D PSP emulator


Not sure how well a Cortex-A8 processor at 500-1000mhz will be able to emulate a 266-333mhz MIPS R4000 core. Seems a bit too close, generationally, does it not?


Ari64 or Notaz would have a better idea, I guess.
The problem with the Pandora is the slow memory rather than the Cortex-A8 clock. Running yabause on a 1GHz Intel Atom is quite a bit faster than on a 1GHz OMAP3530, due to the RAM and cache.
 
Last edited by a moderator:
^ So in your opinion would it be feasible to even get a few games to play decent "well" optimized of course?
 
I really have no idea... I'm assuming that the CPU requirements for PSP emulation would be higher than for N64 or Saturn, but I don't know how much higher. There really aren't any existing PSP emulators that are working well enough to make such a comparison.
 
I had a choice - buy a PSP and hack it, or gamble the money, and buy a Pandora with the winnings. I'm happy with my choice. Maybe if I really really want to play PSP games, I'll buy one second hand. I doubt we'll get an emulator that will do the games justice, and most homebrew could probably be ported. PSX games are already running very well, and for me they are what made the Pandora my "ultimate wish" (excluding "a real woman" of course - but we all know they cant play games very well :lol: ).
 
I even created a own CFW for PSP cause I like the device, however Pandora is still above it for me...


PSP is a nice choice though if you want a cheap homebrew capable device...


Just buy it used for 90 bucks, install our CFW on it and you are set.
 
The problem with the Pandora is the slow memory rather than the Cortex-A8 clock. Running yabause on a 1GHz Intel Atom is quite a bit faster than on a 1GHz OMAP3530, due to the RAM and cache.

I understand the lack of phenomenally large cache, but how slow is the Pandora ram? I used to be (a very, very long time ago) a PS1 programmer and remember dealing with it's slow ram and tiny instruction cache was a bit of a headache.
 
I understand the lack of phenomenally large cache, but how slow is the Pandora ram? I used to be (a very, very long time ago) a PS1 programmer and remember dealing with it's slow ram and tiny instruction cache was a bit of a headache.

There's some old lmbench numbers for Beagleboard here:


http://markmail.org/message/f57u7muxh7ipshix#query:+page:1+mid:cgfnq4qzccevyjsg+state:results


Someone can run it on Pandora if they want, of course.


lmbench runs standard C code, so in this case it won't tell quite the whole story of what's available to you. For instance, read bandwidth is probably dominated by latency, since no latency hiding techniques are employed (on Cortex-A8 you have only one option - prefetch, ideally to NEON registers). If you look at the read bandwidth, about 250MB/s from main memory, which is about 4ns per byte. If you consider that a cache line is 64-bytes that equals about 256ns per cache line, which is similar to the latency figures cited. The cache line size also clearly shows up where the striding breaks performance.


Writes, on the other hand, are probably limited by L2 cache which is configured as write allocating/write back. This incurs the latency of an L2 cache miss and the latency of filling the rest of the cacheline; the write buffer will hide some but not all of this latency, because it'll end up filling before these events complete. Using NEON or perhaps large stms will help with the latter issue because they can address entire cache lines in one burst. The former issue is helped by writing to memory configured w/o L2 write back, like an mmap to /dev/fb0 presumably.
 
sorry for the no doubt stupid question on this but how much more powerful is the psp than the Playstation 1. like i though the psp was pretty close to PS2 power
 
This Java-based PSP emulator needs an i5 with 3.2 Ghz to get 20fps at Crisis Core... Sadly i dont't think you will be able to play PSP-Games on the Pandora. :(


Edit: Well, here is another video, same Emu, same game but with Sempron 2.21 Ghz. Also laggy BUT playable. Seems odd that such a worse CPU compared to i5 can reach nearly the same Framerate.
 
Last edited by a moderator:
This Java-based PSP emulator needs an i5 with 3.2 Ghz to get 20fps at Crisis Core... Sadly i dont't think you will be able to play PSP-Games on the Pandora. :(


Edit: Well, here is another video, same Emu, same game but with Sempron 2.21 Ghz. Also laggy BUT playable. Seems odd that such a worse CPU compared to i5 can reach nearly the same Framerate.

This is complete speculation but wouldnt it be really slow just cause its Java (interpreted, or running in a VM or whatever, not natively compiled)?


Now if it was written in C or C++ or another nativly compiled language, it would be MUCH faster.
 
What is it with everyone requesting emus that are impossible to run at a playable speed? :p


I mean DS, PSP, Saturn, Dreamcast, Ps2, Xbox 360, 3DS? really?


What ever happened to stuff that is doable like GBA, 3DO, Jaguar (one game T2K), CPS1, CPS2, N64 etc?
 
What is it with everyone requesting emus that are impossible to run at a playable speed? :p


I mean DS, PSP, Saturn, Dreamcast, Ps2, Xbox 360, 3DS? really?


What ever happened to stuff that is doable like GBA, 3DO, Jaguar (one game T2K), CPS1, CPS2, N64 etc?

Good point. But let's let notaz work his magic first so people lose interest. And we have CPS1 through MAME4ALL. And if bugging Exophase for Temper worked, why not for GPSP? :p
 
A lot of the PSP home-brews can be ported across as most are open source anyway..


So why emulate something when it can be ran natively?
 
The PSP has commercial games, you know.
 
Last edited by a moderator:
I understand the lack of phenomenally large cache, but how slow is the Pandora ram? I used to be (a very, very long time ago) a PS1 programmer and remember dealing with it's slow ram and tiny instruction cache was a bit of a headache.
The Pandora RAM is DDR-333 with a 32-bit data path. A typical low-end PC (Intel Atom) is DDR2-667 with a 64-bit data path. It's quite a large difference.
 
The Pandora RAM is DDR-333 with a 32-bit data path. A typical low-end PC (Intel Atom) is DDR2-667 with a 64-bit data path. It's quite a large difference. I dou

I bet you anything that the performance difference has way more to do with latency than bandwidth, which is more the fault of the SoC than the memory itself. I think typical latency on Atom is less than half that of OMAP35xx, AM/DM37xx, OMAP4430, or i.MX5x.. in fact the only ARM platform I know of that has competitive latency in Tegra 2, although there could be others.


On the other hand, on Cortex-A8 without prefetching this latency limits bandwidth.
 
Back
Top