Initiator mode imaging of IBM DPES-31080 – observation about read payload during STATUS phase

[fortiko]

Hello,

First of all, thank you for the BlueSCSI project — it’s been extremely useful.

While experimenting with initiator mode disk imaging, I ran into trouble with my particular setup. I want to stress that I am not certain this is a firmware issue, and it may also be related to my drive configuration (jumpers, termination, etc.).

I’m mainly sharing the observation in case it helps.

Hardware
• BlueSCSI v2
• Pico 2 W (RP2350)
• Firmware: I tried several (v2026.03.01, v2026.02.08, v2025.10.27)

Target drive:
• IBM DPES-31080 (1 GB SCSI hard disk)
• capacity 2118144 sectors x 512 bytes
• Drive total size is 1034 MiB

Power:
• The drive is powered from a NeXTstation Color PSU (only used as a power source).
• The NeXT system itself is not connected to the SCSI bus.

Behaviour observed

During bulk disk reads (READ(6) and later READ(10)), it looked like the drive started sending payload data while the initiator still decoded the bus phase as STATUS.

This caused BlueSCSI to treat the incoming payload byte as a status byte, which then broke the read sequence.

I added some debug logging and observed patterns like:

COMMAND: Read6
STATUS
(data appears)

Instead of the (probably) expected sequence:

COMMAND
DATA_IN
STATUS
MESSAGE_IN

Diagnostic workaround

As an experiment, I added a temporary workaround in scsiInitiatorRunCommand().

When:

bufInLen > 0
bufOutLen == 0
returnDataPhase == false

and the phase appears as STATUS, the code temporarily consumes the expected inbound payload before processing the final status byte.

This is clearly not intended as a proper fix, just a diagnostic workaround to see if the issue was related to phase timing.

The hacky patch is attached.

Result

With that workaround in place, the full disk imaging run completed successfully:

SCSI read succeeded, sectors done: 2118144 / 2118144 speed 2427 kB/s - 100%
Finished imaging drive with id 1

The final transfers were READ(10) commands and also completed successfully. Throughput during imaging was roughly 2.0–2.4 MB/s

Important caveat

I cannot rule out that this behaviour was caused by:
• incorrect drive jumper settings
• termination differences
• a peculiarity of this specific drive model

So I’m not claiming this is necessarily a BlueSCSI bug.

The workaround simply allowed me to finalise the imaging and helped narrow down what seemed to be happening.

Question

Has similar behaviour been observed with other SCSI disks in initiator mode?

If useful, I can provide:
• the full debug logs
• firmware build information
• additional testing with different jumper settings

The original (now preserved!) drive doesn't seem to have any issues (yet), so when I find time I am happy to run experiments if necessary.

Thanks again for the project and for taking a look.

next-mirroring-minimal.patch

[erichelgeson]

Thanks so much for the report! Ya it looks like it's reading too fast and seeing a phantom STATUS phase, we might need a phase debounce or some guard. Thanks for taking the time to so thoroughly test and debug this. I'll @ you here when I have something for you to test as this hasn't happened on my drives testing.

[fdanapfel]

I imaged some IBM DPES-31080 drives some time ago using a BlueSCSIv2 with a Pico 1 W running firmware 2024.12.08 using an external disk enclosure where the disks and the BlueSCSI were connected to the power supply of the enclosure., and did not have any issues.

Here is the log.txt from that session:

log.txt

@fortiko You did not mention how the BlueSCSIv2 was powered. Did you just use the TermPower from the SCSI bus, or was it also connected to the power supply?

[fortiko]

Hello @fdanapfel Initially I was using only TermPower. Then I figured out how to connect to the Pico via micro USB to monitor the progress via screen, from that point I suppose that the Pico was powered by the USB cable and bluescsi via TermPower? At no point did I connect the FD power, because the NeXT doesn't offer that plug.

In any case: the updated firmware worked in the exact same scenario where the original firmware didn't, so even if it were related to power, there is a solution for it.

Let me know what else I can contribute. Thanks you all for looking into this!

[fdanapfel]

Initially I was using only TermPower. Then I figured out how to connect to the Pico via micro USB to monitor the progress via screen, from that point I suppose that the Pico was powered by the USB cable and bluescsi via TermPower?

@erichelgeson would have to confirm that using initiator mode when the BlueSCSIv2 is powered either via TermPower or by supplying power via the micro USB on the Pico is actually supported.

At no point did I connect the FD power, because the NeXT doesn't offer that plug.

You can get an adapter cable to convert the "floppy disk"-style power connector on the BlueSCSIv2 to a standard hard disk power connector: https://www.amazon.com/Kentek-Floppy-Internal-Computer-Adapter/dp/B07KS5NHTC

This is what I use to power the BlueSCSIv2 when it is in initiator mode.

In any case: the updated firmware worked in the exact same scenario where the original firmware didn't, so even if it were related to power, there is a solution for it.

OK, then maybe this is an issue introduced in a later firmware versions than the one I used, because I only see you testing firmware versions that are newer than 2024.12.08 (which is the one I used without issues).