Dosbox Fun


Oh and Death Rally is a no go, 5000 cycles needed to play the menu music properly, ~15 000 cycles needed to play the game.
I thought the Cortex-A8 had some power, but if the pandora can't do more than 3000 cycles in dosbox (@600 Mhz) means either that it is per mhz much less efficient than my AMD sempron (in the task of running dosbox) (by a factor of 3 - i calculated that my sempron could do 9000 cycles at 600Mhz) or dosbox is unoptimized for the ARM. Hoping for the latter and that coders will optimize it to the max given time :)


There also other things that can effect it like are you using the x86 dynamic recompiler (its allows more performance than the arm recompilier will for the arm processors)
Dont compare clockspeeds, they really dont mean much. The only thing you could compare is the cycles capacity of the processor.
Cortex of course is going to underperform compared to a desktop processor.

Edit: Also look in ~/.dosbox, thats where the latest version 0.73 puts the conf. Also when you run dosbox it should tell you which conf at the location its using
 
Last edited by a moderator:
Perhaps running the sound emulation at its lowest rate might help claw back a little bit of runtime.
I gave Witchaven a try for a laugh, defaults and 2500 cycles offers about 1.3 seconds per frame, with an awkward menu.
Radix clocks in about 1.1 frames per second.
Terminal Velocity kinda crashed.

I shall try the latter two with lower details and lower sound emulation and see what happens.

Terminal velocity seems to work fine at the lowest quality settings at 3000 cycles, I'll turn it down to 2500 and see if that's still the case. Only complaint I have is that the keyboard is very sub optimal. But it is pretty smooth. EDIT: Seems to work fine at 2500 cycles.

Wacky wheels seems to work fine, I think it'll be a good one to play on the handheld. That hedgehog sitting on the toilet is absolutely brilliant.

Rise of the Triad registered seems to work well, which is suprising to me. I couldn't get lethal tender to work without frame skips at 3000 cycles.

And Commander Keen 4 works as well.

Most of that is as to be expected, I think that RoTT and TV might be a bit of a surprise, but they'll probably do fine, better with that joystick.

I'd consider posting videos, but I'm not sure it's really necessary and I'm not really sure how to do that.
 
Last edited by a moderator:
As an aside, I tried to test out Jazz Jackrabbit in DOSBox on my Ubuntu 9.04 box, but couldn't find any way to stop it from showing percentages and the like instead of the number of cycles. Has anyone else tried out Jazz, yet?
Pickle had done an earlier port of OpenJazz, so probably not much point in DOSBOXing it.

Assuming that OpenJazz supports all of the game's features yet, you're right. However, the last time I checked, it didn't. :/
@Pickle - I'm using 0.72. :) Moreover, I just have entries in my K Menu that point to particular games, as I find it quite convenient to be able to run them directly (so, say, Jazz Jackrabbit has a shortcut that has DOSBox run the executable from my games directory), so if it tells anyone anything, I never get to see it. :lol:


That aside, I have my report on Jazz CD's performance ready now... I did end up playing it for a while. :lol:

It runs playably (with incredibly minor moments of jerkiness) at 3000 cycles, with the soundcard (from setup.exe) set as Sound Blaster Pro with the audio quality set to "High Quality". Graphics-wise, "No Colour Animation" was set in the title screen setup menu, and the "Low Detail" setting was activated from the in-gameplay setup menu. Special Stages are sluggish unless you press F1 three times after entering one in order to set the graphical detail there to the lowest one available (which, on a screen the size of the Pandora's, probably isn't going to make much difference, so isn't a big deal :p).

This was with no frameskip, because DOSBox steadfastly ignored my pressing of the relevant keys for that. I reckon you could probably eke out more speed by changing the soundcard to a lower-class one, whilst not changing the audio quality from "High" (just bringing it down from "Ultra High Quality" made a huge difference, for what it's worth). :p

I'm happy to do more experimenting with this later to see how low I can take things whilst keeping the game experience a good one, if anyone would like. After all, getting to play more Jazz Jackrabbit can't be a bad thing. :lol:
 
Last edited by a moderator:
Dont compare clockspeeds, they really dont mean much. The only thing you could compare is the cycles capacity of the processor.
Cortex of course is going to underperform compared to a desktop processor.

Edit: Also look in ~/.dosbox, thats where the latest version 0.73 puts the conf. Also when you run dosbox it should tell you which conf at the location its using
OK, i just happened to run the 0.71 that i happened to have. (EDGE speeds dont really inspire me to upgrade very often).

Does core=dynamic (or auto) mean that it's using the dynamic recompiler? (assuming yes), would ARM performance be closer to core=normal?
-- tested Death Rally with core=normal,now even my sempron has problems running it properly, 15000 cycles, frameskip=1 and only some 7% idle (depends on scene ofcourse). (The processor is a 3 year old Sempron 2800+ - actually overclocked to 1.73Ghz (native 1.6Ghz) ... still not the brighest star in desktop processors nowadays...)
 
Last edited by a moderator:
Does core=dynamic (or auto) mean that it's using the dynamic recompiler? (assuming yes), would ARM performance be closer to core=normal?
-- tested Death Rally with core=normal,now even my sempron has problems running it properly, 15000 cycles, frameskip=1 and only some 7% idle (depends on scene ofcourse). (The processor is a 3 year old Sempron 2800+ - actually overclocked to 1.73Ghz (native 1.6Ghz) ... still not the brighest star in desktop processors nowadays...)

That information isn't easy to find, but apparently that's what the dynamic does, most of the time setting it to auto will be a better choice. Auto will switch to dynamic if it's the best choice, the option is there mostly for times when the auto function isn't working well. I guess a few games don't work as well with it.
 
Last edited by a moderator:
... still not the brighest star in desktop processors nowadays..."]
That information isn't easy to find, but apparently that's what the dynamic does, most of the time setting it to auto will be a better choice. Auto will switch to dynamic if it's the best choice, the option is there mostly for times when the auto function isn't working well. I guess a few games don't work as well with it.[/quote]But what im saying is that there are 2 dynamic methods. There is a C dynarec which the arm,mips, any non-x86 machine can use, and theres a special x86 only dynamic core. The x86 one can do more things to help performace since its x86 on x86.
But you cant compare cores on different processors. A x86 processor is going to be to do more cycles on any core setting compared to the arm processor on the same core setting.

The only thing that is constant is the cycle. The difference is the maximum amout of cycles a processor can do. The core settings are just a means to increasing the maximum amount.
 
Last edited by a moderator:
Interesting. Has the OMAP 3530 of the Pandora any Hardware) Processor Tricks, that can improve DOSBOX performance or is it only the pure "rough" Cycle Power that sets the Speed of Dosbox? I don't think that the SGX unit can do anything for DOSBOX but I'm not a coder. I know DOSBOX isn't the fastest "Emulator" on earth and not written with ARM in mind but maybe the OMAP has more surprises than we know. ^_^

Oh, anybody want to port a Frontend like the new "D-Fend reloaded"?
http://dfendreloaded.sourceforge.net/index.html?lang=en
 
But what im saying is that there are 2 dynamic methods. There is a C dynarec which the arm,mips, any non-x86 machine can use, and theres a special x86 only dynamic core. The x86 one can do more things to help performace since its x86 on x86.
But you cant compare cores on different processors. A x86 processor is going to be to do more cycles on any core setting compared to the arm processor on the same core setting.
The only thing that is constant is the cycle. The difference is the maximum amout of cycles a processor can do. The core settings are just a means to increasing the maximum amount.

Ah, I misunderstood that then. The number of cycles is after the processor has done it's thing and the dynarec for non-x86 is going to require more power than the x86 version for whatever number of cycles is necessary.

Not that I really doubt that you know what you're doing. I've seen more than enough to be suitably impressed already.
 
Last edited by a moderator:
Processor Tricks, that can improve DOSBOX performance or is it only the pure "rough" Cycle Power that sets the Speed of Dosbox?
My immediate thoughts are to offload the sound processing onto the DSP. In personal tests which involved me kind of guessing at how much faster it was (ie, totally accurate, right?) I found the FM sound engine to be one of the bottle necks. It relies on some floating point math that could probably have something done to improve performance.
Most programs I had running 2-3* times faster when it was rewritten to simply do nothing.

*most being World of Xeen, and 2-3 times meaning slightly faster
 
Last edited by a moderator:
I found the FM sound engine to be one of the bottle necks. It relies on some floating point math that could probably have something done to improve performance.
Most programs I had running 2-3* times faster when it was rewritten to simply do nothing.
*most being World of Xeen, and 2-3 times meaning slightly faster

The DSP idea would be a good approach, TI's GStream port might come in handy here. I know that one of the BeagleBoard guys already managed to harness the DSP through TI's GStream for decoding movies (don't know on which player though, probably mplayer).

Are there many games DOS games around that the difference in speed is substantial between sound on/off settings?
 
Last edited by a moderator:
I loathe that so many games need the CD/floppy in place to load. That's one thing that makes DOSBox so much less handy than it could otherwise be :(
I thought that DOSBox had an option to mount disk/disc images, nowadays? Or is that not useful for cases like these?
It does, but that's only useful if the CD (or floppy) doesn't have any clever "tricks" like unformatted sections or deliberately corrupted sections. if you can create a normal user-level copy of the disc and use that then you're fine - if you need to pull ANY stunts to make a backup disk then AFAIK DOSBox doesn't have a way to copy and then emulate the CD.

Or maybe it can emulate it if you've pulled tricks to copy it, and I just don't have the trick-pulling software :( but either way, I don't think I'm going to be playing X-Wing on my Pandora and Tomb Raider 1 looks equally unlikely at this stage. I think. tho Tomb Raider probably has an open-source clone by now so I may just need to copy some data :)
 
Last edited by a moderator:
It just occured to me that the current speeds that a lot of these games are running at would be virtually identical to when I was playing them at home on my 486dx. I remember trying ecstatica and even playing it in slow motion... It's funny how things come full circle
 
Or maybe it can emulate it if you've pulled tricks to copy it, and I just don't have the trick-pulling software :(
I really only have a couple of MS-DOS games, and neither have any anti-customer nonsense going on, luckily for me, so all I've had to do is copy the contents of the CD-ROMs to my hard drive.

I totally didn't realise that that stuff would present a problem. I must've had a daft pill when I responded, or something. :lol:

QUOTE
but either way, I don't think I'm going to be playing X-Wing on my Pandora and Tomb Raider 1 looks equally unlikely at this stage. I think. tho Tomb Raider probably has an open-source clone by now so I may just need to copy some data :)

Well, there's always the PlayStation version of Tomb Raider... X-Wing, I have no idea about.
 
Last edited by a moderator:
I found the FM sound engine to be one of the bottle necks. It relies on some floating point math that could probably have something done to improve performance.
Most programs I had running 2-3* times faster when it was rewritten to simply do nothing.

*most being World of Xeen, and 2-3 times meaning slightly faster
Sounds like DOSBox needs a less demanding OPL2 emulator. jEnesisDS pulls off OPN2 (YM2612) on a 33MHz ARM7TDMI, and that's a much more intensive FM. The emulation is far from bit perfect but it still sounds pretty good. Possibly some compile time options to reduce sound quality for lower end ports would be in order.

Not that porting to the DSP wouldn't be viable, it'd just be a pain.

Surely the number one focus should be on improving the qualtiy of the ARM output, good luck with that though. I wonder when PC games started using floating point regularly...
 
Last edited by a moderator:
I found the FM sound engine to be one of the bottle necks. It relies on some floating point math that could probably have something done to improve performance.
Most programs I had running 2-3* times faster when it was rewritten to simply do nothing.

*most being World of Xeen, and 2-3 times meaning slightly faster
Sounds like DOSBox needs a less demanding OPL2 emulator. jEnesisDS pulls off OPN2 (YM2612"] on a 33MHz ARM7TDMI, and that's a much more intensive FM. The emulation is far from bit perfect but it still sounds pretty good. Possibly some compile time options to reduce sound quality for lower end ports would be in order.

Not that porting to the DSP wouldn't be viable, it'd just be a pain.

Surely the number one focus should be on improving the qualtiy of the ARM output, good luck with that though. I wonder when PC games started using floating point regularly...[/quote]Dont forget a version for the gp2x has the opl offloaded to the second core. If we could redo the memory interface between dosbox and the opl binary couldnt we use it again? Theres a C complier for the DSP right?
 
Last edited by a moderator:
Dont forget a version for the gp2x has the opl offloaded to the second core. If we could redo the memory interface between dosbox and the opl binary couldnt we use it again? Theres a C complier for the DSP right?
Yeah, there's a C compiler..

Unless something has happened that I'm not aware of there's still work that needs to be ported to the Pandora Linux build in order to get DSP bridge working. It's a pretty detailed setup and procedure that is not the easiest thing in the world to get working. But it really should be done regardless of whether or not it's used in DOSBox.

Personally I wasn't aware of such a version of DOSBox.
 
Last edited by a moderator:
Back
Top