Re: GCR Encoding

["Jplcsch" <jplcsch@wanadoo.fr>]

Theses weak bits was found only on PC with the NEC 765. The signal was
writing with not the electric level ad hoc so when you read this bits, one
time you read 0 and another time you read 1. What is sure : you can never
read the same thing on ten tries. The protection consist to try to read mant
times a weak bit and if found the same value (0 or 1 the problem is not
here) it's a copy ... you stop the program. Why ? because a bitcopier
analyse this bit and choose for a value 0 or 1 but it can't write middle
level electric signal. The protection is : If it's bad the disk is good !
Prolok (with an other techniaue on Apple II a "laser hole" on the media.)
take the same principe : if read is bad then the disk is good!
This schem of protection is not hard to go down. The way of cracking : It
exist always another way.


"Eric Smith" <eric-no-spam-for-me@brouhaha.com> wrote in message
qhwu8iaj5a.fsf@ruckus.brouhaha.com">news:qhwu8iaj5a.fsf@ruckus.brouhaha.com...
> "Bryan Parkoff" <bryan.nospam.parkoff@nospam.com> writes:
> >     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.
>
> No, that is not what happens.  THere isn't any "pair of bytes".
>
> When writing (in 16-sector format), the data is read 6 bits at a time,
> and used as an index in a "nibblizing" table to get the 8 channel bits
> ("nibble") to write to the medium.
>
> Because only 6 data bits can be read or written per nibble, a 256-byte
> data sector is written in segments (my term, I don't know of any
> official name).  The first segment consists of 256 nibbles each containing
> six bits from a distinct  data byte.  The second segment consists of
> nibbles formed by grouping the "leftover" two bits from three data bytes
into
> one six bit nibble.  This results in a total of 342 nibbles per sector
> (plus additional nibbles for the address field, data field prolog, epilog,
> and checksum).  Note that 342 nibbles actually encodes 2052 data bits,
> but since there are only 2048 data bits actually used in a sector,
> 2/3 of the last nibble are effectively wasted.
>
> When reading, the 8-bit channel codes (nibbles) are read then used
> to index a denibblizing table to get 6 data bits.
>
> >     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.
>
> OK, if you don't want me to anser your questions, I certainly don't
> have to.
>
> >     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?
>
> It is *completely* unclear what you mean by "valid pair of byte".  I
> never used pairs of bytes ANYWHERE in my description of how this stuff
> works.
>
> > 2) Do copy-protected disk contain more than 3 (zero) bits that appear to
be
> > invalid?
>
> Sometimes.  If they do, they can't be read completely reliably, for
> reasons we've previously discussed.
>
> > 3) If you answer yes to question #1, why nibble analyzer fail to read
EACH
> > PAIR OF BYTE?
>
> Question #1 didn't make any sens, and neither does this one.  Once again,
> there are no "pairs of bytes" anywhere in the process.
>
> > 4) I would appreciate if you provide more information how PAIR OF BYTE
is
> > stored as WEAK BIT
>
> The aren't.  A weak bit has nothing to do with a pair of bytes.
>
> > since I already have all the copy-protected scheme
> > information from Copy II Plus manual.
>
> I haven't read that manual.
>
> > 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...
>
> No, it's not true.
>
> Are you somehow interpeting FM encoding using clock bits as turning
> a data byte into a "pair of bytes"?  If that's what you're talking
> about, the Disk II doesn't do that, except in using 4+4 encoding to
> store the track, sector, and voume number in the address field.  It
> has NOTHING to do with how the data field is encoded.