forums.ps2dev.org

[jas0nuk]

This emu is much better than the old one, and it runs a few retail games and PSPSDK samples.
The author (NOT ME) has released the source as he no longer has the time to continue it:

http://www.dcemu.co.uk/vbulletin/showthread.php?t=62253

Reuploaded archive if you dont have a DCemu account:
http://www.sendspace.com/file/c5ejcu

Hope someone can improve this ;)

[ector]

Yep, I released it yesterday, have fun :)

It's a user mode only MIPS emulator with a bare bones implementation of the PSP OS. No hardware registers are emulated, but display lists are parsed and executed.

The name comes from so-called Potemkin villages http://en.wikipedia.org/wiki/Potemkin_village, since it's just as much fake :)

It runs a bunch of the samples from the PSPSDK, plus a few simple commercial games.

I can't dedicate any more time to it, so anyone who's really bored should continue the project. Either by improving the simulated PSP OS, or adding proper hardware emulation so that some decrypted "Custom Firmware" can be executed.

Both options are pretty damn hard :)
_________________
http://www.dtek.chalmers.se/~tronic/PSPTexTool.zip Free texture converter for PSP with source. More to come.

[noxa]

Good work ector. I've been working on mine on and off for a year and am just now getting to the point where I can run PB (I get to the taito screen, but deadlock after that). I haven't had a chance to look at your code yet, but I appreciate you releasing it to the public!

[hlide]

[jas0nuk]

[noxa]

Yeah, that's the trick. I've found only a handful of commercial games (at least out of the ones that I own) don't have a valid BOOT.BIN. Demos seem to be the ones that most frequently don't have it (or have it zeroed).
Another stumbling point are games that load modules - most games that use modules for game code are fine, as they’re often unencrypted (like Loco Roco or Tales of Eternia), but others do have it encrypted. And then there are the system modules that the games may try to load, which are often encrypted and since they are not included in the firmware no one has dug in to them (so no NID names, etc which makes it harder to reverse engineer them).

One thing I'd like to try, but haven't, is hack up prxdecrypt so that it can build a decrypted ISO. That way you can pop your UMD in your PSP, run the app to decrypt any prxs (and the EBOOT? I don't know if prxdecrypt can do that) and dump the ISO, ready for emulation.

All of these things are far off for me though - I'm still working on getting Super Mario Wars to run :)

[jas0nuk]

If you need to decrypt the EBOOT.BIN (fake BOOT.BIN), use Aenea's decrypter - http://www.psp-hacks.com/file/165
If you need to decrypt game modules, use prxdecrypter 1.3 - http://dl.qj.net/dl.php?fid=13453

For testing purposes of course, as you can't run these decrypters on the emulator until you emulate the semaphore chip :P

[noxa]

Sweet! I remember seeing Aenea's tool. Wish it had source!

Yeah I doubt the security will be cracked any time soon, and I think anyone who is trying to write an emulator is going the HLE approach (as too little is known about the hardware (especially around security) and computers aren't fast enough to simulate it all properly). Since I own a PSP and a large library of games, I don't mind that I'd have to do the decryption myself for any of the encrypted titles; assuming I could write a little tool that does it in one go.

Interesting times, these are. I really wish I would have worked in earnest on my emulator - I may have been able to release it last year if I had!

[hlide]

sure there is very few chance that we can remove HLE because of the PSP hardware for a long time. Some games may use their own sas module for instance. Is there any chance that HLE can intercept this try and offer its sas functions instead of the game's ?

[noxa]

I've got mine setup so that it has a lookaside during module loading. If the module from the game is unencrypted and not in the list, I just load it and this seems to work fine. If it's encrypted or in the lookaside list, it will load from the host machine. I decrypted a bunch of PRXs and stuck them in the list, and this seems to work too (although many fail to run properly because of hardware dependencies).
This is why I'd like to write a tool that automatically decrypts game PRXs to make emulation easier. For now, I just went through a bunch of my games, pulled the common PRXs, and dumped all those.

Ideally, the 'hard' modules (like ones that use the ME CPU, etc) would be implemented in by the host, while the 'easy' ones (like sceHttp) would use the native PRX. This way there's the greatest chance for compatibility (no need to reimplement tricky behavior) without requiring perfect hardware simulation or reimplementation of everything.
There are exceptions, of course. I implement the MT19937 random number generator in host code, even though I could trivially load the PRX, just because the more code I can run native without the need for translation, the better.

I'd love to emulate the ME core one day, however too little is known about it now to do it for all but the simplest cases.


I had a chance to look at the code for ector's emu. It's pretty neat. It's funny how similar it is to my own in many of the areas :P

[hlide]

humm...

i was thinking about something.

it would be interesting to be able to generate some HLE code from an xml (psplibdoc.xml) for instance.

A first generation would generate either a dummy HLE source for each module where each function would have a __attribute__(weak, alias(sceFunctionNotImplemented)) or a HLE source to fill with the right code.

that way it would be more easy to trace any function

[noxa]

I did that - it makes things A LOT easier. I actually went one step further: I get a list of all modules and NIDs from libpspdoc.xml, then for each one search in the pspsdk header files for the function definition. This allows me to generate complete source files with arguments and everything. I even pull out the comments describing each function, however I don't write those out yet. The tool will even write out hashes of the generated code, so when re-run over new versions of the sdk it can tell you when the contents changed. It's pretty flexible (I have it set up to write out both C++ and C# code), so if anyone wants to abuse it, go for it. You can find the code in the site linked below.

ex:

[ector]

Wow, noxa, you seem to be a bit more ambitious than me (even though I'm the only one of us who can run games...) ;)

Feel free to rip and steal as much as you want from Potemkin, I'll even grant you a personal license so you don't have to follow the GPL if you don't want to for some reason (I see you prefer LGPL).

You seem to completely lack GE emulation for example...

[noxa]

Haha yeah :P

Thanks!
I went with the LGPL just because I wanted to give people the ability to write plugins without releasing the source. Not that anyone but me will ever write a plugin...

I've got a GE impl - it's in a separate plugin. It needs a little tweaking, but runs ok. All of my machines are dual core, so I've got it set up to be multithreaded, running through the lists in another thread.
There are some things pending checkin that allow for stuff like ge callbacks to work right, as well as a bunch of texturing tweaks.

I've got some screenshots here: http://code.google.com/p/pspplayer/wiki/Screenshots
although until I get PB running, I'm a loser :)

[hlide]

you seem to code it in C#, is it because you plan to have a PSP emulator for XBOX 360 too ?

[J.F.]

You might also want to keep the Windows specific stuff separated so that it would be easier for a linux port to mono.

[noxa]

Yeah I have everything componentized and everything is fairly portable.... kind of. The current CPU and video plugins are written in C++/CLI, and mono doesn't (yet) support that. There's been talk of a gcc mod, and a google summer of code entry, but nothing that works.
The frontend is fairly easy to replace - I have both a command line and WinForms frontend, with the command line one clocking in at about 150 lines of code.

After I get things working, I plan on going back and sprucing up my C# dynarec (that emits MSIL) and rewriting the video driver (as it is pretty 'experimental' - read: crap) as well. Then the emulator should be able to run, with little to no modification, on any platform mono runs on (getting the advantages of 64-bit and all, too).

One complication is that it's not possible to use SSE from MSIL. Unless things scream without it, it could present a problem.

[noxa]

Wooo, Puzzle Bobble working in mine now :)

http://code.google.com/p/pspplayer/wiki/Screenshots

[Cpasjuste]

Hehe good work and good luck noxa :)

I'm really looking at this to be able to test my code at work without having the psp sitting around.

[J.F.]

[Cpasjuste]

Hehe thanks for the adivce.

[noxa]

[Cpasjuste]

[GPF]

noxa, great job. I got your source compiled and played some psptris and started TrigWars, not quite sure of the keyboard to psp control scheme yet so i didn't go any further.

To test and see if any of my homebrew will work with it, do i need to convert the eboot.pbp to a particular format? i've discovered it won't load homebrew i copy from my 1.50 psp to the Test Stick folder get errors about it parsing the pbp file.

Thanks,
Troy(GPF)
http://gpf.dcemu.co.uk

[noxa]

I set up some Google groups:
http://groups.google.com/group/pspplayer-general?hl=en
http://groups.google.com/group/pspplayer-dev?hl=en
You can also join me in #pspdev (on FreeNode) if you have any questions.

[hlide]

hi noxa

i'm trying to follow your progress with pspplayer, but it seems your svn source is empty !?

did you abandon this project ?

[Test30]

Thanks

[Warren]

Bump.

I just got back into some PSP Dev and picked up your EMU source. I implemented v1.5 kexploit support and fixed a bug around not having the umd device defined at all.

Current SVN doesn't seem to want to work at all in Release mode, only Debug.

[Wraggster]

great to see some activity on this project. any chance of a compiled release at some stage ?
_________________
Webmaster of http://www.dcemu.co.uk

DCEMU The Worlds Only Homebrew & Gaming Network of Sites.