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: <1991Apr18.174840.14313@nntp-server.caltech.edu>
Date: 18 Apr 91 17:48:40 GMT
References: <9104181535.AA28525@apple.com>
Organization: California Institute of Technology, Pasadena
Lines: 31

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
>like that to do it?  While the issue of the 'actual' speed of the gs has come
>up many times, I've not heard people arguing about whether the original PC
>was 4.77, or something slightly less.

Any system using DRAMs MUST spend some time refreshing them. Well designed
memory systems attempt to hide the delay from the rest of the system by
arranging things so that refresh occurs while the system is doing something
else (and the memory would be otherwise left unused). Apple ]['s
have always done this when running at 1 mhz, because the video accessed
the RAM during the other half of each CPU cycle. If you ever wondered
why the video memory maps were so screwed up, it was so the video circuitry
could take care of the refresh automatically (sperate refresh chips were
expensive back then and there wasn't much board space anyway).

The GS' FPI, however, does a really lame job of it when running at 2.8 mhz;
the corresponding %10 hit is big enough to make a difference. It doesn't have
to be that high of course but the original FPI was a medium to large wire-
wrap board filled with TTL...

>Does this have anything to do with why IBM systems use 9 RAM chips (for
>parity checking?) where 8 do in the gs?

Nope. Parity is totally seperate from refresh (unless faulty refresh is
allowing memory loss so the parity checker goes off).

Todd Whitesel
toddpw @ tybalt.caltech.edu