[Project] Cross-Platform PSP Emulator for PC

[MFZ007]

Hi all!

I'm currently working on a PSP Emulator for PC. After having seen the great progress of noxa and soywiz with their emus I decided I wanted to do it slightly different and try to keep the Emulation as Low Level as possible.


Here in my Dev-Blog you can check out the code via a svn mirror or you can browse it Here.

It's in early stages and I've written the MIPS Core + FPU and I'm currently writing the VFPU instructions.


Now to my main question: This is still far away but, as for the boot-process of the PSP with the decrypting of the IPL through the KIRK SecChip and so on. Is there a way to get the Bootstrap commands so I could later on implement them in the emulator or will I have to do this differently?

Hope you guys can help me out :)

Greets
Mauro

[hlide]

I'm also planning to make a PSP emulator for PC and maybe Pandora.

I rewrote from scratch a R3000 dynarec (c++) for PSP and ARM (zodttd uses my very old recompiler/generator I rewrote for his psx4gp2x/psx4iphone). Zodttd were supposed to work with me to bring yapse4all in life but he seems to be very busy with all the other ports he makes.

It wouldn't be difficult to make a PSP dynarec for PC as well : I just need to write the appropriate generator.

I intend to reuse my new dynarec and to extend it to a PSP dynarec (CPU/FPU/VFPU) to make a PSP emulator. But it must be fast and don't need to deal with low emulation of hardware unlike PSX.

I think HLE is the best strategy to emulate PSP because it would be faster and hardware emulation is beyond question due to the lack of documentation about hardware.

But HLE is probably hell to build since we need to reverse any kernel modules to emulate functions accurately.

So, my question is how far you want to keep the emulation low level ?

[MFZ007]

I've thought about that too and I know it's not yet possible to complete a Low Level Emulator but I didn't mean this project to be completed any time soon anyway. I guess the final goal would be to get a Firmware to run correctly. Of course HLE would be faster to realise but my main interest is on the hardware emulation anyway :) Maybe as soon as I can no longer continue with the VFPU or any other component I'll think about making a HLE branch and try to make things work until more hardware-information is revealed.

with your dynarec do you recompile the VFPU instructions into normal MIPS instructions?

[hlide]

I've thought about that too and I know it's not yet possible to complete a Low Level Emulator but I didn't mean this project to be completed any time soon anyway. I guess the final goal would be to get a Firmware to run correctly. Of course HLE would be faster to realise but my main interest is on the hardware emulation anyway :) Maybe as soon as I can no longer continue with the VFPU or any other component I'll think about making a HLE branch and try to make things work until more hardware-information is revealed.

ok, let me tell you there is no way to get a firmware to run correctly. Don't ask why, I'm not a specialist about firmware hacking but I do know there is a lot of hardware we cannot emulate because we don't have the details and because you CANNOT emulate KIRK to encrypt/decrypt blocks for instance : this issue is probably enough to state it is impossible to run a firmware on an emulator.

with your dynarec do you recompile the VFPU instructions into normal MIPS instructions?

huh ? just a minute. I have a R3000 dynarec for PSP and ARM, that I can turn into a PSP dynarec by extending it with allegrex/fpu/vfpu instructions and writing a x86 generator (to make it running on PC). I'm not in hurry to make it because I need to investigate if it is easy to make a compatible HLE for most games to run properly.

My real challenge would be able to make a PSP emulator on Pandora (an ARM cortex-a8 with OpenGL ES 2.0).

[MFZ007]

Ok, I got it this time ^^

Is there no way to get the already decrypted data from KIRK on the PSP itself and make a dump? I'm not really into PSP-Development itself so I don't know if there's a way to access KIRK.

[hlide]

Ok, I got it this time ^^

Is there no way to get the already decrypted data from KIRK on the PSP itself and make a dump? I'm not really into PSP-Development itself so I don't know if there's a way to access KIRK.

KIRK is a hardware piece, not a software piece. The algorithm used by this hardware piece is totally unknown for public.

If your question is about to avoid the use of KIRK, I suggest for you to hack a firmware to do so before writing an emulator able to run a (hacked) firmware.

[MFZ007]

yes of course. I understand why KIRK can't be emulated (for obvious reasons) but the firmware itself, does it have functions that allow interaction with the chip in any way?

[adrahil]

You'll run into hardware problems, as there is some critical hardware for emulation we don't know a lot about:
- thread management
- exception management
- audio
- GE
- ...

But you're right in the fact that you can use already pre-decrypted firmware files.

[hlide]

yes of course. I understand why KIRK can't be emulated (for obvious reasons) but the firmware itself, does it have functions that allow interaction with the chip in any way?

it DOES ! so it can load crypted modules for instance

and what about AVC codec and Audio images loaded on ME processor. There is a Media Engine which uses an unknown hardware accelerator. How do you plan to emulate them ? (in fact, you may also need to emulate two processors) or even a third processor (an ARM ?) to emulate Wifi controller ?

[MFZ007]

You'll run into hardware problems, as there is some critical hardware for emulation we don't know a lot about:
- thread management
- exception management
- audio
- GE
- ...

But you're right in the fact that you can use already pre-decrypted firmware files.

Yeah, I guess i will, and I see now that I'll probably have to get into HLE because of it. Surely for Audio ^^ I do not plan to emulate the decoder unit for atrac3 what would be the point...

it DOES ! so it can load crypted modules for instance

and what about AVC codec and Audio images loaded on ME processor. There is a Media Engine which uses an unknown hardware accelerator. How do you plan to emulate them ? (in fact, you may also need to emulate two processors) or even a third processor (an ARM ?) to emulate Wifi controller ?

You certainly know how to crunch my hopes and dreams, don't you :) But you're right. It will get nasty eventually.

[hlide]

it DOES ! so it can load crypted modules for instance

and what about AVC codec and Audio images loaded on ME processor. There is a Media Engine which uses an unknown hardware accelerator. How do you plan to emulate them ? (in fact, you may also need to emulate two processors) or even a third processor (an ARM ?) to emulate Wifi controller ?

You certainly know how to crunch my hopes and dreams, don't you :) But you're right. It will get nasty eventually.

well, I'm sorry :). In fact, is there a reason you absolutely need to run a firmware on a PSP emulator ? My opinion is a HLE would be far easier to do than a true hardware emulation because PSP has a much more complex and nasty hardware than the old consoles.

[MFZ007]

No particular reason really. Just interested if it would work. But I think I'll finish the core (Allegrex) first and then decide how to proceed. But it seems as if it's going to be HLE after all. What a pity.

[kralyk]

The bad thing about this is that HLE emulator would be useless for debugging homebrew...

[MFZ007]

exactly. that would be THE advantage of LLE I think.

[hlide]

The bad thing about this is that HLE emulator would be useless for debugging homebrew...

kernel homebrew, you mean. As long as you don't try to trick the firmware, it should be okay with user homebrew.

[MFZ007]

kernel homebrew, you mean. As long as you don't try to trick the firmware, it should be okay with user homebrew.

Yeah, I think so too. But this is not about justifying my way of wanting to do an LL-Emu. I'll certainly try to keep it as Low Level as possible. But I agree with hlide saying it's impossible atm.

[hlide]

If you want to make a PSP emulator to help debugging homebrew or firmware, you may try for a pc to drive a psp. Code could be run on PC or PSP as you wish. Of course, when hardware is implied you have no choice else to run on PSP. It would be in fact a debugger/emulator. Maybe studying psplink may help to make it realizable at a finer granularity.

oh well, probably a fantasy !

[MFZ007]

Yep, probably true.

I'll have a look at psplink but my thought is that it's beyond the things I want to/could do.

One thing is sure: I'll keep asking questions here :)

[hlide]

kernel homebrew, you mean. As long as you don't try to trick the firmware, it should be okay with user homebrew.

Yeah, I think so too. But this is not about justifying my way of wanting to do an LL-Emu. I'll certainly try to keep it as Low Level as possible. But I agree with hlide saying it's impossible atm.

with a HLE, there is two possibilities :

1) to emulate only the kernel modules where hardware are directly implied : most modules would then be in target binary format (they need to be decrypted first of course). This solution may lead to a slower execution but would be more friendly to compatibility.

2) to emulate the higher level modules as possible : most modules would then be in host binary. This solution may lead to a faster execution but would be less friendly to compatibility because it means you would probably don't emulate the intermediate user and kernel modules which are normally only called from user modules that a psp application uses.

note that kernel homebrew modules dealing with direct access to hardware address are still forbidden

[MFZ007]

Now that it's clear that HLE will be a must I'll clearly want it this way:

1) to emulate only the kernel modules where hardware are directly implied : most modules would then be in target binary format (they need to be decrypted first of course). This solution may lead to a slower execution but would be more friendly to compatibility.

[MFZ007]

Hey!

Back again with a question!
Since our project ist Open-Source already, I'd like to ask if some of you guys would be interested in helping us completing the seperate parts of the emulator. You would have direct access to the main svn repository. And of course would be named in the credits ^^.

I'm still working on the VFPU atm so there are other things you could do if you wanted to:

- GE basic structure
- basic HLE-Functions (threading etc..)
- File-Loader (implementing support for pbp, images and so on)
- Unix/Linux GUI, since this project is meant to be multi-platform

It's just a huge load of work and the time draws near where I have to study for University again. So I'd gladly appreciate any help I got :)
We currently work with eclipse cdt as IDE (because it runs on linux/osx as well). The instructions to set up the compiler with eclipse are posted in the Dev-Blog.
Hope someone is interested.

This projects means quite a lot to me so please, if you are just beginning to learn how to program, please don't sign up for this yet.
Looking forward to working with you guys.

If you want to take a look at the code, the link to the svn repository is in the Dev-Blog.

Greetings

[MFZ007]

If you want to have a look at the Win32 GUI

Check out the Dev-Blog

The GUI was created by Stefan Zurfluh.

If you're a Linux coder and are interested in designing a similar GUI for Linux or OSX let me know.

[paco.]

Hlide something new?
bye!!

[hlide]

Hlide something new?
bye!!

AFAIK I'm not related with this project

[paco.]

Sorry for my mistake.
MFZ007 something new?

[MFZ007]

I wouldn't say theres big news.
I'm still working on it and will continue working, I've been in Spain for 2 weeks now and I'm getting back on Monday. I'll get working again by tuesday I think. So far it has been a lot of fun and I've met some interesting people.

If you want to see a little bit older revision of the code, search MFZPSP in google code.

---
Mauro

[paco.]

OK thanks I will look