Dos Box

[Death_Pigeon]

Hi All First Post
Anyways my question is will it be able to play any dos game in particular Warcraft II seeing as though it runs on Linux.

Kinda Noobish with Pandora don't even own a GP32x only got a CF PSP correct me on anything I got wrong

 

[Esn]

correct me on anything I got wrong

Ok. GP32x is a website, not a console. There was a handheld called the GP32, which was followed by the GP2X, which will be followed by the Pandora (each successive handheld was developed by mostly different people, but the community has stayed the same).

As for your question, I'm not sure. I know that many Dos games will run, but some complex ones won't. I'm not really sure where WCII falls.

 

[plopperz]

Warcraft I apparantly ran OK on the GP2X with DosBox. I don't know about WCII. If it can run on a low-end 386 it should run fine on the Pandora (correct me if I'm wrong)

 

[Pickle]

correct me on anything I got wrong

Ok. GP32x is a website, not a console. There was a handheld called the GP32, which was followed by the GP2X, which will be followed by the Pandora (each successive handheld was developed by mostly different people, but the community has stayed the same).

As for your question, I'm not sure. I know that many Dos games will run, but some complex ones won't. I'm not really sure where WCII falls.

I would expect all games to run (we dont have any memory constraints), but not necessarily be full speed or playable. We should expect to get at least 3x the performance on pandora. I think it could be possible.

 

[zodttd]

Pickle: I hope I don't need to do the DOSBox dynarec when it comes down to it for Pandora. That project keeps slipping out of my schedule.

 

[Pickle]

Pickle: I hope I don't need to do the DOSBox dynarec when it comes down to it for Pandora. That project keeps slipping out of my schedule.

Oh I wish you would . I think we will get a good performance increase with Cortex core, but i cant imagine how much faster it would be with the dynamic core extended to ARM.
You may want to take a look, Ive attempted to see how much was needed for the PSP and it really didnt look too bad. It may not take as long as you think it would. It's really the only thing missing.
But i know your time is going towards some good things.

(I believe you live in Canada?.. I live in MI. maybe i have to come over and motivate you? :blink: )

 

[ldesnogu]

You may want to take a look, Ive attempted to see how much was needed for the PSP and it really didnt look too bad.

Doesn't DOSbox already have a MIPS backend? Or are you talking about some other parts than the dynarec?

If I find some time (and some hardware), I will take a look at the ARM backend

 

[Pickle]

You may want to take a look, Ive attempted to see how much was needed for the PSP and it really didnt look too bad.

Doesn't DOSbox already have a MIPS backend? Or are you talking about some other parts than the dynarec?

If I find some time (and some hardware), I will take a look at the ARM backend

Sweet! Let me know if get anywhere.
You misunderstood me, i looked at the dosbox to see how much code was done for the MIPS dynarec, not to develop it. I assumed the MIPS would be comparable to the ARM.

 

[M-HT]

If I find some time (and some hardware), I will take a look at the ARM backend

You could start at my attempt to write the ARM backend (using thumb instruction set).
I am out of ideas why it doesn't work.

Source here

PS:
If you comment the definition of DRC_FLAGS_INVALIDATION_DCODE (line 32) it seems to work at the beginning, but still fails at a later point (instead of failing at the beginning).

 

[ldesnogu]

Thanks

Why did you use Thumb? To save memory?

 

[M-HT]

Why did you use Thumb? To save memory?

Because there is almost no place to use arm instructions which doesn't have equivalent thumb instructions. And thumb instructions use half the memory which means better cache utilization.

 

[Exophase]

Why did you use Thumb? To save memory?

Because there is almost no place to use arm instructions which doesn't have equivalent thumb instructions. And thumb instructions use half the memory which means better cache utilization.


For recompiled x86 ARM code potentially allows you much tighter output than Thumb, allowing for at least better register caching, sub-32bit operations (due to shifts), immediates for more ALU operations, etc. Conditional execution may come in handy as well (at the very least, conditional bl). You could also perform move and shift propagation to fold some moves and shifts in x86 instructions into whatever target they're being moved into. The better address modes don't really hurt either, and if you want to have ARM stubs for things like memory accesses it's going to cost you doing the mode switching without a blx instruction. All in all I don't think it's worth saving the cache pressure over, but none of this might be relevant for the kind of thing you'd get out of porting Dosbox's backend in the normal way.

 

[slaanesh]

A little off subject:

Facts:
DOSBox for PSP has a dyna-rec. PSP uses MIPS R4000 (32-bit) CPU.
The Playstation 2 uses MIPS R5900 (64 bit) CPU.

Question:
Would the DOS Box dyna-rec for the PSP be suitable for PS2?

Was just thinking that old PS2s would make rather nice DOSBox machines.

 

[ldesnogu]

A little off subject:

Facts:
DOSBox for PSP has a dyna-rec. PSP uses MIPS R4000 (32-bit) CPU.
The Playstation 2 uses MIPS R5900 (64 bit) CPU.

Question:
Would the DOS Box dyna-rec for the PSP be suitable for PS2?

That would probably be doable with almost no change. The 32 bit vs 64 bit has been done correctly on all processors except for x86, so it should be no issue here. The main divergence for R5900 from a standard MIPS core is that it's a mix of various levels of MIPS architectures (plus some extras ).
Now you just have to find someone to debug it

 

[M-HT]

For recompiled x86 ARM code potentially allows you much tighter output than Thumb, allowing for at least better register caching, sub-32bit operations (due to shifts), immediates for more ALU operations, etc. Conditional execution may come in handy as well (at the very least, conditional bl). You could also perform move and shift propagation to fold some moves and shifts in x86 instructions into whatever target they're being moved into. The better address modes don't really hurt either, and if you want to have ARM stubs for things like memory accesses it's going to cost you doing the mode switching without a blx instruction. All in all I don't think it's worth saving the cache pressure over, but none of this might be relevant for the kind of thing you'd get out of porting Dosbox's backend in the normal way.

You are of course right (I did static recompilation from X86 to ARM, so I'm aware of this). But with the way Dosbox is doing dynamic recompilation, these types of instructions can be used in low number of places. That's why I think, that using Thumb instructions is better in this case.

 

[Pickle]

Why did you use Thumb? To save memory?

Because there is almost no place to use arm instructions which doesn't have equivalent thumb instructions. And thumb instructions use half the memory which means better cache utilization.


For recompiled x86 ARM code potentially allows you much tighter output than Thumb, allowing for at least better register caching, sub-32bit operations (due to shifts), immediates for more ALU operations, etc. Conditional execution may come in handy as well (at the very least, conditional bl). You could also perform move and shift propagation to fold some moves and shifts in x86 instructions into whatever target they're being moved into. The better address modes don't really hurt either, and if you want to have ARM stubs for things like memory accesses it's going to cost you doing the mode switching without a blx instruction. All in all I don't think it's worth saving the cache pressure over, but none of this might be relevant for the kind of thing you'd get out of porting Dosbox's backend in the normal way.

If we switch to normal ARM could it be more stable than using the thumb version?

 

[Exophase]

If we switch to normal ARM could it be more stable than using the thumb version?

No. c_c

You are of course right (I did static recompilation from X86 to ARM, so I'm aware of this). But with the way Dosbox is doing dynamic recompilation, these types of instructions can be used in low number of places. That's why I think, that using Thumb instructions is better in this case.

I think the incentive here should be to overhaul DOSBox's recompiler structure, since it's quite limiting (I know what you mean, I've looked through it). This could benefit the PSP version too if suitably adapted for, but if it was anything more complex than it is I'm not sure we would have seen a PSP recompiler in the first place.

Could you describe at all what the process of static recompilation was like for you, what you recompiled and how well it worked, how much you had to manually change, etc..

 

[Pickle]

I think the incentive here should be to overhaul DOSBox's recompiler structure, since it's quite limiting (I know what you mean, I've looked through it). This could benefit the PSP version too if suitably adapted for, but if it was anything more complex than it is I'm not sure we would have seen a PSP recompiler in the first place.

Who's going to overhaul what's already there, (are you thinking about it)? Are you saying its limiting on the amount of recompilation that occurs, or limiting on the access to get the backend working?
I guess my concern is, would it be more beneifical to get an backend working for ARM that fits into the current structure, than to think about taking it further? You seem to hint on this with your last statement.
I was really glad this topic came up, as I hoping it would get someone with the background to finish it.

 

[Exophase]

Who's going to overhaul what's already there, (are you thinking about it)? Are you saying its limiting on the amount of recompilation that occurs, or limiting on the access to get the backend working?
I guess my concern is, would it be more beneifical to get an backend working for ARM that fits into the current structure, than to think about taking it further? You seem to hint on this with your last statement.
I was really glad this topic came up, as I hoping it would get someone with the background to finish it.

What I'm saying is that the framework that DOSBox provides doesn't really let you do a very sophisticated recompiler. But the benefit of the current framework is that it isn't that much work to write a new backend for it. The more sophisticated the recompiler, the more the backend will swallow the frontend and the more work will have to be done to support it per-architecture. It'd be best to fit a new backend into what's there (as the PSP port did) and then see if it can be modified to give you more direct/fine control over what's output. Unfortunately, that part could be really difficult.

Moving to what's there will be an improvement. Just not nearly as big of an improvement as it could be.

And sorry, but I'm not overhauling anything. I don't actually work on other people's emulators, so I can't really do much (can only start a few myself >_>)

 

[Pickle]

It'd be best to fit a new backend into what's there


Thats all ive wanted, but it seems we cant even get that far.
The dosbox authors most likely would not except anything else into there CVS. So a rework of the current structure in my opinion would be bad, even though the benefits to the ARM world would be better for it.