🚀 go-pugleaf

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