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!]
I love the idea of playing a CD natively on a pi. Romantic.
Should be fine speedwise for 486 era and classic Amiga era emulation. Don’t think you’ll be wanting to put your swapfile on there though.
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
Heheh, and now we’re back to kilobytes/sec as original source WAS bytes not bits and article misquoted.
But old IDE CDROM drives had volume controls and audio output. So the computer only had to control the drive, not take the digital signal and process it
You are confused. You could use the built in dac in the cdrom to play music and use the hardware control to control it but that was analog audio.
All audio has to become analog at *some* point, unless you’re feeding a teleloop… :D
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.
On some cd-rom you had the play stop, skip forward skip reverse control switches too
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.
Most likely was a SCSI drive jumpered to test mode which enabled them to play audio discs with nothing but the drive and a power supply.
Many IDE drives could also do that when not connected to a computer.
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.
This does have potential practical applications. If you haven’t got a pata adapter this could help you in a pinch!
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.
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.
This one manages a pretty good 44MB/s:
https://github.com/fenlogic/IDE_trial
Cutting away layers of abstraction really does help.
And how exactly does your comment relate to this project implemented as kernel driver?
>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.
BTW those are the kind of speed I would expect from 8-bit microprocessors trying to access 16-bit PATA port back in the 80’s.
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.
It is listed specifically as *bits* not bytes per second and not a incorrect lazy person mistyping lowercase. i.e. 100k byes/sec and 62.5 k byes/sec.
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.”
I have seen better than 100k Byes/sec even on old RLL drives on my amiga. (remember Palomax?)
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.
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.
Totally agree :)
That was the first idea for this project, actually. You can find it here:
https://github.com/manawyrm/ATAPIHat
(it uses SPI I/O Expander chips)
The result is very slow (~10 KByte/s if done well).
Wouldn’t PATA needs to be 5v tolerant? The reflection and rings can get very nasty on the old 40 conductor cable with not enough ground returns and no terminations. I think they only relax that for Compact Flash.
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.
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?)
The video on project page showing significant CPU load during playback suggests the digital audio was actually streamed.
Yes, that’s a small mistake in the article. The value in the GitHub readme is correct.
It’s KByte/s, not KBit/s. The data transfer speed is close to 10 MBit/s, so plenty for CD audio streaming.
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.
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
how would this compare to performance of a ssd plugged into a usb 2.0 to sata port adapter,
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.