Re: GCR Encoding

["Bryan Parkoff" <bryan.nospam.parkoff@nospam.com>]

Eric,

    I will be willing to pay you the fee for more information about MFM
encoding and MFM hardware.  Maybe FM encoding will be included.  I do have
enough information about GCR encoding since I already have Beneath to DOS
3.3 and ProDOS.  I don't need more information for GCR encoding, but I need
to understand how Disk II hardware work.  I do have Understanding Apple II+
& //e book that explains Disk II hardware.
    Do you have any book that can explain FM / MFM encoding and hardware?

-- 
Bryan Parkoff
"Eric Smith" <eric-no-spam-for-me@brouhaha.com> wrote in message
qh1xqwjttk.fsf@ruckus.brouhaha.com">news:qh1xqwjttk.fsf@ruckus.brouhaha.com...
> "Bryan Parkoff" <bryan.nospam.parkoff@nospam.com> writes:
> >     Can Disk II Family read three or four (zero) bits that it will
always
> > show invalid?  Is it the truth that Disk II's hardware is designed to
read
> > only one or two (zero) bits?
>
> Yes, that's correct.
>
> > Can you explain why?
>
> The Disk II controller (and IWM) can't reliably read "nibbles" containing
> more than two consecutive zero bits.  In fact, the older 13-sector state
> machine PROM (P6) can't reliably read more than one consecutive zero bits.
>
> The one bits in the nibble are stored as flux transitions on the media.
> Zero bits are only indicated as the lack of a flux transistion.  On
> a write, every time there is a pulse on the write data line, the drive
> "analog board" electronics and head cause a flux transistions.  On read,
> the head and analog board detect the flux transitions and produce pulses.
>
> The controller transfers data using a shift register running at a
> crystal-controlled rate, but the drive motor speed is not sufficiently
> well regulated to make it possible to accurately time long streams
> without flux transistions.
>
> Also, there is speed variation from one drive to another.
>
> The bit time is nominally approximately 4 microseconds.  Suppose
> you have a disk that was written on a drive that was 8% fast.  Now
> you read that disk on a drive that is 8% slow.  The bit timing will
> be 4.7 microseconds.  On the other hand, you might write a disk on a
> drive that is 8% slow, then read it on a drive that is 8% fast.  This
> would make the timing 3.4 microseconds.
>
> Here are some example timings:
>
>
>            interval between pulses
>
>                     fast wr    slow wr
> data     nominal    slow rd    fast rd
> -----    -------    -------    -------
> 11        4 us       4.7 us     3.4 us
> 101       8 us       9.4 us     6.8 us
> 1001      12 us     14.1 us    10.2 us
> 10001     16 us     18.8 us    13.6 us
>
>
> Suppose the state machine sees two pulses with an interpulse delay of
> 13.8 microseconds.  Should it decode that as 1001 or 10001?  It is
> ambiguous.
>
> Restrictions on consecutive zero bits are used in all disk channel
> codes.  The IDE or SCSI drive in your PC or Macintosh has such
> restrictions.  However, they are dealt with entirely by the embedded
> control system of the disk drive, so you as an end user never notice it.
>
> With the Disk II controller, this restriction has to be dealt with by
> software running on the main processor.
>
> > Why do each byte require between $80 and $FF?
>
> Because as the bits are being shifted in from the disk, the only way the
> software can tell that a whole nibble has been read is by the most
> significant bit being set.
>
> Suppose that this restriction did not exist.  Then the values $FE and
> $7F would both be valid nibbles.  When the software is reading a nibble
> and gets a $7E, how would it know that the full nibble had been read,
> and that there wasn't another zero bit in the nibble about to be shifted
> in, making it $FE?
>
> >  I do understand that between $00 and $7F can't be used
> > because it will show more than two (zero) bits.
>
> That explains $00.  The only reason $7F can't be used is that there
> would be no way for the software to tell that the full nibble has been
> read.
>
> > How did Steve Worniak decide to design logic chip that can only handle
> > two (zero) bits?
>
> The logic chip (74LS323) doesn't care whether the bits are 0 or 1.  Only
> the software cares.
>
> > I do know that he decides to use software by reading each bit.
>
> The software does NOT read each bit, at least not individually.  It
> loops reading the shift register until the most significant bit is set.
>
> > If hardware is chosen to use its own hardware, three or more (zero)
> > bits can be accurate because the rotation speed is always fixed.
>
> The rotation rate is never "fixed".  Even on drives that use a tachometer
> and servo for motor speed control, there is always some variation.
>
> > I am so curious why Apple II decide NOT to use standard MFM encoding
> > that it does exist before 1970s, but all PC like 8080 and/or 8085 use
> > MFM encoding (probably FM encoding) before 1970s.
>
> Because in 1977 when Woz designed the Disk II controller, it would have
> cost a lot more money, and used a much larger circuit board, to implement
> MFM.
>
> The Disk II controller *is* capable of reading and writing FM.
>
> > Please explain every detail if you have great knowledge.
>
> Please pay me my standard consulting fee, and I'll be glad to explain
> every detail.
>
> Alternatively, get a book.  There are several that explain this stuff.
> Beneath Apple ProDOS is a good start.  (There are some fundamental
> errors in the description in Beneath Apple DOS, so I don't recommend
> it as a source for information on the low-level operation of the
> Disk II, but it is still *very* useful at explaining how the Apple DOS
> software worked.)
>
> There is another book that has an even better explanation of how the
> Disk II controller works, but I don't recall the title or author at
> the moment.