This forum can be used to ask questions regarding any hardware projects, correct? If not, I apologize in advance, but since this forum has a number of people who have designed hardware professionally, I feel comfortable asking my question here. Besides, the answers I get to my question here could be incorporated until my little 65816 project (still designing/balancing life, etc).

On the Vintage Computer Forums (VCF), one of my current projects I wanted to do was to create a Low-Level MFM Format Utility for DOS- mainly because I'm sick of programs not returning useful error code information when LLF inevitably goes wrong... MFM hard drives are among the most fickle of vintage hardware, IMO. Part of my application, I wanted to detect bad tracks after formatting by writing test patterns to disk, and seeing which tracks return an error. And that means I need to understand FM and MFM encoding, and how both of them remove the clock signal line.

Well, long story short, it turns out that in my Digital Communications class (Not bashing the class at all- professor was awesome, and there was a lot to cover.), going through my notes, I can't recall us going over the prerequisite to even FM encoding- Non-Return-to-Zero Inverted. Before I go on to MFM, I want to devise a hypothetical circuit that can decode an NRZI stream with a separate clock signal, put it into a shift register. I don't actually care where the NRZI stream comes from- just that the shift register's serial input is connected to the output of an NRZI decoder, and the shift register's "clock" is connected to the clock from the NRZI stream.

Like a real MFM decoder seen on controller ISA cards, I imagine this would entail two separate clocks (except in FM/MFM, the clock is recovered from a signal which carries both and clock data)- one strictly for the NRZI stream and shift register, and the other for any support circuitry attached to the shift register's parallel output, the latter which is shared with the microprocessor. To make this 6502 related, let's assume the microprocessor is a 65816 attached at to the shift register parallel output at 0x00:0x8000 (unlatched) .

NRZI is simple enough to understand- a transition at the leading edge of the current bit clock represents a logic 1, and no transition represents a logic zero. I even found a simple encoder/decoder circuit online. The issue I'm having with incorporating this little circuit hypothetically is that I have to somehow use a negative edge clock for the shift register, and I lose half the period for waiting for the transmission line to settle (more, if I use an inverter on the clock input to the shift register). Data therefore becomes ready "out of sync" with the NRZI clock, and I can imagine scenarios where the shift register is ready, but by the time other circuitry is ready to read the parallel output (i.e. leading edge of microprocessor clock), the positive edge of the NRZI clock has already elapsed, and the data on the parallel output is invalid. I do not know offhand if a shift register with latched output prevents this problem.

Since I'm dealing with two separate clocks, what is a good way to ensure that when the 65816 or other circuitry reads the shift register after 8-bits clock in, the output value from the shift register will not be invalidated by the NRZI clock positive edge by the time the settling time and leading-edge for the circuitry connected to the microprocessor clock has elapsed?

I hope a hurried answer will still be helpful.

I think you'll do better to concentrate strictly on FM and MFM (not NRZI). And be aware that, when you read the disk, your circuit must recover the timing information that's contained in the raw data stream. A PLL (Phase Locked Loop) is useful for that; it locks its operating frequency to that of the raw data stream from the disk (thus accommodating minor variations that the raw data stream is bound to contain). IOW, when you're writing to the disk, you get to set the tempo, as it were. But when reading, the disk is the boss. You need to go: raw data stream --> PLL --> clock input of the receiving Shift Register.

The challenge when reading MFM is that some of the transitions are eliminated, with the timing information partially implicit. (With FM it's explicit -- one clock transition every data cell.)

I'll stop there, fearing that if I go on I'll tell you something wrong (if I haven't already)! It's ages since I've thought about this stuff. If you PM me I can send you some doc I have here, just a few paragraphs. An online search could lead you to similar material (or better).

cheers
Jeff

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html

If you're intending to develop your own hardware to interface to a disk, then another common encoding format is GCR (group code recording).

For software, I think the MFM/FM encoding/decoding is usually handled by the hardware and not seen by the device driver software. Usually a format command is sent to the IC (eg 8272) that interfaces to the drive physically. The status registers of the IC have to be checked for errors.

_________________
http://www.finitron.ca

GCR was primarily used by Commodore in their 5-1/4 inch disks. The 1581 3-1/2 inch disk used MFM. No hard drive that I know about from the ST-506/412 days used GCR. It was either MFM or RLL.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

Apple is also famous for having used GCR in their floppy drives, along with variable-speed motors for their 3.5 inch drives. Their later drive controller ICs have a fairly complicated mode-switch sequence in order to work with both GCR and MFM disks (for higher capacity and PC interoperability).

Right...forgot about Apple (I never paid much attention to them).

GCR does have the distinct advantage of better disk space utilization, since the format can take advantage of the increased linear distance of the outer tracks to write more sectors. It just never caught on in the industry as a whole.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

Mmm, surely any encoding could use variable RPM to put more data on the outer tracks? GCR has the independent advantage of packing more data in a given number of transitions. So Apple's variable-speed drives had two advantages, and Commodore's GCR drives had one.
(The Amiga had the density advantage of track-at-a-time access)
Cheers
Ed