[comp.sys.apple2] speed loss

u9050728@cs.uow.edu.au (Shane Kelvin Richards) (04/16/91)

	Its interesting to note that the Apple //GS Hardware reference says
that although the mhz of the GS is 2.8, it actually is only about 2.5
apparently to service all the other things going on. I wonder what the .3
mhz is being used for?

-- 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Shane Richards
u9050728@cs.uow.edu.au
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-

toddpw@nntp-server.caltech.edu (Todd P. Whitesel) (04/16/91)

u9050728@cs.uow.edu.au (Shane Kelvin Richards) writes:

>	Its interesting to note that the Apple //GS Hardware reference says
>that although the mhz of the GS is 2.8, it actually is only about 2.5
>apparently to service all the other things going on. I wonder what the .3
>mhz is being used for?

DRAM refresh. The reason why DRAMs are so cheap is that they aren't really
memories -- if you just give them power but do nothing else they will
forget everything after ten milliseconds or so (most DRAMs are spec'd to
retain for at least 6 or 8 ms). In order to make them remember, you have to
tweak them every so often so that each row of cells in the square array
on the chip gets accessed at least once every 6 or 8 ms (or whatever the
retention spec is). This is done regularly as you access the memory, but
only to the rows you're actually using -- you have to make sure the others
get refreshed too and that takes an overhead bite out of the memory system.

Whenever the GS is in fast mode, the CPU is suspended every 10th cycle and
a refresh is performed. That's where the other .3 mhz goes. The actual
numbers are

	14.31818 mhz / 5 cycles = 2.863636 mhz maximum

	2.863636 mhz * 90% used by CPU = 2.57727 mhz average

if no accesses to the slow side of the machine are made. Then things
get really bizarre, and Apple hasn't really documented them (I think
they're ashamed to describe how truly brain-dead the original FPI refresh
circuit was).

Todd Whitesel
toddpw @ tybalt.caltech.edu

THROOP@GRIN1.BITNET ("Throop,Henry B") (04/18/91)

[toddpw writes about RAM refreshing]

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.

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

Henry
--
Henry Throop
THROOP@GRIN1.BITNET
throoph@jacobs.cs.orst.edu

toddpw@nntp-server.caltech.edu (Todd P. Whitesel) (04/19/91)

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

unknown@ucscb.UCSC.EDU (The Unknown User) (04/19/91)

In article <9104181535.AA28525@apple.com> THROOP@GRIN1.BITNET ("Throop,Henry B") writes:
>[toddpw writes about RAM refreshing]
>
>Does this have anything to do with why IBM systems use 9 RAM chips (for
>parity checking?) where 8 do in the gs?

	No.. The hardware parity checking seems to me like a hell of
a big waste of dinero/moolah/cash/money...

	It has nothing to do with RAM refreshing.. As you said, it's parity
checking.. 
	I don't know whether they work on odd or even parity, but the
extra bit is set so that there are an odd (or even) number of ones 
in the whole 9 bits.. The parity bit will show if there is ONE bit 
error in the byte, but I believe it tells absolutely nothing about where
the error is, like some other checks..	
-- 
/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. /

alles@buster.cps.msu.edu (Jeff Alles) (04/20/91)

In article <9104181535.AA28525@apple.com> 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? 

Other computers definitely have to pause to refresh their RAM.  They are
designed with this factor in mind with a preset refresh interval.  In fact,
I have a program for IBM PC compatables which will change the delay
which is used, to a larger value.  This reduces the ammount of time spent
refreshing the RAM.  However, if the delay is set too long, the computer
starts to bug out as the bits start to fade.  Using this program, an
increase of 5-10% is possible on most machines.

Jeff Alles
alles@cps.msu.edu

stuckey@ux1.cso.uiuc.edu (Anthony J. Stuckey) (04/20/91)

THROOP@GRIN1.BITNET ("Throop,Henry B") writes:

>[toddpw writes about RAM refreshing]

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

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
this.  One thing that I have noticed is that there are _many_ utilities
for DOS machines to allow you to lengthen the period before refresh (the
manufacturer's specifications are somewhat conservative)  but I have never
seen such a thing for _any_ other machine.  (mac, amiga, II, whatever)
whyfer so??

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

nope.  not at all.  that's just a design decision.  parity ram allows
you to detect memory errors (from cosmic rays, or other sources).
-- 
Anthony J. Stuckey
stuckey@ux1.cso.uiuc.edu

gwyn@smoke.brl.mil (Doug Gwyn) (04/21/91)

In article <9104181535.AA28525@apple.com> 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?

There are all sorts of hardware implementation techniques.  Most "real"
computers don't let memory refresh interfere with ALU operation except
in very rare circumstances when an uncached memory location is needed
for an operation at at that very instant it is being refreshed.

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

No, the parity bit is for error detection; it has nothing to do with
memory refresh speed etc.

unknown@ucscb.UCSC.EDU (The Unknown User) (04/21/91)

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

toddpw@nntp-server.caltech.edu (Todd P. Whitesel) (04/21/91)

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

sb@pnet91.cts.com (Stephen Brown) (04/22/91)

toddpw@nntp-server.caltech.edu (Todd P. Whitesel) writes:
>

[on dotted line, cut.........................]

>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

I have never heard of "cya", just FPI. What does CYA stand for, what are the
differences between it and the FPI? Any other info will not satiate my
curiousity, but it will be appreciated nevertheless... :)


+---------------------------------------------------------+
| Stephen Brown                           Toronto, Canada |
| Internet: sb@pnet91.cts.com      UUCP: utzoo!pnet91!sb  |
+---------------------------------------------------------+
| Apple II Forever !!!                                    |
+---------------------------------------------------------+
| Like my new .signature. ?    Too bad.                   |
+---------------------------------------------------------+

toddpw@nntp-server.caltech.edu (Todd P. Whitesel) (04/23/91)

sb@pnet91.cts.com (Stephen Brown) writes:

>I have never heard of "cya", just FPI. What does CYA stand for, what are the
>differences between it and the FPI? Any other info will not satiate my
>curiousity, but it will be appreciated nevertheless... :)

CYA? Cover Your A**.

The differences are documented in the hardware ref 2nd edition, the only
notable stuff was hardware shadowing for text page 2 and a real powered-up
bit that you can read to see if the machine really has just been turned on.

They didn't bother to fix the brain dead refresh timing or the DMA bank
problem (Apple now uses 65816's which are fast enough to allow the FPI/CYA
to spit out the DMA bank on a DMA access without a bus fight). Maybe there
were other reasons but I don't know what they'd be (except no budget, which
I could understand).

Todd Whitesel
toddpw @ tybalt.caltech.edu

alfter@nevada.edu (SCOTT ALFTER) (04/24/91)

In article <1991Apr20.080839.27678@ux1.cso.uiuc.edu> stuckey@ux1.cso.uiuc.edu (Anthony J. Stuckey) writes:
>this.  One thing that I have noticed is that there are _many_ utilities
>for DOS machines to allow you to lengthen the period before refresh (the
>manufacturer's specifications are somewhat conservative)  but I have never
>seen such a thing for _any_ other machine.  (mac, amiga, II, whatever)

I can't speak for other systems, but the Apple II has no need for
these utilities since processor time isn't eaten up for memory
refresh.  Refresh is handled by the video circuitry; processor and
video accesses to RAM are interleaved.  There is no way the 65(C)02 in
an Apple II can access memory at the same time it's being refreshed.

(This is what I can figure out from the IIe tech reference.  Older IIs
may have been designed differently.  The IIGS was probably designed
differently as well; I think someone said that GSes take a speed hit
when you plug in hella memory.)

Scott Alfter-----------------------------_/_----------------------------
Support Operation Apple Storm!          / v \ Apple II:
Internet: alfter@uns-helios.nevada.edu (    ( the power to be your best!
   GEnie: S.ALFTER                      \_^_/

rhyde@musial.ucr.edu (randy hyde) (04/24/91)

>>>>>
I can't speak for other systems, but the Apple II doesn't need these
utilities since processor time isn't eaten up for memory refresh.
<<<<<

True, but the Apple II (this does not apply to the GS) only runs at 1
Mhz and needs memory which is twice as fast as the processor.  The
refresh (and video display) use the memory half the time and the
processor the other half.  This worked fine in the days when memory was
twice as fast as the processor.  Today, the reverse is true.  Indeed,
processors are many times faster than cheap memory.
A 17 Mhz 65816 requires outrageously fast RAM.  To get the invisible
refresh it would need twice as outrageously fast RAM (something like
5ns).  Since no one can afford a large stockpile of this stuff, I feel
the *small* percentage of overhead required for refresh is reasonable. 
BTW, as processors get faster, the percentage of overhead associated
with refresh goes down (of course, memory has to get faster too...).

toddpw@nntp-server.caltech.edu (Todd P. Whitesel) (04/25/91)

rhyde@musial.ucr.edu (randy hyde) writes:

>A 17 Mhz 65816 requires outrageously fast RAM.  To get the invisible
>refresh it would need twice as outrageously fast RAM (something like
>5ns).  Since no one can afford a large stockpile of this stuff, I feel
>the *small* percentage of overhead required for refresh is reasonable. 
>BTW, as processors get faster, the percentage of overhead associated
>with refresh goes down (of course, memory has to get faster too...).

Come on, Randy, nobody's going to try to run a high speed 65816 directly
off of DRAMs. Cache SRAMs only need to be about 20-25 ns and those are
far more reasonable. A Zip GSX at 10 mhz with a WDC part only needs 55 ns
SRAMs, and the cache hit detect takes 10 ns, so a 20 mhz chip should be
able to get by with 20 (maybe 25) ns cache RAM. I can order those from
Newark -- my roommate chucked our last year's catalog so I don't have any
prices to quote right now. Last I remember 16K was about $20 so now a good
sized cache could probably be had for a few hundred.

Todd Whitesel
toddpw @ tybalt.caltech.edu

rhyde@feller.ucr.edu (randy hyde) (04/27/91)

>> Cmon,... no one's going to run a 17 Mhz 65816 off drams...

That's for sure!  I never claimed they would try.  I was just explaining why
losing cycles to refresh is a fact of life on chips faster than the original
1 Mhz 6502 in the Apple II.  Wait states (even with a big cache) are a bigger
problem with 17Mhz 65816 chips than refresh cycles.