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 ;)
PSP Emulator for Windows, author releases src
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 :)
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.
Re: PSP Emulator for Windows, author releases src
huh are those retail games encrypted ? I thought the main obstacle about running retail games on an emulator is because their ebout.pbp are encrypted. Can you explain me how it is possible ?jas0nuk wrote:it runs a few retail games
Re: PSP Emulator for Windows, author releases src
From reading the compatibility list it looks as if he is loading them via BOOT.BIN which is usually decrypted in most ISOs, but in some it's a fake zeroed file.hlide wrote:huh are those retail games encrypted ? I thought the main obstacle about running retail games on an emulator is because their ebout.pbp are encrypted. Can you explain me how it is possible ?jas0nuk wrote:it runs a few retail games
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 :)
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 :)
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
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
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!
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!
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
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
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
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
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:
My HLE bios is written in C#, so I get to use a whole lot of fun .NET things; in this case, reflection.
My current stats, spit out on startup, are as follows:
Bios: found 437 functions in 29 modules. 194 (44.39359%) implemented.
I ignore _driver modules and some others. There are a few modules missing (specifically the net ones), and some are missing functions.
You can see the code:
http://dev.ixtli.com/pspdev/browser/tru ... LE/Modules
I also have a nice reporting tool that allows me to spit out XML docs describing what is/isn't implemented. I wrote a tool that then runs over all ISO's in a directory and writes out their XML. This allows me, with a little script, to see the functions most commonly used that aren't implemented, etc.
I've also got the start of a web-based compat. database (although it's not hosted publicly). It takes these XML files via webservice calls and will allow one to browse the site to see if something has a chance to work, submit the reports when a game is loaded, or even query the service to see if a game is known to work or not and the proper configuration required.
All of this, of course, pending my emulator actually running a real game ;)[/code]
ex:
Code: Select all
[NotImplemented]
[Stateless]
[BiosFunction( 0x9AE849A7, "sceAtracGetRemainFrame" )]
// SDK location: /atrac3/pspatrac3.h:55
// SDK declaration: int sceAtracGetRemainFrame(int atracID, int *outRemainFrame);
public int sceAtracGetRemainFrame( int atracID, int outRemainFrame ){ return Module.NotImplementedReturn; }
My current stats, spit out on startup, are as follows:
Bios: found 437 functions in 29 modules. 194 (44.39359%) implemented.
I ignore _driver modules and some others. There are a few modules missing (specifically the net ones), and some are missing functions.
You can see the code:
http://dev.ixtli.com/pspdev/browser/tru ... LE/Modules
I also have a nice reporting tool that allows me to spit out XML docs describing what is/isn't implemented. I wrote a tool that then runs over all ISO's in a directory and writes out their XML. This allows me, with a little script, to see the functions most commonly used that aren't implemented, etc.
I've also got the start of a web-based compat. database (although it's not hosted publicly). It takes these XML files via webservice calls and will allow one to browse the site to see if something has a chance to work, submit the reports when a game is loaded, or even query the service to see if a game is known to work or not and the proper configuration required.
All of this, of course, pending my emulator actually running a real game ;)[/code]
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...
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...
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 :)
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 :)
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.
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.
You need to be careful... most employers have a policy in the contracts that any work done at work belongs to them. Many have policies that even work done at home belongs to them (I had to have my last employer specifically remove that part before I'd sign).Cpasjuste wrote: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.
Yeah, I did the same thing - I just put down generic names for all the kinds of projects I'd want to work on; 'emulator', 'AI test', 'Xbox game', etc - the fact that I work for an internet startup with an awesome boss means that I'll never get in trouble, anyway!J.F. wrote:You need to be careful... most employers have a policy in the contracts that any work done at work belongs to them. Many have policies that even work done at home belongs to them (I had to have my last employer specifically remove that part before I'd sign).
Hehe same here, no problem with this :)noxa wrote:Yeah, I did the same thing - I just put down generic names for all the kinds of projects I'd want to work on; 'emulator', 'AI test', 'Xbox game', etc - the fact that I work for an internet startup with an awesome boss means that I'll never get in trouble, anyway!J.F. wrote:You need to be careful... most employers have a policy in the contracts that any work done at work belongs to them. Many have policies that even work done at home belongs to them (I had to have my last employer specifically remove that part before I'd sign).
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
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
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.
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.