You have probably all noticed by now that I’m out of stock of the Desktop BlueSCSI variant. This is due to a combination of working on Initiator Mode support for BlueSCSI hardware, and forgetting to order more of the previous PCB design.
What’s Initiator Mode and why is it kind of a big deal? I’m glad you asked.
Initiator Mode allows BlueSCSI to act as a SCSI Host device. You know how currently BlueSCSI needs a working vintage computer before data can be copied over? Your device (be it a Mac, PC, Amiga, whatever) needs to be bootable so data can be copied onto BlueSCSI. With Initiator Mode you can connect BlueSCSI directly to a target hard drive that needs to be backed up, configure BlueSCSI properly, and it will pull the contents of that drive directly into a disk image on the SD card. A bootable “host system” will no longer be required to take drive backup images.
Why didn’t BlueSCSI support this already? At first I didn’t think it was possible on the Pico stick given the number of additional GPIO signals it seemed to require.
The RP2040 microcontroller exposes several more GPIO signals than the Pico does, because the Pi Foundation used them for things like monitoring and power management. For example GPIO 24 monitors voltage input and GPIO 23 can be used to switch the RT6150 buck regulator chip into a lower power mode. Another pin (GPIO 25) controls the LED. And GPIO 29 is used to block leakage through the ADC3 pin when the 3.3v supply is disabled. So that’s a few GPIO pins gone already on the Pico stick. The Pi Foundation seems to have been desperate to stick to 2×20 pin headers, and they could have switched things around to expose USB over the headers but I digress.
So then how is it possible if we’re missing so many pins? Basically every pin which is connected to the SCSI bus does double-duty. They are all either an input and output signal, or inputs for two different signals.
How can a pin be both an input and an output? With resistors and the LVT/LVTH125 bus buffer chip, that’s how. A typical dual-function pin is structured like this:
This is an excerpt from the schematic showing the ACK signal. This signal when in “Target Mode” (acting like a normal hard drive) needs to be an input, iACK. And in Initiator Mode it needs to be an output. This configuration allows the input bus buffer to speak to the Pico pin (going off to the right) while also allowing the Pico to override that signal and drive the output as necessary.
As shown here, when oBSY is asserted (grounded, 0v), the iACK signal there on the left is buffered to the ack input signal pin through R67 shown above. And when oBSY is not asserted (3.3v) the state of the ACK line is determined by that output pin on the Pico. But wait, you say – you can’t just override ACK all the time! You’re right. This is why there are not one but two jumpers which need to be set to switch BlueSCSI into initiator mode.
One jumper switches which input line is being listened to by a certain GPIO pin (can’t just OR them together or they would collide and cause odd behavior, they must be separate). And the other jumper enables the Output ACK (oACK) signal.
The first production versions of Desktop BlueSCSI which support Initiator mode are in manufacturing now.