Experimenting with DOSBox SVN-Daum, a custom DOSBox build by ykhwong

While watching a Youtube video that demonstrates how to use the Roland MT-32 MIDI synthesizer with DOSBox, I came across DOSBox SVN-Daum, a custom DOSBox build by ykhwong. This custom release provides a menu allowing users to perform common DOSBox tasks such as mounting disk drives as well as changing some configuration (sound, CPU, display, etc.) at runtime without having to edit dosbox.conf and restarting DOSBox:

There is also an Aspect Correction menu option which, if checked, will allow you to play game in full-screen with 4:3 aspect ratio. With the official DOSBox build, fullscreen resolution will be stretched to 16:9, unless you modify fullresolution in dosbox.conf and set it to something like 1024×768. The Aspect Correction menu option therefore provides for a more intuitive way to achieve the same purpose without having to edit the DOSBox config file.

My favorite game, AlleyCat, works well under this release of DOSBox:

In case you don’t know how to quit AlleyCat, press Ctrl-Y while the game is being played. The game will not reset the text mode after it quits so you will most likely need to reset it manually. The easiest way to do this is to run Norton Commander and exit it immediately, after which the text mode will be reset to 80×25.

Everything looked good and I was about to remove the official DOSBox release and use this version of DOSBox until I noticed something odd. When running Super Mario MS-DOS clone by Mike Wiering, the menu screen was shifted up a few pixels, approximately the height of the newly added DOSBox menu bar:

The issue also appears in full-screen mode and regardless of the settings chosen in the Video menu. This does not happen on the official DOSBox build which does not have the menu bar, so I am pretty confident that this issue only happens with DOSBox SVN-Daum. Nevertheless, the game continued to work flawlessly.

Unfortunately the issue is just the tip of the iceberg. Many other games by the same company, Super Angelo, Charlie the Duck, and Charlie II, also start up with a distorted menu screen. The screen is vertically stretched to approximately 200% and clipped by the DOSBox window, so only the top half of the screen is visible:

Although the issue is also observed in full-screen mode, it does not happen with the Wiering Software logo that is shown at startup before the menu screen. Setting various DOSBox video option does not change anything and these games are therefore unplayable.

In an attempt to find out what causes the issues, I used CheckIt, a popular DOS system information tool back in the day, to test the emulation of various video modes under this version of DOSBox. Surprisingly, distorted display was frequently observed when various CheckIt tests were performed, for example missing grid lines in the Color Palette Test #5:

There were also issues in several graphics modes:

This is the test result with failure in at least 8 tests:

On the other hand, no issues were observed in the official release of DOSBox and it performed adequately in most tests, except for EGA Mono (Mode 0Fh) which showed a black screen:

I presumed this is simply because mode 0Fh is not commonly used and thus was never officially implemented by DOSBox. Surprisingly, DOSBox SVN-Daum implements this mode and passes the EGA Mono test with no distortions whatsoever:

In an attempt to dig deeper into the issue, I wrote a simple Borland Pascal 7.0 program that draws 2 lines to test the default 640x480x16 VGA graphics mode:

uses crt, graph;
var gd, gm:integer;
begin
    gd := detect;
    initgraph(gd, gm, 'c:\bp\bgi');
    line(0, 0, GetMaxX, GetMaxY);
    line(GetMaxX, 0, 0, GetMaxY);
    readln; 
    closegraph;
end.

To my dismay, a significant portion of the lines was missing when drawn on the screen:

In one last test, I changed the code to plot random individual pixels instead of lines:

uses crt, graph;
var gd, gm:integer;
begin
    gd := detect;
    initgraph(gd, gm, 'c:\bp\bgi');
    randomize;
    repeat
          PutPixel(Random(GetMaxX), Random(GetMaxY), Random(GetMaxColor));
          Delay(10);
    until KeyPressed;
end.

This time, no distortions were observed:

I assume the distortions are due to possible video memory corruption when blocks of video memory are accessed in a fast manner, which might explain why it only happens when we draw lines, but not when individual pixels are plotted. Apart from CheckIt, so far I only observe the issues on DOS games from Wiering Software, which were still being developed as late as 2007, long after the DOS era. These games might have been programmed with modern machines in mind and might not have speed limiters or other safeguards built in to prevent these kinds of issues. Also in CheckIt tests, the distortions vary each time the test runs, which strongly suggests that the issue is memory-related. The exact answer, however, can only be sought from ykhwong, the author of DOSBox SVN-Daum.

On a side note, several DOSBox SVN-Daum menu options such as changing sound or disk drive will no long work should you choose to boot your version of DOS, instead of using the lightweight DOS version that is included. When this happens, no error message will be shown and your selection will just be ignored silently.

My verdict is that DOSBox SVN-Daum is only good for testing or experimenting with various DOSBox features. For a stable configuration, use the official DOSBox release instead.

See also
Programming Nostalgia: revisiting Mike Wiering’s Mario game written in Pascal
Getting Linux to boot on DOSBox-X