Hmmmm.... I do see it writing the drive head a bunch of times after the DEVICE RESET command? And then checking the status register, which only seems to indicate busy?

During the device reset, it's reporting a status register value of 0x80, so not ready(because it's resetting) and busy? It never seems to become ready to process a command, before executing a new drive select by writing the drive/head register? Or is it not supposed to become more busy(resetting the timer for the drive select timeout) when it doesn't toggle the drive select line?

Just implemented an IRQ to trigger when an ATAPI device receives command 0x08(DEVICE RESET command for ATAPI devices). I now see it properly executing a 0xEC IDENTIFY DEVICE command(which aborts of course), then a 0xA1 IDENTIFY PACKET DEVICE command

And after that, a PACKET command

Edit: Huh? Then a read sub-channel command?

Edit: After that one errors out, though, OAKCDROM does seem to execute a REQUEST SENSE command?Edit: Then it executes command 0x00 again, which of course gives a not present CD-ROM error sense(code 0x20 in the error register).Edit: Then another REQUEST SENSE ( )...

Then another read sub-channel, which of course still fails...Edit: Then mode sense. And it then continues

Edit: OK. Now to change the inserted disk...Edit: OK. The dir starts...It uses command 0x00, then REQUEST SENSE for the new media?Then Read TOC... It gives a MEDIUM NOT PRESENT(then a drive not ready immediately happens in the MS-DOS prompt)... That's a REQUEST SENSE...Then a CD-INSERTED EVENT happens(from the disk change)!Eventually(read TOC still waiting), it gives a 0x02,0x28,0x00 error(Medium is ready (has changed)).Then a REQUEST SENSE.And then another READ TOC, which succeeds Then a Read Sectors, with LBA 0x10(16)

Edit: More sectors follow, and it fully sees the new disk having been inserted, with the new directory list

But that only seems to happen with the OAKCDROM driver? The VIDE-CDD.SYS driver seems to utterly fail at that?

Do I see that correctly that the A0 command (or any ATA command valid for ATAPI) clears the error bit in the status register? Doesn't sff8020i / ATA/ATAPI-4 say it's only cleared by a Request Sense command?

Just thinking about something... What is the purpose of having index 02-99 inside a cue sheet? The software only sees the whole track, doesn't it(using the read TOC command)?

So what happens when you have index 01 and 02 inside a data track? Or an audio track? So far I've only seen tracks with index 00(pregap data in the backend file, HTOA) and 01(the actual track data). What's the purpose of indexes 02-99? What are they used for? Can software even address them individually? Read TOC only gives a whole track after all(thus all indexes)?

Just saw the Read TOC instruction be handled a bit odd. It was generating enough data(just now improved with full track packets instead of a fabricated track 1 only(for the whole cue image, while it's actually supposed to give multiple tracks for such a thing(depending on the amount of tracks in the disk image)), but the parameters it got in the command packets(of 12 bytes long) were read, but incorrectly shifted to their results before being OR-ed to form their native value(e.g. the length fields bytes being combined into a 32-bit integer were using shifts of 0,1,2,3 instead of 0,8,16,24 ).

Just improved the Read TOC command a bit. It's now properly reporting the A0-A2 records for mode 2 and all tracks being listen instead of just track 1(what Bochs/Dosbox does). I also adjusted the mode 1 result to properly give the track 1 information and starting address. Mode 0 is unchanged, as it already reports according to the standards.

Also, just a confirmation, is mode 0 the only mode that gives MSF and LBA results(based on the bit in the command bytes) instead of always MSF results(like mode 2) or LBA results(like mode 1)?

I managed to improve the cue/bin disk image format quite a lot. It now supports all the different combinations of pregap, postgap, index(only index 1 and up, index 0 counted as invalid to read(as it's pregap)). The data read commands now properly support all different kinds of .cue disk image formats(CD-DA, 2048 byte tracks, 2352 byte tracks in both 2048 byte and 2353 byte read modes). I also added support to the cue sheet parsing and ATAPI emulation to properly skip the pregap/postgap regions for read commands(e.g. read(10/12), read TOC, read MSF etc.). The only basic CD-ROM thing that's not yet supported is the audio commands, but the basic data read commands should all be working fully with both ISO files(sectors converted from LBA like Dosbox, with the 2 second pregap) and standard CUE files(as long as the backend is of type binary) without any extensions.

So far tried various games with the new cue image file support(so far gotten only Earthworm Jim 1 running for those, as the others seem to have still unknown CPU problems(some even complain about no SVGA adapter, even though a ET4000 is pretty much fully emulated on the graphical modes(just not the enhanced text modes, WhatVGA keeps aborting them and returning to the main menus on those for some odd reason).