💾 Archived View for mirrors.apple2.org.za › archive › apple.cabi.net › FAQs.and.INFO › CPUandMore › … captured on 2023-05-24 at 23:45:53.
⬅️ Previous capture (2023-01-29)
-=-=-=-=-=-=-
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 | )