When lo_ej is 0 the command is used for manual spindown/spinup.

So when a disc is inserted, automatic spinup follows, which after a timeout performs automatic spindown(e.g. 10 seconds of inactivity)? And using lo_ej 0 performs that manually(allowing it to spin down faster(e.g. 1 second(some minimum spindown time to stop the motor) after the command is sent instead of after 10 seconds of inactivity) or perform a spin up without any data access when a medium is inserted(although automatically spinning down after 10 seconds))?

OK. Just now wondering about something: is the error code reported(02/3A/00), which is NOT READY(OPTICAL DISK CARTRIDGE NOT INSERTED) reported for all cases where no medium is present? I understand for when the tray is actually ejected, but is that also the case for when the caddy is inserted and not containing any medium?

Is there a different code to report when the tray isn't ejected and no disc is in the drive?

Managed to add a few new states to the Dosbox-X based disc spinup/spindown/insert scheme.

First, the insert time is an addition of 2 timings, which are a human change speed(e seconds) and a 1 second extra time by default for retracting the tray into the drive(total 4 sec like Dosbox-X).
There's a small difference, however. UniPCemu now also counts ejects as a valid state. So that's a 1 second eject time, after which the counting simply stops. When counting or finished counting the eject time, said time will be used when retracting the drive(by the eject button on the virtual drive or start/stop load tray command). When such an event starts, it'll start the CD-ROM insertion phase of Dosbox-X. Said time is always 4 seconds on Dosbox-X, but UniPCemu now instead counts 3 seconds(slow human speed) or 0 seconds(when using the start/stop unit command). To that time, the remainder of the time not spent on ejecting the tray(in other words, the amount of seconds(up to 1, which is the tray fully ejected, 0 seconds left becoming 1 second timing added instead, currently)) is substracted from the 1 second the drive takes to eject the tray to obtain the amount of time the drive spent moving out of the drive(between 0 and up to 1 second). That time is essentially how far the tray needs to move to retract into the drive. That calculated time is added to the previously mentioned 0 or 3 seconds, to get a range of 0 to 4 seconds to retract the tray and start the spin up phase's timing.
So that's usually first 1 second to eject the tray, 3 seconds to change a disk(if human, 0 otherwise), 1 second to retract the tray and finally 1 second to spin up the spindle.

Of course there's still a 10 second timeout to spin down and become idle(following after any data accesses reading from disc, if any). And the drive can now be manually spinned down using the start/stop unit with loEj=0 to stop it manually(in 1 second time).
Mostly the ejecting mechanism(and fast(software start/stop unit)/human(currently unused) ejected timings) and status, as well as start/stop of the spindle (both taking 1 second) is now added to UniPCemu's code.
Another new thing is that the Settings menu now has CD-ROM eject (or load when ejected) buttons added, which perform the start/stop unit commands according to the sff8020i ATAPI protocol's requirements with the new timings.

So you can now properly eject the tray when software locks the drive and uses the Microsoft Removable Media Status Notification protocol extension (Which should now be properly detected).

Just added a missing feature to the changing of CD-ROM mounted images. When the CD-ROM drive isn't ejected, it won't allow the disc to be changed until the drive is actually ejected(essentially doubling as a eject button when choosing to select a disk image), while now also preventing changing the disc for any other (or the same) disc image when the tray isn't ejected.

That way it fully works like a combination eject button(when not blocked by software) and works more like an actual CD-ROM drive (properly ejecting the drive when required and not being able to insert a disc when the tray isn't ejected).

Just found a little bug in the automatic ejection feature of the Settings menu mounting of new discs. It was always ejecting the second CD-ROM drive, instead of the one actually selected to remount or unmount.

OK. How does Windows 9x detect if a ATAPI drive tray is opened or closed? The result of the Test Unit Ready command is currently NOT READY/MEDIUM NOT PRESENT/02h for ejected caddy and NOT READY/MEDIUM NOT PRESENT/01h for inserted caddy without media. But according to WinCheckIt 4.0, the drive has the tray open with no media inserted?

OK. PC Doctor 3.0 seems to properly detect the door opened and closed now.
Windows WinCheckIt 4.0 still doesn't see any difference?

Hmmm... What happens if the software requests a loEj=1,start=1 command while the prevent/allow is disabled and the removable media status notification is enabled? Does the removable media status notification count as a prevent, preventing the loEj=1,start=x from loading/ejecting the tray? Or does it just affect the eject button on the drive?

I've just been thinking... Is the MCR bit also set and no action taken when the user wants to insert a disc into the opened tray? So when the tray is open and a disc is present or not, what does the eject button do? Will the drive retract the caddy itself without notifying the OS and letting it handle it, or does it set the MCR bit as a response to a GET MEDIA STATUS command, making the OS perform the start/stop unit command to retract the disc into the drive?

So, as I've now implemented it:
- The start/stop unit command only is blocked by the prevent/allow medium removal bit.
- The button on the CD-ROM drive does one of the following things:
-- When unlocked and tray inserted, ejects the tray.
-- When locked and tray inserted, set the MCR bit read when the Get Media Status command is given(said command now works properly on win95 OSR 2.5(missing and incorrect status setting of the ERR/unit attention bit(buffer overflow))).
-- When ejected, insert the tray into the drive and start spinning up (1 second load, 1 second spin-up). Previously this was blocked and also caused the MCR bit to set. The effect was that Win95 kept issuing start/stop unit with loEj=1,start=0 to eject the tray instead?

Is it correct that the button only sets MCR for ejects, but not for the tray being inserted(just ignores lock&prevent/allow and spin up once loaded the tray into the drive)?