cs4w+@andrew.cmu.edu (Charles William Swiger) (03/16/90)
For those of you who have been wondering about disk interleaves, etc:
Imagine the logical sectors written out on disk directly, one after the
other, as physical sectors (1 to 1 interleave):
logical: 0123456789ABCDEF
physical: 0123456789ABCDEF
The problem with doing this for Apple drives is that by the time you are
ready to ready the next sector, the disk head has already moved past it.
(for 5.25 disks the head's several sectors ahead (it may vary a little
by drive type), for the UniDisk the head's 2 to 3 sectors past, for the
Apple 3.5 drive, it's only 1 sector ahead.) If you want to read the next
logical sector, you would have to wait until the disk rotates all the
way around, ie. another 17 sectors, which would be very slow. Instead,
you make the physical sector layout different from the logical sector
order, in order to read from the disk faster.
For the 5.25 disks, Apple first used a 8 to 1 interleave, like this (I
don't have the manual with me, but this is fairly close, anyway):
logical: 0123456789ABCDEF
physical: 07E5C3A18F6D4B29
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. However, block 0 is >not<
physical sectors 0 and 1, but physical sectors 0 and C (I think.
Again, without the manuals, I can't be certain of my memory. The idea
behind it is correct, even if the specific details are wrong.) This
means ProDOS can read a track several times faster than normal DOS 3.3
could, because it uses a smaller/different/better sector interleave.
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.
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). They are also double-sided. For the sake of simplicity
(read that as "for the sake of not confusing MYSELF"), ignore all of the
complications, and treat them as having 16 sectors per track.
UniDisk 3.5 drives would use a 4 to 1 interleave, like this:
logical: 0123456789ABCDEF
physical: 048C159D26AE37BF
And Apple 3.5 drives can use a 2 to 1 interleave, even though the older
formatting utilities format them to 4 to1, as with the UniDisk above:
logical: 0123456789ABCDEF
physical: 08192A3B4C5D6E7F
For computers that can keep up with the 2 to 1 interleave (ie the //gs,
Transwarped / Zip-chipped / otherwise-accelerated 8-bit //'s) the Apple
drive is the fastest 3.5 drive available. If the computer CAN'T keep
up, the disk will have to rotate about 18 sectors to read the next
logical track, thus slowing the drive down by a factor of 9. (Ver'
bad, indeed, mon ;-)
Note that the Apple 3.5 drive is still faster than the UniDisk, even for
//gs' running GS/OS 5.0.2. I forget what the exact timings were, but a
disk formatted with a 2 to 1 interleave on an Apple 3.5 drive was
roughly 60% faster doing sequential reads than a disk formatted to 4 to
1 interleave on the same Apple 3.5 drive (like a UniDisk would be).
Also note that doing disk caching (referred to previously as "buffering
tracks") does not improve speed the first time a sector is read, but
would cause all subsequent reads to have equal (and much faster: memory
access beats reading from the disk hands down) speed regardless of the
disk drive.
Hope this helps anyone who was confused,
-- Charles William Swiger
cs4w+@andrew.cmu.edu <-- use this one first
when sending me mail, please
cs4w+@drycas.club.cc.cmu.edu
y614cs4w+@vb.cc.cmu.edu
"Ya gotta love CMUs' cryptic userids, because no one else does."dseah@wpi.wpi.edu (David I Seah) (03/20/90)
In article <Aa0558y00WABE1PUpM@andrew.cmu.edu> 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!
joseph@elbereth.rutgers.edu (Seymour Joseph) (03/21/90)
The 3.5" drive is not quite continuously variable, but there are a lot more speeds available than are actually used. I used to have a Sony disk diagnostic program for the mac that allowed me to set the drive speed to anything between 0 and 255. It would actually spin the disk at different speeds. I think you are correct though that Apple only uses a few speeds for it's normal disk formats. Seymour
cs4w+@andrew.cmu.edu (Charles William Swiger) (03/24/90)
Quotes are from Dave Seah: "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." Disk Muncher is still useful. It copies Infocom games flawlessly, without any parameter changes, and without using the one-track-at-a-time bit copier of Copy //+ (major time-saving tip here). As for it being unreliable, I don't remember it producing many bad copies. "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? Continuously variable seems to be like overkill." The drive motor wouldn't have to be continuously variable, it would just have to be able to rotate at 80 different speeds. And yes, that definitely would be overkill (explanation below). However, my article was intended to be a non-technical introduction to interleaves, so I generalized a bit, and ignored the specific details (and I said I was doing so!! ;-). The general idea was that the drive changed speeds on the outer tracks in order to take advantage of the greater length available, thus being able to store more information of the disk then if the drive rotated at a constant speed. There's a reason why the drive only changes speed a couple of times. It would be pointless to change the drive speed if you can't fit another block onto the track (that's the reason for changing the speed, remember?) You'd only make the sync fields a little larger. So it's no surprise that the drive speed only changes when you actually can fit another block on the track (which means you only change speed a couple of times, as you say). Actually, it's easier to make a motor continuously variable then to make one that steps from one speed to another. The speed of a DC motor depends on power (volts times amps), so all you would do to make one continuously variable is to drive the motor off an amp (or just a transistor, same difference) whose input simply varies with the drive speed you want. To make one step from one speed to another would require some digital counting circuitry and a D/A converter, as well as the amp to drive the motor. -- Charles William Swiger