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.

Found a bug in the BIU handling of read accesses that was using Paging TLB lookups for write(!) accesses. Thus it would fail TLB lookups if the access was previously loaded from RAM as a non-dirty or non-writable page.
Edit: It fixed the GDT crashing bug.

Windows 95 (both old and current installs) both fails to boot.
The old setup gave me an error while initailizing device DOSMGR (Invalid VxD dynamic link call to device number 1, service 8DA).
The new setup gave me a BSOD:

1invalid vxd dynamic link call from VSD(02) + 00000011 to device "CD01", service A7

If you want to really test paging on a 386/486 in UniPCemu, old DOS games that use DOS4GW/DOS4GVM are your best bet, like Doom, Duke Nukem 3D, or Descent, they’re known to push memory pretty hard. SimCity 2000 is fine, but stuff like Doom will stress the virtual memory more. Just make sure you don’t need extra tweaks for EMS/XMS conflicts in the emulator.

Enis wrote on 2025-09-23, 12:19:

If you want to really test paging on a 386/486 in UniPCemu, old DOS games that use DOS4GW/DOS4GVM are your best bet, like Doom, Duke Nukem 3D, or Descent, they’re known to push memory pretty hard. SimCity 2000 is fine, but stuff like Doom will stress the virtual memory more. Just make sure you don’t need extra tweaks for EMS/XMS conflicts in the emulator.

Tried Doom 1. I played through the first level and started the second level just fine. Albeit slowly (at ~2FPS and 13% realtime speed with 3MIPS speed setting and minimal screen size setting).
Now trying Doom 2 (afaik DN3D hangs when the gameplay starts, I just see a gray patterned screen on the ET4000/W32i that's emulated).
Edit: Doom II fared the same. Roughly 2FPS at 13%(3MIPS setting), so about 390KIPS emulation speed.
Tried Simcity 2000 without mouse, but it crashed itself to MS-DOS 6.22 due to a missing mouse driver. After that, somehow the shift status was corrupted it looks like, so everything was typed like shift was depressed somehow. Otherwise it's stable.

Also optimized 32-bit operation a bit to behave better for 32-bit builds (caching up to 32 bits instead of 64/128-bits, depending on alignment, thus restricting memory reads to 32-bits).

Tried running Windows 3.0 for a change. Real mode boots, although I get some strange errors while executing some stuff, like calculator being unable to properly calculate anything (any number makes it say the inputted value is invalid or something like that).
Running Windows 3.0 in standard mode causes a triple fault because it's trying to far call (CALLF) to 0:FFFF at executing address 0051:0370 (protected mode).
The IDT seems to contain garbage at least, with the #GP(0) exception handler having a descriptor (IDTR base 120000h) which contains FF0080h in it's entire descriptor (upper bytes cleared).
The double fault handler is wrong as well: it contains FF00D10003009223, which is either horribly misaligned or just plain incorrect (or uninitialized).
Edit: I've been able to still run 3.0 in real mode. Only thing somehow going wrong there is that running calc.exe (did that from the file manager application) somehow fails to recognise input properly. The input reads "-0." (without quotes). Clicking with the mouse on any digit or typing any digit makes it give a message saying invalid input (or like that, don't remember exactly). So that's definitely odd, shouldn't happen. Something is definitely going wrong. Anyone has any idea what it might be?

Managed to improve the MIDI synthesizer's modulation envelope. It was seemingly inverted (compared to the volume envelope). So it was modulating in the wrong direction (up or down instead of inversed like the volume envelope, accoding to the Viena soundfont editor's rendering). So some things like low-pass filter effects (Biquad filter in the newer versions, which isn't released yet in official UniPCemu releases).

Also, the updating (changing of frequency and other run-time parameters etc.) of the filters has been optimized, thus performing way better than it used to (still not the fastest due to heavy precalcs being calculated, but way faster now).

There's still some weird volume issues though. Some instruments are way too loud, some are way too soft, depending on the instrument.
Although the volume envelope seems to be properly doing it's thing? It seems to have the correct volume for some instruments, but some instruments are weirdly soft, almost unhearable?

Been working on protected mode lately, improving some privilege checks here and there that weren't done properly.

Unfortunately, Windows now fails to boot fully now. It starts it's boot process, does some protected mode stuff and seems to somehow crash on a VxD call (getting a BSOD)?

Since the test386.asm test suite still passes all checks (even including my latest additions of all protected processor modes being checked for all known protected instruction behaviours), the protected mode should be operating properly?
But that would mean that some instruction is oddly going wrong, assuming that protected mode is operating properly? Or does it?

Been messing around with the newly added W32P emulation mode (although it's still unfinished).

Somehow I discover weird behaviour in the 16-bit and 24-bit rendering modes.
Apparently the chip is mostly setup like the W32i, but:
- 16-bit color mode with the SC15025 DAC uses proper DAC settings for 8-bit inputs, but configures the attribute controller on the W32P for 16-bit pixel outputs?
- Actual clocking differs for the character clock (halved in higher color modes)?

OK. Found out something interesting. The W32P has some weird behaviour in the memory address clock: if the enhanced 8-bit color modes is used (every enhanced non-16-bit 8-bit and higher DAC mode), the memory address counter is effectively setup for loading at half the rate it's supposed to load at.
There's also some weird vertical timing issue with 32/64K modes only taking half the vertical screen somehow with my latest changes? It's almost as if it skips every other scanline?
Edit: Those modes seem to set the character height to 2 rows (setting of 01h) somehow, which is weird? Other than that, it shouldn't be done so quick (halfway down the screen, rendering every other scanline somehow)?
Edit: My bad, it's not doing that. Misread the precalcs. The row size is 800h. Perhaps that should be halved somehow?
Edit: So the problem in this case is in the doubling of horizontal timings. After fixing that, the DAC is receiving the correct pixel data. Although it's somehow messing up the generated colors somehow in the 16-bit single clock (raising and lowering for the halves) mode.

Improved the video card rendering by making it handle the dot clock rate a bit differently.
Now, the dot clock rate doesn't affect the pixels on the display directly anymore, instead only affecting the output (doubled) and rendering clock itself (which is handled before normal pixel clock handling now).
Thus, screens with doubled pixels and multiple normal pixel fetches will be handled properly (required for 8-bit and 16-bit highres modes on the Tseng cards for example).

And also fixed the double pixel case. So now all that's left to fix is the DAC behaviour for 8-bit and 16-bit input modes.
Somehow, the 15-bit and 16-bit colors don't end up correct anymore?
Oddly enough, in 24-bit color mode, the SC15025 DAC I'm testing with is set up with command register E0h? That would mean it's in 16-bit color mode, which it shouldn't?

Found some bugs in the sfdimg image file format handling.
One issue was with creating a new (empty) disk image. It was using the wrong header signature for certain cases (when the extended header data isn't used). These images can't be mounted anyways (they're an invalid combination of signature and header size). Thus restoring compatibility with generating such an image also restores compatibility with older versions of the app again.

There were also some path issues in the main conversion process itself, which are now fixed (it was causing the root path to be ommitted when needed and vise versa).

Just updated the paging unit to run itself through the BIU (sending and handling requests to it to be fully cycle timed).

All that's left on the protected mode side now is to handle descriptor fetches and saves (1 byte only though) in much the same way. The main difference there is that the descriptors aren't handling extra paging-related bits like PCD and PWT (they use the normal default paging BIU mechanics instructions use, although not using anything like descriptor caches for translation).
Right now they are just handled in the old way, accessing memory directly, bypassing the BIU timing and generic handling (they directly call the bus handler the BIU calls when reading/writing memory).

Edit: After these additions, the newer commits I added to the test386.asm testsuite immediately showed their worth. It immediately showed me that the call gates, when interrupted by the paging waiting for the BIU for results in cycle-accurate mode, were incorrectly updating the stack (it was pushing some data on the stack, but forgetting the parameters from the call gate descriptor when it was supposed to push them (because of the instruction restart for paging not being finished resetting state, causing the resetted handling to clear the count that was stored when reading the data into a small in-CPU cache for later writing to the kernel privilege level stack)).
Having fixed that now, the test386.asm testsuite runs till the end with my latest changes.

Just implemented a generic framework for handling protected mode stack and descriptors using the usual stepping mechanism (just like the CPU uses for normal instructions and on recent commits also on parts of the privilege mode switching call gates).
Now I will just need to implement those into the protected mode stack and descriptor fetches/reads and writes for them to handle the stack and descriptors through the BIU.
Also completed the BIU 64-bit memory reads for this (since descriptors fetch 64 bits from RAM, the BIU will need to support such reads).

Those new added steps work using 3 different variables instead of just two the normal instruction use.
One counter specifies where in the current attempt (or repeated attempt, as all attempts are performed until the current attempt is reached) it's checking. This counter resets whenever the entire mechanism is reset (which is during the next instruction starting or when a read/write operation is confirmed to be pending).
One counter specifies were in the attempts of the current instruction (actually various reads/writes are combined into one) left off (this increases by two for every read or write operation. The first value (even) is used for requests to the BIU, the second for reading the result (which is that the write completed or the read data).
One counter specifies the read cache position. This is used to keep the read data into a cache to read it only once per request, later requests (restarts) cause the cached value to be read instead of performing the memory request again. This counter, like the current attempt counter, is also request to keep in sync for detecting the specific read attempts to perform (either from cache (when already done before) or from the memory read at a completed memory cycle).

All counters of course reset whenever the instruction state is reset (new instruction or a fault handler is started). Thus causing new instructions to reset such a behaviour.
Those 3 counters exist in two different copies: one for descriptor fetches and saves(which is only 1 byte, unlike the 8 byte read operation) and one copy for stack pushes and pops.

Thus, just like the CPU execution, it allows for the reads to cache their data for repeated attempts (as most of the instruction state is reset whenever the pending condition is triggered, causing the entire checks to restart (but one of the counters is used to return to the point that was interrupted once it matches the other counter (the current counter matches the interrupt point counter as it were))). It's basically just executing coroutines using counters, when I think about it.
The interruptions itself is just the BIU reading or writing data to/from memory. If it's in cycle-accurate mode, this interruption almost never occurs, as the read/write handlers simply immediately tick the BIU and retrieve the result. But in cycle-accurate mode, the BIU isn't ticked that way, thus causing the BIU to interrupt the EU routine that is handling those protected-mode tasks.

Of course, the small counters (only byte sized (index) pointers) and small read caches (16 descriptors and 64 read stack doublewords (16 bits read take 32 bits anyways on the cache, with the top 16 bits ignored during readback) could in theory overflow with 128 reads/writes, but to my knowledge there isn't a single instruction that performs that many descriptor or stack reads (and writes too, since those don't take any space in those buffers). So 254 steps is more than enough to handle all protected mode tasks.