Psx4gp2x Dynarec Status Update


FF VII does see some improvement, and if it had memory card support, would be permanely loaded on my gp2x until I manage to finish it (never have on an actual psx). Still not fullspeed, of course.

Might also want to look into some kind of frame rate limiter, as in some parts (very small map areas, like the generator elevators) the FPS is actually too high! Ah well, nice to see you back on my fav project :D
 
we definetly need an optimized mmuhack.o... I am going to suggest this in the cool ideas section. As far as I know, there is a version which notaz compiled specifically for gpsp after it was noticed that the former version was not using the full mmu potential. Maybe, if someone took a good look at the hack, an improved version could be created which would generally be beneficial for all emulators utilizing the mmu hack!
 
nice work zod, i think i got about 5-7 frames from adding the mmu file
keep up the great work, full speed is near!
 
Now, because for me it's hard to memorize all the various button combos required for tweaking the settings, I'd appreciate it greatly if they were all simply menu driven. I know it's not priority, and I don't expect it anytime soon, but... somewhere down the line it would be nice.
 
Shadowsithe: I definitely agree.

I was going through the dynarec code, and psx4all code in general. It's very sloppy and really needs to be rewritten, possibly even the dynarec. At least to get the performance needed for the GP2X. Otherwise going through the code is getting excessive.

I'm working on the dynarec and might have increased performance, but what I learned was the GPU is now starting to take a bigger chunk of the GP2X's CPU time as the PS1's MIPS CPU emulation.

I also think streamlining some of the more often called functions such as polling events like key handling will start to become important. It looks like a lot of work.
 
Its great to hear that theres still room for optimization even if it could involve impossibly large amounts of work. I hope that you will eventually be able to move the gpu over to the 940 like unai mentioned because if its taking up almost as much processing power as the cpu then i suppose that would create a massive speedup.
 
Jackd said:
Its great to hear that theres still room for optimization even if it could involve impossibly large amounts of work. I hope that you will eventually be able to move the gpu over to the 940 like unai mentioned because if its taking up almost as much processing power as the cpu then i suppose that would create a massive speedup.
I thought that the plan was to move the CPU over? Actually I suppose it is still up in the air because of the lack of a memory manager on the second core, it can't map anything and has to be "babysat" by the real ARM with a proper memory manager.

Either way I am glad to see all of this progress, If we ever get the MMSP2+ (or whatever) I am sure this dynarec work will translate to a near perfect emu as soon as Zod can turn his attention to it, as the next-gen unit will surely have something to help with the GPU rendering. In fact it would be nice to own another ARM platform with a graphics chip, what else does PSX4ALL run on again? Edit: oh, the zauras, I need to check out one of those, more PDA functionality would be nice in a handheld (oh crap I sound middle-aged, whatever).

PC's have been here before, the CPU doesn't do the heavy lifting when it comes to simple Graphics functions that can use a "dumb" graphics acceleration unit.
 
Last edited by a moderator:
xnopasaranx said:
we definetly need an optimized mmuhack.o... I am going to suggest this in the cool ideas section. As far as I know, there is a version which notaz compiled specifically for gpsp after it was noticed that the former version was not using the full mmu potential. Maybe, if someone took a good look at the hack, an improved version could be created which would generally be beneficial for all emulators utilizing the mmu hack!
Not true, I haven't recompiled anything. There are two versions of mmuhack.o spread around, one of them is working, other is completely broken (does nothing). I don't know where the broken one came from and why so many emu authors used it.
Also you can't optimize mmuhack.o, it simply works or does not.
 
Last edited by a moderator:
zodttd said:
Shadowsithe: I definitely agree.

I was going through the dynarec code, and psx4all code in general. It's very sloppy and really needs to be rewritten, possibly even the dynarec. At least to get the performance needed for the GP2X. Otherwise going through the code is getting excessive.

I'm working on the dynarec and might have increased performance, but what I learned was the GPU is now starting to take a bigger chunk of the GP2X's CPU time as the PS1's MIPS CPU emulation.

I also think streamlining some of the more often called functions such as polling events like key handling will start to become important. It looks like a lot of work.
some quick questions

is gourad shading disabled in the gpu ?
can the color palette be slimmed down in the gpu rendering ?
do you consider the Gte to be part of the Cpu emulation or the Gpu ?
would the vector calcs of the Gte clog up the bus if it was moved to the 940t ?
 
Last edited by a moderator:
evol said:
some quick questions
is gourad shading disabled in the gpu ?
No, its enables if the application uses it, could be enabled and probably it would be faster, I thought about adding an option to force it but many games and effect would look ugly.


evol said:
can the color palette be slimmed down in the gpu rendering ?
It could but It wont help much in performance, now all the rendering is done directly in 555.

evol said:
do you consider the Gte to be part of the Cpu emulation or the Gpu ?
would the vector calcs of the Gte clog up the bus if it was moved to the 940t ?
Now gte is part of the cpu and that is very dificult to move to the 940t as those calculations and the rendering are already decoupled in the psx, and also they are being recompiled(more or less).
the best I could do (and what I plant to do once I get time again) is to move the gpu rendering to the 940t and use the dma "emulation" to communicate 920 and 940t using the asynchronous nature of both.
 
Last edited by a moderator:
thank you una-i for your answers, they cleared up a lot of questions for me.

i asked about gouradshading because when i tested with demos, it seemed like the framerate dropped when gouradshaded scenes was showing.

and then i was told by a user that gouradshading was not included in the emu (which i thought was odd because it seemed shaded)

http://www.gp32x.de/board/index.php?s=&am...st&p=524654

great work so far, some demos is fullspeed on 266mhz+ramhack interlace 1 progressive on 50% underclock
b.t.w this is my favorite demo http://www.pouet.net/prod.php?which=3331
 
Last edited by a moderator:
zodttd said:
Still trying to get the triple-core ( http://www.paintindy.com/shop/id/51628/dis...104729928186028 ) GP2X processor to use the other 2/3rd's potential. Right now only Dr_Ian has the beta but maybe he's open to sharing if you ask nicely. ;)



Display: 64 bit 5.5" 320 x 240 pixels CRT display

Wow 64 bit display? 5.5" CRT? That is the most compact color CRT I have ever seen, and it gets 10 hours of battery life with a 310 MHz triple core CPU, amazing :rolleyes:

What kind of joke is that?
 
Last edited by a moderator:
http://www.gp32x.de/board/index.php?s=&am...st&p=529908

Really it's a quad core but GPH hasn't passed along any information of how to unlock the 4th core. We're hoping they release their closed source Mplayer module under the GPL to find out how to do this. Will get us fine coarse scaling too! ;P

...

Must of just missed Unai. :(
 
Last edited by a moderator:
Ok, jokes aside...

I did a test of my current build of psx4gp2x. The test was with Buster Bros Collection which in-game can reach about 45 FPS @ 266MHz and interlace 1. That's besides the point though, because when I disable the GPU rendering and run the game it goes from 45 FPS to 85 FPS.

What does this mean? Well if were able to get the GPU to magically take zero overhead, framerates will nearly double! Most every game would run perfectly fine on the GP2X and sound can become a reality. Problem is you wouldnt be able to see anything...unless we can move the GPU to the second cpu. ;)

Unai mentioned when I was able to take the stress of the emulation from the CPU emulation and make things more 50/50 he/we would try it. Maybe it's time. :)

So that should give some people some more hope in the project. ;)

I'm going to try to profile the CPU and GPU emulation and see which routines are taking up the most GP2X CPU time.

If FF7 is nearly playable now, imagine it with twice as much the framerate minus a decrease with sound. Then add memory card and save state support, and you have what I want to do for the next release. It's possible and now I have the stats to show it.


Just to make sure the results I'm finding are on par with the above, I'm testing the sound output by ear. Since the above is more so a vsync per second, as frames aren't rendered it's still somewhat of a guess. Sound would give a better idea of what to expect. Just making sure. :)
 
I still think an option to disable gourad shadeding would be nice, most games look fine without it, on a screen so small, who would notice? :p

Also I was not saying *there are no gourad shaders*, I was told there cant be any on this emu, thnaks for clearing that up una-i, I will stop listening to none devs when i'm asking such questions ;)

@ Zod - You already passed my expectations for this emulator, just memory card support would rule, more performence you say? o_O!
 
Back
Top