Re: GCR Encoding

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

Eric,

    Yeah, I already understood your point since we have already discussed in
the past.  I do understand that data bit and channel bit must be combined
into sequence 16 bit or a pair of byte per raw data byte.  It is how
communication work like you mentioned about modem and etc...
    I wish that 7+1 can be added, but it will require 3 or 4 (zero) bits
that GCR encoding can't accept it.  The discussion is enough so it is not
necessary to repeat over and over.
    My last question is about copy-protected disks.

1)  Can Disk II read A VALID PAIR OF BYTE for each raw data byte inside
copy-protected disk?
2) Do copy-protected disk contain more than 3 (zero) bits that appear to be
invalid?
3) If you answer yes to question #1, why nibble analyzer fail to read EACH
PAIR OF BYTE?  It should read all of them accurately before I can be able to
convert from PAIR OF BYTE into raw data byte (256*16*35) = 140K.
4) I would appreciate if you provide more information how PAIR OF BYTE is
stored as WEAK BIT since I already have all the copy-protected scheme
information from Copy II Plus manual.  I do understand how copy-protected
scheme work such as SYNC HEADER changed, etc....  No need to discuss.
5) Is it true that the manufacturer convert raw data 140K (probably 90K -- 
4+4 only, but no 6+2) into PAIR OF BYTE before one or more PAIR OF ZERO BITS
may be added between each TWO PAIR OF BYTE that they really use Disk II
drive, but not other type of PC drive like FM?  Please explain...


-- 
Bryan Parkoff
"Eric Smith" <eric-no-spam-for-me@brouhaha.com> wrote in message
qhhdzrkfp4.fsf@ruckus.brouhaha.com">news:qhhdzrkfp4.fsf@ruckus.brouhaha.com...
> "Bryan Parkoff" <bryan.nospam.parkoff@nospam.com> writes:
> >     I will be willing to pay you the fee for more information about MFM
> > encoding and MFM hardware.
>
> To understand any of these data formats, it is necessary to understand
> the concept of a channel code, and the distinction between data bits and
> channel bits.
>
> Raw data cannot normally be written directly to a medium, or transmitted
> across a communication channel, because there has to be some means at the
> reading/receiving end to determine where each bit begins and ends.  One
> of the most common ways of dealing with this is to transform the data
> into a self-clocking format using a channel code.  Channel codes may
> or may not be binary.  For instance, modems (including those used for
> DSL) generally pack multiple bits per transmitted symbol.  However,
> for our purposes we will only consider binary channel codes.
>
> To convert binary data into a binary self-clocking channel code, extra
> bits must be added.  Data bits are the user-level data.  For instance,
> on an Apple II a logical sector consists of 256 bytes of eight bits
> each.  But at the hardware level, the disk controller deals with groups
> of eight channel bits that have special limitations on the allowable
> combinations.  Each group of eight channel bits encodes only six data
> bits (or five data bits in 13-sector format.
>
> In general, GCR formats allow any string of channel bits that meet the
> requirement of not too many consecutive zeros.  The channel bits are
> used in groups, and typically there is a "code book" to map combinations
> of user data bits into groups and vice versa, hence the term "group code".
>
> Sometimes some other constraints are added; for instance, Apple GCR adds
> the requirement that the most significant bit must be a one.
>
> Apple calls groups "nibbles".
>
> Note that in GCR there is not a one-to-one mapping of data bits into
> channel bits.  You can't isolate bit 4 of the group, for instance, and
> say that it corresponds to bit 6 of the data byte.
>
> In simpler channel codes, there is a more direct relationship between
> data bits and channel bits.  For instance, in FM coding every other
> channel bit must be a one, and is called a clock bit.  The data bits are
> passed through unmodified, so each data bit maps to exactly one
> corresponding channel bit.  (Inside Apple DOS erroneously claims that
> Apple GCR has clock bits.)  FM coding basically identical to the "4+4"
> format used for the volume, track, and sector bytes of the address field
> in Apple format.  But on an FM disk, all data is encoded that way.
>
> You can see that FM is less efficient than Apple GCR.  There are
> only 16 legal combinations of eight channel bits, versus 32 for Apple
> 13-sector format, and 64 for Apple 16-sector format.  (FM uses a few
> otherwise "illegal" codes with a missing clock bit as the index mark,
> address mark, and data mark.)
>
> For the same channel bit rate, FM is 4/5 as efficient as Apple 13-sector
> format (5+3 encoding) and 2/3 as efficient as Apple 16-sector format.
>
> For typical 5.25-inch FM formats, the nominal channel bit cell time is 4
> us, thus the interpulse time is 4 us or 8 us.  For each actual data byte
> recorded, eight clock bits are inserted, so a byte of data requires 16
> channel bits (64 us).
>
> MFM packs data with twice the density by eliminating most clock bits.
> Clock bits are only introduced when two consecutive data bits are both
> zeros.  The channel bit rate is doubled, so the nominal interpulse times
> are 4 us (between two consecutive one data bits), 8 us (between two one
> data bits separated by a single zero data bit), or 6 us (between two one
> bits separated by two zero data bits).  Thus twice as much data can be
> stored on a disk using the same bandwidth, requiring only that the
> read channel be more precisely able to discriminate the pulse timing.
>
> >  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.
>
> Based on the questions you asked in the original message, it would appear
> that you should spend more time studying those books.
>
> >     Do you have any book that can explain FM / MFM encoding and
hardware?
>
> No.  However, the data sheets for the NEC uPD765, Intel 8271 and 8272, and
> Western Digital 1771 and 1791 have a lot of useful information about it.
The
> data on the Western Digital parts may be found in their 1983 data book:
>     http://www.bitsavers.org/pdf/westernDigital/_dataBooks/