Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!bloom-beacon!mit-eddie!killer!jockc
From: jockc@killer.Dallas.TX.US (Jock Cooper)
Newsgroups: comp.sys.apple
Subject: Slow SHR (was: Re: GS specific programs)
Summary: why slow down SHR?
Message-ID: <7552@killer.Dallas.TX.US>
Date: 15 Mar 89 17:19:43 GMT
References: <8903111538.AA24748@crash.cts.com> <913@n8emr.UUCP> <1300@wpi.wpi.edu> <921@n8emr.UUCP>
Reply-To: jockc@killer.Dallas.TX.US (Jock Cooper)
Organization: The Unix(R) Connection BBS, Dallas, Tx
Lines: 25

In article <921@n8emr.UUCP> lwv@n8emr.UUCP (Larry W. Virden) writes:
>In article <1300@wpi.wpi.edu> dseah@wpi.wpi.edu (David I Seah) writes:
>>Larry, the Apple IIGS graphics screens reside in "slow RAM".  The memory
>>devices involved can read/write data at the old 1Mhz speed of the Apple II+. 
>>So, everytime you try to put something on the screen, the 65816 gets slowed
>>down from 2.8MHz (assumption) to 1Mhz during those write cycles to the video
>>buffer.  The IIGS super hires video buffer is also 32K in size, 4x the size of
>>the Apple II hires screen buffer.  On the 1Mhz Apple II+, we couldn't display
>
>Hey Apple, here is an idea - is there a way to NOT slow down is accessing the
>SHR buffer but slowing down if accessing the HR or DHR buffer?  That way,
>Apple II[e|c] mode programs get what THEY want and GS owners get what THEY
>want!

This is something about the GS that has always baffled me.  Sure, it makes 
sense to have the //e graphics RAM areas in slow RAM... But why put the 
SHR page there?  No //e program is ever going to try to access it!
Why hard code the location of the SHR page in the first place?  
A software pointer (to the SHR area) that the video circuitry could
read to find the graphics data would have been nice. Of course, that would 
have made the graphics a lot faster, and we don't want the GS to run too fast 
now, do we? Give me a break, Apple.

Jock Cooper
HCA Information Services                           uucp: inhp4!killer!jockc