ZX81 RAM pack Issue 3 (ULA 1H035E) DRAM refresh

[1024MAK]

Yeah, I’ve got a Sinclair 16K RAM pack, and it’s a single board inside IIRC. But it’s a case of (1) finding it, (2) it’s non-functional, but I’ve never gotten around to working out why and (3) finding the time to play, err experiment…

Actually I may have another one somewhere, but I’ve not opened this one. And I forget if I even tested it .

Mark

[Bloodnok]

I think I may be able to shed some light on this (and thanks to those who have previously managed to trace the pinouts, it saved quite a bit of time).

The only way to see what is really happening is to hook up a logic analyser and so that is what I've done. Once the relationships can be seen clearly then it's straight forward to work out the rest.

As is clear from the schematic, the ULA only has a possible refresh role for the upper 3 row addresses (A4-A6) of the ram. The rest of the address lines (A0-A3) are muxed as standard and rely on the Z80 refresh mechanism. The question is why provide an independent (and apparently redundant) refresh mechanism for A4-A6 at all?

If I can believe the debug screen on the dependable EightyOne emulator (and I'm absolutely sure I can )then an interesting thing happens to the Z80 refresh counter when the ZX81 is displaying video (most ZX81 enthusiasts will already know this).

At each HALT the R register is reset to $DD and rolls over to $80 continuing the count to $87 before encountering another HALT where it's reset to $DD again. This means that there is a gap in addressing between $88 and $DC where these addresses are not refreshed. It ends up that A4-A6 don't change often enough to meet the minimum refresh specification so they need to refreshed somehow. A0 to A3 are always refreshed as the lower 4 bits of the R register continuously cycle through all 16 combinations. When in fast mode and not displaying video the refresh counter is not reset (unless by the application running at the time).

Digging deeper, the ULA looks to have a 3 bit counter providing the refresh addressing for A4-A6. The analyser trace shows this to be clocked by a free-running oscillator at a frequency of just over 6kHz on the ULA I have. This is probably a simple inverter based RC oscillator and it's frequency doesn't have to be too accurate. A likely design for the 3 bits needed would be the LSB being the oscillator output and 2 more bits produced by a two stage ripple counter.

Correction: Actually, the truth is much simpler (as Simon has pointed out) there's just an 8 bit counter, clocked by refresh, as in all the previous Sinclair ram packs, with the upper 3 bits being mapped to A4-A6 during refresh.

So hopefully mystery solved. Sinclair had to design for the worst refresh case, which for the ZX81, is when displaying video. To fully implement the previous design onto a ULA was probably not cost effective (it would have needed another 13 pins or so for the mux), hence the cut down version refreshing only what was absolutely necessary.

[Sam-Can]

The analyser trace shows this to be clocked by a free-running oscillator at a frequency of just over 6kHz on the ULA I have.

Mystery indeed seemingly solved. FWIW I've measured the outputs from a4, a5 and a6 carefully, using an idea from Mark where the /RFSH line is pulsed via the Z80 clock. It's easy to then see the 3-bit counter (oscillator... etc.) increments on each /RFSH pulse - a bit like the Issue 1 and 2 design.

In this test, the /RFSH input is effectively receiving a regular stream of pulses, rather than bouncing around a bit with instructions of different timings as would normally be the case. So the timing is obviously not real-world, although the sequence of operations is. Also of note is that I have (input) A4 set to logic 1 and (input) A5 set to logic 0. Remember that when not doing memory operations, the default output values of a4, a5, a6 are the input A4, A5, A6 values.

What is going on here:

• Yellow is the output a4 line: in the first part it's at logic 1 (cells containing two values [a4 i.e. 1] and [counter lsb 1]) then there are 32 cycles (cells containing two values [a4 i.e. 1] and [counter lsb 0]) - and this repeats endlessly.

• Blue is the output a5 line: this is a sequence of logic 0 (i.e. [a5=0] and [counter msb 0]) and then 64 cycles (yes I counted them: [a5 = 0] and [counter msb 1]) - and this repeats endlessly.

Not shown is a6, although same pattern except 128 cycles.

All this to say that, like the previous post mentioned, on each refresh cycle the ID of the row selected is: bit 0 = A0 containing bit 0 of I:R (as presented by the Z80 on the address bus during a refresh cycle), bit 1 = ... bit 1 of R, bit 2 = bit 2 of r, bit 3 = bit 3 of r, bit 4 gets a bit that is 0 for 32 refresh cycles and 1 for 32 refresh cycles, bit 5 gets 0 for 64 refresh cycles and 1 for 64 refresh cycles, and bit 6 every 128. This suggests that the internal counter of /RFSH pulses is an 8-bit one, where the top 3 bits are reflected in to a4/a5/a6. It seems like it's a bit off (e.g. 32 values of 0-0-0-r3-r2-r1-r0 rather than 16) but... well I guess it works