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
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.
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.
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.
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.
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.
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
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.
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.
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.
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.
> 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.
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.
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.
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.
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.
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.
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'm fairly confident you could string it together as a scsi-to-firewire-to-thunderbolt chain, potentially with a TB2/miniDP-to-TB3+ adapter as well, but this seems even worse to me.
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.
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.
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 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...
!! 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
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.
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.
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
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.
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
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.
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.
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...
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.
> 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.
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.
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.
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.
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.
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.
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.
How well did you terminate the scsi chain?
A lot of SCSI devices can be jumpered to self-terminate.
Surely you mean 3.5"?
https://github.com/PiSCSI/piscsi
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
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
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.
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.
Using ASCII RS as whitespace between sentences, and only converting it to space(s) for rendering, is the boss move.
That is unfortunately the likely fallback... It just feels so wasteful and inelegant.
I'm fairly confident you could string it together as a scsi-to-firewire-to-thunderbolt chain, potentially with a TB2/miniDP-to-TB3+ adapter as well, but this seems even worse to me.