You mean Windows 3.11 ?

Yes.

Windows 3.11 and WfWG 3.11 are working for me with current source, so perhaps the problem you're having is in some way related to your configuration. Are you using the recommended S3 1.70.04 driver with the machine=svga_s3 setting in DOSBox SVN? Which resolutions and bit depths have you tried?

Thank you for confirming that it works for you. I didn't test the commit in 3.11, so I'll repeat that test when time permits.

You replied "Yes." when Qbix asked if you meant Windows 3.11, now you say you didn't test in 3.11, so what *exactly* are you reporting a problem with?

I am sorry for any miscommunication. I did mean Windows 3.11 in the first post. It should read ">3.11" instead of ">3.1".

So it's one way of saying "dosbox broke Windows 95" then? You do realize that Windows 95 is unsupported right

I was reporting an incompatibility for further testing since I am unable to test Win311 under protected mode. The other concern was which video modes are required for Sargon 3, the reason for the patch.

Prior to the change, Sargon 3 was confused into thinking monochrome text is active because it found RAM in the B0000-B7FFF range, even though the active video window is B8000-BFFFF for color text. However, Sargon 3 is not the sole reason for the change; it simply makes no sense to have conventional RAM in inactive video memory regions. If the previous behavior helps Win9x in some way then it is likely just working around whatever the real issue is.

Were you trying to use a previous installation of Win9x, or did you install with current source? I suggest installing with a standard VGA (640x480x16) driver, and if that works then try others.

Thank you for pointing to the cause and the advice. It is a page fault (segment limit violation) from opening the dos box in Win95 while the S3 Trio driver is active. This kind of page fault is unhandled by the dynamic core, although it is possible to handle it in the normal core. However, as you suspected, the VGA driver works properly. This confirms that this is very likely a Win95 specific issue (and the driver must require additional access to video memory when opening a dos box window, whether intended or not).

The S3 driver chosen automatically by the Win95 setup seems to have no problem in 16 or 256 colors when opening a dos box in current source, so the problem you have may be with drivers for a specific model/version.

I was running into disk errors during the setup of Win95 until I reverted the r3714 change in bios_disk.cpp, so I'll have to investigate what goes wrong there.

That's entirely correct, it is only specific to the S3 driver I tested. I should have noted that. I've used that driver for additional compatibility with directx apps, but it is now confirmed that it isn't the best match for the emulation (as shown by use of the dos box window). I also hope that the bios_disk changes require little effort.

I can reproduce the issue with other S3 drivers in Win95 OSR2 (desktop at 256 colors). However, it is only in the dos box window since dos box fullscreen works. I also tried 16 colors and that works for both cases. It may be from another patch or the installed Windows version.

Edit: isolated issue further to this code bit:

1-      MEM_ResetPageHandler( VGA_PAGE_A0, 16 );
2+      MEM_SetPageHandler( VGA_PAGE_A0, 16, &vgaph.empty );

This must be the memory region where the driver is reading/writing when opening a dos box window under OSR2. Turning off video acceleration also prevents the issue.

Edit 2: it also works by this:

1-      MEM_ResetPageHandler( VGA_PAGE_A0, 16 );
2+      MEM_SetPageHandler( VGA_PAGE_A0, 16, &rom_page_handler );

It seems odd that Win95 would select the B8000-BFFFF memory window while the GUI is up. The A0000-AFFFF region can be separately assigned to the MMIO handler for S3, but dunno if that's at all relevant. Maybe try changing the flags on the empty handler, like the flags on the IllegalPageHandler for instance.

Thank you for the very helpful advice. I'll try it out.

Edit: I was near to testing when I noted this code bit:

1	if(svgaCard == SVGA_S3Trio && (vga.s3.ext_mem_ctrl & 0x10))
2		MEM_SetPageHandler(VGA_PAGE_A0, 16, &vgaph.mmio);

As you suggested, if in fact the MMIO is active at VGA_PAGE_A0, then it is possible that clearing this same memory region could cause the page fault error. This may be supported by the finding that active video acceleration is necessary to cause the error, given that acceleration activates MMIO while unaccelerated video does not.

Verified that mmio memory region is reserved on Win95 OSR2 start and also when opening the dos box window. This code seems to workaround the issue of clearing the mmio region for this example:

1diff -rupN dosbox-orig//src/hardware/vga_memory.cpp dosbox//src/hardware/vga_memory.cpp
2--- dosbox-orig//src/hardware/vga_memory.cpp	2016-04-05 23:19:32 -0400
3+++ dosbox//src/hardware/vga_memory.cpp	2016-04-10 17:13:29 -0400
4@@ -152,6 +152,7 @@ INLINE static Bit32u ModeOperation(Bit8u
5 
6 static struct {
7 	Bitu base, mask;
8+	bool mmio_active;
9 } vgapages;
10 	
11 class VGA_UnchainedRead_Handler : public PageHandler {
12@@ -993,19 +994,28 @@ void VGA_SetupHandlers(void) {
13 		vgapages.base = VGA_PAGE_B0;
14 		vgapages.mask = 0x7fff;
15 		MEM_SetPageHandler( VGA_PAGE_B0, 8, newHandler );
16-		MEM_SetPageHandler( VGA_PAGE_A0, 16, &vgaph.empty );
17+		if(vgapages.mmio_active)
18+			MEM_ResetPageHandler( VGA_PAGE_A0, 16 );
19+		else
20+			MEM_SetPageHandler( VGA_PAGE_A0, 16, &vgaph.empty );
21 		MEM_SetPageHandler( VGA_PAGE_B8, 8, &vgaph.empty );
22 		break;
23 	case 3:
24 		vgapages.base = VGA_PAGE_B8;
25 		vgapages.mask = 0x7fff;
26 		MEM_SetPageHandler( VGA_PAGE_B8, 8, newHandler );
27-		MEM_SetPageHandler( VGA_PAGE_A0, 16, &vgaph.empty );
28+		if(vgapages.mmio_active)
29+			MEM_ResetPageHandler( VGA_PAGE_A0, 16 );
30+		else
31+			MEM_SetPageHandler( VGA_PAGE_A0, 16, &vgaph.empty );
32 		MEM_SetPageHandler( VGA_PAGE_B0, 8, &vgaph.empty );
33 		break;
34 	}
35-	if(svgaCard == SVGA_S3Trio && (vga.s3.ext_mem_ctrl & 0x10))
36+	if(svgaCard == SVGA_S3Trio && (vga.s3.ext_mem_ctrl & 0x10)) {
37+		LOG_MSG("mmio: on");
38+		vgapages.mmio_active=true;
39 		MEM_SetPageHandler(VGA_PAGE_A0, 16, &vgaph.mmio);
40+	}
41 range_done:
42 	PAGING_ClearTLB();
43 }

I haven't identified any code that allows for unmapping the mmio region (nor the video register values which presumably control this).

The MMIO mapping overrides any other mapping, including empty, if the (vga.s3.ext_mem_ctrl & 0x10) condition is true. However, your bool flag is true if the condition was ever true, regardless of if it is currently true. So, another thing to look at is why bit 4 on that register gets cleared.

Thank you for the hint on bit 4 which presumably controls the mmio feature.

Edit: Tested further. It seems like the Win95 OSR2 dos box is not compatible with unmapping the MMIO in current emulation.

Edit 2: noted that with video acceleration off, then the mmio is turned off when the dos box is opened, and then turned back on when it is closed. This seems like an expected behavior of the mmio at VGA_PAGE_A0. However, when video acceleration is turned on, then this mmio is mapped when the dos box is opened. Why does the dos box require a mmio when video acceleration is on?

This will bypass the issue for Win95 OSR2 dos box:

1@@ -1000,7 +1000,8 @@ void VGA_SetupHandlers(void) {
2 		vgapages.base = VGA_PAGE_B8;
3 		vgapages.mask = 0x7fff;
4 		MEM_SetPageHandler( VGA_PAGE_B8, 8, newHandler );
5-		MEM_SetPageHandler( VGA_PAGE_A0, 16, &vgaph.empty );
6+		MEM_ResetPageHandler( VGA_PAGE_A0, 16 );
7+		MEM_SetPageHandler( VGA_PAGE_A0, 8, &vgaph.empty );
8 		MEM_SetPageHandler( VGA_PAGE_B0, 8, &vgaph.empty );
9 		break;
10 	}