Path: utzoo!attcan!uunet!mcsun!hp4nl!sci.kun.nl!cs.kun.nl!rhialto From: rhialto@cs.kun.nl (Olaf Seibert) Newsgroups: comp.sys.amiga.tech Subject: Re: Compression device Keywords: GCR trackdisk.device compression Message-ID: <2460@wn1.sci.kun.nl> Date: 19 Nov 90 12:46:19 GMT References: <291@geocub.greco-prog.fr> <1990Oct15.120046.15007@ericsson.se> <1990Nov16.215210.23026@daffy.cs.wisc.edu> Sender: root@sci.kun.nl Organization: University of Nijmegen, The Netherlands Lines: 57 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