Running a game written in 8086 assembly on a modern CPU

Question

I wrote a game in assembly for the 8086 processor and run it on a DOS emulator named DOSBox.

Now I want to show the game to other people without them having to download an emulator. Basically, I want to compile 8086 assembly to an executable for modern operating systems. Is that possible, or should I convert it to another assembly language? If so, is there a way to do this conversion automatically?

Welbie

Do it like company who are selling their old MS-DOS games on GOG.com and Steam do: bundle DOSBox with the game. Note that you'll have to provide the source to same version of DOSBox that you bundle as well in order to comply with DOSBox's GPL licence terms – Homotaxis

Another alternative is, but it depends of the scope of what hardware your game expects, but you could circumvent any operating system altogether and make a bootable image of your game. This would depend on the target system booting from BIOS, but essentially most of the fundemental INT 21 calls drop into one of the BIOS services. Most notably, keyboard and monitor, but if you're saving data to media or reading from, then it becomes much more complicated. – Ecclesiasticus

Answer 1

The problem is not the assembly language as much as it is the run-time environment.

A modern x86 processor has absolutely no trouble running code written in 8086 assembly language. The new chips are nearly 100% backwards-compatible with the 8086. In fact, they boot up as simply a (very) fast 8086.

The part that doesn't work is the part of your program that expects to be running on top of DOS. You are almost certainly invoking DOS APIs (via interrupts) and doing other platform-specific things. This is why you need the DOSBox emulator: not to emulate so much as to run DOS, which your program then runs on top of.

There are certain cases where you can run DOS applications under Windows, using the Virtual DOS Machine in a console environment, but there are some very significant limitations. First and most significantly, 64-bit versions of Windows won't run 16-bit DOS applications at all, so this would only work on 32-bit versions of Windows. Second, there are a lot of assumptions that DOS programs make (like, the fact that they are running directly on top of the hardware and can therefore interact with it however they want) that are incompatible with running in emulation on Windows. Games are especially notorious for these assumptions and incompatible behaviors, both the ones written by professional software houses back in the 1980s and the ones you might write today. Why? Because games need absolute speed to get good graphic effects, so they do things like writing directly to video memory instead of calling a slow DOS API to do it.

You could rewrite your game not to rely on DOS, but that would be a massive undertaking, tantamount to a complete rewrite. It would be just like porting a program from Windows to the Macintosh. You'd have to check all of the system functions that you were invoking and change them to an equivalent on Windows (or whatever other operating system). This would already be a difficult task, but in some cases, you might even find that there is no direct alternate, so you'd need to rewrite the code. There are ways that code can be written to promote this type of platform portability (for example, clearly separating code that drives the logic of game play and code that makes system calls), but you probably didn't write your assembly code with that in mind.

It may not be pretty, but the best solution is really to package your game with a DOS environment, like DOSBox, which is GPL-licensed. Other virtualization software would work, too. For example, VM VirtualBox with a VM running either MS-DOS or the GPL-licensed FreeDOS. As Ross Ridge says, this is what companies do that are selling their old MS-DOS games on GOG.com and Steam.

Matroclinous

Note that Intel CPUs beginning with Haswell are no longer fully backwards compatible in the sense that they lack the A20 gate. – Sulla

Thanks for pointing that out, @fuz. I'd missed that development in Haswell. I remember the rumors about how A20 had been removed in Nehalem, but that turned out to be a bit of exaggeration—it was just virtualized. – Matroclinous

Nice answer! And congrats on the diamond - it suits you! – Miquelmiquela