Dosbox Speed

[1magus]

After reading through various posts, I have found that DosBOX will run on Pandora but wont be very fast. Now I was wondering through future updates will it get much faster and have greater compatibility or is it at the speed it will always run at and don't expect anything great in the future?

 

[mali]

Ask that Delorean guy from Australia

edit: Status quo

As this is relevant I'll paste it here from a previous DOSBox related thread

4000-5000cycles @850MHz with dynarec

That 2000 number I had in mind was old info(no overclocking/dynarec)

Main issue is with the C dynarec in dosbox is that it is not a full dynarec, it only recompiles certain operations, whereas if you had a full dynarec you would be recompiling more operations. At least thats how ive come to understand it.

Gp2x : 800-1000 cycles with dynarec
Pandora: 4000-5000 cycles with dynarec

So the hardware is definitely providing a good amount performance over the Gp2X.
The MIPS backend may be more efficient in recompiling x86 code than ARM is. Although I dont claim to know all the details, someone like exophase/M-HT can probably give some insight into why the difference in performance is there.

How many cycles are typical on the PSP?

M-HT did several other updates to the ARM recompiler work he did. He also said he's interested in working on it on Pandora once it's out, but that was months ago. You can find out more here:

http://forum.openhandhelds.org/viewtopic.php?f=24&t=931

 

[1magus]

Is there a list of compatibility when it comes to cycles in Dos Box. Like Game XXXX requires XXXX amount of Cycles?

 

[TrashyMG]

Is there a list of compatibility when it comes to cycles in Dos Box. Like Game XXXX requires XXXX amount of Cycles?

Not really but what I gathered from some I think Dosbox on the pandora generally runs about 386DX / 486SX 25mhz like speeds.. Please correct me if I'm wrong, just going by what I've seen on the Youtube videos and such.

 

[WizardStan]

Not really but what I gathered from some I think Dosbox on the pandora generally runs about 386DX / 486SX 25mhz like speeds.. Please correct me if I'm wrong, just going by what I've seen on the Youtube videos and such.

As a general rule, that works. I have encountered a few games that say they work on a early model 386, but aren't very playable at 5000 cycles, so it's not a perfect comparison.
The best part about DosBox is that a cycle is a cycle no matter what architecture you're using. You can install DosBox on your PC right now and set it to 5000 (actually, keep it on the low end, at 4000) cycles and see if your game runs. Or boost it until it does run, see what kind of improvement would be needed before it could be played.

 

[Exophase]

As a general rule, that works. I have encountered a few games that say they work on a early model 386, but aren't very playable at 5000 cycles, so it's not a perfect comparison.
The best part about DosBox is that a cycle is a cycle no matter what architecture you're using. You can install DosBox on your PC right now and set it to 5000 (actually, keep it on the low end, at 4000) cycles and see if your game runs. Or boost it until it does run, see what kind of improvement would be needed before it could be played.

Just because "a cycle is a cycle" doesn't mean that X "cycles" will take the same time to emulate across all contexts. Game A's typical 5000 cycles might take 0.5ms to emulate, while game B's might take 2ms; instruction emulation time is going to vary a lot. This common knowledge that "Pandora emulates 4000-5000 cycles" seems dangerous to me.

I recall DOSBox having an "auto" option - I don't know how this works, but if it can detect idle loops with any degree of success then it'd be best in these cases to synchronize next events on idle loops and only have a really high frame threshold.

 

[WizardStan]

Just because "a cycle is a cycle" doesn't mean that X "cycles" will take the same time to emulate across all contexts. Game A's typical 5000 cycles might take 0.5ms to emulate, while game B's might take 2ms; instruction emulation time is going to vary a lot. This common knowledge that "Pandora emulates 4000-5000 cycles" seems dangerous to me.

I was not aware of that. Isn't a cycle a measure of emulated time over real time? I can see where you're going, but I was previously under the impression that it was a lot more stable than what you're implying. If one instruction takes more time to emulate than another, then it takes more cycles as well, or so I thought. I could have been completely wrong about that this entire time, and if so, I apologize.

 

[1magus]

so there currently is a problem with programming dosbox atm?

 

[WizardStan]

so there currently is a problem with programming dosbox atm?

No problem. Why would you think that? There may still be lots of room for improvement, but that will happen over time as more people (in theory) look at it)

 

[Exophase]

I was not aware of that. Isn't a cycle a measure of emulated time over real time? I can see where you're going, but I was previously under the impression that it was a lot more stable than what you're implying. If one instruction takes more time to emulate than another, then it takes more cycles as well, or so I thought. I could have been completely wrong about that this entire time, and if so, I apologize.

A cycle refers to one emulated clock cycle. Usually when emulating a CPU, you make each instruction take the same number of emulated clock cycles that the original would to emulate a given cycle. With more complex CPUs this number can be very dynamic and complex, so the number of cycles emulated may not be very accurate. DOSBox's goal is to emulate an x86 "platform", rather than any particular x86 CPU, but it still needs to emulate cycles in order to synchronize emulation of all components of the system and put an upper bound on how long any single component will be emulated before emulating other components. So it makes the simplest (and fastest) decision and for the most part makes every emulated instruction take one cycle.

No real x86 CPU will be like this. An 8086 will be several times slower per clock cycle, while a Core 2 would be significantly faster.

So if you compare instructions like say:

nop
lea eax, [edx + ecx]
add ecx, [eax + 0x80007890]
div esi

They'll all take hugely different amounts of time to emulate (from fastest to slowest), but will all cost 1 cycle.

Even if the cycle emulation did match a real x86 CPU some cycles would still cost far more to emulate than others, due to differences between emulation and hardware. Things just won't scale the same.

 

[lobski]

Would it be safe to assume that it'll most run 486-era games, and 133-era games will be very difficult to run at playable clips?

 

[Pickle]

As a general rule, that works. I have encountered a few games that say they work on a early model 386, but aren't very playable at 5000 cycles, so it's not a perfect comparison.
The best part about DosBox is that a cycle is a cycle no matter what architecture you're using. You can install DosBox on your PC right now and set it to 5000 (actually, keep it on the low end, at 4000) cycles and see if your game runs. Or boost it until it does run, see what kind of improvement would be needed before it could be played.

Just because "a cycle is a cycle" doesn't mean that X "cycles" will take the same time to emulate across all contexts. Game A's typical 5000 cycles might take 0.5ms to emulate, while game B's might take 2ms; instruction emulation time is going to vary a lot. This common knowledge that "Pandora emulates 4000-5000 cycles" seems dangerous to me.

I recall DOSBox having an "auto" option - I don't know how this works, but if it can detect idle loops with any degree of success then it'd be best in these cases to synchronize next events on idle loops and only have a really high frame threshold.

A cycle should be a cycle no matter how long it took, the host machine and the emulation settings will only effect the maximum cycles that can achieved. Of course taking your points the max can change given the running processes. What i mean is something that needs a pentium and all the special sound cards is going to need more emulation process time (resutling in less max cycles) than say a 286 with speaker sound.

If im running the same app on both setups the same number of cycles on both is the same speed in the emulation machine, although of course my PC can do things faster and has lots of left over time. Another example is selecting different cpu cores dynamic vs normal, as long as the host can provide X cycles in normal, switch to dynamic will also give X cycles, but there would just be left over process time.

 

[Exophase]

A cycle should be a cycle no matter how long it took, the host machine and the emulation settings will only effect the maximum cycles that can achieved. Of course taking your points the max can change given the running processes. What i mean is something that needs a pentium and all the special sound cards is going to need more emulation process time (resutling in less max cycles) than say a 286 with speaker sound.

If im running the same app on both setups the same number of cycles on both is the same speed in the emulation machine, although of course my PC can do things faster and has lots of left over time. Another example is selecting different cpu cores dynamic vs normal, as long as the host can provide X cycles in normal, switch to dynamic will also give X cycles, but there would just be left over process time.

That isn't the point. Something that runs fine at 5000 cycles on PC will indeed run fine on Pandora, except "running fine" may occur over 1.5ms instead of 1ms, and therefore it'll still be 66% the speed. Meanwhile, something else might run poorly at 5000 cycles but could be running great at 8000 - maybe it's doing more reg/reg instructions than usual and at 5000 cycles the Pandora might only need 0.5ms, but is spending the other 0.5ms sleeping because that's what you told it to do.

The point is that you can't say that X cycles is "what the Pandora can do", it depends too much on the game.

 

[Prometheus]

Bearing in mind that it depends on the game (I already know that's a given), is there any feasible way of getting a rough idea of how something might run on Pandora-DOSBox by messing with DOSBox cycles on a desktop/whatever, at all? A ballpark estimate, if you will. Or should that idea just be thrown out of the window?

(I'm just idly curious, by the way. )

 

[Exophase]

I would say do this: go with the original ~4500 suggested, but look at the percentage CPU time DOSBox is using. Over all of the games you test find the average CPU time used, then scale the number of cycles against deviation from the average. This should give some indication of capable cycles if the Pandora scales in CPU usage anything like your CPU does. It'll still be pretty off, but it'll be better than just going with 4500 cycles suggested.

EDIT: Actually, rather than scaling the number against total CPU time you'd have to first test at two different cycle points (per game) to find how much of the CPU time is spent in cycle emulation.

So something like this:

game A: 10% @ 4000 cycles, 11% @ 5000 cycles
game B: 25% @ 4000 cycles, 27% @ 5000 cycles
game C: 8% @ 4000 cycles, 8.3% @ 5000 cycles

A: 1% over 1000 delta-cycles, 4000 = 4%, 5000 = 5%, 4500 = 4.5%
B: 2% over 1000 delta-cycles, 4000 = 8%, 5000 = 10%, 4500 = 9%
C: 0.3% over 1000 delta-cycles, 4000 = 1.2%, 5000 = 1.5%, 4500 = 1.35%

Average @ 4500: 4.95%
A deviation: 110%
B deviation: 55%
C deviation: 366%

A adjusted cycles: 4950
B adjusted cycles: 2475
C adjusted cycles: 16470

Of course, these numbers are exaggerated for illustration purposes.

 

[Prometheus]

Righty-o. Thanks much.

 

[Pleng]

Would it be safe to assume that it'll most run 486-era games, and 133-era games will be very difficult to run at playable clips?

if clips=speed, then yes it's safe to assume that.

 

[Namo]

There's a short-cut command in Dosbox (I think its something like control-F11) that changes the amount of CPU Cycles, so, if you have a slow game, just add cycles.

 

[Exophase]

There's a short-cut command in Dosbox (I think its something like control-F11) that changes the amount of CPU Cycles, so, if you have a slow game, just add cycles.

Or, if you're at 100% CPU utilization (on the core DOSBox is running on) lower cycles instead.

 

[Namo]

Yup, Dosbox really is a great little program! We have something to thank Microsoft for. If it wasn't for their idiocy in discontinuing DOS in later versions of Windows, than no one would have made DosBox and we wouldn't be able to run DOS games on a Linux-based Handheld!