[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Anybody aware of the description of a 19pin connector of an Apple 5.25 Disk Drive ?



On Monday, May 6, 2013 4:09:01 PM UTC-7, Phil Tubb wrote:
> 
[...]
> ... If you look at Wikipedia's article on "Apple DOS", you'll see that originally a track had the sectors written in this order:  0 7 14 6 13 5 12 4 11 3 10 2 9 1 8 15. This was done to give the software time to decode each sector after it was read. Let's say you want to read all the sectors on a track in order (a very common operation). In the very best case, with this arrangement sector 0 would just happen to be right there ready for you to read. In the same single rotation of the disk, you'd wait as sectors 7, 14, 6, 13, 5, 12, 4, 11, 3, 10, 2, and 9 go by, then you'd read sector 1. (Of course during this "waiting" the software would actually be decoding the raw data read from the disk for sector 0.) Then you'd wait while sectors 8 and 15 go by, and that's the end of the first spin... each spin takes 1/5th of a second. In the next spin, you'd wait while sectors 0, 7, 14, 6, 13, 5, 12, 4, 11, 3, and 10 go by, then read sector 2. Again, you'd be decoding sector 1 while these sectors go by. Then you'd wait while sectors 9, 1, 8, and 15 go by; that's the end of the second spin. You can see it's going to take a whole lot of rotations, at 1/5 second each, to read the track. In contrast, the hardware on S-100 systems of the day easily read all the sectors in one spin (best case); there was no need to allow sectors to pass by while the processor decoded the raw data because the floppy-controller chip could do that by itself. Worst case, the S-100 systems would JUST MISS sector 0 and have to wait one spin for it to come around (the same thing can happen to Apple as well), then use one spin to read every sector on the track.
> 

The following is anecdotal, because I forgot where I read it.

You mentioned the staggering of sectors on individual tracks, allowing the next readable sector to appear just as the decoding of the previous was complete.  One thing that I noticed was that DOS 3.3 seemed to boot-load more quickly than a standard BLOAD; I read that the boot tracks had been carefully interleaved for optimal throughput, but that standard files were stored with a simpler, slower ordering.  Have any of you guys heard about this?  Were there any DOS 3.3 RWTS mods that took advantage of this, improving performance?  If I'm being foolishly naive, I'm prepared for the beating ;-)

Mike