After some more testing, I found some weird things going on with the OPL2 KSL ROM that was taken from Dosbox or something like that I think (I don't remember which) together with the other volume envelope logic.

Somehow, when I move the KSL lookup table outside said function (which is displaced by 8 apparently, based on the ROMs), the sound for OPL2/OPL3 goes haywire for some OPL3 testing songs I used? Can't seem to figure out why that happens.

Managed to get NT 4.0 workstation booting properly again during setup (phase 2, so after the formatting and copying the OS files over for the graphical stage of the boot). 😁

Weird... When executing opcode 86h from a MS-DOS 6.22 install disk 1's scandisk when aborting while performing a surface scan (screen cleared due to returning to MS-DOS), the BIU managed to enter an invalid, bus locked state. There is a request still pending to be executed in the inbound request buffer, but it's never retrieved to be started it seems, causing the EU to lock up, permanently waiting for the result.

Edit: It seems to have been an issue with the IPS clocking mode handling, where it thought the operation was finished (and thus removed the handler from any pending state as it should), but it wasn't.

Having fixed that, the hang disappeared.

After more testing, I found another bus lock contention.

In this case, somehow the CPU managed to lock the bus, while a DMA transfer had ownership of the bus, which obviously shouldn't happen.
This caused both the DMA controller and CPU to lock up, waiting for ownership of the bus (the CPU due to a normal instruction or hardware imposed lock(protected mode etc.), the hardware (DMA) due to trying to complete a transfer).

Once again took a look at the bus lock policies (which are now entirely owned by the BIU in the lastest commits). Adjusted the HLDA mechanics to properly detect an inactive bus (instead of just checking for DMA, checking for any kind of active bus counts there now). The HLDA output now also takes into account if a bus isn't locked before granting the bus.

Eventually reached the point in WIndows NT 4.0 setup where it's writing the recovery disk (after formatting it using floppy disk controller format commands). Somehow it manages to error out on writing the first sector it tries to write somehow?
I've added some bugfixes to force seeking during such an access, but I'm not sure it worked until I get setup back to said point again (which has to restart from the first reboot step each time I test it for WIndows NT 4.0).

Last time, the bus lock was hanging the system (due to multiple locks being held at the same time that shouldn't), so I couldn't continue even if I wanted to. Currently waiting for it to reach that section again to verify if it works now (it should in theory, but I'm not sure).

Fixing a floppy disk scanning (sector ID reading) issue (during read/write/read ID commands), the floppy now properly writes the NT4 ERD again during setup as it did before. 😁

Odd... While testing my emulator, all of a sudden my display started erroring out (Windows 10 Pro) and the OS requested me to reboot. Looking at the hardware list in my PC (although 7-10 years old and upgraded a bit (except the motherboard itself and the GPU) through the device manager showed that somehow the APIC, DMA and some onboard components required a reboot? Normal SDL3 applications shouldn't cause such issues, or do they?
Windows seems to be up-to-date, except the 2025-07 update that's optional.