| View previous topic :: View next topic |
| Author |
Message |
PacManFan
Joined: 25 Jun 2005 Posts: 66
|
Posted: Thu Jul 14, 2005 7:10 am Post subject: PSPSOne or PSPcsx? |
|
|
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 _________________ "I'm a little source code, short and stout
Here is my input, here is my out."
Author of PSPQuake and PSPSOne. |
|
| Back to top |
|
 |
Mike/Pippin
Joined: 05 Jun 2005 Posts: 40
|
Posted: Thu Jul 14, 2005 7:17 am Post subject: |
|
|
| 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 |
|
| Back to top |
|
 |
Mangus
Joined: 17 Jun 2005 Posts: 33
|
Posted: Thu Jul 14, 2005 7:33 am Post subject: |
|
|
| PMF yet agian you rock, i fell sorry for your social life, always hard working you are, a devers life at best i guess ;) |
|
| Back to top |
|
 |
Tim
Joined: 12 Jul 2005 Posts: 38
|
Posted: Thu Jul 14, 2005 7:42 am Post subject: |
|
|
| 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? |
|
| Back to top |
|
 |
crazyc
Joined: 17 Jun 2005 Posts: 410
|
Posted: Thu Jul 14, 2005 8:26 am Post subject: |
|
|
| Tim wrote: | | 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. |
|
| Back to top |
|
 |
PacManFan
Joined: 25 Jun 2005 Posts: 66
|
Posted: Thu Jul 14, 2005 9:03 am Post subject: r3000 -> r4000 |
|
|
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 _________________ "I'm a little source code, short and stout
Here is my input, here is my out."
Author of PSPQuake and PSPSOne. |
|
| Back to top |
|
 |
ector
Joined: 12 May 2005 Posts: 195
|
Posted: Thu Jul 14, 2005 9:16 am Post subject: |
|
|
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? |
|
| Back to top |
|
 |
PacManFan
Joined: 25 Jun 2005 Posts: 66
|
Posted: Thu Jul 14, 2005 9:31 am Post subject: GPU plugin |
|
|
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 _________________ "I'm a little source code, short and stout
Here is my input, here is my out."
Author of PSPQuake and PSPSOne. |
|
| Back to top |
|
 |
mrbrown
Joined: 17 Jan 2004 Posts: 1536
|
Posted: Thu Jul 14, 2005 10:04 am Post subject: Re: r3000 -> r4000 |
|
|
| PacManFan wrote: | | 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. |
|
| Back to top |
|
 |
crazyc
Joined: 17 Jun 2005 Posts: 410
|
Posted: Thu Jul 14, 2005 10:52 am Post subject: |
|
|
| ector wrote: | | 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. |
|
| Back to top |
|
 |
ector
Joined: 12 May 2005 Posts: 195
|
Posted: Thu Jul 14, 2005 11:44 am Post subject: Re: r3000 -> r4000 |
|
|
| mrbrown wrote: | | PacManFan wrote: | | 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 :) |
|
| Back to top |
|
 |
PacManFan
Joined: 25 Jun 2005 Posts: 66
|
Posted: Thu Jul 14, 2005 1:15 pm Post subject: Making progress |
|
|
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 _________________ "I'm a little source code, short and stout
Here is my input, here is my out."
Author of PSPQuake and PSPSOne. |
|
| Back to top |
|
 |
Cogboy
Joined: 19 Jan 2005 Posts: 45
|
Posted: Thu Jul 14, 2005 8:26 pm Post subject: |
|
|
There's always plenty of us for that. :) _________________ "the sony PSP was built by god, to determine who on earth had the best skills to defeat the armies of satan" - Saint Peter. |
|
| Back to top |
|
 |
glitchbit
Joined: 25 Jun 2005 Posts: 11
|
Posted: Fri Jul 15, 2005 3:14 am Post subject: |
|
|
| 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. |
|
| Back to top |
|
 |
mrbrown
Joined: 17 Jan 2004 Posts: 1536
|
Posted: Fri Jul 15, 2005 3:30 am Post subject: |
|
|
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. |
|
| Back to top |
|
 |
glitchbit
Joined: 25 Jun 2005 Posts: 11
|
Posted: Fri Jul 15, 2005 3:40 am Post subject: |
|
|
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. |
|
| Back to top |
|
 |
ZID
Joined: 08 Jun 2005 Posts: 7 Location: United Arab Emirates
|
Posted: Fri Jul 15, 2005 4:13 am Post subject: |
|
|
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 :) . |
|
| Back to top |
|
 |
surferpr
Joined: 15 Jul 2005 Posts: 1
|
Posted: Fri Jul 15, 2005 9:33 am Post subject: Nice... |
|
|
| 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! |
|
| Back to top |
|
 |
Krevnik
Joined: 09 Mar 2005 Posts: 71
|
Posted: Sat Jul 16, 2005 3:03 am Post subject: |
|
|
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. :) |
|
| Back to top |
|
 |
ector
Joined: 12 May 2005 Posts: 195
|
Posted: Sat Jul 16, 2005 3:12 am Post subject: |
|
|
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. |
|
| Back to top |
|
 |
PacManFan
Joined: 25 Jun 2005 Posts: 66
|
Posted: Sat Jul 16, 2005 6:57 am Post subject: Interpreter vs Recompiler (binary code address translator) |
|
|
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 _________________ "I'm a little source code, short and stout
Here is my input, here is my out."
Author of PSPQuake and PSPSOne. |
|
| Back to top |
|
 |
crazyc
Joined: 17 Jun 2005 Posts: 410
|
Posted: Sat Jul 16, 2005 6:59 am Post subject: |
|
|
| Quote: |
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. |
|
| Back to top |
|
 |
PacManFan
Joined: 25 Jun 2005 Posts: 66
|
Posted: Sat Jul 16, 2005 8:36 am Post subject: Another screen shot |
|
|
here.
Another screen shot of a demo running, Looking better.
-PMF _________________ "I'm a little source code, short and stout
Here is my input, here is my out."
Author of PSPQuake and PSPSOne. |
|
| Back to top |
|
 |
Josh1billion

Joined: 12 Jul 2005 Posts: 32 Location: Wisconsin, USA
|
Posted: Sat Jul 16, 2005 9:45 am Post subject: |
|
|
Nice, it looks like you're really getting some progress. :) Good work and good luck. _________________ Josh1billion - PHP, C++, PSP programmer. |
|
| Back to top |
|
 |
shadow_91
Joined: 15 Jul 2005 Posts: 4
|
Posted: Sat Jul 16, 2005 11:09 am Post subject: |
|
|
| 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. |
|
| Back to top |
|
 |
PacManFan
Joined: 25 Jun 2005 Posts: 66
|
Posted: Sat Jul 16, 2005 1:28 pm Post subject: emu vs. PSP |
|
|
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 _________________ "I'm a little source code, short and stout
Here is my input, here is my out."
Author of PSPQuake and PSPSOne. |
|
| Back to top |
|
 |
Jim

Joined: 02 Jul 2005 Posts: 487 Location: Sydney
|
|
| Back to top |
|
 |
ector
Joined: 12 May 2005 Posts: 195
|
Posted: Sun Jul 17, 2005 3:33 am Post subject: |
|
|
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.
Last edited by ector on Sun Jul 17, 2005 4:53 am; edited 1 time in total |
|
| Back to top |
|
 |
mirrorsawlljk
Joined: 17 Jul 2005 Posts: 5
|
Posted: Sun Jul 17, 2005 4:50 am Post subject: |
|
|
| How do you plan on dealing with controls? The PSX had an extra analog stick and two more shoulder buttons. |
|
| Back to top |
|
 |
Jim

Joined: 02 Jul 2005 Posts: 487 Location: Sydney
|
Posted: Sun Jul 17, 2005 10:34 am Post subject: |
|
|
| Quote: |
| Code: |
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: |
addiu $1,$0,0
jalr $1
addiu $1,$0,4
|
will jump to location 0, not location 4.
Jim _________________ http://www.dbfinteractive.com |
|
| Back to top |
|
 |
|