Path: news.uiowa.edu!news.physics.uiowa.edu!math.ohio-state.edu!howland.reston.ans.net!nntp.coast.net!news.kei.com!newsfeed.internetmci.com!in2.uu.net!news.u.washington.edu!news.uoregon.edu!cie-2.uoregon.edu!nparker From: nparker@cie-2.uoregon.edu (Neil Parker) Newsgroups: comp.sys.apple2.programmer Subject: Re: Q: 3.5" encoding scheme Date: 24 Jun 1996 09:50:51 GMT Organization: University of Oregon Campus Information Exchange Lines: 98 Distribution: world Message-ID: <4qlodr$mad@pith.uoregon.edu> References: <4qjdnj$t5a@elna.ethz.ch> NNTP-Posting-Host: cie-2.uoregon.edu In article <4qjdnj$t5a@elna.ethz.ch> GUDATH@EZINFO.VMSMAIL.ETHZ.CH (Henrik 'Ratte' Gudat) writes: >[...snip...] >- as with 5.25" disks, address fields are encoded 4&4, the data chunk 6&2, >right? Wrong. The address fields of a 3.5-inch disk are encoded 6&2 (sort of). The address field looks like this: $D5, $AA, $96, track, sector, sides, format, checksum, $DE, $AA Each datum in the address field is a 6-bit number. Their meanings are as follows: track The low-order six bits of the track number sector The sector number sides Bit 0 is the high-order bit of the track number Bit 5 is the side number (0 for side 1, 1 for side 2) All other bits are zero (i.e. the number looks like "s0000t") format The low four bits are the interleave (usually 2, unless the disk was formatted on a Unidisk 3.5) The high bit is the number of sides (0=single, 1=double) Bit 4 is always 0 (the number looks like "s0iiii") checksum A checksum of the previous four values (I'm not sure, but I think it's computed by EORing) Each of these numbers is translated to a valid disk byte by looking it up in the 6&2 translation table (so that 0 becomes $96, 1 becomes $97, 2 becomes $9A, etc.). >- the two bits that are rolled out of each byte (6&2 scheme) are put into a >secondary buffer. Where will this buffer be written? After the main buffer >(with bits 2-8 of each byte)? or will it also be divided by some magic figure >(for example, 6 chunks of 86 bytes from main buffer and 27 bytes from secondary >each)? It's a bit more complicated than that. There are, in effect, four buffers. They get filled something like this: 1st byte --> 6 bits to byte 1 of buffer 1, 2 bits to byte 1 of buffer 4 2nd byte --> 6 bits to byte 1 of buffer 2, 2 bits to byte 1 of buffer 4 3rd byte --> 6 bits to byte 1 of buffer 3, 2 bits to byte 1 of buffer 4 4th byte --> 6 bits to byte 2 of buffer 1, 2 bits to byte 2 of buffer 4 5th byte --> 6 bits to byte 2 of buffer 2, 2 bits to byte 2 of buffer 4 and so forth. All the while a three-byte checksum is being computed, in a very hard-to-understand way. Watch out! The checksum computation modifies the data, just like it does on the 5.25-inch drive. Once the buffers are filled, they're written: 1st byte of buffer 1 1st byte of buffer 2 1st byte of buffer 3 1st byte of buffer 4 2nd byte of buffer 1 2nd byte of buffer 2 etc. So the byte containing the extra two bits from three other bytes is written immediately following those three bytes. The three-byte checksum expands to four bytes in exactly the same fashion. The data field looks like this: $D5, $AA, $AD, track, 699 data bytes, 4 checksum bytes, $DE, $AA The "track" number is identical to the "track" number from the address field. Remember that the original data is 524 bytes, not 512. >- is the book "Beneath Apple ProDOS" still available? :-)))) I think Byteworks still sells it. But it was written before the 3.5-inch drive was available for the Apple II, so its contents are only relevent in a very general sort of way. - Neil Parker P.S. I recommend having a look at the 3.5-inch drive I/O routines in the IIGS ROM. You can find them by looking in the SetHook/GetHook table, which is at $E10F6F in ROM 1 (note that there are two identical JMP instructions for each vector). It's best to do this without booting GS/OS, because GS/OS patches the vectors. See the file on undocumented Smartport info on my home page, http://cie-2.uoregon.edu/~nparker. P.P.S. Are you aware that something keeps adding control-P's to the subject lines of your postings? I've seen it in at least three unrelated posts from you. -- Neil Parker | No cute quote, no cute ASCII art, no cute nparker@cie-2.uoregon.edu | disclaimer, no deposit, no return.... nparker@cie.uoregon.edu | (This space intentionally left blank: http://cie-2.uoregon.edu/~nparker | )