Connect with us

Floppy Drive Interface Tinkering

Discussion in 'Electronic Design' started by FyberOptic, Jul 27, 2006.

Scroll to continue with content
  1. FyberOptic

    FyberOptic Guest

    Hiya folks! Due to my constant need to do somewhat useless things just
    to see if I can, I decided I want to better learn the workings of a
    floppy drive by making a parallel port interface for one. I might also
    implement something like this in a homebuilt computer design I've
    played around with.

    First of all, there's a couple things I'm unsure about on the
    connector, so to the pinout! (Modern floppies
    would use the top pinout table, correct?)

    I think there's an error in the signal direction for DSKCHG. I would
    assume you read this pin, yet they have it indicated that you write to
    it, which makes no sense. The other thing I'm curious about is what
    the INDEX signal is for. I guess this might have been used for 5.25"
    disks which had that little hole in'em, and I don't even entirely
    understand what it'd use that for, but this seems to be a useless
    signal for 3.5" if this is the case, since they seem to be lacking such
    a hole as far as I can tell.

    Now for the meat of the matter. I thought I had the general idea of
    how the drive worked down, up until I started writing this post, then I
    realized I don't understand a lot more than I realized. I intially
    thought it went something like: enable drive select for the drive in
    question, enable the motor, set direction, step to track you want.. but
    then I realized, how does one actually READ the disk? I mean, I can
    step to the track I want, but how do I read off the bits of that track?
    I don't see any signals on the connector which could indicate anything
    I need to clock. The Drive Select, perhaps, but don't you have to hold
    this low for doing any seeking? Or do the bits come out automatically,
    in a constant stream, looping over and over? I'd assume that if it did
    spit bits out constantly, that this is where the index signal would
    come in handy, but again, I'm not even sure 3.5" disks can do that.

    I also can't seem to find any definitive reference for the actual
    signals needed for each pin, such as what signal to use for density
    select to force high-density disks, or what signal means which
    direction, etc. I found a reference at one point, but it wasn't
    complete, and considering the signals are active-low apparently, I had
    no idea if that person took that into consideration or what.

    What I thought would be something relatively simple has ended up a bit
    trickier than I thought, unless I'm just overlooking something simple.
    A good reference would probably help wonders, but it seems I only
    manage to find a lot of useless pinouts.

    Anyone with any insight on working with floppy drives would be
  2. 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.


    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.
  3. Jim Thompson

    Jim Thompson Guest

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

    ...Jim Thompson
  4. Luhan

    Luhan Guest

    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

  5. Luhan

    Luhan Guest

    Ye olde Shift-Register-Flywheel data recovery system.

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

  6. Jim Thompson

    Jim Thompson Guest

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

    ...Jim Thompson
  7. Guest

    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.
  8. Robert Baer

    Robert Baer Guest

    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.
  9. Robert Baer

    Robert Baer Guest

  10. 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.


  11. 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
  12. FyberOptic

    FyberOptic Guest

    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

    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.
  13. Guest

    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).
  14. Donald

    Donald Guest

    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:
  15. J.A. Legris

    J.A. Legris Guest

    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.
  16. Jim Thompson

    Jim Thompson Guest

    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
  17. FyberOptic

    FyberOptic Guest

    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!
  18. Mark Zenier

    Mark Zenier Guest

    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


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

    Mark Zenier
    Googleproofaddress(account:mzenier provider:eskimo domain:com)
  19. joseph2k

    joseph2k Guest

    Floppy interface never did go IDE, not complicated enough.
  20. joseph2k

    joseph2k Guest

    Actually when 320Kb and 360Kb were standard Apple has 400Kb. Of course by
    then they were using FPGA tech in the FDD and FDC.
Ask a Question
Want to reply to this thread or ask your own question?
You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.
Electronics Point Logo
Continue to site
Quote of the day