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.
- 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
- 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
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:
- Put the desired address on address bus.
- Configure your DRAM address logic to send the lower order bits of
the address bus to the DRAM chips' address lines.
- Assert RAS for all of the DRAM the chips, and then wait a bit for
them to read those lower-order bits.
- Reconfigure your DRAM address logic now to send the higher order
bits of the address bus to the DRAM chips' address lines.
- 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.
- 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.
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,
- $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
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.