DOS Emulation Under Linux - a Simple Guide 299
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."
Keen!! (Score:5, Interesting)
-Cyc
Re:And if DOSemu doesn't work for some reason . . (Score:2, Interesting)
---
Re:Duke Nukem 3D (Score:5, Interesting)
By the way, does anyone know if there is a free program like DOSEMU/DOSBox for MacOS?
Re:Duke Nukem 3D (Score:4, Interesting)
PCEmu (Score:3, Interesting)
Re:Oh no (Score:2, Interesting)
Scorched Earth (Score:2, Interesting)
The author of the guide says he used to play Scorched in his Sixth Form, and the network admin would join in too... exactly like in my school! This game must have been more popular than I first thought. If you've never played it, you really should...
Re:PCEmu (Score:5, Interesting)
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.
Re:PCEmu (Score:3, Interesting)
In fact, dosemu already had some interesting possibilities for saving memory. I wrote the network driver for dosemu, it emulates a "PC/TCP packet driver". In a normal DOS system, that driver would be loaded in high memory, but in dosemu there was only a small block of code residing in the BIOS area (required because of the interface definition for packet drivers), and the actual driver code is 32bit.
So, dosemu can be considered to have "PC/TCP packet driver support in the BIOS", and no memory has to be wasted on loading a driver
A lame question, but... (Score:3, Interesting)
Maybe I can put that stack of floppies to use (Score:2, Interesting)
Right now, I've got a huge box full of old floppies for Dune, ChessMaster, Wolfenstein, and a bunch of other old games that I spent way too much money on, considering all they can do now is collect dust.
Now if they only had an emulator for the Win95 games that no longer work in 2000/XP... Somebody aught to support these commercial products that no longer have an OS to run on!
Possible to get full VESA or 'x' video card? (Score:2, Interesting)
The reason I ask is for the old venerable OrCAD 386 SDT and PCB programs... 800x600 just doesn't cut it, and that old program is still way ahead of what they've put out today in terms of ease of use, functionality and keyboard support.
I know about Eagle's cross-platform abilities and all the other win32-only ones but to be honest, none of them seem to have that right mix of keyboard use, navigation and plain old workability. I'm rapidly running out of systems that OrCAD 386 will run on. :-(
Re:Now if only Windows could do the same thing, ri (Score:2, Interesting)
ok, it's not a big deal to install it (Score:2, Interesting)