On 11/4/13 9:57 AM, Chuck Guzis wrote: Is this just to reduce the storage requirements to just the sector payload? The tradeoff then is the software and hardware resources for synthesis and recovery of the various fields of a sector as opposed to just treating the whole thing as a bitstream sitting in what looks like a recirculating shift register. The problem with the shift register approach is when do you save it? After every assertion and negation of the write gate? Every time the cylinder/head changes?

On 11/04/2013 10:39 AM, Al Kossow wrote: Several reasons, actually. First, the incoming data can be time-domain sampled and stashed away as short, longer, longest (t, 1.5t and 2t) for MFM, which is easier to encode or decode. Second, it does take much less storage. Third, the timing is less critical. Write is always asserted at the beginning of the sector data field, so it's easy to place write data correctly. Since the sector size is known, there's no issue with write-splices. Finally, since CRC/ECC is computed by the MCU, as well as any sector headers, data can be held in non-volatile memory in native (i.e. unencoded representation). That is, in non-volatile memory (e.g. USB flash drive), what you see is what you get. This is the way the inexpensive floppy emulators (i.e. Gotek) work; they use only 32KB of RAM for everything, which is how they can get several hundred floppy images on a single USB flash drive. What I used for my floppy emulation wasn't a shift register--I create a track image, using 2 bits per transition to denote t, 1.5t and 2t MFM timings, then use a simple table lookup to translate those values for the PWM generator part of the MCU. Going the other way, I use the timer "capture" to create a buffer of 2-bit values, then splice the received data into the track image at end-of-track and before the next index pulse is sent. It works very well for non-copy-protected floppy images. --Chuck