As Microsoft will tell you, there’s brisk traffic in computing nostalgia right now. But don’t forget: Windows 1.0 was reliant on MS-DOS. And for years, DOS was the only real solution for technically demanding games on the PC platform.
There’s nothing wrong with wanting to play DOS games in 2019, even if they’re old enough to hang out in dive bars. Phil’s Computer Lab has a lot of interesting resources and a useful YouTube page. Vogons is an informative forum and fun to lurk in, too.
But there are a lot of caveats to installing DOS on new hardware. It’s possible that getting everything just right won’t even be possible now. The reasons… aren’t simple.
A Little History
MS-DOS is a legacy operating system from the nether reaches of Intel-compatible personal computing. It has a technical foundation built on ensuring backwards compatibility while intermittently, even resentfully growing capabilities to accommodate new hardware. And from its earliest days it was the arch-nemesis of the vintage Mac, associated with monochrome screens, command-line computing, pre-internet networks like Compuserve and BBS, and early PC games.
But since the mid ’90s a series of newer and progressively saner operating systems came along and rendered it irrelevant for mainstream PC use. Windows 95 brought about a sea change of graphical computing that only accelerated with Windows 98 and Steve Jobs’ return to Apple and the advent of the iMac. DOS rapidly declined in broad use; by the time Apple unveiled OS X, it had come to serve a progressively dwindling niche of embedded systems and nostalgics, as well as George R.R. Martin, who got used to running WordStar on his DOS machine eons ago and has stuck to it since.
In the ensuing years even embedded systems have grown away from MS-DOS. The project lead of FreeDOS, an open source reproduction of the operating system, recently admitted that the principal use of his project these days is for playing video games. So if real people are using it for games, why am I being a killjoy about building a system to do it?
Why It’s a Bad Idea
The first thing working against you is that DOS existed at a point when hardware was thousands of times slower than now. A ton of games, especially very old ones, were written to run as fast as contemporary hardware allowed. When PCs didn’t run so much as amble, an internal timer that ensured the game ran at a set speed was more work than many programmers expended.
These days even the cheapest PCs you can buy are unfathomably quicker. Trying to install MS-DOS onto a modern computer poses a number of challenges in and of itself, but even after getting it running, trying to launch one of these titles would result in something that would be unplayably fast. You can’t fly a plane across a screen if it crashes into the ground in the time between hitting enter to start a new game and getting your fingers to the arrow keys. There are potential workarounds – using software tools to lower clock speeds, disabling CPU caches, and other trickery that’s too arcane for casual users – but that’s not guaranteed to work on modern systems at all. Even if it does, it’s a frustrating, monotonous, iterative process.
This brings up the next problem. Simpler, less capable hardware was served by simpler software, and what passed for an Application Programming Interface in DOS is incredibly sparse. APIs allow developers to take advantage of functionality without resorting to reinvention. For the purpose of writing games or leveraging hardware to handle multimedia, it only offered a collection of hardware video standards. These had to be accommodated with a labor-intensive low level of programming – remember, DOS didn’t have APIs to simplify the process!
As the industry aspired to more photorealistic standards, the upper VGA-defined resolution boundary of 640×480 at 16 colors was no longer enough. This was solved by VESA VBE, a standard for handling higher resolution modes that sounded straightforward but was a quagmire of bugs and conformance issues in real-world hardware. In the 90s those limitations could often be handled by programs called TSRs which one could load into memory to replace buggy or insufficient implementations. A lot of modern video cards nominally implement VESA, though over time bugs have crept into newer cards which nobody’s bothered to fix. But that doesn’t touch on audio.
I CAN’T HEAR YOU, HOW BAD WAS IT
There are no official software standards for DOS audio. In MS-DOS’ heyday the situation was so bad that most game studios relied on audio libraries written by third party companies, whose entire job was to write support for the most popular sound cards on the market. The closest thing to a hardware standard was compatibility with Creative Labs’ Sound Blaster line of cards: that way, even if a game didn’t support your card, the user could at least hear acceptable audio. Implementing that feature amounted to duplicating the functionality of a Sound Blaster at the register level, then paying royalties to Creative Labs for the privilege.
For some sound cards you could load a piece of software when DOS started to fool games into thinking a Sound Blaster was present, but that was tricky and didn’t always work. There’s also the problem of the connection interface for sound cards being the long-dead ISA bus. It was only in MS-DOS’ twilight years that newer, faster interfaces became standard for audio, and these created compatibility problems of their own. There’s a reason Microsoft’s DirectSound was a godsend in the late ‘90s: you could write to the standard, and for every sound card with DirectSound support, it would simply work. But as much as these problems hobble efforts to run software of yesteryear on AMD CPUs, even the abandonment of the Sound Blaster as de facto standard is a smaller impediment than the decision Intel committed to silicon in 2013 and ever since.
The Fall of Gate A20
When PCs transcended the 1 MB of RAM that was the entire conceivable, addressable memory space of Intel’s 8088, programmers had a notable problem: tricks used to improve performance with segmented memory would break with larger quantities of memory. A solution was accomplished by inserting a logic gate on the A20 line between the processor and system bus, which was named gate A20. This feature became inextricably important to early operating system design, particularly for the class of applications known as memory extenders – programs allowing access to the quantity of memory beyond MS-DOS’ pools of conventional and high memory. (There’s a great writeup at OS/2 Museum on this subject that’s worth reading if you have the time.)
In 2013, Intel decided that gate A20 was no longer worth accommodating in their design, and removed support for it from their processors. I understand the company’s reasoning: continuing to support the feature was likely an irritation for chip designers, and in service to an audience who were all but theoretical from a market perspective. Nonetheless, it breaks DOS memory extenders at large, keeping anyone from running a large number of MS-DOS applications on actual, physical installs to contemporary hardware. Modern Intel chips are thus the worst of both worlds for DOS: too fast for older, simpler games, and simply unable to run newer complex ones.
DOS and Don’ts
We’ve established that modern computers don’t cope well with MS-DOS running on bare hardware. Happily there are a lot of options that will give you an authentic, accurate experience. I’m going to talk about two of them: DOSBox and PCem. Though they’re very different in their approaches, both can make your pixelicious dreams come true.
DOSBox is an emulator built from the ground up to play DOS games. It’s very good at that job: I’ve never personally run into a game that it couldn’t manage, and its compatibility matrix is north of 90% for titles submitted so far. Best of all, it’s cross-platform and runs on nearly everything, including Windows, Linux, smartphones, Raspberry Pis, Chromebooks, and Macs – including venerable PowerPC models.
The learning curve isn’t too steep: read the text files that come with it to learn its basic configuration options. It’s well-behaved, comes with a basic complement of DOS tools, and is easy to point to a folder containing the games you want to play. Best of all, you don’t have to get into the nitty-gritty of installing and configuring DOS itself: DOSBox presents what games expect to find, so outside of setting initial options and playing with settings, there’s no real system administration to do. However, it’s not a real DOS system: while you could install DOS utilities and flesh it out a bit, delivering an authentic DOS experience is outside the priorities of the project and its goals.
If you’re looking to run something more like a real disk operating system, look no further than PCem. It will do an excellent job of recreating the experience of a vintage computer – you don’t even have to use DOS, you could install any operating system that would work on an authentic computer from that era. But it does come with caveats:
* PCem demands a lot of performance. Even a decently equipped Core i7 will struggle to accurately reproduce a midrange Pentium. And support for platforms beyond the PC is currently experimental at best: this won’t manage Doom on your Picade, at least not for a while.
* There’s a lot of configuration involved, from specifying the type of hardware you want to emulate to creating a disk image and manually installing an operating system to it. If your eyes cloud over at that prospect, DOSBox will probably be good enough if you don’t have a specific job in mind beyond playing games.
Both DOSBox and PCem are great tools that make DOS games playable again. They’ll do a better job than wrestling with DOS on bare new hardware, and are a lot cleaner and more reliable than trying to find working DOS hardware in the wild…
Get popcorn. It’s a long video, and an indictment of America’s faddish love of gadgets.