By coincidence, I recently noticed a demo on pouet.net with the same issue, but it's good to know of a game that needs the fix.

I'm still testing the attached patch to make sure it doesn't cause any problems, but so far it looks OK. I've also attached a workaround program you can use until the fix is committed, just put the program in the game directory and run it in DOSBox to start the game.

Wow! I'm impressed by how quickly you found a solution. Running the workaround, I couldn't find any issue, and it also works as a drop-in solution for the shareware 1.1 version of the game. Though, I think I may have found a (very minor) bug with the game itself where you can (sometimes) have a bit of text from the Options menu persist when you return to the main menu.

Cool beans. How do the patch and workaround work, and what do they fix? (Explain to someone well-versed in C++, poor with assembly, and with no clue as to what DOSBox does on the inside).

Real DOS uses attribute 7 (non-intense white on black) as a default when the console device writes to the screen, although the color can be specified with escape codes if an ANSI driver is loaded. DOSBox currently defaults the attribute to "unspecified", leaving it to the video BIOS to use its own default, which works OK in text modes but not in graphics modes.

The patch simply changes the emulated console device to use the DOS-compatible default attribute of 7. The workaround program intercepts console writes made by the game and writes the text through the video BIOS with attribute 7.