CP/M

On Tue, 16 Jun 1998, Ward Donald Griffiths III wrote: Um, I don't know that to be true. That is, the Apple OS did NOT have to write the entire track in order to write one sector. The Apple tracks included sufficient sync bytes between sectors and between sector header and data fields to allow time for the proper location to be found and then written to. I was curious enough to go back to my Apple and continue where I left off many years ago and figure out the DOS code which writes sectors. That is one of the few things I didn't intimately know about the Apple DOS. I began disassembling the machine code tonight but I haven't figured it out just yet. There is only enough buffer space in the Apple DOS RWTS (Read Write Track Subroutines) for the DOS to create one 342 byte 6&2 encoded sector. As far as I know (or think), the OS would search for the address header prologue, which was D5 AA 96, then the data following that contained (among other data) the sector number, then you'd get the address epilogue (DE AA EB). If this was the sector you wanted, you then went into a tight timing loop to bypass the sync bytes (a series of 10-bit words consisting of 8 '1' bits and 2 '0' bits) and then...this is where it gets fuzzy. The data area is has a prologue of D5 AA AD, then 342 6&2 encoded bytes, then the prologue (DE AA EB). [6&2 encoding was an encoding method to insure there were never any bytes written to the disk containing two consecutive zero bits, a no-no for the Disk ][ hardware (this is what made it strange to work with). 6&2 refers to how the bits of each byte were separated: the first 6 bits of an 8-bit byte were indexed into a table which contained all possible 8-bit bytes with the 8th bit set and no consecutive zero bits; this was the value actually written to disk; the remaining two bits of each byte were combined with the two-bits of other bytes to form more 6-bit words that were indexed into the lookup table. 256 bytes * 8 bits / 6 bits = 342 bytes needed for 6&2 encoding. There was also 4&4 encoding which was less efficient as it used up more disk space but was simpler. 4&4 is where you insert a '1' bit between each bit of a byte, therefore, each byte would take two disk bytes to store, but again you would insure that there were no consecutive zero bits written.] Anyway, I'm going to research this and come back with my conclusion if anyone's interested. Sam Alternate e-mail: dastar(a)siconic.com ------------------------------------------------------------------------------- Ever onward. September 26 & 27...Vintage Computer Festival 2 See http://www.siconic.com/vcf for details! [Last web page update: 06/11/98]