Hmmm.... Just discovered something weird trying to boot Windows NT 4.0 to verify CPU behviour to be working properly still.

Somehow it reaches what seems to be opcode 84h (TEST r/m8,r8), but fails to fetch the modr/m parameters for some weird reason?
Looking at the fetching precalcs, it looks like the settings aren't properly retrieved from the instruction parameter lookup table, if at all (perhaps it points to another opcode, so never fetched properly)?
Edit: Hmmm... Now after some more testing (Windows 95 again), I see it failing on a opcode seemingly page faulting and failing somehow (proceeding to execute an invalid instruction).
Edit: After improving that, now Windows 95 fails to boot, telling there's not enough memory to load the registry?

Modified immediate parameter reading faulting/aborting(including paging locks) to check for active instruction by checking the parameter passed to the immediate read function(indicating checking(0)/loading from instruction(1) or main fetching routine(3, for 286+ CPUs only)) instead of directly checking the CPU's fetching/EU execution status (which is reset on any fault or execution phase change).

Also fixed resetting EIP for faults not to manually just load the CS selector, to keep CS selector/descriptor relationship consistent.

Now Hiren's BootCD 7.8 changes once again, now trying to execute an invalid LXS (LDS,LES etc.) instruction with register parameter, in real mode?

Just improved two things on the x86 segment descriptor handling:
- Make RSM properly set the CS segment descriptor mode to real or protected-mode/V86 mode on Pentium and up (applying the CS real mode limit behaviour on Pentium properly).
- Make segment descriptor read/write/execute permission precalcs point directly into the global precalcs lookup table, instead of copying all 256 bytes over, for increased performance (as the data in the table never changes), thus reducing the 256-byte memcpy to a simple 64-bit or 32-bit assignment (depending on the executable address size being 64-bit or 32-bit).

Just tried some older stuff I was testing with in the past and tried booting MS-DOS 6.22 with QEMM 7.04 again.
It, after fixing some CPU committing to behave more correctly (globally after the instruction instead of while parsing it), it crashes, saying it 'Cannot load because there is not enough memory.', which is interesting at least. At least it doesn't crash like it did before.

I made a log of it running the protected mode part of the program. Looking at what it's doing, I don't see anything weird?
Perhaps the issue itself is inside V86 mode that's causing this?
Edit: Looking into good old Hiren's BootCD 7.8 I see the same booting it. Instead of properly starting to extract files, it will spew out some garbage now and execute an invalid GRP5 /7 opcode (FF /7), throwing it into an infinite loop.
Edit: Wfw 3.11 otoh now is crashing immediately upon boot, soon after displaying the loading screen.

Hmmm... Seeing as the testsuite (test386.asm) doesn't seem to give any errors and MS-DOS still boots, but anything on top of it (Windows, memory managers etc.) keep 'running out of available RAM', environment space etc. (even though 128MB is installed) there might be something else going wrong in the CPU emulation somehow?

OK. While finding this bug, I've improved the settings menu text and address inputs a bit.
It now properly supports the valid numpad keys too.
So on an address input (for breakpoints etc.) it adds numeric keys and kpen (keypad enter for confirmation, just like normal enter) key.
And on text inputs (filenames etc.) it supports -, + and . keypad keys as well, ignoring shift status (to prevent del and incorrect _ behaviour on those keys).
That will improve input support a bit when inputting numbers into the text fields.

Improved debugger support for two new types of breakpoints:
- Adding an U qualifier to the end of the breakpoint setting (after processor modes or ignoring of them) causes it to apply to SMM mode only (if not supplied it applies to non-SMM mode only).
- Adding an ! qualifier to end end of the breakpoint setting

So now SMM can be filtered (or SMM being ignored otherwise), with breakpoints also allowed to be saved disabled (saving them for easy re-enabling once needed).

Edit: Hmmm... On the 8088 in cycle-accurate mode I see it executing, but somehow not timing correctly it seems? RETF completes in 1 cycle, which it shouldn't.
Edit: Fixed the CPU new instructions to be guaranteed proper state reset to execute all phases of an instruction, but it still crashes somehow, doesn't even POST on 8088 XT anymore (in cycle-accurate mode)?

OK. As a little side project, I've modified the disk image support a bit:
- sfdimg and normal static disk images now support having a global setting for different sector sizes (still defaulting to 512 bytes, but the data in the header is now effective and changable in new disk images). Software using custom values in said field will now change sector read/write behaviour, as the field is actually used instead of ignored (it used to be assumed to be set to 512 even if it wasn't). If using disk images with non-512 byte sectors on older versions of UniPCemu, they will be written as 512 byte sectors instead, so take caution on using these on newer versions.
Simply said, don't use sfdimg disks with non-512 byte sectors on older versions of UniPCemu, as it will write the data incorrectly on those (although by default it's already set to 512 on creating those disk images).
- Implemented FDI/HDI disk image support on the floppy and ATA hard drive controllers. Non-512 byte sectors will be handled accordingly now with the new support of these formats (as well as on the other formats that didn't support those, like static and dynamic disk images mentioned above).
- Implemented mounting of FDI/HDI disk images. FDI disk images are mounted on floppy disks (filtered actually) and HDI disk images on hard disks. The backend does actually support both on both disk types (when manually editing the SETTINGS.INI file), but the settings menu's own mounting option will only show the fdi in the list of floppy disk drives and hdi on the list of hard disk drives to make management and seperation easier. Both are handled in roughly the same way on the backend, so you can actually rename the files between the two extensions to change from hard disk and floppy disk and vise versa (the file format of both disk types is identical, minus a floppy unused field that isn't emulated, so both types of drives will mount the disk image is requested to). The floppy or hard disk drive controller itself might have problems doing that though (due to interface limitations of sector addressing and LBA addressing support).

The 808x still doesn't boot right now, so that's still to be fixed first for a new release to happen.

The i440fx running MS-DOS 6.22 also doesn't boot now. It displays "Starting MS-DOS..." and then starting executing some LDS infinite loop (checking for non-zero values, which never happen).
Edit: A little bugfix later (on REP instruction issues), I see (once a MS-DOS 6.22 floppy disk is inserted into the floppy drive), MS-DOS 6.22 properly booting from the floppy drive.
So the OS itself is working properly now?
So does hard disk file content listing using the dir-command.
So could that one REP instruction issue have been the main issue causing the crashes?....
At least booting from floppy works correctly it seems (MS-DOS 6.22 at least).
Booting the XT machine gets the BIOS stuck in what seems to be an endless memory validation loop? (Generic Super PC/Turbo XT BIOS 3.0 I think).

On the XT, I see the following BIOS ROM points being reached so far:
e0dc: put zeroes in memory until BX=A000 (end of 640K memory space).
Reaches E0DE.
F92D: Fill memory with 5555.
F933: Check against 5555.
F93F: Fill with AAAA.
F945: Check against AAAA.
F953: Fill with FFFF.
F959: Check against FFFF.
F965: Fill with 0000.
F96B: Check against 0000.
F971: Completed.
e0f4: Reached some kind of check?
E0F8: Memory size 640KB detected valid.
Gets to E100.
Setup stack at E111.
Some routine at E5C0 reached (AH=1, ES=40, DS=F000)?

OK. Ran my latest version of baresifter (within my own repostory, waiting to be merged into the official baresifter by blitz) with all filters disabled.
Somehow, it immediately errors out when handling an interrupt (?) from user mode apparently, when fetching the first instruction of the fault handler, it's fetching from a weird location somehow?
It was the user-mode "{ 4, { 0x66, 0xE9, 0x00, 0x00 } }, // jmp 0x4" testcase.
From what I can see, the JMP itself runs fine, but the fault handler starting somehow messes up, somehow setting EIP to an invalid value? It (EIP) seems to be only 16 bits wide somehow?
Edit: Huh? It looks like after that instruction, the CPU breakpoint isn't triggered correctly and the next instruction doesn't start properly for some reason?

Edit: Fixed potential issues with instruction handling not finishing properly when the fault handler for single-step interrupt handling terminates (properly detecting it's use and finishing the instruction).
Edit: Fixing that, it still reports "Instrution length: b0rken!" for some weird reason?
Edit: OK. Now MS-DOS 6.22 doesn't boot anymore, even from floppy?