With R57 gone (C54 is still in, I'll probably remove it another time) the memory corruption problem seems to be gone.
I was aware there can be some mechanism to allow the CPU to refresh the lower RAM when the ULA isn't reading from it, but I hadn't given it much thought until I saw that it was missing on another Issue 2. I had, probably naively, assumed this Spectrum would have worked properly when it was new and so hadn't expected a problem to be caused by something that was probably there from the day it was built.
I don't feel up to working out exactly why the problem happened, at least not at this hour anyway, but I suspect it can be done.
The corruption was fairly specific. I ran a BASIC program that first filled an memory area (I usually used the display) with a particular value (I ran it most often using 255) and then looped repeatedly reading values back from the area and stopping, reporting what value it had found and at which location if a value had changed
Once a value had become changed, it stayed changed (found from lowering RAMTOP and running the test over the upper part of lower RAM), so the problem wasn't due to a one-off read error. I don't think the Spectrum would have had any cause to write to the area under test while the program was running, so it wasn't corruption occurring to a data value during a write. I am speculating that the problem was caused by (perhaps just one bit of) an intended write going to a wrong location (i.e. within the area being tested).
It probably isn't co-incidence that when corruption occurred within the display area of memory it was always in the first character column. Perhaps whatever point the ULA is in in its read cycle as it accesses those memory locations (probably starting up again after having a break due to the border) made it a vulnerable period and if the CPU made a write at that moment, it was prone to go wrong.
Is it possible for you to try different ULA versions (5C112 vs. 6C001) in that machine? So far I've only tested with the later ULA's, not sure whether I even have a 5C112. Other suspects: crappy power supply / bypass capacitors, transistor inverter, and use of a high-speed cache SRAM vs. the slower low-power types.
I'm not sure I've got a 6C001 ULA that isn't soldered into a Spectrum and I don't think I want to remove one just for this test. I will check though.
I suspect all and any of those things, plus poor connections between the board and RAM sockets; it is a rather crude construction.
I notice that in the Issue 4 Spectrum my transistor inverter circuit (at least I assume it is) puts quite a bit of a sawtooth like noise back onto the the /RAS line, but it doesn't seem to cause a problem. The circuit is a fairly standard one transistor inverter with a base-collector diode and a speed-up capacitor in parallel with the input resistor. I suspect adding lowish value resistor before the input may help.
With the SRAM board connected to the Issue 2, the display changes dramatically and the Spectrum sometimes resets if I touch a 'scope probe to the inverted /RAS signal at the clock input of the latch IC. However, this signal and others around the board seem to look about as I'd expect them to. The Issue 4 Spectrum just carries on as normal when I probe any of the signals on the board.
Btw you mention a Z80C (Z84C00xx I assume) put into it, is that this machine & if so, what speed grade? In my experience 8 or 10 MHz is usually fine, but 20 MHz version might not be a good match for a machine like the Spectrum.
One would expect pixels that are a result of missing Refreshes random all over the screen. Finding all (most) in the left column makes one think of a RAS/MUX/CAS thing. My early Iss2 diagram (Dickens) shows that RFSH is not only RAS but used for MUX ('S' on LS157) too, without organized delay.
What would happen when MUX is toggling while RAS is still settling.
C54 (470pF) connects to R33 (680R) and has to do with enabling ROM (/CE)
R57 is not required. The intention was to let the Z80 drive the /RAS for a refresh whenever the ULA was not accessing the lower 16K. The resistor decoupled the z80 from /RAS. However, a ULA bug means that ULA /RAS only goes high impedance when the z80 accesses the rom during a border update, so CPU refresh never really occurs. (I'll have to check the specific detail).
So, the dram is refreshed just by ULA video read - well out of spec for the chips, but seemingly enough! Thus the resistor was removed.
C54 (470pF) connects to R33 (680R) and has to do with enabling ROM (/CE)
No, on an Issue 2 at least, C54, if present, connects between 0V and /RFSH.
A correction: in some previous posts I mentioned that I'd been using an Issue 4 Spectrum+ in some tests. It is actually an Issue 6A, I don't know whether or not that makes much difference to the relevance of the outcomes.
I see Chris Smith has joined us! I've just re-read the section of the ULA book about the CPU refresh (or otherwise) of the lower RAM. If the description is correct then it explains the strange waveforms I saw on /RAS. I'm still not how sure how nor whether this could cause memory corruption nor if it does, why some areas of memory would seem to be affected more than others. Perhaps some 4116s are a bit sensitive and don't behave if a malformed /RAS signal arrives at just the wrong moment.
I committed the terrible crime of changing two things at once. At the same time as I removed R57 I also modified the power supply circuit (resistor change and addition of a capacitor) as recommended in the service manual. Could this have been what stopped the memory corruption instead? The 12V and -5V (and +5V) lines at the 4116s always seemed clean and stable, but I didn't spend much time examining them and is the power supply modification likely to have much effect on them if they weren't? Could it be that something that happens at the start of each display line (say in the video circuitry when the switch from the border colour to the paper colour happens) caused a glitch on one or more of the power lines and that's what affected the RAM, causing a risk of corrupting the address it was accessing at the time?
I suppose I could easily put R57 back and see whether the corruption returns.
It does appear the Issue 2 Spectrum went through a number of variations. E.g. it is often claimed R57 was done away with after Issue 1, but it clearly wasn't in some cases and it is on the Issue 2 circuit diagram. As I mentioned somewhere earlier, the arrangement of connections between the lower RAM and the ULA on the Issue 2 Spectrum I have been working on is as shown in the Issue 3 diagram. Is this a mistake in the diagram or were there different versions? It's of little operational consequence, but it was quite confusing at first while I was trying to check everything was connected as it should be.
However, a ULA bug means that ULA /RAS only goes high impedance when the z80 accesses the rom during a border update, so CPU refresh never really occurs. (I'll have to check the specific detail).
Hmmm. So that means CPU refresh would happen sometimes as the CPU must happen to access the ROM at least now and then while the border is being displayed.
What would be happening on the lower RAM address lines when the border is being displayed and the CPU is reading the ROM? Perhaps a CPU generated /RAS pulse could interfere with the set-up of the address for the first display byte if it happens just as the end of the border arrives. If that happens, I'd have thought it'd lead to corruption of the display, but not the contents of RAM. Perhaps it's a 'feature' of the 4116 that contents can be damaged if an address is not properly set-up. For example if the address lines were to change during a /RAS only refresh.
No, on an Issue 2 at least, C54, if present, connects between 0V and /RFSH.
I stand corrected. On my Iss2 board both C54 and R57 are not present. Looks like a solution to 'synchronise' Z80-rfsh and ULA-ras. Typical Sinclair then.
With regards the issue 6 circuit board, have a look at the ULA versions chapter. The later motherboards delay the /RAS through two NANDs configured as inverters. You MUST use a 6C with these, though the 6C is backwards compatible with all models. This is also noted in the spectrum service manual.
These inverters would clean up the signal as well in your case - that half-logic level would register as high or low. Where are you measuring /RAS? A the ULA or DRAM? If at the ULA, then no cleanup possible.
I'd be surprised if the CPU RFSH signal was messing with the RAS, unless the coupling resistor was too small. Also with that capacitor, a low pass filter is also operating... Can't think why it's there, it would probably mostly soften the edges of the CPU RFSH transitions.
I see that in the Issue 4 and up, /RAS is delayed by a pair of gates to provide the strobe input to the address multiplexors, but in earlier issues /RAS is used directly. This should only be of consequence when the CPU accesses the lower RAM.
I've made some measurements to try to determine the delay between /RAS going low and the address lines at the lower RAM changing in what seems to be the case of a CPU access. In an Issue 2 Spectrum, it looks to be 25-30ns. This is about what the TI datasheet for a 74LS157 says should be the case.
The 4116 datasheet says the row address must be stable for a minimum of 20ns before /CAS goes low (for the 200ns version). Apparently the shortest delay in the output changing after the strobe input changing is 20ns for a typical 74LS157. I think Sinclair were a bit lucky that it works reliably.
I then measured the delay introduced by the transistor inverter used on the SRAM board I made. Following a falling edge at the input, it takes 25-35ns before there is a valid logic high at the output. The rise time is also rather greater than might be usual in a simple TTL circuit.
This probably explains why the SRAM board works well in the Issue 6A, but not the Issue 2. In the Issue 2 the display is corrupted rather than completely incoherent, so the delay introduced by the inverter is probably only very slightly too great on average.
It seems I need to experiment further with the inverter circuit to try to make it a bit faster. I'm sure there used to exist small four-legged devices that contained a single logic inverter, but I haven't seen one for years.
Found in modification history a msge about the 470pF capacitor at RFSH:
- Needed when Z80 and all RAMs are of NEC manufacture.
-R57 (330R) must be removed when all RAMs are of NATIONAL manufacture, no 470 pF, and RAS & CAS both with 1K to 12V. (in fact it says 23V)
Comments
I was aware there can be some mechanism to allow the CPU to refresh the lower RAM when the ULA isn't reading from it, but I hadn't given it much thought until I saw that it was missing on another Issue 2. I had, probably naively, assumed this Spectrum would have worked properly when it was new and so hadn't expected a problem to be caused by something that was probably there from the day it was built.
I don't feel up to working out exactly why the problem happened, at least not at this hour anyway, but I suspect it can be done.
The corruption was fairly specific. I ran a BASIC program that first filled an memory area (I usually used the display) with a particular value (I ran it most often using 255) and then looped repeatedly reading values back from the area and stopping, reporting what value it had found and at which location if a value had changed
Once a value had become changed, it stayed changed (found from lowering RAMTOP and running the test over the upper part of lower RAM), so the problem wasn't due to a one-off read error. I don't think the Spectrum would have had any cause to write to the area under test while the program was running, so it wasn't corruption occurring to a data value during a write. I am speculating that the problem was caused by (perhaps just one bit of) an intended write going to a wrong location (i.e. within the area being tested).
It probably isn't co-incidence that when corruption occurred within the display area of memory it was always in the first character column. Perhaps whatever point the ULA is in in its read cycle as it accesses those memory locations (probably starting up again after having a break due to the border) made it a vulnerable period and if the CPU made a write at that moment, it was prone to go wrong.
I'm not sure I've got a 6C001 ULA that isn't soldered into a Spectrum and I don't think I want to remove one just for this test. I will check though.
I suspect all and any of those things, plus poor connections between the board and RAM sockets; it is a rather crude construction.
I notice that in the Issue 4 Spectrum my transistor inverter circuit (at least I assume it is) puts quite a bit of a sawtooth like noise back onto the the /RAS line, but it doesn't seem to cause a problem. The circuit is a fairly standard one transistor inverter with a base-collector diode and a speed-up capacitor in parallel with the input resistor. I suspect adding lowish value resistor before the input may help.
With the SRAM board connected to the Issue 2, the display changes dramatically and the Spectrum sometimes resets if I touch a 'scope probe to the inverted /RAS signal at the clock input of the latch IC. However, this signal and others around the board seem to look about as I'd expect them to. The Issue 4 Spectrum just carries on as normal when I probe any of the signals on the board.
It's a Z84C0006PEG, according to its label :-)
What would happen when MUX is toggling while RAS is still settling.
C54 (470pF) connects to R33 (680R) and has to do with enabling ROM (/CE)
So, the dram is refreshed just by ULA video read - well out of spec for the chips, but seemingly enough! Thus the resistor was removed.
No, on an Issue 2 at least, C54, if present, connects between 0V and /RFSH.
A correction: in some previous posts I mentioned that I'd been using an Issue 4 Spectrum+ in some tests. It is actually an Issue 6A, I don't know whether or not that makes much difference to the relevance of the outcomes.
I see Chris Smith has joined us! I've just re-read the section of the ULA book about the CPU refresh (or otherwise) of the lower RAM. If the description is correct then it explains the strange waveforms I saw on /RAS. I'm still not how sure how nor whether this could cause memory corruption nor if it does, why some areas of memory would seem to be affected more than others. Perhaps some 4116s are a bit sensitive and don't behave if a malformed /RAS signal arrives at just the wrong moment.
I committed the terrible crime of changing two things at once. At the same time as I removed R57 I also modified the power supply circuit (resistor change and addition of a capacitor) as recommended in the service manual. Could this have been what stopped the memory corruption instead? The 12V and -5V (and +5V) lines at the 4116s always seemed clean and stable, but I didn't spend much time examining them and is the power supply modification likely to have much effect on them if they weren't? Could it be that something that happens at the start of each display line (say in the video circuitry when the switch from the border colour to the paper colour happens) caused a glitch on one or more of the power lines and that's what affected the RAM, causing a risk of corrupting the address it was accessing at the time?
I suppose I could easily put R57 back and see whether the corruption returns.
It does appear the Issue 2 Spectrum went through a number of variations. E.g. it is often claimed R57 was done away with after Issue 1, but it clearly wasn't in some cases and it is on the Issue 2 circuit diagram. As I mentioned somewhere earlier, the arrangement of connections between the lower RAM and the ULA on the Issue 2 Spectrum I have been working on is as shown in the Issue 3 diagram. Is this a mistake in the diagram or were there different versions? It's of little operational consequence, but it was quite confusing at first while I was trying to check everything was connected as it should be.
Hmmm. So that means CPU refresh would happen sometimes as the CPU must happen to access the ROM at least now and then while the border is being displayed.
What would be happening on the lower RAM address lines when the border is being displayed and the CPU is reading the ROM? Perhaps a CPU generated /RAS pulse could interfere with the set-up of the address for the first display byte if it happens just as the end of the border arrives. If that happens, I'd have thought it'd lead to corruption of the display, but not the contents of RAM. Perhaps it's a 'feature' of the 4116 that contents can be damaged if an address is not properly set-up. For example if the address lines were to change during a /RAS only refresh.
These inverters would clean up the signal as well in your case - that half-logic level would register as high or low. Where are you measuring /RAS? A the ULA or DRAM? If at the ULA, then no cleanup possible.
I'd be surprised if the CPU RFSH signal was messing with the RAS, unless the coupling resistor was too small. Also with that capacitor, a low pass filter is also operating... Can't think why it's there, it would probably mostly soften the edges of the CPU RFSH transitions.
I see that in the Issue 4 and up, /RAS is delayed by a pair of gates to provide the strobe input to the address multiplexors, but in earlier issues /RAS is used directly. This should only be of consequence when the CPU accesses the lower RAM.
I've made some measurements to try to determine the delay between /RAS going low and the address lines at the lower RAM changing in what seems to be the case of a CPU access. In an Issue 2 Spectrum, it looks to be 25-30ns. This is about what the TI datasheet for a 74LS157 says should be the case.
The 4116 datasheet says the row address must be stable for a minimum of 20ns before /CAS goes low (for the 200ns version). Apparently the shortest delay in the output changing after the strobe input changing is 20ns for a typical 74LS157. I think Sinclair were a bit lucky that it works reliably.
I then measured the delay introduced by the transistor inverter used on the SRAM board I made. Following a falling edge at the input, it takes 25-35ns before there is a valid logic high at the output. The rise time is also rather greater than might be usual in a simple TTL circuit.
This probably explains why the SRAM board works well in the Issue 6A, but not the Issue 2. In the Issue 2 the display is corrupted rather than completely incoherent, so the delay introduced by the inverter is probably only very slightly too great on average.
It seems I need to experiment further with the inverter circuit to try to make it a bit faster. I'm sure there used to exist small four-legged devices that contained a single logic inverter, but I haven't seen one for years.
Edit: found out that 25 nsec is not a bad time after all!
- Needed when Z80 and all RAMs are of NEC manufacture.
-R57 (330R) must be removed when all RAMs are of NATIONAL manufacture, no 470 pF, and RAS & CAS both with 1K to 12V. (in fact it says 23V)