[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: How fast is a IIgs?



In article <3v36d3$hcg@tuba.cit.cornell.edu>,
Jay Krell <jmk3@crux4.cit.cornell.edu> wrote:
> 
> It's already been stated correctly, but, again, the actual clock speed
> is 2.8 MHz. There's about a 10% speed hit for code running RAM instead of
> ROM, and...I'm fuzzy here, but, like, all accesses to banks E0
> and E1 are at 1 MHz, and shadowed writes, such as for text, video and? I/O?
> to banks 0 and 1 ("IIe emulation memory") are at 1 MHz?

All shadowed video writes are 1 MHz.  Shadowed reads are 2.8 MHz
(minus refresh delays, so 2.5 MHz on average).  All reads or writes in
banks E0 and E1 are 1 MHz.

I/O writes in the C000 space are usually 1 MHz.  There may be
exceptions: the registers in the FPI, particularly the speed and
shadow registers, might be read at 2.8 MHz.

ROM access are 2.8 MHz without delays.

> Is the reason for the 10% RAM hit, like, RAM is constantly being refreshed,
> and when the "point of refresh" intersects the program counter, execution
> (instruction fetch) is stalled briefly while the code is refreshed?

The fast RAM is refreshed continuously by the FPI.  If the CPU
attempts to access fast RAM when a refresh cycle is due, the CPU will
be delayed until the refresh is complete.

According to the IIgs hardware ref manual, refresh cycles occur every
3.5 microseconds (approximately).

Assuming the fast CPU cycle is 10 periods of the master 28 MHz clock,
i.e. 2.863636 MHz, the period is 349.2 ns, and a refresh cycle would
be required after nine CPU cycles, slowing the CPU down by one ninth,
to an effective speed of 2.577 MHz.

If the CPU is accessing ROM, slow RAM or I/O during the refresh cycle,
then it will not be delayed.  Separate busses are used to access
onboard ROM, slow RAM and motherboard/memory card RAM (including
memory card ROM in banks $F0-$FD).

Slow RAM is refreshed automatically by video scanning, so slow memory
accesses are not delayed at all.

> Do other/all computers behave this way?

Yep.  In some cases, different refresh techniques may be used to avoid
slowing down the CPU.  Caching can help quite a bit.  Some smaller
computers use static RAM, which doesn't require refreshing, but is
more expensive and larger than dynamic RAM.

> Did the "classic" Apple II's avoid it by doing refresh in a different
> part of the cycle than memory reads? 

Yep.  Every 1 MHz cycle is divided into a "CPU" phase and a "video"
phase.  The IOU in the IIe/IIc (Mega II/VGC in the IIgs) is
responsible for reading video data.  The video access cycles are
sufficient to perform dynamic RAM refreshing, so it is not necessary
to steal CPU cycles to do the refresh.

> How 'bout the IIc Plus? 

Should be the same as the IIc/IIe/II+.  All memory accesses are at 1
MHz.  The processor and cache controller run at 4 MHz, and must
synchronize with the bus clock to do a normal memory access.  (The
IIc+ basically has a ZIP CHIP built in.)

> Back to the IIgs, is refresh the same on the motherboard as in the
> memory expansion slot?

The FPI refresh cycles refreshes all CPU-addressable dynamic RAM on the
motherboard and in the RAM card (banks $00 to $7F).

> How 'bout DOC RAM? 

It is refreshed by the Ensoniq.  I believe this is the function of the
"reserved" oscillator (number 31), which just cycles around reading 256
locations in sequence.  This is sufficient to refresh the RAM.

Dynamic RAM is refreshed a row or column at a time.  A single access
to a location in the row/column will refresh the entire row/column.  A
64k RAM has a 256x256 or 128x512 arrangement, so accessing 256
consecutive locations is sufficient to refresh the entire RAM.

The IIgs main memory would require more locations to be accessed,
since one megabit RAM chips (20 bits) are used.  Assuming 1024
consecutive locations must be accessed, the entire refresh cycle will
take about 3.5 microseconds times 1024, i.e. 3.6 milliseconds.
Dynamic RAM must be refreshed within about 4 milliseconds (I don't
know the exact figure off-hand).
-- 
David Empson
dempson@actrix.gen.nz
Snail mail: P.O. Box 27-103, Wellington, New Zealand