Floppy Disk Interfacing

Howdy folks. I've been looking into how floppy drives work again, interested in tinkering with them myself for fun in projects, but have some questions. I also wouldn't mind some confirmations/corrections of my info by folks who actually know about this stuff, unlike myself!

My basis for all of this is on the 1.44MB floppy for the moment, so correct me where necessary:

- Spins at 300RPM, therefore 5 rotations per second, or 200ms per rotation

- 500kbit/s data rate, therefore 2us per data bit

- Since MFM encoding is two physical bits per data bit, encoded rate would be 1000kbit/s, 1us per bit

- Since 1 rotation is 1/5 of a second, and the data rate is 500kbit/s, that would be roughly 100,000 data bits per track?

- At 100,000 data bits per track, that'd make a 1.44MB floppy capable of 2,000,000 data bytes (which sounds right?)

Now, even assuming this is correct, I have questions on implementation.

At 1us per MFM encoding bit, you'd need a clock capable of 1mhz to read the bits fast enough, right? But even so, I have a feeling that there would be sync problems, and have heard that a PLL is required for reading disks like this. PLLs are still a bit out of my league at the moment, but I always learn such things as I go along, so I might could figure it out if push comes to shove. If you had a PLL, I assume the clock would need to be much higher to be able to match up with the data rate from the floppy. I thought that an alternative might be some kind of a software-based PLL, if you had a microcontroller running fast enough in comparison.

What about writing to disks, though? I mean if you're reading from them, you usually have all the sync bits to help you align your clock with the PLL. But how would you align it with the disk rotation speed if the disk was totally blank, with nothing like that to sync by? Would the sync of the PLL also be tied in with the passing of the index hole of the disk?

What is the actual physical procedure of reading and writing to a floppy? I'm assuming that as long as the disk is in the drive and the motor is spinning, that the data line is constantly spitting out bits. What about writing? Do you pull the /wgate (?) signal to 0v, and then immediately start spewing encoded bits into the write pin? And by spewing bits, I mean toggling the pin high and low, since as far as I understand, it doesn't matter if it's physically high or low at any particular moment, it's the transition between the two that counts when reading/writing the floppy.

Are there any delay times you'd have to take into consideration, in regards to like how soon you triggered to write and the time you started sending out the data? Seems like it would be very hard to write into an individual track at a particular spot during a random write, considering how fast the disk is spinning and how close the bits are.

I also understand that you can't put too many bit transitions on the disk too close to one another, or they would create too large of a magnetic field in one area. Hence the need for encoding, such as with MFM. If you did this to every track on the whole disk though, would the magnetic field be noticeable? Like if you held a piece of metal near it?

I'm also curious if anyone knows where there are any technical documents on floppy disks/drives, PC floppy disk layout (the gaps and header and sync and all that), MFM encoding, etc. I'm having a hard time finding such things.

My reasons for messing with floppies ranges from simply learning, to using them for a fun way of storage in microcontroller projects, to being able to read in other older floppy disks for computers of which the drives have long since failed (like my Atari 800 drive). I just find tinkering with this kind of stuff to be more fun in many respects than Flash memory and SD cards. Probably because I grew up messing with it all.

Anyhow, I think that's all I meant to ask for now. I would very much appreciate any info and/or confirmations anyone can provide!

Reply to
FyberOptic
Loading thread data ...

The 177x used a fixed 8MHz clock; this supported 360k/720k formats, so

125/250 kbps.

The use of MFM means that the clock doesn't need to be particularly accurate, as you can't have more than 3 MFM bits (half data bits) without a transition. It just needs to be accurate enough to distinguish 1001 from

10001. For 720k, with an 8MHz base clock, each half bit would last 16 clocks, so you would reset the counter on each transition and sample at t=8, t=24, and t=40. This leaves a large tolerance for inaccuracies in clock frequency and rotational speed.

You read the sector headers to synchronise the clock, then start writing at the end of the header.

This is why you have to format the disk before you can write to it, and why there are gaps either side of the header and data, and why there's a big gap at the end of each track (the recommended 16-sector formats have two whole sectors' worth of padding at the end of each track, to allow for being unable to sync the clock during formatting).

Read the WD-177x data sheet. It doesn't cover high density (1.44MB), but the concepts remain the same.

There are "write splice" gaps between the end of the header and the start of the data, and the end of the data and the start of the next header. The header and data both begin and end with markers to allow the alignment to be correctly detected in spite of the timing differences which occur when switching from reading the header to writing the data.

It's not a question of absolute field strength, but how close opposing fields can be. This is partly a property of the magnetic coating, and partly a property of the size of the read-write head.

MFM encoding:

formatting link

GCR (used on classic Macs):

formatting link

FDC (floppy disc controller) chips such as the 8271 and 177x have data sheets:

formatting link
formatting link

The source code for emulators often contains useful knowledge about the corresponding platform's disk format(s).

If you want to recover old disks, just sample the raw bitstream from the drive's data-out pin and decode it in software on a PC. This will let you read disks from the Amiga (which used a normal PC-type drive but did most of the encoding and decoding in software) and classic Macintoshes (which used a variable-speed drive).

Reply to
Nobody

First up, thanks for the response!

m

in

Looking into PLLs, I found that CD4046 chips are pretty cheap. I've never used such a chip before as mentioned, but it looks somewhat straightforward, and much easier to implement than I originally expected. Do you think I could read a high-density floppy with just a

1mhz clock with something like that, since that's the rate of the encoded bits? I don't think the old CD 4000 parts could go much over 1mhz. I guess I'd have to read them into a shift register, then let a microcontroller grab them in chunks, unless I could actually read them directly by triggering interrupts at the PLL-corrected bit rate, as long as the microcontroller was running fast enough.

Also, would you have to let a whole track go by like at least once to get your PLL in sync, then read on at least the second pass?

r

What I meant though is how would you write formatting to the disk if the disk was totally blank? You'd have nothing to time it by. That's why I asked if maybe you sync up to the index pulse in such a case.

I just want to clarify something right quick in regards to how the floppy drive writes bits. I'm assuming you wouldn't send your MFM- encoded data directly out onto the floppy's write line with each clock. You'd have to keep track of the current state you were outputting on that signal, and every time your encoded data contained a 1, you'd toggle the state of the line (meaning sometimes it might be off even if the bit was a 1). Right?

Yeah I'm thinking it should be much simpler to capture data like that from those older disks, particularly due to the lower capacity and data speed required to get the data off of them. But I wanted to learn it all with a normally floppy disk first, since I can actually confirm the data to make sure I'm doing it right.

And thanks for the info and the datasheets!

Reply to
FyberOptic

On a sunny day (Thu, 28 May 2009 16:58:18 -0700 (PDT)) it happened FyberOptic wrote in :

I did the floppy drive interface including the PLL man years ago myself. ftp://panteltje.com/pub/fdc-1.jpg The PLL is not that hard, I used a 4046 :-) ftp://panteltje.com/pub/fdc-2.jpg Look up write pre-compensation. And I actually used a 8272 to make the packets, yes the same as the IBM PC. Except this was driven by a 4MHz z80 in polling mode (no DMA). Now there was some time critical programing :-) That PLL is very good, you could slow down the flop by braking it with your hand, and it would still read data. Sample and hold :-)

Reply to
Jan Panteltje

You need to allow for the missing transitions. I don't know off-hand how to do this with an analogue PLL.

The 74HC4046 is advertised as going up to 18MHz.

If you can generate a clock where the transitions always occur at the clock's rising edges, then you just sample the data on the falling edges (or vice-versa).

Alternatively, you can sample the data on a free-running clock which is faster than the data rate and do the rest in software. The ratio of the sample rate to the data rate determines how much jitter you can tolerate and the minimum number of samples. 1.5x is normally adequate.

No. Bear in mind that the headers and the data are written at different times, so their clocks will be out of sync. You need to be able to re-sync the clock to the sync bytes at the beginning of the header and data sections (that's why the sync bytes are there).

For formatting, you use a free-running clock. If the clock is fast or slow relative to the drive's rotational speed, you just get more or fewer padding bytes at the end of the track.

When you're writing sectors, the clock only needs to be accurate enough that you don't end up overwriting the following header, so you sync to the header data to get the frequency then run free while writing the data. When you're reading data, you're continually sync'ing to the data.

Er, I thought that this was handled by the drive, but it's been a long time since I last dealt with this stuff at a hardware level (or at all, really; neither of my current PCs even have floppy drives, although I'm sure I still have one in a drawer somewhere).

Reply to
Nobody

The way I did it back in '83...

formatting link

...Jim Thompson

--
| James E.Thompson, P.E.                           |    mens     |
| Analog Innovations, Inc.                         |     et      |
 Click to see the full signature
Reply to
Jim Thompson

The (relatively rare) Amiga 1.44MB drives ran at half-speed so that the Amiga's hardware didn't suddenly have to cope with a doubled data rate. This was a bit of a hack, and apparently reliability suffered a bit on certain brands of drives -- at a mere 150RPM, the flywheels designed for 300RPM weren't as effective in smoothing out the instantaneous fluctuations in rotational speed.

Personally, I'm amazed that (prior to their obsolescence) floppy drives could readily be had for all of $10... amazing you can make something that's fairly mechanical like that so inexpensively.

Although the $10 floppy drives, made of little more than bent sheet metal, never seemed quite as reliable as the older one that used cast blocks and other "beefier" mechanical techniques in their design.

---Joel

Reply to
Joel Koltner

That looks like a pretty simple/clever design! But without seeing a simulation of it working, I have a question or two. Particularly regarding the clock diagrams. Does the one at the top right indicate that SHAPED_DATA is a pulse of 2us for each bit? I'm also assuming that RCLK is being reduced to about 500khz as well. So if they're both running at 500khz, then I would assume this means the MFM has already been decoded?

Just in looking over that and thinking of how MFM works, it made me realize that one can simply drop the first bit of each bit pair (after using the first for clock sync of course), since only the second one represents the actual data. That had never actually clicked in my head yet. I guess I was somehow thinking I would need to decode both bits into a value, kind of like some of the higher RLL encodings might require.

Reply to
FyberOptic

Yes.

Yes. RCLK is now just used to sort.

I was opposed by the digital guru at GR. I won my case by swinging our portable tester around and over my head, with obvious motor speed changes, never missing a bit.

...Jim Thompson

--
| James E.Thompson, P.E.                           |    mens     |
| Analog Innovations, Inc.                         |     et      |
 Click to see the full signature
Reply to
Jim Thompson

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.