An Arduino With A Floppy Drive

For many of us the passing of the floppy disk is unlamented, but there remains a corps of experimenters for whom the classic removable storage format still holds some fascination. The interface for a floppy drive might have required some complexity back in the days of 8-bit microcomputers, but even for today’s less accomplished microcontrollers it’s a surprisingly straightforward hardware prospect. [David Hansel] shows us this in style, with a floppy interface, software library, and even a rudimentary DOS, for the humble Arduino Uno.

The library provides functions to allow low level work with floppy disks, to read them sector by sector. In addition it incorporates the FatFS library for MS-DOS FAT file-level access, and finally the ArduDOS environment which allows browsing of files on a floppy. The pictures show a 3.5″ drive, but it also supports 5.25″ units and both DD and HD drives. We can see that it will be extremely useful to anyone working with retrocomputer software who is trying to retrieve old disks, and we look forward to seeing it incorporated in some retrocomputer projects.

Of course, Arduino owners needn’t have all the fun when it comes to floppy disks, the Raspberry Pi gets a look-in too.

30 thoughts on “An Arduino With A Floppy Drive

    1. Yeah, this.

      Please, talk to someone into software preservation before giving bad advice in an article like “We can see that it will be extremely useful to anyone working with retrocomputer software who is trying to retrieve old disks”.

      The software preservation scene is moving towards flux-level dumps in order to preserve software, particularly copy-protected software. You can’t do that with an 8-bit Atmega, and sector-based dumping would be a marked step backwards in accuracy.

      1. Why so serious?

        Sure. If you have a floppy that you think might contain the long lost source code to v1 of some past decade’s hottest program or raw data feeds from Apollo 11 then yeah, get it to a professional.

        OTOH, if it’s just some old files the owner wrote as a kid and isn’t very sentimental about or some mass-produced common as dirt floppy based game then why do you care? Don’t get me wrong, Greaseweasle is more capable and is a great recommendation but for someone with discs that don’t matter and an interest in tinkering this might be more approachable.

  1. I did something similar with an Arduino Due, with a step stick to control the stepper motor for disks that had the donut come loose from the metal hub (3.5″ disks). Glueing it back made it spin off center. With microstepping the disks can still be recovered.
    Mine was entirely controlled by a Windows application and the arduino passed the flux data on through its high speed usb port. The main purpose was recovering as much data as possible, not so much as direct file access though.

    I’ve also developed a 3D printed cleaning kit that can be used to hold the door open and a turn tool to rotate the disk donut.

    There’s also an option (for really advanced users) to connect the Rigol DS1054z directly to the flux amplifier of some disk drives that has that signal available to tap into the analog flux signal to see if you can recover more data that way. It was interesting to see what a bad sector looks like.

    The windows application is still a bit buggy but if you’re interested here’s the github link, all the files including the stl files for the cleaning kit can be found here:
    https://github.com/imqqmi/FloppyControl

    All in all it renewed my appreciation for the storage standard. I’ve been able to recover more than 99% of the data from really dirty, crusty, mold infested disks.

    1. This is very cool! I had read people saying that discs started coming unstuck from the hub and thought they’d be unrecoverable but I guess not!

      How does the microstepping work? does it do multiple read passes with different offsets or something?

  2. Oooooh… that is seriously cool. In some corner of my heart I miss handling floppy disks. I recently was given a Sony Vaio 3.5″ USB floppy drive which I hooked up to my Raspi running OSMC. I use floppy disks for “headless” playlist selection now. “Unfortunately” there is not much information stored on the disks, so the reading noises are coming on just briefly ;)

  3. Since there is no “FDC” connected to this, one would think this could be another “greaseweazle” or “fluxengine implementation.

    Clearly, the flux data must be read and interpreted. Sadly, the arduino has not the bandwidth, nor the memory in order to do this.

    Nice use of tight assembly loops in C++ though!

    This might be a perfect thing to port to the Raspberry Pico. It has the RAM, it has the bandwidth, peripherals, [ the IO units are made for this! ] .

    Sounds like a good weekened project.

      1. It does *interpret* the flux data, but can not *store* or transmit the raw flux data.

        storing and sending the flux data requires far more bandwidth and memory than the arduino has available to it.

        still, an impressive project, no doubt.

        I’m a sucker for tight assembly code.

        1. Right. This project is pretty much the opposite of GreaseWeazle and FluxEngine. Those read and store the raw flux data from the entire floppy and then have software application interpreted that data. Great if you want to recover data from old floppy disks, but useless if you want to actually use the floppy disk as data storage for the Arduino.

          This project reads and writes data from the individual sectors making it perfect for building a retro computer. But it’s less flexible (no Amiga or Apple disks) or fault-tolerant so it’s not that useful for data recovery.

  4. This write-up seriously undersells the difficulty of getting a floppy drive to work on a plain Arduino:
    – Signals from the floppy drive are short pulses, not neatly timed high and low signals. This means you need edge-triggered logic to read them, regular GPIO reads will often miss the pulse. You’ll see in his design that he uses one of the few edge-triggered inputs on the ATmega: the Timer trigger.
    – Data on the floppy disk is encoded using MFM (modified frequency modulation). Regular FM encoding alternates between clock pulses (that are always there) and data pulses (that are there for a ‘1’ and omitted for a ‘0’.) Modified FM omits the clock pulse if there is a data pulse (a ‘1’) directly before or after. Old FDD controllers used a PLL to sync to the clock and then extracted the data stream directly based on the presence of a data pulse. But the Arduino doesn’t have a PLL. Instead it measures the time between pulses to determine the data pattern. And that distance could 1, 2 or 1.5 bits to really confuse things.
    – An ATmega328 doesn’t have enough memory to store the MFM sequence of an entire sector, so the pattern must be decoded while reading.
    – The data rate of a HD floppy is 500kHz, which sounds low for a 16MHz device but that leaves only 32 cycles to read and decode each bit. You’ll note that [David] has implemented the floppy interface in assembly while very carefully counting the number of cycles for each instruction.
    – … and much more fiddly floppy fun.

    I’ve been working on doing the same and didn’t quite get reading to work, so to see an implementation that does not just reading, but also writing, formatting, file handling AND a DOS completely blows me away. Very impressive!

    1. +1
      And folk typically don’t get that different drives spin at different rates due to calibration or even the same drive may at different times or rotation-angles due to temperature or aging grease… and that different sectors, even on the same track, may’ve been written or read at different rates… Thus the typical PLL.
      I don’t quite get how/if this project accomodates that, from the assembly. It looks like it might, but hard for me to discern.

  5. Sweeeet! (…with wide Kojak smile…)

    Now the Arduino brain not being a von Neumann architecture, this cries for a P code interpreted OS! A M1284 could be a nice start, a M2560 with some XMEM added even better to get some liberating amounts of RAM.

    Let me guess: Next goal is a UCSD like system? Some 16 to 32 Megabytes flash chips as permanent storage, maybe even make them hotplug-able, FDs for easy transfer to other systems, … a whole digitope might evolve!

    Is there a nice document somewhere about bootstrapping the UCSD-P system?

  6. @ Third
    +1, and i dont do that often

    first i learned arduino and looked into this, then gave up (using ONLY arduino library commands).

    i learned PIC assembler (@5mhz) and gave up, not enough SPEED, even in assembler.

    im learning AVR assembler, and i can see that this would-be a little more tricky then outputing WS281x using assembler @ 5mhz.

    there is a reason pretty-much all floppy controllers/interfaces use logic and not a CPU, because at one point in time, all PC-compatibles were LESS then the above-mentioned 5mhz (4.77mhz?)

Leave a Reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.