Floppy Drive Interface Tinkering

You needed to be around 20-30 years ago, when floppy drives were new, and all the interface stuff was well known by hobbyists. And no, I cant help with the details, all that info is long gone. But I can tell you that reading bits off a disk is a *lot* harder than just digital. There were several different encoding schemes, all involving clock and data recovery from essentially analog signals.

--
Regards,

Adrian Jansen           adrianjansen at internode dot on dot net
Design Engineer         J & K Micro Systems
Microcomputer solutions for industrial control
Note reply address is invalid, convert address above to machine form.

Here's the floppy data extractor scheme I used 23 years ago on the OmniComp/GenRad portable testers....

...Jim Thompson

--
|  James E.Thompson, P.E.                           |    mens     |
|  Analog Innovations, Inc.                         |     et      |
|  Analog/Mixed-Signal ASIC\'s and Discrete Systems  |    manus    |
|  Phoenix, Arizona            Voice:(480)460-2350  |             |
|  E-mail Address at Website     Fax:(480)460-2142  |  Brass Rat  |
|       http://www.analog-innovations.com           |    1962     |
             
I love to cook with wine.      Sometimes I even put it in the food.

I used to work for PerSci designing testers for floppy drives. Those direction lines on your chart are ass-backwards.

On older style drives, the data comming out is digital with a recovered clock signal. You still have to detect the trick soft-header info with missing clock bits. If the drive is IDE, you get the actual data. Look up specs on the IDE interface, some compact flash memory cards also use this. You have a 'fighting chance' with a parallel port (or

2).

Luhan

Ye olde Shift-Register-Flywheel data recovery system.

I've used similar schemes for other synchronous data streams.

Luhan

Yep... a true PJL (phase-jerked loop :-)

...Jim Thompson

--
|  James E.Thompson, P.E.                           |    mens     |
|  Analog Innovations, Inc.                         |     et      |
|  Analog/Mixed-Signal ASIC\'s and Discrete Systems  |    manus    |
|  Phoenix, Arizona            Voice:(480)460-2350  |             |
|  E-mail Address at Website     Fax:(480)460-2142  |  Brass Rat  |
|       http://www.analog-innovations.com           |    1962     |
             
I love to cook with wine.      Sometimes I even put it in the food.

You sound like a fun guy. Like others have said, this is a lot harder than it looks. Perhaps you can go visit some of the newsgroups dedicated to old home computers, like comp.sys.cbm. There is a wealth of expertise on these kinds of things.

You might want to download the service manual for the Commodore 1581 floppy drive. This was a 3.5 inch external drive with its own CPU. (The Commodore peripherals were daisy chained on a serial bus and were intelligent). This drive, unlike Commodore's earlier 5.25 inch drives, uses a more or less standard PC-style mechanism, so you can at least learn a bit about the 3.5 mechs.

1) The original IBM spec did not define or use pin 2 or pin 34. 2) Pin 2 for density i would think would exist on the 1.44Mbyte 3.25 drives to *sense* if the floppy was 720K or 1.44Mbytes. There never would be a control to "tell" the drive what density it "should use"., as density is driven by the FDC which is in/on the motherboard (depending 286, 386, 486, etc). The same would hold for the older dual-density 5.25 inch drives (360K / 1.2Mbyte). 3) Pin 34 is something that seems to be added that was never needed, as the index hole would be sensed to indicate the presence of a floppy. If present, it would be *read* as one cannot "tell" the drive that there is a floppy in it with no regard to reality. 4) The INDEX remains used as that is (in a sense) how the FDC is "triggered" to start reading data on a track. Look at the metal disk on the bottom of a 1.44Mbyte floppy. That slot is used to drive it around and the driver has an aligned "index" indicator. 5) Look for a DATA line...there are two: one for read and one for write.

Gee, you could read darn near anything...

When the drives were cooked up, you basically would be doing things the way you describe. Because there were no fancy ICs to take care of it. All you need to do is look in Byte circa 1977, and you may find circuits to do what you want (I say may because it was right on the cusp, and if floppy drives became "cheap enough" too late, the process would have been sidestepped in favor of a more integrated IC solution. But I think Byte did have at least one article that amounted to a floppy drive from ttl parts.

Ohio Scientific used a USART for their drive interface, though that's all I remember. Note the "S", because they were using the synchronous mode. The USART collected the bits into bytes.

But fairly soon, ICs came along that did it all in one package, or almost in one package. Instead of using the CPU to control the control pins on the drive, they'd be connected to the floppy controller IC, which had a certain level of "smartness" to it. Th IC would collect the bits coming off the Floppy drive, assemble them into bytes, and then collect a full sector. It was so much better that once they existed nobody went back to doing it any other way.

Of course, Apple Computer did do it differently. Because in 1977 when they needed a floppy drive as an accessory, it did take a full board of ICs to do the deed. Steve Wozniak decided that if he stripped down the circuitry in the floppy disk drive, making the interface more raw, he could do a far simpler interface for the Apple II. Hence they had to have drives especially made (there is less on the controller boards than on the average Floppy drive of the time), but the interface board is simple, using instead the Apple's CPU to do most of the work.

Michael

Not to mention losing quite a bit of storage capacity due to the simplified interface.

--
Service to my country? Been there, Done that, and I\'ve got my DD214 to
prove it.
Member of DAV #85.

Michael A. Terrell
Central Florida

Looks like I ended up with more responses than I figured for such a short time, so I'll condense my reply to one post before I get behind.

I went and found the service manual to the Commodore 1581 and skimmed through it, which is starting to reinforce the idea that I'm probably going to need a floppy controller IC. In the case of the 1581, which runs off its own 6502 cpu, it uses the WD1770 controller. Since I own an old dead Atari 810 floppy drive (whichs runs/ran from a 6507), I dug up some schematics for it as well, and found it uses a WD1771 controller. Despite having not looked at the datasheets yet, I would assume these are nearly identical.

In the case of the Apple II though, I had always heard how Woz implemented such a simple controller based more around the main cpu, which is what prompted me to think I could use something like the parallel port in the first place, since it gave me the false impression that it was easy to work with a floppy drive. So much does one learn in a day's time which proves otherwise!

In things I've found since my initial post, and things written here, I have a somewhat better understanding of how it's done, at least. Though even if I did manage to put something together to read bits accurately from the drive, I still come across the problem of reading whole sectors. It'd be kind of pointless to have an interface which was incapable of reading any floppies I wrote elsewhere, after all. While from the programmer's standpoint we always see the sectors as 512 bytes (as far as PC floppy disks go), I'm sure there's probably some extra bytes for each sector for error checking, and I have yet to find any reference for what the structure actually is.

So again, it looks like doing all of this "manually" would require way more support circuitry than I'd have room for on a breadboard. Even using an IC might end up taking a bunch of space. But a quick glance through the WD FD1771 datasheet says it can handle 512 byte sectors, so I would assume this IC might be okay to read PC floppy disks, though I'm unsure how compatible it is with whichever was actually used in PCs.

The reason I mention using the 1771 is because I have that one available in the 810 disk drive as mentioned above, and unless by some small chance I got the drive itself going again, I'd be more likely to just remove the chip (and possibly some other components) for my own use, assuming it's not burnt out.

You saw a lot of interesting responses there, but I'm not sure you're started on your project yet :)

First, look at the "flywheel" underneath the drive. You'll see a tiny magnet glued to it at one point. This activates a Hall effect sensor somewhere on the board to generate the index pulse. Not all recording systems required the index signal; the Amiga, for instance, records its tracks at any old location relative to the index mark. The floppy controller reads the track into a RAM buffer that's bigger than the actual data size; software on the host computer located the actual start of the track and removed sync information.

You might find it instructive to put a 2-channel scope on the drive; hardwire the drive so it is in read mode, with the hub motor running. Put one channel on index, one channel on data out; trigger on index pulse. Observe.

If you want to talk to a floppy drive to read and write bits from standard PC-format floppies, the _easiest_ thing to do is to acquire an old "super I/O card" (FDC/IDE/2S/2P/1G typically) and use the floppy controller on that.

If you just want to use a floppy disk as [proprietary] storage, non-interchangeable with any other system, I suggest you look at the

15_4_1, because the GCR format it used is a lot simpler to work with (to my brain, anyway).

In its day there were two controller families being used.

Intel created one version (forget the number) and the WD family like the

1771 and 1793(double density).

The Intel version is the one used in PCs.

This chip is like the intel version and is still available:

This is all an interesting challenge, but really, why don't you devote your effort to something a little more useful - something that might even provide you with a marketable skillset? For example, learn about the USB bus and then how to get data in and out of a USB flash drive.

-- Joe Legris

Yep. But I had trouble getting it by the digital guru, because he didn't seem capable of understanding it. But management came down to my lab and watched as I swung a PSP tester back and forth as it continued to read without skipping a beat. Then I drug my thumb on the motor to slow it down, it kept reading. They signed off on it ;-)

...Jim Thompson

--
|  James E.Thompson, P.E.                           |    mens     |
|  Analog Innovations, Inc.                         |     et      |
|  Analog/Mixed-Signal ASIC\'s and Discrete Systems  |    manus    |
|  Phoenix, Arizona            Voice:(480)460-2350  |             |
|  E-mail Address at Website     Fax:(480)460-2142  |  Brass Rat  |
|       http://www.analog-innovations.com           |    1962     |
             
I love to cook with wine.      Sometimes I even put it in the food.

Back again! Thanks so far for the responses, as I'm slowly but surely wrapping my head around things. But since it's obviously a complicated matter, I'm back with some complicated questions.

I've found that apparently NRZI is used at the lowest of lowest levels, where apparently a binary "1" is indicated by a change in flux on the media, and a "0" is a lack of such a change, since the drive is apparently incapable of determining the actual "polarity" of the flux on the disk, only the changes in it, from what I understand. I did read in one place however that it was the opposite (0 = flux change, 1 = none), but like with most of this stuff, I can't seem to find any "official" documents to say otherwise. So for the time being, I'll assume "1" is flux change.

I keep reading tidbits that this method can't be used directly, possibly for a couple reasons. First, there's something about it messing up the "clock". What exactly can the data bits clock, and how can they clock it reliably, since unless your data was a repeating set of identical/similar bytes, the clock signal would fluctuate too randomly, wouldn't it? The second reason you supposedly can't use it directly is due to something about how you can't have too many magnetic fluxes too close together; I guess this would mean you couldn't have a bunch of "1" one after the other. This would create too strong a flux in one location? Though if so, what would the consequence be?

The solution(?) to the problem(s) was using encoding on top of that, and in the case of PC floppy disks, this is MFM. A "1" is encoded as "01", and a zero is encoded depending on whether it followed a "1"; if so, it's "00", and if it followed a "0", it's "10". The byte "10100001" should end up being "0100010010101001", which apparently ends up taking twice as many bits as the original byte. Again, I can't seem to see any means of using the bit stream as a clock from something like that. It would also seem that if you're using twice as many bits per byte, that if a disk were rated 2mb, wouldn't that mean you only end up with 1mb, or am I missing something?

Then on top of that, you have the track/sector structure, which uses some headers and sync marks and CRC bits and such. What I don't understand in this aspect, is whether these header bits (such as the sync mark) are encoded as MFM, or if these bytes are directly encoded to the drive. The sync mark supposedly breaks the MFM rules somehow, for some reason, but I just don't understand why or what it's for yet.

Hopefully I at least have a decent understanding of the stuff mentioned above, but as usual, I'm welcome to correction and any insight on the issues anyone can offer. Thanks again!

On the interface, It's not "1" or "0", rather, the signals used on the data in and out lines are short pulses. For the input line to the drive, these are generated in the computer's floppy controller IC. (This feeds the clock input of a T flip flop on the drive (or the LSI chip equivalent) to generate the acutual write current in the head). For the output from the drive, the analog electronics on the drive outputs a short pulse from a monostable for every flux transition, independent of the direction of that change.

Go back to an archive of this newsgroup (google) for the April 29, (2006) and read the thead started by Rene Tschaggelar about the floppy interface. I posted the numbers of several ISO standards that describe the floppy formatting. Also in my FTP directory are some of the datasheets I mentioned.

Look for the stuff added there in May, three files, I think.

Mark Zenier snipped-for-privacy@eskimo.com Googleproofaddress(account:mzenier provider:eskimo domain:com)

Floppy interface never did go IDE, not complicated enough.

--
 JosephKK
 Gegen dummheit kampfen die Gotter Selbst, vergebens.  
  --Schiller

Actually when 320Kb and 360Kb were standard Apple has 400Kb. Of course by then they were using FPGA tech in the FDD and FDC.

--
 JosephKK
 Gegen dummheit kampfen die Gotter Selbst, vergebens.  
  --Schiller