N64 Emulation on 1Ghz Pandora...

[GeePeeTwoEggs]

...having been the proud owner of a 1st gen Pandora probably, looking back probably the only disappointing thing about the machine for me was it's inability to run Goldeneye smoothly. I can't remember exactly what the framerate was overclocked to 850 Mhz with sound. Could anyone confirm what it is and what it would/ should realistically be on an overclocked 1Ghz version? The Galaxy Note runs it pretty much perfectly with the iControlpad but you still can't beat dedicated controls, can you? Thanks in advance for any help. I fear my bank account maybe getting emptied again if any replies are positive ))

 

[craigix]

It might be best to wait until some people are testing these things, maybe with overclock towards ~1.3Ghz it will run well, but the answer right now is basically 'we don't know'.

 

[Dead1nside]

That would be one of the first things I'd be interested in the performance improvements of.

 

[Askarus]

Improving Mupen64 and it's compatibility list is more mportant than more CPU power.


I run at 1000 MHZ and it's still not verry good.

 

[diligentcircle]

I've noted that overclocking doesn't seem to help on Mupen64Plus, though it's hard to tell due to lack of an FPS counter, so I guess the limiting factor must be something other than the CPU.

 

[huniper]

I've run both of the 64 emulators on my HP Touchpad which has a 1.5 GHz dual core overclocked to 1.8GHz, 1 Gb of ram and an Adreno 220, and it still doesn't run that much faster than the Pandora.


http://en.wikipedia....ndo_64#Hardware


If you read about the 64's architecture you realize how complicated the system was, there was a secondary co-processor that had two distinct parts. So you are trying to take the functions of three very different chips and make it work on a single ARM CPU with a different instruction set.


http://www.assembler...29-like-N64-CPU


Apparently the PSP emulates 64 so well because the two CPU's instruction sets are similar. At least that's my understanding of it.


Anyway back to the original topic. Unfortunately it's got to be pretty tough to code an emulator and dynarec for this system that works better than Ari64's. That is probably the only way to get real performance improvements

 

[gunrock]

Well, both the N64 and PSP have MIPS processors, thus there will be much less (if any) translation/recompilation of processor instructions needed. Just memory address translation and bespoke hardware emulation. It takes a big load off.

 

[Stradian]

What made Daedalus successful was the native high level emulation ability since the psp has a MIPS processor. Another advantage the psp had is that it has a co-processor to supplement the main one and Daedalus took advantage of this for their Async audio feature and some calculation. Finally, their team has poured heart and soul into there project for a very long time now. It is safe to say, their emulator is far more mature then the arm ports of mupen.

 

[Askarus]

Oh, hi Stradian.


How's your work with mupen going?

 

[Exophase]

What made Daedalus successful was the native high level emulation ability since the psp has a MIPS processor.

Not really. Being MIPS doesn't really helps as much as you may think. Having more registers is good, but unless you're doing static allocation (and neither have enough to do static allocation) you tend to be bottlenecked by the scope of register usage within translation blocks. That is, unless you have some kind of cross-block translation, which afaik neither do.

Another advantage the psp had is that it has a co-processor to supplement the main one and Daedalus took advantage of this for their Async audio feature and some calculation. Finally, their team has poured heart and soul into there project for a very long time now. It is safe to say, their emulator is far more mature then the arm ports of mupen.

What's the compatibility like between the two? What's the performance really like? How many hacks are in Daedalus? Ari64 put an intense amount of work into Mupen64plus's ARM recompiler..


In my eyes the biggest advantage for Daedalus is that it has good low level GPU access and can handle more texture formats natively. Mupen64plus w/gln64es2 spends a huge amount of time in the GPU driver preparing draw calls.

 

[huniper]

In my eyes the biggest advantage for Daedalus is that it has good low level GPU access and can handle more texture formats natively. Mupen64plus w/gln64es2 spends a huge amount of time in the GPU driver preparing draw calls.

So with a better, opensource graphics driver we would see framerate improvements? I wish TI would release the source code.

 

[craigix]

I wonder how well the Android N64 emu will run once the SGX driver is working properly...

 

[ShleeDragon]

I wonder how well the Android N64 emu will run once the SGX driver is working properly...

Everybodies favourite question - Does the 1GHz units support the fastfp?

 

[huniper]

I remember reading somewhere on the forum that there were some SGX driver functions that didn't work on the 1.0.3 revision of the GPU, the revision in the first couple hundred delivered Pandoras.


Since we have a different revision GPU can we use those functions now?


I'm not sure what the functions are or if they actually make a difference, just curious.

 

[notaz]

I remember reading somewhere on the forum that there were some SGX driver functions that didn't work on the 1.0.3 revision of the GPU, the revision in the first couple hundred delivered Pandoras.

Couple of thousand, not hundred, i.e. all 256M units..

 

[huniper]

ahhh I didn't know it was that extensive, these improvements would probably involve changing code in each program and that would mean fragmentation for the sake of a very small percentage of units.


Not worth it


On a side note thank you notaz, you are an asset to the Pandora community!