ACSI2STM

[uweseimet]

I noticed that on github the ACSI2STM authors say that they used the Hatari sources as a reference for their implementation. When there are public official specifications it is not a good idea to use anything else for reference. This is like playing the telephone game.

When running the test suite against a Hatari ACSI drive no errors are reported and ICD compatibility is properly detected. Hatari does not support removable media, by the way, like it is needed for hot-swappable media like memory cards. Without proper removable media handling it is very likely that data are corrupted after switching memory cards.

[troed]

Yeah I saw that too. I'm currently reading up on the original SCSI spec and looking through the code ;) I also need to verify if the source from the repository and masteries version on A-F are the same. I'll spend some time seeing how far away the code is from where it needs to be for what it does.

Code: Select all

  case 0x12: // Inquiry
    ...
    if(getLun() > 0)
      dataBuf[0] = 0x7F; // Unsupported LUN
    dataBuf[1] = 0x80; // Removable flag
    dataBuf[2] = 1; // ACSI version
    dataBuf[4] = 31; // Data length

[uweseimet]

Code: Select all

dataBuf[2] = 1; // ACSI version

This has nothing to do with ACSI. 1 means SCSI-1-CCS, which was the predecessor of SCSI-2 and the successor of SASI. Atari shipped a SCSI-1 drive (Seagate ST157N) with the MegaSTE and TT. For those who purchased Ataris ASVR4 Unix on a hard disk drive instead of a tape drive it was shipped with a Maxtor LXT213-S (or a bigger Maxtor drive if you were willing to pay more), which is also a SCSI-1 drive.
And the Megafile 44 (SyQuest SQ555) was SCSI-1. When hard disks with higher capacities became cheaper and really popular with the Atari, SCSI-2 drives were up to date.

TOS always caches at least 2 FAT/directory and 2 data sectors. You can increase the cache sizes in order to improve performance (HDDRUTIL has a configuration option for this), but you cannot completely switch if off. If you swap a removable medium (e.g. a memory card) any hard disk driver relies on the drive to correctly report this. Even AHDI depends on it, because otherwise it would not have worked with the Megafile 44. In case the driver does not correctly report the media change, TOS will not be aware of it and may keep data from the previous medium in its caches. In the best case this just results in a crash when launching an application from the new medium. In the worst case old data are written to the new medium, leading to data corruption. You may not even notice immediately that there is an issue.

Even with the Atari, newer SCSI levels than 2 are not that unusual. The SCSI standard is still worked upon, and the software protocol was decoupled from the hardware long ago. The Atari can make use of SCSI commands newer than SCSI-2, in case of ACSI with ICD compatible adapters, just like it has always been. Optical SATA drives or USB sticks usually implement one of the more recent SCSI levels, and these levels also support a range of new SCSI commands. HDDRIVER and HDDRUTIL make use of some of them, if available, in order to optimize certain operations, and also to support TOS filesystems on rewritable optical media (DVD-RAM, DVD+RW, BD-RE). For the latter they use the GET CONFIGURATION command in order to find out which media types a drive supports, and which media type is currently inserted. HDDRUTIL only enables the partitioning menu item, for instance, if a rewritable medium is present in an optical SATA drive. RaSCSI is another example where you may find devices with SCSI levels newer than SCSI-2. Even the Hatari supports REPORT LUNS, which is also one of the post SCSI-2 commands, and which is mandatory with current SCSI levels.

[DoG]

ACSI2SD and ACSI2STM is two different things.

ACSI2SD is based on SCSI2SD and uses Cypress ARM Cortex M3.
https://www.eltradec.eu/index.php/en/project-acsi2sd-en
https://github.com/eltradec/ACSI2SD-Proc

ACSI2STM is based on Atmega STM32.
https://github.com/retro16/acsi2stm

It could be same code for different chip of course but I don't think it is.