Re: EDD + CARD

[Dick Sisco <dsisco11111@mchsi.com>]

On 25 Jul 2002 19:51:13 GMT, mjmahon@aol.com (Michael J. Mahon) wrote:

>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 that is exactly why it works as a protection scheme.  After about
8-10 0 bits the standard Apple (or IBM) controller begins returning
random bits.  

A special controller (like that in a Trace duplicating machine) can
lay down  two or three bytes of 0s somewhere on the disk. 

A standard disk controller will add some random 1 bits while trying to
read the 0s. CopyA and its ilk will complain about a bad checksum and
refuse the copy the disk.   A bit copy program will blythly write
those bytes as real bytes, random bits and all,  or, if it rereads the
source track, will complain that it can't get a good read.

The protection verifier on the disk will request reads of those bytes
multiple times.  If those bytes are the same on several reads, the
disk must be a bit bit-copy.  But if they don't match, it's an
original.  

This technique (called "weak bit") was being discussed in the copy
protection community as early as 1985.  I implemented it on the Apple
II for 5.25" and 3.5" disks and 5.25" IBM disks (never could get it to
work on IBM 3.5" disks) for a disk duplication company in about 1987
and I know the Apple 5.25" version was used on at least a couple of
disks.

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