Voodoo running so slow for me in Windows 95.

gfernval: Yes, it becomes clear that the tinyfd library is not quite compatible with Windows XP. The "create blank disk image" issue on Windows XP is caused by this since you need to select an image file.

Meanwhile, the variable curscr can be modified.

Sandi1987 wrote on 2021-01-06, 22:16:

Voodoo running so slow for me in Windows 95.

Hardware Voodoo emulation is indeed slow. Glide pass-through mode is much faster, but does not work in combination with Win9x.

In future releases of DOSBox, could you put SDL2 binaries (SDL1 binaries don´t work in Windows XP) compiled with mingw with debugger enabled?
I have to compile myself (using msys32 in Windows XP) because there is no SDL2 version with debugger enabled that works in Windows XP.

gfernval wrote on 2021-01-07, 16:33:

In future releases of DOSBox, could you put SDL2 binaries (SDL1 binaries don´t work in Windows XP) compiled with mingw with debugger enabled?
I have to compile myself (using msys32 in Windows XP) because there is no SDL2 version with debugger enabled that works in Windows XP.

I would, but I am not yet able to enable the debugger in MinGW builds. It won't compile if I do.

I am using the latest build (0.83.9 - SDL1) on macOS, with Windows 95b installed. Everything is working great, apart from games that present windowed menu options before starting (i.e. Curse of Monkey Island, Jack Orlando). When clicking the button to start the game, DOSBox-X switches from full screen mode to windowed mode. I then have to press F12-F to get back into full screen mode. Just a minor issue, but somewhat annoying because I cannot figure out why it is triggered in these cases. No other games exhibit that behavior, just the ones that present windowed menu options upon launch.

These are my standard settings:

fullscreen = true
fulldouble = true
fullresolution = 5120x2880
windowresolution = original
windowposition =
output = openglnb

Has anyone else experienced this issue or know of a work-around?

_Rob wrote on 2021-01-07, 08:19:

Sandi1987 wrote on 2021-01-06, 22:16:

Voodoo running so slow for me in Windows 95.

Hardware Voodoo emulation is indeed slow. Glide pass-through mode is much faster, but does not work in combination with Win9x.

Let me straight out the mis-information.

Hardware Voodoo emulation as in DOSBox kekko's Voodoo chip emulation is *NOT* slow. For occasions when its performance pitfall is not in the way, it can be faster than PCem "freaking fast" whatever Voodoo emulation and much less dependent on raw CPU prowess. It is partially accelerated by SDL OpenGL. I read the code and I verified that. You don't have to believe my words, just run 3Dfx Valley of Ra demo (Ctrl-P to show FPS), GLquake timedemo and Turok T1Mark to see it by yourself. Quake2 however does have the performance pitfall in the way. It is very obvious in the eyeballs that it slowed significantly during explosions but outside of that few seconds of explosions it wasn't as bad at all.

Gulikoza's Glide pass-through for DOSBox does indeed work in combination with Win9x. There are Win9x games that won't work with Gulikoza's Glide pass-through, but there are also Win9x games that work. Official DOSBox does not support Win9x. Normal core won't cut it for Win9x games, especially games that support 3D acceleration. They need something better such as dynamic_x86 or dynamic_x64.

Hello:

How to disable the error "v86 to 16-bit gate" that pops up when running some programs? Such programs pop up this error
and exit dosbox-x

thanks

gfernval: What programs may cause the error "v86 to 16-bit gate"? I think we can only test if you provide the names of the programs.

P.S. The compatibility issue of "create blank disk image" with Windows XP was already fixed in the latest code. It should be ready for the next release.

kjliew: I think Rob was referring to the speed of the hardware Voodoo emulation in DOSBox-X 0.83.9. Since you appear to be familiar with the code, do you know what may be the cause of the performance issue of the hardware Voodoo emulation? I certainly appreciate any suggestions.

Also, do you know what Win9x games will work with Gulikoza's Glide passthrough? Could you give some examples? Thanks.

Wengier wrote on 2021-01-26, 07:00:

kjliew: I think Rob was referring to the speed of the hardware Voodoo emulation in DOSBox-X 0.83.9. Since you appear to be familiar with the code, do you know what may be the cause of the performance issue of the hardware Voodoo emulation? I certainly appreciate any suggestions.

I didn't look at DOSBox-X code, but I think it is the same Voodoo chip emulation implementation from kekko's patch. Correct me if I am wrong. I am not familiar with the code, I simply extracted it to produce a clean patch for DOSBox SVN.

Wengier wrote on 2021-01-26, 07:00:

Also, do you know what Win9x games will work with Gulikoza's Glide passthrough? Could you give some examples? Thanks.

Gulikoza's page has the list of Windows games that work. I could add to the list the demos/games I tested on DOSBox SVN:

• 3Dfx demos (Valley of Ra, Race, Wizards Tower)
• Titanium Mechwarrior 2/GBL/Mercenaries (3Dfx Glide)
• Heavy Gear (3Dfx Glide)

DOSBox-X's 3Dfx emulation is the code as it existed in DOSBox SVN, with updates pulled from the ykhwong Daum branch sometime 2015, and then some updates to try to cooperate with OpenGL output and the SDL1 menu drawing code.

Hello:

Remember to rename curscr variable in source file sdlmain.cpp with another name (for example curscreen), because it is in conflict with
curscr used in several modules of libpdcurses package included in DOSBox source code.

thanks

gfernval: It was actually already done in the current code. You can check it out too.

kjliew: I am actually not entirely sure if the current Glide passthrough code in DOSBox-X will work with Windows 9x, since I ported the Glide code from DOSBox ECE to DOSBox-X (with some modifications) back then rather than writing it myself. But making Windows 9x games work with Glide apparently requires the glide2x.dll file made specifically for Windows 9x, which is available in the win9x directory of the following zip package:

download/file.php?id=4416

When I tried to run a 3dfx demo in Win98 I got the message "Not enough memory". But it may simply because of some setting issue since I was not yet able to find a decent documentation for setting this up.

Gulikoza's Glide pass-through has always been working for me on DOSBox SVN with Win98SE, I am pretty sure about it. Yes, it requires special stub Glide2x OVL and DLL made for pass-through, and their source codes are available. DOSBox ECE adapted my 2-in-1 patch for both Glide pass-through and Voodoo chip emulation.

kjliew: Thanks for the information. I looked at the DOSBox-X code and found that the error message was caused by a previous change related to the memory code. I have already fixed this in the code, so that 3dfx demos should now work with guest DOS/Win9x systems in DOSBox-X. It should be included in DOSBox-X version 0.83.10 which is scheduled to be released tonight.

Rob: You can try this with the latest code too (and update Wiki if necessary) . Just make sure "keep private area on boot" (if exists) is not set to "false" (its default value has been changed to "auto"). Thanks!

Wengier, I will try if I can find a moment. But it could be a few days.

Wengier, what about the Glide passthrough requires the private area?

The reason DOSBox-X turns it off on guest boot by default, is because that private area is often used by the DOS kernel for it's internal structures and these structures have no meaning once a guest OS is started. The option is there in case anyone wants it to stay in place for whatever reason (DOSBox SVN behavior).

If the glide passthrough needs to be somewhere up there in adapter ROM, could you just place it up there like it's adapter ROM? Complete with the ROM signature and checksum so that it is valid should any BIOS or DOS program scan for adapter ROM?

TheGreatCodeholio: I don't think the Glide passthrough feature actually requires certain ROM area, but according to the current Glide implementation it needs to allocate memory (by calling DOS_GetMemory(5)). If DOSBox-X turns it off then the DOS memory gets unmapped, and the function will simply fail (causing either E_EXIT "memory unmapped" or the Win9x glide2x.dll error "Not enough memory" according to the previous code that blocked all such attempts in guest systems). So the default value of "keep private area on boot" was changed to "auto" which means that DOSBox-X will turn it off on guest boot in all cases except that the user turns on the Glide passthrough feature (Glide passthrough is off by default). When a user turns on the Glide passthrough and boots into a guest system, they naturally expect that the Glide passthrough feature to work on guest systems also, but setting "keep private area on boot" to "false" will make this simply impossible. On the other hand, with "keep private area on boot=auto" an exception will be made in such case to make Glide passthrough to continue to work on guest systems.