Morten79 wrote:

Thanks alot Codeholio for making DOSBox-x. After using 0.82.4 for long time I decided too try the newest version. I then discovered that the Drive option was missing from the menu bar. Actually it's been missing since 0.82.7 2018-06-01 13:05.
Why did you removed that feature? I use it for one game that's on six CD images. I hope it's a minor bug that you're willing too fix soon. I've tested both the 32 and the 64-bit Windows versions. In the meantime I'll just use 0.82.6 😀
I'm using Windows 10 64-bit.

That happened when I replaced the Windows menu resource inherited from Daum's branch, with the menu framework. I didn't bother to recreate the drive list because I didn't see any demand for it.

I'll keep your request in mind. I think it would be helpful to be able to mount and change floppies and CDs at runtime too.

The biggest challenge obviously is to write common code that can show a "select file" interface across all platforms.

Windows obviously has the "GetOpenFileName" function, but I'm not yet familiar with Mac OS X for it's version of the same, and using one from a toolkit like GTK would require linking to a whole GUI toolkit in Linux, so it's probably going to have a custom drawn file select dialog for platforms other than Windows and Mac OS X.

TheGreatCodeholio wrote:

That happened when I replaced the Windows menu resource inherited from Daum's branch, with the menu framework. I didn't bother t […]
Show full quote

Morten79 wrote:

Thanks alot Codeholio for making DOSBox-x. After using 0.82.4 for long time I decided too try the newest version. I then discovered that the Drive option was missing from the menu bar. Actually it's been missing since 0.82.7 2018-06-01 13:05.
Why did you removed that feature? I use it for one game that's on six CD images. I hope it's a minor bug that you're willing too fix soon. I've tested both the 32 and the 64-bit Windows versions. In the meantime I'll just use 0.82.6 😀
I'm using Windows 10 64-bit.

That happened when I replaced the Windows menu resource inherited from Daum's branch, with the menu framework. I didn't bother to recreate the drive list because I didn't see any demand for it.

I'll keep your request in mind. I think it would be helpful to be able to mount and change floppies and CDs at runtime too.

The biggest challenge obviously is to write common code that can show a "select file" interface across all platforms.

Windows obviously has the "GetOpenFileName" function, but I'm not yet familiar with Mac OS X for it's version of the same, and using one from a toolkit like GTK would require linking to a whole GUI toolkit in Linux, so it's probably going to have a custom drawn file select dialog for platforms other than Windows and Mac OS X.

Boxer (boxerapp.com) a GUI frontend for dosbox, has a way to use CDs/floppies the way he described. You might want to check it

bfcastello wrote:

Boxer (boxerapp.com) a GUI frontend for dosbox, has a way to use CDs/floppies the way he described. You might want to check it

Boxer is only available for Mac OS X.

If Boxer is open source it may serve as something to study on how to do the File Open/Save dialog boxes in Mac OS X.

Wouldn't it have to be since it is based on DOSBox?

I think it is.

I was given a compiled 64bit version on their github page to test last year.

Boxer hasn’t been updated since then, I stopped using it when macOS Mojave came, and when I wanted to use NE2000 patch (boxer doesn’t have it).

It is possible to keep use of the normal core in resolving the page faults for the normal core while using the full core to resolve the dynarec core faults. This is sample code:

1diff -rupN dosbox-X/src/cpu/cpu.cpp dosbox-X-Orig/src/cpu/cpu.cpp
2--- dosbox-X/src/cpu/cpu.cpp	2019-04-03 20:32:50 -0400
3+++ dosbox-X-Orig/src/cpu/cpu.cpp	2019-01-25 20:25:38 -0500
4@@ -1817,17 +1817,6 @@ void CPU_Snap_Back_Forget() {
5 	snap_cpu_snapped = false;
6 }
7 
8-bool CPU_IsDynamicCore(void) {
9-#if (C_DYNAMIC_X86)
10-    if (cpudecoder == &CPU_Core_Dyn_X86_Run)
11-        return true;
12-#elif (C_DYNREC)
13-    if (cpudecoder == &CPU_Core_Dynrec_Run)
14-        return true;
15-#endif
16-    return false;
17-}
18-
19 static bool printed_cycles_auto_info = false;
20 void CPU_SET_CRX(Bitu cr,Bitu value) {
21 	switch (cr) {
22@@ -2688,13 +2677,17 @@ public:
23 		cpudecoder=&CPU_Core_Normal_Run;
24 		if (core == "normal") {
25 			cpudecoder=&CPU_Core_Normal_Run;
26+			use_dynamic_core_with_paging=false;
27 		} else if (core =="simple") {
28 			cpudecoder=&CPU_Core_Simple_Run;
29+			use_dynamic_core_with_paging=false;
30 		} else if (core == "full") {
31 			cpudecoder=&CPU_Core_Full_Run;
32+			use_dynamic_core_with_paging=false;
33 		} else if (core == "auto") {
34 			cpudecoder=&CPU_Core_Normal_Run;
35 			CPU_AutoDetermineMode|=CPU_AUTODETERMINE_CORE;
36+			use_dynamic_core_with_paging=false;
37 #if (C_DYNAMIC_X86)
38 		} else if (core == "dynamic") {
39 			cpudecoder=&CPU_Core_Dyn_X86_Run;
40@@ -2711,6 +2704,7 @@ public:
41  			std::string core("normal");
42 			LOG_MSG("CPU:Unknown core type %s, switching to normal.",core.c_str());
43 			cpudecoder=&CPU_Core_Normal_Run;
44+			use_dynamic_core_with_paging=false;
45  		}
46 
47 #if (C_DYNAMIC_X86)
48diff -rupN dosbox-X/src/cpu/paging.cpp dosbox-X-Orig/src/cpu/paging.cpp
49--- dosbox-X/src/cpu/paging.cpp	2019-04-03 20:22:10 -0400
50+++ dosbox-X-Orig/src/cpu/paging.cpp	2018-11-12 03:19:06 -0500
51@@ -112,7 +112,10 @@ static Bits PageFaultCore(void) {
52 	CPU_CycleLeft+=CPU_Cycles;
53 	CPU_Cycles=1;
54 
55-	ret=CPU_Core_Full_Run();
56+	if (!use_dynamic_core_with_paging)
57+		ret=CPU_Core_Normal_Run();
58+	else
59+		ret=CPU_Core_Full_Run();
60 

61 	CPU_CycleLeft+=CPU_Cycles;
62 	if (ret<0) E_Exit("Got a dosbox close machine in pagefault core?");
63@@ -268,8 +271,6 @@ void PrintPageInfo(const char* string, P
64 
65 bool dosbox_allow_nonrecursive_page_fault = false;
66 
67-bool CPU_IsDynamicCore(void);
68-
69 // PAGING_NewPageFault
70 // lin_addr, page_addr: the linear and page address the fault happened at
71 // prepare_only: true in case the calling core handles the fault, else the PageFaultCore does
72@@ -282,7 +283,7 @@ static void PAGING_NewPageFault(PhysPt l
73 	if (prepare_only) {
74 		cpu.exception.which = EXCEPTION_PF;
75 		cpu.exception.error = faultcode;
76-	} else if (dosbox_allow_nonrecursive_page_fault && !CPU_IsDynamicCore()) {
77+	} else if (dosbox_allow_nonrecursive_page_fault && !use_dynamic_core_with_paging) {
78 		throw GuestPageFaultException(lin_addr,page_addr,faultcode);	
79 
80 	} else {
81

Is possible to get rid of mouse lag in the Win95 protected mode MS-DOS? Basically when user runs the command line windowed, the mouse pointer lags and the refresh rate slightly changes to better while pressing or holding any key from keyboard input. Yet, the keyboard input works fine in both environments.

DOSBox-X has a modification to the dynamic core in decoder.h (as compared to vanilla dosbox):

1static bool MakeCodePage(Bitu lin_addr,CodePageHandler * &cph) {
2	Bit8u rdval;
3...
4	if (handler->getFlags() & PFLAG_NOCODE) {
5			LOG_MSG("DYNX86:Can't run code in this page!");
6			cph=0;		return false;
7	}

But the same code is unmodified except for the false condition in the dynrec core (decoder_basic.h):

1static bool MakeCodePage(Bitu lin_addr,CodePageHandlerDynRec * &cph) {
2	Bit8u rdval;
3...
4	if (handler->flags & PFLAG_NOCODE) {
5		if (false) { // PAGING_ForcePageInit(lin_addr)) {
6			handler=get_tlb_readhandler(lin_addr);
7			if (handler->flags & PFLAG_HASCODE) {
8				cph=(CodePageHandlerDynRec *)handler;
9				return false;
10			}
11		}
12		if (handler->flags & PFLAG_NOCODE) {
13			LOG_MSG("DYNREC:Can't run code in this page");
14			cph=0;
15			return false;
16		}
17	} 

I think the modification to the dynamic core originated from Hal's modified dosbox build (megabuild) which was enhanced for paging operations. Since one of those code blocks in the dynrec is not active, it could be removed along with a redundant check on (handler->flags & PFLAG_NOCODE).

The recent compiler warning fix casts written only (/cpu/core_dynrec/cache.h):

1+			if (written>block->cache.size+CACHE_MAXSIZE) E_Exit("CacheBlock overrun 1 %lu",(unsigned long)written-block->cache.size);

but this could be written so both variables are cast like in a related line that is not shown here:

1+			if (written>block->cache.size+CACHE_MAXSIZE) E_Exit("CacheBlock overrun 1 %lu",(unsigned long)written-(unsigned long)block->cache.size);

hail-to-the-ryzen wrote:

The recent compiler warning fix casts written only (/cpu/core_dynrec/cache.h): […]
Show full quote

The recent compiler warning fix casts written only (/cpu/core_dynrec/cache.h):

Copy code to clipboard

1+			if (written>block->cache.size+CACHE_MAXSIZE) E_Exit("CacheBlock overrun 1 %lu",(unsigned long)written-block->cache.size);

but this could be written so both variables are cast like in a related line that is not shown here:

Copy code to clipboard

1+			if (written>block->cache.size+CACHE_MAXSIZE) E_Exit("CacheBlock overrun 1 %lu",(unsigned long)written-(unsigned long)block->cache.size);

Hmmmm.... why not post this on his github project page? Not a complaint, just a honest question

So others may easily search and archive information.

Remapping video memory according to r3974 may restrict access to the mmio region by the s3 trio Windows driver. Testing in the dos box may verify.

A 16-bit wave out sound device fails to close after exiting a dos box in Windows 95. Tested by running DOS Quake, closing the dos box, and then running a 32-bit application dependent on the sound device. However, it works as expected in PCem.

On further testing of 16-bit wave out, I now see that the device has the same behavior in pcem. As expected, other DOS games in the dos box also do not open the sound device in the emulators.

I believe the r4039 commit is not incorporated fully into dosbox-x. The code block is different between it and SVN. I can paste a suggestion, if needed.

Here's a DOSBox-X fix to consider for DOSBox SVN:

On Intel processors, if STI is immediately followed by CLI, then no interrupts are serviced even if some are pending.

I wrote a program in DOSLIB to test this on an actual Intel i486 and I can confirm this is the case even if STI+CLI is executed rapidly in a loop for one second: No interrupts processed.

The reason this came up is that someone mentioned a PC-98 game (made by a game maker program, apparently) that appeared to crash at specific intervals if FM music was enabled.
Upon closer examination the crash happened when the vertical retrace interrupt happened during the FM interrupt, and THAT happened because the FM interrupt has STI+CLI sequences at various places for some reason despite the fact that the FM driver code is non-reentrant. The stack switching at entry and exit will corrupt the stack pointer if entered again while in the middle of processing.

The reason it never crashed on real hardware is that on real Intel CPUs, STI+CLI is too quick to process any interrupts.

The reason it crashed in DOSBox-X is because DOSBox-X inherited the normal core from DOSBox SVN which upon processing STI, immediately breaks to process interrupts.

It might be worth it to see if some games on your compatibility list crashed because of similar sequences in the code.

This fix is implemented in DOSBox-X by adding to the normal core a "peek" function. The STI handler is coded to "peek" at the next opcode, and ignore the STI if the next opcode is CLI.

I do not recommend simply clamping CPU_Cycles to a low value on STI. You will eventually hit a corner case with a game that causes the CPU core to get stuck in an infinite loop.

I have a small issue, not DOSBox-X related, but I believe someone here can help.

When I try to run SimCity 2000 from DOS, "C:\Games\SC2000\SC2000.exe" I get this message:

"Critical Error, Microsoft compatable mouse not found. Please load mouse driver"

Any ideas, please? Tks in advance.

bfcastello wrote:

I have a small issue, not DOSBox-X related, but I believe someone here can help. […]
Show full quote

I have a small issue, not DOSBox-X related, but I believe someone here can help.

When I try to run SimCity 2000 from DOS, "C:\Games\SC2000\SC2000.exe" I get this message:

"Critical Error, Microsoft compatable mouse not found. Please load mouse driver"

Any ideas, please? Tks in advance.

Should not happen unless int33=false is in your dosbox.conf or you are booting a bootdisk to run the game without a mouse driver in the guest OS.

I know that Sim City 2000 is also one of those games that may get unstable or crashy if loaded too low in memory, try LOADFIX first.

TheGreatCodeholio wrote:

bfcastello wrote:

I have a small issue, not DOSBox-X related, but I believe someone here can help. […]
Show full quote

I have a small issue, not DOSBox-X related, but I believe someone here can help.

When I try to run SimCity 2000 from DOS, "C:\Games\SC2000\SC2000.exe" I get this message:

"Critical Error, Microsoft compatable mouse not found. Please load mouse driver"

Any ideas, please? Tks in advance.

Should not happen unless int33=false is in your dosbox.conf or you are booting a bootdisk to run the game without a mouse driver in the guest OS.

I know that Sim City 2000 is also one of those games that may get unstable or crashy if loaded too low in memory, try LOADFIX first.

I'm actually booting from a boot disk. I guess that I need a mouse driver...

Edit: Fixed with the installation of a mouse driver for DOS (MOUSE.COM). Never thought I would forget simple things I knew 25 years ago.