Pandora Pandora-psp

[Bosbeetle]

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

 

[Shaun199three]

Thanks for the quick reply. I thought your analogy was good to since it helped me understand the metaphor. :lol:

 

[Exophase]

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.

 

[Chip]

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.

 

[MarkoeZ]

i think in this case he was simply referring the amount of people that did not know, and not the plausibility of the emulator

 

[mcobit]

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.

 

[JayFoxRox]

<Moved to Pandora-PSP Blog>

 

[pelrun]

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?

 

[JayFoxRox]

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..

 

[Exophase]

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..

 

[JayFoxRox]

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

 

[Exophase]

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

 

[truekaiser]

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.

 

[JayFoxRox]

<Moved to Pandora-PSP Blog>

 

[Vorporeal]

Good to know that another bug's been squashed. Great work!

 

[lippy]

I'm loving the frequent updates! Wish you best of luck with finding the sprintf() issue! Hope it doesn't frustrate you too much...

 

[Exophase]

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?

 

[JayFoxRox]

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.

 

[giovanni]

But can you already test some commercial game?
I mean... In terms of emulation not performace....

 

[borgqueenx]

ExoPhase and JayFoxRox should team up and both make the emulator
2 minds are better then one ^^