How does DRAM refresh work in the Leningrad?

Question

The Leningrad uses the КР565РУ5 chip, which is the same as a 4164. It contains 64kbits of DRAM, and the datasheet says that each of the 256 row addressed need to be strobed every 4ms.

I can see how the address lines A0 through A7 are multiplexed with A8 through A15 using two КП1533КЛ1, which is controlled by RAS. This causes the column and row to be sent to the DRAM chip, makes sense.

Now, the /RFSH signal from the Z80 brings /WE high through some random-looking glue logic; I bet the Z80's DRAM refresh logic is being put to good use. There's just one thing though: the Z80 doesn't flip the highest bit of the R register, and so R only iterates across 32k. So how does the Leningrad refresh the entire DRAM?

(If you don't have the schematics for this computer, they may be found here.)

Answer 1

There's just one thing though: the Z80 doesn't flip the highest bit of the R register,

True

and so R only iterates across 32k.

Not really, it doesn't access 32 Ki but 128 rows.

So how does the Leningrad refresh the entire DRAM?

Well, like any other machine using 4164 RAMs - by refreshing all 128 rows.

It is important to separate address multiplexing (as 8+8) and RAM organization (as 7+9), which is 128 rows of 512 bit cells for the 4164 (*1). Internal bits 6..0 of the row address is used to select a 512 bit row, while bit 7 is used together with bit 7..0 of the column address to address the physical column. As a result it needs only 128 refresh cycles to reload the whole content.

See this excerpt of the original Mostek MK4164 data sheet:

This is true for most chips bearing the 4164 designation (except Fujitsu, National Semi and TI), as well as many other.

According to this list КР565РУ5 are direct analog to Motorola's MCM6664 and Mostek'd MK4164 - both using 128 rows.

The 7 bit refresh was done for 4116 compatibility and came especially handy for Z80 systems, enabling upgrade (and cost saving) without any redesign beyond a new PCB.

---

*1 - Companies with 256x256 organization were Fairchild (F4164), INMOS (IMS2600), Micron (MT4264), National Semi (NMC4164; MMC3764 were 128 row), Siemens (HYB4164) and Texas Instruments (SMJ/TMS4164). All other 64 Ki chips were organized with 128 rows - at least as my memory goes.

Answer 2

From the schematics, I can see this uses a single RAM bank, opposed to the original Sinclair machine, which uses two separate RAM banks.

That means that the entire RAM address space must be shared between the video circuit and the CPU, while the original Sinclair machine only shared 16KB of RAM. Now, it happens that DRAMs are not only refreshed using RAS only refresh cycles (the usual way), but with regular read cycles. As the video circuit must access RAM in a semi-sequential pattern in order to build the screen, that process also refreshes memory. Let's see how:

We will assume that the video circuit reads one the bitmap area every 1.143us (i.e. 7 MHz pixel clock, and a byte holds 8 pixels, so a new bitmap byte is needed every 8 periods of the pixel clock). Let's forget about the attribute byte for the moment. To read the video memory for the first scan, it must read 32 consecutive memory addresses in 36.57us. That is, bits A0 to A4 change while bits A5 to A14 doesn't during this time. Multiplexers are wired so the low address part is used as row address and the high address is used as column address. That means that consecutive accesses hit consecutive row files. During a scanline read, 32 DRAM rows are refreshed in this time. The remaining time, up to 64us (the duration of a scanline in PAL), the video circuit is generating border or blanking signals, and no memory is read.

Scans 0 to 7 use the same row address, as these scans are spaced by 256 bytes. To read the second scanline, the high address byte is incremented, while the low address byte is the same as in scan 0. The same goes for scan 1, scan 2, etc, until scan 7. Low address byte goes from 0 to 31 (dec)

Scans 8 to 15 belong to the next character position. These scans share the same value for bits A15-A8, while A7 to A0 go now from 32 to 63.

Scans 16 to 23 use values for A7-A0 ranging from 64 to 95.

You will see that the complete row space is scanned as the video circuit finishes reading scan 56.

56 scanlines, along with border and blanking, last 56*64=3.584 ms, that's just under the limit of 4ms.

This pattern is repeated three more times: for scans 64 to 127, and again from 128 to 191. After that, there is an interval of time in which RAM is not actively read by the video circuit. For a PAL Spectrum, this interval goes from scanline 192 to 311. That's about 7.7 ms. Too much time without refreshing. During this "void" time, RAM refreshing solely depends upon the Z80 to continue accessing memory. That means that a halted Z80 might cause some RAM corruption. In practice, I've found that much more than a few miliseconds of a halted Z80 are needed to produce noticeable RAM corruption (about 2-3 minutes in a standard Sinclair Spectrum 48K!)

In fact, it's the same technique the Sinclair Spectrum uses to refresh the low memory bank. In the issue 2 model, signal RFSH was still used, but starting with issue 3, the RFSH signal was removed as it was not actually needed.

Answer 3

As mentioned, like many computers of the time, and unlike the original Sinclair ZX Spectrum, it used a single RAM bank.

When computers used a single RAM bank, they would always run the refresh cycle during either HSync or VSync cycles to prevent loss of access to the RAM from the Video Processor. However, the exact version varied by model. Often several models of sold under the same brand were made with different refresh cycle patterns.

The only way to know for sure is to take a hardware analyzer to actual hardware or find someone who has.

I would go over the procedure, but if you aren't able to look it up your own, you shouldn't be doing this one yourself.

This is really only necessary for the highest accuracy of emulation because few, if any, programs took this behavior into account in a manner that would break if it wasn't present.

Currently, several SNES projects are looking into this behavior on the SNES due to games pushing the SNES so far they actually did hit this. (The SNES uses two banks with different refresh rate and data output periods).

I have not heard of any ZX Spectrum emulators replicating this behavior on the original or clones.