AWCTTYPA@UIAMVS.BITNET ("David A. Lyons") (01/10/89)
>Date: Sun, 8 Jan 89 18:41:32 GMT >From: Richard Sherman Payne <portal!cup.portal.com!-Rich-@UUNET.UU.NET> >Subject: Apple //gs access speed. >[...] Does the //gs, in GS/OS, access the 3.5" drives at 1MHZ or at >2.8 MHZ, through the smartport. My understanding was that all access >to the lower 64K were at 1MHZ. And that the drives were accessed >through the lower 64K. I thought that the increased speed of GS/OS >was the result of the 16 bit processor working more efficiently than >the 8 bit (P16 v1.3) at the same speed. Dave Lyons, are you >listening? I'm always listening, except when I'm not :-) Yes, access to drive hardware control addresses (through $00C0xx, $01C0xx, $E0C0xx, or $E1C0xx) happen at 1MHz. But the slowdown only affects the instruction accessing the hadware, and there's a lot of other stuff involved in reading/writing a disk! (I _don't_ think the bit is set that would cause the clock to _stay_ at 1MHz when the slot 5 drive motor is on, although the bit for slot 6 normally is.) ProDOS 16 was also running at high speed most of the time, but it was doing some useless copying of most of the data read from disk, because of the way it was built _around_ ProDOS 8 inside [P16 would actually make ProDOS 8 calls to read data into bank 0, and then P16 would copy the data where it needed to go]. GS/OS eliminates this extra work [at _least_ in the case where a special device driver is available; devices with no special drivers still need to read blocks into bank 0 if only the ProDOS init/status/read/write protocol is available on the card]. With less time taken to process a block of data just read, GS/OS can handle a more efficient "interleave" factor on disk in the Apple 3.5 drive--instead of spreading the blocks out so that FOUR revolutions of the disk are needed to read a whole track one block at a time (an interleave of 4:1), GS/OS can read it in just two revolutions (an interleave of 2:1). GS/OS has other speed improvements, too--for example, up to 32K worth of directory blocks are "cached" so they don't have to be read from disk when they're needed again [even if you use the Disk Cache NDA to set the cache size to 0]. Setting the cache to something nonzero helps only if you have applications that specifically ask GS/OS to cache parts of files as they are read; I don't have a list of applications that do this. > Rich > -Rich-@cup.portal.com --David A. Lyons bitnet: awcttypa@uiamvs DAL Systems CompuServe: 72177,3233 P.O. Box 287 GEnie mail: D.LYONS2 North Liberty, IA 52317 AppleLinkPE: Dave Lyons