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?
Edit: Reverting to the single step breakpoint handling bugfix doesn't fix the issue, but booting the floppy disk version of MS-DOS 6.22 does somehow?
Edit: And with the last commit of non-repeating instructions committing CS/EIP to be returned to properly, that's fixed as well.
The floppy boot also crashes in the same way as the hard disk version if it's committing like a normal 'finished' instruction (setting a return point of hardware interrupts to be incorrectly past the REP instruction instead of before it, thus not interfering with the special REP handling and other repeated instruction breakpoints).
Edit: And floppy MS-DOS 6.22 is still booting now at least.
scandisk, otoh, crashes?