Help - Implementing Shadow RAM in CPLD
- daveejhitchins
- Posts: 6087
- Joined: Wed Jun 13, 2012 6:23 pm
- Location: Newton Aycliffe, County Durham
- Contact:
Re: Help - Implementing Shadow RAM in CPLD
You could try a higher value resistor e.g. lower the charging current - and strap a 3V9 Zener across the battery - Although zeners aren't that accurate so maybe a 1N4001 (or just any diode - 1N4148/BAT52 etc. anything to drop the Voltage!) in series with the feed from the battery to your RTC.
Dave H.
Dave H.
Re: Help - Implementing Shadow RAM in CPLD
I went for 150R, based on the discussion in this thread:daveejhitchins wrote: ↑Wed Nov 25, 2020 8:19 amYou could try a higher value resistor e.g. lower the charging current
viewtopic.php?f=3&t=13590&p=269287#p265614
I did toy with this idea earlier, but backed away when I read the following comment in the RTC datasheet. However, I'm fairly sure the RTC wouldn't really know if you're using a diode. It's only interested in a stable voltage, and for the voltage to be within spec, so I may give the series diode a try - unless someone can tell me why that's a bad idea:daveejhitchins wrote: ↑Wed Nov 25, 2020 8:19 amand strap a 3V9 Zener across the battery - Although zeners aren't that accurate so maybe a 1N4001 (or just any diode - 1N4148/BAT52 etc. anything to drop the Voltage!) in series with the feed from the battery to your RTC.
DS12885 Datasheet wrote:VBat - Pin 20: Connection for a Primary Battery. (DS12885 Only.) Battery voltage must be held between the minimum and maximum limits for proper operation. If a backup supply is not supplied, VBAT must be grounded. Connect the battery directly to the VBAT pin. Diodes in series between the VBAT pin and the battery may prevent proper operation. UL recognized to ensure against reverse charging when used with a lithium battery.
Re: Help - Implementing Shadow RAM in CPLD
The series diode didn't work. With nothing connected to the VBat input, I'm measuring about 4.5v on the pin and the RTC does not communicate. If I then take this input and tie it down to Gnd it works fine. Adding the diode prevents the internal voltage on VBat from being pulled down to a low enough level for the RTC to start communicating.KenLowe wrote: ↑Wed Nov 25, 2020 8:39 amI went for 150R, based on the discussion in this thread:daveejhitchins wrote: ↑Wed Nov 25, 2020 8:19 amYou could try a higher value resistor e.g. lower the charging current
viewtopic.php?f=3&t=13590&p=269287#p265614
I did toy with this idea earlier, but backed away when I read the following comment in the RTC datasheet. However, I'm fairly sure the RTC wouldn't really know if you're using a diode. It's only interested in a stable voltage, and for the voltage to be within spec, so I may give the series diode a try - unless someone can tell me why that's a bad idea:daveejhitchins wrote: ↑Wed Nov 25, 2020 8:19 amand strap a 3V9 Zener across the battery - Although zeners aren't that accurate so maybe a 1N4001 (or just any diode - 1N4148/BAT52 etc. anything to drop the Voltage!) in series with the feed from the battery to your RTC.
DS12885 Datasheet wrote:VBat - Pin 20: Connection for a Primary Battery. (DS12885 Only.) Battery voltage must be held between the minimum and maximum limits for proper operation. If a backup supply is not supplied, VBAT must be grounded. Connect the battery directly to the VBAT pin. Diodes in series between the VBAT pin and the battery may prevent proper operation. UL recognized to ensure against reverse charging when used with a lithium battery.
The Zener may be the next best option. I'll have a look at that now.
- daveejhitchins
- Posts: 6087
- Joined: Wed Jun 13, 2012 6:23 pm
- Location: Newton Aycliffe, County Durham
- Contact:
Re: Help - Implementing Shadow RAM in CPLD
That doesn't make sense! What do you mean by "With nothing connected to the VBat input"? You can't do that - Vbat needs connecting to ground or the battery.KenLowe wrote: ↑Wed Nov 25, 2020 9:33 amThe series diode didn't work. With nothing connected to the VBat input, I'm measuring about 4.5v on the pin and the RTC does not communicate. If I then take this input and tie it down to Gnd it works fine. Adding the diode prevents the internal voltage on VBat from being pulled down to a low enough level for the RTC to start communicating.
The Zener may be the next best option. I'll have a look at that now.
The Vbat pin in an input! Data sheet says "Battery voltage must be held between 2.5V and 4V for proper operation". I don't see how placing a diode between the battery and the Vbat pin can't work! All you're doing is losing the Voltage across the diode! What diode did you use? I'd try a 1N4148 - with such a low current (you can check how much by reading your RAM data sheets) you'll only lose up to 600mV (probably less!) which should be enough to get you out of trouble.
Dave H.
Re: Help - Implementing Shadow RAM in CPLD
Sure, but if you leave the input it floating, and measure what's on the pin you get a voltage. I discovered that when I connected the diode and it didn't appear to do anything. When I measured the voltage upstream of the diode I got the battery voltage. Downstream of the diode I got a voltage that was higher than the battery voltage which initially didn't appear to make any sense. Disconnecting the diode didn't change that. So, although it's an input there must be some internal circuitry that's causing that to happen. Attaching a fixed voltage direct to the input pulls that pin voltage down and allows it to work. With the series diode in circuit it doesn't allow this to happen. I'm sure that's why the datasheet states:daveejhitchins wrote: ↑Wed Nov 25, 2020 12:03 pmThat doesn't make sense! What do you mean by "With nothing connected to the VBat input"? You can't do that - Vbat needs connecting to ground or the battery.KenLowe wrote: ↑Wed Nov 25, 2020 9:33 amThe series diode didn't work. With nothing connected to the VBat input, I'm measuring about 4.5v on the pin and the RTC does not communicate. If I then take this input and tie it down to Gnd it works fine. Adding the diode prevents the internal voltage on VBat from being pulled down to a low enough level for the RTC to start communicating.
The Zener may be the next best option. I'll have a look at that now.
The Vbat pin in an input! Data sheet says "Battery voltage must be held between 2.5V and 4V for proper operation". I don't see how placing a diode between the battery and the Vbat pin can't work! All you're doing is losing the Voltage across the diode! What diode did you use? I'd try a 1N4148 - with such a low current (you can check how much by reading your RAM data sheets) you'll only lose up to 600mV (probably less!) which should be enough to get you out of trouble.
Dave H.
Does that make sense, or am I still talking rubbish?DS12885 Datsheet wrote:Diodes in series between the VBAT pin and the battery may prevent proper operation.
I used a BAT43 diode, although I could easily test again with a 1N4148. I've got plenty of those!
Edit: I've just tried with a 1N4148 and it hasn't made any difference. What I did notice, though, is that just connecting a meter to the measure the voltage on the pin causes the RTC to start responding. Remove the meter and it stops again. This happens either with the VBat pin floating, or connected to the battery via the diode. Connecting the battery direct to VBat works as long as the voltage is below about 4v (I think it might be that the voltage at VBat must be more that 0.7v below Vcc, but that's a bit of a guess. Vcc is currently sitting at 5.0v and VBat is sitting at about 4.2v and it's still working, although I expect it to stop working shortly, once VBat reaches about 4.3v)
Re: Help - Implementing Shadow RAM in CPLD
have you got any decoupling on vbat and vdd ?
Re: Help - Implementing Shadow RAM in CPLD
I'm sure I'm just stating what you already know here....
The DS12885/7 are designed use a simple non-rechargable 3V lithium coin-cell, like a CR2032, and the valid range of Vbat is 2.5V to 4.0V
You are using a 3.6V 150mAh Varta battery with a charging circuit consisting of a 68R resistor and a B5819W diode with a Vf of 0.6-0.9v. So when fully charged, that battery is reaching ~4.3v, which is too high for the DS12885.
Placing a diode in series with Vbat doesn't work, because there is nothing stopping the Vbat pin floating higher than the battery voltage (the diode becomes reverse biased and stops conducting).
You could prevent this diode becoming reverse biased by adding a high(ish) value resistor (e.g. 47K) between Vbat and 0V, but this will slowly discharge the battery. The discharge rate would be 75uA so ~2000 hours to completely discharge a 150mAh battery. This may be acceptible, but is a bit of a hack. But fine for testing the bus interface.
A second option is to add a second B5819W into the charging circuit, so the battery reaches a max of ~3.6V.
A third option is to replace the battery by a 3V cell (and adapt the charing circuit appropriately), but that depends on what the mimumum voltage is for data retention in the RAM.
What RAM are you using? The schematic indicates a IS61C5128AS.
Dave
The DS12885/7 are designed use a simple non-rechargable 3V lithium coin-cell, like a CR2032, and the valid range of Vbat is 2.5V to 4.0V
You are using a 3.6V 150mAh Varta battery with a charging circuit consisting of a 68R resistor and a B5819W diode with a Vf of 0.6-0.9v. So when fully charged, that battery is reaching ~4.3v, which is too high for the DS12885.
Placing a diode in series with Vbat doesn't work, because there is nothing stopping the Vbat pin floating higher than the battery voltage (the diode becomes reverse biased and stops conducting).
You could prevent this diode becoming reverse biased by adding a high(ish) value resistor (e.g. 47K) between Vbat and 0V, but this will slowly discharge the battery. The discharge rate would be 75uA so ~2000 hours to completely discharge a 150mAh battery. This may be acceptible, but is a bit of a hack. But fine for testing the bus interface.
A second option is to add a second B5819W into the charging circuit, so the battery reaches a max of ~3.6V.
A third option is to replace the battery by a 3V cell (and adapt the charing circuit appropriately), but that depends on what the mimumum voltage is for data retention in the RAM.
What RAM are you using? The schematic indicates a IS61C5128AS.
Dave
Re: Help - Implementing Shadow RAM in CPLD
I do have on Vdd, but not on VBat. However, I do currently have a big lump of battery on VBat!
Thanks for the detailed reply, and thanks for confirming my observations on placing a diode in series with VBat.hoglet wrote: ↑Wed Nov 25, 2020 1:07 pmI'm sure I'm just stating what you already know here....
The DS12885/7 are designed use a simple non-rechargable 3V lithium coin-cell, like a CR2032, and the valid range of Vbat is 2.5V to 4.0V
You are using a 3.6V 150mAh Varta battery with a charging circuit consisting of a 68R resistor and a B5819W diode with a Vf of 0.6-0.9v. So when fully charged, that battery is reaching ~4.3v, which is too high for the DS12885.
Placing a diode in series with Vbat doesn't work, because there is nothing stopping the Vbat pin floating higher than the battery voltage (the diode becomes reverse biased and stops conducting).
You could prevent this diode becoming reverse biased by adding a high(ish) value resistor (e.g. 47K) between Vbat and 0V, but this will slowly discharge the battery. The discharge rate would be 75uA so ~2000 hours to completely discharge a 150mAh battery. This may be acceptable, but is a bit of a hack. But fine for testing the bus interface.
A second option is to add a second B5819W into the charging circuit, so the battery reaches a max of ~3.6V.
A third option is to replace the battery by a 3V cell (and adapt the charing circuit appropriately), but that depends on what the minimum voltage is for data retention in the RAM.
What RAM are you using? The schematic indicates a IS61C5128AS.
Dave
Yes, I have been pondering the various options. I'm actually using a low power CY62148ELL-45ZSXI (I'll update the schematic to reflect that), with a minimum Data Retention voltage (Vdr) of 2v, so a non rechargeable button cell is certainly an option.
The simplest solution is probably to stick another diode into the charging circuit, in series with the existing diode. However, I did quite like the option of adding a Zener diode / resistor arrangement on the battery output to clamp the voltage at 3v3, and I've already updated the schematic to reflect this. I probably also need to add a bit of decoupling to this, if I do go down this route. Is there a particular downside to the Zener barrier option?
The VBat voltage has crept up to 4.27v, and Vcc remains at 5.00v. Unsurprisingly, at these levels, the RTC has stopped communicating again.KenLowe wrote: ↑Wed Nov 25, 2020 12:17 pmI think it might be that the voltage at VBat must be more that 0.7v below Vcc, but that's a bit of a guess. Vcc is currently sitting at 5.0v and VBat is sitting at about 4.2v and it's still working, although I expect it to stop working shortly, once VBat reaches about 4.3v
Re: Help - Implementing Shadow RAM in CPLD
The zener option sounds workable as well.
Definitely worth prototyping though!
Definitely worth prototyping though!
- daveejhitchins
- Posts: 6087
- Joined: Wed Jun 13, 2012 6:23 pm
- Location: Newton Aycliffe, County Durham
- Contact:
Re: Help - Implementing Shadow RAM in CPLD
OK . . . Solution . . . Use a non rechargeable Lithium (3V or 3.6V) - You'll have at least 5 years out of it. Problem solved.
As Hoglet has said - it must have internal circuitry that allows the pin to float, reverse biasing any diode in series.
Dave H.
As Hoglet has said - it must have internal circuitry that allows the pin to float, reverse biasing any diode in series.
Dave H.
Re: Help - Implementing Shadow RAM in CPLD
Added bonus is no potentially leaky battery soldered to the board waiting to barf its guts up in the futuredaveejhitchins wrote: ↑Wed Nov 25, 2020 2:30 pmOK . . . Solution . . . Use a non rechargeable Lithium (3V or 3.6V) - You'll have at least 5 years out of it. Problem solved.


Re: Help - Implementing Shadow RAM in CPLD
Thanks for all the advice, guy. It's very much appreciated. I think I've been convinced on the button cell option - particularly once I started to think a bit more about the Zener barrier option. My initial thoughts were to go with a 3v3 barrier, but thinking about it a bit more, I realise that doesn't make much sense for a nominal 3.6v battery! Sensibly, it would need to be above 3.6v (eg 3v9 as Dave H suggested earlier), which reduces the working margin available. So non rechargeable battery it is, then!
Having identified and solved the VBat problem, I'm still being frustrated with the DS12885 that's soldered onto my V2 board. It still refuses to communicate, even with the VBat input now within tolerance (I've tried with it tied to Gnd). On this board I had previously cut the data bus tracks, so I could insert some inline resistors between the data buffer and the RTC, but that didn't seem to make much difference, and in further testing I wasn't sure if cutting the tracks and patching in resistors may have made things worse. So I built up a second V2 board last night to see if that would work any better. On this board, I'm using a remotely mounted 3v button cell, and I've cut the specifically designed link bar to disconnect the 5v feed to the charging circuit. Unfortunately, this hasn't made any difference and this RTC doesn't work either. Again, and as with the previous V2 board, if I disable the onboard RTC (by just not pulsing the AS & DS lines) and hook up a remote RTC (using 'spare' I/O from the CPLD to drive AS and DS) it works just fine. I'm going to spend some more time tomorrow looking into this.
Having identified and solved the VBat problem, I'm still being frustrated with the DS12885 that's soldered onto my V2 board. It still refuses to communicate, even with the VBat input now within tolerance (I've tried with it tied to Gnd). On this board I had previously cut the data bus tracks, so I could insert some inline resistors between the data buffer and the RTC, but that didn't seem to make much difference, and in further testing I wasn't sure if cutting the tracks and patching in resistors may have made things worse. So I built up a second V2 board last night to see if that would work any better. On this board, I'm using a remotely mounted 3v button cell, and I've cut the specifically designed link bar to disconnect the 5v feed to the charging circuit. Unfortunately, this hasn't made any difference and this RTC doesn't work either. Again, and as with the previous V2 board, if I disable the onboard RTC (by just not pulsing the AS & DS lines) and hook up a remote RTC (using 'spare' I/O from the CPLD to drive AS and DS) it works just fine. I'm going to spend some more time tomorrow looking into this.
Re: Help - Implementing Shadow RAM in CPLD
Got the logic analyser hooked up today. Firstly, very simple code:
In the CPLD, RTC_AS and RTC_DS are defined as follows:
And this is what happens with a trigger on rising edge of RTC_AS. According to the RTC datasheet, the address is latched on falling edge of AS. It appears that &FE is what's actually getting latched. Note that the bus has currently got pull up via 4k7 resistor network. Any thoughts? How do I stop that final &FE being latched into the RTC?
I'm guessing D0 is a little bit noisy and the logic analyser is perhaps picking up some false pulses (hence the occasional &FE instead of &FF?). Although, that doesn't have a bearing on the fact the the RTC address is being latched when the data bus has nothing on it?
Code: Select all
.start
LDA #&55
STA &FE38
LDA #&AA
STA &FE38
JMP start
Code: Select all
wire FE3x = (bbc_ADDRESS[15:4] == 12'hFE3);
assign RTC_AS = FE3x && (bbc_ADDRESS[3:2] == 2'b10) && !RnW && Phi2; // &FE38..B -> Address Strobe
assign RTC_DS = FE3x && (bbc_ADDRESS[3:2] == 2'b11); // &FE3C..F -> Data Strobe
I'm guessing D0 is a little bit noisy and the logic analyser is perhaps picking up some false pulses (hence the occasional &FE instead of &FF?). Although, that doesn't have a bearing on the fact the the RTC address is being latched when the data bus has nothing on it?
Last edited by KenLowe on Sat Nov 28, 2020 1:10 pm, edited 1 time in total.
Re: Help - Implementing Shadow RAM in CPLD
Ken,
The Logic Analyzer trace suggests you have sampled at 20KHz.
I assume that's incorrect?
But what was the sampling clock speed?
(You should be running at 12MHz, the fastest the FX2 will sample 16-bits at)
Dave
The Logic Analyzer trace suggests you have sampled at 20KHz.
I assume that's incorrect?
But what was the sampling clock speed?
(You should be running at 12MHz, the fastest the FX2 will sample 16-bits at)
Dave
Last edited by hoglet on Sat Nov 28, 2020 1:11 pm, edited 1 time in total.
Re: Help - Implementing Shadow RAM in CPLD
Duh 
If I run it at 4MHz is that fast enough?

If I run it at 4MHz is that fast enough?
Re: Help - Implementing Shadow RAM in CPLD
Right. Not sure what you mean by the 16 bit wide mode, but here a much more sensible capture. I'll now try writing some data as well through the data strobe:
Re: Help - Implementing Shadow RAM in CPLD
That's much better.
The FX2 board can capture between 1 and 8 signals at upto 24MHz. However, if you capture between 9 and 16 signals, the max capture rate drops to 12MHz.
Dave
Re: Help - Implementing Shadow RAM in CPLD
Ah. Ok, I understand. Because I'm capturing 12 signals, I'm using the 16 bit mode (and therefore limited to 12MHz).
Right, this time I'm running the following endless loop:
Code: Select all
.start
LDA #&20
STA &FE38 ;Strobe in address &20
LDA #&55
STA &FE3C ;Strobe in value &55 to address &20
LDA #&20
STA &FE38 ;Strobe in address &20
LDA #&AA
STA &FE3C ;Strobe in value &AA to address &20
BNE start ;and loop
RTS
Re: Help - Implementing Shadow RAM in CPLD
This time, I've tied RTC_DS to Phi2:
Not exactly what I expected based on the previous trace. I had hoped the falling edge of RTC_DS would happen marginally earlier than the rising edge of R/nW, but that hasn't happened here. Looking at timing diagram in the datasheet, I'm pretty sure the falling edge of RTC_DS needs to happen before the rising edge of R/nW, but that's not what's happening. Am I reading the timing diagram right? Any thoughts on how best to correct this?
Code: Select all
wire FE3x = (bbc_ADDRESS[15:4] == 12'hFE3);
assign RTC_AS = FE3x && (bbc_ADDRESS[3:2] == 2'b10) && !RnW && Phi2; // &FE38..B -> Address Strobe
assign RTC_DS = FE3x && (bbc_ADDRESS[3:2] == 2'b11) && Phi2; // &FE3C..F -> Data Strobe
Re: Help - Implementing Shadow RAM in CPLD
The RnW signal on a 6502 will always lag the falling edge of Phi2, usually by about 50ns.
They only look like they are happening at the same time because the logic analyzer is only sampling at 12MHz (83ns).
If you put the two siignals on a scope, you should be able to measure the delay more accurately.
Dave
Re: Help - Implementing Shadow RAM in CPLD
That might actually explain what's going wrong, then. The R/nW signal is wired direct from the CPU, whereas the RTC_AS & RTC_DS signals are generated via the CPLD. Could it be that there is sufficient delay in the CPLD to cause an issue? I'm using a 10ns CPLD. As you suggest, I'll wire it up to my scope and get a better view of the edges.hoglet wrote: ↑Sat Nov 28, 2020 2:53 pmThe RnW signal on a 6502 will always lag the falling edge of Phi2, usually by about 50ns.
They only look like they are happening at the same time because the logic analyzer is only sampling at 12MHz (83ns).
If you put the two siignals on a scope, you should be able to measure the delay more accurately.
Dave
Re: Help - Implementing Shadow RAM in CPLD
I would be very surprised if the there was a timing issue there.KenLowe wrote: ↑Sat Nov 28, 2020 3:24 pmThat might actually explain what's going wrong, then. The R/nW signal is wired direct from the CPU, whereas the RTC_AS & RTC_DS signals are generated via the CPLD. Could it be that there is sufficient delay in the CPLD to cause an issue? I'm using a 10ns CPLD. As you suggest, I'll wire it up to my scope and get a better view of the edges.
I would expect the CPLD (generating RTC_DS) to be much faster than a SY6502A (generating RnW).
Dave
Re: Help - Implementing Shadow RAM in CPLD
Here's a trace with a single write of &AA to address &20, followed by multiple reads from address &20. I tend to believe the value &D1 is genuinely what is held at address &20. The value I read stays the same, regardless of what I try to write. If I switch to address &21, I consistently read the value &71, and if I switch back to address &20 again I get the value &D1 again:
Re: Help - Implementing Shadow RAM in CPLD
That suggests it's the RTC write that is failing.
Re: Help - Implementing Shadow RAM in CPLD
It does indeed.
Another odd thing. The results vary depending on whether I have pull up or pull down on the data bus. The data bus is currently terminated with 4k7 resistors. Here's what happens:
With pull up:
Test 1
Strobe in address &20
Strobe out data: Result &D1
Strobe in address &20
Strobe out data: Result &D1
Strobe in address &20
Strobe out data: Result &D1
Strobe in address &20
Strobe out data: Result &D1
...
Test 2
Strobe in address &20
Strobe out data: Result &D1
Strobe out data: Result &FF
Strobe out data: Result &FF
Strobe out data: Result &FF
...
With pull down:
Test 1
Strobe in address &20
Strobe out data: Result &85
Strobe in address &20
Strobe out data: Result &85
Strobe in address &20
Strobe out data: Result &85
Strobe in address &20
Strobe out data: Result &85
...
Test 2
Strobe in address &20
Strobe out data: Result &85
Strobe out data: Result &00
Strobe out data: Result &00
Strobe out data: Result &00
...
Edit: Just swapped out the 4k7 for 1k0, but I get exactly the same results as above.
Re: Help - Implementing Shadow RAM in CPLD
I think that's expected. The data sheet says:
Can you write a program that dumps all of the registers, say once a second?
That would prove that read cycles are working correctly, as you should be at to see the RTC clock registers counting.
Dave
(i.e. it doesn't suggest that multiple "data strobe only" cycles are allowed, nor do the timing diagrams show that).An address strobe must immediately precede each write or read access.
Can you write a program that dumps all of the registers, say once a second?
That would prove that read cycles are working correctly, as you should be at to see the RTC clock registers counting.
Dave
Re: Help - Implementing Shadow RAM in CPLD
Sorry, ignore the last post.
I missed the fact that the Test 1 results were different.
I missed the fact that the Test 1 results were different.
Re: Help - Implementing Shadow RAM in CPLD
Without going down another rabbit hole here, I have noticed that on a system where I can communicate with the RTC, multiple 'data strobe only' access does actually repeatedly give the same value with out having to continually precede it with the same address strobe. So long as you've done at least one address strobe.
The real odd thing that I noticed on this test system is that Test 1 (which did precede a data strobe with an address strobe) gave a different result, depending on whether I used pull up or pull down.
I can certainly write a program to read the clock registers (addresses 00..09). However, you actually need to write to the RTC to start the clock in the first instance - via DV0, 1 & 2 (bits 4, 5 & 6) of control register A (which is also RTC address A), so I won't see any registers counting until it's been initialised.
Edit: Sorry, just notice you made a post as I was writing this one.
Re: Help - Implementing Shadow RAM in CPLD
Hi Dave (or anyone else who might be able to help!),hoglet wrote: ↑Sat Nov 28, 2020 2:53 pmThe RnW signal on a 6502 will always lag the falling edge of Phi2, usually by about 50ns.
They only look like they are happening at the same time because the logic analyser is only sampling at 12MHz (83ns).
If you put the two signals on a scope, you should be able to measure the delay more accurately.
Dave
The datasheet states that during a write operation, 'the trailing edge of DS causes the device to latch the written data', and if I'm reading the data sheet correctly I need a minimum 10ns between RTC_DS falling and RnW rising (tRWH) in order to correctly latch in the data? If the 6502 RnW signal typically lags the falling edge of Phi2 by about 50ns, the timing seems quite marginal, or is that quite normal? I will check that on the scope shortly.
I was also toying with the idea of adding a couple of inverters into the RTC RnW line to see if the extra propagation delay would make any difference. However, that would take a little bit of effort, so wanted to first check if it's a worthwhile exercise, or if I'd just be wasting my time?