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.
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.
Implemented some more bugfixes, including:
- Improved time support (properly supporting negative Unix timestamps internally now!)
- Emulator time protection. Somehow, sometimes (like during paging trashing on the host machine) the time elapsed that's reported on the application can make a big jump (on the high precision timing support). This caused the emulator to wait for a very very long time. When the main loop detects this case, it will now simply discard the elapsed time to synchronize it back up, after which it runs on a normal speed again. This case usually doesn't happen, but will cause possible speedups, which can't be avoided (the alternative being having to wait for a very long time that effectively didn't happen, which happened before the bugfix).
Improved x86 task switching and interrupts handling of the EFLAGS register.
It now supports conditionally setting, clearing and unaffecting the EFLAGS resume flag (RF).
Now, when detecting the interrupt to launch, it will itself trigger a set of the resume flag on the stack (or TSS for task switches), if it's not a debug interrupt (interrupt number 01h, triggered by a debugging cause).
Thus it should behave just like Bochs and the documentation on the resume flag (either setting it or leaving it as the instruction left it during the time the interrupt was launched).
Since said flags storage are always based upon the committed state of the EFLAGS by default (if not affected), the documentation for said flag should behave properly now (instead of always setting it during INT1 debug interrupts (except the INT1 instruction of course, which is a trap, not a fault)).
So the version is set to 02h, which might need to be 00h?
Edit: Continuing anyways, I get:
1kd> g 2HAL: An invalid V86 opcode was encountered at address 2000:f76 3Break instruction exception - code 80000003 (first chance) 4halapic!HalpOpcodeInvalid+13: 580191983 cc int 3 6kd> g 7Break instruction exception - code 80000003 (first chance) 8 9A fatal system error has occurred. 10 11******************************************************************************* 12* * 13* Bugcheck Analysis * 14* * 15******************************************************************************* 16 17Use !analyzebugcheck -v to get more information. 18 19BugCheck 7B, {fc90e63c, c0000034, 0, 0} 20*** Bugcheck Analysis may not be correct, please followup with the following. 21Followup : MachineOwner 22 23ntkrnlmp!RtlpBreakWithStatusInstruction: 24807e984c cc int 3
Some more interesting stuff, but first need to patch the revision of the hardware to 00h instead of 02h.
Edit: Also interesting, once that V86 opcode issue was encountered, the screen of the installation turned red? Maybe it was trying to perform a red screen of death?