joncampbell123 / dosbox-x

DOSBox-X fork of the DOSBox project
GNU General Public License v2.0
2.54k stars 372 forks source link

286 reset vector support #28

Closed joncampbell123 closed 9 years ago

joncampbell123 commented 9 years ago

DOSBox-X supports reset by keyboard controller and port 92h. What it doesn't support (but should) is the "reset vector" trick. A specific value is written to CMOS nonvolatile RAM and then the processor is reset. The BIOS detects the specific value, and instead of fully resetting the system, directs CPU execution to a realmode vector stored in the BIOS data area.

For cputype=386 and cputype=486, we will also want to emulate the well known hack where the program turns off A20 then uses the reset trick. On real hardware, the A20 gate causes the CPU to execute the undefined area of RAM below the BIOS at 0xFFEFFFFF which is most likely 0xFF (invalid opcode) so the program's Invalid Opcode exception handler is executed instead right after reset (so that it can grab the ID register from of EDX to obtain stepping information). This trick originated on PC hardware where the A20 gate was external to the CPU, rather than later 486/Pentium processors with A20 as one of the pins for the CPU to emulate internally.

In addition to Windows 3.1 Standard Mode (if it were run on a 286 processor), some 1994-ish demoscene productions I've found might actually work if this is implemented. The demoscene production in question causes DOSBox to act as if CPU reset was initiated.

Windows 3.1 would use it on a 286-class processor to return to real mode. The demoscene entry (I think) may be using it to detect the CPU stepping ID, see: http://www.rcollins.org/ddj/Nov96/Nov96.html.

The RESET test program in DOSLIB could also carry out it's test in DOSBox-X when this is implemented.

joncampbell123 commented 9 years ago

I'm going to go ahead and make the A20 gate invalid opcode thing a separate enhancement