Re: EDD + CARD

[Wayne Stewart <waynes@intergate.ca>]

"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.