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?
Yes. Any general-purpose programming language, including assembly languages, can be used to develop any type of software, including games. In the early days of personal computing, games were commonly developed in assembly language.
Start Emu8086 by selecting its icon from the start menu, or by running Emu8086.exe. 2. Select "Samples" from "File" menu.
The assembly level programming 8086 is based on the memory registers. A Register is the main part of the microprocessors and controllers which are located in the memory that provides a faster way of collecting and storing the data.
8086 Microprocessor Emulator, also known as EMU8086, is an emulator of the program 8086 microprocessor. It is developed with a built-in 8086 assembler. This application is able to run programs on both PC desktops and laptops. This tool is primarily designed to copy or emulate hardware.
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.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With