No idea, sorry. At the time we used Win95 in the family, none of the PCs had got ATAPI devices installed.
While my papa's 386DX40 had got an Mitsumi LU005S with a proprietary ISA card (Win95 relied on its DOS drivers),
I had got a SCSI CD-ROM drive connected to a Pro Audio Spectrum 16 sound card.
On OS/2, I hadn't used an ATAPI CD-ROM drive before Warp 4.x.
Warp 3 had got drivers on-board for popuplar Sony/Mitsumi/Philips and various SCSi controllers,
which was good enough for us. Still makes me wonder why emulators writers aim for ATAPI support at all,
if all major OSes of the past supported better alternatives, anyway. 😉

I've improved reset behaviour for ATAPI devices to make it stop being ready for all kinds of reset(including RESET DEVICE command and SRST).

During boot, I see (for both ATAPI devices):
1. RESET DEVICE
2. ATAPI Inquiry command
3. RESET DEVICE

Directly after the second drive(the secondary slave), I see Windows 95 throwing the protection error(the please reinstall windows message on black background on the top row of the 80x25 text mode).

Perhaps a driver issue? Previously it wasn't seeing the drives or executing ATAPI commands at all(due to the registers being read-only with reset values).

Hmmm.... Weird... When Windows 95 issues an Inquiry command to the CD-ROM drives, it doesn't seem to receive the IRQ(due to the mask register or interrupt flag disabling it?), and while the hardware raises the IRQ to make the OS read it's Inquiry data from the data port, it executes an DEVICE RESET command(the IRQ still not acnowledged by the PIC)? That reset command clears the IRQ line back to low state, thus clearing the request from ever happening?

Edit: Hmmm.... When the hardware raises it's IRQ, the PIC becomes ready to handle said interrupt. But the 0x08 RESET DEVICE command happens before it has the chance to tell the CPU because the interrupts are seemingly disabled during that period?

Looking into it some more(besides improving the detection of the PIC OCW2/OCW3 commands being written according to the 8259A documentation), I see that the interrupts are properly enabled in the interrupt mask register, the interrupt(after it's started to process) is correctly raised, the PIC is ready to handle the interrupt, but the interrupt flag doesn't become set again to actually handle the interrupt, resulting in the driver executing the DEVICE RESET command before the PIC has the chance to raise an interrupt for the Inquiry result?

Hmmmm... Just found something when looking at the ATA/ATAPI-4 documentation, chapter 9.11.

Apparently ATAPI doesn't raise an IRQ but sets the interrupt reason register for the command when it's ready? UniPCemu currently still raises an IRQ at that point. Perhaps that's the issue?

Edit: After fixing that, I see it executing other ATAPI commands(Request Sense and Test Unit Ready), properly booting up! 😁