mirror of
https://github.com/joncampbell123/dosbox-x.git
synced 2025-10-13 17:48:10 +08:00
da27ede399
more keyboard debug printf's. Added commentary on what Windows NT does with the keyboard controller.
74 lines
2.9 KiB
Groff
74 lines
2.9 KiB
Groff
Apparently it's possible to install Windows NT 3.1 in DOSBox and get it to run!
|
|
Here's how:
|
|
|
|
1. Edit your dosbox.conf and make sure you have these settings:
|
|
|
|
[dos]
|
|
biosps2=true
|
|
|
|
[keyboard]
|
|
aux=true
|
|
|
|
Windows NT 3.1 will not detect the AUX port if it does not see the
|
|
BIOS reporting via INT 15h, apparently. The AUX port must be enabled.
|
|
And finally, because the NT 3.1 AUX driver does not carry out the
|
|
full PS/2 device initialization properly, you need DOSBox to default
|
|
to streaming mode when reporting is enabled. NT 3.1 apparently does
|
|
not send the command to enable streaming (leaves it in reporting
|
|
mode).
|
|
|
|
2. Install MS-DOS 6.22 first.
|
|
|
|
3. Use MS-DOS to run the NT installer.
|
|
|
|
4. Shutdown DOSBox-X
|
|
|
|
5. Go into src/cpu/cpu.cpp and modify the top as follows:
|
|
|
|
#define CPU_CHECK_EXCEPT 1
|
|
// #define CPU_CHECK_IGNORE 1
|
|
|
|
The NT kernel apparently requires exception handling to work properly
|
|
before it will boot in DOSBox.
|
|
|
|
6. Startup DOSBox-X and let NT boot. It should make it to the graphical
|
|
desktop.
|
|
|
|
----------------------------------------------------------------------
|
|
|
|
Observations about Windows NT and the keyboard controller:
|
|
|
|
- NT uses INT 15h AH=0xC2 functions initially at boot up to detect PS/2
|
|
mice, but during the full 32-bit OS, uses I/O ports 0x60 and 0x64
|
|
exclusively.
|
|
|
|
- NT calls INT 15h AX=0xC206 BH=0x00 (extended/read device status).
|
|
I'm not sure what it does with it, since regardless of the return value
|
|
it eventually asserts control of the AUX port and issues PS/2 mouse
|
|
reset, set sample rate/resolution commands, and enable reporting anyway.
|
|
|
|
- If the INT 15h call fails to eat the acknowledgement of commands
|
|
(the 0xFA byte returning from the mouse or keyboard), NT's keyboard
|
|
and mouse driver is liable to get some commands screwed up. In my case,
|
|
it caused Windows NT to issue a command to read the 8042 command byte,
|
|
then read back the ACK instead, modify it, and write THAT back to the
|
|
command byte instead of the proper command byte value. The end result
|
|
of course was that both keyboard and mouse did not work after that.
|
|
|
|
- Windows NT modifies the 8042 command byte on startup to a value like
|
|
0x64, which curiously enough means to leave PS/2 port translation
|
|
enabled, as well as leaving IRQ1 and IRQ12 disabled (from the 8042
|
|
controller's point of view). Yes, that's right: Windows NT doesn't
|
|
use the keyboard controller's interrupt mode to receive data from
|
|
the controller. I guess that's a positive in a way because it ensures
|
|
that NT can continue reading the keyboard in case it does something
|
|
stupid to get the controller wedged, but still...
|
|
|
|
Oh, and according to debug dumps of the IO to the 8042 controller,
|
|
Windows NT apparently doesn't bother to wait for the controller to
|
|
signal the buffer is empty either. I guess the programmer assumed
|
|
that, if it didn't use interrupts, and simply had the OS write data
|
|
on a timer interval or something, that the interval would be long
|
|
enough for the 8042 to drain it's buffers.
|
|
|