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.