Unable to get it to work with a Mac Classic

[ovesennet]

I alreadu have an old BlueSCSI (1) working with this machine.
Now with the BlueSCSI v2, I cannot get the computer to see the scsi device.
I enabled logging, I can see that it finds the image (same as I use on the old BlueSCSI.
Then it says Waiting for USB enumeration timed out after 4000ms. What does that mean?
I tried bigger values for USBMassStorageWaitPeriod.
What could be the issue here ?

Thanks!

Log:

Platform: BlueSCSI (Pico1)
FW Version: 2025.08.02-rel Aug  2 2025 16:25:01
Flash chip size: 2048 kB
I2C Supported
 
=== SD Card Info ===
SD card detected, FAT16 volume size: 0 MB
SD Name: 5&DRP, MID: 0x27, OID: 0x50 0x48
Speed grade set to  reclocking system
Initial Clock set to 133MHz
Reclocking the MCU to 200MHz
Setting the SDIO clock to 40MHz
After reclocking, system reports clock set to 200MHz
======== Reinitializing BlueSCSI after reclock ========
[30ms] 
[30ms] === Global Config ===
[30ms] Reading configuration from bluescsi.ini
[32ms] Using system preset "Generic"
[32ms] DBG -- SelectionDelay = 255
[32ms] DBG -- EnableUnitAttention = No
[32ms] DBG -- EnableSCSI2 = Yes
[32ms] DBG -- EnableSelLatch = No
[32ms] DBG -- MapLunsToIDs = No
[32ms] DBG -- EnableParity = Yes
[32ms] 
[32ms] === Finding images ===
[44ms] === Finding images in / ===
[51ms] DBG -- Using block size, 512 from filename: HD00_512.hda
[52ms] == Opening /HD00_512.hda for ID:0 LUN:0
[55ms] DBG ---- Image file is contiguous, SD card sectors 109400 to 211799
[55ms] ---- Configuring as disk drive
[55ms] DBG ---- Geometry set from image size: SectorsPerTrack=50 HeadsPerCylinder=16 total sectors 102400 (divisible)
[55ms] DBG ---- Read prefetch enabled: 4608 bytes
[55ms] 
[55ms] == Platform supports ROM drive up to 1465 kB
[55ms] DBG ---- ROM drive image not detected
[55ms]  
[55ms] === Configured SCSI Devices ===
[55ms] ID: 0, BlockSize: 512, Type: Fixed, Quirks: None, Size: 51200kB
[56ms] [277ms] DBG Waiting for USB enumeration to enter Card Reader mode.
[2603ms] DBG BUS RESET
[4377ms] DBG Waiting for USB enumeration timed out after 4000ms.
[4377ms] DBG -- Try increasing 'USBMassStorageWaitPeriod' in the bluescsi.ini
[4377ms] Clock set to: 200MHz
[4378ms] Initialization complete!
[4385ms] INFO: Pico Voltage: 3.103V.
[4609ms] DBG -- BUS_BUSY
[4609ms] DBG ---- SELECTION: 0
[4611ms] DBG ---- COMMAND: Write6
[4611ms] DBG ------ OUT: 0x0A 0x02 0x02 0x02 0x03 0x02 
[4611ms] DBG BlueSCSI Toolbox enabled = 1
[4611ms] DBG ---- STATUS: 2 CHECK_CONDITION, sense code 0x05, asc 0x00002400
[4615ms] DBG ---- MESSAGE_IN
[4615ms] DBG ------ IN: 0x00 
[4616ms] DBG -- BUS_FREE
[4620ms] DBG -- BUS_BUSY
[4620ms] DBG ---- SELECTION: 0
[4622ms] DBG ---- COMMAND: Write6
[4622ms] DBG ------ OUT: 0x0A 0x02 0x02 0x02 0x03 0x02 
[4622ms] DBG ---- STATUS: 2 CHECK_CONDITION, sense code 0x05, asc 0x00002400
[4626ms] DBG ---- MESSAGE_IN
[4626ms] DBG ------ IN: 0x00 

[erichelgeson]

Interesting - it looks like data line 2 is stuck (could be either on your BlueSCSI, your classic, or the cable) - the first command should be a read (0x08) but it has 2 added to it to make it 0x0A - then the rest you can see are all added the second bit (2)
Expected:
0x08 0x00 0x00 0x00 0x01 0x00
You are seeing bit 2 added to each:
0x0A 0x02 0x02 0x02 0x03 0x02

If you need more direction debugging this stuck line let me know - all you should need is a multi-meter in continuity and start tracing back the D2 line. Some schematics to help: https://bluescsi.com/boms/2023.10a-50pin https://bluescsi.com/boms/2024.01a-DB25

If you determine this is on the BlueSCSI and bought from someone listed on bluescsi.com please reach out to me or them for resolution (if you determine it's the BlueSCSI - could just as easily be your cable or computer - these are about 40 years old!)

Good luck and we're here to help you figure it out!

Edit: missed the first line where you said you have a v1 working - I'd still test any cables you have just to be sure.

[ovesennet]

Thanks for the help. Strange with that added bit. I was under the impression that it could be powered by the computer via the scsi connector like v1, and it does boot and blink. But I think it's maybe a power issue. I connected 5v to the berg connector, and I had it booting the mac from the hd-image once. So it definitely works. But next time, did nothing. I did not try to power it via the usb. I'll look more into this tomorrow.

[erichelgeson]

It can be powered via the SCSI bus for sure - 99% of the time thats how I use it. But Classic's are notorious for bad power supplies. If you have a multimemter please test the 5v rail at the SCSI port.

[ovesennet]

I have connected it to 5v via usb, and tried many kinds of different settings. I checked the log file from the old working v1, and it also logs that it is sending 0x0A 0x02 0x02 0x02 0x03 0x02. I checked with an oscilloscope, and the signals looks fine. However, according to ChatGPT it could be that the BlueSCSI v2 is too fast for the Mac Classic, or the bus timings are not correct. I don't thrust ChatGPT always, but I gave it the log-file, and it says this: "The bad news: the Mac Classic’s SCSI bus and BlueSCSI v2’s new timing don’t agree — the CHECK_CONDITION with sense code 0x05, ASC 0x24 is the giveaway. The BlueSCSI reports an error: “Illegal request – invalid field in CDB”. This means the firmware rejected the Mac’s SCSI command as invalid." I have no idea if this makes sense or not.

It also suggested several parameters I could try in the bluescsi.ini, but no change. As I mentioned, I had it boot the Mac once, but never again.

[erichelgeson]

Please do not use ChatGPT to debug this, it has no idea.

BlueSCSI works with a classic, bus timings are not an issue.

The check condition is correct, as data line 2 is stuck, making the CDB have an illegal field.

No ini settings will help and 99.9% of the time are not required.

Eric(me) is a real person and here to help ;)

The log strongly suggests D2 is asserted (pulled low) can you go through all the data lines with nothing happening on the bus, one should be asserted and the others not.

[ovesennet]

Thanks! Not my intention to offend anyone by using ChatGPT. I always try to solve problems my self first. I am fully aware of the mistakes it can do :)
I will try to check out the data lines more carefully.

[erichelgeson]

I understand where you're coming from, though a LLM cant help us here :)

[ovesennet]

I have come to a conclusion. I have an oscilloscope and are fully capable of tracing signals etc. I took your information about 2 being added to the bytes serious, and thus dataline D1 being faulty. And it is, but not on the computer side. It is always low on the Pico. From the computer and all the way to the R19 resistor on the BlueSCSI, the signal is normal. Between R19 and the Pico, the signal is low. The continuity is there, and I found no shorts to anything else. So my conclusion is that the port on the Pico is faulty.

[erichelgeson]

:slaps head: 0 based indexing strikes again! I meant D1 as the second data line, not D2 as it's the 3rd dataline. Glad you got past my human error :)

Again if you got it from someone on bluescsi.com we can replace it for you.

[ovesennet]

Thanks. I got it from a friend. Not sure where he got it. Anyway, I think I have another Pico I can test with. Not problem. Thanks for helping me solve this.

[ovesennet]

I installed another Pico and it worked fine :)

[erichelgeson]

Awesome! Rare to have a bad Pico, but can happen. Glad you're up and running!