There is a nes emulator for dos that causes repeated logs of unhandled INT2F calls, they correspond to the enabling and disabled of critical sections in Win31.

1diff -rupN dosbox-orig/src/dos/dos_misc.cpp dosbox/src/dos/dos_misc.cpp
2--- dosbox-orig/src/dos/dos_misc.cpp
3+++ dosbox/src/dos/dos_misc.cpp
4@@ -71,7 +71,7 @@ static Bitu INT2F_Handler(void) {
5 	for(Multiplex_it it = Multiplex.begin();it != Multiplex.end();it++)
6 		if( (*it)() ) return CBRET_NONE;
7    
8-	LOG(LOG_DOSMISC,LOG_ERROR)("DOS:INT 2F Unhandled call AX=%4X",reg_ax);
9+	LOG(LOG_DOSMISC,LOG_DEBUG)("DOS:INT 2F Unhandled call AX=%4X",reg_ax);
10 	return CBRET_NONE;
11 }
12 

hail-to-the-ryzen wrote on 2020-07-26, 01:47:

There is a nes emulator for dos that causes repeated logs of unhandled INT2F calls, they correspond to the enabling and disabled […]
Show full quote

There is a nes emulator for dos that causes repeated logs of unhandled INT2F calls, they correspond to the enabling and disabled of critical sections in Win31.

Copy code to clipboard

1diff -rupN dosbox-orig/src/dos/dos_misc.cpp dosbox/src/dos/dos_misc.cpp
2--- dosbox-orig/src/dos/dos_misc.cpp
3+++ dosbox/src/dos/dos_misc.cpp
4@@ -71,7 +71,7 @@ static Bitu INT2F_Handler(void) {
5 	for(Multiplex_it it = Multiplex.begin();it != Multiplex.end();it++)
6 		if( (*it)() ) return CBRET_NONE;
7    
8-	LOG(LOG_DOSMISC,LOG_ERROR)("DOS:INT 2F Unhandled call AX=%4X",reg_ax);
9+	LOG(LOG_DOSMISC,LOG_DEBUG)("DOS:INT 2F Unhandled call AX=%4X",reg_ax);
10 	return CBRET_NONE;
11 }
12 

Ah, yes. The one INT 2Fh call a DOS program can use to freeze the user's desktop if not released (leaving only the DOS window responsive), having used to play with that call back in the day 😀

Perhaps the NES emulator thought it could improve performance somehow?

Anyway I agree. Unknown INT 2Fh calls are not something to be shown to the user unless you run with --debug.

Here is a change to consider in the case where a game searches for mode 0x068 and it is not found. It may lead to a reset to an unintended mode in that case.
diff -rupN dosbox-orig//src/ints/int10_modes.cpp dosbox/src/ints/int10_modes.cpp
--- dosbox-orig//src/ints/int10_modes.cpp
+++ dosbox/src/ints/int10_modes.cpp
@@ -56,6 +56,8 @@ VideoModeBlock ModeList_VGA[]={
{ 0x054 ,M_TEXT ,1056,344, 132,43, 8, 8, 1 ,0xB8000 ,0x4000, 160, 449, 132,344, 0 },
{ 0x055 ,M_TEXT ,1056,400, 132,25, 8, 16, 1 ,0xB8000 ,0x2000, 160, 449, 132,400, 0 },

+/* Alias of mode 100 */
+{ 0x068 ,M_LIN8 ,640 ,400 ,80 ,25 ,8 ,16 ,1 ,0xA0000 ,0x10000,100 ,449 ,80 ,400 ,0 },
/* Alias of mode 101 */
{ 0x069 ,M_LIN8 ,640 ,480 ,80 ,30 ,8 ,16 ,1 ,0xA0000 ,0x10000,100 ,525 ,80 ,480 ,0 },
/* Alias of mode 102 */

This may help from writing outside the writecache with normal5x/6x:

1diff -rupN dosbox-orig/src/gui/render_scalers.cpp dosbox/src/gui/render_scalers.cpp
2--- dosbox-orig/src/gui/render_scalers.cpp	
3+++ dosbox/src/gui/render_scalers.cpp
4@@ -30,9 +30,9 @@ Bit16u Scaler_ChangedLines[SCALER_MAXHEI
5 Bitu Scaler_ChangedLineIndex;
6 
7 static union {
8-	Bit32u b32 [4][SCALER_MAXWIDTH*3];
9-	Bit16u b16 [4][SCALER_MAXWIDTH*3];
10-	Bit8u b8 [4][SCALER_MAXWIDTH*3];
11+	Bit32u b32 [5][SCALER_MAXWIDTH*6];
12+	Bit16u b16 [5][SCALER_MAXWIDTH*6];
13+	Bit8u b8 [5][SCALER_MAXWIDTH*6];
14 } scalerWriteCache;
15 //scalerFrameCache_t scalerFrameCache;
16 scalerSourceCache_t scalerSourceCache;

hail-to-the-ryzen wrote on 2020-07-26, 02:08:

Here is a change to consider in the case where a game searches for mode 0x068 and it is not found. It may lead to a reset to an […]
Show full quote

Here is a change to consider in the case where a game searches for mode 0x068 and it is not found. It may lead to a reset to an unintended mode in that case.
diff -rupN dosbox-orig//src/ints/int10_modes.cpp dosbox/src/ints/int10_modes.cpp
--- dosbox-orig//src/ints/int10_modes.cpp
+++ dosbox/src/ints/int10_modes.cpp
@@ -56,6 +56,8 @@ VideoModeBlock ModeList_VGA[]={
{ 0x054 ,M_TEXT ,1056,344, 132,43, 8, 8, 1 ,0xB8000 ,0x4000, 160, 449, 132,344, 0 },
{ 0x055 ,M_TEXT ,1056,400, 132,25, 8, 16, 1 ,0xB8000 ,0x2000, 160, 449, 132,400, 0 },

+/* Alias of mode 100 */
+{ 0x068 ,M_LIN8 ,640 ,400 ,80 ,25 ,8 ,16 ,1 ,0xA0000 ,0x10000,100 ,449 ,80 ,400 ,0 },
/* Alias of mode 101 */
{ 0x069 ,M_LIN8 ,640 ,480 ,80 ,30 ,8 ,16 ,1 ,0xA0000 ,0x10000,100 ,525 ,80 ,480 ,0 },
/* Alias of mode 102 */

Done. Is this a game that supports VESA BIOS extensions but relies on these unspecified aliases?

TheGreatCodeholio wrote on 2020-07-26, 02:15:

hail-to-the-ryzen wrote on 2020-07-26, 02:08:

Here is a change to consider in the case where a game searches for mode 0x068 and it is not found. It may lead to a reset to an […]
Show full quote

Here is a change to consider in the case where a game searches for mode 0x068 and it is not found. It may lead to a reset to an unintended mode in that case.
diff -rupN dosbox-orig//src/ints/int10_modes.cpp dosbox/src/ints/int10_modes.cpp
--- dosbox-orig//src/ints/int10_modes.cpp
+++ dosbox/src/ints/int10_modes.cpp
@@ -56,6 +56,8 @@ VideoModeBlock ModeList_VGA[]={
{ 0x054 ,M_TEXT ,1056,344, 132,43, 8, 8, 1 ,0xB8000 ,0x4000, 160, 449, 132,344, 0 },
{ 0x055 ,M_TEXT ,1056,400, 132,25, 8, 16, 1 ,0xB8000 ,0x2000, 160, 449, 132,400, 0 },

+/* Alias of mode 100 */
+{ 0x068 ,M_LIN8 ,640 ,400 ,80 ,25 ,8 ,16 ,1 ,0xA0000 ,0x10000,100 ,449 ,80 ,400 ,0 },
/* Alias of mode 101 */
{ 0x069 ,M_LIN8 ,640 ,480 ,80 ,30 ,8 ,16 ,1 ,0xA0000 ,0x10000,100 ,525 ,80 ,480 ,0 },
/* Alias of mode 102 */

Done. Is this a game that supports VESA BIOS extensions but relies on these unspecified aliases?

Yes. An example is flight simulator 5.1 in vesa mode. Otherwise, it will reset to a mode that may produce some flicker.

hail-to-the-ryzen wrote on 2020-07-26, 02:13:

This may help from writing outside the writecache with normal5x/6x: […]
Show full quote

This may help from writing outside the writecache with normal5x/6x:

Copy code to clipboard

1diff -rupN dosbox-orig/src/gui/render_scalers.cpp dosbox/src/gui/render_scalers.cpp
2--- dosbox-orig/src/gui/render_scalers.cpp	
3+++ dosbox/src/gui/render_scalers.cpp
4@@ -30,9 +30,9 @@ Bit16u Scaler_ChangedLines[SCALER_MAXHEI
5 Bitu Scaler_ChangedLineIndex;
6 
7 static union {
8-	Bit32u b32 [4][SCALER_MAXWIDTH*3];
9-	Bit16u b16 [4][SCALER_MAXWIDTH*3];
10-	Bit8u b8 [4][SCALER_MAXWIDTH*3];
11+	Bit32u b32 [5][SCALER_MAXWIDTH*6];
12+	Bit16u b16 [5][SCALER_MAXWIDTH*6];
13+	Bit8u b8 [5][SCALER_MAXWIDTH*6];
14 } scalerWriteCache;
15 //scalerFrameCache_t scalerFrameCache;
16 scalerSourceCache_t scalerSourceCache;

I have an issue open to add this. DOSBox-X supports a higher maximum resolution than DOSBox SVN (1920x1440) and I'd rather make sure that doesn't eat too much memory.

TheGreatCodeholio wrote on 2020-07-26, 02:19:

hail-to-the-ryzen wrote on 2020-07-26, 02:13:

This may help from writing outside the writecache with normal5x/6x: […]
Show full quote

This may help from writing outside the writecache with normal5x/6x:

Copy code to clipboard

1diff -rupN dosbox-orig/src/gui/render_scalers.cpp dosbox/src/gui/render_scalers.cpp
2--- dosbox-orig/src/gui/render_scalers.cpp	
3+++ dosbox/src/gui/render_scalers.cpp
4@@ -30,9 +30,9 @@ Bit16u Scaler_ChangedLines[SCALER_MAXHEI
5 Bitu Scaler_ChangedLineIndex;
6 
7 static union {
8-	Bit32u b32 [4][SCALER_MAXWIDTH*3];
9-	Bit16u b16 [4][SCALER_MAXWIDTH*3];
10-	Bit8u b8 [4][SCALER_MAXWIDTH*3];
11+	Bit32u b32 [5][SCALER_MAXWIDTH*6];
12+	Bit16u b16 [5][SCALER_MAXWIDTH*6];
13+	Bit8u b8 [5][SCALER_MAXWIDTH*6];
14 } scalerWriteCache;
15 //scalerFrameCache_t scalerFrameCache;
16 scalerSourceCache_t scalerSourceCache;

I have an issue open to add this. DOSBox-X supports a higher maximum resolution than DOSBox SVN (1920x1440) and I'd rather make sure that doesn't eat too much memory.

Yes, I agree. It requires verification that the array is large enough for the higher scaler modes.

awgamer wrote on 2020-07-26, 01:42:

Yes, confronted with this many assuredly have arrived at that conclusion, without bothering to mention issues like I have, I'm cantankerous but I'm nice that way.

Another intent of DOSBox-X is retro development, which is also why many of the built-in and fixed settings in DOSBox SVN are broken out as dosbox.conf options in DOSBox-X. So that you can develop your code and then play with the settings to test how well your code handles lack of, too much of, this feature or quirk, etc.

Many SVN limits have been lifted as well. DOSBox-X can emulate a DOS machine with up to 1GB of memory (32-bit builds) or 3.5GB of memory (64-bit builds) and S3 video emulation with 16MB of video memory instead of 8MB. SVN implements a 63MB memory limit and there was once an amusing argument about that and HIMEM.SYS emulation regarding the two different API calls to allocate memory in KB, one using AX and the other using EAX.

I test DOSBox-X emulation against a lot of things to help develop it, including:
- DOS games
- The demoscene (and all of the weird hacks they do)
- NEC PC-98 games (bootable and standalone executables). DOSBox-X has had working PC-98 emulation since late 2017.
- MS-DOS boot disks and DOS booter games
- Microsoft Windows 1.0 through 3.1, 95, 98, and Millennium Edition
- Random non-game DOS applications
- Random Windows 3.1 applications
- Old C and ASM compilers including Visual Basic 3.0 and Visual C++ 1.5
- Anything Pixelmusement dregs up on "Shovelware Diggers" 😀
- DOS games that others on Github report as having a problem (other than the usual "oh if I run LOADFIX first it works, never mind" issues)

Have you ever tested the xadd instruction?

jmarsh wrote on 2020-07-26, 02:58:

Have you ever tested the xadd instruction?

Not recently. Is there something that relies on it?

I did fix up Pentium CMPXCHG8B emulation though because Windows ME will randomly BSOD without it.

TheGreatCodeholio wrote on 2020-07-26, 03:02:

Not recently. Is there something that relies on it?

Luckily not because it's broken in two different ways, and after fixing those I suspect it will still be broken due to a fundamental flaw in how flags are handled.

jmarsh wrote on 2020-07-26, 03:23:

TheGreatCodeholio wrote on 2020-07-26, 03:02:

Not recently. Is there something that relies on it?

Luckily not because it's broken in two different ways, and after fixing those I suspect it will still be broken due to a fundamental flaw in how flags are handled.

Hm...

https://www.felixcloutier.com/x86/xadd

Well, I could go over it to at least assume the flags behave the same as the ADD instruction and verify that it swaps the values properly.
Then, I have an old 486 laptop I could verify the behavior on.

https://github.com/joncampbell123/dosbox-x/issues/1757

It's currently not updating flags at all, and if the write operation faults (e.g. due to read-only memory) the second operand gets updated anyway. xchg also has this problem.
Then even if you fix that, there is still the problem that flags aren't rolled back if a fault occurs which affects ALL read/modify/write instructions but especially ones that use flags for both input and output (e.g. adc and sbb).

Old thread about XADD and CMPXCHG flags: XADD Flags?

jmarsh wrote on 2020-07-26, 03:49:

It's currently not updating flags at all, and if the write operation faults (e.g. due to read-only memory) the second operand gets updated anyway. xchg also has this problem.
Then even if you fix that, there is still the problem that flags aren't rolled back if a fault occurs which affects ALL read/modify/write instructions but especially ones that use flags for both input and output (e.g. adc and sbb).

DOSBox-X's normal core has been reorganized carefully so that if the instruction is interrupted by a page fault, the CPU state is either not updated or it is reverted to it's original state before the instruction began. If XADD emulation is not reverting properly on page fault, then that needs to be fixed. That and the C++ exception-based page fault handling is what allows DOSBox-X to run Windows 95 so well. However the flags emulation should be fixed.

To explain why that helps Windows 95, it helps to understand that Windows 95 can and will task switch while handling a page fault. DOSBox SVN's code (and the dynamic code in DOSBox-X) is written to recurse into another emulator loop only to exit when the page fault returns, but Windows 95 task switching confuses that code, which is why it eventually crashes in SVN.

I can't see any evidence of rollback except on a few select instructions (pusha, popa, etc.). Any opcodes that read from memory, perform an operation that modifies flags and then attempt to write a result back to memory have the potential to corrupt the flag state if the memory is mapped as read-only. xchg, xadd and a few others have the added complication of modifying a register operand as well as memory which should be done after memory access has been checked.

FWIW I can run win95 using DOSBox SVN just fine using the dynamic_x86 core. The major showstopper in the past was ESP not being updated correctly (from whatever value was currently cached in a host register) when the core called external functions. Since fixing that it runs fine with zero crashes, fast enough to run games like Starcraft and Diablo 2.
Relying on exceptions flat-out doesn't work, because for x86_64 the call frames for dynamic code can't be unwound.

jmarsh wrote on 2020-07-26, 05:26:

I can't see any evidence of rollback except on a few select instructions (pusha, popa, etc.). Any opcodes that read from memory, perform an operation that modifies flags and then attempt to write a result back to memory have the potential to corrupt the flag state if the memory is mapped as read-only. xchg, xadd and a few others have the added complication of modifying a register operand as well as memory which should be done after memory access has been checked.

FWIW I can run win95 using DOSBox SVN just fine using the dynamic_x86 core. The major showstopper in the past was ESP not being updated correctly (from whatever value was currently cached in a host register) when the core called external functions. Since fixing that it runs fine with zero crashes, fast enough to run games like Starcraft and Diablo 2.
Relying on exceptions flat-out doesn't work, because for x86_64 the call frames for dynamic code can't be unwound.

Well, yes, that's why DOSBox-X reverts to the recursive method if using dynamic core, because dynamic core doesn't work with C++ exceptions. It happens to on 32-bit Windows but does not work with any platform on Linux due to how exception handler frames are generated by the compiler.

When was the ESP fix done? DOSBox-X is using dynamic core code from DOSBox SVN as it existed in 2018.

Wow, PC-98 emulation, that's very interesting ! 😁

It seems that there were a lot of updates to the PC-98 line over the years, how is it managed inside DOSBox-X emulation-wise ?

@awgamer: please stay polite. When you disagree with how something is done that's fine but no reason to get so riled up over it to use such language. First and last warning.

Dosbox-x is a fork of DOSBox, it's not DOSBox.