cputype=8086 for 8088 and 286 level CPU emulation respectively. At this
time, all the setting does is change the prefetch queue and how the
FLAGS register acts. So far I have tested that cputype=286 is able to
trick programs into detecting a 286 rather than a 386 (those using
Intel's CPU detection algorithm).
Test results:
cputype=286 Windows 3.1 seems to attempt 286-ish mode switching (doesn't work yet)
cputype=8086 Windows 3.1 errors out, says it needs 286 for standard mode
Notes:
MSD.EXE (Microsoft Diagnostics) reports the CPU as 80186 when
cputype=8086. How do we fix this?
MSD.EXE correctly reports CPU as 80286 when cputype=286, but then
reports the FPU as a 80387. How do we fix that?
These first steps will eventually lead to an alternate normal/prefetch
core that implements 286-level decoding, and another with 8086-level
decoding (including opcode 0x0F as "pop cs" and other oddities).
286-level DOS programs to force their way out of protected mode back to
real mode was to initiate CPU reset by deliberately setting up protected
mode in a way that caused an exception, then a double fault, then a
triple fault. On actual hardware the CPU starts a shutdown cycle which
IBM hardware recognizes and initiates CPU reset instead. Using the CMOS
shutdown byte and the reset vector, a DOS program can "crash" it's way
back to real mode fairly quickly this way.
In case this new emulation causes any problems, you can disable the
double & triple fault emulation from dosbox.conf.
