What is DRAM refresh and why is the weird Apple II video memory layout affected by it?

Question

I've roughly known the concept for years, but never really understood it. Back in the day, two types of RAM typically used in home computers: static and dynamic RAM. Static RAM (SRAM) was apparently easier to use because it didn't require refreshing (and circuitry to go along with that), and Dynamic RAM (DRAM) was cheaper but required the RAM to be "refreshed".

So as I understand the story, Woz designed the Apple II to use DRAM because it was cheaper but was able to avoid designing refresh circuitry because he used the odd-phase of the 6502 to do it for him by reading the next chunk of video memory which would effectively do the refresh.

So this leaves two questions in my mind:

1. What exactly is DRAM refresh? Is it simply making sure a memory cell is accessed which gives it an electrical charge to keep it alive, or is it more like a 'read and re-write'?

2. If this refresh mechanism is the reason for the non-linear memory layout of the Apple II video, then why? Is it because the gap of 64 lines was the amount of time that the even-phase would get for compute while the video circuitry was still displaying progressively?

For what its worth, how many chips did Woz actually save by doing this anyway?

Answer 1

Summary

Each DRAM chip has multiple "rows" of memory, and each row needs to be accessed in a certain way (not necessarily via a read or write) on a regular basis in order to avoid the memory "fading away." (Basically, this access recharges the capacitors from which the DRAM row is made.)

The Apple II uses two tricks to do this refresh.

1. Any read or write of a single row will refresh that row; on such a read/write the Apple II generates some additional signals that refresh the rows in all the other RAM chips that are not being read/written.
2. While the CPU is not using the bus, the video system reads through an area of RAM to get the data for the screen. This generates reads from a sufficient number of locations with sufficient frequency that, in combination with #1 above, all RAM is guaranteed to be accessed often enough that it will stay refreshed.

The refresh mechanism is entirely unrelated to the non-linear layout of the video system data; it would work just as well if the layout were linear. The non-linear scanning of video memory does save some circuitry in the address generation of the video system itself, however, so Woz took advantage of the fact that the the refresh system doesn't care in what order the addresses are accessed, so long as they are all accessed within a given amount of time.

The following goes into more detail, but it's still more of an overview than a full and complete description. Once you understand the basic concepts you should be able more easily to understand the detailed documentation such as the data sheets linked below and the schematics, as well as be able to ask more precise questions here for particular details.

Chip Select

To start with, you need to understand that static RAM chips (and other peripheral chips) have a "chip select" (CS) pin that, when asserted, tells the chip to read the address bus and read data from or write data to the data bus. (There may be more than one CS pin, but they all need to be asserted together.) So the normal sequence for a read from such a device is to put the desired address on the address bus and then assert CS for just that chip (making sure all other chips have CS deasserted to avoid conflicts), causing it to output the requested data on the data bus.

DRAM Chip Select

The Mostek MK 4116 and similar DRAM used in the Apple II and many other '70s and '80s computers works slightly differently: there are two select lines: row address select (RAS) and column address select (CAS). Among other things, this allowed the chip to have fewer pins since the low-order bits of the address would be sent separately from the high-order bits, using the same pins for both. Thus a read cycle for DRAM is a bit more complex. As shown at the top of page 5 of the data sheet linked above, it is:

1. Put the desired address on address bus.
2. Configure your DRAM address logic to send the lower order bits of the address bus to the DRAM chips' address lines.
3. Assert RAS for all of the DRAM the chips, and then wait a bit for them to read those lower-order bits.
4. Reconfigure your DRAM address logic now to send the higher order bits of the address bus to the DRAM chips' address lines.
5. Assert CAS only for the appropriate bank of DRAM (eight chips, each on one line of the data bus) and then wait a bit for the DRAMs to read those higher-order address bits, read the data from RAM, and start driving the data bus with the data they read.
6. Read the data from the data bus and then deassert RAS and CAS, which will deselect the chips in the bank so that they stop driving the data bus.

There are a couple of important things to note here. First is we assert RAS to all of the DRAM chips. This doesn't cause conflicts because RAS doesn't cause DRAMs to drive the data bus, it just causes them to read the row address from the address bus. Second is that we assert CAS only to one bank: because CAS is what causes the DRAMS to send their data out on the data bus, we must not enable CAS for more than one bank or there would be a conflict.

DRAM Refresh

A DRAM read of any address from a row automatically does a refresh of that entire row. But it's actually a bit easier than that: on the 4116 you don't actually need to do a full read, you need only assert RAS and that's enough to refresh the row. So even a chip that never has CAS asserted after RAS, and thus doesn't actually select a column from that row and drive the data bus with its value, will still have that entire row refreshed. So as long as you're regularly accessing all of the rows with RAS, even if you don't eventually read the data, the DRAM will be refreshed. (The timing diagram that shows this is on the bottom of page 6 of the data sheet linked above.)

Page 148 of the January 1978 Apple II Reference Manual gives an overview of how the DRAMs are connected, though it can also help to consult this Apple II schematic to confirm particular details. While the CAS line is enabled separately for each DRAM bank (which it must be to avoid bus conflicts on DRAM data output), the address pins and RAS are wired in common for all the DRAM banks. This means that an access to any single RAM location will generate an RAS select for that row on all the DRAM chips, refereshing that row in all of them.

Since the DRAM row addresses are 7 bits wide, this means that so long as within the period needed for DRAM refresh you access (for read or write) 128 different RAM locations that differ in their seven lowest-order address bits, you will referesh all of the DRAM on the system. These locations could be,

• $00-$7F,
• $B800-$B8FF,
• $0000, $0081, $0102, $0183, $0204, ..., $3F7F,
• or any other combination.

Video System RAM Access

Now the CPU may or may not access all of the rows regularly; it depends on the program being run. But in the Apple II the CPU is using the address and data buses only half the time: when the Φ2 ("phi two") clock signal is high. The other half of the time, when Φ2 is low, it's doing internal operations and not using the address or data buses.

This other time, when the inverse clock Φ1 is high, is when the video system accesses RAM to read the screen areas for the data to generate the video display. The processor and video system continually alternate cycles this way, CPU on Φ2 and video system on Φ1. This is shown in the diagram from Woz's Apple II system description in the May 1977 issue of BYTE:

The video system, during its cycles, simply walks through each address in the screen memory, reading it and then using that data to generate part of the scan line on the video monitor or TV. And now you see why the Apple II uses the rows, and not the columns, for the low-order address bits: this means that the video system will be looping through every row in each DRAM in every bank, asserting RAS, as the preparation for asserting CAS in the bank from which it's reading the screen information. This loop happens fast enough that, as a side effect, it refreshes all the RAM in the system.

Since this all happens during Φ1, when the CPU is off the bus, the CPU neither knows nor cares that this is happening. Thus it's often called "transparent refresh."

Apple II Video RAM Layout

There are two unusual things about the Apple II video RAM. First, in high-res graphics the lines as displayed on the screen are not sequential in memory: the second "row" of memory is actually displayed a third of the way down the screen, the third "row" two-thirds down, and then the fourth "row" of memory is the second line on the screen. Second, for both high-res graphics and text/low-res graphics, there are some "holes" between the memory "rows" that are bytes that do not generate anything on the display.

Neither of these has anything to do with refresh or even the logic to handle RAS, CAS and DRAM address multiplexing. The former just saves a couple of chips in the video system's memory access logic, and the latter is related to making it easier to get the right timing for the scan lines that are being generated from the data in screen memory.

(Actually, the above paragraph may be wrong about the layout not affecting the DRAM refresh; see Supercat's comments below, and this question.)

Answer 2

DRAM requires that each row of the memory is read and re-written regularly, at least every few milliseconds for the devices available at the time the Apple II was designed. This contrasts with the 16ms (NTSC) or 20ms (PAL) per video field, so several complete DRAM refreshes are required per video frame.

This is made much easier by the DRAM chip having a row buffer which is filled with the contents of the row every time the /RAS strobe is triggered, and written back when it is released. So it is only necessary for the computer to arrange for some address in each row to be accessed (either read or write), which involves both a /RAS and /CAS strobe to provide a row and column address, or for a special /RAS-only refresh cycle.

Some CPUs like the Z80 include specialised DRAM handling circuitry which produces refresh cycles automatically, and multiplexes the row and column addresses in a way that's convenient for accessing DRAM. This however means that some CPU cycles are "lost" to the refresh process, and that the CPU has to be informed when DMA accesses occur so that it can get out of the way by pausing. It also makes interfacing the CPU to SRAM more difficult.

The 6502, used by the Apple II, has a much more straightforward bus interface, in which addresses are provided throughout the cycle but data transfer occurs only during the second half. Many 6502 computers take advantage of this to interleave video scanout accesses with CPU accesses, so that no CPU time is lost to them. It was also reasonably common practice to rely on the video scanout to perform the DRAM refresh function, both so that no dedicated refresh hardware had to be added, and so that no cycles were consumed by it. Typically the 6845 CRTC (or a clone thereof) was used to generate the scanout addresses and video timing.

To achieve this, the video memory has to be laid out so that every frame refresh touches all of the DRAM rows. Assuming the screen refresh rate is at least as fast as the required refresh interval of the DRAM, this is sufficient. Some computers, including the BBC Micro, took special measures in their address translation (from linear on the bus to row/column multiplexed format to the DRAM) to ensure that every possible screen configuration would meet this requirement. In the case of the BBC Micro, the Teletext mode which used only 1000 bytes of RAM was the critical design factor, but the circuitry was designed to present a logically linear address space to the CPU regardless of any contortions behind the scenes.

It appears that in the Apple II, more of these contortions are left visible to the CPU in terms of the layout of video memory. This probably saved a little bit of hardware in the DRAM address multiplexer, and may have been influenced by the higher refresh rate needed in the original Apple II's DRAM than in the later devices available for the BBC Micro. You could get some idea of the magnitude of the saving by comparing the schematics of the original BBC Micro and original Apple II in this area.

Answer 3

What exactly is DRAM refresh? Is it simply making sure a memory cell is accessed which gives it an electrical charge to keep it alive, or is it more like a 'read and re-write'?

Both.

DRAM stores it's information in the charge of a capacitor(*1). Capacitors leak. Chip capacitors leak faster than discrete ones,and small ones even faster (*2)- DRAM chips have to cope with both.

• Reading may be destructive, like with core, and every read needs to be followed by an (internal) write, depending on the design.

• Without reading, unlike core, it still needs a dummy read

Reading, and thus refresh, doesn't work on a cell (bit) base, but always accesses a whole row at once. Thus a single access will refresh all of them in a single cycle.

If this refresh mechanism is the reason for the non-linear memory layout of the Apple II video, then why? Is it because the gap of 64 lines was the amount of time that the even-phase would get for compute while the video circuitry was still displaying progressively?

No. The video memory layout is simply to allow savings within the video address generators used to walk thru memory to generate a frame. For a continuous refresh it's sufficient to address every row once per frame. This is guaranteed due screen refresh.

The whole addressing is the result of the counters used to perform multiple function.

First is simply addressing the bytes during a frame. During a frame the the video counters need to address 40 bytes per line and 262 lines per frame. Doing so the 'standard' way would require a 5 bit counter (0..39) and a 9 bit counter (0..261). Both not really common sizes. Common are 4 and 8 bit counters. So doing this would require at least five 4-bit wide - like a 74161.

Woz now interleaved them to get it down to only four (Position D11..D14) by using two of them as byte counters (D13/D14), but 'stealing the high bit of the second (D13) to form a 9 bit line counter with the other two (D11/D12).

Of course, same 4 chips could have been used to create a linear 13 bit address right way. But then a set of (expensive) comparators and more important another set of counters for timing line/frame timing would have been needed.

Woz' idea was to use them for both, addressing and timing. So the byte counter did not simply run until 40 for all bytes within a line, but 65 which is the line time, using the only first 40 to access. It is as well the value that lets the top bit of D11 flip, increasing the line counter by one. So this saves separate handling of end of line and increment to the next, as it simply carries over (*3).

So essentially it is about building a 16 bit counter and selecting the right bits to generate timing as well as an address. The 'odd' addressing could have been avoided by having timing and addressing handled by different counters, which meant that, for the line length, two additional 74161 would have been needed.

But there is more to it.

Instead of adding a separate refresh logic, needing it's own set of counters - and of course time to access, slowing video or CPU, Woz simply let the video do the refresh as well. This is in part done due the way the cells (rows) are assigned to addresses. A 4116 RAM chip uses a 14 Bit Address organized as 7 bit row and 7 bit column. By default one would assume to simply put CPU address A13..A7 as row (and A6..A0 as column). But Woz did use A12, A8, A7 and A3..A0 as row address (and the remaining as column). This seemingly wired scheme is in part due the fact that video doesn't cover 16 Ki (which would be needed when using A13..A7), but only 8 Ki (size of a highres screen). More so, a video scan over all 8 Ki would take more than the 2 ms 4116 timing allows as maximum timing between refresh (for each row). The way the addresses are assigned ensures that all 128 values are generated within 2048 cycles. At a clock frequency of ~1,024 MHz, this comes down to 2.038 ms, which is close enough to make it work reliable.

Of course while video (content) is only needed during the visible part of the picture, refresh should run all the time. As solution Woz let the address counters continue to address screen RAM during blanking and retrace. This time just discarding the values read.

For what its worth, how many chips did Woz actually save by doing this anyway?

Two 4-bit counters for line length (see above) (*4).

This article at I-Programmer notes:

He also cheated on the addressing for the memory mapped graphics to save two chips at the cost of a strangely mangled memory layout. For years to come users of the Apple II would wonder why memory adjacent memory locations didn't always control adjacent screen locations.

A quick browsing of I Woz didn't show up any relevant information.

---

*1 - With some some early models this is really a storage of an analogue value, thus DRAM could be used to hold more than one value per bit, like modern Flash. It has been exposed by a few nifty designs, but I guess RAM sizes grew too fast to let room for any serious exploit to generate serious level based applications like with Flash did.

*2 - Not really leak faster, but due their small capacity, the absolute load difference between a secure detection of a load and ambiguity is smaller, thus the time until it's reached is reached faster.

*3 - There is more to it regarding clock generation and timing, but that'll need a lot more space to describe.

*4 - Well, as usual the answer is not as easy when taking about savings, as they are never straight savings (which would mean they were surplus in the first place). In this case adding the two counters would have meant that the adder used for address generation (74283 at position E14) could be saved - but an additional mux would have been needed - so far this comes to a net saving of two IC, but then again this may have needed different glue logic, so the exact number saved is unknown unless we don't know the exact 'other' logic Woz would have used.