Just fixed the ET4000/W32i/p emulation to properly render the sprite again. It was using the old attribute controller output field overrides instead of the proper latched output it's supposed to use. This fixes the Windows mouse cursor to render properly when hardware accelerated again.

Managed to get Windows 3.1 booting into standard mode again. Hopefully no more crashes now.
Although I did experience a 'Stack error. System halted.' running edit.com inside MS-DOS 6.22 after typing a little bit?

Hmmm... Running the Pink Panther in Hocus Pocus causes the mouse to still respond, but Windows to hang?

Managed to fix faults and interrupts combined with the EXT bit. Now that should be handled correctly (instead of the EXT bit incorrectly affecting the interrupt processing itself).

CheckIt 3.0 still crashes during it's Interrupt Bug test, however (on a near RET to a 0000 MOV [BX+SI],AL followed by FFFF #UD). The near RET looks fine, but the stack seems weird or corrupted somehow.

Right now running Memtest86 4.3.7 on my emulator. So far gotten to Test #7 [Moving inversions, 32 bit pattern] Pattern efffffff with 0 errors. So the BIU is probably running without errors. Though that takes an entire weekend and 6:30:23 of emulated time (running at 10% realtime speed, so that's actually 10 times longer in reality).

Found a little bug in the descriptor loading of the LTR instruction and loads of TR during TSS task switching. It was interpreting the results of the faulting/pending descriptor load incorrectly during pending operations, handling it as a fault-type interruption when it shouldn't.

Hmmm... Plain win32s 1.3o runs fine (FreeCell including #NM faults for emulation), but Pink Panther in Hocus Pokus Pink hangs during a #NM with it's installed #NM exception keeps returning to the #NM instruction non-stop?

Just adjusted the SMM save state map for SMI and RSM to be loaded and saved through the BIU as well, not using direct memory accesses anymore. This is done the same as the protected mode memory accesses.

That should make all normal CPU operations to be using the BIU to access memory in all cases, no longer using the old direct memory accesses.
Edit: From what I can see, only the emulator's internal BIOS and it's callbacks (required for booting the emulator) use the old from-CPU direct memory accesses. There's modr/m too, but those should only be in register mode, thus unaffected (IMUL register, LXS register(the offset one), cr/dr/tr registers).

Searching around for a suitable candidate to implement my i450gx emulation, I think I've found a good one with the hardware I'm emulating on my emulator:
https://theretroweb.com/motherboards/s/acer-x3

It seems to have all I need (including the documentation I already have on all the chips that aren't fully emulated yet).
Although the BIOS ROM chips still might need some investigation on what kind they are? Anyone knows?

OK. Running the i450gx BIOS I found a big bug in my emulation: I had the northbridge's PB and MC chips' device numbers swapped. So the PB accesses (according to the manual) went to the MC chips instead and vise versa for the MC chips being addressed.

That explains why I kept seeing the addresses that only exist on the PB on the MC chips PCI accesses instead (which was indeed incorrect).

But I see the BIOS just loading the default values (mostly) into the northbridge's PB chips? It never addresses the MC chips at all and simply seems to give up in a CLI HLT JMP $-2 instruction?

It seems to setup the auxiliary PB chip now, followed by the PB chip, with BIOS ROM set to defaults, then fully gives up with the full processor CLI HLT stop.
Edit: After some PCEB/ESC initialization bugfixes (during PCIRST#), it now seems to get into a POST reboot loop for some reason.

Just improved the FSTENV and FSAVE non-existing FPU instructions a bit: Now when any FPU instruction that's not one of the FSAVE/FSTENV or status word saving instructions is executed with memory operands, the CPU does the following:
- Save the protected mode or real mode CS, EIP of the instruction and the used data segment and offset of the modr/m (the calculated offset and the data selector value) into the CPU register state for those instruction to read.
- Calculate the linear address of EIP and the modr/m offset and save those into the CPU register state too (for the real mode versions of the store state instructions).

Then when FSTENV ofr FSAVE is executed:
- If protected mode, store the saved CS, EIP, data segment selector and data offset.
- If real mode, store the FIP as the linear address of that last instruction executed and FDP as the linear address of the modr/m data last used (which may not be the last instruction).

FXSAVE also (after writing the state to memory) clears both the instruction/data pointers as well as the real mode versions of it (but leaves the selectors (FCS/FDS) alone, as it isn't documented to be cleared).

That should complete the whole documented behaviour of the non-connected FPU in UniPCemu, as far as (un)documented documentation is concerned (https://www.os2museum.com/wp/learn-something- … detection-work/).