The ways in which Apple and Commodore do it are well documented today. Back
in the '80's it was much easier to think of it as a table lookup. Some
controllers used a more conventional approach, i.e. using a standard
controller\formatter to generate the track format, then writing the data
fields in a different modulation, simply substituting the input/output from
one serializer/deserializer for another for a precisely prescribed bit count.
On floppy disk interfaces, the data rate was plenty slow enough to allow that
sort of thing.
I personally preferred the table lookup. That enabled me to put half-again
the usual amount of data on the disk simply by looking up the 5-bit pattern
corresponding to each 4-bits of data. The resulting data could be written at
nearly twice the data rate, resulting in an 8:5 appreciation in capacity.
Various RLL schemes work that way. That's why the RLL controllers provide 9/5
the capacity
Dick
----- Original Message -----
From: "Ethan Dicks" <erd_6502_at_yahoo.com>
To: <cctalk_at_classiccmp.org>
Sent: Wednesday, May 15, 2002 1:40 PM
Subject: Re: [CCTALK] Commodore 1541 Drive
>
> --- Richard Erlacher <edick_at_idcomm.com> wrote:
> > it's well to remember the "GCR" stands for group-coded-recording, which
> > can mean a lot of things, and that it's a form of "RLL," or
> > run-length-limited" encoding. Both operate in a way that generates,
> > typically, more transitions in the aggregate, than the original (NRZ)
> > data stream, but locates the transitions propitiously in a way that
> > limits their density so that it remains within the head-media
> > combination's capability to resolve those transitons accurately enough
> > to allow data recovery.
>
> To summarize: (from 1541 tech docs)... you can't have more than two
> adjacent physical zero bits on the media because the clocking of the
> third bit and beyond gets to be too much guesswork. You can't have
> too many (7? 8?) one bits in a row because that triggers the circuit
> I described earlier that detects start of header data. Remember, also,
> that it's a serial bit stream, so the zeros or ones of one GCR group
> have to be considered when placed next to any other GCR group, front
> or back.
>
> The GCR used by Commdore is a 5-to-4 arrangement - five bits on the
> disks (32 possibilities) are used to encode 4 data bits (16 possibilities).
>
> I don't have the docs right in front of me, but I think I can take a stab
> at what patterns aren't used just based on following those two rules above
>
> Too many 0s in front, back or middle...
>
> 00000 00001 00010 00011 00100 00101 00110 00111
> 01000 01100 10000 10001 10100 11000 11100
>
> Too many 1s in front, back or middle...
>
> 11111
>
> Good patterns
>
> 01001 01010 01011 01101 01110 01111 10010 10011
> 10101 10110 10111 11001 11010 11011 11101 11110
>
> If I had a copy of "Inside the 1541" or the like, I'd look it up, but I
> don't have one in front of me. Essentally, the disk stores those GCR
> codes and the 1541 processor translates buffers back and forth manually,
> kinda like an Amiga with MFM, but without a coprocessor.
>
> > That leaves LOTS of room, and it's in this room where both the Apple
> > scheme and the Commodore scheme live.
>
> Agreed. I do not know how Apple does it. At least the 1541 converts
> GCR<->binary in software.
>
> -ethan
>
>
>
> __________________________________________________
> Do You Yahoo!?
> LAUNCH - Your Yahoo! Music Experience
> http://launch.yahoo.com
> _______________________________________________
> cctalk mailing list
> cctalk_at_classiccmp.org
> http://www.classiccmp.org/mailman/listinfo/cctalk
>
>
Received on Wed May 15 2002 - 17:04:27 BST