Conversation
| eCmdRezero = 0x01, | ||
| eCmdRequestSense = 0x03, | ||
| eCmdFormat = 0x06, | ||
| eCmdFormat = 0x04, |
There was a problem hiding this comment.
@uweseimet - As a side note: In the original RaSCSI code, both 0x04 and 0x06 were treated as Format commands for SASI devices. If we remove the SASI support, this really doesn't matter. But, something to consider if we're keeping SASI support.
// FORMAT UNIT
case 0x04:
CmdFormat();
return;
// FORMAT UNIT
case 0x06:
CmdFormat();
return;
There was a problem hiding this comment.
I propose that we keep SASI support around for at least this next release. Could you add an eCmdFormat06 value that is handled the same way as eCmdFormat?
There was a problem hiding this comment.
I will do that, but the SASI specification clearly says 0x04. Why would a SASI device violate the SASI specification and use 0x06? We also don't add 0x06 to SCSI, do we? ;-)
I suggest to discard SASI after the next release, making 22.03 the last release with SASI support.
|
I added support for 512 bytes per sector because SASI supports that, see #727. |
Summary of SASI changes:
My Atari can now boot from a SASI drive, and can correctly read data and execute programs loaded from the drive. I cannot test the SASI error handling with my setup because RaSCSI appears to implement an old SASI flavor of REQUEST SENSE, where the error status is encoded differently than with newer SASI standards, where errors are reported very similar to SCSI. From the logfile the error handling appears to be correct.