DOS Emulation Under Linux - a Simple Guide

David Precious writes "With just a little work, it's possible to get your Linux system to run DOS applications with very little trouble. Whether you need to run some legacy corporate application, or just want to play some of those old classic DOS games, it's easy to get going. To make it easy, I've produced a simple guide to explain it. Hopefully it'll be of use to some people."

Comments

Re:Duke Nukem 3D

[n3k5]

*i* couldn't get dn3d to run on dosemu+freedos, but it may be possible, particularly if you use, say, MSDOS 6.2 instead of freedos.

DOSBox claims to run Duke Nukem 3D.

By the way, does anyone know if there is a free program like DOSEMU/DOSBox for MacOS?

Re:PCEmu

[kasperd]

I'm curious to know what are those 16 bytes in the ROM...must have been highly optimized :)

The trick is, that when writing an emulator, you don't need to write a BIOS in 16 bit code. Instead a BIOS implementation is written in 32 bit code, that can execute outside the precious low end address space. Then I just need enough entry points from 16 bit code to 32 bit code. An entry points requires an instruction that will trap from virtual 86 mode to 32 bit user mode. I decided to use the HLT instruction which is only one byte. Because of the segment:offset addressing there are 4096 different ways to address this single byte, that means I have 4096 entry points which is a lot more than I need. The entry point for reboot is sometimes accessed through at least two different addressings, so I avoided to place my HLT instruction there and instead placed the conventional five bytes long far jump instruction there, which jumps to one of my entry points. After this five bytes instruction are eight bytes reserved for the BIOS date written as month / date / year. The last three bytes are three single byte instructions HLT IRET RETF. The HLT and IRET are actually used, the RETF I just placed there because it might come in handy. Because of the DOS memory management and the reboot entry point, there is no way to make the ROM smaller than 16 bytes.

To actually protect the ROM against writing I mark the entire page read only, though it is only the last 16 bytes I really need to protect. This means any write to the first 4050 bytes of this page will trap, those are the traps that I needed to fix in the kernel because they would Oops if triggered by a stack access by an instruction emulated in the kernel. All those traps of course slows down execution, so I might want to sacrifice the last 4050 bytes for a bit of performance. I'm still looking for an efficient way to access the last bytes. If I could put an upper limit to the address accessed by virtual 86 mode, I could switch between a limit just below the ROM and a write protected page, which I belive would speed up execution. Together with my emulator I have put a GPL'ed UMM driver that works with my emulator, quite conveniently this driver does not support the last 4050 bytes of UMB that have been causing problems anyway. EMM386 doesn't work with my emulator, and never will because of braindead Intel design.