Not sure if it's 100% slop, but as someone knowledgeable about older x86 processors, I can say after a casual look through "src/emulator/cpu.c" that the code is pretty terrible and often wrong.
For example, "subtract with carry" simply adds the carry to the second operand before doing the subtraction, which will wrap around to zero if it's 0xffff; this doesn't affect the result, but the carry out will be incorrectly cleared. Shift with a count of zero updates the flags, which it doesn't on real hardware. Probably many more subtle bugs with the flags as well.
It can't really be called a 286 emulator either, because it only runs in real mode! For some reason there is already code in there to handle the 32-bit addressing of the 386, but it can't have been written by someone who actually understands how the address size override works - it changes both the size and the encoding of the address register(s), "AX+BX" is never a thing, nor is "EBX+ESI" (etc) used if there is only an operand size override. Also what looks like a (human?) copy-paste mistake with "EBX" in a place where it should be "EAX". At least all that code is #ifdef'd out.
And rather than running a real BIOS, it appears to handle its functions in the INT emulation code, but what is there looks too incomplete to support any real software.
There is emulation code for the PIC (interrupt controller) and PIT (timer) + various other stuff. The intcall86() filters out and handles INT 10h/13h/etc but everything else is emulated "for real": ip/cs/flags are pushed, new cs:ip set, etc.
There is an 8KB BIOS of some sort defined as a big array which should handle boot and hardware interrupts.
> Probably many more subtle bugs with the flags as well.
Sure. And lots of subtle bugs in general. Which is fine for someone's personal fun side project.
Since it's 286, can it run the cursed Xenix 286? Do hacked GDTs work?