Why DOS Games Need Help on Modern Machines

Why DOS games need help on modern machines

A DOS game expected a particular kind of computer around it. It might communicate directly with a graphics card, wait for a hardware timer, or send music to a sound chip chosen during setup. A modern operating system provides a different environment. More processor power does not replace those missing expectations, and an old executable may not start at all without a suitable compatibility layer.

Making the game accessible today means deciding which parts of that environment affect play. The work is more specific than making an old picture fit a new screen. A jump, a sound cue and a moving hazard all depend on events happening in the right order and at the right pace.

Processor speed and game time are different

Some early games advanced as quickly as a processing loop could finish. The loop read input, moved objects and drew another picture. A faster processor could finish that work sooner, making the whole game run too quickly. A delay loop was one way to slow a program down, but its duration also depended on the machine executing it.

Other games used a timer or waited for the display's refresh. The PC's standard timer interrupt occurred about 18.2 times a second; programs could reconfigure the timer for other rates. Waiting on a clock gave a game a way to separate its pace from raw processor speed. It did not guarantee perfect behaviour on every machine, because drawing and other work still had to finish in time.

Doom is a familiar example of a game with a fixed simulation rate: its world advances 35 times per second. That number is about the rules of movement and interaction, not simply the monitor. Standard VGA's common 320 by 200, 256-color mode refreshed at about 70 times a second. A game could advance on every refresh, every second refresh, or a separate timer.

A modern version needs to preserve the relevant clock. Doubling how often a screen is painted should not double an enemy's speed. Likewise, returning to a browser tab after a long pause should not be treated casually as permission to race through a large unseen section of play. Handling interruptions is part of the work, not proof that every browser version already handles them perfectly.

Sound setup described real hardware

The PC speaker commonly supplied simple tones. Clever software could produce more elaborate effects, but it was a very different device from a dedicated sound card. Ad Lib used Yamaha's OPL2 chip for FM synthesis. Early Sound Blaster cards combined compatible FM sound with digital sample playback. Other devices, including the Roland MT-32, offered different sound capabilities.

A game might include several sound drivers, and the chosen driver could change how its music sounded. Setup programs often asked for hardware settings such as a port, interrupt or DMA channel. Not every device needed every setting. A wrong selection could cause silence, distorted playback or a failure to run.

The game or its setup program usually kept the chosen settings; some hardware configuration was also supplied through environment variables. DOS itself did not automatically remember one correct sound setup for every game. That distinction matters when looking back at the apparent ritual of configuring each new title.

Today, emulation or a translation can reproduce those sound functions without asking a player to configure a physical card. Preserving the result still takes care. An effect should begin when the corresponding action happens, and a different sound source should not quietly change the rhythm of play.

More memory did not always mean usable memory

Conventional memory occupied the first 640 kilobytes of the PC's address space. DOS, drivers and other resident software used part of that area, leaving less for a game. Installing extra RAM did not automatically enlarge this particular space. The region above it also included addresses reserved for video and system firmware.

Expanded memory, usually called EMS, and extended memory accessed through XMS offered different ways to use memory beyond conventional memory. They were not interchangeable requirements. A game expecting one arrangement could fail even when the computer contained plenty of total RAM. Memory managers and carefully chosen startup settings could therefore decide whether it ran.

Boot disks offered a way to start with a suitable configuration. Larger games could also use DOS extenders to access memory beyond the limits of ordinary real-mode programs. A modern environment can remove much of that setup work while still preserving limits that actually shaped the game, such as the number of active objects it could handle.

Two ways to bring the game forward

An emulator reproduces the behaviour of an older machine so the original program can run. DOSBox is one example. Its processor-cycle settings affect the speed of the emulated CPU, so a game tied to processor speed may still need an appropriate setting. Emulation makes a compatible environment possible; it does not make every configuration equally accurate.

A translation or port instead expresses the game's behaviour in a new program or environment. The hard question is whether it makes the same decisions from the same situation and input. A picture that resembles the original is useful evidence about drawing, but not enough evidence about movement, collision or timing.

Choosing sound hardware

What still needs to agree: The sound and its timing within play

Arranging a boot disk

What still needs to agree: Rules and limits that affect the game

Using a larger window

What still needs to agree: Level geometry and collision boundaries

Playing on a faster computer

What still needs to agree: The pace of jumps, enemies and hazards

Using touch instead of keys

What still needs to agree: The actions received by the game

What to look for while playing

Try a familiar jump, a moving obstacle and an item pickup. Do they behave as expected? A faithful version should preserve the route and the meaning of each action, even if the screen is larger or the control is a touch button. Repeated attempts help reveal differences that a still image cannot show.

DOSHD presents Dangerous Dave and Electro Man, alongside Bluemoon Interactive's SkyRoads. Their pages describe their approach and limits. Electro Man explicitly remains a translation with differences still being checked, and SkyRoads is a beta. Preserving old rules is the aim; a release's actual claims should stay tied to what has been checked.