SASI drive error codes

[mark_k]

Following from this post in the recent T-Disk: initialization failure, it seems WinUAE's response to REQUEST SENSE commands is wrong for emulated SASI controller/drive. Or at least, it doesn't match what the Xebec S1410A manual says.

REQUEST SENSE STATUS (command $03) returns four bytes, and for an attempted out-of-bounds access the first byte (error code) would be $21 ("illegal disk address: the controller detected an address that is beyond the maximum range"). The address valid bit would be set though, so $A1 followed by three LBA bytes. See page 43 of the Xebec S1410A manual.

[Toni Wilen]

I am sure yet sure if I bother, SASI "support" was not really "designed" for any corner cases or unexpected errors and there is also no guarantee drivers even handle it correctly (this is really unexpected case!) which can make testing impossible.

[sigma63]

Originally Posted by mark_k

See page 43 of the Xebec S1410A manual.

Hello Mark_k, could you please upload this manual to the zone?
Or, alternatively, could you post a link?

Thank you

[mark_k]

http://bitsavers.trailing-edge.com/pdf/xebec/

Also there are some SASI draft documents at
http://bitsavers.trailing-edge.com/pdf/ansi/X3T9/

[mark_k]

Originally Posted by Toni Wilen

I am sure yet sure if I bother, SASI "support" was not really "designed" for any corner cases or unexpected errors and there is also no guarantee drivers even handle it correctly (this is really unexpected case!) which can make testing impossible.

It should be quite simple to "fix" the REQUEST SENSE behaviour though.

After reading the Xebec manual and SASI draft specs, I think I know what the problem was. The Xebec controller always returns 4 bytes in response to REQUEST SENSE.

In the SCSI spec, byte 4 of the REQUEST SENSE CDB is the allocation length. The drive returns up to that number of bytes in response. SASI-revC_Jan82.pdf (p.39) says:
The "No. of blocks byte" in the
command will determine the length, in
bytes, to be returned to the host.
0 = 4 bytes
1-255 = as indicated

So there's a special case where the allocation length byte is 0; the drive should return 4 bytes then.

The description of REQUEST SENSE STATUS in the Xebec manual (104478B_S1410A_Feb84.pdf document p.42, PDF p.49) says CDB bytes 2-5 are "don't care" (and byte 1 bits [4:0] too). The controller always returns 4 bytes.

That Xebec controller behaviour is probably the reason for the "0 means 4 bytes" special case in the SASI spec. X3T9.3_185_RevE_SASI_Apr82.pdf has similar wording (document p.35, PDF p.40):
0 = 4 bytes. To be compatible with existing initiators. Future initiators will specify in byte 04 the number of bytes allocated for sense data (e.g., 1 to 255 bytes).

When emulating a SASI drive (or more specifically Xebec S1410A controller), it could be sufficient to:
- If CDB byte 4 is 0, return 4 bytes. [Probably better to just ignore CDB byte 4 and always return 4 bytes to better match Xebec behaviour, in case some driver sends commands with byte 4 non-zero.]
- The error code in the first byte returned seems to match the ASC in SCSI sense data; e.g. $21 means illegal disk address.

[Toni Wilen]

Actually it is already correct. Request sense length=0 becomes 4.

Log still shows full sense data because log function uses length that SCSI emulation returns and data is truncated in generic SCSI emulation, after device specific SCSI emulator (HD or CD) has returned the data.

[mark_k]

In scsi.cpp there is this:

static void copysense(struct scsi_data *sd)
{
	int len = sd->cmd[4];
	if (log_scsiemu)
		write_log (_T("REQUEST SENSE length %d (%d)\n"), len, sd->sense_len);
	if (len == 0)
		len = 4;
	memset(sd->buffer, 0, len);
	memcpy(sd->buffer, sd->sense, sd->sense_len > len ? len : sd->sense_len);
	if (len > 7 && sd->sense_len > 7)
		sd->buffer[7] = sd->sense_len - 8;
	if (sd->sense_len == 0)
		sd->buffer[0] = 0x70;
	showsense (sd);
	sd->data_len = len;
	scsi_clear_sense(sd);
}

So it looks like you respond with 4 bytes when CDB[4] is 0. But the first byte of the response in that case will be 0x70 not the ASC value?

And! I just noticed this from the log that B14ck W01f posted:
SCSIEMU HD 0: 08.00.9F.F9.11.05.00.00.00.00.00.00 CMDLEN=6 DATA=0000000006987430
UAEHF SCSI: out of bounds, 00000000-013FF200 + 00000000-00002200 > 00000000-01400000
-> SENSE STATUS: KEY=5 ASC=21 ASCQ=00
70.00.05.00.00.00.00.0A.00.00.00.00.21.00.00.00.00.00.
-> DATAOUT=-1 ST=2 SENSELEN=18 REPLYLEN=0
SCSIEMU HD 0: 03.00.9F.F9.11.05.00.00.00.00.00.00 CMDLEN=0 DATA=0000000000000000

Tecmar driver issues out-of-bounds READ: 08 00 9F F9 11 05
Then it issues REQUEST SENSE: 03.00.9F.F9.11.05
Notice that all CDB bytes except the first are unchanged from the previous READ command. So it seems, at least for the Tecmar case, you need to ignore CDB[4] and always return 4 bytes.

[Toni Wilen]

Originally Posted by mark_k

So it looks like you respond with 4 bytes when CDB[4] is 0. But the first byte of the response in that case will be 0x70 not the ASC value?

0x70 is only forced if scsi emulator returned 0 bytes of sense data. (which means request sense was received without sense data = return "all fine")

Notice that all CDB bytes except the first are unchanged from the previous READ command. So it seems, at least for the Tecmar case, you need to ignore CDB[4] and always return 4 bytes.

Should work now. Maybe.. ASC is also copied to index 0 now if SASI.

[mark_k]

I think you need to also:
- Set bit 7 (Valid) of byte 0 of the sense data if applicable
- Bits [7:5] of byte 1 contain the LUN (000 or 001 since the S1410A supports two drives). The rest of byte 1 and bytes 2&3 contains the LBA which you can copy from bytes 4-6 of normal SCSI sense data.

[Toni Wilen]

So it is totally different than SCSI which then means (which I already said): not going to bother with it. Unless there is single algorithm. Not something like: if this status, to that adjustment, if that, do this adjustment and so on.

[Toni Wilen]

What about: if you find yet another SASI controller that is not emulated (with driver), I'll add missing sense codes?

[mark_k]

I wouldn't say totally different; you can see how the SCSI REQUEST SENSE data evolved from SASI. Anyway, in pseudo-C, where scsi_sense_data[] is the normal/standard SCSI sense data:

sasi_sense_data[0] = scsi_sense_data[12] & 0x7F; // Error code (= ASC)
sasi_sense_data[0] |= scsi_sense_data[0] & 0x80; // Valid bit

sasi_sense_data[1] = scsi_sense_data[4] & 0x1F;  // LBA [21:16]
sasi_sense_data[1] |= LUN << 5;                  // LUN

sasi_sense_data[2] = scsi_sense_data[5];         // LBA [15:8]
sasi_sense_data[3] = scsi_sense_data[6];         // LBA [7:0]

[mark_k]

Originally Posted by Toni Wilen

What about: if you find yet another SASI controller that is not emulated (with driver), I'll add missing sense codes?

Has the Micro Forge HD driver turned up? I noticed some related code appeared in WinUAE...

Edit: the original manufacturer driver, not the replacement on Aminet.

[mark_k]

The REQUEST SENSE data for "SASI CHS" drives is similar. See OMTI_5510_Winchester_Controller_Jun85.pdf page B1 (PDF page 53).

sasi_chs_sense_data[1] bits [4:0] is head number
sasi_chs_sense_data[2] bits [7:6] is the high two bits of cylinder number, bits [5:0] is sector number
sasi_chs_sense_data[3] is the low byte of cylinder number

[Toni Wilen]

It should now work but Xebec formatter does not do any request sense commands, it just keeps formatting..

[sigma63]

Originally Posted by mark_k

http://bitsavers.trailing-edge.com/pdf/xebec/

Also there are some SASI draft documents at
http://bitsavers.trailing-edge.com/pdf/ansi/X3T9/

Thank you very much