Hacking N64 Emulation on 3DS... Speculation

Foxi4 · Feb 19, 2014

justinkb said:
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 ;-)

Pretty much. The code would have to be re-compiled in huge chunks or even fully which would be quite a feat for the feeble 3DS.

I also like how we're still ignoring the elephant in the room - Nintendo 64 games are rendered games at 256×224, 320×240 (can be scaled relatively easily to the 3DS screen, alternatively a border could be used) and 640×480 pixels. Assuming that the scaling will be performed on the GPU and the CPU won't be additionally taxed, we're running into the simple problem of being able to actually see stuff on-screen in some games here ...so enjoy the arse-looking scaling and terrible, unreadable fonts, guys! The 3DS's screen is 400x240!

Mr_Pichu · Feb 19, 2014

The ARM9 instruction set used is a variation of ARMv5:

http://infocenter.arm.com/help/topic/com.arm.doc.dvi0022a/DVI0022A.pdf

The ARM11 has the ARMv6 instructions with media support.

http://infocenter.arm.com/help/topic/com.arm.doc.ddi0360f/DDI0360F_arm11_mpcore_r2p0_trm.pdf

MyJoyConRunsHot · Feb 21, 2014

Foxi4 said:
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.

No, sorry but MIPS and DMIPS are pretty disliked as a measurement across the internet:

Jokes aside, management has a tendency to want one figure to represent a processor's capacity. And companies are spending large amounts ofmoneybased on a poorly understood indicator, for both software and hardware acquisitions.
Unfortunately, no one number describes capacity. Processor speed varies depending on many factors, including (but not restricted to):

Workload mix

Memory/cache sizes

I/O access density

Software levels (OS and application subsystems)

Hardware changes

Partitioning

Workload mix is the largest contributor to the variability of capacity figures. An online workload has more of a random access pattern than batch (sequential) processing. Online subsystems, by design, rarely access data in a sequential pattern; they constantly request new records from disk or (hopefully) from buffers.

This brings forward the next point. Memory and cache sizes can significantly improve the throughput of a processor. Online subsystems buffer data and manage it on a least recently used (LRU) basis. The theory is that recently referenced data may be accessed again. If there is a hit (data residing in buffers), then we bypass the expensive physical I/O. This also applies to the processor cache. Memory access isn't direct; the processor moves the data to a local cache and then accesses it from there. Frequent cache updates lead to a slower-running processor.

http://www.ibmsystemsmag.com/mainframe/tipstechniques/systemsmanagement/Don-t-Be-Misled-By-MIPS/

"DMIPS" values are not actually a measurement of instructions per second, or what you're looking at as derived from peak sustained instructions per cycle. They're merely the result of a benchmark called Dhrystone. They're called DMIPS (Dhrystone MIPS) because this result is normalized against the score an old VAX machine got, a machine that allegedly could execute 1 million instructions per second.

Today Dhrystone is almost universally regarded as a poor benchmark. It's a core, scalar integer-only benchmark, meaning it fits entirely in L1 cache and therefore doesn't stress the higher level caches or system memory of a given system, which are often are the biggest contributors to real world performance. But more than that, a lot of esoteric compilation rules have to be followed to even get the benchmarks to not be optimized out, meaning that the compiled code is even less representative of real world programs. And it spends a lot of time in libc code, especially string code, meaning the results are highly subject to software tweaking, even beyond how well a compiler generates code for a platform in general.

Basically, DMIPS are just an outdated marketing tool and probably not that interesting to look at. But that doesn't stop them from being used all the time. Another benchmark, "CoreMark" addresses some of Dhrystone's basic problems, but is still core-only (as the name implies).

Still, it goes without saying that Cortex-A9 has a higher DMIPS score than A8 because it achieves better parallelism/fewer stalls due to its OoOE and shorter pipeline

http://community.arm.com/thread/3062
http://www.transputer.net/tn/27/tn27.html#x1-90004
http://www.edaboard.com/printthread185429.html
https://www.semiaccurate.com/forums/showthread.php?p=200288
I will reiterate that the Wii HAS to have a higher clock speed otherwise it would be weaker than the 3DS(for instance 450Mhz out of 729Mhz in the Wii may be equal to 266Mhz in the 3DS).Go back and read the Mhz myth article I posted up, he says the Pentium 1 does more work per clock speed which allows it to catch up with the Pentium 4 which has to have a higher clock speed to meet the same performance as the P1. But look at their DMIPS:
Pentium 1: 1.88 DMIPS
Pentium 4: 3.0 DMIPS
Why did Ars say the P1 could match the P4 in performance if they two massively different dhrystones. Is it because it not as important as other factors such as cpu spec's like in the above quotes. Thats the reason most people rarely use benchmarks comparing computers over the internet for different subjects as opposed to selecting CPU's by specs, i'm sorry to say but that's the bitter truth.

UltraMew · Feb 21, 2014

*rants*

Foxi4 · Feb 21, 2014

I'm very much aware of the MHz Myth, I know what Dhrystone MIPS is, I know what MIPS stands for. I also realize that DMIPS is an outdated benchmark, but unfortunately we don't have access to any better ones on the 3DS since it's simply not hacked to the point of coding one. It's no bitter truth to me, I'm very much aware of the issues you're pointing out.

You're mistaking MIPS (Millions of Instructions per Second) with Dhrystone MIPS (a benchmark score). They're not "disliked" on the Internet - DMIPS is simply outdated and measures a fraction of the overall potential, there are better, more contemporary benchmark alternatives out there, and MIPS isn't always accurate and dependable, but those are the only scores available to us at this point in time and those are the ones I'm relying on.

MIPS is simply a measurement of how many instructions the processor can perform per second, more or less. Yes, CPU manufacturers will use the easiest-to-perform instructions and yes, they will bend the rules to "squeeze" as much MIPS as possible on their promotional material, but that doesn't make your point stand.

A 266 MHz dual core ARM11 CPU is still not enough to properly emulate the N64, not by any stretch of the imagination. I'm yet to see a single device that efficiently emulates the platform with so little resources. And no, the smartphone you posted doesn't prove your point - the emulation was chugging and it was poor.

dubbz82 · Feb 21, 2014

you might see something along the lines of the old n64 emulator called Corn where there were numerous speed hacks, and where accuracy was hugely sacrificed for performance. The odds of anything reasonably useful outside of a few games though, is pretty slim, because the 3ds just doesn't have the horsepower to do it. Snes, probably (even there it may struggle with some of the more complex games), psx and n64 will be iffy at best...and anything newer, forget it.

Mr_Pichu · Feb 21, 2014

N64 emulation is not out of the question, but likely the results would be less than playable for most games. One approach that was used in an early N64 emulator was the recompiling of MIPS code to the target CPU instruction set. Also many nuances of the N64 hardware were ignored, thus yielding something that was more simulation than emulation.

urisma · Feb 21, 2014

Mr_Pichu said:
N64 emulation is not out of the question, but likely the results would be less than playable for most games. One approach that was used in an early N64 emulator was the recompiling of MIPS code to the target CPU instruction set. Also many nuances of the N64 hardware were ignored, thus yielding something that was more simulation than emulation.

Dynamic recompilation is what all fast emulators do nowadays. It's commonplace. You're referring to Corn, which was a static binary translator (it translated the entire .64 file ahead of use), which allowed for incredibly fast emulation at incredibly reduced accuracy. Also, "simulation" is, at least in academia, referring to completely accurate imitation of the target architecture (at the ISA level and perhaps even the microarchitechture level), whereas "emulation" is much more high level, "good enough" accuracy to where the user can't tell the difference (more or less).

enarky · Feb 21, 2014

I remember running Mario 64 on UltraHLE on my K6-233 back in the days (just looked that up, wow, that was 15 years ago), if that was possible one 3DS ARM11 core surely should be enough for a little, highly inaccurate N64 emulation. Question is, who wants something like that, besides the "because I can!" aspect from the guy who's going to write it? It'll be like the SNES Emulators on GBA, it kind of works, but was anyone seriously playing games on them?

Oxybelis · Feb 22, 2014

enarky said:
I remember running Mario 64 on UltraHLE on my K6-233 back in the days (just looked that up, wow, that was 15 years ago), if that was possible one 3DS ARM11 core surely should be enough for a little, highly inaccurate N64 emulation.

Actually I'm pretty sure K6-233 is faster than 3DS CPU.

http://www.7-cpu.com/

Code:

CPU | Frequency(MHz) | Compressing (MIPS) | Decompressing (MIPS)
 
Hisilicon SD5113 (ARM11)    530    113    283
 
AMD K6-2                    500    260    440

VMM · Feb 22, 2014

I understand why people want to emulate N64 on 3DS but seriously, it's not gonna happen.
CPU isn't strong enough, and N64 has 640x480 games, it would be needed to downscale some games,
needing even more processing power and the visual result of it wouldn't be satisfying.

Here in Brazil we have an expression that would be translated as: Don't put the car in front of the cows.
That's basically what's happening here, we didn't even have a decent SNES or GBA emulators for DS.
PSP did it decent all around, but there was plenty room for improvement in both.
When we become able to emulate almost perfectly 16 bit consoles, that's when we should start thinking on doing a N64 or PSX emulator,
but having in mind the result probably wouldn't be satisfying, few games would work and performance wouldn't be good.

dubbz82 · Feb 23, 2014

stuff could be rendered in a lower resolution initially which would probably actually eat up fewer resources...but still the emulation would likely be highly inaccurate in order to maintain decent speed....i think if anything, we'll see a proof of concept emulator capable of playing some of the less demanding n64 games (mario 64, which already has a proper nds port anyways, and one or two other games). Could it be done? yes. Will it happen? Probably not in any form that end users will really want, or at least not for a long while.

I have to agree with VMM....baby steps first. N64 is a pretty complex system, to the point that even pc based n64 emulators have their fair share of issues. First lets see a working full speed NES emulator even. At this point in time, i think N64 emulation is WAY off in the future, if it happens at all.

Wisenheimer · Feb 23, 2014

VMM said:
I understand why people want to emulate N64 on 3DS but seriously, it's not gonna happen.
CPU isn't strong enough, and N64 has 640x480 games, it would be needed to downscale some games,
needing even more processing power and the visual result of it wouldn't be satisfying.

Here in Brazil we have an expression that would be translated as: Don't put the car in front of the cows.
That's basically what's happening here, we didn't even have a decent SNES or GBA emulators for DS.
PSP did it decent all around, but there was plenty room for improvement in both.
When we become able to emulate almost perfectly 16 bit consoles, that's when we should start thinking on doing a N64 or PSX emulator,
but having in mind the result probably wouldn't be satisfying, few games would work and performance wouldn't be good.

Most N64 games are 240p, same as the 3DS. Some are 480i, but they're still only drawn 240 lines at a time. N64 games rarely if ever use sprites, so it would not have to be "downscaled". It would just have to be rendered at 240p, which probably would not look all that much worse than the originals since they used low polygon counts and textures to begin with. The only thing which might be a problem is rendering text on some 480i-only games, since those are probably sprites.

The biggest issue is the CPU, which would probably have to be brought up to a much higher speed ( I would guess normal clock is around 1GHZ but the 3DS CPU is usually significantly underclocked) to get any descent N64 emulation and would likely kill the battery.

I'm willing to bet though that even the few N64 games that were made to run only at 480i, like Majora's Mask, would look fine on the 3DS screen.

Wisenheimer · Feb 23, 2014

urisma said:
Dynamic recompilation is what all fast emulators do nowadays. It's commonplace. You're referring to Corn, which was a static binary translator (it translated the entire .64 file ahead of use), which allowed for incredibly fast emulation at incredibly reduced accuracy. Also, "simulation" is, at least in academia, referring to completely accurate imitation of the target architecture (at the ISA level and perhaps even the microarchitechture level), whereas "emulation" is much more high level, "good enough" accuracy to where the user can't tell the difference (more or less).

Real-time simulation of even an Atari 2600 at the transistor level is probably beyond even the fastest workstation computers today. You would probably need a supercomputer.

Part of the problem with N64 emulation is that it is way too high level. Nobody has figured out how to do it well. They could do it at a lower level, but not with today's slow clock-speeds.

Foxi4 · Feb 23, 2014

Wisenheimer said:
The biggest issue is the CPU, which would probably have to be brought up to a much higher speed ( I would guess normal clock is around 1GHZ but the 3DS CPU is usually significantly underclocked) to get any descent N64 emulation and would likely kill the battery.

Were are you getting this information from? All the reports I've seen say that it's a dual core 266 MHz CPU. That being said, the amount of cycles doesn't really say much when you don't know the actual core efficiency per cycle.

Wisenheimer said:
Most N64 games are 240p, same as the 3DS. Some are 480i, but they're still only drawn 240 lines at a time. N64 games rarely if ever use sprites, so it would not have to be "downscaled". It would just have to be rendered at 240p, which probably would not look all that much worse than the originals since they used low polygon counts and textures to begin with. The only thing which might be a problem is rendering text on some 480i-only games, since those are probably sprites.

I'm willing to bet though that even the few N64 games that were made to run only at 480i, like Majora's Mask, would look fine on the 3DS screen.

Well, perhaps sprites as they're understood in dev speak weren't used often (sets of tiles set on a matrix), but "flat" textures were used prominently in Nintendo 64 games - in Mario Kart 64 everything except for the map is a pseudo-sprite. To make the game look "normal" you'd have to render it in the background, re-size the frame and then display it, and that messes up text. Processing each and every texture on the fly sounds too inefficient to reach playable speeds. Then again, I'm no emulator coder, that's just what makes sense in my head.

Ulieq · Feb 23, 2014

If the DSI can't be hacked, no way the 3DS will be.

dubbz82 · Feb 23, 2014

Ulieq said:
If the DSI can't be hacked, no way the 3DS will be.

In case you missed the nearly 40 page (and still growing) homebrew thread, there's already a good amount of work underway to get stuff up and running on 4.1-4.5 firmware 3ds's. Nothing anywhere near on the level of an n64 emulator yet, but we already have a few simple games (tetris, pong, and snake clones) and even a chip-8 emulator. No one has (at least publicly) figured out, and released to the public yet, a way to access the arm11 cpu yet, however I'm sure that's not too far off, seeing that's how the current rom loading carts work (from my understanding anyways...)

Wisenheimer · Feb 23, 2014

Foxi4 said:
Were are you getting this information from? All the reports I've seen say that it's a dual core 266 MHz CPU. That being said, the amount of cycles doesn't really say much when you don't know the actual core efficiency per cycle.
Well, perhaps sprites as they're understood in dev speak weren't used often (sets of tiles set on a matrix), but "flat" textures were used prominently in Nintendo 64 games - in Mario Kart 64 everything except for the map is a pseudo-sprite. To make the game look "normal" you'd have to render it in the background, re-size the frame and then display it, and that messes up text. Processing each and every texture on the fly sounds too inefficient to reach playable speeds. Then again, I'm no emulator coder, that's just what makes sense in my head.

It's an ARM 11 CPU. No doubt, it's factory stable clock speed is somewhere in the 600-1200mhz range and it is underclocked whenever possible to save battery life. The architecture was designed from the beginning to have a clock speed of up to 1000 mhz and that is the max factory speed of similar dual-core ARM chips from the same era as the 3DS. Unless hackers actually figure out how to screw around with it, it is hard to predict how high it can be pushed, how badly it will kill the battery, and at what speed it becomes unstable. Because it is an ARM11 design from around 2011, we can assume it is similar to other smart device chips released around that time.

The N64 uses polygons for most 2D objects, so it is simply a matter of rendering those polygons and there textures in 240p instead of 480i. There are no extra steps involved. I'm not sure how it renders text, but I doubt it would be too difficult to get the few 480i games to render it correctly. The real question is CPU power and the efficiency and dedication of the programmer. We know it is possible to get N64 games somewhat playable on Smartphones with similar chips, although it would help to have a processor that is a level about that, like the one in the Vita, iPad Air, or S4 Galaxy, which can push much higher clock speeds.

I don't have high hopes for a good N64 or PS1 emulator on the 3DS, because it takes a lot of work to get one running, even on modern high power hardware. Getting something fully playable at 100% speed on the 3DS would be challenging, and it probably would kill the battery pretty quickly. It would take some dedicated developers. I think many of them have moved on from game consoles to x86 and ARM pocket pc's.

placebooooo · Feb 23, 2014

I personally believe that when the 3ds is hacked and if a n64 emulator comes out for it, it will be just like daedalusx64 on psp but maybe just a little more compatibility?

Foxi4 · Feb 23, 2014

placebooooo said:
I personally believe that when the 3ds is hacked and if a n64 emulator comes out for it, it will be just like daedalusx64 on psp but maybe just a little more compatibility?

The problem with this is that both the PSP and the N64 were based on the MIPS architecture, not everything had to be emulated to get the code running. It's going to be different with the 3DS.

I'm with Wisenheimer on this, I don't think it can be achieved on the 3DS's stock configuration. It's entirely possible that the chip is downclocked to 2x266 MHz rather than customly-made, but if that's the case, with overclocking it we're running into issues of not only battery life but also power supply in general as well as cooling. We don't know how the 3DS would take a 50% increase in clock speed in terms of stability, and I'm saying 50% because I think that 2x 500 MHz or so would be the point where we could reasonably talk about somewhat playable N64 emulation on ARM11.

Just to clarify, by "pseudo-sprite" I meant textures drawn on quads, so polygons as you mention yourself, Wisenheimer. Changing the internal resolution has a nasty tendency of stretching/shrinking those which may negatively affect the picture quality. Then again, scaling the whole display is no good either and it eats up more resources, so you have a point there.

Ulieq said:
If the DSI can't be hacked, no way the 3DS will be.

But alas, the DSi can be hacked, it's just terribly inconvenient since it requires dumping dev.kp, and due to Nintendo's updates that means soldering. That's not a very user-friendly solution, hence DSi hacking never really took off. Nevertheless, DSi homebrew exists and works perfectly fine, it's just that nobody was interested in it enough to build a scene around it.

Hacking N64 Emulation on 3DS... Speculation

Endless Trash

かわいいね！

Well-Known Member

GBATemp's Mew PRETENDING TO BE FOXI4 4 A DAY

Endless Trash

Well-Known Member

かわいいね！

Active Member

owls?

Well-Known Member

Hamon > Stand

Well-Known Member

Well-Known Member

Well-Known Member

Endless Trash

Well-Known Member

Well-Known Member

Well-Known Member

Well-Known Member

Endless Trash

Similar threads

Popular threads in this forum