Dan Foster replied: >In article , >Matthew Russotto wrote: >>In article <3D3F530C.E9C1A309@intergate.ca>, >>Wayne Stewart 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/ On 25 Jul 2002 19:51:13 GMT, mjmahon@aol.com (Michael J. Mahon) wrote: >Dan Foster replied: > >>In article , >>Matthew Russotto wrote: >>>In article <3D3F530C.E9C1A309@intergate.ca>, >>>Wayne Stewart 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/