disk change does not work with emulated IDE CD drive

[thomas]

I add one iso image as IDE1, boot, run IDEfix, mount CD1:, nice.

Press F12, change image to another iso, press ok, nothing happens (change not recognised, all files from the first iso can still be read).

Open a CLI and enter diskchange cd1:, cd1 becomes "not a disk disk". From then on IDE1 does not work any more, no matter if I use Ctrl-A-A, F12 + reset, F12 + restart + start, IDE1 remains "not a dos disk", even if I reinsert the first iso.

Then I tried a real CD drive and a Windows CD emulation, both don't work as IDE1 at all. The volume name is shown, but only directories can be read. Trying to read files gets "Error -2" whatever that means.

[Toni Wilen]

Idefix version? (Different versions may use different commands)

[thomas]

It's not related to IDEfix, does not work with scsi.device V43+, too.

IDEfix used is IDEfix97.lha from Aminet.

[Toni Wilen]

It must be something to do with SCSI CD emulation media change update.

SCSI spec says TEST UNIT READY should return UNIT ATTENTION/MEDIUM MAY HAVE CHANGED sense status if media was changed. This error state is reset when REQUEST SENSE SCSI command is received.

Apparently ATAPI does not use this system and requires polling (?), atapi.device keeps sending TEST UNIT READY, without reseting error state. But I found ATAPI CD datasheet that mentions MEDIUM MAY HAVE CHANGED sense code so I am not sure what ATAPI is supposed to do..

EDIT: I found official documentation that says ATAPI should work exact same. So something else is wrong..

[thomas]

I don't believe it's related to commands and replies. At least not solely. As I said if disk change fails once, something inside WinUAE has been destroyed which stays like this until WinUAE is quit. When I press F12 and click on Reset, I should get a completely new session. But nevertheless the ISO remains NDOS, no matter if it's the new or the old one. At least a CMD_READ (or similar SCSI command) should be able to read data from the disk, even if disk change was not recognised. But it isn't. Even if I load another config the CD drive at IDE1 does not work any more. Only if WinUAE is quit and run again, then CD emulation works again.

[Toni Wilen]

Reset does not clear media changed state. This is a bug.

But real problem is what I explained above, device driver never sends REQUEST SENSE = drive's media status change state is never cleared. Spec says all commands must return media change error code until it is cleared with request sense.

[Toni Wilen]

TEST UNIT READY apparently also clears UNIT ATTENTION state. Can't find any information in SCSI specs but the internet says so.

[alexh]

http://www.t10.org/ftp/x3t9.2/document.91/91-107r0.txt

"The initiator can clear pending unit attention conditions by repeatedly issuing TEST UNIT READY commands followed by REQUEST SENSE commands until a sense key other than UNIT ATTENTION is returned by the target."

[Toni Wilen]

Originally Posted by alexh

http://www.t10.org/ftp/x3t9.2/document.91/91-107r0.txt

"The initiator can clear pending unit attention conditions by repeatedly issuing TEST UNIT READY commands followed by REQUEST SENSE commands until a sense key other than UNIT ATTENTION is returned by the target."

Yes, TEST UNIT READY + REQUEST SENSE is documented. But only executing TUR until status is not CHECK CONDITION also works (which is what atapi.device does), REQUEST SENSE is not needed to clear it.

Does it also mean REQUEST SENSE has nothing to do with clearing UNIT ATTENTION? TUR clears it and copies sense data to internal buffer, which caller can read (using REQUEST SENSE) if it bothers with it?

[Toni Wilen]

http://www.winuae.net/files/b/winuae.zip should fix it (TEST UNIT READY will clear UA, REQUEST SENSE not required anymore)

[thomas]

Diskchange is fixed.

But reading from real CD still does not work. CacheCDFS says "volume xy has a read/write error". (log attached)

Emulated Amiga stucks in init phase if CD drive is on IDE0, no matter if HDD on IDE1 or not. It also stucks if CD drive is on IDE1 with nothing on IDE0.


The same CD drive is also found on uaescsi.device. Don't know if it is supposed to. Mounting a file system on both drives is bad (mounting exactly the same volume twice totally confuses AmigaDOS).

[Toni Wilen]

Originally Posted by thomas

Diskchange is fixed.

But reading from real CD still does not work. CacheCDFS says "volume xy has a read/write error". (log attached)

Fixed. I thought this was same problem and didn't test it..

Emulated Amiga stucks in init phase if CD drive is on IDE0, no matter if HDD on IDE1 or not. It also stucks if CD drive is on IDE1 with nothing on IDE0.

This is KS 3.1 long IDE detection. (At least here it continues booting after the delay) I haven't found any way to handle this faster without doing something that is against IDE or ATAPI spec (=can break non-AOS operating systems). It can only work when no drives are connected.

Or does it also take long when it shouldn't?

The same CD drive is also found on uaescsi.device. Don't know if it is supposed to. Mounting a file system on both drives is bad (mounting exactly the same volume twice totally confuses AmigaDOS).

From UAE point of view it does not matter but perhaps uaescsi.device shouldn't enable it if drive is already IDE or SCSI mounted..

[thomas]

Originally Posted by Toni Wilen

This is KS 3.1 long IDE detection.

I think I did wait long enough to exclude this. But not entirely sure. Will do more tests tomorrow.

perhaps uaescsi.device shouldn't enable it if drive is already IDE or SCSI mounted..

This would be a good idea.

[thomas]

Originally Posted by Toni Wilen

This is KS 3.1 long IDE detection.

You were right. After waiting an incredible amount of time it finally started to boot. I imagine that the wait time on a real Amiga is not that long. Or does the wait time extend if there is an undetected (= ATAPI) device instead of no device?

Fixed. I thought this was same problem and didn't test it..

Confirmed.

[Toni Wilen]

Originally Posted by thomas

You were right. After waiting an incredible amount of time it finally started to boot. I imagine that the wait time on a real Amiga is not that long. Or does the wait time extend if there is an undetected (= ATAPI) device instead of no device?

I only see the usual KS3.1 30s delay and about 10s if KS 3.0 or older.