Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!rutgers!mit-eddie!genrad!decvax!ucbvax!amdcad!phil
From: phil@amdcad.AMD.COM (Phil Ngai)
Newsgroups: comp.arch,comp.sys.m68k
Subject: Re: 68020 speeds and wait states
Message-ID: <16750@amdcad.AMD.COM>
Date: Thu, 21-May-87 12:20:15 EDT
Article-I.D.: amdcad.16750
Posted: Thu May 21 12:20:15 1987
Date-Received: Sat, 23-May-87 11:43:19 EDT
References: <5635@shemp.UCLA.EDU> <1774@im4u.UUCP>
Reply-To: phil@amdcad.UUCP (Phil Ngai)
Organization: Advanced Micro Devices, Inc., Sunnyvale, Ca.
Lines: 25
Xref: mnetor comp.arch:1377 comp.sys.m68k:495

In article <494@haddock.UUCP> wolfgang@haddock.ISC.COM.UUCP (Wolfgang Rupprecht) writes:
>The pin police will have a good laugh though, if they see you
>refreshing your drams by strobing 2**n SEQUENTIAL addresses
>when some of them *don't* go to row-addresses! 

Doesn't everyone know about CAS-before-RAS refresh? DRAMs these days
have refresh counters built into them so you don't have to supply a
refresh address. DRAMs these days are wonderously complicated and
getting more so continually. 

What you do in the privacy of your own chip address-wise is no
business of the pin police. 

>The cheapest way (hardware-wise) to refresh drams is to have a strip
>of nops (ie 256 bytes of 'em) that the cpu executes once per refresh
>time. This is usually just as fast as some hardware counter doing the
>same thing.

Yes, but when your software crashs, the contents of core evaporate. I
always believe in hardware controlled refresh. It's not that
expensive.  A refresh counter and a few extra states in the RAM
controller. 

-- 
Phil Ngai, {ucbvax,decwrl,allegra}!amdcad!phil or amdcad!phil@decwrl.dec.com