Re: GCR Encoding

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

Sean,

    I don't mean to say something like hard to understand.  I can give you
the wrong words, but my concept is perfect understood.  I can't choose the
right word to describe how I can type to say in the newsgroups.  You agree
that my words are chosen wrong, but the concept is already from the manual
and from you.  (Smile)
    I do understand SYNC Header that has 10 bits and 9 bits.  I wish that
Nibble Analyzer can display FF2 FF2 FF2 or FF1 FF1 FF1 instead of FF FF FF.
It might be easier to detect, but software has not written yet or has not
existed.  Only 2 or 1 after FF help us to recognize that 2 means 10 bits and
1 means 9 bits while FF always remain 8 bits + 2 bits or 8 bits + 1 bit.
    If it is true that some copy-protected disks contains more than 3 (zero)
bits, I am positive sure that GCR encoding always ignore it while continue
reading valid bits in the data streaming.
    Thanks for explaining.  Please tell how manufacturer designs by writing
copy protected scheme into disk before it is completely copy-protected.
Where can I get information via website?

-- 
Bryan Parkoff
"sean weintz" <strap@hanh-ct.org> wrote in message
vuhf7q4fc7uu44@corp.supernews.com">news:vuhf7q4fc7uu44@corp.supernews.com...
> Errr.... you say you understand things and
> then ask questions that make it very clear you do
> NOT understand those things.
>
> OK, here is apple GCR in a nutshell -
>
> 16sector, which is 90% of this disks out there
> (including copyprotected) uses an encoding scheme
> where when the disk drive reads a byte off the drive,
> it cannot have 2 consecutive zeroes and it cannot start
> with a zero. When the controller starts to read a byte,
> if the first bit it reads is a zero, it simply throws
> the bit away and makes the next bit the first bit in
> the byte. If the next bit it reads is a zero, it throws
> THAT bit away as well, and continues doing that until it
> finds a bit that starts with a zero. That is why nibble
> anylizers CANNOT tell you exactly what is written to the track.
> For instance, if you had a data stream on the track that was:
>
> 001111111100111111110011111111
>
> the controller card would read that as FF FF FF.
>
> In fact, that particular bit pattern is how the drive syncs up
> to byte starts at the beginning of sectors.
>
> See my coments in your text below:
>
>
> Bryan Parkoff wrote:
>
> > 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?
>
> This question is difficult for me to make sense of. Each "raw" byte is a
> fraction of one data byte. as eric said, there is not a one to one mapping
> of data bits to channel bits.  Each channel byte contains only 6 data bits
> of an 8 bit byte - the rest of the data byte is in the next channel byte.
> So I guess if I understand you correctly, the answer is no.
>
> > 2) Do copy-protected disk contain more than 3 (zero) bits that appear to
be
> > invalid?
>
> Some do, yes.
>
> > 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.
>
> Cracked apple ii games for 4 years as a hobby, and never heard the term
> weak bit used. What ARE you talking about?
>
> > I do understand how copy-protected
> > scheme work such as SYNC HEADER changed, etc....  No need to discuss.
>
> Apparrently you do not understand sync headers at all. Sync headers use 10
> bit bytes, right? (all apple GCR sync bytes are 10 bit normally) so nibble
anylyzers
> cannot read them accurately. for instance they would read (or actually the
controller
> would read):
>
> 01111111101111111101111111
> and
> 001111111100111111110011111111
>
> as being exactly the same thing, (namely FF FF FF) which of course they
ain't.
> In fact, that use to be a halfway decent way to throw off nibble copiers -
> drop one sector off the track, and fill the space with 9 bit self sync
bytes
> instead of 10 bit. Nibble copier will think they are 10 bit self sync bits
> and overwrite the track start on the copy! (that is before the algorithms
in
> nibble copiers got smarter)
>
>
>
> > 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...
>
> Can't make heads or tails of what you are asking there.
>
> >
> >