Release Pandora-PSP

[JayFoxRox]

Moved back to: http://www.gp32x.de/board/index.php?showtopic=47270
Major updates can be found at: http://jayfoxrox.bplaced.net/pandora-psp/

 

[M.J.B.]

Holy mother of god it's a PSP emu... Wait a second thats not even possible for a computer yet. How is it possible for pandora fullspeed? if it does work though... who will make the roms?

 

[second exodous]

Holy mother of @!* it's a PSP emu... Wait a second that's not even possible for a computer yet. How is it possible for Pandora full speed? if it does work though... who will make the roms?

torrents....

EDIT: Wait a second, there are emulators for PSP, not as developed as emulators for the DS but that's because not as many people want to emulate it.

Click the links, JayFoxRox is coding one, but I'm sure he is grateful for your vote of confidence M.J.B.

I for one applaud you JayFoxRox.

 

[Exophase]

Holy mother of @!* it's a PSP emu... Wait a second that's not even possible for a computer yet. How is it possible for Pandora full speed? if it does work though... who will make the roms?

torrents....

EDIT: Wait a second, there are emulators for PSP, not as developed as emulators for the DS but that's because not as many people want to emulate it.

Click the links, JayFoxRox is coding one, but I'm sure he is grateful for your vote of confidence M.J.B.

I for one applaud you JayFoxRox.

I would hazard a guess that there are more people working on PSP emulation than DS emulation. It's not as far along because it's a spectacular amount of work. HLE of this level is an enormous burden.

 

[second exodous]

JayFoxRox said on the forum he linked to that it would be harder to write a DS emulator. There are lots of PSP emulators, but aren't quite done yet. I just know a lot more people with the DS, Nintendo has sold millions more DSs then Sony has PSPs, so I would assume more people are working on DS emulators.

But it looks like JayFoxRox's PSP emulator is coming along great, so I'm excited. I searched the thread on gp32x and couldn't find what one would need to have to help him but if all I need is Linux I'd like to help him as I use Linux right now. The more people that help the faster it will get to a playable state.

 

[Exophase]

JayFoxRox said on the forum he linked to that it would be harder to write a DS emulator. There are lots of PSP emulators, but aren't quite done yet. I just know a lot more people with the DS, Nintendo has sold millions more DSs then Sony has PSPs, so I would assume more people are working on DS emulators.

That is of course his opinion and he's entitled to it, but there's not really an authoritative answer, only differing opinions amongst informed individuals. However, bear in mind that I said that I find PSP emulation to be more work, not harder. There is a difference.

The approach he is taking in writing a PSP emulator (the same approach all PSP emu authors have taken, really the only viable one right now) is very different from the more traditional approach people have taken when writing DS emulators (where you can HLE much less anyway). It's difficult to compare them, but it's worth noting that really no one has done an emulator with a lot of OS level HLE, for an extensive OS, that also plays a large number of commercial games. The closest are the two XBox emulators, and as far as I'm aware they both play about one commercial game each. Said XBox emulators also have the advantage of being able to run x86 code natively without needing the extensive recompiler work in order to get PSP's CPU and especially its VFPU emulated. They're also wrapping from an offshoot of Windows to actual Windows, which is more of a natural fit than HLE'ing PSP's OS. Essentially an entire operating system has to be written for PSP emulation, and it has to conform closely to the original PSP one in design. That's not an easy thing to pull off. On the other hand, with PSP emulation you don't have to worry about a wide pool of differing SDKs to HLE since the latest firmware is universal and has to be compatible with all games.

DS has a lot of hardware, but it's pretty well documented. A GBA emulator is also halfway there.

 

[second exodous]

Oh, I mixed up 'harder' and 'more work' like you said. Yeah, I have no idea what you're talking about, now I don't know if I could be of any help to JayFoxRox.

I was looking at some PSP games just to know what the PSP had and they have a lot better games than I remember two years ago, I hope this drives more PSP emus. I'd also think a PSP emulator would make more sense than a DS emulator on the Pandora.

 

[Kramy]

Explanation...

Sounds no harder than creating the first java virtual machine!

Good luck!

 

[second exodous]

Sounds no harder than creating the first java virtual machine!
Good luck!

JayFoxRox seems to have a pretty good handle on it, go here and read up on it. I'm glad there are determined and smart(genius) people to get things up and running on the Pandora.

 

[M.J.B.]

sorry for my last comment, didn't mean for it to be rude, i just didn't think psp emulation would be possible on a p&|a. sorry

 

[JayFoxRox]

M.J.B.: I didn't think it was rude, but whatever floats your boat.. I never said (and if I did it was not meant that way) that ALL applications will run fullspeed. But games which are not too cpu hungry should work fine. And what roms do you mean? There is a huge amount of homebrew apps and you can dump UMDs without much trouble these days
second.exodous: There are tons of PSP Emulators out there and some are really stable already (which doesn't really mean that they play alot of software)

Answering questions for an interview atm and writing a new entry for the homepage.

 

[Exophase]

M.J.B.: I didn't think it was rude, but whatever floats your boat.. I never said (and if I did it was not meant that way) that ALL applications will run fullspeed. But games which are not too cpu hungry should work fine. And what roms do you mean? There is a huge amount of homebrew apps and you can dump UMDs without much trouble these days
second.exodous: There are tons of PSP Emulators out there and some are really stable already (which doesn't really mean that they play alot of software)

Answering questions for an interview atm and writing a new entry for the homepage.

The question is, what games are actually going to be "not too CPU hungry." Sure there are some like Puzzle Bobble that use very little CPU, but are these the games that people are going to really want to play? I expect that typical 3D games will invest a good portion of CPU time in processing triangles before spitting out display lists, especially since PSP is poor at blitting. If the game does T&L using the VFPU (that's what it's there for afterall) then the CPU load will probably be high as well. I also hear that audio mixing on the kernel results in a lot of CPU time used - this wouldn't necessarily mean much if you're HLEing it, but if it was so poor on the PSP then you'll probably see people doing various audio things in their own software routines instead of using the firmware.

Of course, as I mentioned before, many 3D games will probably be able to maintain relative game speed, audio speed, etc while being shortchanged of a lot of cycle time. They'll just end up rendering at less fps. With the HLE OS approach of PSP emulation you'll have to generate vsyncs at real time anyway, so it'll be interesting to see how things run. On the downside, this also means that if a game absolutely requires more CPU than you give it, either intentionally or unintentionally, it'll flat out break rather than just run more slowly.

 

[M.J.B.]

M.J.B.: I didn't think it was rude, but whatever floats your boat.. I never said (and if I did it was not meant that way) that ALL applications will run fullspeed. But games which are not too cpu hungry should work fine. And what roms do you mean? There is a huge amount of homebrew apps and you can dump UMDs without much trouble these days
second.exodous: There are tons of PSP Emulators out there and some are really stable already (which doesn't really mean that they play alot of software)

Answering questions for an interview atm and writing a new entry for the homepage.

OK... That would be awesome man, keep going

 

[JayFoxRox]

You should expect the new homepage entry tomorrow or so as I m not in the mood to do anything right now.
I have fixed alot bugs today but there are still some left.
However, I decided to pause this project for a while. I planned to have this ready for the Pandora release but that was delayed again and I don't want to spend all my time on this. Its always better to have something more "standard" in the portfolio and this is why I'm going to work on my engine and a new game (thread will follow in the near future I think) for the Pandora.
Its also very depressing to get stuck so often. Its a trial and error approach once you have a bug in your emulator - and I have lots of them.
I will still try to port to the beagleboard this weekend (more in the next news entry), just don't expect too many updates and progress on the emulator itself in the next few weeks. Ofcourse you can still ask questions or so and I will answer. I might be getting a video too if I'm boored
Another reason is that I got rendermonkey to work on my PC through wine - which didn't work 2 month back when I started with Pandora-PSP.

I might give away the source code if someone wants to continue while I do something else. (don't expect too much tho. It started with a really dirty test and grew a lot after that, alot of code is slow and dirty. Almost no comments in the whole code etc.)

Exophase: I tried ATV Offroad Fury Pro yesterday and it worked absolutly fine at the 75MHz setting of M33. Take notice that the system calls are probably also slower. The menu and the loading screens were really slow but as soon as you are able to play it runs without any problems. Just to name one game which SHOULD be possible which is still fun to play - its probably the game I played most besides Burnout and Flatout.

PS: I noticed that I'm a guru group member now, thanks for that, but I still laugh at it at times

 

[fischju]

Wow, that is great progress! I look forward to reading that blog post, and good luck with your other endeavours.

 

[Exophase]

Exophase: I tried ATV Offroad Fury Pro yesterday and it worked absolutly fine at the 75MHz setting of M33. Take notice that the system calls are probably also slower. The menu and the loading screens were really slow but as soon as you are able to play it runs without any problems. Just to name one game which SHOULD be possible which is still fun to play - its probably the game I played most besides Burnout and Flatout.

That's interesting information. Did you notice a degredation in frame rate? I wonder how much that particular game uses the VFPU.

 

[JayFoxRox]

This was made using a small bubble-sorted array which logs (not at runtime but by checking every long in the .text section) how often each instruction appears in ATV Offroad Fury Pro:

--- Results for '.text' ---
0 unknown instructions, 1400918 instructions in total
lw: 246602 
addiu: 167566 
sw: 149495 
or: 149286 
jal: 89647 
ori: 62686 
lui: 62260 
beq: 56164 
addu: 45588 
jr: 31928 
nop: 30613 
lwc1: 23475 
swc1: 21518 
bne: 20978 
lv.q: 17007 (not implemented)
andi: 14558 
sv.q: 13233 (not implemented)
mtc1: 12972 
sll: 12710 
lh: 12620 
jalr: 12383 
beql: 10835 
sb: 9586 
mov.s: 8009 
sltu: 7624 
vmov.t: 5775 (not implemented)
mul.s: 5355 
sltiu: 5343 
bnel: 5084 
slt: 4687 
lbu: 4519 
mfc1: 4433 
slti: 3628 
subu: 3532 
sh: 3286 
and: 2935 
vmov.s: 2885 (not implemented)
add.s: 2806 
ins: 2792 
mtv: 2506 (not implemented)
j: 2498 
c.lt.s: 2408 
sub.s: 2401 
srl: 2389 
lhu: 2297 
lb: 2214 
c.le.s: 2129 
sv.s: 2066 (not implemented)
xor: 1990 
lv.s: 1898 (not implemented)
sra: 1834 
bc1f: 1748 
bc1t: 1691 
trunc.w.s: 1441 
div.s: 1111 
mfv: 1088 (not implemented)
cvt.s.w: 1046 
bc1t1: 980 
mflo: 902 
xori: 872 
vscl.t: 853 (not implemented)
bc1fl: 759 
bltz: 720 
blez: 706 
vdot.t: 705 (not implemented)
c.eq.s: 642 (not implemented)
vadd.t: 641 (not implemented)
neg.s: 640 
mult: 620 
bgez: 613 
vtfm3.t: 603 (not implemented)
vsub.t: 579 (not implemented)
vmov.q: 577 (not implemented)
ext: 493 
bgtz: 453 
swr: 435 
swl: 435 
lwr: 363 
vpfxs: 359 (not implemented)
sllv: 357 
movn: 351 
lwl: 350 
movz: 320 
div: 289 
nor: 288 
vzero.t: 270 (not implemented)
bltzl: 221 
mfhi: 220 
vsqrt.s: 190 (not implemented)
srav: 173 
vcrsp.t: 153 (not implemented)
divu: 150 
vrsq.s: 122 (not implemented)
vscl.q: 120 (not implemented)
blezl: 120 
vmul.q: 117 (not implemented)
vf2iz.q: 99 (not implemented)
vmin.q: 99 (not implemented)
vtfm4.q: 96 (not implemented)
bgtzl: 91 
vrcp.s: 89 (not implemented)
vhtfm4.q: 88 (not implemented)
vneg.t: 81 (not implemented)
bgezl: 81 
vadd.s: 77 (not implemented)
sqrt.s: 76 (not implemented)
vadd.q: 71 (not implemented)
vnop: 68 (not implemented)
vpfxt: 65 (not implemented)
srlv: 56 
vf2h.p: 55 (not implemented)
mfvc: 54 (not implemented)
rotr: 51 (not implemented)
vcmp.t: 49 (not implemented)
break: 47 (not implemented)
vcmp.s: 41 (not implemented)
bvt: 41 (not implemented)
vmax.t: 37 (not implemented)
vmin.t: 37 (not implemented)
vsub.q: 34 (not implemented)
vzero.s: 30 (not implemented)
vmul.t: 29 (not implemented)
seb: 27 
multu: 27 
vsub.s: 25 (not implemented)
vzero.q: 24 (not implemented)
vf2h.q: 23 (not implemented)
vhdp.q: 23 (not implemented)
vqmul.q: 19 (not implemented)
sv.q: 16 (not implemented)
vcmp.q: 16 (not implemented)
seh: 15 
vmul.s: 14 (not implemented)
vflush: 13 (not implemented)
vsync: 13 (not implemented)
vabs.t: 13 (not implemented)
sync: 12 (not implemented)
bvtl: 11 (not implemented)
vi2s.p: 8 (not implemented)
wsbh: 8 
min: 7 
max: 6 
vabs.q: 5 (not implemented)
vrot.q: 4 (not implemented)
vh2f.s: 4 (not implemented)
vf2iu.q: 4 (not implemented)
vrcp.t: 3 (not implemented)
cache: 3 (not implemented)
vh2f.p: 2 (not implemented)
vcst.s: 2 (not implemented)
wsbw: 2 
vslt.t: 2 (not implemented)
vneg.s: 1 (not implemented)
vone.t: 1 (not implemented)
vi2f.t: 1 (not implemented)
vf2iz.t: 1 (not implemented)
vmul.p: 1 (not implemented)
add: 1 
73 instructions are not implemented

Every known instruction which appears more than once in the .text section is listed. The unknown instructions include all VFPU instructions and a few float instructions, cache instructions and 8 other instructions. Looks like 1/3 instructions is a VFPU instructions. Surprisingly high I think, but its probably a bunch of instructions in a row which can be optimized as they will be matrix functions or so.
I wrote the instruction counter in a rush and it might have some errors in it. Its also possible that some instructions are never called and / or the memory is not initialized here and there.

//Edit:
Post updated. I'm also showing the non implemented instructions now so I have a general idea on how much work is left to get the game running (in theory).
Ofcourse this is no good indicator how many VFPU instructions are executed at runtime (because it could loop either alot of integer/float or vector instructions a few hundred times a frame while another memory location is seldomly (or never) reached) but its still pretty interesting imo.
And I forgot to mention it before: fullspeed gaming with no stuttering or anything at 75MHz - Worked just like 222MHz and greater.
The game doesn't even get into its own thread if I try to emulate it. So that will require further investigation (but thats not going to happen in the next weeks ). I have another buggy testcode which worked fine before and I would assume its the same instruction which makes problems.

 

[Exophase]

Thanks, but I regret to say that a static analysis is pretty meaningless since what happens at runtime is going to be MUCH different. You know, that 10% of code taking 90% of the time and all that stuff.