Why is DOSbox so slow?

Being a software guy (and not one that deals in emulation code) and not really a hardware guy, can anyone explain to me why DOSBox is so slow?

If I have a 3000 MhZ computer trying to emulate a 133 Mhz computer, why does it slow it down so much? Certainly it seems you should be able to emulate the OS and IO calls of the old system on the speedy new systems of today. The PS2 emulates the old PS games. The 360 emulates the XBox.

Yet time and again, all the old games stutter and the sound doesn’t work.

not that I’m not grateful for the people who created it, but why, technically, isn’t it faster?

The PS2 doesn’t emulate PS games. The PS2 has a PS1 inside of it.

DOSBox is essentially a 486 emulator. If you have a fast CPU, then it is essentially a fast 486 emulator. If you’re trying to run mid-90’s/early Pentium software, you’re not going to be that happy even if you have a supercharged system.

Besides, DOSBox is more than just a dos prompt emulation. It does the wonky DOS memory management (which is a job in itself). It does a bunch of sound card emulation. It does cdrom emulation. Etc. Etc.

It must also be tweaked. The default settings won’t get you anywhere.

On my AMD3K system, early 90’s stuff runs like a scalded feline. I’m even able to get some fairly advanced stuff like Terminal Velocity & System Shock running OK. Magic Carpet runs well, too.

I keep meaning to look into the DOSBox code and see what they are actually doing.

My guess is that they are doing a software emulation of the x86 since with the older esoteric modes, and lack of virtualization support on earlier x86 processors, I’m really not sure you can actually take advantage of the fact that you’re running on the same processor family. I don’t know if Vanderpool will be a help in that regard.

The PS2 emulation relied on having the same main CPU (a 33Mhz R3000 variant) as the PS1 available in the PS2. In the PS2 it was called the IOP and used as an I/O processor when not in PS2 emulation mode.

Microsoft could also afford to throw a couple million dollars in high-priced engineering time at their emulator. I’m not sure there is a whole lot of x86 on x86 emulation work for DOSBox to leverage.

Try setting the cycles higher, to say 9000. Also, make sure you have the sound settings correct. You can change both in the config file. These two links might help you:



DOSBox is emulating a PC right down to the CPU, instead of running the code natively. That’s good, since it lets DOSBox work on non-Intel systems, but it does make it slower. Every emulated instruction is going to take at least a handful of native instructions to emulate, and that alone divides the processing speed considerably.

You can speed things up by using sophisticated techniques to ‘convert’ from one instruction set to the native one, or run it natively if it’s the same, but DOSBox just doesn’t do these things yet.

Edit: Beaten so hard, but I’ll at least add that running natively isn’t necessarily good either, since then you’re running at the full processor speed and a lot of the old programs you’ll be trying to use will run into problems with timing loops. Emulating the instruction set lets them limit the processing rate so you can effectively get close to a specific clock rate. A lot of old games only worked if you, say, had exactly a 16MHz processor and were unplayable otherwise.

Shit, that was a LOT of tech geek over a nine minute span.

Which is why a ton of computers as we moved into the 286 and 386 age of processors had the “Turbo” button. By turning the “turbo” off, the processor could be slowed down to the 8MHz of the 8086 and 8088 so you could run the legacy programs that relied on the exact timing of the older processors. At least that’s what I remember, but there is probably a better and more detailed explination.

Dosbox is not only emulating the CPU, it is emulating the co-processors of every component in the system: The Yamaha OPL3 for Adlib music, the Creative codec for 8-bit audio, the VGA chip for graphics, the IDE controller for disk access. All of these processors that work independently are now being serialized through your computer’s CPU. The sum total of these parts is much greater than the mere 133MHz CPU you’re emulating.

Wow, I never turned off my turbo button. I always thought “What’s the point?”

Because emulation is not virtualization.

DOSBox is never going to have x86 virtualization support because it values portability and being future-proof over being fast.

If sound doesn’t work, you probably haven’t configured something right. If the games are too slow, either turn up your cycles or get a faster CPU, or wait for a faster CPU to be invented.

Why DOSBOX is cool:

By chance any of you able to get Wing Commander 3 to run under DosBox? More specifically, I can get the movies to play fine but the actual game play is jerky as hell no matter what speed settings I use. Interestingly the simulator on the Victory plays just fine, but the actual missions are fudged up somehow.

can you point me in the direction of a guide or FAQ that qill tell me how to tweak it? Im particularly interested in getting system shock to run at least moderately. As it stands its unplayable

I also had the molasses syndrome when trying to play Arena using it. I didn’t mind the crap graphics, but the slow motion emulation made me nausiated.

Each system needs to be tweaked individually for each game so there are no magic codes to hand around.

Adjust your cycles (both up and down), add or remove a frameskip, adjust sound, adjust memory, adjust, adjust, adjust until you get something good.

Unless you are playing late 486/early pentium games, or it is listed at the DOSbox site as unworkable, you ought to be able to find a workable configuration.

If you don’t already have a front end program for DOSbox, get one.

I’d reccomend DFend as a great Windows front end to DOSbox. Tons of flexability, and lets you create separate profiles and settings for each game and makes them easy to launch.

For what it’s worth, emulating the CPU instructions and making it very fast is relatively straightforward. You can even implement a compiler for it and translate code to run natively on another platform. Not that big of a deal, it’s a compiler like any other.

Things get hard when we need to emulate more than just the core CPU instruction set, though. Real code tends to rely on subtleties of instruction timing, external input timing, etc., that’s much trickier to emulate in such a way that it’s functionally equivalent to running on the real hardware. Add in emulation of peripherals, on-chip and off chip, memory management, external devices, etc, and the complexity of the problem expands very, very quickly. It’s still a tractable one, but it’s not easy and getting good performance out of the system while maintaining correctness is an art.

System Shock can run natively on WinXP with patches & tweaks. See this thread for links and discussions.

http://vogons.zetafleet.com/ has lots of advice on getting pre-Win95 stuff to run. Site loads slow as hell, though.