I have some ideas on building a PSP emulator (not just an instruction interpreter) which might make figuring out some of the more esoteric files and functions a little bit easier.
The problem I'm having is that my ideas about the hardware configurations all seem to be slightly wrong...
I started with the general layout of the PS2, and tried altering things slightly to fit with what I've read about the PSP's innards in the various internet FAQs, but so far I haven't stumbled upon exactly the right configuration.
Since I don't have the $$ to toss around on extra PSPs, I'm reluctant to open mine up and have a look, so if anybody has a general idea of how the stuff inside is laid out, I'd like to know. If somebody has pictures, that would be even better.
Also, I'd like to know if anybody other than me can think of a use for something like this, and if it's even worthwhile. If my time could be put to better use on another project, then I'd rather do that.
PSP Emulator...
-
Guest
I couldn't find the pictures on Lik-Sang.....
As for your question, why compete with PSPE, I don't think it would be competing, as I'm trying to solve a different problem. PSPE is an instruction interpreter, not really an emulator, and it serves its purpose as a testing ground for homebrew apps.
The reason behind building this emulator isn't to run games. Simulating the hardware in software on another computer, the way I am, is bound to be on the order of 1000x slower than the real thing for certain processes, and as such would be completely useless for most games. The real reason I want to build a better simulation is just to run the firmware and see how it ticks.
That doesn't mean there couldn't be optimizations. Once processes are understood, they could be taken out of the soft simulation and rewritten to run better on a PC. So this could eventually lead to running games. But for the time being, I'd like it to boot.
Any help or criticism is still welcome.
As for your question, why compete with PSPE, I don't think it would be competing, as I'm trying to solve a different problem. PSPE is an instruction interpreter, not really an emulator, and it serves its purpose as a testing ground for homebrew apps.
The reason behind building this emulator isn't to run games. Simulating the hardware in software on another computer, the way I am, is bound to be on the order of 1000x slower than the real thing for certain processes, and as such would be completely useless for most games. The real reason I want to build a better simulation is just to run the firmware and see how it ticks.
That doesn't mean there couldn't be optimizations. Once processes are understood, they could be taken out of the soft simulation and rewritten to run better on a PC. So this could eventually lead to running games. But for the time being, I'd like it to boot.
Any help or criticism is still welcome.
My code is usually pretty portable, and in this case, the software I'm using to design runs on both linux and windows. This simulation might not ever be released as a standalone executable... depends on how much time I have, and if I ever even get it working.
I did eventually find the gallery at Lik-Sang, and I might have enough information to interpolate the hidden layer(s) of the board. Here's hoping...
I did eventually find the gallery at Lik-Sang, and I might have enough information to interpolate the hidden layer(s) of the board. Here's hoping...
Hello...
I am sorry but I dont see a difference with your emulator and PSPE.
(And I have written some basic compiler, emulator and virtual machine so I know what I am talking about)
Even simulator are most likely to simulate CPU the complete timing and hardware stuff of the cpu. I am not sure that PSPE code do that far (else I bet it would run far slowly)
The problem of PSPE is just that it does not have a bios to bootstrap and execute directly the user program.
PSPE also does not have the complete memory map probably (well, still enough to make a PSP program work still :-)
which means it does not know the hardware register of the chips on board.
Still the CPU core emulation is most likely to be the same source as you would use for your stuff...
PSPE is most likely to get closer to a fully running emulator as long as our knowledge of PSP will increase.
BTW, and how do you plan to make the "bios" of the PSP run ? Most of the PRX are encrypted in the flash.
Even if you use a dump of a PSP bios to boot your emulator,
I really wish you good luck.
I am sorry but I dont see a difference with your emulator and PSPE.
(And I have written some basic compiler, emulator and virtual machine so I know what I am talking about)
Even simulator are most likely to simulate CPU the complete timing and hardware stuff of the cpu. I am not sure that PSPE code do that far (else I bet it would run far slowly)
The problem of PSPE is just that it does not have a bios to bootstrap and execute directly the user program.
PSPE also does not have the complete memory map probably (well, still enough to make a PSP program work still :-)
which means it does not know the hardware register of the chips on board.
Still the CPU core emulation is most likely to be the same source as you would use for your stuff...
PSPE is most likely to get closer to a fully running emulator as long as our knowledge of PSP will increase.
BTW, and how do you plan to make the "bios" of the PSP run ? Most of the PRX are encrypted in the flash.
Even if you use a dump of a PSP bios to boot your emulator,
I really wish you good luck.
laxer:
I think there is a big difference between running a sequence of MIPS instructions and simulating two MIPS cores, floating point units, a vector unit, etc... and the buses that connect them all. A more in depth simulation gives a more in depth picture of the machine, and a more in depth picture of the machine means a better idea of how to write better homebrew programs, or even better emulators.
Yes, absolutely, it will be slower, but as I said, my intent isn't to run games, it's to see how the guts work.
Thanks a ton for your comments, and keep them coming!
Chrighton:
Excellent point! Those files are key to getting this to work.
I think there is a big difference between running a sequence of MIPS instructions and simulating two MIPS cores, floating point units, a vector unit, etc... and the buses that connect them all. A more in depth simulation gives a more in depth picture of the machine, and a more in depth picture of the machine means a better idea of how to write better homebrew programs, or even better emulators.
Yes, absolutely, it will be slower, but as I said, my intent isn't to run games, it's to see how the guts work.
Thanks a ton for your comments, and keep them coming!
Chrighton:
Excellent point! Those files are key to getting this to work.
I think there is a big difference between running a sequence of MIPS instructions and simulating two MIPS cores, floating point units, a vector unit, etc... and the buses that connect them all.
Hi !
Sorry, I may have missed a point :-(.
So you want to simulate the mips core and everything ?(=Simulator)
Or just execute the instructions ? (=Emulator)
The simulator also simulate the data path and pipeline in the hardware.
A good emulator still can emulate the timing in cycle. (thats what does Snes9x or Atari emulator with very good cycle emulation)
Now if you build a simulator, you will have a lot of detail about the cpu ok, but when it comes to the hardware ??? Simulate memory access, pin going up and down and everything ???
I personnally believe that EVEN if you are able to do it, you will take no benefit from such software. (Better buy a real logic analyzer and open your psp)
I believe just correct execution of instruction WITH correct timing (=pipeline, branch prediction and //ism) is far good enough.
The second point is:
As Chrighton suggested, yes, you have the decrypted module in memory,still it is not the file as it is in flash. Its a loaded module which is not exactly how it is stored. While this could work for PSPE, it will not work well for your tool.(how to link your hardware simulator that should call data from Flash device into using a decrypted version of the data ? about code loader ?)
Of course, as it is a piece of software everything is possible in term of behaviour. Still...
Personally (dont flame me here ok ? ;-)), I think that if you have enough talent and energy to do such project, you would better help the guys working on PSPE, like having a step by step execution, builtin disassembler, memory/register viewer, synchronization with a real PSP code at the same adress :-P. A lot of fun stuff is possible now the IO are most likely to get open and useable soon.(wireless debugging would be cool)
Also, for the moment PSPE is probably mapping the system call (like IO) directly to windows OS routine.
Now that the kernel can be dumped, this part could be emulated too and then you can write emulation layer of access to the memory stick, graphics chipset or wireless chipset :-)
(Hum... can see some legal issue here : distribution of a BIOS that nobody is able to do from his own psp backup, not really good)
As Sony rely on people using library instead of accessing hardware directly, may be the current version of PSPE is the best design to go.
Just need to improve the CPU timing and relation to other hardware (like HBlank routine beeing mapped to the CPU speed, support CPU set mhz etc..etc...)
For the moment PSPE is a kind of embryo of emulator, still it brings most of the things we need, and if effort has to be made, it should be to improve it instead of building another huge and complex piece of software.
:-) Anyway please keep up the good work, more people with good skill means a lot of cool software. See you.
-
Guest
One thing to keep in mind...
If you intend to fully emulate the PSP, you have many months or years of work ahead of you. Thats fine if you are fine with it. By all means, so long as you realize what you are getting into. :)
The current emulator for the PS2, pcsx2, I think has been in development for a very long time, and only just recently is beginning to run games (judging by occasionally reading news posts). This is because, not only has the PS2 architecture taken time to be well understood (or reasonably well), but it certainly must have taken time to translate that understanding into something that works.
But again, if you accept the time committment, more power to you!
If you intend to fully emulate the PSP, you have many months or years of work ahead of you. Thats fine if you are fine with it. By all means, so long as you realize what you are getting into. :)
The current emulator for the PS2, pcsx2, I think has been in development for a very long time, and only just recently is beginning to run games (judging by occasionally reading news posts). This is because, not only has the PS2 architecture taken time to be well understood (or reasonably well), but it certainly must have taken time to translate that understanding into something that works.
But again, if you accept the time committment, more power to you!
SimulatorSo you want to simulate the mips core and everything ?(=Simulator)
Or just execute the instructions ? (=Emulator)
To a degree, yes.Now if you build a simulator, you will have a lot of detail about the cpu ok, but when it comes to the hardware ??? Simulate memory access, pin going up and down and everything ???
Of course it's good enough, but what is the correct execution for all these instructions? You're right that finding things like this out would be more easily done with a logic analyzer, but I don't want to open my own PSP, and I certainly don't want to try to split open the main board to get at the hidden layer(s) sandwiched inside.I personnally believe that EVEN if you are able to do it, you will take no benefit from such software. (Better buy a real logic analyzer and open your psp)
I believe just correct execution of instruction WITH correct timing (=pipeline, branch prediction and //ism) is far good enough.
At this point, it is easier and cheaper for me to build a fake PSP from the (scant) details I have, and assumptions based on the PS2 hardware, so that's the route I'm going.
As for the second point, it isn't impossible in simulation to just load a saved state, or for that matter, just load the unencrypted files instead. Obviously, not every aspect of the simulation will be able to work just like the real thing. The security embedded into the hardware, I'm pretty sure, isn't understood by anybody at this point (I haven't been reading these forums for long, so somebody correct me if I'm wrong), and some of the bus connections I have laid out are simply arrows and numbers, with no clues as to their interfaces with the chips themselves. The VME uses some kind of FPGA for DSP, and there's no way I'm going to try to simulate that.
The simulation won't be perfect, but I think the important pieces will be in there...
gorim:
I'm really just trying to understand how everything fits together, not necessarily producing a mass distributable emulator. Hopefully, though, I can provide some useful information for the people who are building true emulators.
rinco:
Thanks for the info; I'll be checking all those out later today.
-
Guest
gxemul will execute binaries produced from psp-gcc in R4000 or R6000
(as mrbrown suggests is more similar) mode.
edit machine.c to change the framebuffer addr:
(as mrbrown suggests is more similar) mode.
Code: Select all
$ ./gxemul -V -M 32 -J -T -i -X -E testmips -C R6000 test.elf
Implicitly turning on -v, because of -i
GXemul-0.3.2 Copyright (C) 2003-2005 Anders Gavare
Read the source code and/or documentation for other Copyright messages.
Simple setup...
net: 10.0.x.x/8 (max outgoing: TCP=60, UDP=60)
gateway: 10.0.x.x (60:50:40:30:20:10)
nameserver 192.168.x.x
machine "default":
memory: 32 MB
cpu0: R6000 (I+D = 64+64 KB)
device 0 at 0x0010000000: cons [console]
device 1 at 0x0011000000: mp
device 2 at 0x0004000000: fb [generic]
machine: MIPS test machine
loading test.elf:
ELF32 LSB (LE), entry point 0x80030128
chunk 0 (load) @ 0x1018, vaddr 0x00400018 len=0x28
chunk 1 (load) @ 0x2000, vaddr 0x80030000 len=0x290
chunk 2 (load) @ 0x2290, vaddr 0x80070290 len=0x38
136 bytes of symbol strings at 0x231c
55 symbol entries at 0x269c
500 bytes of symbol strings at 0x2a0c
found _gp address: 0x800782a0
starting cpu0 at 0x80030128 (gp=0x800782a0)
-------------------------------------------------------------------------------
GXemul> unassemble
80030128: 27bdffe0 addiu sp,sp,-32
8003012c: afbe0018 sw fp,24(sp)
80030130: 03a0f021 move fp,sp
80030134: afc40020 sw a0,32(fp)
80030138: afc50024 sw a1,36(fp)
8003013c: 3c038003 lui v1,0x8003
80030140: 8c64027c lw a0,636(v1)
80030144: 2462027c addiu v0,v1,636
80030148: 8c450004 lw a1,4(v0)
8003014c: 2462027c addiu v0,v1,636
80030150: 8c460008 lw a2,8(v0)
80030154: 2462027c addiu v0,v1,636
80030158: 8c43000c lw v1,12(v0)
8003015c: abc40008 swl a0,8(fp)
80030160: 27c20005 addiu v0,fp,5
80030164: b8440000 swr a0,0(v0)
80030168: abc5000c swl a1,12(fp)
8003016c: 27c20009 addiu v0,fp,9
80030170: b8450000 swr a1,0(v0)
80030174: abc60010 swl a2,16(fp)
GXemul> step
80030128: 27bdffe0 addiu sp,sp,-32
Code: Select all
fb = dev_fb_init(machine, mem, 0x04000000, VFB_GENERIC,
480,272, 480,272, 24, "generic", 1); /* values are probably wrong */
Rinco, I did this change and the only thing I'm getting with gxemul 0.3.3.2 is a segmentation fault, right during the initialization of the framebuffer, is there anything else I need to modify to get this going?
I also tried with gxemul 0.3.2 and I get the same seg fault:
(gdb) r -V -M 32 -J -T -i -X -E testmips -C R6000 out
Starting program: /home/jason/gxemul-0.3.2/gxemul -V -M 32 -J -T -i -X -E testmips -C R6000 out
Implicitly turning on -v, because of -i
GXemul-0.3.2 Copyright (C) 2003-2005 Anders Gavare
Read the source code and/or documentation for other Copyright messages.
Simple setup...
net: 10.0.0.0/8 (max outgoing: TCP=60, UDP=60)
gateway: 10.0.0.254 (60:50:40:30:20:10)
nameserver 192.168.1.1
machine "default":
memory: 32 MB
cpu0: R6000 (I+D = 64+64 KB)
device 0 at 0x0010000000: cons [console]
device 1 at 0x0011000000: mp
Program received signal SIGSEGV, Segmentation fault.
0x0809b413 in dev_fb_init ()
(gdb) where
#0 0x0809b413 in dev_fb_init ()
#1 0x00000000 in ?? ()
(gdb)
Also, you seem to be using "testmips" but this arch is defined to be BIG_ENDIAN, while the psp is little endian, what's up with that?
I also tried with gxemul 0.3.2 and I get the same seg fault:
(gdb) r -V -M 32 -J -T -i -X -E testmips -C R6000 out
Starting program: /home/jason/gxemul-0.3.2/gxemul -V -M 32 -J -T -i -X -E testmips -C R6000 out
Implicitly turning on -v, because of -i
GXemul-0.3.2 Copyright (C) 2003-2005 Anders Gavare
Read the source code and/or documentation for other Copyright messages.
Simple setup...
net: 10.0.0.0/8 (max outgoing: TCP=60, UDP=60)
gateway: 10.0.0.254 (60:50:40:30:20:10)
nameserver 192.168.1.1
machine "default":
memory: 32 MB
cpu0: R6000 (I+D = 64+64 KB)
device 0 at 0x0010000000: cons [console]
device 1 at 0x0011000000: mp
Program received signal SIGSEGV, Segmentation fault.
0x0809b413 in dev_fb_init ()
(gdb) where
#0 0x0809b413 in dev_fb_init ()
#1 0x00000000 in ?? ()
(gdb)
Also, you seem to be using "testmips" but this arch is defined to be BIG_ENDIAN, while the psp is little endian, what's up with that?
Can you PLEASE stop quoting quotes from nested quotes ... ? Try a bit before posting anything. I've edited your posts, but next time, I won't be so kind and I'll just erase them silently.
pixel: A mischievous magical spirit associated with screen displays. The computer industry has frequently borrowed from mythology. Witness the sprites in computer graphics, the demons in artificial intelligence and the trolls in the marketing department.
I am using gxemul-0.3.2. I don't know why your gxemul segfaults. I use
XDarwin... perhaps correct values are required for XFree86 & Xorg...
edit: infact line size is 512, so you may wish to change that second 480
to 512.
gxemul appears to have all sorts of endian detection code. so big or little
doesn't seem to be an issue.
XDarwin... perhaps correct values are required for XFree86 & Xorg...
edit: infact line size is 512, so you may wish to change that second 480
to 512.
gxemul appears to have all sorts of endian detection code. so big or little
doesn't seem to be an issue.
It's good to see someone taking some initiative.
And yes R6000 is probably wrong, but it's more right than R4000.
Perhaps we need to make a PSP machine type; with a VFB_BGR frame
buffer and Allegrex cpu.
I look forward to exchanging hacks with you when a psp versioning
repository is publically available.
And yes R6000 is probably wrong, but it's more right than R4000.
Perhaps we need to make a PSP machine type; with a VFB_BGR frame
buffer and Allegrex cpu.
I look forward to exchanging hacks with you when a psp versioning
repository is publically available.
Well, GxEmul now does PSP:
http://gavare.se/gxemul/diary.html
http://gavare.se/gxemul/screenshots/200 ... rtable.png
http://gavare.se/gxemul/diary.html
http://gavare.se/gxemul/screenshots/200 ... rtable.png
This is great news!
I downloaded the file gxemul-20050624.tar.gz off your website. It compiles fine under linux (Fedora Core 4).
Following your instructions, I am running the following:
dd if=EBOOT.PBP of=EBOOT.elf bs=1 skip=0x3940
gxemul -X -E psp EBOOT.elf
This is just the regular PSP Hello program and this is the output I get
Any ideas what I'm doing wrong?
[/code]
I downloaded the file gxemul-20050624.tar.gz off your website. It compiles fine under linux (Fedora Core 4).
Following your instructions, I am running the following:
dd if=EBOOT.PBP of=EBOOT.elf bs=1 skip=0x3940
gxemul -X -E psp EBOOT.elf
This is just the regular PSP Hello program and this is the output I get
Code: Select all
GXemul-20050624 Copyright (C) 2003-2005 Anders Gavare
Read the source code and/or documentation for other Copyright messages.
Simple setup...
net: 10.0.0.0/8 (max outgoing: TCP=60, UDP=60)
gateway: 10.0.0.254 (60:50:40:30:20:10)
nameserver 207.69.188.185
machine "default":
memory: 32 MB
bintrans: i386, 16 MB translation cache at 0xa3b000
cpu0: Allegrex (I+D = 16+16 KB)
cpu1: Allegrex (I+D = 16+16 KB)
device 0 at 0x0004000000: fb [Playstation Portable] (bintrans R/W)
machine: Playstation Portable
loading EBOOT.elf:
The file format of 'EBOOT.elf' is unknown.
00 50 42 50 00 00 01 00 28 00 00 00
Possible explanations:
o) If this is a disk image, you forgot '-d' on the command line.
o) This is an unsupported binary format.[/code]
You have not got a .ELF file. The dd instructions only work for the
eboot.pbp from the hellopsp download. To confirm you have a real elf,
use 'file' or 'psp-readelf'.
While we're talking about deficiencies... this is what I know:
- Anders (the author) plans on adding a TLB-less cpu type.
- Everything besides hellopsp will try to use dynamic links... which do nothing besides return:
eboot.pbp from the hellopsp download. To confirm you have a real elf,
use 'file' or 'psp-readelf'.
While we're talking about deficiencies... this is what I know:
- Anders (the author) plans on adding a TLB-less cpu type.
- Everything besides hellopsp will try to use dynamic links... which do nothing besides return:
So a dynamic linker needs to be written/hacked.089004a8: 0e240163 jal 0x0890058c <sceKernelCreateThread>
089004ac: 00004821 (d) move t1,zr
<sceKernelCreateThread("user_main",0x8902bb8,32,0x40000,..)> <sceKernelCreateThread>
0890058c: 03e00008 jr ra
08900590: 00000000 (d) nop
Yes, the problem was the incorrect .elf file as you pointed out. It was easier to download the source and compile the psp hello demo. For those of you who want to try it. Do the following to create the elf file:
Thank you
Code: Select all
ee-gcc -march=r4000 -g -mgp32 -mlong32 -c hellopsp.c
ee-gcc -march=r4000 -g -mgp32 -mlong32 -c pg.c
ee-gcc -march=r4000 -g -mgp32 -c -xassembler -O -o startup.o startup.s
ee-ld -O0 startup.o hellopsp.o pg.o -M -Ttext 8900000 -q -o EBOOT.elf