A Vision864 (86C864) driver does seem unlikely to use acceleration features found only on the Trio 64 (86C764), and a Trio 64V+ (86C765) driver would probably not use them as well. However, the S3 emulation in DOSBox claims to be 86C764, and my comment about draw command 3 is in reference to the S3 Trio 64/32 1.70.04 driver suggested by the Windows 3.1x DOSBox Guide

Edit: Now that I think about it, the "flat model" 864 1.41b5 driver was suggested for Win3 in DOSBox in the past, but there were some problems resolved by using the Trio 64/32 1.70.04 driver and so it became the suggested driver.

What is the best S3Trio64 driver to benefit from better/higher resolution and colors on Win98 (and now that I asked, for 3.x too) with Dosbox-X ? I've already made the .cfg tweaks to enable this, and tried a few drivers recently, and whenever I try to go above 1280x and more than 24M colors... the colors are a bit garbled and "full blue-ish". I've also tried the same mentioned on DosBox-X github wiki.

jmarsh wrote on 2021-04-07, 09:06:

All the stuff DOSBox-X added to the dynamic_x86 core to "handle page faults" is mostly nothing but a huge slowdown. Nearly all memory accesses performed by that core (dyn_read_byte/write_byte/read_word/write_word) already handle faults correctly and the remaining opcodes that can cause problems (pusha, popa, etc) are still unfixed. My suggestion would be to rip the whole lot out, if there's anything that it does actually fix it can be implemented in a more optimal way.

Would that then have a negative impact on Win9x support? I notice that SVN appears fine with Win95 and 98 .. fast and stable in almost all instances, as long as I use the "pentium_slow" CPU.

The non-recursive page fault handling was added to the dynamic_x86 core in DOSBox-X 0.83.10 by a contributor, and according to his description this makes the dynamic x86 core more friendly with Windows 9x. But there are apparently known issues with this non-recursive page fault handling, and if he sees this I hope he can make further cleanups to the code if possible. I think he did try to make the non-recursive page fault handling optional with a setting, but I will see if there is anything not yet covered, e.g. by disabling such code completely and compare the performance.

You should just rip it out, it doesn't fix anything (which should have been verified before it was committed).

Wengier wrote on 2021-04-10, 07:12:

The non-recursive page fault handling was added to the dynamic_x86 core in DOSBox-X 0.83.10 by a contributor, and according to his description this makes the dynamic x86 core more friendly with Windows 9x. But there are apparently known issues with this non-recursive page fault handling, and if he sees this I hope he can make further cleanups to the code if possible. I think he did try to make the non-recursive page fault handling optional with a setting, but I will see if there is anything not yet covered, e.g. by disabling such code completely and compare the performance.

If these changes were the primary cause of the slow downs I am experiencing vs. SVN, then I would have been seeing more even performance (against SVN) in earlier versions of DOSBox-X. However, I recall that when I performed benchmarks last year, I was already getting a speed reduction of about 25-30%, which must have been long before these page fault changes were introduced. I will have to do some more testing with the toggle on/off to see if that impacts anything in the latest version.

There is indeed still some issue with the S3 emulation and high colours where you get the blue tint.

As to higher resolutions, unfortunately the S3 Trio64 is the best card emulated by DOSBox. And the Trio64 drivers only support up to 4MB of video ram. DOSBox-X supports 8MB video ram, but the only way to use it is with the VESA drivers, which is documented on the DOSBox-X wiki.

The patch for S3 Trio64V+ support won't help with this issue, as it was also limited to 4MB. Basically you would need emulation of something like a Nvidia RIVA TNT , ATI 3D Rage Pro or Matrox G200 which have 8-16MB video ram.

Reverting the dynamic_x86 core to current SVN will likely break functionality in the dosbox-x dynrec core. There was also some merging of code between the dynrec and dynamic core (SVN) which may obfuscate future changes to the dynrec core. In any case, any changes or reversions should also be tested against the ne2000 emulation (Win 9x) since that was a problem area for these cpu cores.

For the cases I tested, the speed reduction with the non-recursive page fault handling (dyn_x86) was not >10%. Dosbox-x is intended as a project with experimental features, so it is fairly common that commits are made that break the emulation (see the s3 mmio emulation, for example). Many of the commits are fixes to other fixes, but that is expected with a priority on adding code instead of fully testing a build that is described as stable.

The point I am making is not that it is unstable, but that it tries to fix something that isn't broken; the dynamic_x86 core uses the *_checked memory access functions which don't trigger inline page faults. If it didn't use them it would have issues when self-modifying code touched the currently running block. Currently that can still happen via DMA since it bypasses the emulated TLB/memory maps.

I'd be fine with the highest resolution possible on standard/vanilla S3 Trio64 emulation on DOSBox-X, though.

Regarding the dynamic x86 non-recursive page fault handling - I cannot really say from my own experiences, because when the dynamic x86 core was ported from SVN it worked for me, but both TheGreatCodeholio, Rob and another user stated that even though the core worked fine for them in DOS, they encountered BSODs often when running Windows 9x, which meant it was not yet stable for them for the purpose of Windows 9x. But when the non-recursive page fault handling was introduced all of them reported that it had become much more stable for them to run Windows 9x as a whole (albeit with other known issues). So the non-recursive page fault handling did appear to be important for them, and it was merged to the repository at that time so that they could finally run Windows 9x with the dynamic core reliably, and also as a result it cannot really be reverted from the main code at this time. For me the non-recursive page fault handling is optional because I did not really encounter the issue myself, and I can try to disable it from my own system for performance comparisons etc, but not from the repository yet for reasons mentioned above, unless the said issue is resolved in some better way.

hail-to-the-ryzen: Indeed DOSBox-X includes several experimental features, but it is also needed to be added that the development pattern of DOSBox-X is largely incremental, which means that it is generally expected or hoped that a commit does add values to the existing code. So for the non-recursive page fault handling for example it resolves the major stability issue for people like TheGreatCodeholio and Rob, even though the commit itself cannot be described as 100% stable, apparently. In general DOSBox-X’s experimental features will not be the default option unless they are indeed considered important. Any experimental features are expected to be improved in later PRs or commits of course. This is why many commits are being made to fix existing issues or other fixes, instead of having to perfect it in a single PR or commit. But efforts are being made to stabilize the code before an official release.

A review of the commit history of the dynamic_x86 core is here:
https://github.com/joncampbell123/dosbox-x/co … pu/core_dyn_x86

The commit history shows that some of the SVN patches for the dynamic_x86 core occurred after the non-recursive page fault handling was added. That means it is untested whether the latest dynamic_x86 core is unstable in Windows 9x. Windows 9x was tested and the non-recursive page fault handling was added before all SVN commits were added to this dosbox-x cpu core.

Bruninho wrote on 2021-04-11, 00:24:

I'd be fine with the highest resolution possible on standard/vanilla S3 Trio64 emulation on DOSBox-X, though.

As I said, you can have higher res with DOSBox-X using the VESA drivers as documented here:
https://github.com/joncampbell123/dosbox-x/wi … -98#vesa-driver

With this, you can have resolutions such as 1920x1080 in 32bit colour, or 1920x1440 in 16bit colour.

hail-to-the-ryzen: For the SVN patch for the dynamic_x86 core, I think you were primarily talking about the Pentium MMX patch updated by @kekko last month. According to his description the updated MMX patch is "way more stable than the dosbox-x implementation, plus it should be easier to port to other architectures", and he reported that the Windows 9x game Serious Sam performed faster with the updated MMX patch, as can be found in his comment below:

Re: Pentium MMX emulation patch

Then this updated MMX patch was incorporated into DOSBox-X and it was tested against the MMXTEST tool by myself and the code appeared to work as expected. At that time there was still over half a month before the next DOSBox-X release, and nothing wrong was found or reported during this period. It was only after the DOSBox-X 0.83.12 release some users began to report issue(s) with the updated MMX emulation in DOSBox-X, which showed that the updated MMX emulation may in fact be less stable for some Windows 9x games at least. As a result the MMX patch was reverted. This kind of reversions did happen occasionally, but at the time of incorporation it was believed that the updated MMX emulation would greatly add value to the existing code.

I have to try out the latest release. Gonna see if I can do it this weekend.

hi

since there were no changes in the last releases to the gus code for midi
(the midi playback problems with ppl1.61 patches still exists)
therefore I have an idea 😀

there are several gustypes like classic, classic37, max, etc
how about a new gustype
"dosboxsvn"
this new gustype uses dosboxsvn gus code
i guess this is the easiest fix for the midi problem
(anti loop fix is still required but with it and svn code it should play midis with ppl1.61 patches like dosbox svn without problems)

Shifting negative values results in undefined behavior:
https://github.com/dosbox-staging/dosbox-staging/pull/1005

1 	if (sizeof(Type) == 1) {
2 		const Bit8u xr = signeddata ? 0x00 : 0x80;
3 
4 		len--;
5 -		current[0] = ((Bit8s)((*data++) ^ xr)) << 8;
6 -		if (stereo)
7 -			current[1] = ((Bit8s)((*data++) ^ xr)) << 8;
8 -		else
9 -			current[1] = current[0];
10 +		current[0] = ((Bit8s)((*data++) ^ xr)) * 256;
11 +		if (stereo)
12 +			current[1] = ((Bit8s)((*data++) ^ xr)) * 256;
13 +		else
14 +			current[1] = current[0];
15 	}

It's only undefined if overflow can occur, in these cases it cannot.

If this code was going to be changed from using shifts (i.e. slowed down) it would make more sense to map the values correctly; positive values should map to the full range of 0->32767 instead of 0->32512 to prevent negative biasing.

Thank you for the insight.

hi

i have a small problem - and _ don't work
when i press the key i get ß and ? (same as with the ß key)

this is my layout (standard german layout)
https://images-na.ssl-images-amazon.com/image … _AC_SL1200_.jpg

all keys work except the - _ key

for - i can use numpad
but _ is impossible to get