🚀 go-pugleaf

In article <1990Nov16.215210.23026@daffy.cs.wisc.edu> pochron@cat37.cs.wisc.edu (David Pochron) writes:
>In article <1990Oct15.120046.15007@ericsson.se> etxtomp@eos.ericsson.se writes:
>[about a comp: (compression device)]
>Why not just write a GCR-trackdisk.device that writes disks in GCR format
>instead of MFM format?  You get twice as much disk space (880*2 = 1.66 megs I
>think - its been a while since I last read the disk drive section in the
>hardware reference manual!) and you only have to live with the fact that reads
>and writes will be twice as slow.  Using a trackdisk.device with a compression
>routine would probably work much slower - especially on a 68000 machine, but
>would give different results from different files.

Your suggestion _seems_ very interesting. Unfortunately, you forget one
little but important detail. While MFM indeed expands 1 data bit to 2
disk bits (or 4 bits to 8, as some people say) and GCR only expands 4
bits to 5, GCR has only half the bit rate as MFM. So actually, MFM is
_more_ efficient.

Now this has of course a reason. Current double density disks don't
like magnetic field changes too close to each other, and since 1's are
encoded as field changes, you can't have 2 1's directly next to each
other. Therefore, MFM uses 'clock' bits to dilute the data such that 2
1 data bits are always separated by a 0. (On the other hand, there
can't be too much 0's in a row either since the timing partly depends
on the 1's for resynchronisation.) Therefore, MFM encoding is relatively
simple.

Since GCR puts the bits further apart, it does not have the problems
with 1's. It still does have the problem with 0's though, and of
course also needs some special code for SYNC to indicate the start
of a data block and so. So some kind of encoding is still necessary.
Since SYNC with GCR is 10 or more 1's in a row, it needs to ensure
that no data that is encoded can ever look like a SYNC. And also it
must limit the number of 0's in a row to at most 2. (I think).
There are in fact a number of different encodings that satisty these
conditions. In fact, the Apple-][ GCR encoding is different from the
Commodore-2040, 3040, 4040, 2041, 1540, 1541, 8050, GCR encoding.
(GCR encoding is also a lot more work than MFM encoding.)

I do have a 1541 ROM disassemble somewhere, so I could look up the
actual encoding.  (Unfortunately I don't have a ROM disassembly for the
2040 et al.  In those days I had not figured out yet how to access the
address space of the other processor. Could somebody help me to get
hold of one?)

>I mentioned this before and am surprised it received no response.  Perhaps
>what I am suggesting is way out in left field...   :-)

Unfortunately, yes. Although I don't know the expression 'out in left
field' ;-)
>(MSH-authors - any comments?)

You succeeded in getting a comment from the one that's on this net.

>David M. Pochron	    |  from Rescue Rangers, _A Fly in the Ointment_
--
Olaf 'Rhialto' Seibert                               rhialto@cs.kun.nl
How can you be so stupid if you're identical to me? -Robert Silverberg