Xref: utzoo comp.sys.apple:23761 comp.sys.apple2:278 Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!wuarchive!zaphod.mps.ohio-state.edu!think!husc6!m2c!wpi!dseah From: dseah@wpi.wpi.edu (David I Seah) Newsgroups: comp.sys.apple,comp.sys.apple2 Subject: Re: Interleaves, was: Fast reading of floppies... Message-ID: <9891@wpi.wpi.edu> Date: 20 Mar 90 04:26:37 GMT References: <1990Mar15.142012.15985@spectre.ccsf.caltech.edu> <13979@nigel.udel.EDU> Reply-To: dseah@wpi.wpi.edu (David I Seah) Organization: Worcester Polytechnic Institute, Worcester ,MA Lines: 59 In article cs4w+@andrew.cmu.edu (Charles William Swiger) writes: [excellent intro to Disk Interleaving deleted] >Note that if you read the sectors backwards, its faster by a factor of >about four. This trick has been used by a lot of "fast" DOSes like >HyperDOS and others to speed up disk access without rearranging the >physical sector interleave. ProDOS also uses this trick, but through >another layer of indirection. ProDOS reads the disk by 512 byte blocks: >2 sectors per block, 8 blocks per track. ProDOS improved performance by doing away with multi-buffering too. The 5.25" driver for ProDOS 8 actually decodes the raw 6 bit disk bytes into 8 bit bytes on the fly by using some really enlightening lookup table techniques and self modifying code. There are 64 "legal" bit patterns (there were also a couple extra ones) you can write on a 5.25" drive, which corresponds to a 6 bit logical disk byte. Hence, three 8 bit data bytes in your buffer had to be translated into 4 disk bytes. (6 & 2 encoding). Old DOS 3.3 had to copy the 342 disk bytes into a buffer, then use shift operations to translate this raw stuff into 256 8 bit bytes, then move the data out to your personal data buffer. ProDOS is able to do all these steps on-the-fly during the time critical read cycle...wow! Disassembling this code and understanding it was almost a religious moment in my wasted high school career :-) >Locksmith and Copy //+ do not read the disk in logical sector order, as >has been pointed out. Instead, they read the sectors as fast as >possible and then decode the order the sectors were actually read into >the logical order. There used to be a disk copier called Disk Muncher that just read in the raw data without decoding it, then writing the stuff back out directly. It was real fast, but somewhat unreliable. There was also an ancient copy program that did something similar to scatter read (I think). It read the first sector it came across on the track, and checked to see if it had been read or not. If it hadn't, it would read it and go until all sectors were read. It was marginally faster than COPYA. >Apple's 3.5 inch drives have different numbers of sectors per track to >take advantage of the greater length available on the outer tracks of >the disk. They change the disk rotation rate to retain constant linear >velocity for whatever track they're on (in other words, the physical >spacing between bits on the disk is constant, even through the outer >tracks would rotate faster than the inner ones if the drive speed were >held constant). I've always wondered if the 3.5" is really continuously variable. When you listen to the mechanism format a disk, it seems like the drive produces 5 or 6 different motor hums...is the drive capable of only 5 or 6 different discrete speeds? Continuosly variable seems to be like overkill. > -- Charles William Swiger > -- Dave Seah | O M N I D Y N E S Y S T E M S - M | Internet: dseah@wpi.wpi.edu | User Friendly Killing Machines | America Online: AFC DaveS .............................................................................. // Infinitum! // Infinitum! // Infinitum! // Infinitum! // Inifinitum!