Dosbox - room for optimization?

[Esn]

Good gracious... I must admit, I haven't had much time to put into Keens 4 to 6 since around Hotfix 3 and Hotfix 4 - what happened?! They used to run damn-near perfectly. :blink: Esn, I must confess, I am baffled - I don't know what changed.


If you're using Xfce, have you tried running Background Killer prior to trying to run those games? (If it's not still around, I kept a copy handy. Let me know if you want it.)

They were slow for me in Hotfix 4 as well (I never did try them in HF3). If I really want to get the most speed, I overclock in minimenu then run the background killer (I do have it, yes). That way, they run pretty close to fullspeed - though there's still the occasional stutter, but not nearly as often.

 

[Exophase]

Most emulators that are ported to handhelds aren't further optimized, or aren't a whole lot. When you see high performance emulators it's usually because someone rewrote a lot of it (or wrote all of it). You shouldn't get your hopes up too much that someone will tweak it to be more than marginally faster.


The ARM recompiler itself was originally made for handhelds like GP2X, but it's a fairly simple implementation of the reference framework in DOSBox. So I'm sure it has a lot of room for improvement, but that might not be the full extent of the bigger performance deficiencies.


One thing that always kind of bothered with DOSBox is the whole deal with setting "cycles." This makes it like most console emulators, in that they emulate something with fixed timing characteristics, but unlike those the intention of DOSBox isn't to emulate a fixed platform but a kind of virtual one. So you end up in a constant hassle of trying to pick a cycles value that's suitable for the game's internal speed to be high enough while also keeping the external speed high enough.


An alternative is to not have cycle counting at all, and instead handle events like timer and vsync interrupts asynchronously and in real time. Then the x86 emulation and other components get as much work done as possible. Another plus is not spending the time actually counting the cycles. This method can sometimes cause software to break outright instead of just not run, but since DOS software was meant to run on a variety of hardware it shouldn't usually be this sensitive. It's also harder to debug (since execution isn't deterministic anymore), which is why I guess you'd want to have an option to still cycle count.


Then again, I don't know what the "auto" setting on DOSBox actually does, I've kind of been assuming it isn't this.


DSx86 works like this, and considering the hardware it appears way more efficient than DOSBox. And it's not actually using a dynarec at all.

 

[Prometheus]

An alternative is to not have cycle counting at all, and instead handle events like timer and vsync interrupts asynchronously and in real time. Then the x86 emulation and other components get as much work done as possible. Another plus is not spending the time actually counting the cycles. This method can sometimes cause software to break outright instead of just not run, but since DOS software was meant to run on a variety of hardware it shouldn't usually be this sensitive. It's also harder to debug (since execution isn't deterministic anymore), which is why I guess you'd want to have an option to still cycle count.

I know this is a dumb question, but where would really old software that ends up running ludicrously far-too-fast be left by something like that? My experience with DOSBox as it is, is that running some games depends on cranking the cycles really low so that they don't go above the speed they're supposed to. (An example would be Mega Man and Mega Man 3 for MS-DOS. Yes, it's a Mega Man-related example, but that's what you're likely to get from me. )


I mean, I know you can mess with patching the original files, or obtaining and running some software or other that's supposed to slow things down on hardware above certain speeds, but I do find it much more convenient to be able to just tweak it in the emulator without having to mess with anything else.

 

[Exophase]

I know this is a dumb question, but where would really old software that ends up running ludicrously far-too-fast be left by something like that? My experience with DOSBox as it is, is that running some games depends on cranking the cycles really low so that they don't go above the speed they're supposed to. (An example would be Mega Man and Mega Man 3 for MS-DOS. Yes, it's a Mega Man-related example, but that's what you're likely to get from me. )

I mean, I know you can mess with patching the original files, or obtaining and running some software or other that's supposed to slow things down on hardware above certain speeds, but I do find it much more convenient to be able to just tweak it in the emulator without having to mess with anything else.

I'm always amazed that so much of the original DOS games out there expects fixed time delays by running a loop for some fixed number of iterations. Fortunately this should have largely stopped being a problem once PCs became diverse enough and games required more than original 8086's. Or maybe the truly awful examples didn't really care if they ran at different speeds depending on the machine. But I expect that the higher requirements get, the less you see this..


So keeping in an option to throttle to a certain number of instructions per second (or whatever) would cost overhead in cases where you can probably spare it.


Another option, that's more of a gross hack but simpler to maintain, is to slow the emulator itself down. So that every frame (or whatever) it stops emulation for some period of time so it doesn't use more than a certain percentage of host CPU time. The tricky part with this is that to achieve the asynchronous approach at all you need the emulation and real-time events to happen in separate threads, so you have to have some mechanism of remotely putting the emulation thread to sleep. Since you need to be able to alert it anyway for interrupts (and it has to have points where it checks to see if it's alerted) you could make it go to sleep when it sees an alert telling it to.


The disadvantage there is that the values would change depending on what you're running DOSBox on, and might not be totally stable at that, but it should largely work.

 

[WizardStan]

An alternative is to not have cycle counting at all, and instead handle events like timer and vsync interrupts asynchronously and in real time.

I was under the impression that this is mostly what DosBox did when setting cycles to max. I don't know where I got that idea from and may have been entirely mistaken though.

 

[Exophase]

I was under the impression that this is mostly what DosBox did when setting cycles to max. I don't know where I got that idea from and may have been entirely mistaken though.

The documentation doesn't really say what it's doing besides "using as many as it can", but the impression I get is that it's still using cycle counting, but changing the value depending on how much idle time it detects when it throttles. I don't know if this is a static or dynamic thing either, but it doesn't quite use 100% CPU time so I don't think it's actually dropping cycle counting or throttling. Which means it still has the overhead of counting, as well.

 

[ZXDunny]

So keeping in an option to throttle to a certain number of instructions per second (or whatever) would cost overhead in cases where you can probably spare it.

I was wondering if some sort of mechanism like idle-loop detection might be able to help with this? Obviously not in 100% of cases, but some investigation of what these games are expecting may give some clues what opcode-layout to search for, and have the emulator modify speed if they're found.


D.