[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: How fast is a IIgs?
- Subject: Re: How fast is a IIgs?
- From: toddpw@frappe.ugcs.caltech.edu (Todd P. Whitesel)
- Date: 1995/07/26
- Newsgroups: comp.sys.apple2
- Organization: California Institute of Technology, Pasadena
- References: <3ut7ag$cbm@sun.lclark.edu> <3v0lhg$7nc@news2.delphi.com> <3v36d3$hcg@tuba.cit.cornell.edu>
jmk3@crux4.cit.cornell.edu (Jay Krell) writes:
>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?
>So, code in banks E0 and E1 runs at 1 MHz, right? Those darn vectors...
Any accesses to E0/E1 would be 1 mhz. This includes writes to any shadowed
video buffer in banks 0/1 (reads run at full speed tho).
>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?
It's when both the CPU and the refresher in the FPI try to access the fast
memory at the same time. This happens about 10% of the time when you're
running wholly in fast RAM.
>Do other/all computers behave this way?
Nearly every system with DRAM does, although the performance hit varies.
One benefit of caches was to isolate the CPU from these effects.
>Did the "classic" Apple II's avoid
>it by doing refresh in a different part of the cycle than memory reads?
yes. memory ran at 2 mhz, CPU & Video each at 1 Mhz.
>How 'bout the IIc Plus?
It was like taking a //c (2/1+1) and sticking a 4 mhz Zip Chip on the
motherboard. For 8 bit code it was faster than the stock IIgs.
>Back to the IIgs, is refresh the same on the
>motherboard as in the memory expansion slot?
yes. the FPI controls both of them the same way.
>How 'bout DOC RAM?
The DOC handles that. It's one reason why the Sound GLU has a "busy bit".
Todd Whitesel
toddpw @ ugcs.caltech.edu