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 |                                           )