Linux Gaming – DOSBox, an x86 DOS Emulator: Play Your Original DOS Games in HD

DOSBox is an x86 DOS Emulator that not only emulates the x86 architecture, but also emulates a common 1990s-era DOS environment. With DOSBox, you can replay your old games and play them on modern hardware, since there are many interesting and legendary DOS applications that aren’t available for Windows or Linux.

DOSBox is very stressful on many computers, since you normally need a high-end PC to emulate a 486 at 33MHz. Since the ODROID uses a completely different architecture (ARM vs X86), it has even more work to do during emulation. Despite its complexity and multiple layers, DOSBox runs surprisingly well on the ODROID platform.

Some time ago, I compiled an ARMv7-optimized version of DOSBox which appeared to be running faster than the stock DOSBox version that comes with the official distribution. I took some time to compare these versions and find out exactly what is improved by using an ARMv7-optimized build.

Below you will find a series of side-by-side tests that highlight the differences between the generic build of DOSBox, and a build that is specifically compiled for ARM. The custom build of DOSBox for ARMv7 may be downloaded from my repository at http://bit.ly/1DhCv6l.

Configuration

Configuring DOSBox can sometimes be difficult. While most games run fine with the basic settings, others only run with a very specific configuration, so I chose a set of values that worked best for the original version of the game Quake, since it’s very demanding on the hardware.

What’s remarkable about Quake is that the game itself is in 3D without requiring a graphical desktop environment. In contrast to games like “Duke Nukem 3D” ,which contains some 3D objects and use 2D sprites in many situations, Quake was already using 3D models, similar to the models used in later games on Windows, which was very impressive for that time.

There was no easy way to find the right settings, and after a period of experimentaiton, I ended up with the following results, with frameskip and aspect ratio turned off:

core=dynamic
cputype=pentium_slow
cycles=fixed 32000
cycleup=500
cycledown=300
memsize=32
scaler=normal3x
Dynamic cores should be used for any value of fixed cycles over 20,000. Pentium_slow is the CPU with the most features, and I set the cycles to 32,000, which is very high. Some test programs reported it to be a 1285 MHz fast Pentium CPU. I chose such a high number because of Quake, since at 32,000 cycles it gives the most fluid experience on both DOSBox versions.

Tests

After performing a variety of tests, I discovered that it was actually hard to find some good benchmarks. I remembered some benchmarking applications from back when DOS was popular, but they were hard to find. However, I did find a test environment for performing different benchmarks under DOS called DOS Benchmark, which is available for download from http://bit.ly/1ttzaRR.

DOS Benchmark offers CPU, GPU, and memory tests, as well as demo versions of the games Doom and Quake for benchmarking the environment. I tried to run every test available, but not all of them were working, although I did find a few that performed nicely. For instance, I found a test with a spinning 3D cube running in DOS, which has some great visuals, and ran relatively fast on the ODROID.

Figure 1 - Spinning cube under DOS
Figure 1 – Spinning cube under DOS

Figure 2 - Stock Debian version of DOSBox
Figure 2 – Stock Debian version of DOSBox

Figure 3 - ARMv7-optimized version of DOSBox
Figure 3 – ARMv7-optimized version of DOSBox

3DBench test

The ARMv7-a optimized version was nearly 17% faster in this test. Unfortunately, that test is not very reliable if you change the CPU cycles as I did. I was able to achieve results with over 200 FPS with values like 100,000 CPU cycles, but even with these high numbers, the emulator was far from working better or even faster. I could see that the video output was lagging and skipping frames, but the test still got high scores.

Figure 4 - 3D Bench test using stock build
Figure 4 – 3D Bench test using stock build

Figure 5 - 3D Bench test showing difference in results using ARM build
Figure 5 – 3D Bench test showing difference in results using ARM build

Benchmark

The CPU tests were showing that the ARMv7-a optimized version performs somewhat better. An improvement of around 30% was common when it came to CPU computing comparisons.

Figure 6 - CPU benchmark using stock build
Figure 6 – CPU benchmark using stock build

Figure 7 - CPU benchmark using ARM build, which is clearly faster
Figure 7 – CPU benchmark using ARM build, which is clearly faster

Memory issues

While some benchmarks worked better in the ARM version, I saw some major issues in some tests when it came to the ARMv7-a optimized version. Some tests didn’t even run on the ARMv7-a optimized version of DOSBox, or causes strange behavior. Only the stock Debian version was running 100% of the tests correctly. (Figure 8 – CACHECHK was only working on the stock Debian version of DOSBox, and properly identified the CPU)

For example, there was a memory test which used blocks of different sizes and did some operations on them so that in the end the different blocks added up to 24MB in total. It operated on 384 x 64KB blocks and gave a result on how fast the memory did the computing. The same test on the optimized version resulted in very different results. Not only did the ARM test took approximately 10 times as long to run, the values were completely inaccurate. Instead of 24MB in results it added up blocks of 512 MB and more at a ridiculous speed.

Some tests went so high, that it went out of scale and resulted in either a negative speed or with high exponents calculating ten thousands of megabytes per second. Other tests didn’t start at all, or caused the emulator to freeze.

Testing tools

I tried some other testing tools for benchmarking the graphics performance of the system, like the spinning cube and VideoDOS, which sometimes had very odd results. Because the graphical tests are just benchmarks, and don’t directly relate to gameplay responsiveness, I did some hands-on testing with some of my favorite games as well.

Figure 9 - Graphical test on the stock Debian build of DOSBox
Figure 9 – Graphical test on the stock Debian build of DOSBox

Figure 10 - Graphical test on the ARM build of DOSBox. This graphic tests gave odd results: some tests seemed to run faster with more colors and in higher resolutions, while others seemed normal)
Figure 10 – Graphical test on the ARM build of DOSBox. This graphic tests gave odd results: some tests seemed to run faster with more colors and in higher resolutions, while others seemed normal)

Figures 11 and 12 - Results of VideoDOS of the ARM optimized version (left) and the stock Debian version (right)
Figures 11 and 12 – Results of VideoDOS of the ARM optimized version (top) and the stock Debian version (bottom)

Games

The benchmark package included two games, Doom and Quake, since both were very commonly played during the golden age of DOS, and offered some nice benchmark features in demo mode. However, the benchmark build into Doom did not work correctly, and claimed to nearly always be running at nearly full speed, although it was far from it. (Figure 13 – The Doom DOS version is playable but not very smooth on DOSBox, but performs much better as a native Linux port)

Instead of using the built-in benchmarks, I did my own testing and compared the time that it took the games to do a full demo run. The results were very surprising for me: Demo 3 took about 108 sec to complete a full demo run on the ARMv7-a optimized version of DOSBox, and on the stock Debian version of DOSBox it took 156 sec instead. That’s a nearly 45% increase in speed for the ARM version.

Even more dramatically, you could see the difference when playing Quake. A demo run for Demo 3 took 147 sec on the optimized version and 248 sec on the stock Debian version, which is approximately 70% faster! After all the benchmarking, I wanted to see how well the emulator performs in a real gaming experience, and soon found out that the settings that I had originally chosen did not work well for any other games, so I changed the settings again and ran a couple of test games. After I tuned down the cycles to 6,000 instead of 32,000, Dune 2 was running perfectly fine, with nice, smooth gameplay. The sounds, music and voices were all good, and I had no other issues.

I also tried a couple more demanding games, such as Prisoner of Ice, which is a very nice adventure game with some movie cut-scenes and an option to either run in 320×240 resolution or in 640×480. The last one even offered some other features such as better fonts. Both versions were running fine on DOSBox. I also found the same superior performance while playing Space Quest 6.

Results

The ARMv7-a optimized version runs significantly better than the stock Debian version of DOSBox. If I would have to estimate a number, then the optimized version is, on average, 10 to 15% faster than the version from the Debian repository. Sometimes, it was even far faster than that, such when running Quake.

The faster results seem to be related to some math optimizations inside the emulator, which may also create issues as a side effect, especially with memory operations. This, in turn, may cause glitches in some games, or prevent them from running properly. Besides that, the ARM optimized version is the better version when it comes to speed.

From my previous testing, I can say it’s even fast enough to handle Windows 3.11 or even Windows 95. Most games should run nice on both emulators but run are just a little better on the ARM optimized version.

Additional configuration

When I was done with the testing played some games, I changed my settings to the following options, which I found worked well with many games:

core=auto or dynamic
cputype=auto
cycles=fixed 3000
memsize=31
I also found that DOSBox is able to use glshim together with its opengl renderer using the output option:
output=opengl
Finally, I changed the sdl settings:
fullscreen=true
fulldouble=true
fullresolution=1280x720
windowresolution=original
output=opengl
These options start the game in fullscreen mode, and when used together with LD_LIBRARY_PATH=/usr/local/lib/, you can run the emulator with OpenGL support.

Other games

As you can see from the chart below, games vary a lot in playability, and there is no single setting file that works with all games. I also found that the “auto” mode on cycles does not really work well. The 100% speed it uses on heavy games is often worse than using a fixed cycle value.

When using DOSBox for your own games, I suggest starting at a cycle value of 3,000, and working your way up until the game starts getting slow again, then taking a few steps back. This should result in the optimum playability for your favorite DOS games.

Game Cycles Infos Comments
Sid Meier’s Colonization 1,500-3,000 Game runs best with rather low cycles.  Besides that, it’s running very fine with no issues or sound drops.  However, the intro on the first game start takes a long time to play through.
Shadow Warrior 15,000-20,000 The game is laggy, and not playable
Terry Pratchett’s Discworld 1 3,000-6,000 Game ran fine without any issues
Syndicate 6,000-10,000 Game ran fine without any issues Does not run with glshim
Wing Commander I 2,000-4,000 Game ran fine without any issues.  In my opinion, the Amiga version has a much better soundtrack You should use a 3x scaler here
Prisoner of Ice (640×480) 2,000-8,000 Game ran fine with only a minor issue with the sound cracking occasionally
Space Quest 6 ~12,000 Game mostly runs at full speed, but has some slight stuttering in the music, and the text is too fast
Dune 2 3,000 Game seems a little slow but generally good and without issues
XCom Series 1,000-15,000 Works well with only slight speed issues
Dark Legions ~20,000 Works well with only slight speed issues

Be the first to comment

Leave a Reply