Status Of Psx4gp2x Work Being Done :)


zodttd

Solving your premature emulation since the Tapwave
Joined
Dec 2, 2005
Messages
1,167
Website
www.zodttd.com
News update:
The latest builds of psx4all can be found at:
http://www.zodttd.com

zodttd.com will provide RSS feeds as well soon. :)

Hi everyone,

A small but good status update on psx4gp2x. I've actually been working on the psx4all ARM Dynarec (psx4gp2x) for some time now, off and on. After bothering Exophase enough, he is starting to come to his senses and help me out with psx4all. :)

Thanks to Exophase, a night full of coding (and lots of work for me to do in the day!) helped us produce a disassembler for the psx4all ARM Dynarec which produces not only the MIPS disassembly from the PSX side of things, but also the dynarec'd ARM disassembly for the corresponding MIPS code! This is going to be extremely helpful for improving the dynarec performance overall!

Now, when debugging and profiling I can run psx4gp2x and load up a game and get something such as the following:
Block PC bfc04a20 -> 0x904b00
bfc04a24: lui t1, 49089
bfc04a28: lw t1, [t1 - -8360]
bfc04a2c: lui t3, 49089
bfc04a30: sb zero, [t1 + 0]
bfc04a34: lw t3, [t3 - -8356]
bfc04a38: li t2, 10
bfc04a3c: li v0, 30000
bfc04a40: li v1, 1
bfc04a44: li a0, 2
bfc04a48: sb t2, [t3 + 0]
bfc04a4c: lui t4, 40961
bfc04a50: lw t4, [t4 - -28220]
bfc04a54: nop
bfc04a58: bne t4, v1, bfc04a64
bfc04a5c: nop

00904b00: mov r2, #12648448
00904b04: orr r2, r2, #-1090519040
00904b08: mov r0, #856
00904b0c: orr r0, r0, #252928
00904b10: orr r0, r0, #66846720
00904b14: orr r0, r0, #-67108864
00904b18: add r0, r0, r2
00904b1c: stmdb sp!, {r2, }
00904b20: bl ff79c3c0
00904b24: ldmia sp!, {r2, }
00904b28: mov r2, r0
00904b2c: mov r3, #12648448
00904b30: orr r3, r3, #-1090519040
00904b34: mov r4, #0
00904b38: stmdb sp!, {r2 - r3, }
00904b3c: mov r1, #0
00904b40: mov r0, r2
00904b44: bl ff79c6bc
00904b48: ldmia sp!, {r2 - r3, }
00904b4c: mov r0, #860
00904b50: orr r0, r0, #252928
00904b54: orr r0, r0, #66846720
00904b58: orr r0, r0, #-67108864
00904b5c: add r0, r0, r3
00904b60: stmdb sp!, {r2 - r3, }
00904b64: bl ff79c37c
00904b68: ldmia sp!, {r2 - r3, }
00904b6c: mov r3, r0
00904b70: mov r5, #10
00904b74: mov r6, #1328
00904b78: orr r6, r6, #28672
00904b7c: mov r7, #1
00904b80: mov r8, #2
00904b84: stmdb sp!, {r2 - r3, }
00904b88: mov r1, r5
00904b8c: mov r0, r3
00904b90: bl ff79c670
00904b94: ldmia sp!, {r2 - r3, }
00904b98: mov r9, #65536
00904b9c: orr r9, r9, #-1610612736
00904ba0: mov r0, #452
00904ba4: orr r0, r0, #1019904
00904ba8: orr r0, r0, #267386880
00904bac: orr r0, r0, #-268435456
00904bb0: add r0, r0, r9
00904bb4: stmdb sp!, {r2 - r3, }
00904bb8: bl ff79c328
00904bbc: ldmia sp!, {r2 - r3, }
00904bc0: mov r9, r0
00904bc4: cmp r9, r7
00904bc8: movne r12, #612
00904bcc: orrne r12, r12, #18432
00904bd0: orrne r12, r12, #1069547520
00904bd4: orrne r12, r12, #-2147483648
00904bd8: moveq r12, #604
00904bdc: orreq r12, r12, #18432
00904be0: orreq r12, r12, #1069547520
00904be4: orreq r12, r12, #-2147483648
00904be8: mov r10, r12
00904bec: str r2, [r11, #36]
00904bf0: str r3, [r11, #44]
00904bf4: str r5, [r11, #40]
00904bf8: str r6, [r11, #8]
00904bfc: str r7, [r11, #12]
00904c00: str r8, [r11, #16]
00904c04: str r9, [r11, #48]
00904c08: ldr r0, [r11, #656]
00904c0c: add r0, r0, #15
00904c10: str r0, [r11, #656]
00904c14: ldr r1, [r11, #916]
00904c18: sub r0, r0, r1
00904c1c: ldr r1, [r11, #920]
00904c20: cmp r0, r1
00904c24: blge ff7af73c
00904c28: mov r1, #540
00904c2c: orr r1, r1, #9175040
00904c30: mov r0, r10, lsr #16
00904c34: ldr r1, [r1, r0, lsl #2]
00904c38: mov r0, #252
00904c3c: orr r0, r0, #65280
00904c40: and r0, r10, r0
00904c44: ldr r0, [r1, r0, lsl #0]
00904c48: teq r0, #0
00904c4c: bxne r0
00904c50: bl ff774090
00904c54: bx r0

As you may notice from the above code (besides a bug or two in the output), the dynarec is saving and restoring two registers almost constantly on and off the stack! This can be easily changed for the better! Also see how much that small block of MIPS code is taking so many ARM instructions? This is due to many things, but a large chunk of it can be reduced by changing the way I handle the differences between direct/indirect branches, as well as IRQ checks. I'm outputting too much code for checking IRQs and since its done at the end of each block, with such small blocks, it's way too much overhead.

Then Exophase gave me a good idea to change the way IO is handled. Since I learned about PSX emulation mostly from FPSE/PCSX, they used a plugin model. My model, although it doesnt use plugins, is similar, and doesn't benefit from performance increases that can be had by using a more unified approach for moving IO data.

The short of things: Exophase has been a HUGE help already! Expect good things from psx4all to come. This work helps not only psx4gp2x, but other ARM based ports of psx4all as well.
 
Excellent plan - dumping the dynarec'ed assembler(!).
An obvious profiling strategy I guess? (I'd never have thought of it).

Anyway, good to see this development still active :)
 
I actually have dumped the dynarec output and disassembled it with IDA. The problem with that is, you dont have the matching MIPS disassembled code. So thanks to Exophase and his work with the disassemblers for MIPS and the much more difficult ARM...I was able to get a clean representation of performance, one codeblock at a time. It's been a thing Exophase, and I for that matter, have wanted for awhile. I just wasn't able to disassemble ARM in a timely manner and have it get anywhere as near as good as what I have now.



EDIT: I saw the post before you edited it kevcal. Didn't require an edit imho. ;) ...But yes, this is an obvious strategy but just was out of reach for so long. Hopefully this will mean things will pick up quickly!
 
Ten dollars donation on its way. Keep up the good work guys!
 
woah... I assume, the changes you plan to make according to the flaws you pointed out in the disassembled output are going to bring us an enormous speed boost? It sure seems like those are essential amendments. Good work zodttd and exophase!
 
Thanks zodttd and Exophase, you can't believe how much the whole community is looking forward to better PSX emulation :)
 
I'm not sure to understand everything (in fact I don't, but I don't want to appear like stupid... Ooops, I'm looking stupid now) but thank you for the hard work and time you two had put recently in this project.
 
Wow, you don´t cease to surprise us. At last, light at the end of the tunnel :)
By the way, is U-nai still working on the 2nd core?

Thank you guys!!
I consider donating, too

Staying tuned :)
 
zodttd said:
Then Exophase gave me a good idea to change the way IO is handled. Since I learned about PSX emulation mostly from FPSE/PCSX, they used a plugin model. My model, although it doesnt use plugins, is similar, and doesn't benefit from performance increases that can be had by using a more unified approach for moving IO data.

The short of things: Exophase has been a HUGE help already! Expect good things from psx4all to come. This work helps not only psx4gp2x, but other ARM based ports of psx4all as well.
First good work. I have a dumb question are you basing your psx emulator now of the FPSE(psx emu for pocket pc) Or where you always basing it of it? Because i know that the fpsce requires 500-600mhz handled most notably the dell axim for smooth playing.
Ok hopefully this makes sense.
 
Last edited by a moderator:
Quick history of psx4all:
- One night (literally one night) many years back, I ported PCSX to the Tapwave Zodiac when bored with porting Zodiac TTD. It was my first dip into emulation. I called it ZodPSX and it became PalmPSX.
- The Zodiac scene died out and most moved to the GP2X, as did I. Created GP2PSX and continued tweaking PCSX.
- Unai, Chui, and Tinnus jumped on board and helped me remove the PCSX code piece by piece and create psx4all.
- What we have now is a codebase similar to PCSX by design (which will change as well for performance reasons). The GPU is completely rewritten, the CPU core is completely rewritten, the SPU has been rewritten though I know little of it's history.

Exophase threw out the idea of rewriting a psx emulator from the ground up again from what I learned from psx4all. Not such a bad idea. If we do it, it will be open source. I think he needs motivation since he's very busy with his baby named gpSP. :)

For now though, psx4all is being tuned up. :)
 
zodttd said:
Quick history of psx4all:
- One night (literally one night) many years back, I ported PCSX to the Tapwave Zodiac when bored with porting Zodiac TTD. It was my first dip into emulation. I called it ZodPSX and it became PalmPSX.
- The Zodiac scene died out and most moved to the GP2X, as did I. Created GP2PSX and continued tweaking PCSX.
- Unai, Chui, and Tinnus jumped on board and helped me remove the PCSX code piece by piece and create psx4all.
- What we have now is a codebase similar to PCSX by design (which will change as well for performance reasons). The GPU is completely rewritten, the CPU core is completely rewritten, the SPU has been rewritten though I know little of it's history.

Exophase threw out the idea of rewriting a psx emulator from the ground up again from what I learned from psx4all. Not such a bad idea. If we do it, it will be open source. I think he needs motivation since he's very busy with his baby named gpSP. :)

For now though, psx4all is being tuned up. :)
thanks zottd but quick question what happen to the gizmondo emu? I understand leaving the zod i did to.
 
Last edited by a moderator:
zodttd said:
I actually have dumped the dynarec output and disassembled it with IDA. The problem with that is, you dont have the matching MIPS disassembled code. So thanks to Exophase and his work with the disassemblers for MIPS and the much more difficult ARM...I was able to get a clean representation of performance, one codeblock at a time. It's been a thing Exophase, and I for that matter, have wanted for awhile. I just wasn't able to disassemble ARM in a timely manner and have it get anywhere as near as good as what I have now.

EDIT: I saw the post before you edited it kevcal. Didn't require an edit imho. ;) ...But yes, this is an obvious strategy but just was out of reach for so long. Hopefully this will mean things will pick up quickly!

Yeah, thought I'd written it so it sounded a bit...

Ayyway, being able to compare 'like for like' I reckon will give you so much more info on where you can make optimisations (imho :p ) I watch this development with great interest - I think you're at the limit of what the gp2x can emulate and it's actually fun to be a bystander watching.
 
Last edited by a moderator:
Back
Top