After opening a plain full screen dos box in Windows 95 OSR2 (640x480 @ 16-bit colors), there is a repeated logging of this line:
PAGING:Recursive PageFault for 46c used=0

It continues until the dos box is closed and prints about every 400,000 cpu cycles. However, it does not occur in a windowed dos box. Haven't yet determined if all S3 Trio 32/64 drivers lead to the same logging, but setting video acceleration to none has no effect with the driver tested.

The log is printed by LOG_MSG, so it requires "log console=true".

I think it is related to the video mode (tested with Quake). Video modes 3, 13, and 100 do not lead to the extensive logging of that page fault, for example, but video mode 101 (640x480) leads to repeated logging of these lines:
PAGING:Recursive PageFault for 46c used=0
ERROR INT10:Unhandled VESA Function 7 Subfunction 0

I think that INT10 error is unrelated to the page fault logging because it is specific to Quake.

At video mode 103 (800x600), the lines logged are much fewer, but the fps are low, too. Is it possible that the logging is specific to a dos box @ 640x480/16?

The problem with INT 10h in protected mode is that, if INT 10h does anything involving paging, then the page fault handling has to revert to recursive mode because DOSBox-X's BIOS interrupt handling is non-interruptible.

Also, Quake as I understand it uses a DOS extender (CWSDPMI I think) that uses paging and a swapfile on the hard drive.

I understand - thank you for the help.

If umb=true, then should xms turn on automatically and a message printed to the log?

hail-to-the-ryzen wrote:

If umb=true, then should xms turn on automatically and a message printed to the log?

If XMS is disabled (as if HIMEM.SYS were not loaded), then there is no driver to provide upper memory blocks, and umb=true doesn't mean anything anymore.

Revisited that previous issue about opening a full screen dos box in Windows 95 OSR2. Although my tests were in a modified build, I could reproduce a warning where the pf_queue.used is >0 (independent of the expected occurrence of recursive page faults with pf_queue.used=0). This led to instability in the guest OS desktop. Traced the warning to the function below which clears memory, in this case for vesa mode 3 (monochrome text). The warning is avoided by adding a small delay to the function below or possibly in the upstream function for setting up the vesa mode. Also, this change seems reasonable since there is no configurable delay for this case of real_writew, yet there are configurable delays on the video memory accesses. Requires vmemdelay >0 to work.

1--- int10_modes-orig.cpp
2+++ int10_modes.cpp
3@@ -521,7 +521,11 @@ static void FinishSetMode(bool clearmem)
4 			break;
5 		case M_TEXT: {
6 			Bit16u seg = (CurMode->mode==7)?0xb000:0xb800;
7-			for (Bit16u ct=0;ct<16*1024;ct++) real_writew(seg,ct*2,0x0720);
8+			for (Bit16u ct=0;ct<16*1024;ct++) {
9+				// LOG_MSG("Delay for clearing the memory");
10+				VGAMEM_USEC_write_delay();
11+				real_writew(seg,ct*2,0x0720);
12+			}
13 			break;
14 		}
15 		case M_EGA:	
16--- vga-orig.h
17+++ vga.h
18@@ -515,6 +515,8 @@ void SVGA_Setup_TsengET3K(void);
19 void SVGA_Setup_ParadisePVGA1A(void);
20 void SVGA_Setup_Driver(void);
21 
22+void VGAMEM_USEC_write_delay(void);
23+
24 // Amount of video memory required for a mode, implemented in int10_modes.cpp
25 Bitu VideoModeMemSize(Bitu mode);

On further testing, determined the above (46c) page fault warning occurs when that memory is accessed at same time that the (B800) screen memory segment is clearing during the setup of a vesa mode. This was tested with opening a Win95 OSR2 full screen dos box. One workaround is change the original code for clearing screen memory:

1	case M_TEXT: {
2			Bit16u seg = (CurMode->mode==7)?0xb000:0xb800;
3			for (Bit16u ct=0;ct<16*1024;ct++) real_writew(seg,ct*2,0x0720);
4			break;
5		}

So that real_writew() is not called. Instead, let memset() clear the memory directly:

1	   case M_TEXT:
2		case M_EGA: case M_VGA:	case M_LIN8: case M_LIN4: case M_LIN15: case M_LIN16:
3		case M_LIN32:
4			/* Hack we just access the memory directly */
5			memset(vga.mem.linear,0,vga.vmemsize);
6			memset(vga.fastmem, 0, vga.vmemsize<<1);
7			break;

This is not expected to occur in DOS.

The above workaround is not effective in DOS. Instead, the change below fixed the issue and worked effectively during some testing in DOS and Win95 OSR2:

1--- int10_modes-orig.cpp
2+++ int10_modes.cpp
3@@ -1681,17 +1681,17 @@ dac_text16:
4 		svga.set_video_mode(crtc_base, &modeData);
5 	}
6 
7-	FinishSetMode(clearmem);
8-
9 	/* Set vga attrib register into defined state */
10 	IO_Read(mono_mode ? 0x3ba : 0x3da);
11 	IO_Write(0x3c0,0x20);
12-	IO_Read(mono_mode ? 0x3ba : 0x3da);
13 
14 	/* Load text mode font */
15 	if (CurMode->type==M_TEXT) {
16 		INT10_ReloadFont();
17 	}
18+
19+	FinishSetMode(clearmem);
20+
21 	// Enable screen memory access
22 	IO_Write(0x3c4,1); IO_Write(0x3c5,seq_data[1] & ~0x20);
23 	//LOG_MSG("setmode end");

Hi!!
Even on the very last version, the bios support for int 10h 1c02h is still broken.
Any help please?

If an OS tries to read from an invalid c/h/s on a disk, should a failure be returned to the OS? Right now invalid values are silently ignored, converted to 'absolute' sector offsets, and read from the image file.

In my case, I tried to format a 160KB floppy image with DOS 5. For whatever reason, DOS tried to format the floppy as 360KB, which succeeded. Then I copied 360KB of files to it without an error occurring, and without an attempt to write to a position outside of the 160KB image. Obviously there was data overlap and loss, but it was undetected by the OS.

I suggest that either (a) invalid c/h/s values are reported back to the OS as an error, or (b) they are logged (LOG_MSG).

The only scenario I can think to use option B would be if an image was mounted with the wrong c/h/s values, and the OS used the values from the partition to access the drive. (Or if the opposite were true.) Since in general FAT is based on absolute sector offsets, an incorrect c/h/s by the OS would work fine with option B, but fail with option A.

On the other hand, option A should represent a more accurate simulation of an old PC, and should not pose a problem unless the chs values could not be detected properly when mounting the image.

Haven't gotten around to INT 10h 1C02h yet, but the issue is there in the tracker.

I just finished some scripting to update dosbox-x.com with documentation from the source code using Doxygen, which may a good reference for those that want to work on the source code with me.

http://dosbox-x.com/doxygen/html/index.html

danrevella wrote:

Hi!!
Even on the very last version, the bios support for int 10h 1c02h is still broken.
Any help please?

I just noticed that the INT 10 save function leaves the attribute controller flip-flop in the wrong state, and the restore function leaves the attribute controller with the Palette Address Source (bit 5) clear, which on normal VGA hardware leaves the screen blank.

I just pushed a change to INT 10h AH=1Ch handling that I think should resolve your issue. I don't have any software on hand that uses this BIOS call so I cannot 100% verify this issue is fixed.

I just incorporated the EGA mode param changes from SVN, and the +2 adjust for vtotal. The refresh rates now match DOSBox SVN for EGA modes.

Please excuse, maybe anyone is able to supply an extend debugger version compiled?
I have try to compiled by myself, but after many and many try I had to renonce...... I'm not able...
About a program who use int 10h Ah=1c, i remembre and old post with an utility about:
Cheat App for DOS

The dosbox-x parameter dynamic_core_cache_block_size is set at the default value of 32. This works as expected for core=dynamic. However, where setting it to 64, it may lead to a cache block overrun error. This is related to an insufficient total cache size, therefore the increased cache block size must lead to a higher use of the cache. However, where dynamic_core_cache_block_size=64 and the total cache size is increased, then there is a reproducible error for insufficient number of cache blocks (Chessmaster 3000 for DOS).

Included patch below for testing. It naively increases the caching in the dynamic core where the dynamic_core_cache_block_size is set larger than 32.

1diff -rupN dosbox-orig//src/cpu/core_dyn_x86/cache.h dosbox//src/cpu/core_dyn_x86/cache.h
2--- dosbox-orig//src/cpu/core_dyn_x86/cache.h
3+++ dosbox//src/cpu/core_dyn_x86/cache.h
4@@ -483,17 +483,22 @@ static CacheBlock * cache_blocks=NULL;
5 
6 static bool cache_initialized = false;
7 
8+extern int dynamic_core_cache_block_size;
9+extern int cache_total_adjust;
10+
11 static void cache_init(bool enable) {
12 	Bits i;
13+	int cache_total_adjust = 1 + ((dynamic_core_cache_block_size - 1) / 32);
14+	// LOG_MSG("cache_total_adjust by %i",cache_total_adjust);
15 	if (enable) {
16 		if (cache_initialized) return;
17 		cache_initialized = true;
18 		if (cache_blocks == NULL) {
19-			cache_blocks=(CacheBlock*)malloc(CACHE_BLOCKS*sizeof(CacheBlock));
20+			cache_blocks=(CacheBlock*)malloc((CACHE_BLOCKS*cache_total_adjust)*sizeof(CacheBlock));
21 			if(!cache_blocks) E_Exit("Allocating cache_blocks has failed");
22-			memset(cache_blocks,0,sizeof(CacheBlock)*CACHE_BLOCKS);
23+			memset(cache_blocks,0,sizeof(CacheBlock)*(CACHE_BLOCKS*cache_total_adjust));
24 			cache.block.free=&cache_blocks[0];
25-			for (i=0;i<CACHE_BLOCKS-1;i++) {
26+			for (i=0;i<(CACHE_BLOCKS*cache_total_adjust)-1;i++) {
27 				cache_blocks[i].link[0].to=(CacheBlock *)1;
28 				cache_blocks[i].link[1].to=(CacheBlock *)1;
29 				cache_blocks[i].cache.next=&cache_blocks[i+1];
30@@ -501,12 +506,12 @@ static void cache_init(bool enable) {
31 		}
32 		if (cache_code_start_ptr==NULL) {
33 #if defined (WIN32)
34-			cache_code_start_ptr=(Bit8u*)VirtualAlloc(0,CACHE_TOTAL+CACHE_MAXSIZE+PAGESIZE_TEMP-1+PAGESIZE_TEMP,
35+			cache_code_start_ptr=(Bit8u*)VirtualAlloc(0,(CACHE_TOTAL*cache_total_adjust)+CACHE_MAXSIZE+PAGESIZE_TEMP-1+PAGESIZE_TEMP,
36 				MEM_COMMIT,PAGE_EXECUTE_READWRITE);
37 			if (!cache_code_start_ptr)
38-				cache_code_start_ptr=(Bit8u*)malloc(CACHE_TOTAL+CACHE_MAXSIZE+PAGESIZE_TEMP-1+PAGESIZE_TEMP);
39+				cache_code_start_ptr=(Bit8u*)malloc((CACHE_TOTAL*cache_total_adjust)+CACHE_MAXSIZE+PAGESIZE_TEMP-1+PAGESIZE_TEMP);
40 #else
41-			cache_code_start_ptr=(Bit8u*)malloc(CACHE_TOTAL+CACHE_MAXSIZE+PAGESIZE_TEMP-1+PAGESIZE_TEMP);
42+			cache_code_start_ptr=(Bit8u*)malloc((CACHE_TOTAL*cache_total_adjust)+CACHE_MAXSIZE+PAGESIZE_TEMP-1+PAGESIZE_TEMP);
43 #endif
44 			if(!cache_code_start_ptr) E_Exit("Allocating dynamic core cache memory failed");
45 
46@@ -516,14 +521,14 @@ static void cache_init(bool enable) {
47 			cache_code+=PAGESIZE_TEMP;
48 
49 #if (C_HAVE_MPROTECT)
50-			if(mprotect(cache_code_link_blocks,CACHE_TOTAL+CACHE_MAXSIZE+PAGESIZE_TEMP,PROT_WRITE|PROT_READ|PROT_EXEC))
51+			if(mprotect(cache_code_link_blocks,(CACHE_TOTAL*cache_total_adjust)+CACHE_MAXSIZE+PAGESIZE_TEMP,PROT_WRITE|PROT_READ|PROT_EXEC))
52 				LOG_MSG("Setting excute permission on the code cache has failed!");
53 #endif
54 			CacheBlock * block=cache_getblock();
55 			cache.block.first=block;
56 			cache.block.active=block;
57 			block->cache.start=&cache_code[0];
58-			block->cache.size=CACHE_TOTAL;
59+			block->cache.size=(CACHE_TOTAL*cache_total_adjust);
60 			block->cache.next=0;								//Last block in the list

61 		}
62 		/* Setup the default blocks for block linkage returns */
63@@ -571,6 +576,8 @@ static void cache_close(void) {
64 }
65 
66 static void cache_reset(void) {
67+	int cache_total_adjust = 1 + ((dynamic_core_cache_block_size - 1) / 32);
68+	// LOG_MSG("cache_total_adjust by %i",cache_total_adjust);
69 	if (cache_initialized) {
70 		for (;;) {
71 			if (cache.used_pages) {
72@@ -583,12 +590,12 @@ static void cache_reset(void) {
73 		}
74 
75 		if (cache_blocks == NULL) {
76-			cache_blocks=(CacheBlock*)malloc(CACHE_BLOCKS*sizeof(CacheBlock));
77+			cache_blocks=(CacheBlock*)malloc((CACHE_BLOCKS*cache_total_adjust)*sizeof(CacheBlock));
78 			if(!cache_blocks) E_Exit("Allocating cache_blocks has failed");
79 		}
80-		memset(cache_blocks,0,sizeof(CacheBlock)*CACHE_BLOCKS);
81+		memset(cache_blocks,0,sizeof(CacheBlock)*(CACHE_BLOCKS*cache_total_adjust));
82 		cache.block.free=&cache_blocks[0];
83-		for (Bits i=0;i<CACHE_BLOCKS-1;i++) {
84+		for (Bits i=0;i<(CACHE_BLOCKS*cache_total_adjust)-1;i++) {
85 			cache_blocks[i].link[0].to=(CacheBlock *)1;
86 			cache_blocks[i].link[1].to=(CacheBlock *)1;
87 			cache_blocks[i].cache.next=&cache_blocks[i+1];
88@@ -596,12 +603,12 @@ static void cache_reset(void) {
89 
90 		if (cache_code_start_ptr==NULL) {
91 #if defined (WIN32)
92-			cache_code_start_ptr=(Bit8u*)VirtualAlloc(0,CACHE_TOTAL+CACHE_MAXSIZE+PAGESIZE_TEMP-1+PAGESIZE_TEMP,
93+			cache_code_start_ptr=(Bit8u*)VirtualAlloc(0,(CACHE_TOTAL*cache_total_adjust)+CACHE_MAXSIZE+PAGESIZE_TEMP-1+PAGESIZE_TEMP,
94 				MEM_COMMIT,PAGE_EXECUTE_READWRITE);
95 			if (!cache_code_start_ptr)
96-				cache_code_start_ptr=(Bit8u*)malloc(CACHE_TOTAL+CACHE_MAXSIZE+PAGESIZE_TEMP-1+PAGESIZE_TEMP);
97+				cache_code_start_ptr=(Bit8u*)malloc((CACHE_TOTAL*cache_total_adjust)+CACHE_MAXSIZE+PAGESIZE_TEMP-1+PAGESIZE_TEMP);
98 #else
99-			cache_code_start_ptr=(Bit8u*)malloc(CACHE_TOTAL+CACHE_MAXSIZE+PAGESIZE_TEMP-1+PAGESIZE_TEMP);
100+			cache_code_start_ptr=(Bit8u*)malloc((CACHE_TOTAL*cache_total_adjust)+CACHE_MAXSIZE+PAGESIZE_TEMP-1+PAGESIZE_TEMP);
101 #endif
102 			if (!cache_code_start_ptr) E_Exit("Allocating dynamic core cache memory failed");
103 
104@@ -611,7 +618,7 @@ static void cache_reset(void) {
105 			cache_code+=PAGESIZE_TEMP;
106 
107 #if (C_HAVE_MPROTECT)
108-			if(mprotect(cache_code_link_blocks,CACHE_TOTAL+CACHE_MAXSIZE+PAGESIZE_TEMP,PROT_WRITE|PROT_READ|PROT_EXEC))
109+			if(mprotect(cache_code_link_blocks,(CACHE_TOTAL*cache_total_adjust)+CACHE_MAXSIZE+PAGESIZE_TEMP,PROT_WRITE|PROT_READ|PROT_EXEC))
110 				LOG_MSG("Setting excute permission on the code cache has failed!");
111 #endif
112 		}
113@@ -620,7 +627,7 @@ static void cache_reset(void) {
114 		cache.block.first=block;
115 		cache.block.active=block;
116 		block->cache.start=&cache_code[0];
117-		block->cache.size=CACHE_TOTAL;
118+		block->cache.size=(CACHE_TOTAL*cache_total_adjust);
119 		block->cache.next=0;								//Last block in the list
120 
121 		/* Setup the default blocks for block linkage returns */
122diff -rupN dosbox-orig//src/cpu/core_dyn_x86.cpp dosbox//src/cpu/core_dyn_x86.cpp
123--- dosbox-orig//src/cpu/core_dyn_x86.cpp
124+++ dosbox//src/cpu/core_dyn_x86.cpp
125@@ -258,6 +258,11 @@ static void dyn_restoreregister(DynReg *
126 
127 extern int dynamic_core_cache_block_size;
128 
129+/* Increase CACHE_TOTAL where block_size greater than 32 and by a factor which is rounded to next integer */
130+/* dosbox.cpp defines block size as > 0  otherwise edit equation */
131+extern int cache_total_adjust;
132+int cache_total_adjust = 1;
133+
134 static bool paging_warning = true;
135 
136 Bits CPU_Core_Dyn_X86_Run(void) {

Hello,

I asked this in the Game/Apps section.
Snip===
I Wonder. In the Compatibility Page of Dosbox it say it full supportet.I tried many Dosbox Version, down to version 71 and other Forks.
The Vector Grafic is damaged. The one and only where it works is your Dosbox-X Port.

Anyone has a Code Solution? Can you give me hint where did you fix this?

All Ports

Dosbox-X

I think ... i have it found.

Airbus A320 from Thalion (Grafik Glitch in VectorGFX))

I have a question. I know you've repeatedly said that the dynamic core was removed because you couldn't get it right with page fault handling, but will you ever get that problem sorted out and allow the dynamic core to work STABILY with page faulting (i.e. Windows 98), at least in 32-bit? I know you've recently restored the dynamic core, but as you said, it doesn't work with paging because it's incompatible with the current emulation code. So probably no Win98.
The reason why I am asking this is because I am planning on trying to install Windows 98 SE again and am worried that it will run too slow just as the version I tried last summer did (I set the core to normal and it had major performance issues with even some less demanding games as said before, but I tried an earlier version which had the dynamic core from early 2015 and it worked at full speed).
Will you be able to add this sometime in the future? Personally, it seems much more important to me than fixing PC-98 games and such. So will this ever be "fixed", or will I have to use a really old version? Or is there some OTHER way to run Windows 98 SMOOTHLY in the current version without the dynamic core AND without a huge performance dip?

In sdl_gui.cpp, scrollock is often spelled as scrolllock and SDLK_SCROLLLOCK.