I have it returning 0xFF for all registers except status (0) if the drive selected is not present. If I remember correctly, some of the Pentium BIOSes were quite picky about this behavior.

UniPCemu now does the following:
During reads:
- Unused(unmapped due to no drives being present) drives float the bus(thus return ~0).
- Controller without drives float the bus during reads from the normal registers(x0h-x7h).
- Alternate status gives 0 when no drive is present on the selected channel.
- Drive address register gives 0 when a controller isn't present(no master or slave present).
- x0h with no drive floats the bus(data register read) for all possible sizes(byte, word and dword).
- x7h gives 0 when no drive is present on the current channel.
During writes:
- Writes to an not present drive's master/slave data register are ignored.
- Writes to registers x0-x7 without any drives present there are ignored.
- Data register writes without selected drive present are ignored.
- Features/sector count/Sector number/Cylinder low/Cylinder high write to master and slave simultaneously, but only when said drive is ready(for proper detection, according to ATAPI documentation on needing to send a packet command to enable writes to said registers).
- Drive/head register writes to the selected drive(bit 4 that's written) only. All bits but bit 4(DRV bit) are protected against changing until enabled with the packet command(same as feature registers etc.).
- Command register writes are ignored when no drive is present on the selected drive.
- Control register(with SRST etc.) doesn't write it's value and it's effect(because the value's unchanged) when no master or slave is present.

That's all the I/O ports as UniPCemu handles them now. And that's both for ATAPI and ATA drives.

For some reason, Windows 95 properly detects the primary master/slave configuration(perhaps with some help of the XT-IDE Universal BIOS that's compiled with 80386 and the Windows 95 hack) for the harddisks now. 😁

But while it seems to have detected the secondary ATA controller(at 170h/378h(as it's defaults are for the value 0 in the PCI configuration space(when the BARs are zeroed))), it doesn't see the CD-ROM drives that are connected to it? Does it require some strange behaviour to see the CD-ROM drives? Or perhaps some extra customization that needs to be done for it to load CD-ROM drivers in the GUI for it?

The System (accessed by My Conputer (right click) > Properties, tab Devices) doesn't show the CD-ROM drives in there. Just two ATA controllers with one containing the Windows 95 HDD drive and (when mounted) the second hard drive on the same controller.
No CD-ROM drives are displayed?

Hi, did you check if your CD-ROM Drive emulation works, at all ?
What happens if you install MS-DOS drivers, like OAKCDROM.SYS or VIDE-CDD.SYS ?
Does this make Windows 95's internal MSCDEX-replacement detect the drives, perhaps ?
If not, you could also add MSCDEX (DOS) to Autoexec.bat and see if your CD-ROM emulation gets along with that one, at least.

I've managed to improve the ATAPI drives a bit. I took another look at the special ATA vs ATAPI drive behaviour regarding the reset(SRST) and RESET DEVICE command. I changed the RESET DEVICE command to no longer generate an IRQ on completion. I also improved the 8-bit mode(feature 01h/81h to toggle) to change I/O to only respond to 8-bit I/O when enabled(feature 01h).

I also changed the write protection on all r/w registers to no longer apply when the DRDY bit is cleared permanently(until it received a PACKET(PACKET/IDENTIFY PACKET DEVICE) device command) due to the ATAPI needing to report non-ready(according to the ATA/ATAPI-4 specs, chapter 9.4 DEVICE RESET protocol.
I also changed the RESET DEVICE command to, instead of setting the error register to 01h or something else, only clear bit 7 of it(according to chapter 9.4).

Windows 95, when having detected the secondary ATA/ATAPI controller(at 170h/378h), seems to do three things when enumerating it during booting(The second ESDI_506.PDR that's being initialized):
1. Write and read back the values in the cylinder registers(previously failing due to being read-only on ATAPI devices).
2. Execute the ATAPI PACKET command, sending an Inquiry command(Checked it running the command itself, didn't verify what happens with the result itself(if Windows reads it properly).
3. Execute the RESET DEVICE(command 08h) command.

It does those three once for the secondary master and once for the secondary slave. Then it gives a pseudo-BSOD(black screen with an error message in the top-left, on the first row of the 80x25 text display):
"Windows protection error." etc.

The last line in the bootlog.txt is still the second ESDI_506.PDR being initialized, no success line following it.

Weirdly, during the Add device wizard, I noticed that it somehow detects a PS/2 mouse(causing problems with the mouse when rebooted)? There is no PS/2 mouse installed into the system(just a PS/2 keyboard on a 8042 controller)... Perhaps a 8042 controller issue? Or a CPU issue itself?

Edit: The CD-ROM might be working fine. OAKCDROM.SYS+MSCDEX.EXE combo seems to run just fine from the Windows 95 A setup floppy, booting into setup just fine(although still having those RETF to E0 from CPL3 issues?).

Just been thinking... What is the maximum theoretical RAM supported by the Compaq Deskpro 386 BIOS? 16MB? I've just changed the mid memory block to end at FA0000 instead of F00000. Now, instead of 15386KB of RAM, the BIOS detects 16000KB of RAM.

Would it be possible to extend past 16MB now? I know that FA0000-FFFFFF is the memory area that contains the RAM/ROM memory(the low memory hole being remapped there by the hardware). Does the BIOS check past that 16MB RAM block?

Edit: Installed 17MB of RAM to test... The Compaq BIOS only detects 16000KB(memory ending at FFFFFF). I currently have the memory holes as follows:
0-9FFFF: Low memory
A0000-FFFFF: memory hole, of which:
E0000-FFFFF: remapped to 15MB ahead(at FE0000-FFFFFF).
100000-F9FFFF: Mid memory
FA0000-FE0000: Compaq reserved memory. R/W
FE0000-FFFFFF: Compaq reserved memory. BIOS ROM area uses it for shadowing. Can be made read-only using the register at 80C00000. This is also visible at E0000-FFFFF.
1000000-C0000000: Remainder of memory that's left unmapped. There's the memory-mapped register at 80C00000 for the Compaq chipset, though.
100000000-*: Any memory that's more than usual 32-bit software can address. Currently 'usable' due to being mapped, but unusable due to lack of CPU support(requires extended paging with newer processors than the plain Pentium).
UniPCemu now can use the entire 16MB range with the Compaq systems. Of course 128KB of that is unusable due to the BIOS ROM shadowing that the Compaq BIOS uses. So that's a total of 15872KB being usable, according to MS-DOS. In my case it's a bit less(1KB of low memory below 640K being used by the XT-IDE BIOS).
But now, the entire 16MB is actually adressable by the OS(if it disables the write protection and remapping of the 80C00000 register(setting bits 0&1 of said register)). If it does that, the entire 16MB RAM is writable by the CPU(640K low, 15MB extended).