Hacking N64 Emulation on 3DS... Speculation

[Rydian]

Yeah but we can still send and recieve data faster over it than on a gameboy right? So if we recive the data first, then we could work with it and even it out right replicate the speed and latency.
A little like streaming a video

You're talking about bandwidth, not latency.

Let's say you have two types of cars. They're identical in every way except the max speed, one can go up to 100MPH, the other can only go up to 50MPH. The time it will take for an individual car to get to it's destination is the latency.

Now let's say you want to send out a package with these. Obviously the car that can go faster and get there in less time is the one to go for when you only have one car load to send. If there's only one car load, the 100MPH car will get there a lot faster than the 50MPH car every time.

Now, what if you had more than one car? Let's say you only have 5 of the 100MPH cars, but you have 20 of the 50MPH cars. If you have a job that needs 20 packages to be sent, the 100MPH cars would need to make four trips, while the 50MPH cars would only need to make one. So even though the 100MPH cars are individually faster, the whole job (download) is completed in less total time with the 50MPH cars because you can send out more packages at once.

The speed of an individual car is the latency, the number of them that you can send out at once is the bandwidth.

• Downloading stuff online depends on the bandwidth. You can have 500ms ping (half a second of latency, which is terrible), and that'd only delay the start of the download by half a second... how fast you get the pieces of the package depends on your bandwidth, how many pieces you can get at a time. The latency matters little to none, it's bandwidth that determines how "fast" the download/stream/whatever finishes.
  
  
• Online gaming is an example of something that depends on latency. Each individual command you give to your character in a multiplayer game needs to be sent out to the other players, so the quicker each individual piece of data gets across the network, the less lag there will be. As long as you have enough bandwidth for the game (usually not an issue nowadays), latency is the defining factor in lag.

Anyways, link cable trading stuff was designed to go over a cable that's no more than a few feet of length, and assumes little to no latency. The internet goes over far more distance and has a lot more latency. One game unit would send some data, not get a response in a few milliseconds, and assume the cable had been disconnected or something, or the two devices could easily go out of synch and crash the connection, etc.

It might work if the emulators on both sides buffered up the data before simulating the trade with the actual units, but this would need to be programmed specifically per-game...

 

[DaniPoo]

You're talking about bandwidth, not latency.

Let's say you have two types of cars. They're identical in every way except the max speed, one can go up to 100MPH, the other can only go up to 50MPH. The time it will take for an individual car to get to it's destination is the latency.

Now let's say you want to send out a package with these. Obviously the car that can go faster and get there in less time is the one to go for when you only have one car load to send. If there's only one car load, the 100MPH car will get there a lot faster than the 50MPH car every time.

Now, what if you had more than one car? Let's say you only have 5 of the 100MPH cars, but you have 20 of the 50MPH cars. If you have a job that needs 20 packages to be sent, the 100MPH cars would need to make four trips, while the 50MPH cars would only need to make one. So even though the 100MPH cars are individually faster, the whole job (download) is completed in less total time with the 50MPH cars because you can send out more packages at once.

The speed of an individual car is the latency, the number of them that you can send out at once is the bandwidth.

• Downloading stuff online depends on the bandwidth. You can have 500ms ping (half a second of latency, which is terrible), and that'd only delay the start of the download by half a second... how fast you get the pieces of the package depends on your bandwidth, how many pieces you can get at a time. The latency matters little to none, it's bandwidth that determines how "fast" the download/stream/whatever finishes.
  
• Online gaming is an example of something that depends on latency. Each individual command you give to your character in a multiplayer game needs to be sent out to the other players, so the quicker each individual piece of data gets across the network, the less lag there will be. As long as you have enough bandwidth for the game (usually not an issue nowadays), latency is the defining factor in lag.

Anyways, link cable trading stuff was designed to go over a cable that's no more than a few feet of length, and assumes little to no latency. The internet goes over far more distance and has a lot more latency. One game unit would send some data, not get a response in a few milliseconds, and assume the cable had been disconnected or something, or the two devices could easily go out of synch and crash the connection, etc.

It might work if the emulators on both sides buffered up the data before simulating the trade with the actual units, but this would need to be programmed specifically per-game...

I get that, it's just hard to accept...

 

[MANU.M.T]

Zelda OOT is on 3DS, so to a certain extent it's possible, but with an emulator... This is another story

 

[Rydian]

Zelda OOT is on 3DS, so to a certain extent it's possible, but with an emulator... This is another story

OOT for the 3DS was a remake, not emulation.

 

[MyJoyConRunsHot]

PSX CPU (R3000) is roughly 1 dmips per mhz
http://www.datasheetarchive.com/indexer.php?file=DSA00504090.pdf&dir=Datasheet-029&keywords=1/R3000 mips&database=user-highscore#

R4000 is higher than that. 1.1-1.2

ARM11 ARMv6Z is 1.25 (max) dmips per mhz
http://en.wikipedia.org/wiki/List_of_ARM_microprocessor_cores

R4000 @333MHz 366-400 dmips
ARM11 ARMv6K @268MHz is 335 dmips maximum.

google dmips if you don't know what it is.

"Both are utterly useless when you want to determine whether a special device will provide enough performance to execute a given task. to be fair though, MIPS are even a little bit more useless than DMIPs."
http://mohammadthalif.wordpress.com/2011/12/13/diffrence-between-mips-and-dmips
Sorry but randomizer may still be correct.

 

[Foxi4]

"Both are utterly useless when you want to determine whether a special device will provide enough performance to execute a given task. to be fair though, MIPS are even a little bit more useless than DMIPs."
http://mohammadthalif.wordpress.com/2011/12/13/diffrence-between-mips-and-dmips
Sorry but randomizer may still be correct.

That's all nice and dandy in theory, but in practice we follow architecture standards. General-purpose CPU's like the ones found in PC's or mobile devices will not be limited to one/few particular instructions necessary for their operation - they'll have instruction sets of their particular architecture, so the whole argument on which this article is based is a false premise in this context. Both DMIPS and MIPS do matter, however the statement that they're generalizing things and some instructions are executed slower than others or aren't present at all on the other machine is entirely correct.

 

[MyJoyConRunsHot]

That's all nice and dandy in theory, but in practice we follow architecture standards. General-purpose CPU's like the ones found in PC's or mobile devices will not be limited to one/few particular instructions necessary for their operation - they'll have instruction sets of their particular architecture, so the whole argument on which this article is based is a false premise in this context. Both DMIPS and MIPS do matter, however the statement that they're generalizing things and some instructions are executed slower than others or aren't present at all on the other machine is entirely correct.

Then by your definition, this should not be happening:

HTC Wildfire S arm11 600Mhz single core.
3DS arm11 dual-core 532/6Mhz total

If this can run it at full speed with minimal frame rate issues on a single-core, imagine what the dual-core 3DS can do at full power. This alone would make the arm11 quite a bit more powerful than the PSP because it does more work translate, compared to the PSP which uses an MIPS and has to do much less. N64 on VC should be right around the corner at this rate.

 

[Luigi2012SM64DS]

Then by your definition, this should not be happening:

HTC Wildfire S arm11 600Mhz single core.
3DS arm11 dual-core 536Mhz total

If this can run it at full speed with minimal frame rate issues on a single-core, imagine what the dual-core 3DS can do at full power. This alone would make the arm11 quite a bit more powerful than the PSP because it does more work translate, compared to the PSP which uses an MIPS and has to do much less. N64 on VC should be right around the corner at this rate.

What about RAM and shit.
CPU mhz means nothing.

 

[MyJoyConRunsHot]

What about RAM and shit.
CPU mhz means nothing.

Didn't we all agree on this.
128MB is more than enough.
Even devices with barley any RAM can run n64 full speed, see PSP.

 

[JulietStMoon]

Ugh, why did you bring this thread back to life?

 

[Foxi4]

Then by your definition, this should not be happening:

HTC Wildfire S arm11 600Mhz single core.
3DS arm11 dual-core 536Mhz total

If this can run it at full speed with minimal frame rate issues on a single-core, imagine what the dual-core 3DS can do at full power. This alone would make the arm11 quite a bit more powerful than the PSP because it does more work translate, compared to the PSP which uses an MIPS and has to do much less. N64 on VC should be right around the corner at this rate.

There are several problems with your reply, I'll address them one by one...

Firstly, my definition doesn't make the above impossible at all as both CPU's are several times more powerful than the N64's. I never said that emulation of the N64 on the 3DS is completely impossible and I'm not sure where you're getting that idea from.

Secondly, never "add clockspeeds" and equate that to horsepower - you only get better results on paper wheras in real life, a dual core setup forces you to parallelize your code which may or may not increase performance depending on the coder's skill. That's not to say that multicore setups are less efficient - they're more efficient, but also more demanding. See, there's a good reason why lots of emulators do not benefit from having more than two cores on-board - it's because that's easy to code. Say, one core will handle game logic, the other will handle sound and misc. guff and you're all set. Unfortunately, in the case of the 3DS it's going to be two slow and poor cores doing the labor - that can be a bottleneck unless the workload is parallelized just right.

Thirdly and finally, this isn't full speed - it's nowhere near full speed and on top of that, Mario 64 isn't a particularly demanding game - it uses a small number of polygons and resorts to gourad shading rather than textures for most surfaces, which is why it's easy to emulate. Throw an Ocarina of Time at that emulator on a Wildfire and you're in for choppy madness, not to mention that OoT is choppy on real hardware to begin with. Better yet, try something that uses multi-layered textures and see what happens - think Rogue Squadron or Banjo Kazooie. I'm also not hearing any sound - thank god, because it surely would be monstrously out of sync. Differentiate "playable" and "full speed" please.

Even devices with barley any RAM can run n64 full speed, see PSP.

There's such a thing as architectural differences. When you're emulating another system that shares the same architecture (in the case of the N64 and the PSP it's MIPS) a lot of the instructions can be directly executed. When you're not, the workload is much larger as they have to be interpreted or re-compiled into executable instructions.

 

[DiscostewSM]

Not sure if it was mentioned, but isn't it kinda bad to use smartphones/tablets/etc as examples for a case like this? Now, I'm no expert, but I would imagine they have a lot more going on in the background than a 3DS does. Not saying it makes N64 full-speed emulation possible, but I would think it wouldn't require as much resources to pull off similar results.

 

[Foxi4]

Not sure if it was mentioned, but isn't it kinda bad to use smartphones/tablets/etc as examples for a case like this? Now, I'm no expert, but I would imagine they have a lot more going on in the background than a 3DS does. Not saying it makes N64 full-speed emulation possible, but I would think it wouldn't require as much resources to pull off similar results.

Very true, and on top of that in the case of Android almost everything's running on Dalvik JVM and even native binaries coded in NDK have to bounce off it before getting straight to the hardware so it's not a 1:1 performance dealio...

inb4RydianGivingASpeechAboutHowJITisALMOSTasGoodAsNativeCode hey, I'm just covering all the bases here! ;O;

 

[MyJoyConRunsHot]

There are several problems with your reply, I'll address them one by one...

Firstly, my definition doesn't make the above impossible at all as both CPU's are several times more powerful than the N64's. I never said that emulation of the N64 on the 3DS is completely impossible and I'm not sure where you're getting that idea from.

The argument is about how well they can emulate N64 which the video demonstrates can easily happen very well.

Secondly, never "add clockspeeds" and equate that to horsepower - you only get better results on paper wheras in real life, a dual core setup forces you to parallelize your code which may or may not increase performance depending on the coder's skill. That's not to say that multicore setups are less efficient - they're more efficient, but also more demanding. See, there's a good reason why lots of emulators do not benefit from having more than two cores on-board - it's because that's easy to code. Say, one core will handle game logic, the other will handle sound and misc. guff and you're all set. Unfortunately, in the case of the 3DS it's going to be two slow and poor cores doing the labor - that can be a bottleneck unless the workload is parallelized just right.

Actually, you can add clock speeds together to theoretically get the same performance. A dual-core 268Mhz arm11 in itself can theoretically be the same or better than a single-core 536Mhz arm11 as long as the program running is optimized to use the dual-core efficiently, hence why Cube/Wii ports run like c.rap. Plus, the 3DS has a sound processor to shift some of the burden.

Thirdly and finally, this isn't full speed - it's nowhere near full speed and on top of that, Mario 64 isn't a particularly demanding game - it uses a small number of polygons and resorts to gourad shading rather than textures for most surfaces, which is why it's easy to emulate. Throw an Ocarina of Time at that emulator on a Wildfire and you're in for choppy madness, not to mention that OoT is choppy on real hardware to begin with. Better yet, try something that uses multi-layered textures and see what happens - think Rogue Squadron or Banjo Kazooie. I'm also not hearing any sound - thank god, because it surely would be monstrously out of sync. Differentiate "playable" and "full speed" please.

Yes that is full speed as you can get save the frame rate issues. Have you tried Oot on this phone?
N64 has been known to run well with sound on iphone 3G:
arm11 single-core 620Mhz (underclocked to 412Mhz)
128MB eDRAM (Wildfire S had 512MB but didn't do any better)

There's such a thing as architectural differences. When you're emulating another system that shares the same architecture (in the case of the N64 and the PSP it's MIPS) a lot of the instructions can be directly executed. When you're not, the workload is much larger as they have to be interpreted or re-compiled into executable instructions.

Hence why you can't properly compare the PSP with the 3DS cpu 1:1, the architecture are too different. However, since Wildfire/S and iphone 3G can run them very well shows how much more powerful they are than the PSP since they have to do far more work to run the same game at a comparable speed.

 

[profi200]

I'm aware, the Android and Java problem, but i want to add my Mustard

OoT runs not even on my quadcore Cortex-A9 Tablet without any lag, so i don't want to destroy the hope of someone, but i do it: A N64 emu, which can play everything in fullspeed will never exist.

A good reference is the Raspberry Pi with a ARM1176JZFS (single core). Even the RPi has some problems with emulating N64. Don't expect much from the 3DS with a dual core CPU and a lower clock rate then.

spyro3dsguy:
You must have really shit eyes. For me it looks really laggy in that video.

 

[Foxi4]

The argument is about how well they can emulate N64 which the video demonstrates can easily happen very well.

Sure. A choppy, proof-of-concept, somewhat playable version, yes. Full speed? No, at least not with all games, and forget about full compatibility. Again, not "impossible", just "poor".

Actually, you can add clock speeds together to theoretically get the same performance. A dual-core 268Mhz arm11 in itself can theoretically be the same or better than a single-core 536Mhz arm11 as long as the program running is optimized to use the dual-core efficiently, hence why Cube/Wii ports run like c.rap. Plus, the 3DS has a sound processor to shift some of the burden.

Provided it is well-optimized for parallel, multicore code. For that statement to be true, both cores would have to run code at 100% efficiency which is practically never the case.

As far as the sound coprocessor argument is concerned, it's somewhat irrelevant unless the expected sound formats match, which they probably don't and will have to be pre-processed on the CPU anyways. It takes some toll off, but not a whole lot.

Yes that is full speed as you can get save the frame rate issues. Have you tried Oot on this phone?
N64 has been known to run well with sound on iphone 3G:
arm11 single-core 620Mhz (underclocked to 412Mhz)
128MB eDRAM (Wildfire S had 512MB but didn't do any better)

"As full speed as you can get" meaning not full speed at all - it's clearly choppy, I don't think I'm going blind. As far as the iPhone 3G is concerned, its applications run directly on the hardware while Android ones go through Dalvik as I've mentioned earlier, so it's able to squeeze out a little bit of extra power there. That, and again, we're running into the parallelized code issue again.

Hence why you can't properly compare the PSP with the 3DS cpu 1:1, the architecture are too different. However, since Wildfire/S and iphone 3G can run them very well shows how much more powerful they are than the PSP since they have to do far more work to run the same game at a comparable speed.

Nobody has ever claimed that they're less powerful than the PSP - we know that they're more powerful, we can effectively calculate that.

 

[MyJoyConRunsHot]

I'm aware, the Android and Java problem, but i want to add my Mustard

OoT runs not even on my quadcore Cortex-A9 Tablet without any lag, so i don't want to destroy the hope of someone, but i do it: A N64 emu, which can play everything in fullspeed will never exist.

A good reference is the Raspberry Pi with a ARM1176JZFS (single core). Even the RPi has some problems with emulating N64. Don't expect much from the 3DS with a dual core CPU and a lower clock rate then.

spyro3dsguy:
You must have really shit eyes. For me it looks really laggy in that video.

What the hell did we say about clock speeds?

 

[Foxi4]

What the hell did we say about clock speeds?

You keep maintaining that if a 600MHz ARM11 processor can be used to emulate the N64 poorly then the 3DS's 266MHz dual core ARM11 CPU can do it too... which is the case, but it can do it just as poorly if not worse. Of course we're omitting the whole "smartphones have an OS on their back as well" debacle, but that's the point you're making, or so I understand it - I'm assuming that so did profi200.

 

[pancho-mazorca]

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

 

[Foxi4]

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

Exactly. Rayman 3D is a port and Starfox 3D is a remake. They're not being emulated, they're native 3DS code - they don't need any extra processing power. It's the same case as with Ocarina of Time 3DS.