Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!jarthur!nntp-server.caltech.edu!toddpw
From: toddpw@nntp-server.caltech.edu (Todd P. Whitesel)
Newsgroups: comp.sys.apple2
Subject: Re: speed loss
Message-ID: <1991Apr21.102552.17717@nntp-server.caltech.edu>
Date: 21 Apr 91 10:25:52 GMT
References: <9104181535.AA28525@apple.com> <1991Apr20.080839.27678@ux1.cso.uiuc.edu> <14792@darkstar.ucsc.edu>
Organization: California Institute of Technology, Pasadena
Lines: 33

unknown@ucscb.UCSC.EDU (The Unknown User) writes:

>	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.

That's how standard slot RAM cards work. The GS Memory Expansion slot
is exactly what its name implies. There are pins dedicated to DRAM control
signals like RAS and CAS, and refresh is controlled by the FPI on the
motherboard. It is the lameness in the FPI that is causing the problems.
(The FPI could be stealing refreshes when the CPU is doing internal
operations -- but Noooaaaoooo...)

>	Seems like a counter and a clock would be the main components.

The counter is in the chips themselves (all DRAM's in the GS memory slot
must support CAS before RAS refresh) and the clock is in the FPI.

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

This is what the FPI _SHOULD_ do, but doesn't. I was hoping the ROM 03
(which has a 'CYA' chip instead of the FPI) would fix this but it
probably doesn't. I still wish the motherboard would use latch-on-write
to deal with the 1 mhz bus (instant graphics speedup), but the AppleTalk
code would die a horrible death unless a couple of MSI were added to the
SCC circuit, or the AppleTalk driver were to be slightly modified to make
it accelerator friendly...

Todd Whitesel
toddpw @ tybalt.caltech.edu

P.S. Isn't Orca/Disassembler the neatest thing? heh heh