Psx4gp2x Public Beta 2 Released.

[X-Code]

Translated this as best I could on the Spanish site too .

Keep up the good work zodttd .

 

[zodttd]

I GOT THE DYNAMIC RECOMPILER WORKING! YAY!

I'M TESTING IT OUT AS WE SPEAK!

I'll update everyone on it's progress in about 12 hours. It should have the BIOS completely loaded and dynamicly recompiled by then. Right now it runs a few hundred cycles into it. This is BIG GREAT news for GP2X users, as I'm estimating this week a new release including dynanmic recompilation will be possible. Huge performance increases coming very soon nonetheless.

Time to work on it for another 12 hour stretch...

 

[devestation]

I GOT THE DYNAMIC RECOMPILER WORKING! YAY!

I'M TESTING IT OUT AS WE SPEAK!

I'll update everyone on it's progress in about 12 hours. It should have the BIOS completely loaded and dynamicly recompiled by then. Right now it runs a few hundred cycles into it. This is BIG GREAT news for GP2X users, as I'm estimating this week a new release including dynanmic recompilation will be possible. Huge performance increases coming very soon nonetheless.

Time to work on it for another 12 hour stretch...

Sounds excellent.

BTW, ygpm.

 

[gaterooze]

Wow, that's stunning progress. Months worth or work in a week?!?! Crikey!

 

[STTrife]

GREAT job zodttd!!! I made a simple port of snes9x, and now I see the difficulty of the code and I see how slow my port runs I can imagine now what kind of work you are doing... you must be a genious
keep it up!!!

for people who have problems with running psx games:

if your game is not working you might try

http://server1.megagames.com/psx/psx_patches.shtml

to see if yo can patch your game to remove copyright protection...

and for the self modifying code: the program is usualy loaded into memory and executed from there. Now this code might write value to into the memory where the program resides. It can then change it's own code while executing. If you translated the whole image to ARM code than I forsee two problems:
a. it will not be the same size. You cannot assume each asm instruction can be translated into an ARM-asm code with the exact same size. so when it tries to self-modify it will be doing this at the wrong place (possibly)
b. WHEN it modifies itself it will write PSX-asm code into the translated ARM-asm code so you will not have a valid ARM program anymore

An example of selfmodifying code is programs that are 'compressed' with EXE-compressors. It could also be done as a security thing like copy protection. Anyway I'm not an expert on this, I have no idea if snes has any games, or even has possibility to modify it's own code.

 

[Tobriand]

Hmm... I wonder if you could get round that by passing any code which generated errors through a detector (to check that it was ARM) and then back through the recompiler. It'd be crazy complicated (memory addresses all over the place, and of course, you have to hope the chip doesn't just crash completely when fed non-arm code that it tries to run) but it might work. Maybe. Says he who knows a rather minimal amount about the subject.

In any event, many congratulations to Zodttd for getting the core running in the first instance - I'll be looking forward to reading the update (hopefully) later today. It really is amazing though, the speed at which you've done this. First you thought it'd take a month... then a week, and now we're only on the 6th day of that week and already you're getting results!

 

[X-Code]

Well done zodttd ( and the rest of the team too )... I'll get my game testing gloves on :lol:

 

[kevcal]

and for the self modifying code: the program is usualy loaded into memory and executed from there

Yeah, self modifying code has to be run from RAM (code usually is for speed anyway).
I've written 68k self-modifying code (reuse/speedup of loops in games).. it's generally/always
frowned upon in a professional environment; now whether games programming houses care...?

If there are PSX games that use self-modifying code, then it will show up in (probably) all
of the PS emulators... So maybe try any games with problems on (say) a PC-based emu
to check.

Kev

EDIT:
BTW, well done on the progress on the dynarec!
If the dynarec is as good as people make out - ie it can optimise code - does it imply that it can be enhanced/
improved over time to give more and more speed increases as familiarity with PSX/ARM assembler improves?

 

[Radek]

and for the self modifying code: the program is usualy loaded into memory and executed from there

Yeah, self modifying code has to be run from RAM (code usually is for speed anyway).
I've written 68k self-modifying code (reuse/speedup of loops in games).. it's generally/always
frowned upon in a professional environment; now whether games programming houses care...?

Selfmodifying code is very rare now.

If there are PSX games that use self-modifying code, then it will show up in (probably) all
of the PS emulators... So maybe try any games with problems on (say) a PC-based emu
to check.

If the emu is using normal interpreter (not dynarec) selfmodifing code should not affect its perfomance. Dynarec will be affected thought and possibly to great degree by such code.
(it must check for such situation, then retranslate, then again check, retranslate...)

Kev

EDIT:
BTW, well done on the progress on the dynarec!
If the dynarec is as good as people make out - ie it can optimise code - does it imply that it can be enhanced/
improved over time to give more and more speed increases as familiarity with PSX/ARM assembler improves?

Why not? But next gains will not be that impressive as when dynarec was implemented at first.

 

[Phil]

Hatchi Matchi!

 

[Nr.56]

I'm wondering if a lot of these games that hang might be the newer games that were protected (against piracy)? Could that be the reason they're hanging? Might be an idea to "patch" the ISO of one of them and see if that helps.


BTW tried out Resident Evil, OCed to 280, with progressive on and interlacing 1, and as long as you're alone on the screen it's damn near full speed (near enough that I can't tell the difference)! Incredible! It's about the only game I've tried were interlacing and progressive noticeably affect FPS.
Of course as soon as you get a zombie on screen with you then the FPS plummits, but hey, a lot of the time you're alone anyway.

most rips of this games run on other emulators like epsxe!
i don´t think that the copyprotection is the reason for hanging.

 

[kevcal]

If the emu is using normal interpreter (not dynarec) selfmodifing code should not affect its perfomance. Dynarec will be affected thought and possibly to great degree by such code. (it must check for such situation, then retranslate, then again check, retranslate...)

I see, so if an emulator is not dynamically recompiling, then self-modifying code would work fine as it is interpreted on an instruction by instruction basis (well sort of).
Do other PSX emulators use dynamic recompilation?

But next gains will not be that impressive as when dynarec was implemented at first.

Would there be any benefit in (I don't know what's in the PSX bios(!)) 'recompiling' the bios itself to make it as optimised as possible -
as I guess the BIOS holds many of the most used hardware access routines?
ie as well as an scph1001.bin(?) file - have a scph1001_arm.bin file.

Also are there standard libs that PSX games writers used that have 'standard' routines utilised often that may benefit from a 'by hand' translation to ARM assembler?

Kev

 

[DaveN]

*opens the package containing a new 2gb sd card*

Now let's talk about timing Even if I already ordered this like three or four weeks ago, bad service of the store ( a local one )

@Topic:
Fantastic work! Like you already said before, getting dynamic recompiling working could be months of coding.

 

[STTrife]

I think recompiling the bios file in advance could work but then again I'm not familiar with (dynamic) recompiling. However if the dynamic recompilation reuses blocks of code then PROBABLY zodttd and co. already compile the bioscode only once and not everytime it's needed
it might only take a few seconds to compile it once so maybe there's no need to put it in a file, but just recompile it at startup of emulator.

Again I wonder if anything I say is correct, because I actually don't know anything for sure but that's zodttd fault he should have explained it better to me then lol

 

[Radek]

I think recompiling the bios file in advance could work but then again I'm not familiar with (dynamic) recompiling. However if the dynamic recompilation reuses blocks of code then PROBABLY zodttd and co. already compile the bioscode only once and not everytime it's needed

That is very important to have gains from dynarec - to reuse translated code as long as possible. Translation is relatively expensive but execution of translated code much quicker than interpreting.
(except selfmodifying code)

it might only take a few seconds to compile it once so maybe there's no
need to put it in a file, but just recompile it at startup of emulator.

It might be done on a demand or offline and then resulting binary file saved somewhere for reuse. If there are no selfmodifing code tricks offline method could be even better as more sophisticated translation could be done.

There is also aproach of improving translations where at every runtime translator use previous output to analyze and generate a better one.

Again I wonder if anything I say is correct, because I actually don't know anything for sure but that's zodttd fault he should have explained it better to me then lol

You are well informed and what you said is correct.

 

[kevcal]

There is also aproach of improving translations where at every runtime translator use previous output to analyze and generate a better one.

Self-profiling...
Hooray - self-modifying code in the dynarec!

Kev

 

[deepmenace]

sorry to be a n00b but does anyone have even a rough idea of what kind of performance gains this will lead to?

like between 0-10 fps depending on the game?

will it affect 2-d more than 3-d?

 

[X-Code]

2x to 3x increase in performance ( we're told ), it'll be most noticeable in 2D games, but all games should speed up quite a bit .

Not easy to estimate exactly how much the increase will be, but a game running before at 15 should come close to fullspeed ( not in all cases though :lol: )... Don't forget that it's still under development.

 

[deepmenace]

2x to 3x increase in performance ( we're told ), it'll be most noticeable in 2D games, but all games should speed up quite a bit .

Not easy to estimate exactly how much the increase will be, but a game running before at 15 should come close to fullspeed ( not in all cases though :lol: )... Don't forget that it's still under development.

w0w. thanks x-code. fingers crossed eh?

i never thought this'd be possible.

 

[X-Code]

This is still only guesswork, the only person that knows how fast this is working this minute is zodttd ( and the rest of the team of course )... We can only hope that it'll reach anything near fullspeed in the near future... All this testing and waiting is fun though.