Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!seismo!rutgers!ucla-cs!zen!ucbvax!COGSCI.BERKELEY.EDU!bryce
From: bryce@COGSCI.BERKELEY.EDU (Bryce Nesbitt)
Newsgroups: comp.sys.amiga
Subject: Re: 14.31818 MHz 68010 Upgrade
Message-ID: <8708111710.AA12671@cogsci.berkeley.edu>
Date: Tue, 11-Aug-87 13:10:47 EDT
Article-I.D.: cogsci.8708111710.AA12671
Posted: Tue Aug 11 13:10:47 1987
Date-Received: Thu, 13-Aug-87 04:03:48 EDT
References: <19965@ucbvax.BERKELEY.EDU> <204@dana.UUCP>
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: Institute of Cognitive Studies, UC Berkeley
Lines: 57

>In the marjority of cases it is better
>to blow alternate cyccles for hidden refresh than to use a contention
>refresh scheme that causes wait states...

There is another option which allows a system to achieve near zero refresh
wait-states without "resorting" to hidden refresh.  It's only practical
if you are building your own refresh controller from scratch.  It involves
a refresh count down timer that has multiple taps, the first tap is 
"refresh_request" the second is "refresh_demand".  When request is active
the controller will refresh the RAM whenever any *other* bank or area of
memory is accessed, or when there is an idle slot.  "demand" does the obvious
and takes the refresh no matter what.

Any design is simpler if you have CAS before RAS dram chips...

This can be enhanced by always designing boards with at least two banks of
memory, and setting them up at alternate machine-word addresses.  A 
sequential read of memory by the processor would result in a free refresh
slot on alternate banks, every cycle.

You can simplify your design at the expense of hiking your power use
by resetting a counter and refreshing at *every* free slot.  If the counter
ever runs down then you "demand" a refresh cycle.

If you use this idea, be sure to inscribe credit "in copper" near the proper
section of your circuit board.  1/2 :-)

-----------
I first learned of the hidden refresh concept with relation to a memory
board that only took a hidden cycle after a processor cycle on it's ram.
So far so good.  If the processor spent any meaningful time accessing
some *other* ram then *this* ram would start to forget... forg... fo... f.

BTW1: Dynamic ram can take a *long* time to decay.  On the order of multiple
seconds.  Not that this information is of any use -> I'm sure a refresh
system built on this as fact would be quite doomed.

BTW2: Making OpticRAMs by taking the top off ceramic DIPs works!  Your
software refreshes a row, then reads it later to see if it decayed to zero
(due to light).  Use multiple cycles with different times for gray scale
calculation.  I had a lot of fun with this-> but I never go byond using a
paper mask to create test images.  I didn't and don't have a lens set up of
any type.
(Hand grining lenses... yeah that's the ticket. :-)


>George Robbins - now working for,	uucp: {ihnp4|seismo|rutgers}!cbmvax!grr

Would the A2000 memory boards properly hold off a processor that tried to
take a read cycle at the end of its hidden refresh, or would that tend to cause
problems?


|\ /|  . Ack! (NAK, EOT, SOH)
{o O} . 
( " )	bryce@cogsci.berkeley.EDU -or- ucbvax!cogsci!bryce
  U	"Success leads to stagnation; stagnation leads to failure."