Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!uwm.edu!spool.mu.edu!news.cs.indiana.edu!rutgers!tut.cis.ohio-state.edu!ucbvax!agate!darkstar!ucscb.UCSC.EDU!unknown
From: unknown@ucscb.UCSC.EDU (The Unknown User)
Newsgroups: comp.sys.apple2
Subject: Re: speed loss
Message-ID: <14792@darkstar.ucsc.edu>
Date: 21 Apr 91 05:59:40 GMT
References: <9104181535.AA28525@apple.com> <1991Apr20.080839.27678@ux1.cso.uiuc.edu>
Sender: usenet@darkstar.ucsc.edu
Organization: University of California, Santa Cruz; Open Access Computing
Lines: 29


In article <1991Apr20.080839.27678@ux1.cso.uiuc.edu> stuckey@ux1.cso.uiuc.edu (Anthony J. Stuckey) writes:
>THROOP@GRIN1.BITNET ("Throop,Henry B") writes:
>>Do other computers (Mac, IBM, for example) also suspend the CPU occasionally
>>to refresh the DRAMs, or do they have a seperate coprocessor or something
>yes, they do.  this is an inherent problem of all computers.  there is 
>no way that i can fathom (but then, i'm a cs, not ce major) to coprocess

	It seems to me that, on the RAM card, you could simply have 
some relatively simple circuitry to refresh the RAM automagically without
having to suspend the CPU -as much- or at all.

	Seems like a counter and a clock would be the main components.
The counter to count through the possible RAM location values on the card, 
and the clock to determine how long between refreshes. Since apparently
a whole "row" of RAM addresses are refreshed at once, you don't have to 
read each location, just the first on each row.

	The only times this would present a conflict would be when 
you ask for a memory location WHILE the circuitry is refreshing.

	Yes, I guess it is making the CPU wait, but it seems that it would
make less of a speed loss than it does now.

	I've not worked with DRAMs in any of my hardware classes, so
please tell me where I'm wrong and if any of this is viable at all.
-- 
/unknown@ucscb.ucsc.edu Apple IIGS Forever! WANT ULTIMA VI //e or GS?-mail me.\
\CHEAP CDs info-mail me. McIntosh Junior:  The Power to Crush the Other Kids. /