[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: GCR Encoding

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.