Theoretically Speaking, Is The Pandora At Least Capable Of Dreamcast E


khephren said:
I used to develop on the dreamcast back in the day, and one of the main differences (from an artist/designers point of view) was that the PVR2 chipset used tile based defered rendering, unlike most other GPU's that used Z-buffers for occlusion, and for checking which poly's are off screen. This makes it a lot slower to emulate the them on modern GPU's.
However, If the pandora's PVR5 GPU still uses tile based rendering, you could be in for a pleasant surprise on that front.

I would think it would be easy to go from tile to z-buffer. A tile is just a small z-buffer area used to conserve memory. You might be able to just ignore the whole tiling thing if you have a fullscreen z-buffer.
 
Last edited by a moderator:
quadomatic said:
Hmmm...can the DSP be overclocked?
TI, while showing many different clock rates and modes for the Cortex-A8, have explicitly discouraged over / under clocking the DSP. I'd assume that is a no-no.
 
Last edited by a moderator:
It`s possible to calculate the effort porting the emulator from PSP to the Pandora?
I`m not a Dev, but many of the Code must be in PSP(MIPS) Assembler. And this must be rewritten from scratch for the Pandora (ARM).
 
Tashi said:
It`s possible to calculate the effort porting the emulator from PSP to the Pandora?
I`m not a Dev, but many of the Code must be in PSP(MIPS) Assembler. And this must be rewritten from scratch for the Pandora (ARM).
There's no point doing this, long before a version with a MIPS recompiler exists... maybe if one is done then we can ask drkIIRaziel.
 
Last edited by a moderator:
Short Question: What is a recompiler? Or do you mean decompiler?
Sorry I`m not a Dev. But I like to know(basically) what are the steps to port the emulator(or any other emulator) to the pandora. Maybe my previous question is a bit naive. But I`m curious :)
 
It depends on specifics. If it's well written, most of the code doesn't need much changing, if at all. However, the dynamic recompiler (if there is one) needs to be ported to ARM.

In case you don't already know, dynamic recompilation is much like JIT compilation. It's basically generating ASM for the cpu the emulator runs on, so that the emulated system's ASM doesn't have to be interpreted instead (which is slow). Compare this to java when it was interpreted to java nowadays, when it has a Just In Time compilator.
 
I just read the whole thread, and I gotta say:

Very impressive stuff. I didn't expect the PSP to be able to emulate it at all, hopefully this will mean that we'll see some even more impressive stuff on the pandora (perhaps even playable speeds?)
 
sindbad said:
It depends on specifics. If it's well written, most of the code doesn't need much changing, if at all. However, the dynamic recompiler (if there is one) needs to be ported to ARM.

In case you don't already know, dynamic recompilation is much like JIT compilation. It's basically generating ASM for the cpu the emulator runs on, so that the emulated system's ASM doesn't have to be interpreted instead (which is slow). Compare this to java when it was interpreted to java nowadays, when it has a Just In Time compilator.
Thank you for explanation! I guessed the emulator is written in pure ASM for MIPS. But now It seems the emulator is coded in a higher language and then compiled (via recompiler) to ASM. Then this recompiler has to be ported to ARM to generate the code for the Pandora. If a recompiler exist, like Exophase explains.
I hope I understand It right.
Sorry for holding this topic on the top. I know at this state of development its only speculative the emulator is coming to the pandora, or not. And nobody whats to spread to much hope.
 
Last edited by a moderator:
jakshep2 said:
It's Theoretically possible if VERY good coding is used.
why do you persist in contributing to threads of which you know nothing about?
i, like you, have very little knowledge of coding, porting, emulator requirements and the like - so i resign myself to reading the threads instead. i think you should do the same.
 
Last edited by a moderator:
jakshep2 said:
It's Theoretically possible if VERY good coding is used.
It's also easy to build a really good spaceship if you use REALLY good glue to put the metal together.

This is about as specific as saying its possible if you believe really hard.

Have you even looked at the last few pages? If you did, you would realize how complicated emulation is and how far beyond you this is. I have coding experience, but I have no idea how emulation works. I'm not making comments on how others who understand how this works can get emulation working. I suggest you just read and learn.
 
Last edited by a moderator:
Tashi said:
sindbad said:
It depends on specifics. If it's well written, most of the code doesn't need much changing, if at all. However, the dynamic recompiler (if there is one) needs to be ported to ARM.

In case you don't already know, dynamic recompilation is much like JIT compilation. It's basically generating ASM for the cpu the emulator runs on, so that the emulated system's ASM doesn't have to be interpreted instead (which is slow). Compare this to java when it was interpreted to java nowadays, when it has a Just In Time compilator.
Thank you for explanation! I guessed the emulator is written in pure ASM for MIPS. But now It seems the emulator is coded in a higher language and then compiled (via recompiler) to ASM. Then this recompiler has to be ported to ARM to generate the code for the Pandora. If a recompiler exist, like Exophase explains. It's not really like that. It's probably written in C or C++, so the emulator source code (minus the dynrec) can be compiled to ARM directly. The dynamic recompilation part produces MIPS ASM, which needs to be changed to ARM, but even the recompiler is probably writte in C/C++.
 
Last edited by a moderator:
Very interesting. I'm not going to hold my breath for fullspeed emulation, perhaps optimization for certain games? I remember when I had an old single core PC with about 500mb RAM, I was able to play the DC shoot 'em ups at an acceptable speed. Not 100% fullspeed mind you, but fast enough to be played.
 
sindbad said:
Tashi said:
sindbad said:
It depends on specifics. If it's well written, most of the code doesn't need much changing, if at all. However, the dynamic recompiler (if there is one) needs to be ported to ARM.

In case you don't already know, dynamic recompilation is much like JIT compilation. It's basically generating ASM for the cpu the emulator runs on, so that the emulated system's ASM doesn't have to be interpreted instead (which is slow). Compare this to java when it was interpreted to java nowadays, when it has a Just In Time compilator.
Thank you for explanation! I guessed the emulator is written in pure ASM for MIPS. But now It seems the emulator is coded in a higher language and then compiled (via recompiler) to ASM. Then this recompiler has to be ported to ARM to generate the code for the Pandora. If a recompiler exist, like Exophase explains. It's not really like that. It's probably written in C or C++, so the emulator source code (minus the dynrec) can be compiled to ARM directly. The dynamic recompilation part produces MIPS ASM, which needs to be changed to ARM, but even the recompiler is probably writte in C/C++.

To put it in a more complete way, the emulator takes the GAMES code which has already been compiled for the specific system (Dreamcast in this case) and does some clever recompiling directly in memory so it can run on the system you're using. It doesn't mean that the emulator is written in ASM, but it does do some clever things with the original game to make it run better on the CPU it's being run on (MIPS or ARM in this case)
 
Last edited by a moderator:
Two links for you, one on maxconsole and drk||Raziel's blog, both basically same content but you may be interested in bookmarking the blog. Nothing really new, but drk||Raziel mentions Pandora positively, which is good publicity.QUOTE
After the code is cleaned up/rewriten there are plans to port to pandora ( www.openpandora.org, realy cool stuff )
The maxconsole writer needless to say only refers to PSP.
Regarding speed of the PSP Lite version:QUOTE
The current speeds are very low, but that is expected. There is no dynarec, no optimisation, not even a single mips assembly line on the current source. Most of the current code (everything, apart from 3d rendering) is based on the pc version of nullDC, and most of this code will be replaced. So yeah, IT WILL TAKE QUITE SOME TIME BEFORE THE PROJECT IS ANYTHING NEAR USEABLE.

The current speed (as stated by the on screen couters) is around 10%. THIS IS WRONG, IT IS ACTUALY LOWER. The interpreter runs underclocked (to make the speed bearable). This also happens on the pc build of nullDC when using interpreter (for the same reasons). The rps field (renders per second) is accurate.
 
TaG said:
The current speed (as stated by the on screen couters) is around 10%. THIS IS WRONG, IT IS ACTUALY LOWER. The interpreter runs underclocked (to make the speed bearable). This also happens on the pc build of nullDC when using interpreter (for the same reasons). The rps field (renders per second) is accurate.
I'm glad drk||Raziel publicly acknowledged this >_>
 
Last edited by a moderator:
not sure i follow there... does he just mean that he is emulating an under clocked DC? if so that is obvious from the videos i believe i remember seeming the clock being 30mhz ish which is way lower than the DC... sorry can't check myself on dialup atm
 
Back
Top