Jonathan Bromley wrote:
(snip)

> Yes, and it's a completely ridiculous way to do it. The
> added cost of making frequent additional row accesses is
> far greater than the cost of the necessary refresh.

Processor speed has increased somewhat faster than DRAM speed.

> A DRAM row is effectively a cache. When you access a row,
> you read the whole row into the DRAM's row buffer as a free
> side-effect, and can then make very fast column accesses
> to anly location in the row. It's preposterous to throw
> away that massive free bandwidth just to save yourself
> some refresh effort - unless you're trying to design
> a $80 home computer/toy in the early 1980s.

When RAM cycle time was faster than processor cycle time.

> In those days, the video buffer was a sufficiently
> large fraction of the overall DRAM that it was
> reasonable to lay out the video memory so that
> every row was automatically visited by the video
> scan, giving a refresh cycle every 20ms (16.7ms
> in the USA). That was out-of-spec for many DRAMs
> of the day (8ms refresh cycle) but in practice it
> worked in almost all cases - and the manufacturers
> of those computers had a shoddy enough warranty
> policy that they weren't going to worry about a
> handful of customers complaining about occasional
> mysterious memory corruption on a hot day.

Any access to the row will refresh the whole row.
If you address it such that sequential characters are
in different rows then it is refreshed much faster than
the frame rate.

-- glen