"Michael J. Mahon" wrote: > That would be a very interesting manual... I have the looseleaf part, but > not the main manual. ;-( > > >The manual says the card is able to reliably read "hidden timing BITS found > >between the raw disk Bytes" > > Actually, the ondinary Disk ][ controller is capable of reading "every bit" > on the disk as well, as long as there is some recognizable transition in > each 8-bit sample. This is equivalent to bypassing the clock-recovery > state machine on the controller, and just reading the bits as they shift > in, without regard to the high bit being set. > > This would leave the actual data decoding to software after a full track > has been read, but the only time there could be any ambiguity about > a bit on the disk was when 8-20 bit times went by without any transition > from 1 to 0 or 0 to 1. As a practical matter, I think that no disk ever > contained patterns like that. Self-sync nibbles are eight 1's and two 0's, > and it would take a _very_ nonstandard write routine (reloading the register > before it was completely written, for example) to write gobs of consecutive > 1's or 0's. > > So, what exactly _was_ the function of the EDD+ card? If it literally > presented the head signal to the software, with, say, 2MHz sampling, > then what would it enable that could not be done with non-standard > software and the standard Dosk ][ card? I'll do a pdf of the manual as soon as I finish the currant projects. I was doing the ProSel 16 manual. I'm taking a break from it to do the RocketChip manual which another A2 user kindly sent me a photocopy of. I want to get those two done before I start another pdf. Here's a small quote from the manual THE DRIVE CONTROLLER: The drive controller, like the disk drive, also has two jobs. The first job is, when writing disks, to take raw disk bytes from the computer and break them down into eight separate bits, which are then fed into the raw bit stream in route to the disk drive. This is a fairly simple and straight forward process. The second job of the drive controller is a bit more complicated. When reading the disk, the drive controller collects eight bits at a time from the raw bit stream, then converts them back into their original raw disk byte value. Let’s go into detail of what happens during this reading process: When the drive controller is told to read the raw bit stream from the drive, chances are that the drive controller will not be properly aligned (out of synchronization) with the raw bit stream. This means that the drive controller will not be properly converting the raw bit stream back into the same raw disk bytes, that were originally wrote to the disk. For example, let’s say that the raw disk bytes “FC FC FC FC" are being wrote to the disk. Here is what the raw bit stream would look like going to the disk drive 11111100111111001111110011111100 But, when the track is read back, there is no way of telling which bit in the raw bit stream was the "start" of a raw disk byte; and chances are that the drive controller will start converting raw disk bytes Out of alignment. Here is what the raw bit stream might look like when trying to read it: 11111111100111111001111110011111100 A few "extra" one bits that were already on the track, before the “FCs” were wrote, were read first. The drive controller would convert this raw bit stream into the raw disk bytes "FE 9F 9F 9F". These raw disk bytes should have been “FC FC FC FC". So, what we need is a way of ‘aligning the raw bit stream so that the raw disk bytes can be converted back correctly. This is where timing bytes and timing gaps come into Play. When reading the disk, after the drive Controller is finished creating a raw disk byte from the 8 bits taken from the raw bit stream, the drive COntroller starts over again looking for another raw disk byte. Any "0" bits that happen to flow down the raw bit stream immediately after the 8 bits, which made up a raw disk byte, are completely ignored by the drive controller; since all raw disk bytes must start with a "1" bit. These “0” bits, which are ignored, are called “timing bits”. As we will soon see, the main purpose of a timing bit is to align the drive controller with the raw bit stream, so that the problem with converting the raw bit stream to raw disk bytes, as was the case with the previous example, doesn’t happen. RAW DISK BYTES, TIMING BITS, TIMING BYTES, AND TIMING GAPS: A normal raw disk byte consists of eight bits. The first bit, the left—most bit, must always be a “1”. Timing bits are any extra "0" bits which immediately follow a raw disk byte. As discussed in the previous section, these extra “0" bits are ignored (skipped over) by the drive controller. A timing byte is the term for a raw disk byte with at least one timing bit attached, which means a timing byte contains nine or more bits (eight raw disk byte bits, and at least one timing bit). Here is an example of four timing bits which make up three timing bytes (we have added “spaces” to separate raw disk bytes for your convenience): RAW BIT STREAM (from drive, to drive controller): 1111111101111111100111111110110101011010101010010110 | | | ( timing bits) 11111111 0 11111111 00 11111111 0 11010101 10101010 10010110 | | | | | | $FF $FF $FF $D5 $AA $96 (raw disk bytes) The four zero bits that are pointed Out from the top of the raw bit stream are timing bits which the drive controller ignores. The eight bit patterns pointed out from under the the raw bit stream are the actual bits of information that make up the raw disk bytes. So, this example of the raw bit stream would yield us the raw disk bytes “FF FF FF D5 AA 96". Each of the first three raw disk bytes (FE’s) are considered to be timing bytes, in this example. The first and third timing byte here, each has one timing bit attached, making the total length of these timing bytes nine bits long. The second timing byte has two timing bits, making it ten bits long. When several (usually at least 4) timing bytes are written out to the track consecutively, we call the group of timing bytes a “timing gap”. Timing gaps are very important, because they allow the drive controller to line up with the raw bit stream correctly, so that the raw disk bytes following the gap can be converted to their proper values. Dick Sisco replied: >On Fri, 26 Jul 2002 15:33:17 -0000, russotto@grace.speakeasy.net >(Matthew Russotto) wrote: > >>In article , >>Dick Sisco wrote: >>> >>>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. >> >>Why does it do that? A 0-bit is a lack of transition on the disk; while >>the controller may not be able to figure out how many non-transitions >>occurred, I don't see why it should start returning 1s. > >As it was explained to me, the circuitry in the disk controller turns >up its aplification(?) if it doesn't see transitions. It eventually >senses a transition when there really isn't one. I can't swear that >that's an accurate description, but that was the way the instructor at >a disk duplicaton seminar explained it to me. And it did seem to >work. Exactly. Since the head amplifier must accomodate wide variations in signal levels, it incorporates an automatic gain control (AGC) which continuously adjusts the degree of amplification of the head signal prior to the thresholding operation that interprets it as a 1 or 0. In the absence of transitions, the AGC turns up the gain, so that within 8-10 bit periods, noise is being converted to "signal", which results in about half the bit cells being interpreted as 1's. One potential problem with this scheme, is that if the disk has ever been recorded before, the noise that the read head picks up may not actually be random, but may be either residual magnetization of the medium or "fringe field" data--data outside the nominal track but close enough to force a deterministic read pattern when the gain is turned up. Either effect could make the "zero nibbles" be read deterministically, which would make the code that does the "original verification" think that it was seeing a copy. I speculate that this scheme was used only on virgin or bulk-erased diskettes to avoid these problems. -michael Check out 8-bit Apple sound that will amaze you on my Home page: http://members.aol.com/MJMahon/