CD Drive in USB mode

[psycopenguin]

Trying to utilize a Toshiba XM-3401TA in USB SCSI mode but Windows 11 detects the drive as a USB hard disk rather than a CD-ROM drive blocking it from reading it as the disk drive driver does not allow the read of UDF format. Drive does work in Ubuntu so the drive an BlueSCSI are communicating properly it is just that the drive reports as a disk drive rather than a CD-Rom drive blocking from proper read. Would it be possible to add to the ini reporting as a CD-Rom Drive rather than disk drive during device presentation.

[erichelgeson]

Ya that is great idea - if it's a fixed disk 0x00 or a optical 0x05 we could likely present it differently to the host.

[erichelgeson]

@psycopenguin Please give this build a try. Flashable uf2's will be here once CI job is done: https://github.com/BlueSCSI/BlueSCSI-v2/actions/runs/19272786968

It works on my external Apple 300e and linux. I don't have a Windows machine to test.

$ sg_inq /dev/sdi
standard INQUIRY:
PQual=0  PDT=5  RMB=1  LU_CONG=0  hot_pluggable=0  version=0x02  [SCSI-2]
[AERC=0]  [TrmTsk=0]  NormACA=0  HiSUP=0  Resp_data_format=2
SCCS=0  ACC=0  TPGS=0  3PC=0  Protect=0  [BQue=0]
EncServ=0  MultiP=0  [MChngr=0]  [ACKREQQ=0]  Addr16=0
[RelAdr=0]  WBus16=0  Sync=0  [Linked=0]  [TranDis=0]  CmdQue=0
length=36 (0x24)   Peripheral device type: cd/dvd <---- correct device type.
Vendor identification: MATSHITA
Product identification: CD-ROM CR-8004            < --- actual product/vendor data.
Product revision level: 1.0p

[psycopenguin]

It appears that the BlueSCSI crashes when trying to load up the CD drive. Windows starts detecting the drive as a CD-ROM when connected with a CD inserted then then the activity light goes solid blue on the BlueSCSI and Windows throws an unknown USB device error. Correcting requires a full power reset of the BlueSCSI to get the com port and USB CD-Rom showing again briefly. The drive does not appear to be spinning up during this time so it appears that the BlueSCSI is completely locked up.

[erichelgeson]

Can you please provide any log.txt or err.txt? I tested on a pico1/pico2w without issue.

[psycopenguin]

Here is the logging with debugging enabled from the blueSCSI. It appears to boot properly when the BlueSCSI is booted without a CD in the drive but once a disk is inserted the BlueSCSI presents as a USB drive to the computer rather than a removable CD drive. When a disk is inserted and the usb connection to the BlueSCSI is unplugged and plugged back in the drive briefly shows up as a CD-ROM and then the activity light goes solid and the BlueSCSI disconnects and reconnects as an unknown device. I can verify same behavior happens on Manjaro if you disconnect/reconnect while a disk is inserted in the drive. It appears to still be working property if you boot without a disk in the drive in Linux and then insert one which was the same behavior as before as Linux was able to decode the disk even in generic usb drive mode

log.txt

[erichelgeson]

I'm not able to reproduce what you describe on Linux or Macintosh. I've updated a few things to help with some eject scenarios and Zip/MO/Removable devices - please try the latest and give me a log: https://github.com/BlueSCSI/BlueSCSI-v2/actions/runs/19285394300/job/55145094273

[psycopenguin]

I am still seeing the same issue with the most updated firmware. I was able to get the drive to properly detect by loading up a disk in the drive while the BlueSCSI was booted using power from the SCSI cable and ejecting as soon as I connected the USB to the computer but as soon as it attempted to load the disk I got the same solid activity light and unknown usb device message. see below for current logs and an error log that was generated this time

err.txt

log.txt

[erichelgeson]

OK I see the issue. Windows doesn't seem to be honoring the protocol version thats set (I mean who'd expect a SCSI-2 device on a USB connection :D) - It's sending CDB's that the drive doesn't know about and the drive cant respond to. It might be possible to map these to the older spec, but that a bit of a can of worms if they'd map 1-1. Not sure how far we want to go with this. The most direct solution for you to read your disk is to grab a cheap USB/SATA CDROM drive that is supported by modern OS's and a lot faster and more reliable.

edit: I will add a proper check condition for CDB's that we know are too long/unsupported in scsi-2 and see if that at least gets you further, maybe the app/windows will be smart enough to try the older versions of the commands.

[psycopenguin]

I was mostly just trying to use this functionality because I had a caddy based CD-ROM drive that was a curiosity to use so completely understandable if this fringe case is too much effort to try to implement

[erichelgeson]

I pushed up one more attempt if you'd like to try in Windows.

[psycopenguin]

Sorry for the delay just now got around to testing this. Appears to be the exact same behavior as before where Windows detects the CD drive but as soon as a disk is inserted solid blue activity light and get a device malfunctioned from Windows

[erichelgeson]

If you wanted to try latest we made some changes around this which might handle it better in windows. let me know!