Emulating dual Hercules+CGA monitors setup with DOSBox

5.00 avg. rating (94% score) - 1 vote

There is an interesting option called “Dual monitor support” located in the Options > Environment > Startup dialog of Turbo Pascal 7.0 and Turbo C++ 3.01. If you have a dual monitor setup, specifically a Monochrome Display Adapter (e.g. MDA/Hercules) and a Color Graphics Adapter (CGA), then enabling this option will allow the IDE to be displayed on the monochrome monitor, and the debugged program to be executed on the color monitor.

dualmonitor

This option can also be specified from the command line (/D), as described in the help text for TC /? (Turbo Pascal does not support BP /? or TURBO /?, although command line arguments are described in details in online help):

Syntax:   TC [option [option...]] [srcname|projname [srcname...]]
srcname  is any ASCII file (default extension assumed)
option   is any of the following: (/x- = turn option x off):
 /b              batch mode build project then exit
 /d              dual monitor mode, IDE uses other monitor
 /e[=n]       *  use n pages of expanded memory for swapping
 /h              displays this help
 /l              LCD/B&W colors for screen
 /m              batch mode make project then exit
 /p              restore palette on EGA after swap
 /rx             use alternate disk 'x' for swap file
 /s           *  allow maximum swapping (thrashing)
 /x[=n]          use n KB for the code and data memory pool
              *  means enabled by default

A Hercules card is difficult to procure, even in the early 2000s, and for years I could not get this option to work. Not all BIOS or motherboards support this option. Some only support very specific Hercules + CGA combination and Hercules + VGA will not work. It was not until recently that I came across a patch for DOSBox on vogons which supports exactly this feature, and decided to give it a try. You can also download the complete set of files here.

What the patch does is essentially modifying the DOSBox to report via BIOS that a Hercules card is present, and then capture writes to the B000-B7FF region (used for text on monochrome monitors), interpreting these writes and display the corresponding text onto the DOSBox console window using the pdcurses library. With this, the DOSBox console window has been repurposed to be the monochrome terminal (named as the secondary display) and log messages (if useful) must be retrieved from the log files. For it to work, you will also need to check your EMM386 declarations (if any) and make sure that region B000-B7FF is excluded, or just remove EMM386 altogether.

According to the documentation provided by the patch author, to start DOSBox in dual monitor mode, you must specify the -display2 parameter, followed by the color you want (white or green):

dosbox.exe -display2 green

Before the latest Windows 11 update, the color setting used to work for me. However, it is presently ignored and I simply get light grey text color, which is not a big problem in any case. To test it, run Turbo Pascal 7.0 (or Turbo C 3.01) with a simple program and step through it, line by line:

snip
In the screenshot above, the IDE is shown in the monochrome monitor (left) and the program output on the color monitor (right). As you step through the program, numbers will be written to the color monitor (right window). This is a very convenient way of debugging as you can see both the codes and the output at the same time, compared with having to swap between the two screens. Take note that DOSBox hot keys (e.g. CTRL-F9 to exit) overrides that of Turbo Pascal (Ctrl-F9 to run), so you might want to use the IDE’s menu, or change the DOSBox key assignments.

There are disadvantages however. The IDE is now monochrome and features such as syntax highlighting will be limited to keywords. Second, as DOSBox will only process keypresses if the main window gains focus, you will need to click the mouse in the color monitor (e.g. program output) before you can type into the IDE on the monochrome monitor. This is a confusing process and takes a while to get used to. Finally, the dual monitor setup is nowhere as good as debugging with a modern IDE. If your program is running (and not paused via a breakpoint for example), clicking on the IDE window will do nothing, e.g. the IDE essentially freezes. To go back to the IDE and set more breakpoints, you will have to quit the program, or at least pause it via Ctrl-C or Ctrl-Break, which does not always work. In a modern IDE, breakpoints can still be set with the program still running, with just a simple mouse click.

In case you are wondering, the “CGA snow checking” option allows the IDE to use certain software techniques to limit snows, which is caused by writing to display RAM while the CRT refresh is in progress. Snow was a real issue of CGA display back in the day, see this for more details. On an emulator such as DOSBox, setting this option is useless and would just slow down the processing speed.

For all its limitations, in the lack of real hardware, the DOSBox patch to emulate dual monitor setup is still very useful for those who want to enjoy this feature, either for Turbo C/Turbo Pascal development, debugging software using SoftICE, or to play games such as MahJongg VGA which support two monitors (the monochrome will be used to display statistics). My hats off to the author of the patch who has devoted his time to develop this useful feature.

5.00 avg. rating (94% score) - 1 vote
ToughDev

ToughDev

A tough developer who likes to work on just about anything, from software development to electronics, and share his knowledge with the rest of the world.

2 thoughts on “Emulating dual Hercules+CGA monitors setup with DOSBox

  • September 2, 2024 at 8:44 am
    Permalink

    I use DOSBox-X when I need a dual-monitor environment since that capability works better.

    What I wish DOSBox-X could do is allow the emulated Hercules video card to be put into bitmapped mode.

  • ToughDev
    September 3, 2024 at 3:40 am
    Permalink

    Hi Bill,

    Oh yes, I love DOSBox-X – far more sophisticated than DOSBox and much easier to use. You can also conveniently compile DOSBox-X in Visual Studio and debug it, giving you the opportunity to study the behavior of many DOS programs (e.g. which ports/memory address are being accessed), which is hard to do even with DOSBox X internal debugger.

    If I have the time, I would love to improve DOSBox-X internal debugger to be more user friendly, e.g. adding UI buttons to dump memory / disassembly and to step over/step into code, instead of just shortcut key. This will perhaps be an exercise during my next break from work :)

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>