Hmmm... Just found one little missing line-break when checking the 80386+ 32-bit opcode extensions(the 32-bit versions of the 80(1)86 opcodes). All other instructions seemed to run without issues(on the 80386 32-bit extensions side).
So if there's an issue with the instruction execution, it should be in the 8086 or 80186 core(seeing as the 80286 only adds 0F opcodes).
And I doubt that the crashing applications(WhatVGA and CheckIt Diagnostics 3.0) use any 80286+ opcodes when starting up, before making the screen blue for the different startup tests(or detecting hardware for WhatVGA)?
I saw not a single error otherwise in the 80386+ 80(1)86 opcode execution(all 8086 and 80186 opcodes' 32-bit variants).
Edit: Almost checked all 8086+/80186+ 8/16-bit opcodes as well. So far no errors observed(looking from Visual Studio's debugger debugging UniPCemu).
So only a few potentional 80(1)86 errors left(as well as all potentional 80286+/80386+ 0F opcodes and 80486+/Pentium ones). Hmmm...(so far checked until the BIOS has asked for and gotten the F1 key to continue to boot(in UniPCemu's case: starting INT19 to start the XT-IDE Universal BIOS(F8 for using Plop for CD booting) I'm using atm).
Otherwise, if nothing shows up after those, the issue must be somewhere in the miscellaneous CPU behaviour itself(e.g. exceptions/interrupts/far code segment transfers itself etc.)? But I've already checked those extensively in the past? Those can be found in the various non-'opcodes*_*.c' files, e.g. stack management(cpu_stack.c), interrrupts(protection.c and cpu_interrupts.c), multitasking.c(probably not, since it doesn't use TSS multitasking?) and various protection mechanisms(protection.c).
Edit: So far checked all 8086-80186 8/16-bit and 32-bit extensions opcodes(not the 80386+ only ones yet). No issues have been found so far(gotten until MS-DOS 6.22 prompt and past the boot menu I have in the test image. Also executed a DIR command for a bit of extra opcodes. Still no issues found yet.
Edit: OK. Ran CheckIt, but other than a single JG jump that didn't happen until then(opcode 7F), nothing shows up there either, but it still crashes. Hmmm...
Edit: Added 80486/80586 opcodes and extensions. Still nothing.
Edit: Added 80286 opcodes. Hmmm... SALC? FPU DBh opcode? FNINIT... FPU D9h opcode. FNSTCW... That's it for the 80286+ opcodes.
That just leaves the 80386+ 0F opcodes?
Edit: A few more of those(MOVZX, 0F84 JZ 16-bit), but nothing more of those. So another dead end there 🙁
Now, where is the cause? The only other place where such a strange real-mode bug could appear is in the different mechanics of the CPU itself, which only contain the segment-related logic itself(far jumps/calls and protected mode-like semantics and interrupts in real mode)?
Edit: More 286+/386+ opcodes validated with the CD-ROM drivers activated.