Pandora Pandora-psp


somebody wrote a great analogy

Porting a game is like letting somebody translate a book so you can read it. Emulating a system is learning a whole new language so you can read all books in that language.

The latter takes more energy and needs more resources. In other words to emulate a system you add layers and therefor the machine emulating the other system needs to be more powerfull that the original machine (that is just reading its native language)

But the other guy said it much more elegant
 
Thanks for the quick reply. I thought your analogy was good to since it helped me understand the metaphor. :lol:
 
Last edited by a moderator:
Shaun. said:
Sorry if this is a stupid question but I never really understood why the Pandora may not have the power to emulate a console which is far less powerful then the Pandora itself. I'm pretty sure alot of other people don't understand this because i noticed there is a massive thread about gamecube emulation. Anyway can someone please explain this to me?




I hope you don't think Gamecube is far less powerful than Pandora.
 
Last edited by a moderator:
Exophase said:
Shaun. said:
Sorry if this is a stupid question but I never really understood why the Pandora may not have the power to emulate a console which is far less powerful then the Pandora itself. I'm pretty sure alot of other people don't understand this because i noticed there is a massive thread about gamecube emulation. Anyway can someone please explain this to me?
I hope you don't think Gamecube is far less powerful than Pandora.Or conceivably emulatable on the Pandora.
 
Last edited by a moderator:
i think in this case he was simply referring the amount of people that did not know, and not the plausibility of the emulator ;)
 
Last edited by a moderator:
'Bosbeetle' said:
somebody wrote a great analogy

Porting a game is like letting somebody translate a book so you can read it. Emulating a system is learning a whole new language so you can read all books in that language.

The latter takes more energy and needs more resources. In other words to emulate a system you add layers and therefor the machine emulating the other system needs to be more powerfull that the original machine (that is just reading its native language)

But the other guy said it much more elegant
I think a better analogy is, that you have to look every word up in a dictionary to read the book.
What consumes a lot of more time. And writing the emulator is like making a dictionary for the language the book is written in. The better the dictionary is structured, the faster you can find the words you need.
 
Last edited by a moderator:
I wonder if it's doing some funky optimisation which is falling foul of memcpy's overlap issues. What happens if you use memmove instead?
 
Last edited by a moderator:
no, same problem with memmove, my guess is that the last case is optimized in a somewhat weird way by gcc, I m testing this right now by re-ordering instructions and checking the asm-listing.
I also got a usb cable working but psp-gdb sucks to be honest. It seems to skip alot of breakpoints and its really crashy so thats no real help for most things..
 
JayFoxRox said:
no, same problem with memmove, my guess is that the last case is optimized in a somewhat weird way by gcc, I m testing this right now by re-ordering instructions and checking the asm-listing.
I also got a usb cable working but psp-gdb sucks to be honest. It seems to skip alot of breakpoints and its really crashy so thats no real help for most things..


Don't you have a debugger in your emulator (one with a disassembler)? For this sequence of code It should be pretty simple to understand what the ASM is supposed to be doing and find where it's going wrong..
 
Last edited by a moderator:
If it was that easy I would just step through the code, but memcpy() is more than 100 instructions with lots of branches. There is no full featured debugger yet (there is one actually but its disabled because its adding more bugs to the emulator and I would like to keep it as clean as possible for now) but only a disassembler which prints the register contents before / after each instruction to the terminal.
But I still do what you suggested anyway - understanding the asm listing is not as easy as you think tho and takes a lot of time ;)
 
Last edited by a moderator:
JayFoxRox said:
If it was that easy I would just step through the code, but memcpy() is more than 100 instructions with lots of branches. There is no full featured debugger yet (there is one actually but its disabled because its adding more bugs to the emulator and I would like to keep it as clean as possible for now) but only a disassembler which prints the register contents before / after each instruction to the terminal.
But I still do what you suggested anyway - understanding the asm listing is not as easy as you think tho and takes a lot of time ;)

Maybe the function has all of that going in it but the actual hot trace of a memcpy by 4 can't be that complicated (I also imagine it's much less than 100 instructions). If you can log the debugger output then send it to me and I'll see if it's very hard ;p
 
Last edited by a moderator:
JayFoxRox said:
no, same problem with memmove, my guess is that the last case is optimized in a somewhat weird way by gcc, I m testing this right now by re-ordering instructions and checking the asm-listing.
I also got a usb cable working but psp-gdb sucks to be honest. It seems to skip alot of breakpoints and its really crashy so thats no real help for most things..
would not be the first time gcc does that.
 
Last edited by a moderator:
Good to know that another bug's been squashed. Great work!
 
Last edited by a moderator:
I'm loving the frequent updates! Wish you best of luck with finding the sprintf() issue! Hope it doesn't frustrate you too much... :D
 
Last edited by a moderator:
JayFoxRox said:
I have only tested the cube sample so far but that runs only SLIGHTLY slower than the library version of it on my PC but its still faster than the PSP. And thats still interpreted machine code..

Could you do me a favor and find out how many instructions you're actually interpreting per second?
 
Last edited by a moderator:
I get about 25k instructions per second (in the gu/cube sample + printing some GU stuff to the console which probably slows down a bit), I m sure that can be optimized a lot too but for now this works fine. I m sure the PSP is A LOT faster than this (atleast the CPU), but it still works fine for the samples because Vertical-Sync is not working yet in the emulator ;)
I planned to add a profiler to the cube sample anyway (mainly for the GE code, but CPU too ofcourse) so thats what I will do as soon as the other problems are gone.
Yesterday, I had a look at sprintf() with psp-gdb but some registers seem to be wrong before that already - but that might be a problem with different stack pointers on real hardware.
 
Last edited by a moderator:
But can you already test some commercial game?
I mean... In terms of emulation not performace....
 
Back
Top