Raspberry Pi Gets PATA/IDE Drive Via GPIO Header

By and large, the Raspberry Pi is a computer that eschews legacy interfaces. Primarily relying on SD cards for storage and USB ports for further expansion, magnetic hard drives are a rare sight. However, [Manawyrm] decided that some 40-pin goodness was in order, and set to making a PATA IDE adapter for the platform.

To achieve the task of interfacing now-vintage IDE devices with the Raspberry Pi, [Manawyrm] elected to use the single board computer’s GPIO pins to get the job done. 23 pins are required, with 16 used for the data bus, with the rest dedicated to address lines, strobes, and other features.

The adapter is no speed demon, netting 800 KiB/s on reads and 500 KiB/s on writes with a Raspberry Pi 4. The main bottleneck comes from relying on libgpiod, which [Manawyrm] readily admits is designed for general IO tasks, not data transfers. Despite this, it’s still fast enough to play an audio CD from an IDE CD-ROM drive without skipping. A kernel build is required, however, as Raspberry Pis are unsurprisingly not configured to use ATA disks by default.

Obviously, more serious applications would substitute a dedicated USB hard disk adapter or give the Raspberry Pi a PCI-express (PCIe) card for sata drives instead, but that doesn’t discount the fun inherent in the build. While it may be slow, it shows that talking to PATA hard disks is actually quite straightforward when you understand the basics. Of course, if you want to do the opposite, and have your Raspberry Pi emulate a PATA disk, that’s possible too. Video after the break.

[Thanks to DosFox for the tip!]

36 thoughts on “Raspberry Pi Gets PATA/IDE Drive Via GPIO Header

    1. tekkienet just reminded me that that’s bits per second, not bytes per second as was usually the minimum unit used for quoting HDD speeds, so nasty slow, not sure you’d want to use it with any emulation, except maybe floppy images for 8 bit machines.

      Reminder though, slowass storage + fastass processor, relative to each other, means it’s an ideal situation for heavy filesystem compression, if you wanna actually use HDD like this on a Pi

      1. And this is exactly what most vintage systems did — sound cards typically had an analog input for the analog output on the CD-ROM drive, and passed the signal through to the pre-amp.

    1. On the dawn of the century, my boss had a CD-Drive on her car, wired to the battery. She wired the headphone plug to the car audio, got a 12V to 5V converter, and had digital audio on a time when CD audio on cars were expensive.

          1. Can confirm, used an old Creative IDE drive, with media controls and a headphone jack on the front, as a CD player in my van in high school. All I needed was power, which I also cobbled together an adapter for.

  1. You gotta quit running hardware from userspace my dudes. If you can write an IDE implementation you can learn to code a basic ( not compliant with expected APIs just /dev node ) driver.

    1. When bumblefucking around to test the viability of something in Linux, keeping it in userspace saves a lot of headache.
      After all, you’re acting like this is a released product and not just the mere proof of concept that it is.

  2. >netting 800 kbit/s on reads and 500 kbit/s on writes

    At those kind of speeds, you might as well run the whole thing on SPI. Use 74HC595 for latching serial write data and 74HC597 to convert reads back to serial. :P Or implement the whole thing in a CPLD along with state machine and take advantage of DMA to burst an entire block of data.

      1. Nah, you got around that on 16/32 bit systems until DMA mode 2 got common… and supported by both disks and i/o controllers/motherboards. Tide turned about when IDE disks got to the gigabyte range on the high end, but were 4 or 500MB on the same tech at lower end. You’d still suffer with that speed on low end clones though when they did crap like stick a 16 bit ISA I/O card into a P75 with PCI slots, dooming it to fall back to PIO mode 2 or something, which systems could still be found into later 90s.

          1. Aw dang, how did I miss that, probably because I expect it to be quoted in bytes/sec yah, slower than floppy ugh. Well unless you use a 1541 on a C64, then it’s like “yay speed boost.”

          1. Yes, now you’ve put me straight on bps Bps, it is much slower than any genuine hardware HDD interface combo I’ve played with in the past. I believe I saw as low as 90kB/sec on a big ole MFM drive, but that was as it came to me, system completely messed up and riddled with virii, after cleanup, low level format, redoing interleave and system reinstall it was up to a giddy 230kB a sec which was the slowest “best possible” speed I saw out of anything.

    1. Oh, why not “just” use some of those I2C i/o expander chips? My morbid curiosity wants to see the PATA interface wrangled over something that’s a wet noodle in comparison to the parallel interface.

  3. Author claims “800 KiB/s reading, 500 KiB/s writing speed”, so it’s kilo *bytes*, not kilo *bits*.

    Anyway, it may be slow, but I like it because it’s simple and versatile. It could be used on any platform with spare GPIO — think STM32 or a hypothetical unicorn PC with 3 parallel ports. Just like any other bit-banged interface (SPI over GPIO, parport over GPIO, UART over GPIO, Ethernet over GPIO etc.) it has its place.

    1. Yep – was wondering how you could play an audio CD digitally if it as 800 kilobits/seond read speed – as an audio CD requires 2 x 44100000 x 16 bits per second = 1.4 Mega bits/second (+overhead?) (Unless the CD was just being told to play internally and output audio via an internal DAC – as some CD-ROM drives did – and all the PATA interface was doing was handling playback control, rather than full bitrate audio data?)

  4. This is worth a look at, to look at the principles of operation and gpio wiggling, as I also have a collection of old drives such as ESDI, SCSI, SASI and a Fujistu Eagle which I’d like to mess around with.

  5. I think I’ll just stick to my USB dongle, even at like 10yrs old it has 40pin, 44pin, SATA3, plus a bower brick with all the needed outputs and was $20-30 a decade ago I’m sure I could likely get it for half that now on sites like aliexpress – Fun idea/Proof of concept, I just can’t see how practical it is for the time/money invested to make it

    1. Very, very bad. a USB 2.0 adapter would be at least 30x faster. (~30 MByte/s are realistic via USB 2.0, this does 0.8-1 MByte/s). It’s a nice proof of concept, but I really don’t recommend it for practical use.

Leave a Reply to ManawyrmCancel 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.