Hmmm... Tried booting Windows 2000 CD-ROM on the new i440fx motherboard emulation.
It actually starts loading the files! The floppy disk version hanged before it could start loading said files (directly after the RAID/non-something devices press F6 query).
Edit: It gets to the "Setup is starting Windows 2000", after which it ends up hanging the CPU with a cleared interrupt flag HLT instruction? That's at address 0008:803a6089 of the thread:
TR=28:80837000
FS=30h:FFDFF000
CR3=30000

Just tried the Windows NT 4 workstation CD-ROM booting 0n the i440fx emulation.
Somehow, it boots, while failing on the i430fx BIOS?

Just managed to find and fix a bug with compiling UniPCemu using Android Studio, causing the SDL2_net functionality to be virtually unused by the project (it's module is actually compiled and included, but UniPCemu won't call any SDL2 initialization and assumes it isn't included). The old ndk-build method relied on it to have been passed with the ndk-build command line parameters to include said code, while the Android Studio project never would include it.

Said functionality is now automatically included when the ndk-build process in Android Studio finds that a module makefile(Android.mk to be exact) is found in a folder called 'SDL2_net' in the location mentioned in the README.

Although this now means that when said SDL2_net folder contains an Android.mk, you must have the SDL2_net module uncommented inside the org/libsdl/app/SDLActivity .java file, otherwise the app initialization will crash the app(because the SDL2_net module isn't loaded).

One little notice to users of the UniPCemu's Master branch: It is now moved to the default branch instead, to match other well-known repositories

Just implemented support for multiple CPUs (for multiple Pentium Pro / Pentium II CPUs).
The basic framework is already adjusted. Also implemented a proper lock signal for all emulated CPUs(them blocking each other LOCK instructions when multiple appear).
DMA also looks at said signal if to begin a transfer or not(affects e.g. LOCK CMPXCHG or LOCK XCHG).

Also the BIU is adjusted so that it can handle parallel CPUs now.

The only thing that's actually left is the implementation of receiving APIC packets on the local APIC of any CPU that's not the boot CPU. So the APIC packets to the other CPUs won't actually reach said CPU(neither from the IO APIC or using the command register). So that's the last thing left to implement, currently (afaik).
Edit: That's implemented now as well.

The only thing remaining is some Settings menu option to select 1 or 2 CPUs to emulate(currently it's hardcoded at 1 CPU). That's only for Pentium Pro and up.

OK. Having enabled the second CPU, it's receiving a SIPI, but it eventually reaches 8000:10000, which triple faults the CPU because of a #GP(0) fault in real mode that can't be handled somehow?

OK. Having moved all variables to their respective CPUs, somehow all architectures (and CPUs) fail to boot? That's even on the XT?

The Compaq (according to the POST code) even complains about floppy drive port and video card issues?
Obviously, I've broken something with the migration of all CPU variables or perhaps even before that?

It looks like it somehow sets a weird video mode(low-res mode?) on all VGA graphics cards? Huge text is displayed?

Looked through all code but the new CPU core code(the code for each instruction), but didn't find any errors in converting it?
Edit: Managed to find the offending bug: the direct memory access variable(used in the generic CPU support modules) was being used in the CPU support modules, but the actual CPU cores(the 8086 core in this case) weren't all using that variable. That would cause the 8086 to use the non-CPU specific one(which was left over from the move to the CPU) while all other cores properly used the CPU-specific one.

Edit: Then found an issue with regards to some locks on the CPU structures, which would need circumvention when called from within a CPU handler (in this case requiring the simple clearing of the CPU structure using memset() instead of deallocating and reallocating the memory).

Edit: Just adjusted the CPU to be able to execute a locked RESET and INIT. So now the APIC, 8042 and PPI can properly execute a INIT or RESET without the CPU having to need to release the CPU lock to reallocate registers. It will simply clear the registers if such a method is used, fixing the need for a release of the lock while resetting/initializing the CPU.

OK. It takes a while to load(I just implemented the Remote Read Command), but Windows NT 4.0 setup now properly boots from CD-ROM! 😁

Edit: Windows NT 4.0 still only sees 1 CPU installed? Even though the BIOS actually reports 2 CPUs installed? Does NT 4 not support multiple processors over the APIC
It literally says:

11 System Processor [1024 MB Memory] MultiProcessor Kernel

The BIOS actually displays it's having 2 processors? The BIOS is setup for MPS 1.4 and leaves the second processor with the INIT state(thus waiting for a SIPI message).

Just modified the CPUID mode to be dynamically assigned during runtime.

It can now be configured for:
- Modern operation: unknown settings set EAX=EBX=ECX=EDX=0 (Normal operation compatible with most OSes).
- Limited to leaf 1: Limits the reported leaf past 1 to leaf 1 (supporting Windows NT 4.0).
- Set to DX on start: Sets the resulting EAX value to the DX from reset. Leaf is ignored(early Pentium emulation, to support Windows NT 3.1).

Just found a CMPXCHG bug: all arithmetic flags other than the zero flag(other than as mentioned in the processor documentation's operation's section), iow all other arithmetic flags, were missing from said instruction and thus not updated!

Little sidenote: Are these resulting flags even used by programs and OSes?

OK. Having fixed said CMPXCHG bug and RESET/INIT behaviour on the i430/i440fx, reinstalling Windows NT 4.0 from the beginning now fully hangs before showing the mouse cursor in the GUI part of setup?
Edit: That's with 2 CPUs. With 1 CPU it happens like before(triggering a 8042 CPU RESET).

Just adjusted the 80486 CMPXCHG and XADD instructions, as well as the Pentium CMPXCHG8B instruction to properly use the BIU. So now, in both cases, proper bus locking will occur(as it should, especially important in MultiProcessor configurations which UniPCemu can do properly now (up to 2 CPUs)). Previously, it would ignore any bus locks and just executed each instruction atomically(but not allowing other CPUs to take control or race for concurrency as they should(when both CPUs try to take control of the bus, both would have taken 'control' without locking, each executing a locked instruction without taking into account if the other CPU was locking the bus)). It also improves the cycle-accuracy of the 80486 and Pentium in this case, as well with respect to the data read/written without locks.

As a little side note, those were the final instructions that still needed conversion to the BIU and cycle-accurate method of implementation. So now all cores are properly cycle-accurate as they should have been(the 80486 and Pentium weren't fully 100% yet).

Just tried the Windows 2000 setup again... Something interesting happened (not hanging anymore when starting the Windows 2000 setup's post-loading phase), after fixing the CMPXCHG, CMPXCHG8B and XADD instructions to be cycle-accurate and properly locking. That's directly after setup says at the bottom of the intial file loading "Setup is starting Windows 2000".

So it's having a inaccessable boot device instead of hanging now?

Just took a look at Qemu's way of handling the IDE hardware. I saw a few things:
- ATA Read sector(s) command clears the error register (required for Windows apparently)?
- With UniPCemu itself: setting the device signature cleared the selected drive in the drive/head register(incorrect behaviour).
- Resetting a non-existant drive needs to report non-Ready(incorrect behaviour).
- According to Qemu: Starting a new ATA drive command clears the error register?

So two little bugs with UniPCemu's signature and ready status.
And two little bugfixes found by looking at Qemu(the error register being cleared at executing a new command and after a read sector(s) command(for Windows).

Now the long delay at the end of the BIOS (the i440fx BIOS that is) is now seemingly gone! 😁

Edit: Trying Windows 2000's setup reveals something interesting: it seems to say that it's loading Windows 2000, but no actual disk access or anything is performed at all? The status registers are unread and the error register isn't read as well? It just gives the 0x0000007B (0xF2463848, 0xC0000034, 0x00000000, 0x00000000) STOP error when starting the kernel it seems?

Edit: This might have something to do with Qemu's win2k-hack apparently? Is this the cause of it(too fast ATA IRQs for writes apparently)?

Windows NT 4.0 workstation still seems to have the reboot issue? Or is it some corrupt file? Can't seem to get Bochs to POST/boot the i440fx BIOS, though. Can 86box use the Bochs-formatted disk image? With SPT=63, heads=16?

Edit: Just reset most Bochs settings to their default values, enabled the i440fx with the Bochs BIOS, then proceeded to boot UniPCemu's disk image with it. It booted without any issues on Bochs, getting to the step of asking for the NT 4.0 workstation CD-ROM.

So the disk image itself isn't having any errors in it? There's actually a CPU bug in UniPCemu somewhere?

Edit: The final messages I see when comparing the Bochs console against UniPCemu's faults:
- I see both emulators throwing a #GP(0x000B) due to an invalid IRET to user mode with a kernel mode segment selector(0x000B=kernel selector 0x0008, RPL=3).
The first what I see Bochs dump after that is some KBD information(typematic, delay, repeat rate) followed by the parallel port(unsupported bits), then enabling the FIFO on COM1&COM2, finishing with the ATA CD-ROM not having any disc inserted.

UniPCemu I actually see throwing the #GP(0x000B), but didn't check any of the other hardware mentioned after that. I'll need to check that out now...

OK. All I see is command F3 being written to the PS/2 keyboard, followed by 0x20. Then a 8042 CPU reset follows that, which isn't supposed to happen? Perhaps a keyboard issue?
Edit: After looking at it executing, it seems like command 0xF3 never properly entered it's result phase for the parameter being written. Thus the host would never receive the ACK from the PS/2 keyboard!
Edit: That's fixed now. The kernel still seems to error out on a page fault at C1140000 now, though? CR3=3945000 now.

Someone gave me a good tip today: try to use another PC, VM or editor to view the NT 4.0 log files from it's boot.

So I'm going to finish setup on the Bochs machine(also i440fx with 1GB RAM installed), then create a copy of the disk image (to get a bootable NT machine), then use said copy of the machine's event viewer to view the events that last happened when the UniPCemu machine crashes. Perhaps that will show me what driver or file is going wrong?

Setting Bochs to 10MIPS(like UniPCemu) made the setup finish pretty fast. I should be able to view the EVT log using it? Simply let UniPCemu run until it crashes, then use the copy with the finishes Windows NT 4.0 setup(which runs fine on Bochs) to view the EVT log in UniPCemu's copy of the disk image?
Or will the NTFS file systems clash with each other because of duplicate drive IDs?
Edit: OK. No EVT files were created during said failed boot. Perhaps I'll try to boot the Windows NT 4.0 fully installed copy from Bochs using UniPCemu itself? Perhaps that'll result in something interesting being logged?
Edit: Just tried the fully installed version from Bochs. It seems to get past the initial login screen, logging in as the Administrator, but after that it says it's loggin in and crashes with a BSOD. It's giving me:

1STOP: 0x0000001E (0xC0000005, 0xA0018748, 0x00000000, 0x000001E0) KMODE_EXCEPTION_NOT_HANDLED*** Address a0018748 has base at a0000000 - win32k.sys
2
3CPUID:GenuineIntel 6.3.3 irql:1e   SYSVER 0xf0000565

OK. The 1F0 value is the memory address it page faults on(a 32-bit CMP instruction)?

The instruction stream executed is 39 7e 10. It's 32-bit code.
So it's CMP [ESI+10],EDI...
ESI=EAX=0x1E0...

All segment registers are the main boot thread(CS,FS,TR). LDTR=NULL. CR3=0x30000.

Edit: Oh.... Said crash will happen, even when not pressing Ctrl-Alt-Del and logging in. So the issue is somewhere much further down the OS! It has nothing to do with the actual login process!
At least that excludes said cause from the list of causes.

So CR3=30000, Breakpoint at 8:0PI and FS=0:FFDFF000O as the breakpoint settings should in fact log the offending program. The BSOD will always happen, so it's guaranteed to actually log the offending instruction? (The remainder of the settings is as usual:
Debugger mode: Enabled, just run, don't show, ignore shoulder buttons
Debugger log: Only when debugging, common log format
).

Just started working on making the Paging mechanism acquire a bus lock for the current instruction when accessing the paging structures in memory. That would allow it to properly handle the read-modify-write cycle when needed and properly handle it in MultiProcessor configurations.

Unfortunately, currently this new method should work with some minor adjustments to the code, but somehow it's even hanging the test386.asm check #08 (the startup routine of paged protected mode) when enabled in the Paging module.
So I still need to figure out why it's actually failing when requiring the BIU to acquire locks. Perhaps something to do with the startup routine in the test386.asm tests (check #08h)?
Edit: Hmmm... After adding a few more special cases to the paging waiting-for-bus-lock support(don't finish executed(to fix instructions finishing execution otherwise, by default) and perform the reset of registers(to a start-of-instruction state) to allow hard instructions, like IRET, to behave properly in protected mode when performing paging, which requires the registers to be properly at their starting state when executing), it seems to properly handle being able to perform in protected mode with Paging again(at least with the test386.asm testsuite).

Now at least the test386.asm testsuite seems to be able to complete it's testing without any visible issues.
Edit: Windows NT 4.0 doesn't seem to like it. It immediately crashes when booting with a "Trap F000FA22" error like OS/2 used to have (although I didn't check those operating systems for a while, since getting Windows NT 3.1 booting).
Disabling the new Paging function(returning 2 to make the parent caller functionality start pending and the bugfixes mentioned above for test386.asm) causes Windows NT to properly boot again, at least until the point the hang(setup) or crash(completed Bochs installation) is encountered.

So there's still some issue with the Paging locking the bus left?
Edit: After modifying the Paging locking to not reset the CPU registers when not exercuting an IRET, interrupt or task switch, it seems to fix Windows NT 4.0 to properly boot at least? It reaches the same old point where it triggers a CPU reset through the 8042.
Don't know if there are any other errors left, though.
Edit: OK. Windows 95 "C"(OSR 2.5) seems to fail booting with a Protection Error Black Screen of Death, when the new Paging with locking feature in UniPCemu's code is enabled? Perhaps something to do with the 16-bit support somehow going wrong or awry when combined with Paging(which NT barely uses, if at all)?

OK. Hiren's bootCD also crashes with a double fault on a PUSH EDX instruction with ESP way above the limit of the stack segment? Perhaps some issue with switching stacks to kernel mode now, with the Paging locking enabled?

Even OAKCDROM.SYS under MS-DOS with EMM386 loaded seems to hang(even executing a FFFFh #UD instruction!).