The latest changes are now released on itch.io!

One small change on the CPU emulation is also added: all TLB entries used with paging now have their pointing (for the LRU cache algorithm) and data (the tags and other related data) merged into one single 30-byte structure that's used for all TLB entries, packed using aligning the data at 32/64-bit boundaries as tightly as possible (although the 64-bit platforms previous and next pointers are taking double the space, they're at the same aligned position as on 32-bit platform, only taking double it's space, causing the structure to be 8 bytes larger for each TLB entry on 64-bit platforms (30 bytes instead of 22 bytes, due to larger pointers)).

Managed to get the packet server improved a bit.

It can now be compiled on almost all platforms (except PSP, but that's only because it has too little memory to work with) with a special nopcap mode (added using command line parameters to make or added automatically when using SDL2_net on the Android platforms).

Said nopcap mode adds the packet server modes to the executable, but with only the loopback mode available when enabled (so will error out when trying to use any network card or scanning any network card).
That allows it to host a private network on all supported devices (all UniPCemu builds except the PSP) without internet or real network access, thus allowing multiplayer using dial-up and other local networking.

A slight bug in the reporting of SLIP mode etc. has also been fixed in the packet server, thus making it report the correct IP address to the clients connecting to the packet server in that mode.

OK. I've been testing the packet server somewhat.

The server seems to be running stable, but some weird things occurs with two Windows 95 clients connected to it.
When both are connected (using PPP in this case, but probably the same would count for SLIP), when trying to access each other's share at the same time both Windows 95 clients seem to freeze?
They can access each other fine if done one way at a time, but when trying to access each other at the same time it just seems to crash both Windows 95 OSes running inside Dosbox-X?

It might be a strange Windows 95 bug manifesting, but this eems kind of weird?
One of the two seems to be hanging with the network indicator (of the Dial-up connection) showing it's sending and receiving something at the same time?
The mouse is still responsive though.

Edit: Fixed a bug in the pcap thread handler and updated the generic thread handling a bit to allow for thread termination to ask a thread to be closed to close as fast as possible (using a simple flag). So when it's trying to close any thread, it will set such a flag for the thread to ask it to close (although the thread can be asked to close using local variables as well).
This prevents the issue that was happening with the packet server's listening thread, which in all cases of it running parses and receives packets from both clients connected to it, it's own sent packets to itself as well as any packets from the pcap library if it's enabled and connected to. The issue in this case was that when terminating the application, the packet server thread terminated because it was seeing that the application was terminating. But in the meanwhile the main thread (which is running the communications part to connected clients (and all of the packet server but the filtering (which is handled by the special pcap thread that was hanging)) and main emulation routines). The pcap thread just constantly polls the pcap inputs and server loopback device (which is internal for the server) for packets to receive (and for ARP to actually also send data back automatically as fast as possible).
The issue that caused a crash was because when terminating, the main thread would issue ARP requests and expect hardware to properly handle that (because it's doing some specific ARP requests to announce itself as not using allocated IP addresses anymore). But because the pcap thread was terminated, the sending of those packets wouldn't work properly (because of being blocked by the loopback buffer being full and never emptied by the pcap thread), thus keeping the main thread waiting on the pcap thread to parse the packets (which was already terminated by the application trying to be closed (which sets a global flag)).

Luckily, the issue was simple: simply make the pcap thread use it's own thread flag (which is handled by the server's own teardown and startup routines) as well as instead of using the global variable to check for forced teardown (which is used for the entire app being in a shutdown state, where it's set when the app is going to tear down all components, one of being the packet server itself (which is a custom part of the modem handler in the emulator)).
The issue with said global flag is simply that it's set too early (before the packet server has a chance to use the pcap thread to tear down it's own operations (this is done both in pcap and normal server and loopback mode).
So the solution is luckily simple: just make the thread system itself (which handles teardown of the real threads as a wrapper around SDL with some extra functionality) provide a flag that it sets when a thread is requested to be terminated (this is set just before calling the specific SDL/SDL2 function to wait for the thread to end).
What then happens is that flag that is set when requesting the thread to end (by the global thread functionality module in the app) is checked by the thread instead (it doesn't have to check it, provided it has safe alternatives to tearing itself down and return to the caller), causing it to return to it's caller (the thread termination code within each UniPCemu thread started by the module.
Thus all methods that terminate a thread (which call the same function) set that flag, which can be detected by said thread only to cause it to abort. Although in the case of the pcap thread it also has it's own flag (which is used every time it's terminating the thread because it doesn't need to run it (during startup) or when tearing down the entire server (when closing the app or restarting it). The global flag that's within the thread module itself just adds a little safeguard for when the normal packet server terminating code can't do it's work (like the main thread terminating before teardown because of any crash etc.).
Other threads can also use it of course, but aren't required to if the thread's lifespan is the same as the app itself (which simply depend on always used flags for such a purpose).

Just fixed an issue with the XBox 360 controller detection. It should now be detected again in the cases where SDL2 reports the joystick name as "Xbox 360 Controller".

OK. After noticing that Android builds crashed when running the i440fx, I started looking into what caused the crash on a i440fx after the PCI detection.

Turns out that the 16-bit and 32-bit IDE device I/O (port 1F0/170) didn't decode correctly, causing the channel detection to be out-of-range.

Now, running Windows 2000 setup again, I see it doing two things after Windows 2000 setup says it's starting "Windows 2000":
- Reading the drive/head register.
- Reading one of the cylinder high or low registers (didn't remember which one that was).

It might be working a little bit better now! But not entirely there yet?

Edit: The register contents seem to contain a ATA signature?
Drive/head is A0, so that's fine?
Now, sector number is 0x01, the cylinder registers are cleared, sector count 0x03 and it's reporting ready, status register 0x40.

The last command issued was a ATAPI sector read command of sector 16 on the CD-ROM.
Edit: Interesting. When 'Starting Windows 2000..." it's writing the value 0x08 various times to the CD-ROM drive control port? A reset is probably needed there somehow to make it detect the drive as Windows' kernel initializes?

Edit: I indeed see it write 0x08 to port 3F6? Even during it's initial device detection before starting up setup (before the blue screen loading of drivers part)?

The BIOS also seems to write that value oddly enough during POST (i440fx motherboard BIOS)? I see it using proper 0x04 in between sometimes though?

Edit: Hmmm...
https://kernel.googlesource.com/pub/scm/linux … ude/linux/ide.h
https://kernel.googlesource.com/pub/scm/linux … ivers/ide/ide.c

Perhaps that 0x08 should actually be written to the command register instead of the control register? So it's writing the 0x08 (device reset command) to the wrong i/o port?
That would make sense to reset properly?

Edit: Looking further at where that 0x08 value is written... It's done by the BIOS, not Windows 2000!!!
That happens at F000:BFBA each and every time!

Edit: OK. Another one at F000:B7BA? Also at :B87B? :B88E writes a normal 04h reset value? :B89B writes a cleared value. :B7BA is another 08h to port 3F6h. And then another. And another?

The BIOS call to reset seems to happen at e000:000030bf.

Edit: The capture of what's going wrong apparently:

Just did some research and disassembly of the unpacked ROM (the contents of memory E0000-FFFFF during the write of the drive control register). The value that's written (08h) is taken from the hard disk 0 parameter table it seems (although hardcoded into the BIOS ROM). It's value is 08h, which means: more than 8 heads (bit 3 set), disable IRQ, no reset.
So that makes the BIOS not reset the drive when asked to?

Just tried it again with the ATAPI controller setting the cylinder and sector count registers to the signature values after a command enters result phase.

Windows 2000 seems to read said registers, but it doesn't perform anything else on the controller and simply crashes into a STOP 0x0000007B (0xF9063848,0xC0000034,0,0) after that?

Nothing else is done after said last read command (an ATAPI read(10) command, reading sector 0x10)?
UniPCemu does seem to at least try to raise an IRQ after it's completed the ATAPI command?

Edit: Hmmm... I do see it executing a read(10) ATAPI command after writing the control register (with a value 0). It's packet seems to contain a request for reading sector 10h?

It seems to complete, but nothing after that?

Edit: I do notice that during the whole setup process, interrupts on the PIC and APIC for IRQ15 (which the CD-ROM is attached to) is masked, so it's never triggering?

Edit: After "Setup is starting Windows 2000", I just see it reading the mentioned two registers, with the I/O APIC being used (the 8259 PICs are both masked by setting their IMR to FFh). It never does anything else with the CD-ROM drive?
It only enables IRQ8 on the I/O APIC? Never any other IRQs?

Anyone has any idea what's going on?

Just tried ReactOS 0.4.14 again.

It seems like the same issue? Just IRQ8, then instead of BSOD it eventually just reboots? Some common issue?
Edit: Moved to another thread for the ReactOS issue for now.

Just fixed a simple directory listing issue in UniPCemu.

Since on Windows directory listings are in Unicode format (and the same is true for the serial port path (converting from UTF-8 to Unicode encoding), if used), UniPCemu now converts them from Unicode (2-byte or 4-byte, whatever the size of TChar is) to UTF-8 strings it understands.
And the reverse is true as well now (for UTF-8 paths being listed, converting them to the proper wchar array) when listing directories and opening a serial port.

So now UniPCemu can properly understand and display UTF-8 and (on Windows file paths) use Unicode when talking to Windows directly (which is outside the scope of SDL/SDL2).

Another thing that has been fixed is clickable text now properly decoding UTF-8 as required (it was missing from it but not from non-clickable text), as well as display of undefined character codes to properly display a simple ? symbol instead.
Perhaps I'll create a simple glyph in UniPCemu's reserved character code space for that later as a better implementation.

It also fixes problems with any filename that had non-ASCII characters in them, as they were not retrieved from the OS (Windows) in an expected format, causing any mounting of them to fail in that case (and removing it from the mount point because of said reason, because the app thinks it doesn't exist).
Of course having those incorrect characters in the settings file will also behave that way, as it's an incorrect filename (unless something actually exists by that name), which is unchanged.
The only thing that changed here is the display and retrieving of a correct file list from Windows (and properly storing it in the setting when it's selected to use).

Although I've fixed various issues in UniPCemu since the last commit of 13-07-2023 00:56 (primarily the UTF-8 support being improved and 808x BIU and fetching cycle-accuracy being more accurate (and the 8F opcode being slightly adjusted in timings)), I've also managed to get the 286+ (checked though Pentium II on i440fx) CPUs broken somehow?

The i440fx BIOS crashes very quickly, crashing on an #UD exception when it shouldn't (according to the commit of 13-07). So that's bug searching once again. I've probably forgotten something again while converting to the new cycle-accurate immediate timings or some other component in prefetching failing?

Edit: I still can't figure out what's causing the weird behaviour of the i440fx (Pentium II) emulation to suddenly start entering a BIOS ROM area where it's executing an #UD opcode? I know it should have something to do with the fetching instructions from the PIQ for executing said instruction, as older commits without the new fetching behaviour (although it should just be for 808x CPUs on the instruction level instead) don't show this erroring behaviour?

Anyone knows what could cause the BIOS to end up in an invalid ROM area?

Perhaps just an EU fetching issue specific to 286+ CPUs? Hmmm...
Edit: Ah. Found a REP-prefix (REP/REPZ/REPNZ) instruction state reset error that's fixed now. It wasn't resetting the instruction's own state every repeat as it should, because the prefetching would reset itself when done, causing it to never detect a new instruction to start after the first memory location in the iteration, thus effectively NOPping all other executions (because the EU handler was thinking it already finished!).

I'll have to check if that does the trick later. It should affect memory clearing and all block copying etc. (because that uses REP-prefixes usually). Weird MS-DOS still booted though, as it depends on it for filename comparison?
Edit: It would explain MS-DOS trying to execute non-executable files (like TXT files), which it shouldn't, as mismatch in headers (perceived due to REP failing) will cause such a behaviour (REP header comparison for 'MZ' etc.).

It also wouldn't affect booting MS-DOS, since the first file matching "I" for IO.SYS still matches and the same for "M" for MSDOS.SYS (and perhaps "C" for CONFIG.SYS in my particular case if no nother files with "C" exist in the root directory).

Edit: The i440fx now ends up in no-mans land (CS=0) again? Hmmm...
Edit: Merging REP family prefix behaviour to be using the PIQ EU handler (which now omits any fetching from PIQ) I see it executing an INT 8Bh instruction to code segment 0? That can't be right?

After a full day of work (and a few hours) managed to get the entire common emulator framework (and UniPCemu with it, as it runs on it) ported to SDL 3.0.
Although UniPCemu won't release on SDL3 until a first release of official SDL3 is made, this future-proofs the project just a bit more.

Just fixed some issues with x86 modr/m SIB decoding. Now the case of [EBP] with MOD being 0 will properly apply the offset combined with index as it's supposed to, as will [EBP+imm8/imm32].

Basically, this fixes the case of [index*n+disp32] to behave properly (instead of being reduced to just [disp32] due to incorrect clearing of the immediate).

Although it was Jazz Jackrabbit 2 that put me on the trail to this fix: I noticed that the stack had a 0x00000000 value read and dereferenced incorrectly (which shouldn't happen) directly after the first cutscene (of the greyscale image) in windowed mode on Windows NT 4.0. The log of Windows NT 4.0 (by dr watson) showed it was failing on ESI that was just earlier loaded from the stack using a [ESP+xx] parameter, which must have been an SIB byte used (as it's a SIB-specific instruction encoding). And since the value on the stack wasn't written properly, the issue is probably something to do with stack-based memory operations as well. Since the BIU should be working properly afaik and I've extensively tested pretty much all instructions that UniPCemu implements seperately (although not using the SIB byte for addressing), the logical cause would be probably somewhere with functioning on the stack for writing a variable. The only candidate that would fit that would be a SIB byte processing, as all other modr/m modes don't allow SP/BP-relative processing on the stack (which must have been used, as the stack isn't at a fixed place in memory for loaded executables). Since I know that the normal non-SIB modr/m processing should be working just fine (as it's running off the same basics as the 16-bit decoder, just with 32-bit registers replacing them (except for the SIB r/m cases)), the only logical conclusion in this case would be the SIB byte decoding itself (the instruction decoding and displacement loading should be fine, as they're done in different functions and the IP pointer ends up at a correct spot when executing the executable).
In fact, the SIB decoding of memory addresses and applied segments (CS/SS/DS/ES/FS/GS) is performed (with that I mean the EA offset calculation and used segment determination for the memory operand) AFTER the instruction is loaded from memory and the entire modr/m, SIB and displacement are fetched for the instruction (but before the immediate if fetched). Said function that decodes the address and segment register is only called again in one case (the POP case with the modr/m pointing to a (E)SP memory address, like POP [ESP+4] for example, which is required for some operatings systems like Windows 9x to boot properly (it depends on the value to be written AFTER ESP is incremented, not before it's incremented (when the instruction starts executing, so it's writing to 2(word) or 4(dword) bytes after the original (E)SP location in that case, which is odd but true behaviour on the x86 CPUs))).

Basically, what changed now is that [index*n+disp32] is now properly performed (instead of being reduced to [index*n] for a parameter, which was caused by the displacement being zeroed for the MOD=0 combined with BASE not being EBP (which is invalid behaviour).

UniPCemu still silently applies the displacement during index calculations instead of during base calculations (and the base of [disp32] will instead just return 0 for the MOD=0 case in all situations to let the index calculations carry the displacement calculation accordingly (to simplify calculations of different index/base combinations allowed)). The index calculations just will remove the displacement after it in disassembly (the "+12345678]" part at the end of the modr/m disassembly for 32-bit displacement for example) if the [disp32] method is used only (since it would otherwise print it double), as well as with the non-[disp32] cases, like [ESP+index*4] with MOD=0 (it will calculate, but just zero the displacement used during index calculations in this case (and not fetch it from the PIQ for the instruction fetching part)).

Edit: It still crashes? Weird?

What happens if r/m=4, SIB.base=EBP and SIB.index not being ESP? Is EBP+index*scale still used in that case?

Edit: Just made the instruction decoding of the SIB byte more in line with the other instructions.

It will now perform the base and index, where the base may be omitted (for the [disp32] case), otherwise suffixed with a '+' before the index part). The index part, if used (non-SP), will give a simple reg*1/2/4 followed by a displacement (not if MOD=0 with non-EBP base). For ESP index, it will be either a simple base (if a non-[disp32] base is used (selected by MOD=0 with EBP base) or an offset from the base (when a base exists, so the MOD=0 with EBP base doesn't apply).

So some example outputs now:
EBP+EAX*4+08 (reg with 8-bit displacement, mod=1)
EBP+EAX*4+12345678 (reg with 32-bit displacement, mod=2)
12345678 (this is the case of MOD=0, EBP base and index ESP. Since the no base applies here, the + isn't prefixed, and the ESP doesn't output any index disassembly (not calculates it, just the base is returned))
ESP+08 (base ESP, index ESP with 8-bit displacement, mod=1)
ESP+12345678 (base ESP, index ESP with 32-bit displacement)
EBP+EAX*4+12 (base EBP (because mod=1), index EAX with 8-bit displacement)
EBP+EAX*4+12345678 (base EBP (mod=2), index EAX with 32-bit displacement)
Edit: OK. Verified it with the test386.asm testsuite (which AFAIK checks all modr/m memory inputs and outputs using SMC). It checks out (together with the 80386 instructions tests) without errors.

Then what is going wrong with the emulator? If test386.asm can't find any errors, what is the cause of JJ2 crashing (together with Windows 2000 and newer failing to boot)?

Edit: Hmmm... Even though Windows 95C boots, it can't seem to properly find the onboard PCI IDE controller anymore (the hard drive itself is in legacy INT13 mode) of the i440fx motherboard? That shouldn't happen?

Edit: OK. I modified the PCI vs legacy settings on the PCI interface a bit (based on just the 41/43h registers now):
- Setting bit 7 of those registers (or bit 15 of the word registers) now enables it's legacy mode (disabling PCI mode). The enabled bit in register 04h is still used to disable the entire controllers connected.
- Clearing bit 7 of those registers (or bit 15 of the word registers) now enables PCI mode, converting the device into a full PCI-compatible device (with the BAR0-3 registers activating as expected).
- Clearing bit 0 of register 4 disables the entire controller as expected now (also effecting it when it's in legacy mode). The IDE register range occupied by the controller will now also disappear from read/write accesses accordingly. Although the legacy IRQ lines are still connected in this case, the PCI lines are properly lowered. I don't know what the behaviour of the real device is in that case.

So basically, setting bit 7(or 15 depending on the size of the register addressed) turns it into a legacy port, while clearing the bit puts it into PCI mode instead. Both ports can be set individually. If the second port is set to PCI mode and the first port to legacy, the hardware will move the second port BARs to listen to the first port BARs instead (so instead of programming BAR2&3 you need to program BAR0&1 for the second port when 41h=80h and 43h=00h for example).

Edit: Windows 9x seems to like the controller for now (with of course both controllers enabled in the BIOS to detect and boot from it while it's setup to the onboard controller in the emulator settings).

Tried Windows 2000 setup again with the latest i440fx motherboard emulation (and some slight IDE bugfixes).

Once Windows 2000 is starting, I see it read the following before the BSOD:
cylhigh is read EBh
drivehead is read A0h

The BSOD says:

1*** STOP: 0x0000007B (0xF9063848,0xC0000034,0x00000000,0x00000000)
2INACCESSIBLE_BOOT_DEVICE

Checking the i440fx again (Pentium II) now gives me errors on the stack somehow, with the latest emulation code?

test386.asm is now failing at test 9 (stack functionality). So the BIU is probably once again failing somehow (at least of the i440fx)?

Edit: OK. It isn't 'hanging' in the usual way. It's just that the PIQ is loaded and starved on the newer CPU and never loads more data into the PIQ. Thus it creates a hanging condition.
It's read 81FC from memory, then tries to read a 32-bit immediate, but it can't because the PIQ only has 3 bytes left in it's queue?

Edit: Hmmm... Something with EIP and paging is going wrong apparently.
The PIQ contains (according to the BIU's PIQ and prefetch address register) bytes from memory locations F2FFD-F2FFF and is waiting for the EU to read the (prefetch) paging structures of the next block into the TLB (it's trying to read address F3000 into the PIQ).
The EU otoh is trying to read a dword at EIP=2FFC (CS points to memory block F0000h, so the BIOS ROM) from the PIQ, but the PIQ only has data for CS:[2FFD through 2FFF].
The EU has read the first 2 bytes of the instruction into it's debugger information (so it's actually read 2 bytes of the instruction normally). It's the doubleword access that somehow fails?
The instruction starts at EIP=2FFA. So 2FFA is the first byte and 2FFB is the second byte. Then 2FFC should have the remaining 4 bytes of the instruction (the 32-bit immediate), but the PIQ only seems to have bytes for 2FFD-2FFF? That shouldn't be happening!

The instruction before it is at 0010:2FF4. It left EIP at 2FFA (which should be correct), with the BIU being at EIP=3000 with 5 bytes stored in the PIQ. That can't be correct, as 3000-5=2FFB (so it has addresses 2FFB and onwards stored at said point in time). The instruction buffer has 6 bytes inside it's cache (0F8591A50000). That matches the locations in the BIOS ROM at address 2FF4.
The PIQ seems to contain the first 3 bytes of the next instruction?
I also see the PIQ intermediate buffer having 1 byte stored for parsing when a read operation completes?
So that's 1 byte of instruction worth that hasn't been properly added into the PIQ.

Edit: Managed to fix it. There were some problems with BIU T1 type detection for the current operation not properly finishing (setting a new value while it's still processing, thus not parsing the 'T4' cycle correctly in all cases). The bookkeeping of the current T1-type operation (EU vs PF vs Idle as some people here call it) is now properly handled on those CPU cases as well. The test 9 testcase now properly proceeds to the next instructions as it was supposed to.
Edit: test386.asm's results still check out with the latest commit. So at least the 80386 seems to be in working order. 😁
Edit: And some more bugfixing fixes the 808x CPUs as well. Although the cycle count according to 8088 MPH is too high now (it's changed for some reason, due to the the latest BIU code fixes somehow, that have been added since the commit of 2023/09/27).

A slight improvement to the newer code once again. Now I've implemented SDL3_net support into the tcphelper module, so the new SDL libraries can be used completely without loss of functionality.

Although the SDL3_net functionality is currently a straight port from the SDL2_net functionality and still unverified to be working properly.
One nice thing this does seem to add is that it now can support the Dial-up modem ringing signal with improved accuracy (and not accepting the connection until the user accepts it on the emulated system, for example with ATA on a Hayes modem).
Although currently said functionality is always disabled in the modem itself.

Edit: Hmmm... Oddly enough, incoming connection don't get notified by the SDL3_net library? I'm on a dual-stack IPv6 configuration and connecting over IPv4.
Edit: OK. That issue seems to be an issue on SDL3_net's side. It somehow won't accept connections from IPv4 when on dual-stack IPv6?

Improved the TCP module in UniPCemu somewhat.

I've added improved support for IPv6 address recognition (previously only IPv4) using either up to 8 words of address (which can have one point of 0 fill using IPv6 "::" syntax, multiple are counted as an invalid IPv6 address). The remainder (filters etc.) operated on the full 8-word IPv6 address always in the other parts of the app (so "::1" becomes " 0000�0000�0000�0000:0001 " and for example 127:1::1 becomes " 01270000�0000�0000:0001 " and 127:1::2:3 becomes "01270000�0000�0002:0003").
It also supports ports in the SDL3_net IPv6 address using "[127:1::2:3]:portnumber", for example "[127:1::2:3] :80" (remove spaces, the forums glitches out for some reason) for some HTTP server.

Things like subnet masks (like "/24" suffix or the like) in IPv6 aren't recognised though (they shouldn't happen anyways).

The packet server otoh simply stores it's IPv6 blocklist together with the IPv4 entries (they don't clash because of being different lengths) as the 8 16-bit words concatenated as hexadecimal 4 digits at a time (like the IPv6 addresses above, but with zero-padding to 4 digits for each word like above and the colon sign removed (unlike IPv4 that's using 9 digits (each byte in decimal zero-padded to 3 digits for each byte). Localhost (::1) would be "00000000000000000000000000000001" for example.

I've been looking at what's going wrong to cause the i440fx BIOS ROM to crash on the new CPU emulation.

Interesting enough, just before the crash I see it returning from a jump to F000:0000EC30? Anyone knows that specific address in the BIOS ROM? Is that address defined for common BIOS ROMs?

Edit: Hmmmm.... Just reverting the entire CPU emulation to the last released build's version (mentioned in an earlier post on this forum) still causes the i440fx to crash?

So could it be that the CPU isn't the cause of the i440fx crash, but instead one of the other components of the emulator?

I've already checked the 8042, DMA (the XT improvements), almost all hardware changes made.

I verified that reverting the total of:
- Entire CPU modules changes
- Emucore interrupt logic
- 8042
- PIT bugfix
- softdebugger debug ports removed.
- CPU task switching (part of CPU logic)?
Seems to make the i440fx POST again oddly enough?

Edit: OK. Managed to reduce the i440fx issue to:
- 8042 changes.
- PIT modes 2&6 not applying modes 3&7 also?
- Softdebugger 8/16/32-bit ports for testing functionality.

Edit: Another check. The softdebugger added ports isn't the cause. So that leaves the 8042 changes and PIT modes fix (added break statement).

Edit: OK. So the cause of the i440fx not POSTing is the 8042 malfunctioning somehow with the new buffer filling (for received or internal data) and IRQ handling.

So the question is now: What is causing the 8042 to fail?
Edit: It looks to be the condition to parse sent written data in the output buffer to not have the input buffer filled!
So probably the check shouldn't be performed at said global location but perhaps in a more specific location only?

I've just modified it to apply just to parameters to commands that affect either the output buffer directly (write to first/second port buffer) or IRQ lines directly (the 8042 output port).
Commands still seem to be requiring to be writable (for example enabling/disabling port commands with a single command is required to ignore the output buffer full status).

Edit: Hmmm... It seems to boot like usual, but the ESCD fails to update for some reason on the i440fx?
Edit: Improved BIOS flash ROM caching a bit, to be uncachable.
Edit: Fixed a CPU reset issue with it waiting for a reset when the EU isn't ready to reset yet (still pending a transfer).
Edit: The i440fx BIOS still gives the error, despite the BIOS flash rom caching? It says: "ERROR -- Can't Write ESCD".
Edit: Just found the cause: it was trying to flash the BIOS ROM using the FFFE0000+ memory blocks. But the A20 line wasn't properly updated because the 8042's pending of a stuck output port write failed (which also controls A20). The 8042 was essentially discarding the write because of invalid aborting of pending writes (clearing a flag when it shouldn't (the flag that indicates that something is to be parsed and what kind of write it is for (to a PS/2 port, output port etc.)) when it should leave it alone in that case (noticed it in this case because that write pending flag wasn't set, but the input buffer full flag was set, which shouldn't happen in proper operation of the 8042's emulation (it's supposed to be flag set to non-zero matching bit 1 set for a pending write). In this case the pending write type flag was cleared (nothing to send), but the input buffer status bit was set (there's something to write to any hardware device). So it was stuck to never be parsed.

Ofc any used testsuites never find this bug because they leave A20 untouched.

Improved lots of instruction timings again (based on MartyPC's timings). Now all opcodes until opcode D0h (except the INC/DEC opcodes in the 40-4Fh range) use the new timings (although not verified yet).
Edit: And that's those INC/DEC opcodes also implemented.

So that's all GRP opcodes and opcodes past D0h left to properly implement timings for.

OK. Just running 8088 MPH with the new opcode timings (although the highest quarter are still WIP right now, the opcode D0-FF range), somehow the CGA has two weird bugs:
- The first character clock gives weird content for the first clock of the CGA vs Commodore screen.
- 16/256 color screen works, but all others seem to fail using the start address somehow it seems? They all display the first scanline of the screen only (or 2 scanlines in some of the modes)?

I'd think that would be caused by the offset perhaps, but that's updated correctly it seems? I see it jumping back one byte in memory every other scanline during horizontal total though? Why would the screen be giving the same scanlines over and over? Is the horizontal offset being added to the start address clipping somehow?

I see the start address decreasing by 50h every second frame during the screen before the racing the beam part, but it doesn't seem to properly move the image up and down the screen for example?

The flower girl otoh keeps having a start address of 0 during the entire frame somehow? I expect the same thing to happen to the other 1024 color images and the old vs new CGA screen (except the 16/256 color one)?
What could cause that to happen? Do they do some weird style of updating somehow? Or is there a bug in the CPU breaking up 16-bit port I/O to 8-bit somehow?

Edit: The credits also go wrong somehow? I see 3 black boxes, none of them moving at all? Music is running though?
Edit2: Found the bug: the EGA and up's top window position register was forcing the top window to be specified at the defaulted register location of 0 (so it was immediately starting the EGA/VGA top window (see the EGA/VGA Line Compare register and Overflow registers respectively) on scanline 0, which shouldn't happen). 😖

8088 MPH is at a metric cycle count of 1702 right now.
Edit: That fixes the 'Which CGA am I' screen. So the others should be fixed now as well.

The first character clock within the first screen when the demo starts (as well as the last character clock) are displaying incorrect pixels though? It looks like it's shifting the second clock into the first clock on the previous scanline? And the first clock into the previous scanline? Perhaps it's something to do with the new delayed character clock loading?

Other than ofc those two clocks (probably something to do with loading first or next scanlines first clocks somehow), images seem to show up correctly (and ofc the Kefrens part scrolling left each frame on all scanlines due to cycles mismatch (x too many or few, which seems to be a constant for all scanlines))? The second clock shows the data it seems (like the first is duplicated twice)?