Pandora Pandora-psp


'JayFoxRox' said:
Back with a small update:
First, I would like to thank DasFool for his great work which he did on a volunteer basis - I wish there were more people like him. He completed more than 150 lines already which are used to register the system calls in the emulator. With his work alot of applications started to work and it makes it alot easier to add new system calls to the emulator.
I have found some more functions to be necessary and forwarded those lists to him (I found even more afterwards, but I will probably do them myself).
What I did today was mainly re-implementing all the CPU instructions. I changed alot of small stuff. The instructions are detected differently now which is a bit slower than before (*cough* about 4 times slower *cough*) but thats only a temporary issue. I m sure it will pay off in the end though.
This time I took the allegrex specific instruction set as provided by hitmen. Cookies for em ;). (I'll see if I can bake them some for breakpoint)
I had the most important float instructions implemented in a really dirty way earlier today and puzzle bobble seemed to get through the company logos (but with nothing drawn - not sure why). However, I already removed them (FPU instructions) again to have a cleaner code to start with.
The most interesting part is probably that I have finished the registration of about 50% of all CPU instructions already (including FPU and VFPU) so only their interpreter / dynarec code is missing. While this sounds like a small number, you should remember that some instructions are used for debugging only, never used in retail games. Registering all instructions is still really good because if a instruction is not implemented it can atleast tell me the instruction name (which I look up in the instruction set afterwards so I can implement it).
I'm at a stage now where most of the PSPSDK samples work more or less.
Most existing problems are either because the FPU is still missing, missing functions for some specific things (registry access, irda, network, ...) and the others are problems with sprintf not working correctly for %d formatting. I have no idea why the sprintf problem exists and I will have to look into that tomorrow.
The plan for tomorrow is to write an application which connects to the PSP via network and then uploads code which is executed on the PSP with a register-compare after each instruction. That way I can easily compare everything to the real hardware and the sprintf problem should be solved in no time (writing the application will take some time - but hey.. I will need a thing like that later anyway)
Once the sprintf problem is gone I will try some homebrew games.

One additional thing on my todo list for tomorrow is the homepage (Please: I do NOT need a person to design it, I will do it myself. Plain text is alright for this project, I know CSS and HTML, but for a project like this its just not necessary) so I can note my findings and to have an automated compatibilty list with highlighting and some other features I need.

Another thing about some misinformation which is going on:
- I don't need the offical SDK or anything, it doesn't help neither. I don't need the bios neither (- atleast not right now)
- The PSP is NOT just a 333mhz RISC cpu powered device: It has 2x RISC cpu with each beeing able to be clocked at 333mhz, but thats not it, the main cpu is having some extra instructions for floats and vectors
- The similarity between the ARM and the MIPS is more of a problem and no help, the ARM has (to my knowledge) less registers than the MIPS and instructions on the ARM are usually more grouped than they are on the MIPS this makes a dynarec more complex
- Only because the mips emulation core is not done yet, doesn't mean that this project is rarely working as said on some blogs. I have focused on the wrapper functions which are making up a HUGE portion of the whole emulator as its re-creating the whole *strikes through* interface to the graphics hardware and alot of things like buttons + analog nub etc.

For the future: Don't quote me on my future plans as I m known for changing them a few times within minutes :p. Argh.. I really need a roadmap for the project.
That was a great read. Posts like these are great to keep us busy while we wait for our handhelds. \^_\^

-God Ginrai
 
Last edited by a moderator:
'JayFoxRox' said:
The plan for tomorrow is to write an application which connects to the PSP via network and then uploads code which is executed on the PSP with a register-compare after each instruction. That way I can easily compare everything to the real hardware and the sprintf problem should be solved in no time (writing the application will take some time - but hey.. I will need a thing like that later anyway)
Once the sprintf problem is gone I will try some homebrew games.
That's brilliant, good luck to you!
 
Last edited by a moderator:
It's no problem really, JayFoxRox, it's just a bit of grunt work. If it allows you to focus on the stuff that counts I really don't mind.

You have more mail btw.
 
Last edited by a moderator:
QUOTE
Back with a small update:
First, I would like to thank DasFool for his great work which he did on a volunteer basis - I wish there were more people like him. He completed more than 150 lines already which are used to register the system calls in the emulator. With his work alot of applications started to work and it makes it alot easier to add new system calls to the emulator.
I have found some more functions to be necessary and forwarded those lists to him (I found even more afterwards, but I will probably do them myself).
What I did today was mainly re-implementing all the CPU instructions. I changed alot of small stuff. The instructions are detected differently now which is a bit slower than before (*cough* about 4 times slower *cough*) but thats only a temporary issue. I m sure it will pay off in the end though.
This time I took the allegrex specific instruction set as provided by hitmen. Cookies for em wink.gif. (I'll see if I can bake them some for breakpoint)
I had the most important float instructions implemented in a really dirty way earlier today and puzzle bobble seemed to get through the company logos (but with nothing drawn - not sure why). However, I already removed them (FPU instructions) again to have a cleaner code to start with.
The most interesting part is probably that I have finished the registration of about 50% of all CPU instructions already (including FPU and VFPU) so only their interpreter / dynarec code is missing. While this sounds like a small number, you should remember that some instructions are used for debugging only, never used in retail games. Registering all instructions is still really good because if a instruction is not implemented it can atleast tell me the instruction name (which I look up in the instruction set afterwards so I can implement it).
I'm at a stage now where most of the PSPSDK samples work more or less.
Most existing problems are either because the FPU is still missing, missing functions for some specific things (registry access, irda, network, ...) and the others are problems with sprintf not working correctly for %d formatting. I have no idea why the sprintf problem exists and I will have to look into that tomorrow.
The plan for tomorrow is to write an application which connects to the PSP via network and then uploads code which is executed on the PSP with a register-compare after each instruction. That way I can easily compare everything to the real hardware and the sprintf problem should be solved in no time (writing the application will take some time - but hey.. I will need a thing like that later anyway)
Once the sprintf problem is gone I will try some homebrew games.

One additional thing on my todo list for tomorrow is the homepage (Please: I do NOT need a person to design it, I will do it myself. Plain text is alright for this project, I know CSS and HTML, but for a project like this its just not necessary) so I can note my findings and to have an automated compatibilty list with highlighting and some other features I need.

Another thing about some misinformation which is going on:
- I don't need the offical SDK or anything, it doesn't help neither. I don't need the bios neither (- atleast not right now)
- The PSP is NOT just a 333mhz RISC cpu powered device: It has 2x RISC cpu with each beeing able to be clocked at 333mhz, but thats not it, the main cpu is having some extra instructions for floats and vectors
- The similarity between the ARM and the MIPS is more of a problem and no help, the ARM has (to my knowledge) less registers than the MIPS and instructions on the ARM are usually more grouped than they are on the MIPS this makes a dynarec more complex
- Only because the mips emulation core is not done yet, doesn't mean that this project is rarely working as said on some blogs. I have focused on the wrapper functions which are making up a HUGE portion of the whole emulator as its re-creating the whole *strikes through* interface to the graphics hardware and alot of things like buttons + analog nub etc.

For the future: Don't quote me on my future plans as I m known for changing them a few times within minutes tongue.gif. Argh.. I really need a roadmap for the project.




OK, thanks for the "small" (I wish the devs would write this "small" updates ;-) ) update!.
Very informative!

I wish you all the best with this project and if you need another one to hack thousands of numbers into a textfile, let me know...
 
Last edited by a moderator:
'JayFoxRox' said:
Back with a small update:
First, I would like to thank DasFool for his great work which he did on a volunteer basis - I wish there were more people like him. He completed more than 150 lines already which are used to register the system calls in the emulator. With his work alot of applications started to work and it makes it alot easier to add new system calls to the emulator.
I have found some more functions to be necessary and forwarded those lists to him (I found even more afterwards, but I will probably do them myself).
What I did today was mainly re-implementing all the CPU instructions. I changed alot of small stuff. The instructions are detected differently now which is a bit slower than before (*cough* about 4 times slower *cough*) but thats only a temporary issue. I m sure it will pay off in the end though.
This time I took the allegrex specific instruction set as provided by hitmen. Cookies for em ;). (I'll see if I can bake them some for breakpoint)
I had the most important float instructions implemented in a really dirty way earlier today and puzzle bobble seemed to get through the company logos (but with nothing drawn - not sure why). However, I already removed them (FPU instructions) again to have a cleaner code to start with.
The most interesting part is probably that I have finished the registration of about 50% of all CPU instructions already (including FPU and VFPU) so only their interpreter / dynarec code is missing. While this sounds like a small number, you should remember that some instructions are used for debugging only, never used in retail games. Registering all instructions is still really good because if a instruction is not implemented it can atleast tell me the instruction name (which I look up in the instruction set afterwards so I can implement it).
I'm at a stage now where most of the PSPSDK samples work more or less.
Most existing problems are either because the FPU is still missing, missing functions for some specific things (registry access, irda, network, ...) and the others are problems with sprintf not working correctly for %d formatting. I have no idea why the sprintf problem exists and I will have to look into that tomorrow.
The plan for tomorrow is to write an application which connects to the PSP via network and then uploads code which is executed on the PSP with a register-compare after each instruction. That way I can easily compare everything to the real hardware and the sprintf problem should be solved in no time (writing the application will take some time - but hey.. I will need a thing like that later anyway)
Once the sprintf problem is gone I will try some homebrew games.

One additional thing on my todo list for tomorrow is the homepage (Please: I do NOT need a person to design it, I will do it myself. Plain text is alright for this project, I know CSS and HTML, but for a project like this its just not necessary) so I can note my findings and to have an automated compatibilty list with highlighting and some other features I need.

Another thing about some misinformation which is going on:
- I don't need the offical SDK or anything, it doesn't help neither. I don't need the bios neither (- atleast not right now)
- The PSP is NOT just a 333mhz RISC cpu powered device: It has 2x RISC cpu with each beeing able to be clocked at 333mhz, but thats not it, the main cpu is having some extra instructions for floats and vectors
- The similarity between the ARM and the MIPS is more of a problem and no help, the ARM has (to my knowledge) less registers than the MIPS and instructions on the ARM are usually more grouped than they are on the MIPS this makes a dynarec more complex
- Only because the mips emulation core is not done yet, doesn't mean that this project is rarely working as said on some blogs. I have focused on the wrapper functions which are making up a HUGE portion of the whole emulator as its re-creating the whole *strikes through* interface to the graphics hardware and alot of things like buttons + analog nub etc.

For the future: Don't quote me on my future plans as I m known for changing them a few times within minutes :p. Argh.. I really need a roadmap for the project.
Awesome, thanks for the update. It's nice to be in the know! :D
 
Last edited by a moderator:
Great update.

P.S.: PLEASE DON'T QUOTE HIS LONG POST. We know what you're referring to, you're just wasting space.
 
Last edited by a moderator:
I'd be very interested in this emulator purely so I can play the dozens of PSP games I already own on a screen that doesn't ghost.

Yeah, there are new PSP models out now, but why should I fork out more money for an almost identical machine with worse battery life?
 
Last edited by a moderator:
Thnx for the update JayFoxRox! It's awesome to see these devs working on something challenging and hard so we have fun :D

Specwise, the Pandora should be able to emulate the PSP, but I guess it all comes down to the coding! Can't wait to see a vid of it running it's first commercial game
 
Last edited by a moderator:
just a thought
when it comes down to do some testing
would testing remoteplay be possible (if you have a ps3 ofcourse)
 
'arrrgh' said:
No. It is highly unlikely remoteplay will ever be implemented.
How would you know? IIRC, remoteplay is basically streaming video games, so I don't see why it wouldn't be possible, assuming the PSP emulator makes it to playable speeds.

-God Ginrai
 
Last edited by a moderator:
'God Ginrai' said:
'arrrgh' said:
No. It is highly unlikely remoteplay will ever be implemented.
How would you know? IIRC, remoteplay is basically streaming video games, so I don't see why it wouldn't be possible, assuming the PSP emulator makes it to playable speeds.

-God Ginrai

You would have to make the PS3 think the Pandora is a PSP, which will be much, much harder than making the Pandora think it's a PSP.
 
Last edited by a moderator:
'sdedalus' said:
'God Ginrai' said:
'arrrgh' said:
No. It is highly unlikely remoteplay will ever be implemented.
How would you know? IIRC, remoteplay is basically streaming video games, so I don't see why it wouldn't be possible, assuming the PSP emulator makes it to playable speeds.

-God Ginrai

You would have to make the PS3 think the Pandora is a PSP, which will be much, much harder than making the Pandora think it's a PSP.



MMM <_<

would you not just grab the prx from the FW and run it on the emulator

nothing else should need changed, the ps3 doesnt check if the psp is a psp, the psp tells the ps3 its a psp, the ps3 simply sends data, which the psp (emulator) interprets by running the prx
 
Last edited by a moderator:
'emcp' said:
MMM <_<

would you not just grab the prx from the FW and run it on the emulator

nothing else should need changed, the ps3 doesnt check if the psp is a psp, the psp tells the ps3 its a psp, the ps3 simply sends data, which the psp (emulator) interprets by running the prx
You're never going to be able to run the entirety of a PSP firmware on this emulator. You probably also won't be able to run most things which are intended to be ran in kernel mode or as kernel modules (a lot of homebrew). This kind of high level emulation is intended to provide an environment for commercial PSP games to run in, which happens to be sandboxed off enough from what a real PSP is that a real PSP is not really what you have to emulate (in some regards).

I don't know what communication protocols are in use between the PSP and PS3, but I have a good feeling that it's involving hardware and encryption that this isn't going to be emulating.
 
Last edited by a moderator:
'Exophase' said:
'emcp' said:
MMM <_<

would you not just grab the prx from the FW and run it on the emulator

nothing else should need changed, the ps3 doesnt check if the psp is a psp, the psp tells the ps3 its a psp, the ps3 simply sends data, which the psp (emulator) interprets by running the prx
You're never going to be able to run the entirety of a PSP firmware on this emulator. You probably also won't be able to run most things which are intended to be ran in kernel mode or as kernel modules (a lot of homebrew). This kind of high level emulation is intended to provide an environment for commercial PSP games to run in, which happens to be sandboxed off enough from what a real PSP is that a real PSP is not really what you have to emulate (in some regards).

I don't know what communication protocols are in use between the PSP and PS3, but I have a good feeling that it's involving hardware and encryption that this isn't going to be emulating.


now thats a valid answer
thanks, i knew here would be problems, similar problems to what you stated but not the others, the kernal makes a very good point
 
Last edited by a moderator:
Back
Top