mcp@ziebmef.uucp (Marc Plumb) (05/02/89)
I posted a rather long explanation of magnetic disk encoding techniques to c.s.a a while ago, and while in Boston for Michael Tiemann's GCC seminar, I visited the MIT engineering library and fount The Book that explains it all. For the interested, volume 2 is most relavent: Magnetic Recording, C. Denis Mee & Eric D. Daniel. Keywords: Magnetic recorders and recording. TK7881.6.M24 1987 (3 volumes) ISBN 0-07-041271-5 (v. 1) ISBN 0-07-041272-3 (v. 2) ISBN 0-07-041273-1 (v. 3) Anyway, I now know how to write a 1,7 RLL code with a 2/3 information density, i.e. 2 data bits per 3 "raw" bits, giving 3 us per data bit, where MFM uses 4. This gives you 1.33 million bytes unformatted on a floppy, where MFM gives you 1,000,000. I'm going to do my file system (yes, now I'm home in Toronto and can actually work on it!) first, but this is a sufficiently interesting intellectual exercise that I'd like to figure out the feasability of the thing. At 0.2s per revolution and 2us bit times, there are 100,000 raw bits (nominal) on a track, giving 66,666 data bits. I'm wondering if I could fit 65536 data bits + header information (for 8K of *formatted* capacity per track, 10x128K = 1,310,720 bytes per floppy) in there, but I don't know the acceptable speed variations in a floppy drive. Does anyone else know how fast a drive can spin and still be considered acceptable? Also, the 2-to-3 encoding is computationally expensive, and I'm trying to figure out whether it's easiest to do with a few K of lookup table (1 byte -> 12 bits per step) or the blitter. I have a few ideas about making the blitter work, becasue the 3-to-2 decoding is nasty for the 68000. Reading over the blitter manual, however, I notice that the blitter block diagram illustration doesn't tell me what the inclusive and exclusive fill enables do. Are there any nifty hacks one can perform with them? Finally, the disk hardware. Is it capable of maintaining sync over a 14us period between 1's? Can it handle the increase in DC bias? And is there a reason the trackdisk.device currently avoids the DSKSYNC register? It looks like it would save quite a bit of data shuffling. Thanks for any info! -- -Colin
jesup@cbmvax.UUCP (Randell Jesup) (05/08/89)
In article <1989May2.114259.21058@ziebmef.uucp> mcp@ziebmef.UUCP (Colin Plumb) writes: >a track, giving 66,666 data bits. I'm wondering if I could fit 65536 >data bits + header information (for 8K of *formatted* capacity per >track, 10x128K = 1,310,720 bytes per floppy) in there, but I don't >know the acceptable speed variations in a floppy drive. Does anyone else >know how fast a drive can spin and still be considered acceptable? Specs are: nominal rotation time: 200ms. allowable variance in rotation speed: +- 1.5% allowable variance in system clock: +- 5% nominal clock speed + 2.5% So, maximum bits are nominal*1.015*1.05*1.025, minimum are nominal*.985*.95*1.025. Nominal bits are something like 6250*8*2 bits. >Finally, the disk hardware. Is it capable of maintaining sync over a >14us period between 1's? Can it handle the increase in DC bias? And I don't know. >is there a reason the trackdisk.device currently avoids the DSKSYNC >register? It looks like it would save quite a bit of data shuffling. Yes, it would: the trackdisk was coded before the feature was available. This is being corrected. -- Randell Jesup, Commodore Engineering {uunet|rutgers|allegra}!cbmvax!jesup