Anyone For Dosbox?

[sold]

I really would appreciate any news about dosbox. I don't mind if there isn't any, but it is one of my most anticipated apps for Pandora. Pickle, if you have the time, don't let that goats life be taken for naught. Please give us an update And mayhaps grace this humble topic with a video.

I cannot guarantee 100% that the goat was a virgin, but ffs I hope it was. You see, there wasn't a male goat...

Thanks in advance for any response.

 

[Pickle]

I really would appreciate any news about dosbox.

Not really anything new with dosbox, last i was running CVS (0.73) code with some custom M-HT dynarec changes. I was also last playing with dark forces as a test.
I will try and get some videos going for the weekend.
Now before the requests start to come in, im only going to try things I have and arnt a total pain to load.

 

[Khan]

Regarding those videos...Could you make those tests running at 850 Mhz? (5000 cycles, Am I right?) Just to rise our expectations

Thanks

 

[Pickle]

Regarding those videos...Could you make those tests running at 850 Mhz? (5000 cycles, Am I right?) Just to rise our expectations

Thanks

I can run at 850 Mhz.
I will be running them with dynamic core, MAX cycles, 22050 sample rates

Update: Dosbox videos coming today

 

[rabidpoobear]

Regarding those videos...Could you make those tests running at 850 Mhz? (5000 cycles, Am I right?) Just to rise our expectations

Thanks

I can run at 850 Mhz.
I will be running them with dynamic core, MAX cycles, 22050 sample rates

Update: Dosbox videos coming today

OMG I'm so excited! Delicious videossss. My precioussss

 

[Esn]

Dosbox: Blake Stone and Dark Forces
Dosbox: Duke 1 and Airborne Ranger
Dosbox: Commander Keen 4

In Keen 4, I notice that the sound effects are a little delayed. Is there any particular reason that the music was turned off?

 

[multiplex]

Dosbox: Blake Stone and Dark Forces
Dosbox: Duke 1 and Airborne Ranger
Dosbox: Commander Keen 4

In Keen 4, I notice that the sound effects are a little delayed. Is there any particular reason that the music was turned off?

Tsk, impatient. The first three minutes of the second video is darkness, so you at least ought link it like this. Though here's hoping Pickle fixes the encoding issue or whatever.
And yay, Commander Keen! Been a while since I played that. Same goes for Pickle, judging by the video.

 

[fischju2000]

Looks great, like all the videos, but I'm a little concerned that nobody has ever played a game on the Pandora well. Everybody always seems to suck...Pickle was pretty good at Dark Forces though :lol:

 

[Enverex]

Regarding those videos...Could you make those tests running at 850 Mhz? (5000 cycles, Am I right?) Just to rise our expectations

Thanks

I can run at 850 Mhz.
I will be running them with dynamic core, MAX cycles, 22050 sample rates

Update: Dosbox videos coming today

With the exclusion of overclocking the processor, do you see much (or any) room for optimisation with DOSBox? Or is this likely to be the best we're going to see on the Pandora?

 

[Khan]

Well, I think we can still wait for hardware acceleration to be usable enough or transfering sound to DSP but, again, Pickle has the last word.

BTW, Dark forces looks gorgeously smooth (maybe we can expect 486DX/33 perfomance figures after all )
Great job, Pickle!

 

[rv6502]

BTW, Dark forces looks gorgeously smooth (maybe we can expect 486DX/33 perfomance figures after all )
Great job, Pickle!

with a very good dynamic recompiler running 32 bit x86 code you could easily get up to 486DX-120Mhz performance depending on the software being run
with interpreted emulation running 16bits x86 code, not much more than a 386DX-16

the 486 had only 8KB to 16KB of cache (code+data)
ARM and 486 have roughly equivalent cycles-per-operation speeds (1 cycle/op)

where it hurts:
* emulating has an overhead for emulating I/O and virtual memory
* the ARM ALU is 32bits only (8bits and 16bits ops needs to be shifted back and forth to emulate the x86 flags)
* ARM instructions are 4 bytes long and recompiled code is much larger so a lot less fits in the cache VS x86 code
* Thumb instructions are 2 bytes long but are much less efficient for emulation because you need a lot of bit-shift operations and address calculations which the 4byte ARM code does better, so you end up with much more Thumb code than ARM code for emulating the same x86 opcodes.

x86:
ADD [EBX], EAX ; 2 bytes, 3 cycles (on 486)

ARM:
ldr r12, [r1] ; 4 bytes, 1 cycle
adds r12, r12, r0 ; 4 bytes, 1 cycle
str r12, [r1] ; 4 bytes, 1 cycle

both take the same time, but ARM takes 12 bytes VS 2 bytes, less fits in the instruction cache = more memory delays
that's not even counting the overhead of emulating virtual memory.

emulating a MIPS processor with flat memory (N64, PS, PSP) is a lot easier for an ARM than emulating an x86 in protected mode (dos4gw, windows, etc)

 

[ldesnogu]

with a very good dynamic recompiler running 32 bit x86 code you could easily get up to 486DX-120Mhz performance depending on the software being run

Don't you think "very good" and "easily" are mutually exclusive? If it's that easy I'm eagerly waiting for that performance, let's say before end of this year.

the 486 had only 8KB to 16KB of cache (code+data)
ARM and 486 have roughly equivalent cycles-per-operation speeds (1 cycle/op)

where it hurts:
* emulating has an overhead for emulating I/O and virtual memory
* the ARM ALU is 32bits only (8bits and 16bits ops needs to be shifted back and forth to emulate the x86 flags)

If your x86 regs are in memory, shifting can be skipped by using ldrsb and ldrsh.
Also if you compute flags for each instruction without checking if it's really needed you'll never approach your claimed 486DX-120Mhz performance.

* ARM instructions are 4 bytes long and recompiled code is much larger so a lot less fits in the cache VS x86 code
* Thumb instructions are 2 bytes long but are much less efficient for emulation because you need a lot of bit-shift operations and address calculations which the 4byte ARM code does better, so you end up with much more Thumb code than ARM code for emulating the same x86 opcodes.

Thumb-2 can help here (though I find it disgusting ).

x86:
ADD [EBX], EAX ; 2 bytes, 3 cycles (on 486)

ARM:
ldr r12, [r1] ; 4 bytes, 1 cycle
adds r12, r12, r0 ; 4 bytes, 1 cycle
str r12, [r1] ; 4 bytes, 1 cycle

both take the same time, but ARM takes 12 bytes VS 2 bytes, less fits in the instruction cache = more memory delays
that's not even counting the overhead of emulating virtual memory.

Some comments:
- Your ARM code sequence has a load-use penalty between the ldr and the adds.
- You are missing AF and PF flag computation.
- Translating one instruction at a time will not provide good enough speed.

 

[Sugar_Kane]

I had already signed dark forces off as a no on the pandora, based on the 386-max dosbox speed prediction, but here we see it, running at a playable speed. I'm pretty excited about that, and it makes me wonder if tie fighter might have a chance after all.

 

[rv6502]

x86:
ADD [EBX], EAX ; 2 bytes, 3 cycles (on 486)

ARM:
ldr r12, [r1] ; 4 bytes, 1 cycle
adds r12, r12, r0 ; 4 bytes, 1 cycle
str r12, [r1] ; 4 bytes, 1 cycle

both take the same time, but ARM takes 12 bytes VS 2 bytes, less fits in the instruction cache = more memory delays
that's not even counting the overhead of emulating virtual memory.

Some comments:
- Your ARM code sequence has a load-use penalty between the ldr and the adds.
- You are missing AF and PF flag computation.
- Translating one instruction at a time will not provide good enough speed.
[/quote]

true, true, I'm just giving a rough estimate, and I figure some good recompiler would interleave the instructions, canceling the penalty.

what I mean is the 486 and ARM9 have roughly equivalent performances running native code, ARM benefits from more registers and free shifting operations, 486 benefits from code size.
cycle for cycle, excluding register spills, you get similar performance.

and old 486 PCs don't have too weird of a hardware like 2 to 6 processors to emulate: no Blitter, Copper, raster DMA, etc.
if the game supports VESA (doesn't use ModeX nor 16 colors planar) you don't have much impact to emulate the hardware side.

80% to 90% of the time spent in a 486/early Pentium era game was in the software rendering and transferring the finished frame (up to half of the time spent!) to the video card.

it makes those games "easy" to get good emulation performance compared to earlier CGA/EGA games (complex hardware) and later 3D-accelerated FPU/MMX heavy games.

only problem is that a lot of the good games of that era have the source code available, making this point moot

 

[borgqueenx]

after watching the new dosbox vids...im kinda disappointed <<< IF this is the final result.
The psp even runs games smoother with his dosbox port.

 

[Enverex]

after watching the new dosbox vids...im kinda disappointed <<< IF this is the final result.
The psp even runs games smoother with his dosbox port.

No-one has mentioned that any real further optimisation can be done (short of some pro coming along and making a dynamic recompiler to take full use of the ARM A8) so this is all you're likely to see.

Not quite sure why the PSP would run better than the 850Mhz Pandora though, seems a bit strange.

 

[renegadechic]

after watching the new dosbox vids...im kinda disappointed <<< IF this is the final result.
The psp even runs games smoother with his dosbox port.

got to say i am a bit skeptical of this and would happily see examples. also, is the pandora also running the emulator at almost double the PSP resolution?

 

[borgqueenx]

i play commander keen on dosbox on my psp with full speed. with music, sound, everything enabled. no problems at all.
if no one believes me, i can make a video if you'd like...

But it wont change the fact that for some strange reason the psp runs dosbox better then the pandora

 

[Pickle]

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?

 

[Exophase]

true, true, I'm just giving a rough estimate, and I figure some good recompiler would interleave the instructions, canceling the penalty.

Pandora is Cortex-A8, which is much better than ARM9 (dual issue superscalar, branch prediction, 64bit path to dcache, etc). It also has some useful instructions that can help in x86 emulation, such as bit insert/extract (including sign extension) and some 12bit and 16bit immediate operations.

what I mean is the 486 and ARM9 have roughly equivalent performances running native code, ARM benefits from more registers and free shifting operations, 486 benefits from code size.
cycle for cycle, excluding register spills, you get similar performance.

ARM also benefits from three-address arithmetic, which can make a worthwhile enough difference in propagation with a recompiler. I would pick ARM9 over 486 in performance, much less Cortex-A8 which is far ahead. By the way, Pandora's CPU also has 256KB of L2 cache, while will go a long way towards negating any code density advantages the 486 may have had.

and old 486 PCs don't have too weird of a hardware like 2 to 6 processors to emulate: no Blitter, Copper, raster DMA, etc.
if the game supports VESA (doesn't use ModeX nor 16 colors planar) you don't have much impact to emulate the hardware side.

However, you do still have to emulate the address space and depending on aborts for this will not only require a kernel module but you'll also spend a lot of time going through Linux's abort system then emulating the instruction when you get such an abort. If a lot of accesses are done to hardware registers then this will be a problem, but as you say such a thing normally won't happen. Of course, for 32bit games there will be free reign of the address space, something you just can't give while constrained within an address space in Linux. Anything that forces you to emulate the MMU or trap I/O (outside of port mapped of course) directly is going to cost you a lot of performance. But in 16bit code you have to emulate segmentation, so it's a similar kind of situation. Of course there are going to be games that will use the address space in a very simple way, but you can't really generalize such a thing. I don't really know how the common memory managers were setup so if it's at all abstracted via them then this can be circumvented at a higher level.

80% to 90% of the time spent in a 486/early Pentium era game was in the software rendering and transferring the finished frame (up to half of the time spent!) to the video card.

it makes those games "easy" to get good emulation performance compared to earlier CGA/EGA games (complex hardware) and later 3D-accelerated FPU/MMX heavy games.

MMX can translate pretty well to NEON code. FPU hopefully about the same, although just how well is difficult to determine because of the weirdness in the x87 stack. I still think there's a lot of potential in emulating Linux in user mode + Wine, since you're guaranteed a good amount of address space abstraction. But of course there were a lot of games that were for DOS and not Windows, even by this era.

M-HT has gotten around 40-50% native performance with his relatively simple static recompiler for some DOS games. The additional impact of using a dynamic recompiler would not be that much. So yes, I definitely think that the targets you're interested in are attainable. Unfortunately (as I'm sure you can see), DOSBox for ARM is not very efficient. Laurent is working on qemu for ARM, which should be quite a bit faster. But w/o address space abstraction it won't be able to perform DOS emulation as well as you'd hope it could.