The Raspberry Pi Becomes A SCSI Device

SCSI devices were found in hundreds of different models of computers from the 80s, from SUN boxes to cute little Macs. These hard drives and CDROMs are slowly dying, and with that goes an entire generation of technology down the drain. Currently, the best method of preserving these computers with SCSI drives is the SCSI2SD device designed by [Michael McMaster]. While this device does exactly what it says it’ll do — turn an SD card into a drive on a SCSI chain — it’s fairly expensive at $70.

[GIMONS] has a better, cheaper solution. It’s a SCSI device emulator for the Raspberry Pi (original link dead, here’s the new location of this writeup). It turns a Raspberry Pi into a SCSI hard drive, magneto-optical drive, CDROM, or an Ethernet adapter using only some glue logic and a bit of code.

As far as the hardware goes, this is a pretty simple build. The 40-pin GPIO connector on the Pi is attached to the 50-pin SCSI connector through a few 74LS641 transceivers with a few resistor packs for pullups and pulldowns. The software allows for virtual disk devices – either a hard drive, magneto-optical drive, or a CDROM – to be presented from the Raspberry Pi. There’s also the option of putting Ethernet on the SCSI chain, a helpful addition since Ethernet to SCSI conversion devices are usually rare and expensive.

Officially, [GIMONS] built this SCSI hard drive emulator for the x68000 computer, developed by Sharp in the late 80s. While these are popular machines for retrocomputing aficionados in Japan, they’re exceptionally rare elsewhere — although [Dave Jones] got his mitts on one for a teardown. SCSI was extraordinarily popular for computers from the 70s through the 90s, though, and since SCSI was a standard this build should work with all of them.

If your retrocomputer doesn’t need a SCSI drive, and you’re feeling left out of the drive-emulation club, the good news is there’s a Raspberry Pi solution for that, too: this Hackaday Prize entry turns a Pi into an IDE hard drive.

Thanks [Gokhan] for the tip!

90 thoughts on “The Raspberry Pi Becomes A SCSI Device

      1. For some definitions of “better”. SCSI was a true communications protocol, while SATA/SAS are purely for storage. You could plug a few SCSI cards into your PCs and connect them to each other, transferring data at 80mb/s, at a time when 100mbit Ethernet was still new…

        1. You’re right. I had a SCSI optical scanner and a pen plotter back in the good old days. Up to 8 devices on a chain if my memory serves me. Termination was a bit of a pain, but not terrible once you understood it.

          1. i think my first cd burner was a scsi device. came with an interface card with this really fat ribbon cable.

            i think the thing i hate about sata is their choice in connectors. ive never had a scsi or ide cable wiggle itself loose and stop working intermittently or until you wiggle the connector. replace cables clean contacts every 3 or 4 months. ive had ribbon cables stay attached for years and function perfectly the whole time. worst standard ever.

          2. “Termination was a bit of a pain, but not terrible once you understood it.”

            You had to sacrifice an animal to the gods of SCSI to resolve the worst SCSI problems…


        2. This is how I had my Amiga and PC “networked” together as it was a far cheaper and faster solution than ethernet for the Amiga.
          Just file sharing. Downloading Amiga stuff via the PC.

      2. SAS: Serial Attached SCSI.

        As for using SCSI as a interlink, you would need a SCSI card that supported bus mastering, or a 3rd party device to perform half-duplexing.

        1. By definition all SCSI cards support “bus mastering” on the SCSI bus. Instead, you need a card that can act on a SCSI select command (i.e. can be set to “target” mode) instead of being a pure initiator. Most cards today can (either via special firmware or some command that sets them into target mode) but back then you’d have to have one of the more expensive ones (like Adaptec), because all others could only be used as initiator.

    1. Yeah, no. We’re better off without 50-conducter parallel cables, bus IDs, and the black magic of termination.

      I used Macs through the 90s, even Apple’s relatively user-friendly implementation was a mess of exceptions and gotchas.

          1. Every SATA device has termination built-in, like when you use Ethernet with 8P8C modular jacks. In the days of yore, like SCSI, we ran Ethernet over a single common bus which needed to be terminated at each end.

            The reason SCSI termination was a problem was always that people tried to be clever about it. Terminators in drives (which could be removed and should be in some cases, but could also be installed backwards if you weren’t careful), “intelligent” active terminators, etc.

            Give everything its own SCSI ID and make sure you terminate both ends of the common SCSI bus, but have no other termination in the middle. When manufacturers got “clever” they complicated the whole thing. And don’t even get me started on “SCSI Configured Auto-Magically”. Yes, SCAM, they actually called it that.

    2. What’s with all the comments about termination? Ok.. I never was a very big SCSI user. So.. I really don’t get the problem and would like to hear about it.

      The longest chain of devices I ever remember using was 2. It was no big deal, Plug the first device into the computer, the second device into the first device and the termination dongle on the third. Also, not really a termination issue but make sure the device id is set uniquely on each. How is that hard?!?!

      1. What if the computer already has one or more internal SCSI devices? What if you get 2 devices that have only single ports and always-on termination? What if you take a raw device that has termination enabled and put it into an external case? What if the enclosure is incorrectly cabled and has the two ports at one end of the cable and a couple feet of internal cable before going to the device at the other end?

        In theory, it shouldn’t be too hard. In practice, various manufacturers found ways to screw it up.

  1. Depending on the pi, this really does not sound like a steller cost savings. $40 for a high end pi, another bunch o bucks for an SD card for it.. And that is just the pi, not even getting into any of the glue. $70 for plug and play does not sound all that expensive.

    1. He used a Pi because he needed a buzzword to get his work featured here. Using a microcontroller for this purpose would be far cheaper and better (µC’s boot in less than a second, have fast GPIO pins, can use SD cards directly without prior OS installation and do not need a beefy power supply) than a Pi, though it would require much more effort and development to get it working.

      1. Or maybe he used a Pi because it’s much simpler, more powerful, and thus more flexible? With a Pi you can develop and debug the stack in place. Clearly a win in my book.

      2. “…It turns a Raspberry Pi into a SCSI hard drive, magneto-optical drive, CDROM, or an Ethernet adapter using only some glue logic and a bit of code…” [from the article}

        I want to see an article on “How to Turn the Raspberry Pi Into a Real Computer”, but I’m afraid no one, up to and including Eben Upton, would see the benefit in expending the resources required for such an undertaking. Consider: if it were easy, you would have already seen, long ago, such an offering from one of the Raspberry Pi entities (Foundation, Trading Company, etc.).

        1. “I want to see an article on “How to Turn the Raspberry Pi Into a Real Computer”, but I’m afraid no one, up to and including Eben Upton, would see the benefit in expending the resources required for such an undertaking. Consider: if it were easy, you would have already seen, long ago, such an offering from one of the Raspberry Pi entities (Foundation, Trading Company, etc.).”

          It costs about as much to outfit a Pi as it does to source a second-hand desktop, about $50 + keyboard/mice, monitor – the desktop being the much more useful option.


      3. And then you’d have to completely invent your own SCSI stack, which the Pi running Linux has by default. I’d rather bang out a board with a hand full of TTL than have to implement a protocol that spans THOUSANDS of pages. You whine about the cost, but how much is your time worth?

      1. The single-core CPU will probably be the bottleneck, since the whole protocol is software-driven, and SCSI has strict timing requirements that need to be met so that the other end doesn’t time out. That said, Gokhan mentions that he received some reports of his software working with a Pi Zero, so you might still get it to work somehow…

        1. How much a bottleneck? Those early SCSI devices topped out at about 5MB/sec. If the bottleneck isn’t that bad, Zero may be better for older devices like 68k Macintosh, Amiga, and others.

          If file transfer is all one needs to save data off old devices, SCSI ZIP drive and USB ZIP drive might be far cheaper. I see the 100MB drives on eBay for under $20 with a few disks, use SCSI on older devices, move disk to USB drive on modern computers, then sell the drives. Do be mindful that 250 drives can read but not write to 100 disk, and 750 drives are rare and probably more expensive than it’s worth.

          1. “How much a bottleneck? Those early SCSI devices topped out at about 5MB/sec.”

            Agreed. The computers we’re talking about have clock speed in the handful of megahertz range, while the Pi Zero CPU gallops along at what, something like 500 MHz?


          2. Well your doing all of the scsi in software and not dedicated hardware so 5mbs can actually be challenging as you would only have a handful of clock cycles to accomplish everything while still running an OS and all the peripherals

          3. The problem is not the throughput, the problem is the latency. The SCSI spec says that a device has 1.8 microseconds (that’s roughly 0.002ms) to detect that it has been selected (it sees its SCSI ID on the bus) until it must have answered that it is there and ready. Some other delays are even stricter (the lowest I can find right now for example is the Deskew Delay which is 45nanoseconds)
            And since Linux is not a real-time kernel, this is pretty hard to guarantee, since you always have other processes or kernel I/O interrupting your SCSI FSM. For Sync SCSI, is even harder.

            On a RT kernel I would agree that it’s no big deal. But on a general-purpose O/S, getting the timing right is tricky.

            There is a reason the whole SCSI FSM was silicon back then and not done via software (and since the FSM is so damn complex it’s also easy to see why SCSI was so expensive back then)

          4. Seagate at one time have ST01/ST02 SCSI card. They are just a tiny bit above your average latches. With exception of the arbitration and the bus handshaking, everything was done by software. The NCR5380 wasn’t much better.

          1. The problem is that Linux is not an RT OS and the small delays that the SCSI protocol requires (some as low as 45ns) are tricky to get right if you can get preempted basically at any moment ;-)

      2. Find a Pi Zero for $5. They are like unicorns. You hear of them but you never see them. A quick look at eBay shows about $24 for one, there may be one less expensive but not $5. And you still need a bunch of peripheral stuff. I mean if you have a pi that are not using and need to synthesize a scsi device that’s fine, but I don’t see this as being a steller cost saving.

        Don’t get me wrong, the pi’s are neat devices and really useful for some things, but they don’t fit everywhere and as far as I can tell, they have yet to meet their advertised prices.

    2. Well, there are multiple advantages of using a Raspberry. For example you don’t need to swap SD cards every time you want to change the SCSI harddisk, so you can actually put the RPi inside of your target computer for example. Then there’s the advantage that you can mount disk images or ISOs over a (wireless) network (you don’t need to store them on the RPi at all). Also, if you use an advanced filesystem like btrfs, you can easily shapshot your SCSI disk images (which is very helpful when testing/debugging old systems).

      Disclaimer: I own a SCSI2SD and use it extensively, and I designed something similar to what Gokhan did but on top of a BeagleBone. The hardware is finished, but the software still needs to be (re-)written (first I wanted to use the Linux SCSI target framework but that turned out to be awesomely complex so I’ll probably re-design it as userspace program)… I might take another look at the software part after reading this,

        1. Definitely, and it would probably also help with the lower-speed devices if they don’t have to submit to the <2µs bus selection timeout. I guess the tricky part is getting as much as feasible into silicon but keeping as much as possible in the software…

    3. Probably comes in a few dollars cheaper seeing as the SCSI2SD needs a microSD and cables as well. More flexible what with the Ethernet-over-SCSI, you could update your drives over WiFi, switch images from your IoT light switch/toaster/bidet, etc. And it’s homemade! Doesn’t that count for something anymore??

      1. “Probably comes in a few dollars cheaper seeing as the SCSI2SD needs a microSD and cables as well”

        Unlike the Raspberry Pi which ships as a complete solution, minus power source, storage device, and cables?


  2. Heh, I just bought the parts to do something similar with a Pi. I think I’ll try this, it looks easier then my plan.

    Good job on that, so many of the ancient devices out there these days are having their spinning rust break down, and this is a great way to keep the rest of the hardware operational.

    1. More modern Ultra SCSI drives may not be compatible with devices that have SCSI 1 interfaces though, like the X68000, FM TOWNS, Apple Macintosh (Plus, SE, II, et al), Sun SPARCstations, etc. Which was the point of this emulation! :)

      1. SCSI is a backwards-compatible protocol, any newer SCSI device should theoretically also work with older systems. The problem is more that you need to emulate specific (constrained) devices, like harddisks with 520 megabytes or less, or CD ROM drives that identify themselves with a specific vendor ID. You cannot do that with one of those plug-and-play converters, and that is the point why people want to emulate SCSI rather than use a simple converter.

      2. >More modern Ultra SCSI drives may not be compatible with devices that have SCSI 1 interfaces though

        I have a 4.3GB Seagate Barracuda plugged into an Apple IIGS. The only thing I needed to get it running was an 80-pin-to-50-pin adapter. IIRC, I set it up with three or four ProDOS partitions (maxed out at 32 MB each) and set up the remaining space as an HFS partition.

        AFAIK, the only SCSI devices that don’t play well with others are HVD devices, which I don’t think I’ve ever seen. LVD devices will fall back to SE mode, wide devices will fall back to narrow mode, and the signaling rate can fall back all the way to 5 MHz if necessary.

    1. I think you miss the point, this isn’t a way to use old SCSI technology with newer computers, it is a way to provide a n older computer an alternative device that is no longer available.

      Can’t you find a SCSI to Parallel, SCSI to USB, or SCSI to PCI adapter to use your older SCSI scanner with your modern-day computer?


      1. There are ways to connect 30 years old hard drives to modern computer. The problem is not solely in finding a way to interface SCSI but also disk format. Macintosh uses HFS and HFS+ format and those can’t be read on PC. There have been software that allowed Windows to view Mac formatted disks but this brings another issue: PC cannot handle 68k Mac’s resource fork. Mac files (document with embedded images, some PICT files, etc) are often stored as 2 separate file called data and resource forks. PC can only handle data fork so a lot of files would cause problem. I don’t know how modern PC can read Amiga or 68000 or other computer’s files but disk format will still be an issue.

        1. TL;DR: You probably would have to resort to emulation if you want to read the data without losing any of it, IMHO. Try online forums for enthusiasts of the platforms you’re interested in, I’m sure someone will be able to help you out (or at least point you in the right direction). If you can manage to dump the old hard drive to a file, you can then attach it to the emulator to access your files.

          I also found that Linux reads loads of weird/non-standard partition and archive formats, so it’s quite good if you need to extract files from these for some reason. One issue is if (like in the example you gave) you get a resource fork kind of thing with your filesystem, since Linux prefers a file-centric approach. But as I said, if you can get emulation to work, you don’t need to worry about any of this. Just install whatever software you used to originally create these files in the emulator, attach the HDD image, and you can start doing whatever it is that you need to do with your files.

    2. They make PCIe SCSI cards, I have one in one of my machines for my AIT backup drive. Though the big issue will be getting the specific scanner drivers to work.

      1. the SANE project has drivers for almost any old SCSI scanner that you can think of. I used it to drive an old Mustek 600dpi SCSI scanner some years ago and it worked perfectly…

      2. My 20 year old SCI scanner works fine with stock SANE drivers while hanging off of on an adaptec card sitting in Linux box running current lubuntu.

        Parallel port scanners, OTOH, are deprecated since the SCSI over parallel port support was dropped from the Linux kernel some time ago.

    3. It just emulates SCSI device. Not a host adapter just now. So, to use it still required to connect to a scsi host adapter.
      if PI can use SCSI->USB adapter, You use yor scanner in PI.

    4. No but why would that be any challenge at all?

      If you have a desktop just get a PCIE SCSI adapter.

      If not.. or if you have no PCIE slots open there are USB SCSI adapters. I’m not sure if they are really full SCSI or if they only implement what is needed to talk to a storage device like those shitty USB parallel port adapters that implement just what is needed to talk to a printer making them not good for anything else.

      If you want to go USB maybe you can try it and get back to us! Or maybe someone else here already knows…

  3. Timely project. I’ve been thinking about the best way to provide a SCSI drive for my x68000 XVI, now that the SCSI to IDE/CF adapters seem to have skyrocketed in price. I’ve been considering using a SCSI2SD (and may still do so for expediency’s sake), though I’ve been told there’s some compatibility issues with then by some folks over on reddit’s /r/sharpx68000.

    I like the idea of using a microcontroller for this as @localhost mentioned above in a comment, and as implemented in this awesome-looking project:

    Ultimately, I’d like to develop my own expansion board for the x68000 and include this functionality on it, hence my interest in a more microcontroller-centric solution.

  4. SCSI lives on in many ways. Others have mentioned SATA, but there’s also USB Mass Storage. I had to come to grips with the device end of that to get Orthrus working properly.

    1. You’re thinking of UAS USB Attached SCSI. USB originally only implemented bulk mass storage transfers. UAS was only implemented at USB v3 though it is backward compatible to capable USB 2.0 devices.

  5. I’ve had a SGI Indigo2 sitting in storage for years because I couldn’t find a compatible optical drive. It came from a university surplus auction, had the HD and monitor but nothing else. When I got the 13w3 cable for the monitor (pre “amazon sells everything” era) I thought I was golden. But of course they had wiped the drive clean. And the NIC wasn’t playing nice, so netboot didn’t work.

    Guess I should throw one of the Pi at it, now. Or port this to a teensy. Or . . . well, maybe I should make sure the Indigo is still where I think it is.

  6. I loved Scuzzi peripherals with my C64 and Amigas. But, the devices got harder and harder to find. The biggest failing of the SCSI was cost. Apple and Commodore printers, drives, etc… Cost more because the SCSI devices had to be smart. “IBM compatible” peripherals cost less. As the price of the many MS Dos computers dropped they became more popular. IDE devices cost less because they were “dumb”, controlled by the computer, not the device itself. IDE devices became more popular, even though they were harder to install. IDE survived and SCSI died. Survival of the fittest does not mean survival of the best.

    1. “IDE devices became more popular, even though they were harder to install.”

      Harder to install? ‘Configuration’ of an IDE drive consisted of nothing more than setting ‘Master/Slave’ jumper correctly, while SCSI had termination, device ID selection.

      SCSI was harder, but neither was really ‘hard’ to configure/install IMHO.


      1. I think he means “harder to coerce into working together”. I had tons of IDE drives that would not work as master with a specific other drive as slave, or vice versa, or which wouldn’t work as slave at all, or which couldn’t do DMA (only PIO) when configured as slave devices, or which didn’t spin up when another drive was present on the IDE bus, …

        1. I mixed and matched a whole lot of drives back in the day. I made a lot of PCs from old parts from different eras and manufacturers that were never expected to work together.

          I didn’t have these kinds of problems.

          That being said, most drives did not have two jumper positions, master & slave… most had at least 3. There was master, single and slave. Some had a second master position, if the drive doesn’t like the slave you are putting it with or vice versa try the second master position and things usually would get better. Also.. I write position, singular, but often two or more jumpers were actually required for a given setting.

          With the older drives, positions were not always labeled, you needed a reference to look them up. In our shop we had this little reference book that was probably only about 3″ x 4″ yet a whole inch thick with tiny writing and tons of archaic computer parts info. They sold them at the local universities campus book store.

          The same book also had BIOS settings. With such old drives (and sometimes old motherboards) the autodetect did not always work right so we sometimes entered a drives sectors, heads, etc… all manually.

          Anyway.. I say we didn’t have those problems because in the end we almost always got stuff working. That little book really made the difference!

          I kind of miss those days. The challenge was fun. Computers were still pretty expensive but we could build useful ones cheap by mixing and matching parts from computers that were already getting too obsolete to be useful. Mostly this was done to fill the office or for friends, we could have made a killing selling them though!

          To this day I have more than a lifetime’s supply of computer screws all which I carefully sorted by size, shape and thread, removed from the cases of various old computers I disassembled to get various drives, expansion cards, etc… but discarded the bulk because the case could not fit a standard size/shape motherboard.

          1. Remember, this was all before ATA drives were common and IDE was the standard. Some issues are described here for example: Quote:

            “As long as one drive is jumpered as master and the other as slave, any two IDE/ATA/ATAPI devices should work together on a single channel. Unfortunately, some older hard disks will fail to work properly when they are placed on a channel with another manufacturer’s disk. One of the reasons why drives don’t always “play nicely together” has to do with the Drive Active / Signal Present (/DASP) signal. This is an IDE/ATA interface signal carried on pin #39, which is used for two functions: indicating that a drive is active (during operation), and also indicating that a slave drive is present on the channel (at startup). Some early drives don’t handle this signal properly, a residue of poor adherence to ATA standards many years ago. If an older slave drive won’t work with a newer master, see if your master drive has an “SP” (slave present) jumper, and if so, enable it. This may allow the slave drive to be detected.

            Drive compatibility problems can be extremely frustrating, and beyond the suggestion above, there usually is no solution, other than separating the drives onto different channels. Sometimes brand X won’t work as a slave when brand Y is the master, but X will work as a master when Y is the slave! Modern drives adhere to the formal ATA standards and so as time goes on and more of these older “problem” drives fall out of the market, making all of this less and less of a concern. Any hard disk bought in the last five years should work just fine with any other of the same vintage or newer.”

    2. Actually, IDE devices were as “smart” as SCSI devices. The IDE controller hardware in the PC was the dumb part. I’ve seen IDE controllers that consisted of basically three 74LS chips (latches) and a few caps/resistors. The whole IDE controller was on the disk PCB

    1. I have; and to elaborate, old IDE was created by Compaq and donated to the public domain. It was only intended for two devices. Old SCSI was configurable for up to 8. A real wrestling match was getting an Adaptec host adapter (bus master type) to coexist with a Sound Blaster. The default configuration(s) stomped on each other. Even if you knew what to change, the motherboard may not cooperate as well.

  7. SCSI is not dead. All my SCSI hardware still works, just like it did in the 80’s, and 90’s.

    These days the worse problem is that I’ve got a pile of cables on my desk, and they’re all a different type.

    So I miss the fact that there was SCSI, and then .. well, just SCSI. (Except I don’t, because all the old SCSI hardware I have still works..)

    Which is great. So, I’ll personally be trying to build one of these rPi-SCSI devices, and will be tuning into various ways of keeping these old machines alive.

    (Incidentally, I can *totally* imaging popping rPiSCSI into a Yamaha A5000 sampler, and there-in unleashing very, very big demons…)

  8. Brilliant project! I’ve built the full version of this board and used it with the software from these guys to dump an old SCSI hard drive to the Pi. Using it as a basis for an interface to save scientific scanners from the knackers yard. If anyone’s interested, boards are available and I’ve translated all the comments in the software so it’s easy to see how it all works.

    1. Ooops! Didn’t have e-mail notifications switched on so didn’t realise there’d been a reply to my post.

      Have this fully developed now, mounted in a custom aluminum case with a GUI driving old (but still state of the art even though up to 20 years old) laboratory fluorescent scanners. Send me a message here and I’ll e-mail you the translated files and I’ve got quite a bit of extra info too. Plenty of spare PCBs available too.

  9. Would be also interesting, if we could connect the PI direct to the Zorro Bus or otherwise internal i.e. in a A500, without the need of a controller. PI will have to tell the Amiga, that itr is a controller and emulates a space of the sd card as the harddrive

  10. Being one of the probably few still using MFM hard drives, I can’t help but thinking the Pi probably could emulate these as well. Reading about this project and considering it’s ability to emulate a Motorola 68K CPU on the Amiga’s (I have one myself on the CDTV), it should “just” be a matter of designing an interface together with the software/firmware needed to do the translation.
    Or, perhaps it could even be used to store data from an MFM controller onto a SCSI drive… the possibilities are endless, hopefully the people with knowledge and will to do so are also out there somewhere… c”,)
    I’d buy one for sure! :-D

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.