mostly associated with the inherent 180-degree phase ambiguity in MFM data recovery. Since it's an F-(3/2)F code, it has, inherently a phase shift between the time-locus of the "ones" clock and the "zeroes" clock. The ones clock occurs whenever there's a one, but the zeroes clock doesn't occur on the first zero following a one.

This is actually a misleading, though standard, way of looking at MFM, since what it represents is what's on the cable rather than MFM itself. If you have a good simulator available, then you can generate MFM in its raw form quite simply by generating manchester code and then dividing it by two, i.e. feeding it into a 'T' flipflop as the clock. The resulting signal will quite accurately be the MFM encoded data as it is driven onto the heads of the disk drive, i.e. it will change sign each time there's a transition in the MFM stream. What's on the cable is what you'd see if you drove that data pattern into a "bidirectional" one-shot, e.g. 96S02, which, if you've looked at OLD, in fact very old, floppy and hard disks, you've seen from time to time.

I've never understood why MFM was chosen as the cable-interface modulation as opposed to the much easier to generate and interpret Manchester code, but here we are.

If I were building a floppy disk encoder, I'd be inclined to use Manchester encoding, since it's very easy to use. Also, it will produce precisely the same flux reversal pattern and density that MFM will generate, despite the fact that Manchester code has two transistions per bit, while MFM has somehwat fewer than one. The effective "differentiated MFM" that the bidirectional one-shot contributes to the MFM stream is easy to generate, too, but the fact that you have to emulate a "genuine" data stream as the host controller, presumably the device with which you're going to interface in your FDD emulation, may not tolerate that.

The 32 MHz '320 will yield an 8 MHz execution rate, won't it? How well will it allow you to synchronize with an external process using the mode-0 serial port? (It does have two serial ports, doesn't it?) You may find it more "friendly" to your task to use the Maxim/Dallas DS89C430 or one of its kin. It has a 1KB XRAM internally, though you may want external RAM anyway. What's more, it operates 4x as fast as the '320 from the same clock. Additionally, if you feed it an 8 or 16 MHz clock you have some additional flexibility as to how you operate the serial port with respect to your code. I haven't yet figured out how long it takes for the serial port interrupt to arrive, in bit times, and how long it takes to get "around the horn" in a loop that has to examine the bits sampled by the mode-0 port in pairs and interpret them based on the previous output bit.

What you must do, bit-wise, is exaine each bit in the context of the previous bit, and in terms of its relative phase. Since I'm not yet sure of exactly what you're going to be doing, I won't bore everybody with the nuts and bolts details at this point. If you are, in fact doing what I'm occasionally working on, then perhaps we can work through this. It will keep me focused on this, a freebie, and yet get it out of my hair, and perhaps get you a bit of benefit from (a) my years in the disk controller industry, and (b) the work I've already done.

Here's what I'm doing ...

I'm using a CF module to store the data that should be the disk drive. I talk to the controller as though I were a disk drive, and it talks to me as though I were one as well. It is a crystal-controlled device, but there are two problems that have to be dealt with. (a) no two crystals operate at precisely the same rate, (b) the controller will write-precompensate data under some circumstances. My application is for really old systems, from the '70's, so that's certain, while I'm not even sure that the 1.44 MB floppies needed write-precompensation.

The efforts that deal with write precomp correctly are not wasted on systems that don't require it, BUT, it's a bit of trouble you could avoid if you know for certain you don't need it. Getting rid of precomp is non-trivial in firmware, though hardware can deal with it. It just takes a lot of hardware, and I'd rather work that out in firmware if I can.

Perhaps you'll want to take this off the forum until we "get in sync." It's up to you, of course.

RE