Raspberry Pi Emulates An Amiga 500 Floppy Drive

[Maurizio] loves using his Amiga 500. His classic piece of hardware has been serving him well for years, except for the floppy drive, which recently gave out on him. No problem for [Maurizio], he just cracked his case open and added a Raspberry Pi as a real-time floppy emulator. [Maurizio] didn’t want to make any permanent changes to his A500 case, and more importantly he wanted to use the Amiga’s original floppy drive interface. The latter placed some rather stringent timing requirements on his design.

The interface hardware is relatively simple. Most of the circuit is dedicated to level shifting from the 5v Amiga 500 to the 3.3V Raspberry Pi. A 74LS06 Hex inverter converts the signals to the open collector outputs the A500 requires. [Maurizio] powered his Raspberry Pi from the floppy power connector of the Amiga. His model A Raspberry Pi works fine, but a model B would pull a bit more power (700ma) than the Amiga floppy power supply is capable of providing (550ma). The user interface side of the equation is simple: Two buttons, one used to switch disks, and one to “Write to SD”. Live disk images are stored in the Raspberry Pi’s ram, so the user needs to hit the “Write to SD” button to store any changes to disk before swapping floppies.

The software is perhaps the most interesting portion of this build. [Maurizio] is emulating a floppy drive in real-time – this means emulating MFM encoding in real time. Calls have to be made with a timing accuracy of 2 microseconds. The Pi’s stock Linux Operating system was just not going to cut it. [Maurizio] coded his drive emulator “bare metal”, directly accessing the Arm Processor on the Raspberry Pi. This gave him access to the entire processor, and allowed him to meet the hard timing requirements of the floppy interface.

58 thoughts on “Raspberry Pi Emulates An Amiga 500 Floppy Drive

  1. wow. this is amazing. I whould love to have the skill to do this for my c64. great job!

    now that I think about it, the c64 might be easyer. it communicates over a serial protocol, and relies on another cpu inside the drive. hmm, It seems I’ve got a new project! tnx!

  2. Outstanding!! An alternative to more expensive SD HxC Floppy emulator with more potential. Maurizio what would it mean to make it work with ATARI ST and AMSTRAD similarly to SD HxC solution?

    1. The SDCard HxC Floppy Emulator is a great piece of hardware. i installed one into an amiga 500 just few month ago. Could have done it without any modification to the case, but for an optimal usage i installed buttons and cut a hole for the display.
      The emulator itself is just plug’n play. Put the right file on your card and you can even controll the whole thing from the amiga itself. It’s not getting better than that.

      1. Because they are 100x overpowered for the task, it is.

        If you really want to talk power,
        (1) Amiga itself draws so much power that rPI is irrelevant and
        (2) this can be done with an AVR chip at 1/10 the pwoer cost of the rPI & 1/10 the hardware cost.

        1. do you get out a scalpel to remove the real mode circuitry from your intel chips?

          do you remove the back seat of your car when you ride alone?

          do you understand that $26 parts cost is irrelevant in a one-off build?

          do you understand that different engineers have different skill sets and parts on hand and use different paths to meet their optimal solution?

        2. No it can’t. Well, at least not with the AVR chips we normally see on Hackaday. Maybe there is some high-end AVR chip that can do it?

          The communication between a floppy drive and a computer is not the same as the uart serial or tcp/ip communication most of us are used to. If it takes time to calculate what you are going ot send the computer doesn’t just wait for you. There is no buffer that just waits for you to fill it up as you get to it. Either you send the data at the precise ms it is expected or you don’t.

          Your typical Arduino an similar can’t possibly keep up.

          A more common way to emulate a floppy is to use a PLC. That avoids a lot of the waste in a RasPi such as the audio and video hardware yet it is most likely a more expensive solution. Also, RasPi comes with a LOT of community support.

          1. >No it can’t. Well, at least not with the AVR chips we normally see on Hackaday. Maybe
            >there is some high-end AVR chip that can do it?

            Semi-virtual_diskette (2001? 2004?) : PIC16C65b !

            Amiga Floppy Emulator (2005) : AtMega uC

            USB HxC (2006) : 128 Macrocells 16Mhz CPLD (here hooked to a Raspberry PI)

            SDiskEmul (2007) : 10Mips PIC18F -> Floppy EMulation + Display Overlay

            SD HxC (2008) : PIC18F

            UFE (2010) : PIC32

            (somes are probably missing in this list…)

            Also it seems that someone else have made a direct Raspberry PI Floppy emulation before :

        3. The Amiga floppy data rate is only 250k bit/s. If you throw in a CPLD to
          handle the timing critical stuff and use time compare/capture to handle
          raw floppy data, you have 60 or so instructions (for a 16MHz AVR) to
          push each bit. Not something that is impossible to do with a bit of
          hard work.

          You can go even further if throw in a data separator/state machine for
          raw MFM and use SPI for data.

          The biggest issue is actually having a big enough buffer in RAM to store
          and work on the raw data for a track. Going to a 32-bit processor that
          have a lot more onchip memory and DMA come free for pushing data.

          1. That’s why I love Raspberry PI! Anyway, it’s not a single stream of SPI data… it’s a little bit more complicated… not easy how to go on Mars, you have only to put some more fuel and more food, isn’t it? :D :D

          2. I hope you program better than you maths… 2us per cell means 500kbit stream…. but the requirements are not the data stream, but the response to the control signal which is less then 400ns… so no, an avr 16mhz can’t do it WITHOUT other hardware (and other money)… and why should I use avr instead raspberry ? the circuit was too easy? Anyway, this “floppy drive” is not a new device, it’s just the way it works, and it works, that is new… :D (See the 3 gola of this project…)

          3. FYI: Double Density data rate is 250k bits/s not 500k bits/s.

            This blog has done a bit of RW on the raw Amiga floppy data.
            >The DD pulses should nominally be 4us, 6us, and 8us apart before
            pre-write compensation.

            The “2us timing” on the RPi is probably referring to the timing offsets
            due to precompensation. Using timer capture/compare, the resolution can
            be dialed down to the AVR clock cycle.

            The control signal stuff can be done with simple 74XX gates just like
            the extra logic chip required to mod a PC floppy drive to the Amiga
            drive back then.

            Even the RPi has RC time delay done in the 7406 gates. What sane
            engineer would short change and restrict him/herself to a “software”
            only implementation? There is nothing wrong about COST optimizing a
            design into hardware/firmware as each side complement the other.

            RPi costs about 10X of ATmega chip. One could BUY a CPLD/FPGA or two for
            the cost difference. If you have a CPLD that decodes/encode raw floppy
            MFM data, you could use SPI. A digital data separator isn’t that
            complicated and can fit inside a CPLD quite easily.

            Not like I would go the ATmega path as a $3 ARM chip is what I hinted in
            my last paragraph.

        4. Not everybody has a fetish for minimal solutions, and some people are trying to Do A Thing rather than create an objet d’arte. Different goals, different priorities, different resources.

          Honestly, I feel like a lot of the “he/she could have done the same thing with ______” might be more about trying to show off than making an actual suggestion. “Yeah well I can play that guitar solo faster and on fire.”

    1. “Calls have to be made with a timing accuracy of 2 microseconds.”

      I don’t think he is going to get that from a typical hobbyist microcontroler. Sure, there are probably many much more apropriate devices out there but if you limit your hardware to things that are readily available in the hobbyist market and well supported in the open source community maybe a RasPi IS a pretty good choice…

          1. It’s not a new free product! It’s a “flopppy drive” invented years ago…. the “hack” is doing that with less hardware (and money) and much easier as possible, it’s quiet a useful project for Amiga fans and the guy of the project above seems create a prototype for reading, whlle I didi it simplier and working… (and writing too). It’s not something magical and it don’t want to be, it’s just a program and a simple hardare interface, you see?

    1. Oooh, the memories. Late nights working through assorted levels of Emerald Mines. An Amiga clone would be just the thing.

      There are PC clones out there, but they just don’t feel the same.Maybe it’s a joystick / controller thing.

  3. HI all,
    the point was using a Raspberry PI (I already have) to give life back to Amiga, a hobby I have once a month so I don’t want to spent much money (HxC is a top level solution but it’s expensive for my goal). So the main features are:

    1- it’s cheap (you can use Raspberry PI as xbmc player or linux pc if you don’t use Amiga)

    2- it’s really easy and fast to make for hobbyst (no need to solder on SMD…)

    3- it was really not easy to manage 4 drives (and 16 disks) at same time with real time requirements, so it was for me a good point (it isn’t a C64 drive…)

    If someone could do it with less money and with less requirements (of equipment too), I encourage him to do it! We Amiga fans will love it! The main reason I did it is because I found nothing other than HxC)… So my friend, the race is on :D :D

  4. Hey everybody,
    For this type of task use a cortex m3 or m0 (or m4), they are the “new” “8bit” mcu, and forget about avr pic and for god’s sake rpi. Just forget about it! A 30mhz cortex m0 comes under 2 usd (in larger quantities under 1 usd) like LPC81x , but there are tons of other cortex m0 even 48-72 Mhz under 2 usd (see lpc11xx they are 50 mhz parts needs typ 7mA (!!!) at 50mhz). M0 with larger flash (256k- ) are about 3-4 usd. But if you need more speed get a cortex M3 or M4, you got 120+ Mhz lot of features, and power usage about 50mA. There are tons of cheap dev boards out there.

    1. I ordered a few STM32F103C8T6 $2.73/each (free shipping) flying in on Pigeon
      post from China. They should be perfect for these type of applications: 72MHz M3,
      20kB RAM, DMA engine to move timer compare/capture and 12Mbps USB.

      Soldering fine pitch SMT parts is so therapeutic and relaxing for me. ;)

      1. Ah ah ah Fun is fun… I really injoy doing this project, learn and taking care of encoding, signal etc .etc.. Fun is the journey…. (and techtravel was one of my favourite reading starting this project). So good luck and enjoying this yourself ! ! I had another (stupid) idea for something else, hope I will show you in some weeks :D :D

      2. Anyway, before to speak you should be learn more and a lot… The 250kb is the throughput NOT MFM coded… but the data on disk buffer is MFM coded so you have to double it… In numbers (just to help your math) :
        a single track as at least 1088*8*11=95744 bit plus the fap
        they are sent in 200 ms so 95744bit/200ms= 478720 bit/s …

        For your project A strongly suggest to study a little bit more before buying stuff it will be just not enough….

        This is the difference between DIY Do It Yourself and SIY Say It Yourself. Anyone can say it will make this project with 2 transistor, but I have deep doubts and finally I don’t see other than nothing. Just read read read….

        1. I am not here to “steal” your 30 seconds of fame. You really need to
          tone down your negativity. It is counter productive for an otherwise a
          good technical discussion. You don’t need to put down people to get the
          points across.

          You got a working project and I only have an idea in my head for the
          last few years, so of course you would know more on this particular
          subject than I do.

      3. Not necessarily building anything. It is just an idea at the bottom of
        my project list for the past few years.

        See http://www.techtravels.org/amiga/amigablog/?p=56
        Scope picture top trace showing raw Amiga floppy MFM data.
        Scope X axis: 2us/division, so 2 grids = 4us

        It is 4us between falling edge. The pulse width/rise time is a matter of
        the characteristic of the floppy drive. I don’t need that part for
        figuring what the Amiga is writing for MFM data.

        What is important is _only_ the negative edge timing. (i.e. a flux
        transition) whether it shows up at the “clock” part or the “data” part
        of the bit window. So it is only a single falling edge timer capture event
        for what I have in mind even though it has “2” bits as you stated.

        1. it doesn’t matter how you generate it, the throughput is the throughput and for MFM specification of DD it is 500kbit, 2us per cell. The specification of floppy controllers tells that it’s not a negative pulse, it’s a low level and needs to be low for a while (some are low for 0.4-1.5us others 0.8-1.3 us…). I seen lot of this oscilloscope screenshots when I stared and after a while I had to make my owns too. While most of the software I tried don’t care about it, some it does (for instance the game James Pond II). I don’t know exactly how works their loader, sure lot of (old) games have deep customized, perhaps for some copy protection issue too. But in order to make the emulation as real as possible I respected this timing (and the others)… and it worked with every software I tried (and really a lot of games… and fun!!). But do in your project what you like to do, I will not blame you for what you’ll do, the goals of your project are different than mine (for example the “easy to build” goal really doesn’t fit with SMD soldering and microcontroller programming, this is what HxC project requires, and your too…)

        2. Since DMA and hardware timers take care of recording and play back down
          to the resolution of the hardware timer with very little CPU overhead.
          So recording/play back the rising edge timing for tricky “protected”
          disks is not a show stopper.

          If they can generate a 1.3us timing there, doing a 4us is no problem using
          the same DMA/timer tricks. So even real HD floppy data rate is no issue either.

    1. Just use the spi in master mode, for data capture and replay (mosi is for replay miso is for capture the clk doesn’t needed) . Can handle the data rate easily. Set your spi clock at 8Mhz, and use dma and double buffering. I think even 4 Mhz spi is enough (in that case you got 8 bit for 2 us ). It’s not problem if you are not sync with the mfm data, the oversampling will help

    1. Actually the same interface could be used as external. Here is the pinout of external floppy connector:


      Keep in mind the external connector has the lines SEL2 and SEL3, so it will be useful to use 4 drives emulation software. The external connector doesn’t have SEL0 lines, so if you want to emulate internal drive too, you have to disconnect the internal drive and connect by a cable SEL0 from the internal connector to the interface.

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.