Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!apple!rutgers!cbmvax!daveh
From: daveh@cbmvax.commodore.com (Dave Haynie)
Newsgroups: comp.sys.amiga.tech
Subject: Re: Static vs. static column vs. dynamic vs. ???
Message-ID: <15763@cbmvax.commodore.com>
Date: 9 Nov 90 17:54:24 GMT
References: <15571@brahms.udel.edu> <1990Nov08.222823.1925@hoss.unl.edu> <1990Nov9.005423.13745@jarvis.csri.toronto.edu>
Reply-To: daveh@cbmvax.commodore.com (Dave Haynie)
Distribution: na
Organization: Commodore, West Chester, PA
Lines: 51

In article <1990Nov9.005423.13745@jarvis.csri.toronto.edu> leblanc@eecg.toronto.edu (Marcel LeBlanc) writes:
>252u3130@fergvax.unl.edu (Phil Dietz) writes:

>>Well, everything takes time.  It may only take nanoseconds to refresh
>>the RAM, but it is ALWAYS refreshing the RAM.  The time slowly but
>>surely adds.....

>But in a good design, refresh amounts to very little time.  

Yup.  Modern DRAM, regardless of density or speed, needs one refresh cycle 
about every 15.6 microseconds.  This amounts to roughly a 1% speed penalty
if every refresh cycle contends with a desired memory cycle.  In reality,
though, the conflict is far less than that.  On the Amiga's chip bus, DRAM
refresh is just another couple chip type DMA slots, in there like floppy 
and sound fetch are; there's no slowdown or contention, ever.  On most Zorro
II memory cards, there's enough time with even 150ns to run a refresh
cycle and a memory cycle for every 68000 bus cycle.  On more modern designs
like the 3000, the CPU is significantly faster than the memory, so refresh
can only happen when necessary.  In the even of a tie between a refresh
request and a processor memory request, the processor goes first, then the
refresh immediately after.  

Some memory controllers get real sophisticated and try to sneak in refreshes, 
or count incidental refreshes.  For instance, any time you read a memory
location, the whole row for that location is automagically refreshed.  So if
you have all memory getting the RAS* signal, and keep track of those rows
addressed during a refresh period, only those not addressed need to be
considered.  This could be done even in the A3000, but it has some 
disadvantages as well, such as being memory architecture sensitive.  The
A3000's memory refresh logic will work with any current and very likely any
future DRAM, regardless of size.

>The only way ROM is going to be less expensive than RAM is if you have huge
>volumes!  I know I won't get a direct answer from Commodore, but can the
>volume numbers for the A3000 possibly justify this?  Like I said, I still
>don't believe this.

You really don't need such huge volumes.  Let's see, 512K of DRAM is four
256K x 4 DRAMs.  Even at current prices, I think ROM is still 1/2 to 1/4
the price.  Even EPROM, which has been dropping in price, is getting
competitive (in fact, the EPROM people have tried to convince us there's
no need for maked ROMs anymore, but even a dollar or two in price 
difference can make a difference over the long run).

>Marcel A. LeBlanc  --  Electrical Eng. Computer Group, Univ. of Toronto


-- 
Dave Haynie Commodore-Amiga (Amiga 3000) "The Crew That Never Rests"
   {uunet|pyramid|rutgers}!cbmvax!daveh      PLINK: hazy     BIX: hazy
	Standing on the shoulders of giants leaves me cold	-REM