Every time I figured out a weird hidden keyboard combination to exit from yet another game was a happy day.
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.
Having flashbacks to troubleshooting bus termination on DEC equipment.
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.
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 once transferred all 20MB of a Mac Plus hard drive, an author’s lifetime work, to a new iMac with this method.
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.
Get yourself a board, raspberry pi, and set up a samba server.
Or using the bluescsi initiator mode to make a disk image seems not too badly priced either.
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
https://catspawdynamics.com/ultra-scsi-to-firewire-to-thunde...
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...
Some level shifters like you suggest and perhaps something like this - https://www.adafruit.com/product/2264
Another good candidate for hardware is a Lombard Powerbook. Otherwise you'll need an adapter.
This seems to be about SAS (serial SCSI) however.
sigio•6h ago
stmw•6h ago
ch_123•5h ago