On Tue, 16 Jun 1998, Ward Donald Griffiths III wrote:
Actually, Apple was the _ultimate_ soft-sector, as it
didn't pay any
attention to sector detect at all -- it had to read the whole track
then figure out where it started. It's a major reason why database
applications were never a big thing on Apples until hard disks showed
up -- updating things by record was only possible by writing whole
tracks.
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]