Ask HN: Anyone have a good solution for modern Mac to legacy SCSI converters?
Meaning attaching old SCSI drives to modern Macs, not putting SSDs into old Macs.
50 comments
GBSCSI and ZuluSCSI support “initiator mode” that can be used to either image an attached SCSI disk to a file on an SD card or provide live access to it over USB as a mass storage device—with better performance than the old USB 1.1 SCSI adapters too, which top out at about 750KB/sec.
They are still USB 1.1 however, so they won't be able to surpass that speed limitation over USB.
They’re not really designed to be adapters in that direction anyway; the more intended use is that you use it to image a drive to a file on an SD card, and then use that file with a GBSCSI or ZuluSCSI going forward.
The point is that you can do reads/writes to it on a super-faster SD card reader on your main system, and then also use it with the ZuluSCSI/whatever. USB long ago exceeded SCSI’s data rates.
Thanks, looking into this more now.
If the reason to connect them is to dump them, something like https://bluescsi.com/ in Initiator Mode might work: https://bluescsi.com/docs/Initiator-Mode
Than you, will look... I had been vaguely aware of it before but will look more seriously.
I would use a mac of the Beige G3 variety. They still had SCSI ports and can run a bunch of OSes. I'd dump to a BlueSCSI or make a network disk that can be read by a newer OS or host a share from a newer computer to dump onto (SMB, AFP).
Another good candidate for hardware is a Lombard Powerbook. Otherwise you'll need an adapter.
Another good candidate for hardware is a Lombard Powerbook. Otherwise you'll need an adapter.
If you just want to grab the data to put into a more useful format, as opposed to really needing to actually use them as drives on your modern Mac, you may be able to do it if you happen to have access to something that has a couple dozen GPIOs, works with 5V logic, and is running faster than 1 GHz.
An RPi would be perfect except they use 3.3V logic. There are ways to deal with that such as bidirectional level shifters, such as [1].
Anyway, if you can find such a system bit banging SCSI on the GPIOs should work. Heck, on the original Mac Plus SCSI it was partly bit banged and that was on an 8 MHz 68000 where each instruction took at least 4 clock cycles.
They used an NCR 53C80 SCSI chip which pretty much simply provided registers to read and write the SCSI signals, plus a little bit of logic to handle those few places where something too fast for bit banging was needed.
Looking at my copy of the SCSI 2 spec briefly, it looks like the only thing you might have to worry about is the spec requires at most 10 ns difference in propagation delay between any two signals between the two ends. If you needed to change multiple signals together and used some higher level interface that did them one by one that might be slow enough it would look like propagation delay to the other end.
That could be addressed by directly writing to the registers that control the GPIOs. On most system each register controls multiple GPIOs and you can change them simultaneously. With SCSI we'd be using enough GPIOs that we might have to write to 2 or 3 GPIO control registers, but that would probably be fine.
It looks like the next shortest maximum allowed time is 400 ns. Way too short for an 8 MHz 68000, but trivial for a Pi or similar.
[1] https://www.adafruit.com/product/395 or https://www.sparkfun.com/sparkfun-level-shifter-8-channel-tx...
An RPi would be perfect except they use 3.3V logic. There are ways to deal with that such as bidirectional level shifters, such as [1].
Anyway, if you can find such a system bit banging SCSI on the GPIOs should work. Heck, on the original Mac Plus SCSI it was partly bit banged and that was on an 8 MHz 68000 where each instruction took at least 4 clock cycles.
They used an NCR 53C80 SCSI chip which pretty much simply provided registers to read and write the SCSI signals, plus a little bit of logic to handle those few places where something too fast for bit banging was needed.
Looking at my copy of the SCSI 2 spec briefly, it looks like the only thing you might have to worry about is the spec requires at most 10 ns difference in propagation delay between any two signals between the two ends. If you needed to change multiple signals together and used some higher level interface that did them one by one that might be slow enough it would look like propagation delay to the other end.
That could be addressed by directly writing to the registers that control the GPIOs. On most system each register controls multiple GPIOs and you can change them simultaneously. With SCSI we'd be using enough GPIOs that we might have to write to 2 or 3 GPIO control registers, but that would probably be fine.
It looks like the next shortest maximum allowed time is 400 ns. Way too short for an 8 MHz 68000, but trivial for a Pi or similar.
[1] https://www.adafruit.com/product/395 or https://www.sparkfun.com/sparkfun-level-shifter-8-channel-tx...
!! This is oddly tempting. I was hoping someone had done this already.
Some level shifters like you suggest and perhaps something like this - https://www.adafruit.com/product/2264
Some level shifters like you suggest and perhaps something like this - https://www.adafruit.com/product/2264
This is what GBSCSI/ZuluSCSI are already.
Amazon has usb scsi adapters, I dont use apple devices, but i'd guess that would work. https://duckduckgo.com/?q=usb+scsi+adapter&ia=web
Hmm, what I see on Amazon is a lot of USB-to-SATA adapters, not SCSI. eBay has used, old USB-to-SCSI adapters, which is one of the options that's sometimes recommended.
Looking at "scsi to usb" on amazon.com, most of the options I see are SATA, IDE or even parallel printer port adapters, but nothing which allows a SCSI device to be connected to a USB port.
If you've got a mac with a pci-e slot, you can get a pci-e card off ebay and an appropriate stack of adapters to go from a modern wide cable to whatever you need? If you don't have a mac with a pci-e slot, borrow a desktop pc with a slot and go from there? If you borrow an old enough desktop with PCI you might be able to get an older scsi controller and skip a few chains in the cable adapter path.
Or using the bluescsi initiator mode to make a disk image seems not too badly priced either.
Or using the bluescsi initiator mode to make a disk image seems not too badly priced either.
I don't. One option I am considering a Thunberbold-to-PCI card expander, with a SCSI HBA card supported by or for MacOS...
This would be my recommendation as well. I use one for a 4k video card to go to external monitor. This specific card had people chatting on forums that it didn't work on M-series chips. I'm still on the last Mactel MBP, so it worked fine for me.
In the past, I've run other expanders specifically for SCSI devices mainly JBOD RAID enclosures. ATTO was the brand that we relied on. Couldn't remember the specific HBA though. Too many everything since now and then
In the past, I've run other expanders specifically for SCSI devices mainly JBOD RAID enclosures. ATTO was the brand that we relied on. Couldn't remember the specific HBA though. Too many everything since now and then
At least as of the last major macOS release, that will not work, because the PCIe LSI SCSI HBA driver doesn’t have the extra stuff needed to support external PCIe.
It’d be a pleasant surprise if Apple implemented that for macOS 26 but I wouldn’t hold my breath.
It’d be a pleasant surprise if Apple implemented that for macOS 26 but I wouldn’t hold my breath.
Interesting... What bothers me is that you'd think that with Mac Proc M2 having advertised support for "storage" cards and lots of PCIe slots, at least some SCSI HBA's would have drivers?
There are some Firewire SCSI adapters. Sometimes older Firewire tape drives have internal SCSI to Firewire boards. I've used them to with old SCSI CD drives.
If you need to connect them physically, I think you're blocked by HBA chipset support in macOS.
There is a path, but it's not what I'd call "good". Thunderbolt to Firewire to SCSI. It's a dongle Rapunzel and you're reliant on device enclosures for power.
May be better with a native PCI-e or PCI HBA and 700W power supply and a junker ATX Linux machine to provide network shares.
There is a path, but it's not what I'd call "good". Thunderbolt to Firewire to SCSI. It's a dongle Rapunzel and you're reliant on device enclosures for power.
May be better with a native PCI-e or PCI HBA and 700W power supply and a junker ATX Linux machine to provide network shares.
You could do "network shares" as in mount the filesystem from Linux and export over Samba/NFS/etc; it would probably also be possible to export the drive as an iSCSI device and mount HFS(+) filesystems directly from the Mac.
> May be better with a native PCI-e or PCI HBA and 700W power supply and a junker ATX Linux machine to provide network shares.
Agreed. Even if it's possible to get a combination of adapters to allow a SCSI interface to be attached to a Mac (and assuming the correct driver support is present), I think getting an old PC and an old SCSI adapter card may be cheaper.
Agreed. Even if it's possible to get a combination of adapters to allow a SCSI interface to be attached to a Mac (and assuming the correct driver support is present), I think getting an old PC and an old SCSI adapter card may be cheaper.
I considered the Linux box solution, and fear you're probably right, but it just feels like such a waste... for something that should be so simple with all this Mac Book horse power and Thunderbolt interfaces.
This post is about using a SCSI scanner but it seems to validate the SCSI->FireWire->Thunderbolt idea.
https://catspawdynamics.com/ultra-scsi-to-firewire-to-thunde...
https://catspawdynamics.com/ultra-scsi-to-firewire-to-thunde...
very much not on topic, but that reminded me: my first PC (286) miraculously had a 40MB 2.5" Apple-branded HDD connected via SCSI adapter. Who knows where it was sourced from. One weird thing was that it initialized on boot for about 40 seconds, displaying nothing. I've been really surprised later seeing how fast other PCs with ATA drives were to boot. I still wonder, and maybe someone has a clue why init was so long? Is it something inherent to SCSI?
Nothing to do with SCSI itself, possibly a long time out polling for devices. Some dumb firmware would do silly things like poll each possible target ID and wait for a timeout in series. 6 possible devices on an old early SPI bus times a 5 seconds each is getting you in the neighborhood.
Having flashbacks to troubleshooting bus termination on DEC equipment.
Having flashbacks to troubleshooting bus termination on DEC equipment.
For contrast, I had an Amiga with a 120MB Maxtor SCSI drive, and power-on to looking at the loaded Workbench GUI was about 6-7 seconds. The slowest part was waiting for the drive to spin up, which seems like an acceptable reason for a delay. Warm reboots were a few seconds faster.
So no, that's not anything inherent to SCSI. It could've been either the SCSI driver being slow to initialize, or the adapter being glacial, or the drive itself taking forever to come online.
So no, that's not anything inherent to SCSI. It could've been either the SCSI driver being slow to initialize, or the adapter being glacial, or the drive itself taking forever to come online.
It depends on the scsi driver; it’s possible that it was checking/enumerating the 6 possible SCSI ids and waiting 5 seconds each.
Neat! Well, SCSI is more complicated (than IDE of the times) and the drives themselves are smarter, but that still seems like a long time.
I've been 10-11 at the time, and half the games I had didn't have an obvious "quit" menu option. I hated pressing the hardware "reset" button because it meant waiting for a minute again, staring at the BIOS setup screen.
Every time I figured out a weird hidden keyboard combination to exit from yet another game was a happy day.
Every time I figured out a weird hidden keyboard combination to exit from yet another game was a happy day.
How well did you terminate the scsi chain?
I was a kid without any PC anywhere in 40miles around me, had no idea that SCSI had to be terminated or anything. I don't remember any jumpers on the drive, though.
A lot of SCSI devices can be jumpered to self-terminate.
Surely you mean 3.5"?
nope. it was in a 3.5" bay in my standard AT box, but it was smaller, on some massive rusty metal adapter. It looks like it was from some early apple powerbook.
I've got my computer second hand from some rural school accounting department in south of Russia, circa 1994. Who knows how it got there. And who got and wired SCSI adapter compatible with ISA bus in that box.
I've got my computer second hand from some rural school accounting department in south of Russia, circa 1994. Who knows how it got there. And who got and wired SCSI adapter compatible with ISA bus in that box.
Here's a solution to the opposite problem: https://bluescsi.com/
not even opposite, as mentioned in my comment it does have Initiator Mode, allowing it to act as a host
It does appear that MacOS still ships with SCSI drivers and that there people actively working on updating them to DriverKit - this is an interesting thread from last month (Dec 2025)
https://developer.apple.com/forums/thread/807791
This seems to be about SAS (serial SCSI) however.
This seems to be about SAS (serial SCSI) however.
The SCSI protocol driver on macOS is there mostly for USB devices speaking the enhanced storage protocol and similar use cases. That’s how a USB-SCSI adapter from 1999 actually still works on modern macOS.
The PCIe SCSI card driver on macOS is for LSI32032 and related cards, and at least as of last year’s release only works on an internal PCIe slot on a Mac Pro, not in a Thunderbolt-connected slot in an external PCIe enclosure. (Apple “just” needs to implement some extra functionality to support them in external slots, but they no doubt have lots of competing work to do.)
The PCIe SCSI card driver on macOS is for LSI32032 and related cards, and at least as of last year’s release only works on an internal PCIe slot on a Mac Pro, not in a Thunderbolt-connected slot in an external PCIe enclosure. (Apple “just” needs to implement some extra functionality to support them in external slots, but they no doubt have lots of competing work to do.)
Use any other kind of PC with an expansion bus to dump the blocks to a modern block device, then attach that to the Mac.
I used to be an Apple service technician. We kept an old mac that had SCSI in an expansion port and Ethernet in another for precisely this reason.
I once transferred all 20MB of a Mac Plus hard drive, an author’s lifetime work, to a new iMac with this method.
I once transferred all 20MB of a Mac Plus hard drive, an author’s lifetime work, to a new iMac with this method.
That's pretty delightful, to think of someone using a computer as such a pure tool like that (as opposed to a distraction machine as is so often the case).
I like to imagine the author finally hit the limit of the 20MB hard drive, then decided, "you know what, rather than put 2 spaces after periods, I'll replace them all with a single space like the kids do", saving 400KB, and making room for at least a couple more weeks of work while shopping for a new computer.
I like to imagine the author finally hit the limit of the 20MB hard drive, then decided, "you know what, rather than put 2 spaces after periods, I'll replace them all with a single space like the kids do", saving 400KB, and making room for at least a couple more weeks of work while shopping for a new computer.
Using ASCII RS as whitespace between sentences, and only converting it to space(s) for rendering, is the boss move.
https://github.com/PiSCSI/piscsi
Get yourself a board, raspberry pi, and set up a samba server.
Get yourself a board, raspberry pi, and set up a samba server.
This appears to be the opposite - "PiSCSI allows a Raspberry Pi to function as emulated SCSI devices (hard disk, CD-ROM, and others)"
My mistake, I thought initiator mode was a bit more feature complete.
https://github.com/PiSCSI/piscsi/wiki/Initiator-Mode
https://github.com/PiSCSI/piscsi/wiki/Initiator-Mode