Psx4gp2x Public Beta 2 Released.

[TKF15H]

is it possible that this dynarec would benefit other apps (much like Squidge's mmu hack), or is it strictly useful for this emu?

Depending on how it's being written, maybe. If it has a well defined front-end (MIPS input) and back-end (ARM output), others emulators may be able to write their own front ends for other processors.

 

[Nr.56]

Ehhh the wiki has a table with game tests that really needs some updates:

http://wiki.gp2x.org/wiki/GP2PSX

I think it's better if you use that instead of creating your own thread etc.

The wiki has no oportunity to compare needful things. every game is tested in only one setting. this is not really helpful to see improvements. tell me what the hardwarescaling performed by looking the wiki! what improvements you get by changing the interlacing to 1? you get no answer
furthermore you can list special bugs for every game (the loop bug in soul reaver) with discriptions.

 

[STTrife]

I'm not so familiar with wiki's (I only READ them) but I thought it's possible to make any kind of table that you like? so can't you alter the wiki table to give you what you want?

 

[Damien]

i'm curios how dose it that a game like diablo runs at 5 fps
and a game like redalert runs at 35 fps (constant)

tnx guys
and zottd GREAT GREAT GREAT JOB!!!!

First i was surprised as well that Resident Evil for example runs faster then Diablo. I dont know that much bout coding but i guess one reason for Diablo running so slow is the fact that there is alot of stuff to calculate that you dont see. Diablo has to "remember" alot of stuff when you change levels in the dungeon and monsters even move around when you cant see them at all. I guess the ISO-3D doesnt help either... But thats just a guess... I CANT CODE !

 

[kardasan]

A dynarec is something that's made specifically for a CPU emulator... it's like another way to emulate something. It translates the PSX CPU commands to ARM commands that the GP2X CPU can understand. In that case, the PSX's CPU, the MIPS R3000A. So Anything that uses a R3000A CPU could benefit...

Now find anything else that does

If I understand correctly what do you want to do, then you want to translate the code from PSX's CPU to ARM. But if so then isn't it a very resource-eating? Is it possible to do it on the fly or will we have to convert images before loading them (which isn't a really a problem )

 

[X-Code]

It's a dynamic recompiler, it runs in real time with the emulator, and is speeding up the CPU emulation by converting the original R3000A instructions into it's ARM counterparts... Basically, it seems like a better and faster system

 

[DaveN]

It's a dynamic recompiler, it runs in real time with the emulator, and is speeding up the CPU emulation by converting the original R3000A instructions into it's ARM counterparts... Basically, it seems like a better and faster system

It isn't just translating the commands, it also tries to optimize them. An example:

A system may not be able to copy two chars at the same time, so it has to copy it one per one:

a = DOG
temp = 1. Char of a
b = temp 
temp = 2. Char of a
b = b & temp
temp = 3. Char of a
b = b & temp

Dynamic recompiling now could use the new functions of our better processor and do it just like this:

a = DOG
b = a

And this will be much faster!

Edit: That's how I understood it, if that's completly false, feel free to correct me.

 

[kardasan]

so again, won't it be more resource-eating? Optimising code is not simple O(n) operation...

 

[X-Code]

I don't know if it's meant to be optimizing on the run, I can only imagine that you would slow the translation down if you added extra instructions, unless they are actually necessary, on the other hand, I'm no expert in emulation :lol: ( or much else after my beers )

 

[Vimacs]

On normal interpreter cores you emulate instruction by instruction.
On a dynarec you convert a chunk of code to the native "language" and save the result, so now evry time that chunk is needed you can just run the native counterpart instand of emulateing evry instruction again.

 

[X-Code]

Kinda like a recoverable cache system, it's neat, and should speed things up a load, thanks for clarifying this part B)

 

[Jarska333]

on the other hand, I'm no expert in emulation :lol: ( or much else after my beers )

After my beers, I'm expert in everything. B)

 

[shinneri]

Dino Crisis - wouldn't run
Dino Crisis 2 - wouldn't run
Resident Evil 2 - run until the "violence and gore" image and froze

Theme Park - didn't see the actual fps, but it was completely playable--even the 3D walk around part.

 

[STTrife]

I see your point about the 'extra' instruction but it's not extra. You must compare it to the previous way of emulating which is more indirect then dynamic recompilation Besides you CAN'T emulate it without extra instructions. The code of PSX binaries can't just run directly run on the GP2X so you always have to emulate the processor, or translate it to ARM bytecode... always

Compiling the whole image in advance could make it faster but I don't think it's always possible. I'm not sure if the PSX has any, but games with self-modifying code will not work anymore then.

 

[X-Code]

I meant extra unnecessary instructions, not the necessary ones, but yeah, I know, instructions have to be converted, it was the cache system that was eluding my poor beer-fried mind :lol: , I do see this new system as a much more feasible ( and fast one ).

 

[Nr.56]

Has someone wangled to run " the italian job" ?
My image hangs on loading screen. <_<

 

[Lobo]

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.

 

[kardasan]

I'm not sure if the PSX has any, but games with self-modifying code will not work anymore then.

Ow. That's interesting. Would you be so kind and give me couple of examples of such games? For any platform, not only psx.
If I understand this whole discussion about dynarec correctly, then it seems that translating machine chunks of PSX machine code to ARM machine code is faster than interpreting, right? (I belive that disassembling the PSX machine code, translating it to ARM assembler and then compiling it to ARM machine code won't do, right ) It seems quite obvious that when you skip/modify some instructions then you won't have to execute them, but is the process of translating/optimising the single chunk really faster than interpreting all the instructions in that chunk? Then, are you taking the fixed size chunks (like in caching) or do you determine somehow the size of chunk that would hold a complete instruction in it? For example:

a = 4

isn't the same size (in machine code) as:

a = b

am I right here or is it my brain malfunction?

BTW, I'll read all the answers after 10th of July, because I'm going on vacation, so till then I'm blind and deaf here ^^

 

[X-Code]

On normal interpreter cores you emulate instruction by instruction.
On a dynarec you convert a chunk of code to the native "language" and save the result, so now evry time that chunk is needed you can just run the native counterpart instand of emulateing evry instruction again.

It is said, Should it be not faster to check, convert and optimize one chunk once, than one chunk many times ?.


Even so, I like all the weird stuff I read here, I'm not into making emulators so I'm safe :lol:

 

[zodttd]

I seemed to have introduced a bug in .Z as well as .ZNX compression at least since beta 1. I think I have the .Z bug fixed, which might have also fixed .ZNX compression as well. I will know when the bug is fixed soon and will let everyone know.

This bug caused MANY games to not work at all, or crash at different points in games, usually in .Z compressed games.

I changed the code to work more like v0.35, so if you see a game that worked in 0.35 that doesnt work now, it may just work in the next release.

I'm not sure how much more compatibility will be seen on non-compressed games, but it won't be any lower, only the same or higher.

Thanks to Unai for pointing out this bug and Tinnus for mentioning the 0.35 compatibility rate for a tip on how to fix the bug.