Atari ST/TT: Support of ICD compatible command semantics?

[uweseimet]

When using BlueSCSI with the internal host adapter of a MegaSTE I could not figure out whether BlueSCSI supports ICD compatible command semantics or not. The results I got were inconclusive.
I'd like to refer to RaSCSI ticket PiSCSI/piscsi#637 which describes these semantics. The implementation was straightforward because essentially just the first (custom) command byte had to be ignored. hal/gpiobus.cpp in the rascsi project has the details.
Without ICD compatible semantics drives with a capacity of more than 1 GB can only be used partially, for instance.

[mynameistroy]

Hi Uwe,

indeed there is a mechanism for that here

BlueSCSI/src/BlueSCSI.cpp

Line 1594 in c12aa47

// Atari ST ICD extension support

[uweseimet]

@mynameistroy It works, indeed. When first testing this I was using outdated software and the results confused me.
I think I find a bug, though: When BlueSCSI is connected to my TT and a READ(16) command is sent, this command is properly rejected with the respective SCSI error code because it is not supported by BlueSCSI. When I do the same with the MegaSTE, READ(16) is not rejected, but it returns some (invalid) data. READ CAPACITY(16) has a similar issue. For testing I use my SCSI Driver/Firmware test suite, which is available on https://www.hddriver.net/en/scsidriver.html.
Looks to me as if in case of an ICD compatible command there is something wrong with the error handling of unsupported SCSI commands, at least with commands where the CDB has more than 10 bytes. Maybe you can check this?

[mynameistroy]

Ah since I don't have a mythical TT myself :D I didn't realize there might be an issue! I've used an older version of your test suite way back but good to know it's been updated so I'll grab a copy and give it a go.

[uweseimet]

@mynameistroy Note that the test suite sources are on https://github.com/uweseimet/atari_public if you need them. I don't think this is a software issue, though, because other devices connected to the ACSI port (UltraSatan, RaSCSI) correctly report an error.

[mynameistroy]

Just an update to this that I believe I have a fix in place for handling 16 byte CDBs

[uweseimet]

Does this fix also work with other byte counts? All in all, any unknown command, i.e. any unknown opcode, should be rejected. The byte count does not really matter IMO, because if the first byte contains an unknown command there is no need to receive any further bytes. For unknown commands you don't know anyway how many bytes the respective CDB might have.

[mynameistroy]

Should be fine for any and all in the defined command lengths. It does currently acquire the full CDB before determining if rejection is required but I do plan on refactoring that with some other optimizations in the near future. For the time being though this just makes it handle things a bit better.

[uweseimet]

I guess you have already tested your changes against the SCSI Driver testsuite?

[mynameistroy]

Yes I used that as my test case for this

[uweseimet]

If I wanted to update my BlueSCSI firmware, how would I do that in order to install your changes? I don't have a Mac or Windows PC, but I have a VirtualBox VM with MacOS, which I assume should work. I can install and run the updater, but what do I have to do to update with your changes?

[erichelgeson]

@uweseimet if you're on linux you should be able to just run the command as shown in the updater script https://github.com/erichelgeson/BlueSCSI-Updater/blob/main/utils/flash-bluescsi-firmware-usb.sh#L10

If you need me to build the bin for you please let me know the exact version in your log.txt so I can build the right one.

[uweseimet]

@erichelgeson Sounds good, regarding Linux. This is what my log says:

BlueSCSI <-> SD - https://github.com/erichelgeson/BlueSCSI
VER: 1.1-20220917-USB-128MHz
DEBUG:0 SDFAT_FILE_TYPE:3
SdFat version: 2.2.0
Sd Format: exFAT
SPI speed: 50Mhz
SdFat Max FileName Length: 64

But this is not a high priority issue, and @mynameistroy has tested the change already. I was mainly interested tn seeing how the update procedure works. But this can wait until there are more new features. In particular support for multiple LUNs ;-).

[mynameistroy]

The issue of 16 byte CDB handling has been fixed and merged with #194

[uweseimet]

I tried the new BlueSCSI release, but it is not working for me, neither with the MegaSTE nor the TT. Both machines crash when booting from BlueSCSI. The image I used with the TT is a fresh copy of an image that works fine with RaSCSI/PiSCSI. With the MegaSTE I used the same image that was working for me with the previous release. The hardware setup is the same as before, i.e. the same cables, the same SD card, and BlueSCSI connected to the internal SCSI port.
The systems crash at various places when executing AUTO folder programs. With each boot attempt the crash happens somewhere else.

Something else was strange: I noticed that after the firmware update all filenames on the SD card were duplicated:

-rwxr-xr-x 1 root root 487593984 Nov  3 15:04 CD50_tt.iso
-rwxr-xr-x 1 root root 487593984 Nov  3 15:04 CD50_tt.iso
-rwxr-xr-x 1 root root 805306368 Nov  5 07:59 HD00_512_mega.hda
-rwxr-xr-x 1 root root 805306368 Nov  5 07:59 HD00_512_mega.hda
-rwxr-xr-x 1 root root       936 Jan  1  2022 LOG.txt
-rwxr-xr-x 1 root root       936 Jan  1  2022 LOG.txt

I created a new filesystem on the card in order to fix the problem with the duplicate filenames, but this did not resolve the main issue, i.e. the Atari crashing.