Dosbox 0.72 Pre-release Info

[Rivroner]

How fast is running with sound Alone in the Dark? Thank you

I don't know how it was on the previous version (it didn't run on my F200), but on this version, without overclocking, I guess it runs at about 8-10fps with sound, is playable if you are a very patient person B)


Thanks for the answer

SO, if we overclock to 266 maybe is playable at all

 

[Qbix]

Well Im very close to releasing a version of dosbox for the GP2X.

1. I have made a couple memory saving changes. I have found many of the crashes users experience are a result of being "out of memory". All games/programs tested seem to run. I havnt heard or tried anything that doesnt run.
2. I have profiled the code, seems to give the expected 20% increase in speed.
3. I have compiled in DJWillis SDL touchpad code (there is still work to do in this area)

The touchpad does work, just not ideal. Once we explore this some more the new version will be made public.

I can run many EGA/PC Sound games like duke nukum at 200 Mhz. I have played stunts on the lowest settings and it was playable to some degree. It seems in general some vga titles can run decently with no sound.

Looking forward to seeing it. (the code as I don't own a GP32)

for the Nokia N8x0 port there were some bugfixes done with regard to unaligned acces when dealing with the
vga emulation. I don't know if the GP2x would benefit from those as well.

From the psp port we recieved a patch which adds a banked tlb. This reduces the memory footprint of dosbox
as well. It might be an idea to look at that if you are short on memory.

Memory. Yes There are some points where you can decrease the size of certain tables. I don't know if there are really redundant memory allocations in the DOSBox code, but I will study the changes you have made.

You might want to lower the default samplerates of all sound devices to 11025.
the opl emulation is quite heavy for handhelds and is awful for any caching the system might have done.

Good luck,

Peter
(DOSBox Author)

 

[gruso]

^ Respect to that man! You've contributed much joy to our household.

 

[Pickle]

Well Im very close to releasing a version of dosbox for the GP2X.

1. I have made a couple memory saving changes. I have found many of the crashes users experience are a result of being "out of memory". All games/programs tested seem to run. I havnt heard or tried anything that doesnt run.
2. I have profiled the code, seems to give the expected 20% increase in speed.
3. I have compiled in DJWillis SDL touchpad code (there is still work to do in this area)

The touchpad does work, just not ideal. Once we explore this some more the new version will be made public.

I can run many EGA/PC Sound games like duke nukum at 200 Mhz. I have played stunts on the lowest settings and it was playable to some degree. It seems in general some vga titles can run decently with no sound.

Looking forward to seeing it. (the code as I don't own a GP32)

for the Nokia N8x0 port there were some bugfixes done with regard to unaligned acces when dealing with the
vga emulation. I don't know if the GP2x would benefit from those as well.

From the psp port we recieved a patch which adds a banked tlb. This reduces the memory footprint of dosbox
as well. It might be an idea to look at that if you are short on memory.

Memory. Yes There are some points where you can decrease the size of certain tables. I don't know if there are really redundant memory allocations in the DOSBox code, but I will study the changes you have made.

You might want to lower the default samplerates of all sound devices to 11025.
the opl emulation is quite heavy for handhelds and is awful for any caching the system might have done.

Good luck,

Peter
(DOSBox Author)

The only game ive tried so far that didnt run right was wolf3d. The ingame graphics were garbage.

I did shrink the TLB table as suggested in the PORTING doc. We could try and move that to the upper 32 mb, but I dont see the benefit? The only negative was a possibility of protected mode games? Everything ive ran and the testers have ran has worked. If its newer protected mode games, would they run anyway with the current speed.
I also shrunk the drive/folder cache, didnt seem to effect anything. I did have the GUS removed, but just added it back in.
The TLB was the big one at a 15mb worth of saving memory. Ive allocated up to 10 mb in the dosbox.conf. I think 8 mb would be the max anyone really needs.

Qbix, another area where we might get some more performance is in the game resolution. The GP2X has a 320x240 res. As you know dosbox defaults to 640x400, we have our SDL scale that down to 320x240. So for games that 320x200, dosbox scales up and then the GP2X scales back down. Is there a good way to cut this out and just have dosbox scale at 320x200?

 

[Qbix]

The only game ive tried so far that didnt run right was wolf3d. The ingame graphics were garbage.

I did shrink the TLB table as suggested in the PORTING doc. We could try and move that to the upper 32 mb, but I dont see the benefit? The only negative was a possibility of protected mode games? Everything ive ran and the testers have ran has worked. If its newer protected mode games, would they run anyway with the current speed.
I also shrunk the drive/folder cache, didnt seem to effect anything. I did have the GUS removed, but just added it back in.
The TLB was the big one at a 15mb worth of saving memory. Ive allocated up to 10 mb in the dosbox.conf. I think 8 mb would be the max anyone really needs.

Qbix, another area where we might get some more performance is in the game resolution. The GP2X has a 320x240 res. As you know dosbox defaults to 640x400, we have our SDL scale that down to 320x240. So for games that 320x200, dosbox scales up and then the GP2X scales back down. Is there a good way to cut this out and just have dosbox scale at 320x200?

If you allready have 8 mb available then there is little to gain. If there will ever be a dynrec core then you will need more memory as dynrec requires quite a bit for the translated code.

The drive cache thing only kicks in when you mount directories (with lot's of entries) and the game does a lot of searches for files. Those have to be cached as they can be resumed.

The scaling. Have you disabled the normal2x scaler in the configurationfile(or in src/dosbox.cpp) ? That one is responsible for the upscaling of 320x200 =>640x400

be sure to run with core=simple. (and maybe try with core=full as well as that one is small and thus cache friendly)

 

[Pickle]

The scaling. Have you disabled the normal2x scaler in the configurationfile(or in src/dosbox.cpp) ? That one is responsible for the upscaling of 320x200 =>640x400
be sure to run with core=simple. (and maybe try with core=full as well as that one is small and thus cache friendly)

I see where its defaulted as normal2x. We also could set it to none in the dosbox.conf. I think some of the dosbox.conf out there have this missing, at least I know I have some that are missing that setting.
if we never scale should I then have set RENDER_USE_ADVANCED_SCALERS to 0, is setting it to a 1 a waste? I currently have it set to 1.
I think everyone has been using the simple core, at least I have.

 

[Qbix]

The scaling. Have you disabled the normal2x scaler in the configurationfile(or in src/dosbox.cpp) ? That one is responsible for the upscaling of 320x200 =>640x400
be sure to run with core=simple. (and maybe try with core=full as well as that one is small and thus cache friendly)

I see where its defaulted as normal2x. We also could set it to none in the dosbox.conf. I think some of the dosbox.conf out there have this missing, at least I know I have some that are missing that setting.
if we never scale should I then have set RENDER_USE_ADVANCED_SCALERS to 0, is setting it to a 1 a waste? I currently have it set to 1.
I think everyone has been using the simple core, at least I have.


I think it is best to modify dosbox.cpp to change the defaults. (e.g memsize=8, scaler=none,core=simple,etc)
As dosbox sticks to defaults if an option isn't specified in the configuration file.

The scaler cache is a good thing. So having it at 1 isn't a waste, but some profiling will tell how much it matters to the device.

 

[Pickle]

I think it is best to modify dosbox.cpp to change the defaults. (e.g memsize=8, scaler=none,core=simple,etc)
As dosbox sticks to defaults if an option isn't specified in the configuration file.

The scaler cache is a good thing. So having it at 1 isn't a waste, but some profiling will tell how much it matters to the device.

I will take your advice then and make those changes.
One question I did have about the memory, is it fully allocated even if it isnt used by the dos program? For example I specific 8 mb, does dosbox try to get the full 8 mb even if the program doesnt use anything above 4 mb?

 

[Qbix]

I think it is best to modify dosbox.cpp to change the defaults. (e.g memsize=8, scaler=none,core=simple,etc)
As dosbox sticks to defaults if an option isn't specified in the configuration file.

The scaler cache is a good thing. So having it at 1 isn't a waste, but some profiling will tell how much it matters to the device.

I will take your advice then and make those changes.
One question I did have about the memory, is it fully allocated even if it isnt used by the dos program? For example I specific 8 mb, does dosbox try to get the full 8 mb even if the program doesnt use anything above 4 mb?


I'll answer with the code :
CODE

Bitu memsize=section->Get_int("memsize");

if (memsize < 1) memsize = 1;
/* max 63 to solve problems with certain xms handlers */
if (memsize > MAX_MEMORY-1) {
LOG_MSG("Maximum memory size is %d MB",MAX_MEMORY - 1);
memsize = MAX_MEMORY-1;
}
MemBase = new Bit8u[memsize*1024*1024];



So yes it allocates what you specify. So maybe 4 is more safe.

 

[Pickle]

So yes it allocates what you specify. So maybe 4 is more safe.

Well I have tested 10 mb, I just wasnt sure if I was actually uses 10 mb of the GP2X memory. With the code you just posted it does. So I think 8 meg should be safe.
I might take the time this week end to see how how I can go.

 

[Pickle]

I took a quick look into the dynarec code and I thinks it something that's reasonable to do to get more performance.
It appears we would need a header file (like the other arch's) that define a group of functions that link into the main dynarec core.
I think if someone with a good ARM asm knowledge took a look at this, they probally could get it done in a reasonable timeframe. Im actually surprised it hasnt been done already.

Im guessing there are about 50 functions, but many are very short. Looks like most of them add ASM to a cache that perform the x86 operation.
I guess it's being called a 'C' based dynarec by some because of the linking C functions?

 

[Pickle]

Here's the latest with dosbox and its good.
Hitnrun who has been testing was able to debug and anaylze the dosbox code and come up with some fixes to the dosbox code that fixes the touchscreen support.
I expect to have the final version ready to go within the week/weekend.

 

[Pickle]

Its done!

http://archive.gp2x.de/cgi-bin/cfiles.cgi?0,0,0,0,5,2534

You must read the readme theres some cool features slipped in last minute.

 

[BadAstronaut]

I know I have posted this elsewhere, but anyone reading this thread that manages to get a game to run reasonably well (with or without sound), please upload your configs and a bit of info in a zip file to http://archive.gp2x.de/cgi-bin/cfiles.cgi?0,0,0,0,63

If you like, you can use the text files I have created as a starting template. Note that I have not yet uploaded any configs for this release of dosbox, so everything there has no touchscreen support and some could do with a re-mapping of the keys (I did those right when I just got my GP2X and they could be done better).

 

[TrevorBradley]

I got XCOM: UFO Defense (UFO: Enemy Unknown) to run... I got to the world screen, but things seem very slow and the mouse glitchy.

Colonization seems to be giving me a black screen but it could be a misconfig.

I'm actually looking forward to more of BadAstronauts wrappers.. Maybe these should be collected into a single file with new versions as new games are added?

 

[BadAstronaut]

Maybe these should be collected into a single file with new versions as new games are added?

Anyone else agree with this, or think that we should keep them to individual titles as is the case already? If people think we should collect them all into one file, I guess I can upload a zip every week or so of new configs that people have emailed to me (1badastronaut@gmail.com) - personally I would prefer there to be entries for each individual game, which makes searching the archive possible as well. Still, if I am in the minority here I don't mind uploading a zip with all of them.

Then again, we could just have both - individual configs listed in the archive, as well as a zip file containing all the files available. Don't see why the file archive can't just have both

(but then, someone has to tell me how to overwrite existing files on the archive with each upload of a newer version)

 

[jdbye]

Yay, Heroes of Might and Magic works perfectly, albeit at a slow speed.
Warcraft I didn't work, which is strange since it worked on an earlier dosbox and at a pretty amazing speed too, but you couldn't play it because it needed mouse.

It's just the demo, can anyone else try and see if they can get the WC1 demo working?

 

[TrevorBradley]

Maybe these should be collected into a single file with new versions as new games are added?

Anyone else agree with this, or think that we should keep them to individual titles as is the case already? If people think we should collect them all into one file, I guess I can upload a zip every week or so of new configs that people have emailed to me (1badastronaut@gmail.com) - personally I would prefer there to be entries for each individual game, which makes searching the archive possible as well. Still, if I am in the minority here I don't mind uploading a zip with all of them.

Then again, we could just have both - individual configs listed in the archive, as well as a zip file containing all the files available. Don't see why the file archive can't just have both

(but then, someone has to tell me how to overwrite existing files on the archive with each upload of a newer version)


They're really quite small... I really don't mind when there are only 10, 20 or 50 games, but there are literally thousands of games that could be emulated by dosbox, and I wouldn't want to see the archive stuffed with dosbox entries.

Other software, like Mame, have indexing files that let us just plug in our roms and go. Think of it the same way... we could have a single zip dosbox configuration package where we just plug in our games and go.

One thousand Dosbox config files could fit into a 2.5MB zip file. I really wouldn't mind downloading that file if it were very well indexed just to get one or two files I needed.

 

[trainchaser]

OMG. Any chances for Dark Forces/Blood/Ufo: Enemy Unknown support in the
future? (overclocking to ~260-270)

Can anyone check SWOS and Elder Scrolls Arena (and possibly the above titles)?

Thank you!!!

 

[TrevorBradley]

OMG. Any chances for Dark Forces/Ufo: Enemy Unknown support (that great Star Wars FPS) in the future? (overclocking to ~260-270)

Thank you!

I got UFO Enemy Unknown to the planet screen/first base creation. Seemed really sluggish (like I'm not sure if this has crashed sluggish), but I didn't tune the dosbox.conf file.

A plea for a later version: Can we have some key combo quit dosbox (start+select?), even if we have to set it up in mapper.txt? It would make testing way easier if a bad config didn't mean resetting.