15 May
2002
15 May
'02
10:04 a.m.
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(a)yahoo.com>
To: <cctalk(a)classiccmp.org>
Sent: Wednesday, May 15, 2002 1:40 PM
Subject: Re: [CCTALK] Commodore 1541 Drive
--- Richard Erlacher <edick(a)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(a)classiccmp.org
http://www.classiccmp.org/mailman/listinfo/cctalk