Hello,
Do you have any plan to add the pixel perfect scaling patch in dosbox-x ?

Choum wrote:

Hello,
Do you have any plan to add the pixel perfect scaling patch in dosbox-x ?

+1, would be great to have. I work on a high resolution retina display, and mostly I have to run windowed and 2x scale. I would like to run fullscreen and with pixel perfect.

Choum wrote:

Hello,
Do you have any plan to add the pixel perfect scaling patch in dosbox-x ?

I thought I already added that, with the "High DPI" option in SDL1 builds on Mac OS X.

Although on my Macbook, you'll also have to adjust the GUI scale so the logical pixels are exactly 2x the actual pixels.

Apparently on a 13" Macbook the scale is not exactly 200%

I have a quick question ....

Does this version of DosBox offer printer support? I have an old set of games (simulation sports games) and - of course - the information those games generate would be great to print out!

Lemur21 wrote:

I have a quick question ....

Does this version of DosBox offer printer support? I have an old set of games (simulation sports games) and - of course - the information those games generate would be great to print out!

DOSBox-X did incorporate printer emulation from Daum, yes.

src/hardware/parport/printer.cpp

Is there a problem with keyboard layout ?
My Windows use French (azerty layout)
dosbox-x seems to correctly detect/set it

But the keyboard do not act like an azerty one exept if I set my Windows keyboard to US keyboard, then the keyboard in dosbox-x act like a french one.

I try on the X86 Windows version (SDL1)

Choum wrote:

Is there a problem with keyboard layout ? My Windows use French (azerty layout) dosbox-x seems to correctly detect/set it […]
Show full quote

Is there a problem with keyboard layout ?
My Windows use French (azerty layout)
dosbox-x seems to correctly detect/set it

But the keyboard do not act like an azerty one exept if I set my Windows keyboard to US keyboard, then the keyboard in dosbox-x act like a french one.

I try on the X86 Windows version (SDL1)

SDL1 might do better, but there's only explicit support in SDL1 and DOSBox-X for a few layouts.

It may be trivial to modify the in-tree SDL1 library to recognize and handle your AZERTY layout properly.

Thank you
activating this setting fix my problem
usescancodes = true

With the two latest updates, Installing Windows 95 and then IE 4.0.1 SP2 correction crashes during Multimedia Player installation (with 0.82.14 it worked completely fine). I guess it is a critical issue for the stability which seemed to be one of the general DOSBOX-X principles, yet my previous comment about this was ignored 😒
Unless Windows 95 support doesn't matter anymore then Sorry.

Timbi wrote:

With the two latest updates, Installing Windows 95 and then IE 4.0.1 SP2 correction crashes during Multimedia Player installation (with 0.82.14 it worked completely fine). I guess it is a critical issue for the stability which seemed to be one of the general DOSBOX-X principles, yet my previous comment about this was ignored 😒
Unless Windows 95 support doesn't matter anymore then Sorry.

You would be better served using W98SE. W95 is buggy compared to 98

Timbi wrote:

With the two latest updates, Installing Windows 95 and then IE 4.0.1 SP2 correction crashes during Multimedia Player installation (with 0.82.14 it worked completely fine). I guess it is a critical issue for the stability which seemed to be one of the general DOSBOX-X principles, yet my previous comment about this was ignored 😒
Unless Windows 95 support doesn't matter anymore then Sorry.

No that's something to be concerned about.

Does it matter what core you are using or what cputype is selected?

bfcastello wrote:

Timbi wrote:

With the two latest updates, Installing Windows 95 and then IE 4.0.1 SP2 correction crashes during Multimedia Player installation (with 0.82.14 it worked completely fine). I guess it is a critical issue for the stability which seemed to be one of the general DOSBOX-X principles, yet my previous comment about this was ignored 😒
Unless Windows 95 support doesn't matter anymore then Sorry.

You would be better served using W98SE. W95 is buggy compared to 98

However Win95 has less overhead, and it can run reasonably well under DOSBox SVN and DOSBox-X.

Win95 OSR2 has some weird quirks of it's own.

Timbi wrote:

With the two latest updates, Installing Windows 95 and then IE 4.0.1 SP2 correction crashes during Multimedia Player installation (with 0.82.14 it worked completely fine). I guess it is a critical issue for the stability which seemed to be one of the general DOSBOX-X principles, yet my previous comment about this was ignored 😒
Unless Windows 95 support doesn't matter anymore then Sorry.

Is this Windows 95, or Windows 95 OSR2?

Windows 95 OSR2 is a bit weirder to emulate for than the original Windows 95.

Are you using the Windows release, the one I compile with VS2017?

This interesting bit of information just came up that might be related: Spectre mitigation techniques in VS2017.

https://twitter.com/Foone/status/1107548233968943104

I didn't change anything in the CPU normal core recently, though I will try to confirm here on Linux whether the same crash happens.

One way to check if this is the case is to see if the MinGW builds fail in the same way. MinGW does not yet apply Spectre mitigation techniques.

Finally, there are small programming experiments in the experiments/ directory of the source tree.

These are experiments in various libraries and OS functions that may or may not become new code in the future of DOSBox-X.

A README is provided in each experiment's directory to explain what it's about.

Comments are welcome, in case I missed anything important.

Here goes testing.

Windows 95 original OEM release.
cputype=pentium
cycles=40000
core=normal

No crash here.

Are you using core=dynamic or core=auto?

EDIT: After reboot, a sudden crash with an FPU overflow.

EDIT: You know what DOSBox SVN and the borrowed x86 FPU code have that DOSBox-X doesn't have? Code to E_Exit() when the FPU stack overflows.

EDIT: Commenting out C_FPU_X86 from config.h and running the startup again seems to resolve the crash.... so far. DOSBox-X bombing out from the x86 FPU core seems to have caused MSIE 4 to fail to create root certificates so it prompts me to confirm installation of each part. But it worked.

I can confirm the problem is in src/fpu/fpu_instructions_x86.h

Quick fix:

Locate FPU_PREP_PUSH and FPU_PREP_POP and comment out the line in each one that calls E_Exit() if the FPU stack overflows or underflows. Then you can run Windows Media Player.

Thanks alot !

Sorry I was offline when some basics infos were needed, it is Windows 95 OSR2 and the crash was occurring in every combination, playing with cpu types/core. I was planning to do more tests about it. Yet everything was done so quickly 😀 It is nice to see it resolved though.

Thanks alot Codeholio for making DOSBox-x. After using 0.82.4 for long time I decided too try the newest version. I then discovered that the Drive option was missing from the menu bar. Actually it's been missing since 0.82.7 2018-06-01 13:05.
Why did you removed that feature? I use it for one game that's on six CD images. I hope it's a minor bug that you're willing too fix soon. I've tested both the 32 and the 64-bit Windows versions. In the meantime I'll just use 0.82.6 😀
I'm using Windows 10 64-bit.