Apple II hi-res and DRAM refresh (was RE: TRS-80 Model III)

From: Sellam Ismail <>
Date: Wed Aug 28 13:22:01 2002

On Wed, 28 Aug 2002, Ethan Dicks wrote:

> With my early experience having come from the Commodore world, I admit
> that the hi-res mapping on the Apple ][ struck me as odd, too; but when
> I programming professionally on it, our graphics guru whipped up a fast
> and simple row->address lookup routine and we didn't have to worry about
> it from an application standpoint.

Yes, it adds a few cycles to the plotting of points, and it is quite lame,
but we must look at the history of why it is like this, as Ethan describes

> The "logic" is that the video refresh circuit doubles as a DRAM refresh
> counter. By decoupling the sequential nature of the CPU's view of the
> hi-res page and the video output circuit's view of the same memory, the
> timing lines up and results in a simpler refresh circuit (i.e., you
> don't have to refresh every byte in a DRAM chip, just every row, every
> so often; the mapping is driven by the bit geometry of the 4116 DRAM and
> how many columns there are per row). I forget how many chips Woz saved,
> but I think it was between 1 and 4.

Woz was all about efficiency in design: a true hacker. The hack was very
clever for the day (1977) and saved on chip costs, which were still high
back then. Also, Woz believed that anything that could be done in
software should, and stuck with a minimalist hardware design attitude.

Yes, it's totally lame to those who came up on computers with normal,
sequential graphics screens, but as Ethan mentioned, a simple look-up
table (consisting of $180 bytes) and some convenient 6502 opcodes (load
accumulator indirect indexed) fixes the problem quite nicely and easily.

Sellam Ismail Vintage Computer Festival
International Man of Intrigue and Danger

 * Old computing resources for business and academia at *
Received on Wed Aug 28 2002 - 13:22:01 BST

This archive was generated by hypermail 2.3.0 : Fri Oct 10 2014 - 23:34:37 BST