Pandora Pandora-psp

[JayFoxRox]

I didn't even touch homebrew games yet, stop thinking about commercial games..
I once thought I got Puzzle Bobble running without renderer but it just sticks itself in an endless loop. Probably some sort of trap or error handler. I will know more once the dwarf symbols are fully loaded.

 

[gibberish]

i always read your posts in this thread jayfoxrox, despite the fact i have absolutely no idea what you're talking about half the time i find it intensely interesting to read. you obviously know what you're on about and although im not too bothered about a psp emulator myself i know tonnes of other people are and i wish you luck with it!

 

[Exophase]

I get about 25k instructions per second (in the gu/cube sample + printing some GU stuff to the console which probably slows down a bit), I m sure that can be optimized a lot too but for now this works fine. I m sure the PSP is A LOT faster than this (atleast the CPU), but it still works fine for the samples because Vertical-Sync is not working yet in the emulator
I planned to add a profiler to the cube sample anyway (mainly for the GE code, but CPU too ofcourse) so thats what I will do as soon as the other problems are gone.
Yesterday, I had a look at sprintf() with psp-gdb but some registers seem to be wrong before that already - but that might be a problem with different stack pointers on real hardware.

I don't want to discourage you since I know you know what you're doing and you're on a good track to completion with this emulator. I'm just concerned about others who might not know very well getting the wrong idea.

When you say that this particular demo is running faster than it does on a PSP people may consider this to be an indication that commercial games won't pose a speed challenge. What they have to understand is that right now you're virtually not emulating a CPU at all, and that the CPU (especially VFPU) emulation is probably going to be the most demanding part of the emulator, by a huge margin. 25K instructions per second is not even a drop in the bucket. NES games tend to execute way more than that.

It's hard to say just how many "typical" CPU instructions a PSP game can execute, and it's even harder to say how many it will execute (unless you profile it on a real PSP, which possibly can be done since the PSP does have profiling hardware). I guess one good thing is that you can artificially underclock the CPU and a lot of the games will be designed to cope with it, so framerate suffers but event timing, audio and controls don't. In fact you might end up trying to make vsync happen at real 60Hz instead of emulated 60Hz, which would even make some games run better if the emulating maching was powerful enough. Would save you from having to count cycles (maybe), but you'd end up having to do guarded exit points so you don't interrupt in the middle of an instruction.

 

[JayFoxRox]

yes, ofcourse. I already said this before, some games won't work that easily because they are far too cpu intense while others will have no problem beeing run because they keep the cpu idle most of the time. The fire sample from tyranid is still by far too slow - But thats getting about 60k instructions per second (which means that my console output and / or GU stuff is REALLY slow).
More high-level calls mean better performance but more time to implement anything.
I never said that 25k is enough to get something cool working - but it gets the job done for the samples and some homebrew games, possibly a few commercial titles too
Don't really get what you mean by "not emulating a CPU at all" though. But I m new to this so you might be right.
I m working on support for PSPTris right now by the way because I found out that its already getting to the file loader while writing my last reply.

 

[Exophase]

yes, ofcourse. I already said this before, some games won't work that easily because they are far too cpu intense while others will have no problem beeing run because they keep the cpu idle most of the time. The fire sample from tyranid is still by far too slow - But thats getting about 60k instructions per second (which means that my console output and / or GU stuff is REALLY slow). More high-level calls mean better performance but more time to implement anything. I never said that 25k is enough to get something cool working - but it gets the job done for the samples and some homebrew games, possibly a few commercial titles too

I don't know where PSP games spend their CPU time, how much of it is in high level calls. But I would be surprised if you knew this at this point (if you do it'd be interesting to know). I would also be surprised if most games didn't find some ways to spend several millions of cycles per second on something not tied up in high level calls. I'd be surprised if any at all use numbers under 100k.

Don't really get what you mean by "not emulating a CPU at all" though. But I m new to this so you might be right.

I didn't mean that you weren't emulating a CPU in a functional sense, I meant that purely from a performance perspective. The kind of CPU you're emulating is probably well less than 1% the speed what a normal PSP CPU would execute.

 

[lingenfr]

JFR, don't let folks piss on your parade. Thanks for what you are doing.

 

[giovanni]

I never thought that a test can say too much about the emulation capabilities... I only can't wait to see the result in commercial games emulation.
You must keep up the good work

 

[God Ginrai]

JFR, don't let folks piss on your parade. Thanks for what you are doing.

Exophase wasn't raining on his parade, he was just trying to keep other users from expecting too much from JayFoxRox.

-God Ginrai

 

[hlidegp2x]

The fire sample from tyranid is still by far too slow - But thats getting about 60k instructions per second (which means that my console output and / or GU stuff is REALLY slow).

the fire sample is not a good example. It just reads and draws directly in a frame buffer per pixel (average of neighboring pixels colors) which is quite slow and don't even use GE commands. And again, there is no such GU stuff in this example. On the other hand, cube example should run faster because it mainly uses GE commands (which are normally emulated through OpenGL) to draw a cube.

Shadow (PCSX2) and I work on a private psp emulator written in c++ which is able to run Puzzle Bobbles and Blokus Portable. But even with our interpreter they run too fast to be playable because those games probably relies much more on GE work than on CPU work to do all the graphics stuff. They are not playable because we have a very basic hle stuff which doesn't wait for a 60 Hz vblank. Of course, Pandora is not a modern PC so it will be difficult to determine if a fullspeed psp emulation is still doable for most games on a pandora.

 

[JayFoxRox]

First of all a small correction: I checked again and noticed that I read the numbers wrong: its 250.000 Instructions per second and not 25.000. So the fire sample gets 600k while the cube sample gets about 250k.
hlide: Oh, no you got me wrong there. I tried to say that its running too slow because its depends too much on the cpu just like you said it too. BUT seeing how the fire sample gets 600k but the cube sample only 250k (which is not even half the speed of the fire sample) my GE code (which is completly OpenGL ES 2.0 based through the PVR Emulator) or float instructions must slow the cube sample a lot.
I started to implement the fileio and it can open / close files fine (using the correct mode etc.) but it still fails to seek and to write data. This seems to be a (yet another) problem with the CPU emulation because it actually tries to seek and write data a few times with very weird parameters here and there (But I used fopen() in my psp application code so that might be causing the problem, however its more likely that its a CPU problem).

 

[lippy]

First of all a small correction: I checked again and noticed that I read the numbers wrong: its 250.000 Instructions per second and not 25.000. So the fire sample gets 600k while the cube sample gets about 250k.

Lol, don't you just love order of magnitude errors... For once though, it's a nice error to have!!!

 

[Exophase]

Is it executing 250,000/600,000 instructions per second on your PC or on the Pandora?

If you're concerned about inconsistent execution rate of the CPU interpreter then you should consider writing a profiler that determines how often different types of instructions are executed. This could be more useful in the future, especially with regard to optimizing VFPU instructions. You might also want to have a profiler for the HLE'd instructions, although an external profiler can handle that part okay.

 

[JayFoxRox]

No, 250 / 600k on my PC. I still didn't reconnect my beagleboard after breakpoint (I didn't take it with me but I still unplugged and worked with it when I still planned to take it with me).
So far, I m not concerned about speed. I have profiled a few times (using gprof) before but not after switching to OpenGL ES - but profiling on my todo list since some time already, especially the shader related stuff. I won't measure the speed of the interpreted CPU instructions on the PC because the interpreter won't be used on the Pandora (because of the dynarec I m going to add). Its still good to have it because I can see if I understood the instructions and if the emulator behaves correctly before cross-compiling for Pandora. I will only keep the interpreter on the Pandora so I can compare the dynarec results to the interpreter results (which should be used as a reference).

 

[hlidegp2x]

hlide: [...]my GE code (which is completly OpenGL ES 2.0 based through the PVR Emulator) or float instructions must slow the cube sample a lot.

oh yes, I see now : "printing some GU stuff to the console which probably slows down a bit". Not probably, it's really slow. You should have an option to cut off logs or console output, they make the emulation really too slow.

For infos, when we run our interpreter in Debug mode (with logs and console ON), Bobbles and Blokus are slower than they are on a true PSP. When we run them in Release mode (with logs and console OFF), they ran too fast (it looks like 600 fps). So check it without logs and console. Of course, this is on a PC, not on a Beagleboard/Pandora so you might not expect the same speed improvement !

do something like :
CODE

#if NO_LOGGING
#define logf(cat, lvl, fmt, ...)
#else
#define logf(cat, lvl, fmt, ...) LOG_logf(cat, lvl, fmt, ## __VAR_ARGS__)
#endif

 

[Exophase]

No, 250 / 600k on my PC. I still didn't reconnect my beagleboard after breakpoint (I didn't take it with me but I still unplugged and worked with it when I still planned to take it with me).
So far, I m not concerned about speed. I have profiled a few times (using gprof) before but not after switching to OpenGL ES - but profiling on my todo list since some time already, especially the shader related stuff. I won't measure the speed of the interpreted CPU instructions on the PC because the interpreter won't be used on the Pandora (because of the dynarec I m going to add). Its still good to have it because I can see if I understood the instructions and if the emulator behaves correctly before cross-compiling for Pandora. I will only keep the interpreter on the Pandora so I can compare the dynarec results to the interpreter results (which should be used as a reference).


When I said "profile the instructions" I don't mean using gprof on the interpreter, I mean writing your own profiling code to determine the frequency of execution for different classes of instructions. It won't matter if you're not using the interpreter on the Pandora (although I think you will at some point because it's really hard to get a recompiler off the ground from nothing). The types of instructions being executed won't change.

This will give you a good idea of what you need to optimize most in the future. So that you don't waste a lot of time optimizing VFPU instructions that are rarely used.

 

[hlidegp2x]

You might also want to have a profiler for the HLE'd instructions, although an external profiler can handle that part okay.

do you mean SYSCALL instruction to execute an HLE function in native code ? as far as I know, there is no need to HLE'ize anything else.

@JayFoxRox: how do you handle NID functions, do you patch them into "JR $RA; SYSCALL #id" regardless they are user or kernel function to let SYSCALL executes your native code associated to the given NID function ?

 

[Exophase]

Yes, I meant calls to HLE'd functions...

 

[JayFoxRox]

hlide (post 1): Printing is implemented like that and the GU data to the terminal is only information about the vertex buffer address and type + number of polygons etc. I doubt its causing the slowdown. Its probably the extremly long shader which is really slow right now because even disabled features like lighting have to be processed. The textures are also re-loaded every frame.
(With full debug information it takes almost 5 seconds to get to the main() function )
Exophase: Yes, got that before already. But gprof is fine for this too. Ofcourse I m going to optimize the most used functions first.
I will write a small wrapper to make interpreted functions into small dynarec memory blocks so I don't have to implement them all at once.
hlide (post 2): Right now I check if $pc is in the ".sceStub.text" section and get the linked NID from ".rodata.sceNid", then I check if the NID exists in the NID table and execute the required function. Syscalls are also working, though, both syscall and jumps to ".sceStub.text" execute the same function -they know wether they were called by NID or Syscall anyway. But I have to admit that I didn't check what the PSP does - and this gets the job done for testing.

PS: I think this discussion gets a bit too technical for the average forum user so we should move it to IRC or PM/IM if there is need for it

 

[streak]

PS: I think this discussion gets a bit too technical for the average forum user so we should move it to IRC or PM/IM if there is need for it

Please proceed on forum, maybe somebody new add something usefull to the topic, aswell

 

[dflemstr]

PS: I think this discussion gets a bit too technical for the average forum user so we should move it to IRC or PM/IM if there is need for it

Please proceed on forum, maybe somebody new add something usefull to the topic, aswell
...or just continue on the Dev board. It can be quite interesting to read through all this at times.