What Emulator WON'T run on a DS *N64*

[RemyK313]

Man, this thread is just chock full of misinformation and plain not-knowing...

Why is emulation for the N64 unlikely? Because it would be really difficult to set up a hypervisor or any sort of high-level emulation like the kind that was implemented for the first N64 emulators....

If you compare the hardware in the 64 and the DS, you'll see that they come from similar architectures. Sure, they're not the same family, but say I wanted to chock up a very quick program to run on the 64... that same code could be run on either of the DSs processors with very little change....

However, to implement emulation for the 64, you'd have to implement emulation for ALL of its parts. That's not all that crazy of a feat, just I don't really know how you'd get it running all in tandem, and at a decent speed...

It has absolutely NOTHING to do with that stupid, "you need 7 times the power" rule. That's just a plain dumb statement. I mean, not only is power defined by the people who say this only in terms of processing speed, but they obviously don't look at history.

The 64 ran at about 93Mhz and within its viable life was "emulated" (it was a high-level thing, which is weird because it didn't really emuate, as it did hack and hotspot its way through) on machines that were running at 250Mhz or so...

About 90% of all emulation is done because developers have two things : knowledge of the systems they're working to develop for, and documentation for the thing they're trying to emulate...

However, the big problem with emulation ISN'T necessarily with what functions in the system are supported on a hardware level, but how those systems communicate with each other.....

For instance, when it comes to Saturn emulation, their DSP uses chips which have no documentation out on them. So, we may never see perfect Saturn sound emulation......

As for "an 8-bit processor running at 16Mhz isn't faster than a 16-bit processor running at 12Mhz" why? Do you specifically know what the CPI is for the processors? Or what applications are going to be run on it? If the byte/word size is the same for both processors and they're running the same code, then yeah, the 8-bit processor's going to be faster.. A 75Mhz FPGA made to encode MPEG-2 video will do it faster than a 3300Mhz Pentium 4 that's encoding on top of an operating system.

The straight truth is that the reason you won't see N64 emulation isn't necessarily because of power, but because hypervising, or HLE can't be directly(easily) be translated to the DS. Part of that is because there still isn't full documentation for all of the parts of the 64 or the DS, and the other reason is because the two systems have different hardware configurations which makes a direct translation difficult, if not impossible.

But who knows. If you have enough documentation generally these things are done.....

For instance, if I had an intimate knowledge of the DS' hardware (which, about 80 percent of all homebrew for the DS relies on knowing the system well) there's no reason why I couldn't whip up a direct ARM translation for MAME... considering MAME source code is fairly easy to read, and documented to the best of their abilities.....

I know that part of the reason why you can't run MAME straight as an ARM port has something to do with instruction memory, or immediate data memory available to the DS..... something to do with 32Mbits... and MAME is well over that size...

But just look at MarcaDS. He basically did exactly what I just mentioned : he whipped up some ARM code, probably churned it through DevKitARM, and just "saw how it went." He pared down the size of the supported drivers, and ONLY implemented the drivers for the games he wanted to emulate, namely Pac-Man...

There's no reason why that same exact process couldn't be done for other MAME games on a game-to-game basis. Especially when you consider other developers have already found a way to use a slot-2 card as an extra RAM system. If you email the guy who came up with a way to use slot-2 as extra program data, and the developer for MarcaDS for their code, there's no reason why they wouldn't give it to you...

Especially for MAME. Since he's already done the translation for a few games, chances are he's already developed the MAME core. From thereon, all you'd have to is individually translate individual drivers... It becomes a task in busy-work....

But I mean, this is stuff that's obvious to anyone that actually develops, and actually gets into the hardware. It also becomes apparent to those who are new to the hobby, and pick up devkitpro and a few assembly lessons......

But where in the crap do these magic numbers come from? All this instant benchmarking and machine comparisons with absolutely no benchmarking standards? It's almost like listening to old wives' tales. You know, like how you shouldn't eat a bowl of cherries with milk? Yeah, exactly like that is why you need 7 times the power to "emulate" anything on anything....

[Mr_Biggs]

Hey, welcome to DCEmu.

That's quite the bit of contradiction there, mate. You seem to make some good points, but now I'll toss a few your way.

Yes, back in the first years of N64 emulation, you could use a 250Mhz Pentium II to emulate some games. But we're not talking about a 250Mhz processor here, the DS has a 67 and 33 Mhz processor, which you can't say total up to 100 Mhz, due to needing to run separate processes on them. So it's even weaker than the 64.

And while we're on that note, what's similar between a DS and a N64? I know there wasn't an ARM processor inside a N64. Sure, they both use cartridges and used 3D graphics, but that's like comparing a SNES to a Genesis. Only similarities I see.

The "magic number" that was described throughout this thread is based from observation, as a figure needed for full emulation. If you think it's a old wifes' tale, write us an emulator that can play Super Mario 64. To my knowledge, one system has never been emulated at or lesser than it's native system's specs.

And honestly, if it was possible, somebody would have done it already.

P.S. Correct me if I'm wrong, but isn't a Hypervisor used to create a virtual platform for an operating systems(i.e not an emulator), such as Linux on Xbox 360?

[RemyK313]

MHz is not an accurate benchmark for speed. Like I said earlier, an el-cheapo FPGA clocked at 50MHz can encode MPEG-2 video faster than a 3Ghz Pentium 4.

The clock speed doesn't contribute entirely when benchmarking. In fact, reducing a processor's CPI and using more efficient instructions is a much, much better way to gain performance..

As for the ARM processor, I was comparing the way that ARM and MIPS are coded for. They're similar architectures, and if you can program for one, then programming for the other one requires very little conversion. All RISC processors have a similar way of being coded for. It's kinda like how if you know C# you can typically read through Java without too much confusion.

The way that 3D graphics are handled on the 64 and DS are really different, and neither of which are documented very well (well, the ARM7TDMI processor is documented REALLY well )... what with Nintendo not actually having released any official documentation for the system, and the fact that none of the official SDKs have been leaked (except for one of the earliest ones). We end up kinda shooting in the dark with the 3D stuff a lot more than with the 2D ones. I'd say that translating the 3D stuff on the DS in ANY manner is difficult because the parts are so different. There is no direct translation. The guys who wrote UltraHLE ingeniously figured out that the 64 makes calls to the hardware in a really high level format. From there, they implemented functionality for those high level calls at the low level. Add in a ton of hacks for speed, and you've got an emulator for a console during the period of its commercial viability.

So what's similar? For one, the base the systems sit on are accessible to developers in a similar fashion. I never intended to say that the two systems had similar hardware configurations, my point was the opposite : the two systems have profiles that are radically different...

If in fact there could be a way to implement the 64's weird RCP directly through the DS' shadowy 3D modules, I doubt there'd really be too much else to stop it from being able to do the 64. The 64 got its "64" from that crazy RCP that they implemented, and a million things in that part of the system make it really, really hard to see an implementation of the system on the DS.

I mean, if the 64 could do what it did at 100 mips, I'm sure that the DS wouldn't have any trouble with its beefy 300 mips processing output. That's three times the processing ability right there

In any case, lack of documentation, and lack of hardware profile compatibility is like 80% of the reason why 64 can't be implemented as a hosted hypervisor on top of the DS, translated directly, or otherwise "emulated."

We might see a 64 emulator should all the pieces be fit into place.. meaning a good implementation at a low level on a 32-bit machine, and that entails tons more documentation on not just the 64, but the DS as well.

I mean, as of right now, homebrew developers don't have the greatest understanding of the 3D hardware. If Nintendo would just wisen up, and at least DOCUMENT the damn system, make it more accessible to developers, I'm sure that the guys at devkitpro would make some great tools to make it easy for the rest of us guys who aren't geniuses but like making games.

As for the 7 times rule... in just a couple years the way we perceive computing speed is going to be radically different from the way we've been thinking about it for the last 30 years. Seeing as we've just about hit the limit for clocking speed, and the fabrication processes, the future of performance lies in parallel computing. Even now, a lot of people are buying dual-core and more-than-that-core computers... you can't really even find a computer with a single-core processor anymore. Eventually, computers are going to come to the point where everything is an embedded, parallel system, running connected to a superfast bus... and people who were around when everything was clocked at in GHz will be confused as to how to numerically benchmark their computers seeing as computers will end up being put together like legos, with each brick being clocked individually in MHz.

Really, how exactly do you compare a Pentium 4 computer running at 3Ghz doing the exact same job as an ASIC or an FPGA clocked at 50MHz? Yeah, benchmarking and computer performance is weird like that... that's why we don't use numbers to benchmark, we use time, instruction count, and generally how long machines take to compute a specific task to grade their performance.

[Homestar4000]

add the atari jaguar plz

[Zolga]

why make this thread, its pretty obviously they wont run

[DanTheManMS]

why make this thread, its pretty obviously they wont run

Because to some people, it isn't obvious, and then they ask, and we have to keep saying "NO IT'S NOT POSSIBLE ALSJIFEALFJSLAEF"

So it's just easier to make a single stickied thread for it.

[kyrton]

wait, and the dsi?? doesnt have with its 133 cpu clock, cant emulate n64/ps1/gba??? so its need 7 times of power to emulate... so dsi cant emulate win98?? win98 requires 16ram and 100mhz~ (less then dsi)

[Eviltaco64]

wait, and the dsi?? doesnt have with its 133 cpu clock, cant emulate n64/ps1/gba??? so its need 7 times of power to emulate... so dsi cant emulate win98?? win98 requires 16ram and 100mhz~ (less then dsi)

I'm afraid that even the DSi lacks the power to emulate N64. :P

As for running Windows 98 on a DSi... In order to do so, you'd pretty much have to emulate a computer with an x86 processor and a generic sound/video card (which would be pretty demanding).

It'd be much easier to get a lightweight open source version of Linux and port it to the DSi.

[Rou]

n64 would be awesome though.

[Rockoman1000]

Mr_biggs!? As in Biggs?! As in the guide on onverse?! Is it really you? if it is, thats a HUGE coincidence. WOW. my onverse username is rockoman200. The only reason my username here is 'rockoman1000' is because i originally wanted rockoman100, bu i accidentally put another 0......T.T......