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 https://github.com/akuker/RASCSI/issues/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 https://github.com/erichelgeson/BlueSCSI/blob/c12aa478d541364ddfa0d2b45a47a3ddf02a1311/src/BlueSCSI.cpp#L1594

[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.

[uweseimet]

@mynameistroy @erichelgeson Any feedback on the issue above? Maybe I should create a separate ticket for this?

[mynameistroy]

My apologies, been busy with life to have a chance to dig into this. However much of that is clearing up so I'll probably get a chance to have a look this evening or tomorrow.

[mynameistroy]

@uweseimet I got a chance to look at this and I'm not able to reproduce your issue. Everything works fine for me on my MSTE.

I definitely can't explain the duplicate filenames issue. I can only assume a filesystem corruption of some kind.

As for the crashing, not sure what is going on.

[erichelgeson]

Apologies for missing the @ here - Anytime there is SD card weirdness it can normally be corrected with a full overwrite format using the SD Card Formatter Utility - please try that first.

[uweseimet]

@erichelgeson I neither use Windows nor MacOS, which appear to be required for using this software. So far I have never had any issues with SD cards that required a special treatment. The type of SD card I was using with BlueSCSI is the same as those I am using with Linux and the Atari with regular SD card readers.

[erichelgeson]

The author of the SDFat library we use says

You should never use an OS utility to reformat an SD card. Use the SD Association formatter .

I do not claim to be an expert on SD card or all their nuances.

Maybe you could find a friend with a windows or mac computer? Or try https://github.com/greiman/SdFat/blob/master/examples/SdFormatter/SdFormatter.ino

[uweseimet]

@erichelgeson Well, I have no issues using this type of card anywhere else, and neither with Linux nor the Atari I ever needed other tools than the Linux ones or my owns to correctly prepare (format) SD cards or other drives. Duplicate filename issues are very likely filesystem-related. After re-creating the filesystem the filename issue was gone. The core issue in my case is not the duplicate filename, but that for an unknown reason the latest BlueSCSI firmware does not work anymore for my Ataris.