After meddling with the code and looking at the manuals again, it seems it required the Interrupt Reason(which is stored in the Read-only ATA Sector Count register on ATAPI devices). After having implemented that, it now proceeds to send the packet:D (Testing with the MS-DOS 6.22 OAKCDROM.SYS).

So my current work is a combination of the ATA-1, ATA/ATAPI-4 for CD-ROM support and https://www.pjrc.com/mp3/gallery/cs580/ata_atapi.html for the more exact way it's handled.

It's now executing an ATAPI Inquiry command and aborting for some odd reason after it's sent?

The interupt reason is set to 3h, which should be saying it's to receive data from the ATAPI device?

Edit: Strangely, the Byte Count that's requested to transfer isn't 36h(the size of the Inquiry Result), but instead of that it's 0?

After changing the definition of a byte count of zero to mean infinite(implemented as one more than the maximum buffer size of a block), it now reads the entire result of the Inquiry command. But after that, it aborts instead of accepting the result for some reason?

Current code: https://bitbucket.org/superfury/unipcemu/src/ … ide.c?at=master

It reads until it completes the data phase(reads the entire Inquiry data from the data ports), then gives up on the CD-ROM device?

Edit: The current code revision: https://bitbucket.org/superfury/unipcemu/src/ … ide.c?at=master

The remaining parts have been adjusted, but why does OAKCDROM.SYS reject the drive? It should receive an interrupt after a final BSY with DRQ being cleared? Or is there a problem with the data that's transferred(Inquiry result data)? Most of the buffer is cleared out, only three bytes are filled:

1//Now fill the packet with data!
2		ATA[channel].Drive[ATA_activeDrive(channel)].data[0] = 0x05; //We're a CD-ROM drive!
3		ATA[channel].Drive[ATA_activeDrive(channel)].data[1] = 0x80; //We're always removable!
4		ATA[channel].Drive[ATA_activeDrive(channel)].data[3] = (4<<4); //We're ATAPI version 4, response data format 0?
5		//Leave the rest of the information cleared (unknown/unspecified)

Or is something required missing? Does OAKCDROM.SYS require DMA?

A little improvement on the data returned by the Inquiry command: https://bitbucket.org/superfury/unipcemu/src/ … ide.c?at=master

That's based on the sff-8020i documentation and Bochs.

The OAKCDROM.SYS driver still rejects the drive and refuses to see it. It aborts after the last byte is read from the buffer? Can anyone see what's going wrong? Why is the driver rejecting the drive(Not starting the result phase)? It will BSY for 20us with DRQ cleared(nothing left to transfer). After that, BSY will clear and the result IRQ will be fired with COD and IO set in the Interrupt Reason register. Shouldn't that make the driver continue with new commands or information?

Just tried the VIDE-CDD.SYS on my Compaq 386 emulation: it properly detects both Secondary Master and Slave correctly as CD-ROM drives.

Then I start up "MSCDEX.EXE /D:MSCD001"(without quotes) at the command line. It(or the driver) emits a MODE SENSE(10) and a SEEK ATAPI command, then gives up saying there's not enough drive letters. Adding the LASTDRIVE=Z directive to the CONFIG.SYS makes it properly add the two drive letters. 😁

Inserting the Megarace CD-ROM and trying to read the TOC seems to crash it atm(due to buffer overflow in UniPCemu). But at least it's trying to process it:D

After having fixed that, it properly reads the TOC and tries to execute a read(10) command. This command simply aborts, because the drive isn't spinning?

After modifying the drive access commands(stuff like reading TOC and CD-ROM data) to spin up the CD-ROM, it now proceeds to read the Primary Volume Descriptor off the CD-ROM! 😁

Something strange is happening as well: when a CD-ROM is already inserted when the drivers and MSCDEX are loaded, executing a MS-DOS dir command on the CD-ROM drive hangs the system, not executing any commands(probably due to the finish phase of the seek command)?

Each time it emits a seek command, it will hang the entire operation?

Edit: It simply takes a long time(for some unknown reason) to execute the virtual seek. After that, it properly lists the root directory contents of the CD-ROM drive! 😁

Just tried executing the install.exe from the CD-ROM drive. It crashes and displays all kinds of garbage on the screen below the command prompt, together with a beep sound from the PC speaker.

Edit: Found a little problem with detecting the disk size to be 4 times smaller than it's supposed to be(shifted right by 2 instead of no shift).

When looking at the disassembly of the VIDE-CDD.SYS/MSCDEX.EXE drivers, it looks like it's waiting a long time for the Drive Ready bit to lower?

Edit: It seems to be waiting for the DSC bit to set?
Edit: It was indeed expecting the ATAPI Seek command to set the DSC bit to identify it has seeked to the sector(is that even possible on a CD-ROM?). Now the delay is entirely gone.

Edit: The CD-ROM now reads files without problems or delays:D Now the only problem left is probably the 80386 CPU, which is messing up when running INSTALL.EXE or INSTDOS.EXE.

The installer is working properly now, but cannot run because MS-DOS and the CD-ROM drivers(+HIMEM.SYS and mouse driver) take up too much Conventional memory. So I tried adding EMM386.EXE from MS-DOS 6.22 after HIMEM.SYS and loaded some other device drivers high. Now, after fixing the CPU to mask it's flags properly again for CPU detection(EMM386.EXE not rejecting the CPU to be a non-386+ CPU), it crashes with a 0xFFFF instruction(GRP5 /7 instruction), which doesn't exist in the x86 instruction set. I see the previously executed instruction was at 1934:0000, which seems quite odd as well(why would an MS-DOS application start at that location, except if it's a .SYS device driver or .COM executable?).

After extending the kept information to keep all information about the previous execution point, I've end up at 1934:0FAE. So that should be the cause of the invalid instruction, if not sooner.

Edit: I cannot find anything other than that location. 1934 is the program executing, but the exact start of the EMM386.EXE application is unknown?