I have another interim experimental release up (no Win32 build for that reason).

http://hackipedia.org/Projects/DOSBox-X/dosbo … df3f-src.tar.xz

Changes include:

Fixes to the code to compile properly for 64-bit Linux.

CTRL+C and CTRL+BREAK support in DOSBox DOS kernel.
Typing CTRL+C should now trigger CTRL+C instead of typing hearts.
If you use DOSBox to run ancient DOS development IDEs and compilers, being able to CTRL+C out is vital.

Added support for resetting the CPU and system through the keyboard controller or port 0x92. Windows ME no longer complains about not being able to reset the computer when you restart windows. It turns out Windows 95 and 98 were able to reset DOSBox regardless because they contain fallback code to call INT 19h should the keyboard method fail, while Windows ME doesn't use that fallback anymore.

Changed #defines in cpu.cpp to enable exceptions for segment loading when privilege levels differ (RPL != DPL). The defaults between C_DEBUG and normal seemed kind of silly to me (either ignore them entirely, or E_Exit() when it happens--why?) Seems to have no effect on Windows 9x/ME, but the change actually makes it possible to boot Windows NT 3.1 in DOSBox! (why it crashes at the login prompt or when I move the mouse is another issue to look into).

New experimental "non-recursive" page fault mode added. It's not 100% stable, so it's disabled by default. Enable by adding 'non-recursive page fault=1' to the cpu section of your dosbox.conf. When enabled, the hack if possible triggers the page fault exception in a way that aborts the CPU instruction and throws control back up to the Normal_Loop() where the CPU exception can be set up and executed non-recursively. There seem to be a few corner cases with core=dynamic where bugs show up especially if the page fault was caused by a floating point instruction in the guest. Otherwise, the non-recursive mode seems to resolve the issue with page faults building up and overflowing the PF queue. I'm able to use Windows 98 SE now without the PF queue case triggering and slowing down the whole virtual machine. Even Windows ME is usable now (though you still have to forcibly bypass the first-boot setup stage that seems to reliably crash DOSBox).

Also confirmed:

The non-recursive mode makes it possible to use Windows 98 with IDE enabled for all drives and the S3 driver without page fault issues.

APM BIOS emulation works fine when Windows ME shuts down, but the APM BIOS driver always causes a BSOD and should be disabled from the System control panel applet.

I would also like to point out that in the NOTES and BUGS directories of the source tree I've been taking notes and writing wish lists as well as plans and a list of bugs and issues I would like to address if possible. One big concern of mine is that core=dynamic is essentially required to run Windows 9x/ME. core=normal and other settings don't work. I will be away from the project for the next week or two. If anyone here would like to help me with what I've noted in those files, go for it.

In some of the spare time I've had I've also been testing miscellaneous things in DOSBox-X running Windows 95:

https://www.youtube.com/watch?v=mcdPk6ExOd0

https://www.youtube.com/watch?v=IhmcWjmn0eo

Enjoy.

1commit 925ee125517bb6e380c4a05886b153d252f1df3f
2Author: Jonathan Campbell <jonathan@castus.tv>
3Date:   Sun Apr 13 16:32:49 2014 -0700
4
5    change default cpu.cpp exception handling to actually carry out the
6    exception. doing this (and enabling the non-recursive page faults)
7    allows DOSBox to actually boot into Windows NT 3.1!
8
9commit cf52e950462493b4a7381817a8d818f6970e2d4a
10Author: Jonathan Campbell <jonathan@castus.tv>
11Date:   Sun Apr 13 16:11:19 2014 -0700
12
13    E_Exit: print to STDERR
14
15commit a9d791d3c98ff919b19a117d4a5741a0d5dc96bd
16Author: Jonathan Campbell <jonathan@castus.tv>
17Date:   Sun Apr 13 16:07:55 2014 -0700
18
19    add support for system reset via port 92h
20
21commit 4aef7cf5f3a235bd923c4f00dead7eb8f4d0beb8
22Author: Jonathan Campbell <jonathan@castus.tv>
23Date:   Sun Apr 13 14:58:35 2014 -0700
24
25    more
26
27commit 277b6d0b16325d65d4068bfdf60f16da5ba6865e
28Author: Jonathan Campbell <jonathan@castus.tv>
29Date:   Sun Apr 13 14:35:20 2014 -0700
30
31    add option (enabled by default) to allow resetting the DOSBox emulator
32    if the guest OS or application uses the standard method through the
33    keyboard controller. This fixes Windows ME's inability to reboot the
34    system when you select "restart system". Windows 95 and 98 apparently
35    happened to work regardless because they contained code to fallback to
36    calling INT 19h from real mode... or something.
37
38commit 49f72786d4d2dbcd2320552e6924bcce2521b6e2
39Author: Jonathan Campbell <jonathan@castus.tv>
40Date:   Sun Apr 13 14:08:21 2014 -0700
41
42    add more bug report
43
44commit 5bf3e55509bfe67d724de04a5a034a01ae916ac2
45Author: Jonathan Campbell <jonathan@castus.tv>
46Date:   Sun Apr 13 09:35:38 2014 -0700
47
48    add commentary
49
50commit 09f7efc66f2ae5a62755a57d3c15bfec44e18bc8
51Author: Jonathan Campbell <jonathan@castus.tv>
52Date:   Sun Apr 13 05:34:41 2014 -0700
53
54    hm, the non-recursive page fault code isn't 100% stable with dynamic.
55    default off.
56
57commit 2069888c1c6608decf8375df0fdb68115d3b4bf0
58Author: Jonathan Campbell <jonathan@castus.tv>
59Date:   Sun Apr 13 05:05:42 2014 -0700
60

61    comment out assertion in IDE emulation that triggers if not word
62    aligned. Apparently Windows 98 can trigger it when installing Visual
63    Studio 4.0 or something.
64
65commit 33b84d7d66fc502e709324812f011d48c992cbd1
66Author: Jonathan Campbell <jonathan@castus.tv>
67Date:   Sun Apr 13 03:13:32 2014 -0700
68
69    add experimental non-recursive pagefault mode. so far, so good.
70    it doesn't seem to have any effect on problems with IDE and S3 graphics
71    emulation, but it does seem to lessen to probability that Windows 98
72    triggers the pagefault recursion issue that causes it to slow down so
73    much.
74
75commit e14e3d9966b006be4b8a617b9ef71d0b3cf90a04
76Author: Jonathan Campbell <jonathan@castus.tv>
77Date:   Sat Apr 12 18:32:27 2014 -0700
78
79    remove save state code that typecast function pointers to Bit32u for
80    some reason. added code to conditionally call into the dynamic core only
81    IF the dynamic core was compiled in. This fixes several compile issues
82    with x86_64.

Tremendous work on your CPU core emulation! And all the other updates, too! I tried to find the bits relevant to your "non-recursive page fault" mode and added them to a SVN build. It's brilliant coding in bypassing the page fault problems and I look forward to studying the complex patch to allow this. I tested it with GLQuake and it worked perfectly -- generating debug messages in the console window where the alternative page fault mode is used. I'm surprised this was possible with the dynamic core and also without heavily modifying the page fault core (as danoon did). I will continue to test with 9x games (so far the only runtime error was from UT99, presumably related to the "floating point instruction" as mentioned above).

Also, the fact that NT3.1 boots is very promising. I wish I understood the debugger better instead of relying on printf statements. 😀

I ported danoon's "non-recursive normal core" and this "ported code" is in this patches subforum. It allows 9x to boot (and ME to install), although its code in the normal_loop may require a conditional statement or else some modification. I can try to help as you wish.

Thank you again for these wonderful additions to your emulation.

NT on DOSBox?!? 😳 oh my god! Excellent!

SA1988 wrote:

NT on DOSBox?!? 😳 oh my god! Excellent!

Don't get your hopes up quite yet... at this stage so far it's possible to make it through the WINNT.EXE, boot floppy, and graphical setup stages, but getting past the CTRL+ALT+DEL login prompt is impossible because it will always BSOD there (and it seems to BSOD anyway if you move or click the mouse!). But that's better than before, where you would boot the boot floppy written by WINNT.EXE and the initial setup boot would barely make it past the initial blue boot screen before faulting. But it's also worth noting that NT 3.1 has it's share of crashiness in VirtualBox too (especially if you run MS-DOS programs within the program manager), so it's best not to expect 100% stability anyway.

Seems like it's time to call it DOSBox-Win branch or something like that 😉

Dominus wrote:

Seems like it's time to call it DOSBox-Win branch or something like that 😉

Or add in danoon's Boxed Wine and call it WinBox.

collector wrote:

Dominus wrote:

Seems like it's time to call it DOSBox-Win branch or something like that 😉

Or add in danoon's Boxed Wine and call it WinBox.

Was there a thread about that? There don't really seem to be many details on that page.

The link was from danoon's thread on jDOSBox.

Java Port

He managed to get Full Tilt Pinball 2 and Caesar III to run in jDOSBox without having Windows installed in it. I would love to see this for x-branch to avoid the slowness and loss of robustness of Java. I also suspect that some of the improvements of TheGreatCodeholio's branch might be necessary for some Win games/apps.

Which vs version do we use to compile this? or should one try mingw or something?

Another update:

http://hackipedia.org/Projects/DOSBox-X/dosbo … 3f49-src.tar.xz

Bug fixes in this update:

- Fixed bug in IDE emulation that only considered the master device when emulating CD-ROM CD change/spinup/spindown times.
Prior to this fix, IDE ATAPI emulation failed completely if you attached the CD-ROM drive as IDE primary slave or secondary slave. From the OS's point of view, the device "hung". MSCDEX.EXE would get stuck in an infinite loop trying.

- BOOT command (booting a guest OS) now disables INT 33h emulation, since INT 33h is a DOS API not a BIOS API.

- Modified DOSBox GUI mouse handling NOT to do any INT 33h emulation logic if booted into a guest OS.
Why does that matter? Well, INT 33h emulation calls INT10_SetCurMode(), which uses real_readb() to read the BIOS data area. Whoever wrote that code apparently forgot that real_readb() is beholden to the guest OS's page tables, and therefore, if you're running a 32-bit protected mode OS that maps out that part of the linear memory space (like Windows NT 3.1), doing that causes a page fault. To put it another way, the reason Windows NT 3.1 was crashing when you moved the mouse was because DOSBox was apparently still trying to emulate INT 33h and causing the crash from it's mouse movement handler. NT now boots up to the login prompt and moving the mouse no longer causes an instant BSOD.
This issue with page faulting is also the reason why Windows ME's setup phase had a problem with BSOD'ing when attempting to load it's native mouse driver, since Windows ME also maps out the first 64KB for 32-bit code. What would happen is that the System Configuration stage would eventually get to configuring the mouse, then BSOD, and when you hit enter to recover, the mouse cursor would remain frozen. After this fix, WinME no longer does that during the setup phase. Also noted in the NOTES is that the other crash during Setup (dynamic core + pagefault + floating point problem) can be averted with lots of patience and setting core=normal between first reboot and when the WinME desktop finally shows up.
I also added file "DOSBox mouse emulation assumptions and why they failed Windows NT and Windows ME" to the NOTES directory to explain the issue in more detail and why this wasn't a problem with Windows 3.1 through Windows 98 SE.

- PS/2 emulation hack for Windows NT 3.1
Having gotten NT 3.1 to boot without crashing, I then found that the mouse cursor still did not respond to movement. Looking at what NT was doing with the AUX port, it turns out NT correctly does MOST of the process involved in resetting and configuring the PS/2 mouse, except that while enabling reporting, it does not send the command to set streaming mode. The hack allows you to have PS/2 mouse emulation default to streaming mode on reset (and therefore work with NT) by adding "aux default reporting mode streaming=true" to the "keyboard" section of your dosbox.conf, which is a technical violation of what PS/2 mice are supposed to do, but we're talking about Microsoft here 😀

- Additional testing for the hell of it:
I also boot-tested Windows NT 3.51, NT 4.0, and Windows 2000 in DOSBox-X. The setup program is able to install the OS, but for some strange reason, Windows NT's IDE driver is not able to identify which IDE device it booted from (INACCESSIBLE_BOOT_DEVICE). These versions of Windows only got as far as the initial blue bootup screen. Oh well, I tried. 😀

Happy hacking.

Hah, DOSBox-X apparently lacks the same crashiness issues VirtualBox has when NT is running DOS programs!

therock247uk wrote:

Which vs version do we use to compile this? or should one try mingw or something?

I use Visual Studio 2008 to compile the Win32 version. I've never tried it with mingw, yet.

TheGreatCodeholio wrote:

therock247uk wrote:

Which vs version do we use to compile this? or should one try mingw or something?

I use Visual Studio 2008 to compile the Win32 version. I've never tried it with mingw, yet.

btw, is the read capacity 0x25 command implemented? Because the only ide cdrom driver for NT 3.1 in existance uses it.

collector wrote:

The link was from danoon's thread on jDOSBox.

Java Port

He managed to get Full Tilt Pinball 2 and Caesar III to run in jDOSBox without having Windows installed in it. I would love to see this for x-branch to avoid the slowness and loss of robustness of Java. I also suspect that some of the improvements of TheGreatCodeholio's branch might be necessary for some Win games/apps.

I'm not entirely clear how that's supposed to tie into DOSBox's emulation. Is he expecting WINE to do all the dirty work and then export the sound and graphics to DOSBox?

To be honest, though it's a lot more work, I would instead write a native Windows 3.1-like emulation layer into DOSBox itself (the same way DOSBox emulates INT 21h and DOS right now), where DOSBox does the work of setting up a Win16 environment, loading and tracking DLLs and EXEs, and proving a built-in shell. You could access this built-in mode from Z:\WIN.COM, of course, from DOSBox's native DOS prompt. Doing it this way would also mean DOSBox itself could provide more useful debugging information on what is loaded where and why, if you have a troublesome Win16 program. It would also allow DOSBox to run Windows 3.1 games without having to install Windows 3.1. Then as the Windows 3.1 emulation becomes stable, you logically build from there to add Win32s emulation, then Windows 95 emulation, then the various additional APIs... and grow from there. I would expect plenty of borrowing from the WINE project too, of course.

The NE format isn't all that complicated by itself to implement. In fact, on Hackipedia.org in the DOSLIB2 project I have a proof-of-concept library that demonstrates loading and calling DLLs in 16-bit real-mode DOS (something I feel Microsoft should have been offering the DOS world back in the day instead of reserving that for Windows).

SA1988 wrote:

TheGreatCodeholio wrote:

therock247uk wrote:

Which vs version do we use to compile this? or should one try mingw or something?

I use Visual Studio 2008 to compile the Win32 version. I've never tried it with mingw, yet.

btw, is the read capacity 0x25 command implemented? Because the only ide cdrom driver for NT 3.1 in existance uses it.

I was not aware of that command. I'll look it up and see what I can do.
Does anything else use that command?

I think the NT 4.0 and 2000 atapi drivers do

Windows NT 3.1's built-in Tseng ET4000 SVGA driver works with DOSBox-X (machine=svga_et4000)

The same can't be said for S3 emulation though (machine=svga_s3)

SA1988 wrote:

I think the NT 4.0 and 2000 atapi drivers do

Indeed. Looking at debug output while trying to boot NT 4.0 shows several attempts to use ATAPI command 0x25.
Looks like command 0x25 is only expected to return two DWORDs with sector size and last sector number. That's pretty easy to do. I'll get right on it.

Ah cheers i got it to build. 😁

TheGreatCodeholio wrote:

SA1988 wrote:

I think the NT 4.0 and 2000 atapi drivers do

Indeed. Looking at debug output while trying to boot NT 4.0 shows several attempts to use ATAPI command 0x25.
Looks like command 0x25 is only expected to return two DWORDs with sector size and last sector number. That's pretty easy to do. I'll get right on it.

http://hackipedia.org/Projects/DOSBox-X/dosbo … cf9a-src.tar.xz

Just added it.