Fixed an issue with an x86 CPU locking the bus for any reason while the BIU is still processing a transfer (usually on it's final tick of the T1-T4 or T1-T2 or T1 ticks). When requesting a bus lock, the main condition is that the bus is idle, which might not be the case (for example a 386 on T2 before having ticked said T2 but having returned it's data result to the EU already, as it's processed first).

In this case, the main CPU execution detects that a bus lock is requested while the bus processing is still active and the BIU isn't requested by the EU to tick more cycles. If this condition is detected, the BIU is forced to tick single cycles anyway to force it to become idle properly before the main loop of the emulation grants the bus lock to the BIU.
When the BIU itself requests the bus lock, this is unaffected. But when the EU requests a bus lock (for a descriptor load or paging lookup from a TLB miss) this case might trigger if the EU leaves the BIU in an unfinished state (not yet having finished it's memory T4(80(1)86/T2([2/3]86)/T1(486+) cycles).

Improved the BIU handling of caching during Paging reads.
Now it will optionally disable the read cache for reading when reading the Paging entries, as indicated by CR0 and the current paging level entry pointer (or CR3 itself, if it's to be used).

So software can optionally disable the read cache for all reads, as well as the various levels of the Paging lookups (level 1 (4KB/4MB/2MB), level2(4KB) or during PAE during any of those levels as well (although the PDPTE entries don't have seperated toggles from the CR0 register itself).

So the following entries can now toggle write-through (unused right now) and cache disable (used just for TLB reads right now) on any of the Paging-level layers:
- PDPTE (using CR0 only)
- 4MB/2MB (CR0 with either CR3 or PDPTE).
- 4KB (on the PDE layer).

Some weird things keep occurring when running various software now:
- Rebooting causes a hang on a CMP memaddr,AAh jnz previousinstruction (inside i440fx BIOS, real mode segment E000h)
- WinCheckIt 4 fails to read it's gathered report (CHK file is corrupt). The POST diagnostic value during this point is that of 0Dh (apparently that means 'Initialize video interface; Detect CPU clock, read CMOS location 14h to find the type of video in use, detect and initialize video adapter'). So is there a weird initialization error in the video card?
The instructions executed are:

1(opcode 80h /7) CMP byte DS:[4F0],AA
2(opcode 75) JNZ 1A8F

The value at DS(0):4F0 is FFh.
That's at the start of the "Intra-Applications Communications Area (IBM Technical Reference incorrectly locates this at 50:F0-50:FF)"
- Disney's Villains Revenge fails (under Win95 C) to detect the CD-ROM as it's own and terminates itself.

Edit: After fixing breakpoints to be handled correctly again (the new instruction border wasn't recognised, so IRQ8 wasn't detected for breakpoints in some cases (directly after a real-mode interrupt finishes)).

I now see it doing the following during POST:

1E000:1A8F initial breakpoint at boot
2E000:19EC start of INT08
3E000:19F2 CMP byte DS:[04F0],FF
4First attempt: ->1A1A MOV byte DS:[04F0],00
54F8=EAX from RDTSC
64FC=EDX from RDTSC
7AL (4F) to some I/O port
8
9Another IRQ0:
10Reaches E000:19F9 CMP byte DS:[04F0],AA. No match, so:
11Reaches E000:1A00. Decreases EAX from TSC with old value.
12SBB high dword too.
13Store new count into 4F8+.
144F0 set to AAh (opcode C6h).
15
16Continues POST after restoring IVT 20h (IRQ8).

So the key to the hanging condition is in the IRQ8 handler it seems. At least failing somehow when POSTing for the second time.

Edit: Looking at when the crash occurs, I see something interesting: While reaching the first instruction of said loop, the PIC(8259A) has it's ISR register set to 02h. So it still thinks that the slave APIC has an in-service interrupt!

Edit: Found a bug in the 8259A emulation: it didn't clear the ISR register properly during initialization, thus causing a stuck IRQ (from the slave PIC in this case, but it could be any hardware with in-service interrupts).

Trying a fresh install of Windows 95 OSR 2.5 ("C") gives a new result now: it triple faults due to pushing on the stack causing page faults?
I see that CR3 and the PDE is fine. But the PTE is reading value FFFFF000 from memory for the stack address (of an ENTER or simple PUSH instruction if I remember correctly).
That shouldn't happen?

Tried running old KolibriOS again (which used to run properly). I see it execution an exact amount of 2 far jumps into segment 08h (the kernel segment). The first jump succeeds properly. The second jump causes a double fault and crashes the OS.
That shouldn't be happening?
Edit: OK. The first GDTR base address is 00011880.
The second (crash) uses a GDTR of 8003f8ff, thus misaligned (the access rights byte is shifted into the 6th byte instead of the correct 5th byte of the descriptor loaded.
It's the second opcode 9Ah far jump instruction.