English Amiga Board Amiga Lore


Go Back   English Amiga Board > Support > support.WinUAE

 
 
Thread Tools
Old 06 September 2016, 08:37   #1
mark_k
Registered User
 
Join Date: Aug 2004
Location:
Posts: 2,479
SASI drive error codes

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.
mark_k is offline  
AdSense AdSense  
Old 06 September 2016, 15:56   #2
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 42
Posts: 19,524
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.
Toni Wilen is online now  
Old 08 September 2016, 10:41   #3
sigma63
Registered User

 
Join Date: Oct 2014
Location: Berlin
Posts: 78
Thumbs up

Quote:
Originally Posted by mark_k View Post
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
sigma63 is offline  
Old 08 September 2016, 13:07   #4
mark_k
Registered User
 
Join Date: Aug 2004
Location:
Posts: 2,479
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 is offline  
Old 08 September 2016, 13:36   #5
mark_k
Registered User
 
Join Date: Aug 2004
Location:
Posts: 2,479
Quote:
Originally Posted by Toni Wilen View Post
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.
mark_k is offline  
Old 08 September 2016, 15:26   #6
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 42
Posts: 19,524
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.
Toni Wilen is online now  
Old 08 September 2016, 17:51   #7
mark_k
Registered User
 
Join Date: Aug 2004
Location:
Posts: 2,479
In scsi.cpp there is this:
Code:
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.
mark_k is offline  
Old 08 September 2016, 18:05   #8
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 42
Posts: 19,524
Quote:
Originally Posted by mark_k View Post
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")

Quote:
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.
Toni Wilen is online now  
Old 10 September 2016, 17:16   #9
mark_k
Registered User
 
Join Date: Aug 2004
Location:
Posts: 2,479
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.
mark_k is offline  
Old 10 September 2016, 17:43   #10
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 42
Posts: 19,524
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 is online now  
Old 10 September 2016, 19:03   #11
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 42
Posts: 19,524
What about: if you find yet another SASI controller that is not emulated (with driver), I'll add missing sense codes?
Toni Wilen is online now  
Old 10 September 2016, 19:08   #12
mark_k
Registered User
 
Join Date: Aug 2004
Location:
Posts: 2,479
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:
Code:
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 is offline  
Old 10 September 2016, 19:09   #13
mark_k
Registered User
 
Join Date: Aug 2004
Location:
Posts: 2,479
Quote:
Originally Posted by Toni Wilen View Post
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.

Last edited by mark_k; 10 September 2016 at 19:28.
mark_k is offline  
Old 10 September 2016, 21:27   #14
mark_k
Registered User
 
Join Date: Aug 2004
Location:
Posts: 2,479
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
mark_k is offline  
Old 11 September 2016, 10:15   #15
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 42
Posts: 19,524
It should now work but Xebec formatter does not do any request sense commands, it just keeps formatting..
Toni Wilen is online now  
Old 13 September 2016, 16:29   #16
sigma63
Registered User

 
Join Date: Oct 2014
Location: Berlin
Posts: 78
Quote:
Originally Posted by mark_k View Post
Thank you very much
sigma63 is offline  
AdSense AdSense  
 


Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools

Similar Threads
Thread Thread Starter Forum Replies Last Post
SASI drive option for Tecmar T-Disk? superfrog support.WinUAE 7 25 February 2016 03:06
A500 Floppy Drive error? Geon106 support.Hardware 4 24 February 2011 16:50
removable drive removal error NewDeli support.WinUAE 5 24 September 2009 21:15
Hard Drive checksum error :( staticgerbil support.Apps 4 16 November 2003 23:46
Power light error codes Unregistered support.Hardware 3 03 September 2002 20:14

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +2. The time now is 13:52.


Powered by vBulletin® Version 3.8.8 Beta 1
Copyright ©2000 - 2017, vBulletin Solutions, Inc.
Page generated in 0.18590 seconds with 11 queries