[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 :D 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]

sold, on 06 August 2009 - 03:27 PM, said:

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 :)

This post has been edited by Khan: 06 August 2009 - 08:40 PM

[Pickle]

Khan, on 06 August 2009 - 04:35 PM, said:

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 :-)

This post has been edited by Pickle: 08 August 2009 - 06:26 PM

[rabidpoobear]

Pickle, on 06 August 2009 - 03:44 PM, said:

Khan, on 06 August 2009 - 04:35 PM, said:

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]

Esn, on 09 August 2009 - 01:46 AM, said:

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. :P

[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:

This post has been edited by fischju2000: 09 August 2009 - 12:47 AM

[Enverex]

Pickle, on 06 August 2009 - 09:44 PM, said:

Khan, on 06 August 2009 - 04:35 PM, said:

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! ;)

This post has been edited by Khan: 09 August 2009 - 02:35 PM

[Stephane Hockenhull]

Khan, on 09 August 2009 - 09:32 AM, said:

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)

[Laurent]

Stephane Hockenhull, on 09 August 2009 - 06:38 PM, said:

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.

Quote

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.

Quote

* 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 :P ).

Quote

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.

[Stephane Hockenhull]

Quote

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.

This post has been edited by borgqueenx: 13 August 2009 - 02:35 PM