PSPSOne or PSPcsx?

[PacManFan]

Howdy everyone, PacManFan here.

I've been hacking away for the past 2 days on the open source PCSX Playstation emulator, trying to get it to run on the PSP.
I've finally had a little success.

Here's a bad screen shot of a demo running.

Before anyone says anything about the pitch being off, I know, I'm still figuring it out.



Before anyone asks:
1) it runs at about 1fps in the emulator
2) No, I haven't put it on my PSP yet, I'm still at work.
3) No, I haven't tried Game XYZ on it yet.
4) No, there is No sound, No controls, No way to specify roms yet.
5) After a little cleanup, I'll make the code available

Here's a todo list:
1) Find some volunteers to work on this with me.
2) put in a microwindows rom selector
3) put in mapped controls
4) add sound
5) Code a new recompiler for the r4000 chipset, right now there is the x86 and sh4 chipset <- this is a big one!
6) optimize the H3ll out of this.

Comments?

-PMF

[Mike/Pippin]

Looks great. I think its the first PSX emu that Ive seen screenshots of. Hopfully you can get it going good as a PS1. Cant wait to play SaGa Frontier

[Mangus]

PMF yet agian you rock, i fell sorry for your social life, always hard working you are, a devers life at best i guess ;)

[Tim]

You mention "Code a new recompiler for the r4000 chipset"... this may be a stupid comment but.... if PSX is an r3000 and PSP is an r4000... seems like it could be done pretty efficiently. Is r3000 a subset of r4000, or is the architecture different enough that it wouldn't be a simple translation?

[crazyc]

You mention "Code a new recompiler for the r4000 chipset"... this may be a stupid comment but.... if PSX is an r3000 and PSP is an r4000... seems like it could be done pretty efficiently. Is r3000 a subset of r4000, or is the architecture different enough that it wouldn't be a simple translation?

This is a tricky proposition especially on an arch without (as far as I can tell the PSP lacks) a proper TLB.

[PacManFan]

I think writing this recompiler (actually a binary translator) shouldn't be too hard. I believe that r3000 is a subset of r4000 code. No instruction code translation is really necessary. I can let the code execute natively up until a CALL or JUMP statement. For a call or a jump, addresses need to be remapped.

One other thing I didn't put in my to-do list is putting in PSP GE calls to subsitute for the PSX GPU calls.

If I can write this binary address translator, and replace GPU calls with GE calls, this emulator will run full speed or better.

I'll post more screen shots later and report if I can get this running on my PSP, and not just the PSPEmu.

-PMF

[ector]

Keep in mind that you need to translate memory accesses. Can't let any sw or lw execute natively, you need to replace them with calls to memory read/write functions..

What GFX plugin are you integrating?

[PacManFan]

Well, for the plugins, I decided to compile them in with the app. So, they're not really plugins anymore, because they can't be swapped out without recompiling. I'm using P.E.O.Ps GPU plugin, and null stubs for SPU and pads. I've written a primitive CDR plugin for accessing BIN and ISO's from the memory stick.

-PMF

[mrbrown]

I think writing this recompiler (actually a binary translator) shouldn't be too hard. I believe that r3000 is a subset of r4000 code. No instruction code translation is really necessary. I can let the code execute natively up until a CALL or JUMP statement. For a call or a jump, addresses need to be remapped.

Boy, you are in for a world of hurt.

[crazyc]

Keep in mind that you need to translate memory accesses. Can't let any sw or lw execute natively, you need to replace them with calls to memory read/write functions..

cop0, cop2 and swi also need fixups.

[ector]

I think writing this recompiler (actually a binary translator) shouldn't be too hard. I believe that r3000 is a subset of r4000 code. No instruction code translation is really necessary. I can let the code execute natively up until a CALL or JUMP statement. For a call or a jump, addresses need to be remapped.

Boy, you are in for a world of hurt.

Yeah that's a much better way to put it :)

[PacManFan]

Here's another screen capture.



I've got the byte pitch figured out, and I've put in a control handler to map buttons and the directional pad. I haven't put in the analog controls yet. I've verified that the program runs fine on a PSP, and I've got optimizations turned on.
For the demo, I get about 4-5 FPS

I'm making good progress, I may need beta testers soon.

-PMF

[Cogboy]

There's always plenty of us for that. :)

[glitchbit]

Drop me a PM or an email. My email is my user name @gmail.com. I can make a video for your betas if you'd like and I also have a number of psx games I bought for like $2 when I went through my psx on my pda craze a year or so ago and I should still have a few my ripped iso's I created that I can test them with. Not like I need ripped iso's anymore though considering I know have a 1gb stick =). Also my vid cam is pretty good quality 3CCD(means color is better and this is standard for cams they use for broadcast) and leica lens, best cam for under $1000 pretty much.

[mrbrown]

We are not going to start a bunch of me toos in this thread. If you want access to a beta of this emulator, PM PacManFan or e-mail him.

Any more me toos will be filtered.

[glitchbit]

well he did say he may need beta tester but I gotcha I should have PM'd him, if only I knew more about coding for the psp then I could really contribute to this thread.

I do wonder though if the authors of fpsce would be willing to help you out, they did a really good job for Xscale/ARM processors.

[ZID]

Do what $ONY Did with its PS2, let the PSP run PS1 Games and codes without emulation because like the other said the PS2 processor is compatible with the PSP one , make it like that GBA Emulator for GP32 which it let the code run directly without emulation http://gp32emu.dcemu.co.uk/gpadvance.shtml .
but i don`t know about other hardware, like the video chipset and sound chipset, it they compatible also ???

I think the "PSPsx" or "PSPSx" are fantastic names for this emulator :) .

[surferpr]

Nice work pacman. I have been waiting for some time to see someone try this feat. I can help you with art, web design and beta testing or just the art, web dev. I belive every one here should pitch in and support this gargantuate of a project. The community salutes you. WACAWACAWACA DangIT!

[Krevnik]

Yeah, PS1 emulation on a PSP isn't trivial... although you do have the advantage that you aren't in a huge world of hurt as having to write a freaky huge recompiler for EVERYTHING.

RAM access should be re-routed to a pre-allocated block of memory, as the PS1 was running with about 4-8MB of RAM (I can't remember which off the top of my head), this shouldn't pose too much of a problem, and you can avoid having to call on /every/ RAM access. (limit it to memory mapped IO regions, and the like, if possible)

Since you are on the same arch, you do have a lot less work to do. However, because you are porting a JIT system, performance will be doomed to be lower than it could be, unless a route was taken to essentially have two contexts: 1 for the emulated app, 1 for the emulator itself, context switching between the two as we run. (Which the big question is: is a context switch every so often better or worse than a bunch of RAM/Cache hits from swapping registers and RAM, and then keeping complex state of this whole process)

If you are interested, I could possibly spend a little time seeing if I could at the very least design an r4000 JIT, and implement a shell of it to work from. Since we are on a similar arch, there are a lot of places where we can take shortcuts and improve performance, although it is still a JIT. :)

[ector]

Krevnik, it's not that simple. Problem is that PSX has a lot of memory mapped I/O, so yes, every single read/write will have to be checked if it is to one of these regions.

PSX had 2MB of RAM (and a similar amount of VRAM) so that is not much of a problem but the different memory map is.

I'd advise to first get the interpreter up and running as pacmanfan is doing, then make it a "threaded" interpreter (nothing to do with threads, it's a term for converting code blocks to blocks of jal InterpretLi jal InterpretAdd jal InterpretSub etc), and if that is fast enough (could very well be) stop there.
Only if this is not fast enough, spend time on more advanced techiques.

[PacManFan]

This isn't as hard as I thought it would be. PCSX is a nicely laid out emulator. It has an interpreter, and a recompiler for x86 and sh4 instruction sets already. For the PSP, the "recompiler" is really an address translator. Whenever the cpu needs to talk to memory through a load instruction, or a branch instruction, the address is mapped from the original address space to the blocks that the emulator allocated. For all other instructions such as ADD, SLTI, ANDI, etc..., they are directly copied from the loaded program into a buffer that will be executed in "chunks".

I've gotten that far already with the recompiler in a few hours, now I need to do something about the COP0 and COP2 instructions for the geometry transforms.

The tricky part is mirroring the emulators internal copies of the PSX registers with the actual hardware registers of the psp, and syncing them back and forth.

I've gotten the emulator (interpreter) portion of this to run psx games and demos fine, although it's dog slow. I think after I finish with the recompiler, I'll see a very significant speed jump.

After that, I'll be asking around about GE calls and the such to rewrite the existing graphic plugin with some accelerated graphic hardware calls.

If someone wants to rewrite a PSX GPU plugin with GE calls, it would really be helpful for this project.

Any takers?

-PMF

[crazyc]

PSX had 2MB of RAM (and a similar amount of VRAM) so that is not much of a problem but the different memory map is.

Optimal situation would be if RAM addresses overlap and MMIO is unmapped. Then RAM accesses could pass through while MMIO would cause a exception.

[PacManFan]

here.



Another screen shot of a demo running, Looking better.

-PMF

[Josh1billion]

Nice, it looks like you're really getting some progress. :) Good work and good luck.

[shadow_91]

also, pacmanfan, if you are just running the eboot on the psp emulator, try it on the psp itself. i hear the pspe is slow as shit.

[PacManFan]

I've been running both on the emulator (for developement) and on the real deal PSP. The PSP is 2X as fast as the emu. Currently, I'm working on the binary address translations and the branch instructions of the dynamic recompiler. I've got the memory mapping back and forth between the psx r3000 code and the r4000(PSP). I'm trying to figure out how to implement the branch instructions correctly.

I've worked a lot with x86 assembly before, by never MIPS.
This may sound like a real stupid question, and I've been digging through MIP assembly instructions, but what is the equivalnt of a RET statement in r4000 assembler? I know that instructions like jal jumps to a target location and stores the pc+8 in ra, but what is the instruction to make a subroutine return?

Sorry if this sounds like a newB question.

-PMF

[Jim]

jr ra

[ector]

By the way, you do know about delay slots?
That is:

jal mysub
xor $1, $3, $2
addiu $1,$0,$0

In this case, xor will be executed before the jal is taken, and addiu will be executed by the time the function returns. That is, jumps are delayed by one cycle.

[mirrorsawlljk]

How do you plan on dealing with controls? The PSX had an extra analog stick and two more shoulder buttons.

[Jim]

Code: Select all

jal mysub 
xor $1, $3, $2 
addiu $1,$0,$0 

In this case, xor will be executed before the jal is taken, and addiu will be executed by the time the function returns. That is, jumps are delayed by one cycle.

That's not really correct, the jal is executed first and the xor is executed second, before the first instruction of mysub.
eg, you can't do this, which from your description would work

Code: Select all

addiu $1,$0,0
jalr $1
addiu $1,$0,4

will jump to location 0, not location 4.

Jim