Is this patch compatible with the dosbox-x menu code? It seems to correct the issue where the window position is set at coordinate 0,0 after exiting fullscreen mode. The expected behavior is where the window position is not reset but instead retains its previous location.

1diff -rupN SDL-1.2-Orig//src/video/windib/SDL_dibvideo.c SDL-1.2/src/video/windib/SDL_dibvideo.c
2--- SDL-1.2-Orig//src/video/windib/SDL_dibvideo.c
3+++ SDL-1.2/src/video/windib/SDL_dibvideo.c
4@@ -948,8 +948,8 @@ SDL_Surface *DIB_SetVideoMode(_THIS, SDL
5 
6 	if ((video->flags & SDL_FULLSCREEN) == SDL_FULLSCREEN) {
7 		/* HACK */
8-		SDL_windowX = 0;
9-		SDL_windowY = 0;
10+		// SDL_windowX = 0;
11+		// SDL_windowY = 0;
12 
13 		/* pay attention! */
14 		SetFocus(SDL_Window);

hail-to-the-ryzen wrote:

Is this patch compatible with the dosbox-x menu code? It seems to correct the issue where the window position is set at coordina […]
Show full quote

Is this patch compatible with the dosbox-x menu code? It seems to correct the issue where the window position is set at coordinate 0,0 after exiting fullscreen mode. The expected behavior is where the window position is not reset but instead retains its previous location.

Copy code to clipboard

1diff -rupN SDL-1.2-Orig//src/video/windib/SDL_dibvideo.c SDL-1.2/src/video/windib/SDL_dibvideo.c
2--- SDL-1.2-Orig//src/video/windib/SDL_dibvideo.c
3+++ SDL-1.2/src/video/windib/SDL_dibvideo.c
4@@ -948,8 +948,8 @@ SDL_Surface *DIB_SetVideoMode(_THIS, SDL
5 
6 	if ((video->flags & SDL_FULLSCREEN) == SDL_FULLSCREEN) {
7 		/* HACK */
8-		SDL_windowX = 0;
9-		SDL_windowY = 0;
10+		// SDL_windowX = 0;
11+		// SDL_windowY = 0;
12 
13 		/* pay attention! */
14 		SetFocus(SDL_Window);

Looks good to me.

😀

I also replicated the ROM "writes" to the EMS memory frame where loading the Windows 95 version of EMS386. As you indicated, it was a different (and higher) region of memory. I assume that the OS on boot is verifying that memory area as not writable.

Interesting findings on the S3 Trio and its drivers. Would it be useful to emulate a true ISA based S3 card for testing against the Windows 3.x drivers? Also, after this LFB work, is it necessary to continue to offer the vesa_nolfb machine type?

hail-to-the-ryzen wrote:

Interesting findings on the S3 Trio and its drivers. Would it be useful to emulate a true ISA based S3 card for testing against the Windows 3.x drivers? Also, after this LFB work, is it necessary to continue to offer the vesa_nolfb machine type?

The vesa_nolfb option if I understand is meant to tell DOSBox to emulate S3 but to emulate a VESA BIOS that does not emulate a linear framebuffer, so that DOS games that are incompatible with it can run, right?

It's also useful for testing your own retro-development to see how well your code can handle a VESA BIOS without linear framebuffer support.

ISA S3 emulation will have to emulate a card that pre-dates the PCI, EISA, and VESA slots. From what I understand, that means emulating an S3 chipset that's older than the Trio64 cards.

If the LFB is now configurable in DOSBox-X, then it should be possible to turn it off from an application instead of specifying a machine type, but certainly the option is useful in the configuration file.

From a cursory search, I couldn't find which versions of the S3 cards correspond to the different slots. It seems that nearly all sites classify an EISA card as an ISA.

http://vgamuseum.info seems to be the best resource out there, so far. Including datasheets.

I searched some of the entries and it seems that the S3 Trio is >ISA, but the early versions of the Diamond Stealth are ISA based cards. It seems that 1991/2 are ISA, but I didn't find a 1993 example, and then the later cards are advanced slots.

Hi all, I'm new here but I play PC games since the CGA era.

I've been using DOSBox SVN-Daum for quite some time but I would like to try DOSBox-X. I downloaded it from here -> https://github.com/joncampbell123/dosbox-x/releases, but it does not work in Windows XP. Is there a fix for this? or can someone point me to a version that works in Windows XP? I hope this will be fixed in the next version.

Thank you.

vogoner wrote:

Hi all, I'm new here but I play PC games since the CGA era.

I've been using DOSBox SVN-Daum for quite some time but I would like to try DOSBox-X. I downloaded it from here -> https://github.com/joncampbell123/dosbox-x/releases, but it does not work in Windows XP. Is there a fix for this? or can someone point me to a version that works in Windows XP? I hope this will be fixed in the next version.

Thank you.

The main release cannot support Windows XP because Visual Studio 2017 doesn't support it properly.

The MinGW builds however should work on Windows XP.

hail-to-the-ryzen wrote:

A greater concern is that the output=opengl mode now has a long time delay where switching from window to full screen mode. I noted it today, but it occurs in my current build and one I built in March. I think it may be from the yesterday's Windows 10 update. I haven't tested for the issue in other builds yet.

Solution is to disable this activated feature of Windows 10: https://www.google.com/search?q=focus+assist+disable

DOSBox-X 0.82.9 is released. Mouse pointer integration, MCGA and MDA emulation, EGA bug fixes, Video capture and run command, hacks, fixes, and more. See changelog for details. https://github.com/joncampbell123/dosbox-x/re … windows-v0.82.9

Hi

Thanks for the release

I run the system from image and I think I found a bug associated with config.sys>menucolor. It occurs also in the older versions.
Shouldn't the background and font color be saved?
No matter what is loaded, device or executable, the color data is always flushed out and strings print with defaults.
https://i.imgur.com/CrHaSCs.png

Timbi wrote:

Hi […]
Show full quote

Hi

Thanks for the release

I run the system from image and I think I found a bug associated with config.sys>menucolor. It occurs also in the older versions.
Shouldn't the background and font color be saved?
No matter what is loaded, device or executable, the color data is always flushed out and strings print with defaults.
https://i.imgur.com/CrHaSCs.png

Since this is low level, that would be a fault with INT 10h emulation, correct?

So this is a case where INT 10h is writing a color attribute when it shouldn't, then?

TheGreatCodeholio wrote:

The main release cannot support Windows XP because Visual Studio 2017 doesn't support it properly.

The MinGW builds however should work on Windows XP.

And where can I download those builds?

vogoner wrote:

TheGreatCodeholio wrote:

The main release cannot support Windows XP because Visual Studio 2017 doesn't support it properly.

The MinGW builds however should work on Windows XP.

And where can I download those builds?

Github, of course!

https://github.com/joncampbell123/dosbox-x/releases

^Thank you very much for your help, and sorry I completely missed that link.

This FDC configuration option doesn't seem available: auto-attach to int 13h.

hail-to-the-ryzen wrote:

This FDC configuration option doesn't seem available: auto-attach to int 13h.

Currently it auto-attaches to A: and B: as a means to attach a floppy disk image at all, especially if booting into a guest OS.

Could that option be removed from the configuration list? Also, is it ever necessary to set "allow dma address decrement" to false?