If you haven't: compile/get a 32 bit version of dosbox. (apt-get install dosbox:i386)

Qbix wrote:

If you haven't: compile/get a 32 bit version of dosbox. (apt-get install dosbox:i386)

I have not tried this yet. I am running debian 8 on this machine. I probably just did "sudo apt-get install dosbox".

you might need to add the architecture
dpkg --add-architecture i386
apt-get update

It's considerably faster.

Qbix wrote:

you might need to add the architecture dpkg --add-architecture i386 apt-get update […]
Show full quote

you might need to add the architecture
dpkg --add-architecture i386
apt-get update

It's considerably faster.

I could swear at one time (can't remember if it was debian 7 or 8 ) that I enabled the ability to do both 32 and 64 bit stuff..... I have installed debian on probably a half dozen machines at my house in the last few years...

yeah, but it doesn't install the 32 bit one on 64 bit mahine, unless you specificy it (so dosbox:i386)

you my friend- are my hero!

it seems to work amazing! I am getting only 70 percent processor occupancy going up the hill at monaco where the graphics are the most detailed! I need to test it more, but so far the results seem spectacular. Thank you so much!!!!

On average, how much faster is the x86 dynamic core compared to the recompiling core? Are we talking about percents or orders of magnitude?

I've thought about compiling a 32-bit version on my main desktop system but it got annoying as some 32--bit SDL-related libraries are missing from Arch Linux repositories...

How does the x86 dynamic core exactly work? Does it let most of the code run natively? (I think Virtualbox works like this when VT-x/AMD-V is not available.)

Roughly 200-300% faster? Depends on the game...
It still interprets/recompiles every instruction but takes advantage of the fact that the new code will implicitly produce the same flag results as the original code. So unlike the generic dynamic core there's no need to manually calculate the flags every time they're accessed.

jmarsh wrote:

Roughly 200-300% faster? Depends on the game...
It still interprets/recompiles every instruction but takes advantage of the fact that the new code will implicitly produce the same flag results as the original code. So unlike the generic dynamic core there's no need to manually calculate the flags every time they're accessed.

Ok, thanks for the information.

I tried to compile Dosbox (SVN) on Debian, but looks like I can't compile a 32-bit version.

If I do ./configure --build=i386-pc-linux-gnu configuration works but compiling does not - it complains about loss of precision. As far as I can tell this is because it's still compiling a 64-bit version and the error is about conversion of pointers to 32-bit integers.

If I do CC="cc -m32" CXX="c++ -m32" ./configure --build=i386-pc-linux-gnu as instructed elsewhere, it fails during configuration as it can't find some 32-bit SDL files. And installing libsdl1.2-dev:i386 is not OK because installing some of its dependencies would require deleting a huge bunch of packages.

I've tried using --host instead of --build but it doesn't apparently help.

Installing dosbox:i386 from repositories is possible but it can't be installed side by side with the default 64-bit version. This isn't a big problem, but it's just annoying that the 32-bit SVN version can't be compiled.

junglemontana wrote:

Installing dosbox:i386 from repositories is possible but it can't be installed side by side with the default 64-bit version. This isn't a big problem, but it's just annoying that the 32-bit SVN version can't be compiled.

I did 'sudo apt-get remove dosbox' before hand, it still kept my directory and config file. This way, when the 32 version was installed the old config was already there and it worked pretty much seamless for me.

This is on debian 8 with the standard gnome 3 gui

For Ubuntu/Debian, I think it is easier to use a 32-bit Ubuntu/Debian guest on Virtual Machine to compile the 32-bit version of DOSBox and then run it on the 64-bit host by resolving the i386 libraries dependency. This worked very well for me with Ubuntu/Debian as both distro have good i386 multilib packages ecosystem. Compiling for 32-bit using "gcc -m32" did not work for me, which I believe the linking of 32-bit libraries had issues.

I have recently transitioned from Ubuntu to ArchLinux in favor of its pacman rolling update and x86_64 optimization. Unfortunately for ArchLinux, the i386 multilib is considered unsupported, so I haven't tried the same trick I used for Ubuntu/Debian.

kjliew wrote:

For Ubuntu/Debian, I think it is easier to use a 32-bit Ubuntu/Debian guest on Virtual Machine to compile the 32-bit version of DOSBox and then run it on the 64-bit host by resolving the i386 libraries dependency. This worked very well for me with Ubuntu/Debian as both distro have good i386 multilib packages ecosystem. Compiling for 32-bit using "gcc -m32" did not work for me, which I believe the linking of 32-bit libraries had issues.

I have recently transitioned from Ubuntu to ArchLinux in favor of its pacman rolling update and x86_64 optimization. Unfortunately for ArchLinux, the i386 multilib is considered unsupported, so I haven't tried the same trick I used for Ubuntu/Debian.

Using a virtual machine is a possible solution as well. It just takes some effort.

Debian does have a multiarch ecosystem for x86-64/i386 but there are still packages that are not multiarch-compatible. And if such packages end up into the stable branch, it may take years before they are fixed.

I think the offending package in my case is libglib2.0-dev:i386 which is in the dependency chain of libsdl1.2-dev:i386. It seems that it has been fixed but Stretch repositories still have an older version after two years.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=683593

Oh, and Dosbox in Stretch repositories is still version 0.74. Version 0.74-2 is not available in stretch-backports either. PFFT.

Arch Linux no longer maintains a 32-bit distribution but many 32-bit libraries are available in the repositories. However, two such libraries needed by Dosbox (SDL_Net and SDL_Sound) are not so they must be installed manually if one wants to compile a 32-bit Dosbox.

junglemontana wrote:

Oh, and Dosbox in Stretch repositories is still version 0.74. Version 0.74-2 is not available in stretch-backports either. PFFT.

I thought this was the case and was wondering why OP was not experiencing segfaults using the distro package (since the old x64 dynarec doesn't align the stack correctly = FPU instructions trigger alignment faults).

I never really had issues with running either the 64 or 32 versions as far as crashes are concerned.

This is possibly getting off topic, but Is there a better Linux distribution you would suggest as far as "built in support" would be considered? Back in the day when I installed Debian on this machine I wanted something that wouldn't need to be upgraded all the time. On my other machine I had Debian as well, but I switched to Mint because Debian gave me frustrations not having some later software in the repositories (mostly browser version stuff) I know there are options to compile things manually but I am not the most advanced user. I would be in over my head using Archlinux.

Ubuntu is basically just Debian with faster updates. Pick a LTS release if you don't want to upgrade regularly.

Just a note about Arch Linux: it seems that SDL_sound is only needed for compressed disc audio (rarely needed I guess?) and SDL_net is only needed for networking features. I just ignored these libraries and managed to compile a 32-bit Dosbox on Arch.

If those features are needed, one can install SDL_sound and SDL_net from AUR or manually from their sources.

I'll check if 32-bit Dosbox can be compiled in a 64-bit environment on the newly released Debian 10 "Buster".