With 8088 MPH I now see the following (with current (2023/12/31's commit's CPU timings)):
- On some screen the first pixel clock of active display seems to display some font colors during scrolling when the loading image reaches partway top somehow? The same thing happens on other screens as well? This is perhaps caused by the reloading of character or attribute bytes from VRAM at an incorrect last clock of the screen (the bottom-right pixel)? Perhaps about the top 16 scanlines of the vertical movement of the loading screen causes said behaviour (moving it lower makes it black instead)?
- The 16/256 color screen shows the noise on the entire first scanline of active display, as well as the entire third column of active display. (think like in a cross pattern combining them).
- 4K color images look displayed correctly.
- The racing the beam seems to be scrolling left now with a constant speed every frame it seems? About 4 pixels each frame it look like roughly?

The character/attribute clock reloading shows some weird behaviour though?

I've taken a raw screen capture of the pixel outputs in RGB mode for more accurate viewing of what happens.
Anyone can see what's going on there?

Hmmm... Something might be wrong with the latest horizontal display timings?
I only end up with 632 active display pixels on the Windows 95 boot screen logo? That's with the first character clock reading inputs for the second etc.'s behaviour implemented. So it's missing 1 character clock? The left overscan seems to have the opposite issue?

Edit: Fixed it (It was a Tseng chipset issue). But there's a off-by-1 pixel for end of horizontal display somehow? The scanline ends with one pixel from the next row?
Edit: Fixed it to work properly again. The issue was with some <= comparison needing to be reverted to < for the horizontal timings (as the first character clock is fixed now).
Edit: Just modified the predisplay status of the first character clock of active display to render overscan instead (this is also reflected in the display enable signal after all). Because of the loading mechanism, this is always 1 clock after the specified start of active display programmed into the EGA cards and up (on MDA/CGA as well, but they use extra logic for loading from VRAM).

Edit: Hmm.... When in the default BIOS video mode, during POST, Scanline 1BBh has active display from pixel 25 through 673 instead of blanking like the previous scanlines? It seems to still be blanking until pixel (25,54), where active display would start on the next scanline. But that pixel is still blanking, then the next pixel until the end of horizontal display (end) seems to be normal overscan (not blanking), then blanking again until a normal full scanline on the next scanline?

So scanline 1BBh (at 25,55 on the CRT raster it's rendering to) it will have ended vertical blanking and start to render the remaining scanlines until a new frame is started within the video card (at which point it will start rendering the first pixel of active display)? Is that correct behaviour? CRT 25,54 is the last pixel drawn in blanking overscan (from scanline 1BAh) before it will start rendering something again (the overscan color)?

Hmmm... I'm just wondering now...

Is 7.5IRE black level applied to overscan as well? Because if I enable it for overscan as well, the first scanline gives a weird result because of the raised black level for active display and overscan (vs blanking, which is at 0IRE).

Although that might be a case of malfunctioning overscan somehow? The rendering method is pretty simple in this case. Only during retracing the beam doesn't draw pixels. In all other timing period it's either active display (starting 1 character clock late and ending 1 character clock late for VRAM readout) or overscan for the remainder of the horizontal period. The same applies to vertical timing (exactly like the diagram at https://wiki.osdev.org/VGA_Hardware#Resolution_and_Timing). Only when the blanking and retrace periods are active the black pedestal is lowered to 0IRE in all cases (otherwise it's at 0 or 7.5IRE as in the settings of UniPCemu).

Also just noticed that the bottom displacement and on top is always 8 pixels it seems?

Something's going horribly wrong in this display generation for some odd reason? Why could the last and first scanline disagree on what the other scanlines use for their start of active display (and prepended reload clock extending it for one clock at start and finish (skewing both))?

It's effectively happening just on the scanline where blanking ends (top of the screen) and on the scanline the active display ends roughly? Or perhaps a few scanlines down?

Thinking about it some more, the cause is weird? The end of horizontal blanking is set to ~1 in those cases. But blanking clearly is honoured correctly on that 'erroring' scanline, while the next scanlines (until vertical display starts and even ends on the next frame), where it seemingly starts to invert somehow? (At the place it's supposed to end (horizontal character clock lower bits ~1) it's starting somehow? So instead of ending at character clock 1 there it isn't active and starts when vertical display isn't active?

That shouldn't be possible, as blanking start triggers a start and blanking end ends it instead (although at a limited amount of bits checked, depending on graphics card emulated)? Both EGA, VGA and SVGA (All Tseng) display this odd behaviour, so there's definitely something wrong there? Didn't check MDA/VGA yet though.

OK. So it starts at CRT coordinates 9,28. That's at 785,415 on the VGA's internal dotclock,scanline counters driving output.

VBlank is still active before starting to parse the clock. All others (hblank and h/v retrace) are lowered already. Horizontal total happens at the 800th clock (becoming the 0th clock instantly). So that's 15 clocks somehow until the scanline starts rendering somehow? So 15 overscan clocks. But it starts rendering that stuff after 18 clocks? So how come totalling happens at 15 clocks (3 clocks missing)?

Just created a simple reboot-ready disk image of Windows 95 OSR 2.5 ("C") inside UniPCemu. So basically setup until it reboots in to the BIOS to finish the second phase of setup.

Running it inside UniPCemu eventually makes it hang within a loop with interupts disabled in the CPU (Pentium Pro)?

But copying the disk over to 86box with roughly the same setup (minus sound card) makes it boot without issues.
So there's obviously some weird error inside UniPCemu somehow? Perhaps a CPU bug (as it keeps page faulting within the page fault handler itself)?

The normal (installed on an older UniPCemu build) install boots without issues, even on the latest commit (with improved 8259A PIC emulation (rotating priority implemented, special mask mode implemented, SFNM implemented, proper IR priorities and EOI priorities))?

Edit: Probably not a hardware bug? Running while debugging UniPCemu reveals that the SS segment is base 0, limit 4G, Access rights 93h, upper byte 9Fh.
ESP and EBP are FFFFFA00-FFFFFC00 range, so that looks correct.
But the pushes at the start of the handler push with ESP truncated to address FAD4, while (after copying ESP to EBP to setup a stack frame), it executes TEST SS:[EBP+2e],02. Since EBP is now loaded with (for example) FFFFFAD4, it isn't mapped and thus page faults within the page fault handler?

The normal stack accesses by faulting and stack push/pop isn't affected by this, as it's truncating ESP to 16-bits. But EBP isn't truncated for a normal memory lookup. Thus infinitely faulting instead of properly booting Windows 95 "C" for the first time.

Anyone knows what happens on a real CPU in this case? Is EBP truncated for such a memory lookup?

OK. Even with the old PIC code, the fresh install of Windows 95 "C" (OSR 2.5) seems to hang in the same code (page fault handler probably) infinitely trying to read from decreasingly lowered ESP addresses (all faults and stack operations use SP instead of ESP (due to the B-bit in the SS descriptor being cleared), so they don't fault) while the TEST [EBP+xx] instruction (with EBP pointing to the stack frame, but having the upper 16 bits set to a invalid value) keeps page faulting inside the page fault handler itself?

It obviously isn't the new improved 8259 PIC that causes it (seeing as reverting to an older commit doesn't affect this issue). Running the disk image from 86box with as many as possible same hardware (i440fx with all UniPCemu sound cards but the MPU-401 and MIDI synthesizer) boots without any issues (properly finishing setup).

Anyone knows about this kind of faults and what might be causing this fault during the first boot of Windows 95 C(OSR 2.5)?
Edit: OK. Reverted the newer 808x timing improvements for the opcode to verify. Even reverting that, some things still crash that didn't before.

So there's something wrong with the CPU now it seems?

test386.asm checks out at least.
So do Checkit and QAPlus/Pro 05.28

PC-Check 6.21 CD-ROM boot crashes right at the start of the CD-ROM boot process somehow?
Still got Ultimate Boot CD and Hiren's BootCD 9.0 left to check. But it's getting too late right now.

I've just been thinking...

Does stack switching to a higher privilege level using a 16-bit TSS clear the top bits of ESP after loading SS and loading SP with a 16-bit value from the 16-bit TSS? Or are the upper 16-bits left unmodified?

UniPCemu currently leaves the top 16 ESP bits to what they were set to before.

Edit: According to Bochs, it loads either SP(upper bits unmodified) or ESP (upper bits modified) based on SS descriptor of the stack switched SS descriptor's B-bit? That happens both with gates and interrupts (exception.cc and call_far.cc)?
So the TSS size (16 vs 32-bit TSS) only limits how much is read from it, but the SS descriptor (of the targeted stack segment) B-bit actually determines how much of it (zero-extended) is written to SP(truncated with a 32-bit TSS) or ESP?

Hmmm... Windows 9x setup after first boot now triple faults (probably, didn't check exact fault yet) with those changes? Didn't look into it, but it simply reboots a bit after jumping back to graphics mode from text mode (updating settings or something like that that usually happens during the setup phase or new hardware being installed during reboot).

Hmmm... Tried PC-Doctor from Hiren's BootCD 7.8. It simply seems to crash due to a single page fault?
It's seemingly crashing on a non-present page (the error code is zeroed). So it's because of a non-present page being read from kernel memory, accessing address D94000 (64MB of memory installed on a i440fx emulated machine).

Edit: Hmmm... It seems PC doctor is scanning for a byte value E9 in RAM? And it never seems to find it? Perhaps some JMP opcode? It looks like some infinite scanning function until it overflows the memory space. Perhaps some invalid starting address?
Edit: You'd almost think some MOV, memory write or other loading of a base address is failing somehow?
But test386.asm is checking out without errors? So why are those programs suddenly failing?
Edit: Different program, same issue...
Perhaps something DMA is going wrong?

Hmmmm... Does Windows 9x setup use ATA DMA during the first boot?
The CD-ROM uses no DMA, just plain REP INSW. That terminates correctly as well. I see it actually writing the data to memory.

Edit: Perhaps some (string) move instruction going wrong? But test386.asm denies that's the case?
Or normal 8257 DMA issues? Why would it start scanning empty memory?

Edit: Running other programs give the same result. They all end up scanning memory until crashing in the same way? I remember it doing some load from a register-offset memory address, substracting e8h and comparing it to 01h, which never happens (thus overflowing memory addresses, causing a page fault to crash)?
Running a simple "mem" command runs without visible issues.
Perhaps a loader issue?

Edit: Seeing as the issue is with some high bits in ESP being set (FFFFxxxxh to be exact), perhaps the cause is something related to sign extension? For example, the MOVZX instructions sign extending when they shouldn't?
Edit: Masked MOVZX instructions to be sure (in case the unsigned typecast would sign-extend).

Edit: OK. Interesting. Looking at the segment descriptors that are loaded, bit 4 of the segment limit upper byte (containing 4 bits of segment limit and the D/B bits etc.) seems to all have bit 4 set? Is that normal behaviour for EMM386-like kernels?

Edit: Fixed various 16-bit instructions overflowing their 8-bit or 16-bit contents to not incorrectly sign-extend to 16-bits or 32-bits.

OK. Having checked differences in the 808x/80186 cores, I've identified some possible causes that might cause the new crashes:
808x MOVSB/W? OK.
In fact, all 808x string instructions (they all have changed behaviours with the new 808x timings)? LODSB=? (probably OK. Optimized away.). LODSW=OK. LODSD=OK. MOVSB=OK. MOVSW=OK. MOVSD=OK. STOSB=? (probably OK. Optimized away. Memory write observed.). STOSW=OK. STOSD=OK. CMPSB=OK. CMPSW=OK. (incorrect counter used (2 higher than supposed to. FIXED.)?). CMPSD=OK. SCASB=OK. SCASW=OK. SCASD=OK.
808x RETF? RETN is OK. RETF is OK.
808x CMP? 8-bit: OK. 16-bit: OK.
9D POPF? Assuming it's used at all on 386+ CPUs (afaik they aren't used, as the 80386 has it's own handing of those instructions due to changed behaviour). 16-bit: OK. 32-bit: OK.
Verify opcodes 80-83 operation on 80386+?
80186+ GRP opcodes? Opcode 80h OK. Opcode 83h 16-bit and 32-bit OK. Opcode 81h 16-bit and 32-bit OK.
-- GRP5 INC OK. DEC OK.

Opcode 8F POP? 16-bit and 32-bit: OK.

Related:
ISA DMA? Don't see it used.
ATA busmastering DMA? Also don't see it used.

That's about all instructions that have actually changed behaviour on the 808x core itself, which is inherited by the 80286+ cores (as much of the handling is the same, except for some specific 808x timings in some cases).

Edit: Or perhaps it isn't related to the CPU itself at all, but a hardware problem?
Edit: Hmmm... Perhaps a memory problem?
Edit: That adds a few more 32-bit instructions used, but still crashing on the last release's MMU code.
So that's probably not it?
Perhaps some other hardware is the cause somehow, but nothing much changed, other than slight ATA, video card improvements (which is EGA, VGA and SVGA) and 8259 improvements (which shouldn't affect this afaik)?
Edit: Perhaps they didn't boot on the last release version after all. So the problem goes further back?
I do remember it running on older versions though. It's just that CD-ROM OS that seems to fail?
Running said software extracted to a hard disk image seems to work? Does that mean there's CD-ROM or ATAPI/ATA problems?

Just added some more support for special software (as well as some bugfixes).

Now, loading architecture-specific disk read-only settings is working again (this was buggy since the move of the mounted disks to the architecture-specific settings). It also transfers the old setting location properly now.

You can now also configure the CPU to report CPUID's leaf 1 ECX bit 31 to indicate the CPU is a virtualized CPU for software that might need it (though it only applies if CPUID supports leaf 1 and CPUID is supported at all).

That would also improve compatiblity with software like Baresifter (a Sandsifter implementation). Although I'm trying to check if I can get the latest version running again (as it sets an unsupported CR4 bit that crashes the program due to an exception, which is on my fork of the repository).
It might be possible to lower CPU requirements even further by checking for the CPUID presence and setting up a 4KB page table instead of just one 4MB page table (increasing memory requirements but reducing CPU support to a plain Pentium?).
And perhaps I can reduce it even further, to a 386, by modifying the program's paging tables to use 4KB entries and disabling large pages?
Edit: OK. That was reasonable easy to implement into the code. It just still is compiled for i686 though. Don't know if using i386 to compile is possible at all (seeing as it uses the CPUID in inline assembly)?
Edit: Ofc, it crashes on my newly added code instantly inside UniPCemu.
Although part might be with some bad assembly code somehow?
I think the function call to detecting CPUID is at 0020:00400790, at least with the function disabled to always return true (UniPCemu breakpoint setup to 0:400790POS to trigger there. That's POS as in 'position' (meaning for normal protected mode, omit CS in breakpoint (ignoring it in the comparison), single-step)).
Edit: After some more bugfixes in the CPUID detection code (some register ordering due to AT&T syntax vs Intel syntax and fixing the ESP masking with FFFFFFFC(noted as "$-4" instead of "-4" in said AT&T syntax)), the code now properly detects the CPUID instruction (with interrupts disabled for safety)! 😁 Although it uses a simplified version of the CPU processor detection (it just toggles the ID bit in the EFLAGS register and detects if it can be modified). So although it doesn't differentiate between a 486 and 386 (which both don't have CPUID usually), that takes care of the CPUID instruction on said processors. If it's detecting that, it will substitute the results from CPUID as being all zeroed for the CPUID checks in the program. For most cases, that would mean that bitflags aren't set (as they aren't reported) and that the maximum number of function 0 and 8000000h reporting 0 causes the checks to properly be handled as well (function 0 doesn't exist disables all that functionality, turning it into a 486 wrt those functionalities).
The only extension that might be left for that might be the WP bit for 386 processors?
Although I didn't check what it does on a 486 CPU yet (it should go bare minimum and use the 4KB page tables I implemented).
Luckily UniPCemu's 85C496/7 motherboard can verify that (and if a 386 is to be checked that can be done on the Compaq Deskpro 386).
Although the 386 would still definitely crash on loading CR0 with the WP bit enabled. Although I don't know if it's even useful to disable that with Sandsifter software, as it's mandatory perhaps?
Edit: Hmmm.... It crashing on a F30F1E instruction on the 486, but that's not the program itself but the SYSLINUX 6.04 loader, which happens at 0020:00100ec5?

Not related to the above issues, I've lookup up the behaviour of the 80286 SAVEALL instruction (opcode 0F04) and it's relation to prefix (286-only, not on 386+ anymore) F1, which is apparently a sort of CMOV-ish prefix for the ICE module code.

What happens on most processors is that the SAVEALL instruction stores data to ICE memory using the (on normal chips) disconnected pins on the die. And adding the CMOV-ish(F1) prefix causes it to write to RAM instead, just like with LOADALL(at address 0x800).
After completing the dump, it will wait on the disconnected pins on the die for a ready signal, which will never happen.
Luckily a 8042 reset is still recognised, so after the 80286 deadlocks like that, a reset will actually reset the chip and bring it out of ICE ready-waiting mode apparently.
https://forum.vcfed.org/index.php?threads/i-f … l-opcode.71519/

Simply emulated now by writing the state to 0x800 in memory, then deadlocking the CPU into idle state (immediately after completing the instruction's EU execution phase) with a special flag that causes it to clear it on RESET pin raise from the 8042 or normal CPU reset.
And it simply checks for prefix F1('CMOV' prefix when used with this instruction only) to determine whether to write the state to RAM before hanging the CPU or immediately hang the CPU (since nothing is written to RAM due to the lines being disconnected).

Not directly related to the issues with the newer CPUs, but still fun to have implemented.

UniPCemu now supports some new features in the source code:
- Full i82347 APM chip emulation for power states (including poweroff).
- Full i4x0 power state support (mapping the i82347 at +2 of the PCS chip, with special write handling at +0 for poweroff support only).
- Compatible chipsets with EXTSMI# now support triggering it using a 'green button' on the settings menu.
- Implemented swapping support for X/O buttons (or A/B on Nintendo Switch), allowing to use the western((old) default on PSP and non-Switch platforms) or eastern((old) default on Switch) to be used with western or inverted X/O or A/B buttons for confirm/cancel actions.

Still searching for errors in the CPU and hardware emulation before making a new release (because Windows 95 OSR 2.5 setup's second phase crashing).

OK. Checking Windows 95's first boot I see something strange. All segment descriptors have normal 4GB descriptors, but SS is 4GB limit with the B-bit cleared somehow? That isn't supposed to happen I think (causing SP to be used on the 4GB data segment descriptor, which can't be good)?

Edit: Huh? I see P6 RSM executing from SMM, it has AR set to 0C93 (with base 0, limit 4GB), but while the resulting AR byte is correct (93h), the resulting SS D/B byte isn't (it's set to )...

Ah! Found the bug in the 80386 LOADALL (which is used in this case to load the descriptor during RSM)! It's masking with F00 to obtain the upper 4 bits of the AR dword. But instead of masking with F00h then shifting right by 4 bits, it's shifting F00h right by 4 bits and masking that! 😖

So instead of loading the Limit High byte of the CPU segment descriptors with the upper 4 bits of the limit and 4 bits for the D/B and granularity nibble, it was loading it with the upper 4 bits of the limit (correctly) and upper 4 bytes of the access rights byte (which usually is 0x9(like 0x93 for normal data segments), so loading it with Granularity 4GB and 16-bit D/B (creating a 16-bit default code segment or stack segment using SP instead of ESP).
This had disastrous consequences for operating using 16-bit code (which would suddenly be interpreted as 32-bit code) and caused the 32-bit ESP register to instead be interpreted using the 16-bit SP register (obviously wrong, because that would create physical addresses in the 0-64KB linear memory area range (where MS-DOS and Windows 9x stores their MS-DOS compatible IVT and other OS-critical data like parts of the kernel).
And the handlers for protected mode would happily start corrupting said area because of using the SP register there.

Fixed some things related to SMM and more:
- Fixed SMM RSM as well as the 80386+ LOADALL instruction to load the 4 bits mentioned in the previous post correctly.
- Fixed SMM reporting of initial EDI to be proper EDI (instead of ESI) of the start of a string or normal instruction (not repeating yet).
- Improved MSR 0Eh on Pentium to support the ITR bit (bit 9) for supporting SMM RSM to load the string instruction registers instead. Clearing it on the Pentium will cause it to not perform the operation. Any other CPUS (which don't support the MSR) will act like the ITR bit is set (thus causing it to handle all other documented stuff like listing 2 of http://www.rcollins.org/ddj/Mar97/Mar97.html , but without the TR12 check on processors not supporting TR12 (any other than the Pentium CPUs emulated)).
Edit: And fixed RSM to only load the data from SMRAM once. Also improved some stepping through the instruction like with cycle-accurate handling to make it perform faster and with less reloading when not needed due to the nature of the loading process.
Edit: And then fixed RSM to load it's data from SMRAM properly.
Thus RSM behaves much faster now (instead of reloading data from SMRAM each time it's re-executing because it couldn't finish in one go).

Edit: OK. That's not good:

Or it would somehow need a full reinstall because of the fixes of earlier corruptions during the first stage setup?

OK. Found a bug in the real mode 80386+ IRETD instruction. It was popping 16-bit values off the stack instead of proper 32-bit popping (with operand size prefix used of course). Stack checks were performed correctly, but only 16-bit registers were written.
Also improved call gate 16/32-bit behaviour and RETF/IRET 16/32-bit behaviour and zero-extending.

Just improved SMM and LOADALL to actually load custom limit values into the segment descriptors. It will now use granularity to set the top (G set) or bottom (G cleared) bits of the limit (20 bits value) in the segment descriptor. Then after loading the segment descriptor, it will load the actual limit (instead of from the precalcs of the descriptor itself) into the cache as a manual setting.

Of course that required all other loads that don't update the limit to be adjusted not to overwrite said limit, unless it's (un)documented the load occurs (because of loading access rights (in real mode or Virtual 8086 mode) or loading from descriptor tables in memory).
The Pentium (and up) handling of the ignoring of the limit (forced to behave as if 0xFFFF in real mode, honored again once entering protected mode) is now also implemented, except in System Management mode of course (during it's initial startup of the SMM activation).
The older CPUS (pre-Pentium) in real mode(or SMM mode, though unimplemented on those CPUs) and Virtual 8086 mode(as well as protected mode loading of descriptor caches) will overwrite the limit properly (using all descriptor cache values and loading the limit and access rights fields (leading D/B and Granularity bits alone) normally).

Although, right now, Pentium and up will clear the B-bit of CS when it's loaded for any reason in real mode (or SMM mode), for obvious reasons.

OK. A few bugfixes later (also fixing EIP to no longer wrap 1MB anymore in all modes when using byte granularity limits of segment descriptors), I see something weird happening on Windows 95 OSR 2.5("C")'s setup?

It's asking me what kind of bus is installed for some reason? Does it somehow fail to detect the installed bus? Isn't the PCI bus automatically detected?
Diagnostics software (Hiren's bootCD) also seem to crash, so they can't be relied on either?

Just found another undocumented 80386+ feature:
https://www.os2museum.com/wp/sgdtsidt-fiction-and-reality/

Apparently, 80386+ SGDT/SIDT actually store the top 8 bits of the descriptor (the highest 8 bits of the base address), instead of zeroing it with 16-bit opcode size (what UniPCemu performed up until now) or setting it to all ones(which the 80286 does).
Odd that I didn't find out about it until now.

Don't know if it affects Windows 95 setup in any way though? I think it uses MINI.CAB, which would use WIN32s?

OK. Somehow it seems to crash within protected mode segment 868h when loading some diagnostics software from the Hiren's BootCD 7.8 CD-ROM (which I use for diagnostics CPU purposes)?
Edit: It seems to somehow be getting into some infinite loop?