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/).

Just improved the exceptions that push data on a stack to not trigger data breakpoints. My emulator was so far just triggering the breakpoints at the start of the interrupt handler, but apparently on x86 this is prohibited by hardware (only for exceptions though, since normal instructions like INT n instruction, INTO, ICEBP and INT3 should happily trigger data breakpoints for it's stack pushes).

Found a bug in the LAPIC's interrupt controller, where once enabled to use LAPIC interrupts it would spam non-existing interrupts to the CPU core, while there wasn't any from the LAPIC, thus resolving back to the 8259A PIC, which would also not have any interrupt, thus firing IRQ7 over and over every time the CPU had it's interrupt flag set when starting an instruction. This was a conversion bug from the old to the new INTA-based handling, which is now fixed. 😁

Edit: Interesting enough, I see Windows NT 4.0 #GP(8) faulting on a IRETD to CS=0xB, where the CS segment selector DPL is 0 (Access rights=0x9B)? That's weird, since RPL=3 while DPL=0 with a non-conforming code segment?
Anyways, Windows NT 4.0 boots again.

Just improved the EXT bit handling. Now the EXT bit is only set for special interrupts starting (INTA/NMI starting) and faults raising faults (to be exact, it's set to trigger for error codes of faults after a fault has been raised already).

This matches to what I can find about the EXT bit, which isn't anything but what the 80386 programmer's reference manual tells me, which is barely anything at all (only that it's something "external to the program" whatever that is).
Said EXT bit handling has thus been stripped out of most code and now purely implemented as a per-instruction state (reset whenever the state is committed and when a new instruction is starting).

Actually implemented a STG 1702 RAMDAC for the experimental ET4000/W32P (both chips partly implemented right now). Some of the enhanced modes are supported, but not all (the 16-bit DAC input modes aren't supported yet if they become multiple pixels).

Edit: Most modes are implemented now, including the ones mentioned by the WhatVGA documentation. Only the single pixels multiple output modes on the RAMDAC (1x 16-bit to 2x 8-bit and 2x8-bit to 15-bit or 16-bit) isn't implemented, defaulting to legacy 8-bit mode instead.

Improved the ATA read/write sector(s) (EXT) and read/write multiple (EXT) commands to behave slightly more correctly. Set multiple now properly reports it's size in 8-bits instead of being capped to 7-bits (thus 7Fh maximum can become FFh now). The read/write commands now properly report their final LBA (as documented) instead of the next sector's LBA after a read/write command completes.

Windows NT 4 SP6 seems to install, probably correctly. Though trying to log in seems like it fails, at least with multiple CPUs? AMIDIAG complains about all kinds of IPI issues with different targets, so probably an error there (self IPI in both physical and logical mode etc., basically all shorthands)?