[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: EDD + CARD
- Subject: Re: EDD + CARD
- From: mjmahon@aol.com (Michael J. Mahon)
- Date: 25 Jul 2002 19:51:13 GMT
- Newsgroups: comp.sys.apple2
- Organization: AOL http://www.aol.com
- References: <ahp637$1g0u$1@node21.cwnet.roc.gblx.net>
- Xref: archiver1.google.com comp.sys.apple2:21592
Dan Foster replied:
>In article <uk05n03qt3dgbc@corp.supernews.com>,
>Matthew Russotto <russotto@grace.speakeasy.net> wrote:
>>In article <3D3F530C.E9C1A309@intergate.ca>,
>>Wayne Stewart <waynes@intergate.ca> wrote:
>>>
>>>The manual says the card is able to reliably read "hidden timing BITS
>>>found
>>>between the raw disk Bytes"
>>
>>Doesn't make a lot of sense to me; in a GCR scheme, there aren't any timing
>>bits.
>
>Perhaps it's referring to the prolog/epilog bytes that sits in between
>5.25" floppy disk sectors such as D5 AA 96 / DE AA EB ?
>
>Timing bits is probably another way of saying 'something that synchronizes
>access to data by identifying start/end of data portion of a sector'.
In fact, at the base level, no single-bit-stream disk has "timing bits"
except by decoding convention. On the media "bits is bits" and only
some predefined pattern can be used to separate the data from the
timing (or clocking) info.
In GCR schemes, the clocking is implicit in the restricted patterns
that are recorded. The Apple GCR scheme uses a lead-in pattern
of 10-bit (not 8-bit) "self-sync" nibbles which guarantee that the
controller state machine is synchronized to nibble boundaries. Then
each recorded nibble consists of eight bits with the leading bit a 1.
This "start bit" in each nibble allows the controller (and software) to
maintain synchronization throughout the data transfer.
In this context, prolog and epilog nibbles are just a part of the data
stream, since the controller must already be synchronized to the
bit stream to correctly recognize nibbles.
More likely, "hidden timing bits" refers to "extra" bits in longer-than-
8-bit sequences written to the disk. The most common use of such
sequences is "self-sync" patterns. The standard self-sync sequence
is eight 1's followed by two 0's--the result of writing the nibble FF with
40 microsecond timing instead of the 32 microsecond timing required
to write 8-bit nibbles.
The standard disk read routines are not capable of detecting the two
0's directly, since the controller shift register's high bit has already been
set by the first of the eight 1's. Non-standard techniques can measure
the time until the high bit becomes set again, and so determine how
many 0 bits were present after the initial 8.
If the presence of a non-standard number of 0 bits were not detectable
by a Disk ][ controller, this so-called "bit stuffing" scheme could not
be verified to be present, negating its usefulness as a disk "signature"
technique.
But since each "bit time" is only 4 microseconds, an unaccelerated
Apple II has a hard time sampling often enough to determine just how
many bit times have elapsed "between" detected nibbles. The Disk ][
controller samples the head signal at 2MHz to unambiguously detect
bits. The Apple processor must do a LDA shiftreg,x followed by a
conditional branch to detect a shift register transition. Since the
LOAD/BRANCH combo requires at least 6 cycles to execute, the
Apple can do only two tests in three bit times, making accurate
determination of the extra 0 bits problematic.
I speculate that the EDD+ card samples the head read signal at
a higher frequency (2MHz would do nicely, but even 1MHz would
be sufficient) and shifts the raw bits into a register which can be
read by the Apple II faster than every 32 microseconds, allowing
software to reconstruct the actual disk bit patterns unambiguously.
If anyone has the code that used this card, some reverse-engineering
of the code should reveal the actual principles of operation.
-michael
Check out 8-bit Apple sound that will amaze you on my
Home page: http://members.aol.com/MJMahon/