Gp2psx V0.36


Tinnus is correct. I'm getting a version of GP2PSX, most likely, tonight from Unai that's been cleaned up and worked on by him and Chui. Depending on it's state, and if they think it should be released, we'll make a release of it.

I'm determined to get a dynarec working with this emulator.
For those who are completely confused, simply put, a DynaRec (dynamic recompiler) is a method of emulating a machine. It's usually faster than the method I'm currently using which is an Interpreter. So by using the dynarec in GP2PSX will make things overall faster. By how much is undetermined, but my guess is it will add enough speed to give the GPU some "room to breathe".

So let's hope this dynamic recompiler happens, since it's finally coming together in terms of development. Thanks Tinnus! :)
 
zodttd

wouldnt Ldchen of FpseCE

be the right person to talk to about the implementing of the dynarec

seems like both emus could benefit from exchanging ideas
and i think the team has just switched to asm dynarec opposed to the previous C dynarec

dont ask me how they pulled of an C dynarec im a noob at programming but the forums said they made a C dynarec and is optimizing it with asm

until next time cheers :)

http://www.fpsece.net/contact.htm
 
Wow, I look forward to seeing this in action. You know it sounds a bit like how they did Bleem! a long time ago. They said that the way it ran the games was not really "emulation", but that it "imitated" the playstation hardware, so basically it was just a program that could also play playstation games. I don't really understand too much about this, but I am very excited to see such enthusiasm about a project like this.
 
Taht was marketing. "hardware imitation" == emulation. Altough Bleem! did use a dynarec.
 
Not all systems can be dynarec'ed though. It's very hard to do it when you can have self-modifying code...
 
Dynarec is just another optimisation technique for various cpu core emulators. It normally gives the best performance increase if the code normally runs from rom, although can work with code running from ram with more work.

If a Dynarec just isn't feasible, or would take too long to implement, the next approach is normally something like adding delayed flag calculation to interpreter based cores (again, not always possible, depends on the cpu core being emulated - some may support full delaying of all flags, whilst other only support a few).

And then there is the classic "rewrite cpu core interpreter in assembler", which is always possible, and is normally done before attempting to step up to a Dynarec. A level 1 dynarec is normally very similar to an assembler based interpreter, in that it just runs blocks of code that the interpreter would otherwise run - the only part missing being the decision making (which is done at dynarec block creation time, rather than at each and every instruction).

Once the l1 dynarec runs well enough, it's usually optimized via redundant flag calculation removal (as you can see if a flag is required whilst compiling the code) and other techniques.

Trying to do the last one first however usually ends up with the same consequence of when you try to run before you can walk - you fall flat on your face, your brain implodes, and you give up.
 
I just got the latest codebase from Unai and Chui who have been hard at work on it. I will give it a compile and give a status report a.s.a.p. Will see if I should wait for the dynarec or not. Either way a new release in a week or two is definitely happening. ;)
 
That is great news. If you feel it's even going to take longer than what you said that's fine. Take your time. I can wait quite a while. Haha not sure how much I can say for everyone else. It is very exciting to hear.
 
Hey ZodTTD, now that we have the righteous 2.0 Firmware and there's no excuse not to upgrade is there any chance you could incorprate the overclocking utility? It'd just make things slightly easier, especially in an emulator where overclocking is so important...

Looking forward to the next release, regardless what happens... :p
 
BTW: If you're still having problems with ARM assembler, you might try contacting Reesy - he loves assembler coding more than anything else ;)
He might help you, if he's got the time.
 
Cool. A brief of the project is as follows:
- I got the latest codebase from Unai and Chui and got it working on the GP2X.
- I got compatibility higher by removing my "tricks" to speed up emulation, as well as fixing a dumb bug in the game loading routine. Games such as the original Wipeout (not XL which already worked), now work.
- Due to removing some of those optimizations/tricks, the speed of the emulator went down by about 1-3 FPS.
- I made a quick script for loading GP2PSX overclocked to 266MHz using Cpu_Speed.gpe. But I'm in the process of implementing overclocking without the use of the script and external program. It won't be too much trouble to do, it's just not at the highest priority considering the use of a GPU script and Cpu_Speed works. It'll get done though. :)
- Unai is still in the process of writing the new version of the GPU. He's going to have some freetime coming up soon, and should have it ready in due time.
- Good news about the GPU, Unai figured out what was wrong with the frameskipping's "time warp" effect. Interlacing is working on the new GPU to a certain extent.
- A name change for GP2PSX is coming, as well as a dedicated site. Will announce it shortly.
- I keep missing Tinnus' messages to me about his work on the dynarec. So I'm sorta not sure on it's current status. Last I heard he was implementing a "C Dynarec" then proceed to get a dynarec with translation caching working. I'll get a better report on this soon.
- The code for GP2PSX is much cleaner. It was a real mess originally.
- We now have a better development setup, including a SVN. So development time and getting in touch will be getting better.
- Profiling has been put into GP2PSX, so I'm going to go through the numbers and find bottlenecks to help optimize things.

Before I get a new version of GP2PSX ready I would like the following to be ready:
- Either the new gpu be ready, or the current gpu with frameskipping working.
- Depending on how far along Tinnus is, a "C Dynarec".
- Some way of overclocking compatible with GP2PSX. If time allows internal overclocking to be implemented over a GPU script, then that would be great.

Some questions for everyone:
- Right now sound is disabled in the development build of GP2PSX. I was thinking of leaving it disabled until the emulator is in a position in terms of performance to allow for it. It's one less thing I have to worry about making sure it works before releasing a new version, so if it's not needed right now, it would be best to be left out next release. So, is it needed? It's ok if it is.
- I'm thinking of making a simple menu system for GP2PSX so options can be chosen without remembering weird key configs. Is this something required before releasing the next version?

Oh yeah!
Unai now has a PayPal account to receive donations. See my signature for the link to donate to him. I think he could use some inspiration to get this new GPU ready. He's been showing me great work. I believe his new GPU will make GP2PSX much better based off his work with the original GPU alone. I know much of his work hasn't been shown publicly, but he's been constantly working on GP2PSX and it's getting better and better. With frameskipping, interlaced rendering, and some tricks up his sleeve, he's going to make this emulator worth it. The quicker this new GPU progresses, the quicker new releases come as this emulator is heavily dependant on his work. :)

Hopefully I'll hear from Tinnus today. I'll give another status update concerning the Dynarec when I do hear from him.

If Reesy offers his help for this project, I will gladly accept it. :) I don't want to bother him though as I'm sure he's very busy.
 
Back
Top