Hacking N64 Emulation on 3DS... Speculation

[DiscostewSM]

lol, what bout Rayman 3D or Starfox 3D, both games are convertions from nintendo 64....

They are remakes/ports, built from the ground up, designed with the target platform in mind. There is no emulation being done with either of them.

 

[Luigi2012SM64DS]

Please. Just leave.

 

[profi200]

To get usable results (but not even with this 100% on the most games) you need to run the emu completely on bare metal without anything other running like the os and you need anything the 3DS has (all 3 ARM cores, GPU, DSP). But as already metioned, the 3 ARM cores don't make it better, if you are bad at multicore programming. The architecture difference between ARM11 and 9 makes it even harder to get this running and optimised.

€:
On ARM9 is some stuff missing, the ARM11 has. Programming a emu with 3 ARM cores, which are not all the same, would be really difficult and annoying for the programmer.

 

[Foxi4]

To get usable results (but not even with this 100% on the most games) you need to run the emu completely on bare metal without anything other running like the os and you need anything the 3DS has (all 3 ARM cores, GPU, DSP). But as already metioned, the 3 ARM cores don't make it better, if you are bad at multicore programming. The architecture difference between ARM11 and 9 makes it even harder to get this running and optimised.

The thing with programming for muticore systems is a lot like carrying buckets of water.

Imagine that there's one guy (CPU core) carring two buckets of water (instructions) from a well (binary) to a tub (execution) versus two guys carrying one bucket of water each performing the same task from two separate wells. Everything is fine and dandy and the same amount of water is being transported... as long as the two guys aren't bumping into each other along the way or queuing at the tub to dump their bucket (desynchronization, one core idling because the next operation requires data that hasn't been processed by the other core yet) and the wells aren't drying up as they're doing it (Idling when the tasks in one thread are substantially more demanding than the tasks in the other thread, so one core is running at 100% stress and the other is having a nap).

Needless to say, achieving 100% efficiency is nigh-impossible with this kind of a setup when you don't have overhead processing power to waste, and unfortunately, the 3DS doesn't have that. It would require a lot of optimization to squeeze out every last bit of processing power to make this thing work properly.

Now, don't get me wrong - I'm not dissing multicore! Running multiple threads on multiple cores at the same time is extremely beneficial in contemporary applications... not so much in older applications that are merely being interpreted or recompiled live during emulation. A multicore setup is actually highly desired when emulating platforms that are multicore/multi CPU themselves, since you can emulate each core or CPU on a separate thread and a separate core, but again, this more often than not requires overhead processing power that you can waste while idling.

There are ways to go around these problems, yes, but they're rather complex and take time to develop and optimize, so a "playable" N64 emulator on the 3DS in the nearby future will remain within the realm of day dreaming for a couple years.

 

[profi200]

That's what i mean. The 3DS will never reach the performance of the single core equivalent, if such complicated things run on the cores. Not even because of the lower clock rates. I even doubt, the 3DS is as fast as the RPi with all 3 cores together, simply because it's a pain to synchronize all 3 cores, so every core permanently do something.

The generation following the 3DS will most likely do the job well, but the 3DS is not made for this.

 

[JulietStMoon]

lol, what bout Rayman 3D or Starfox 3D, both games are convertions from nintendo 64....

I seriously want to throw something every time someone says this. Being ported from another system is ENTIRELY DIFFERENT from emulation in every way imaginable. There's a huge, huge, huge, extremely apparent difference between emulating an entire console on another console, and rebuilding a specific game to run natively on another console.

 

[Coto]

before I took any look at r4300i asm, i thought it was possible. Now I see possible just ports, not emulation. The r4300i is too difficult to emulate, to not even say properly, because it takes like 5 stages for decoding an instruction on several "bit" modes. Every stage is profiled to run from 2 co processors that dealt with TLB ,instruction cache and data cache. (the execution task relied on CoProcessor0).

so when you emulate, you have to run r4300i oriented assembly, perform the shifts, align opcodes between inmediate integer type, jump type and register type (object oriented), then emulate TLB mechanism (sorts current executed instructions on a fast and small cache, or perform table-entry lookup for physical addresses), then work on weird (and possibly faulty) invalidate cache mechanism, which manually forced the programmer to keep and read data from cache, instead RDRAM (ram), and when RAM was accesed, cache had to be invalidated.

In the end, the r4300i does 32 registers for integers, and 32 for floats (on 5 stages) on the same timeline. While ARM11 has stuff like vfp, smaller 32 bit data path with power-saving oriented features. it's just not enough

 

[Rydian]

Visit GBAtemp, 11 notifications WTF? Oh somebody revived an old thread and people started reading through it.

When ports are done they're often more desirable then emulation in terms of improvements because the authors have the game's original source code (and resources), and things aren't set in stone nearly as much as when you only have the compiled assembly and resources are expected to take up a certain amount of data each. Also ports of an already-done game, after a period of time has passed, usually means that the port is to a more powerful system , so they often take the time to improve on things (since the resources used are much more flexible and they can change the source around more than simply needed to port).

With emulation you often have temporal control (save states, fast forward, rewind, save backup) and other things... assuming it's third-party emulation. First-party emulators and interpreters typically do not give those types of features.

Some things to consider when thinking about whether an older game would work better emulated or as a port.

 

[Deleted member 194275]

So why this came back to life?

Anyway, just try to emulate Gauntlet Legends (an ugly looking game) on a hi spec PC then you will see that power, even when it is enough, is not all that you need to emulate.

 

[MyJoyConRunsHot]

That's what i mean. The 3DS will never reach the performance of the single core equivalent, if such complicated things run on the cores. Not even because of the lower clock rates. I even doubt, the 3DS is as fast as the RPi with all 3 cores together, simply because it's a pain to synchronize all 3 cores, so every core permanently do something.

The generation following the 3DS will most likely do the job well, but the 3DS is not made for this.

That's only if you were planning to code the emulator yourself instead of Nintendo. The Wii theoretically shouldn't be able to run N64 either, and it's homebrew emulators are nowhere near 100%. But take a look at virtual console and see how they managed to optimize it properly for the system. I'm pretty sure the same could be done for 3DS, no need for 9th gen.

 

[XDel]

It would be great to be able to play Shadows of the Empire, DOOM 64, and Perfect Dark on anything but a N64 with those craptastic controls!

 

[MyJoyConRunsHot]

That's what i mean. The 3DS will never reach the performance of the single core equivalent, if such complicated things run on the cores. Not even because of the lower clock rates. I even doubt, the 3DS is as fast as the RPi with all 3 cores together, simply because it's a pain to synchronize all 3 cores, so every core permanently do something.

The generation following the 3DS will most likely do the job well, but the 3DS is not made for this.

That's if the you were coding a homebrew emulator for 3DS instead of Nintendo. The Wii shouldn't be able to run N64 either and the homebrew emulator's are no where near 100%, but take a look at the virtual console and see how games were optimized for the Wii that couldn't be done by the scene. The ARM11 supports up to 32KB more data and instruction cache, similar pipeline length(assumption) and higher branch prediction than the GC and the Wii (crushing Oxybelis's dmip comparison which still relies on Mhz) which put's it's power at least ahead of the GC but behind the Wii only because of the crazy high frequency. So I'm pretty sure it can handle most N64 games, no need for 9th gen.

 

[Foxi4]

That's if the you were coding a homebrew emulator for 3DS instead of Nintendo. The Wii shouldn't be able to run N64 either and the homebrew emulator's are no where near 100%, but take a look at the virtual console and see how games were optimized for the Wii that couldn't be done by the scene. The ARM11 supports up to 32KB more data and instruction cache, similar pipeline length(assumption) and higher branch prediction than the GC and the Wii (crushing Oxybelis's dmip comparison which still relies on Mhz) which put's it's power at least ahead of the GC but behind the Wii only because of the crazy high frequency. So I'm pretty sure it can handle most N64 games, no need for 9th gen.

Virtual Console titles are carefuly selected and the emulation core of each title includes game-specific patches. Each Virtual Console title is adjusted to play its game full speed - it and nothing else. This is why injecting ROM's into Virtual Console titles has hit-and-miss results.

Virtual Console performance is superior to NOT64, sure, but for good reasons - it's because the framework is coded by an army of Nintendo programmers with access to official SDK's and extensive hardware documentation, often even the original game's code, instead of one or a couple of homebrew coders with unofficial tools and no game source code, thus they know exactly what they can omit and still allow the game to function, they cut corners and achieve full speed. NOT64 is a general purpose emulator, it plays any ROM you throw at it, it doesn't cut corners and as such it's less efficient.

What I'm saying here is that you're comparing an emulation core coded specifically for *1* game to a full-blown emulator that's supposed to play a wide variety of games and that's just stretching it.

On top of that, again, we run into the problem of code parallelism on multiple weak cores which we've gone through and through again.

 

[MyJoyConRunsHot]

Virtual Console titles are carefuly selected and have game-specific patches included, their "emulator core" is adjusted specifically to play them at full speed - them and nothing else. This is why injecting ROM's into Virtual Console titles has hit-and-miss results.

Virtual Console performance is superior to NOT64, sure, but for good reasons - it's because the framework is coded by an army of Nintendo programmers with access to official SDK's and extensive hardware documentation, often even the original game's code, thus they know exactly what they can omit and still allow the game to function, cut corners and achieve full speed. NOT64 is a general purpose emulator, it plays any ROM you throw at it, it doesn't cut corners and as such it's less efficient.

Exactly, the key thing is the Wii getting many games running at full speed including Oot, if they hadn't released them, people would think the Wii was too weak to run them. Nintendo of course would do a better job than any other coder since they have more knowledge of the system and use speccially optimized emulators for individual cover games like Oot that a regular coder couldn't and shows that the Wii can run N64 games if done properly. The same could be said about the 3DS, most games can run only if the emu's are specially optimized which only Nintendo can do, if a homebrew N64 emulator turns out terrible on 3DS and Nintendo releases them on VC is the 3DS still too weak to play them?

 

[Foxi4]

Exactly, the key thing is the Wii getting many games running at full speed including Oot. Nintendo of course would do a better job than any other coder since they have more knowledge of the system and use speccially optimized emulators for individual cover games like Oot that a regular coder couldn't and it shows that the Wii can run N64 games if done properly. The same could be said about the 3DS, most games can run only if the emu's are specially optimized which only Nintendo can do, if a homebrew N64 emulator turns out terrible on 3DS and Nintendo releases them on VC is the 3DS still too weak to play them?

Yes. In my opinion, but keep in mind that it's just my opinion, the 3DS's hardware limitations make it nigh-impossible to create a Virtual Console-like framework that will efficiently emulate N64 games, even for Nintendo developlers, period. Maybe a handful of very simple titles could be emulated, but nothing of the likes of LoZ: OoT.

 

[MyJoyConRunsHot]

Yes. In my opinion, but keep in mind that it's just my opinion, the 3DS's hardware limitations make it impossible to create a Virtual Console-like framework that will efficiently emulate N64 games, period. Maybe a handful of very simple titles, but nothing of the likes of LoZ: OoT.

Remember, the higher caches , pipelines and branches will allow it to, especially with a little overclocking.

 

[Foxi4]

Remember, the higher caches , pipelines and branches will allow it to, especially with a little overclocking.

Nintendo has never resorted to overclocking their machines - their games rely heavily on CPU timing, they even did in DS times and that's just one generation behind. Higher caches, pipelines, branches or even fairy dust will not help when you're trying to perform tasks way beyond the feeble prowess of a poor 266MHz core and using two in parallel to emulate one chip wastes both time and resources as well as creates the danger of desynchronization. I can see that you're very dedicated and firmly believe in what you're saying, but I simply have to disagree with you, sorry.

 

[MyJoyConRunsHot]

Nintendo has never resorted to overclocking their machines - their games rely heavily on CPU timing, they even did in DS times and that's just one generation behind. Higher caches, pipelines, branches or even fairy dust will not help when you're trying to perform task way beyond the feeble prowess of a poor 266MHz core and using both in parallel to emulate one chip wastes both time and resources as well as creates the danger of desynchronization.

Sorry but this guy disagrees
http://arstechnica.com/gadgets/2011...nship-between-cpu-clockspeed-and-performance/
Also, Mhz has little bearing on why the Wii can run Oot,in fact it just means the Wii has to chug out a way higher clock speed just to do what the 3DS does at a lower clock speed. Only, if the Wii had a similar architecture or similar cpu specs would Mhz even be relevant. As the above says, caches, branches and pipelines have far more bearing on performance than Mhz, otherwise the Pentium 4 would exhibit much better performance at it's clock speed than the original Pentium, but unfortunately that's not the case.

I can see that you're very dedicated and firmly believe in what you're saying, but I simply have to disagree with you, sorry.

I'm saying than it's not out of this realm that an ARM11 can run Oot smoothly for the most part, ARM11's are outdated now but I have never seen them as weak as you're pushing foreword.

 

[Foxi4]

Sorry but this guy disagrees
http://arstechnica.com/gadgets/2011...nship-between-cpu-clockspeed-and-performance/
Also, Mhz has little bearing on why the Wii can run Oot,in fact it just means the Wii has to chug out a way higher clock speed just to do what the 3DS does at a lower clock speed. Only, if the Wii had a similar architecture or similar cpu specs would Mhz even be relevant. As the above says, caches, branches and pipelines have far more bearing on performance than Mhz, otherwise the Pentium 4 would exhibit much better performance at it's clock speed than the original Pentium, but unfortunately that's not the case.

I'm saying than it's not out of this realm that an ARM11 can run Oot smoothly for the most part, ARM11's are outdated now but I have never seen them as weak as you're pushing foreword.

Ehh... I'm not saying that "266 MHz is weak", I'm saying that a 266 MHz ARM11 is weak because it is. Clock speed is a measurement of cycles per second, not performance. I was referring to the performance offered by a 266 MHz ARM11 chip because that's the context of the conversation - I thought this much was clear.

You may treat DMIPS/MIPS or FLOPS as irrelevant measurements, unfortunately the rest of the world does not. Assuming that the 3DS's CPU is at least as efficient as a Cortex-A8, it's 2 DMIPS per core per cycle. At 266 MHz and two cores, that's 1064 DMIPS. The Wii's CPU pushes 2,3 DMIPS per cycle at 729 MHz, which is roughly 1676,7 DMIPS total, end of story. That's the calculation prowess of both processors within a common Integer-based benchmark and one is inferior, fact of life.

 

[justinkb]

The code would have to be extraordinarily good, perhaps even using some kind of huge static analysis of the entire N64 game's binaries before execution (which would constitute an on-the-fly "port", in a sense), for this to work within the limitations of the relatively slow 3DS. It will probably never happen, certainly not smoothly with any kind of real time emulation. Anyway, either code this or get someone to code this, speculating on it won't help anything