what would you guys think of a n64 emu for the ngc

[AlphaWolf]

Ethernet should be plenty fast enough. The only reason that the disc is too slow is not the thruput, but because the seek latency is too high. The memory would have to be page-mapped, and there would have to be a remote service running on a pc to serve pages of n64 rom to the gc, which is no small amount of work for something of a challenging novelty.

EDIT : There should be a poll selection for "Yes it can be done, but it sounds a bit too psychotic for me."

Well, the bandwidth needed for an n64 cartridge is somewhere in the 500 meg per second range, the ethernet will only give you 100mbits, the disc I am not sure exactly how much, but I am fairly certain it's nowhere near that (it would have to be far more than 50x dvd read speed for that).

It would definitely work with 64mbit roms, namely mario, but 128mbit roms would be tricky, and 256mbit roms (e.g. zelda) would be pretty much impossible. Basically your game selection on an n64 emulator on a GC would be extremely limited, unless you wanted to play at like 2 seconds per frame

 

[Azimer]

You guys are not talking about the same things. Scully is noting a method to attach a datafile to the gamecube .dol file and alphawolf is talking about emulating that data on the GC. k thx

 

[AlphaWolf]

You guys are not talking about the same things. Scully is noting a method to attach a datafile to the gamecube .dol file and alphawolf is talking about emulating that data on the GC. k thx

Well, all things considered, if you realy want to emulate an n64 on another console (as opposed to a PC), the xbox is currently your only real option

 

[dcook32p]

Joke of the Day

Well, all things considered, if you realy want to emulate an n64 on another console (as opposed to a PC), the xbox is currently your only real option

Why is it that my mind keeps comparing this thread to... oh... say, emulating an Xbox on a Pocket PC?

 

[Tagrineth]

It can be done... in theory.

Guys. GC has more RAM than you're accounting for. It has 24MB main RAM plus 16MB A-RAM. If you used a smart enough page/flag system you could easily keep up to 32MB ROMs resident, provided no Expansion Pak was needed (8MB RAM left - 4MB for N64 native RAM and 4MB for emulating should be enough, given enough optimisation to keep things packed).

I'm actually fairly sure that the Zelda Bonus Disc uses this method to run OoT and MQ, but probably with some very intelligent paging scheme. Why else would it:

• Look *identical* to the N64 version in every single physically possible way, with the sole exceptions of resolution/Anti-aliasing, and replaced icons for buttons
• Have the exact same frame rate issues the N64 version have, in almost exactly the same places - if it was rebuilt, it would by all rights be able to sustain 59.96FPS with ease
• Undergo a ridiculously long load right at the start, but never load again while the game is playing
• Ask if you want to use Rumble immediately (IS THE RUMBLE PAK PLUGGED IN? - N64 games don't like this changing while the game is running)
• Have no bug fixes whatsoever from the N64 original
• And here's the real kicker: Loading the pause menu takes even LONGER than the N64 version, more along the lines of what PC EMULATORS used to need, and the game pops back down to 320x240 at 8-bit colour for the subscreen - WHY would it need to do that if it was recoded?

Basically though, all you could realistically pull off is a high-quality implementation of UltraHLE - extremely good and compatible with a handful of games, but anything that went remotely low-level would start having problems.

[/end rant]

 

[pj64er]

To add to tag's points, why else would there be a MQ rom (dated 2003 and refers to the 'L' button for z-targeting) floating round the net that can run perfectly fine on any N64 emulator?

 

[AlphaWolf]

I'm actually fairly sure that the Zelda Bonus Disc uses this method to run OoT and MQ, but probably with some very intelligent paging scheme. Why else would it:

Its fairly likely that they merely rewrote the core of the game engine to not depend on random access. The bugs you mentioned were probably kept for nostalgia sake, and the start menu slowness could be something on the API level that wasn't worked out smoothly (even directly recompiling software from one platform to another doesn't necessarily guarentee that things like this wont happen).

I think it would be too cost prohibitive for them to write an emulator for that game, porting the code would probably be much cheaper (unless they stole some GPL'ed emulators code? *shrug*)

 

[Tagrineth]

Its fairly likely that they merely rewrote the core of the game engine to not depend on random access. The bugs you mentioned were probably kept for nostalgia sake, and the start menu slowness could be something on the API level that wasn't worked out smoothly (even directly recompiling software from one platform to another doesn't necessarily guarentee that things like this wont happen).

I think it would be too cost prohibitive for them to write an emulator for that game, porting the code would probably be much cheaper (unless they stole some GPL'ed emulators code? *shrug*)

But that doesn't account for any of these...

• Have the exact same frame rate issues the N64 version have, in almost exactly the same places - if it was rebuilt, it would by all rights be able to sustain 59.96FPS with ease
• Undergo a ridiculously long load right at the start, but never load again while the game is playing
• Have no bug fixes whatsoever from the N64 original

 

[sytaylor]

it does.. he said

bugs you mentioned were probably kept for nostalgia sake

 

[AlphaWolf]

But that doesn't account for any of these...

• Have the exact same frame rate issues the N64 version have, in almost exactly the same places - if it was rebuilt, it would by all rights be able to sustain 59.96FPS with ease
• Undergo a ridiculously long load right at the start, but never load again while the game is playing
• Have no bug fixes whatsoever from the N64 original

Again, the first two could be caused by issues with porting to another API - they probably didn't iron things out too well. For all intents an purposes, an emulator could fix these problems if the author wanted to.

And so far as the bugs, the developers could have wanted the game to be as true to the original as possible, so they intentionaly left the bugs intact.

 

[Tagrineth]

wrt bugs, if that's the case why do more or less all other remakes have the bugs fixed? One example of that would be Final Fantasy VI for PS1 - definitely a shoddy port, but they fixed many of the worst bugs, for example the famous problems with the Phoenix Cave.

And Nintendo themselves even fixed one particular bug in OoT N64 - the initial production run had a bug where if you threw a Deku Nut in Queen Gohma's chamber before she saw you, the game would lock up no matter what (not sure exactly when, but it's a famous bug)... my N64 cartridge, a later version, doesn't have the problem, but a good friend of mine with the gold cartridge confirmed that he bumped into the lockup the first time he played that scene.

So much for keeping them for nostalgia.

And then there's the aforementioned load. What other reason could it POSSIBLY have for existing?! How would it be feasible to load EVERYTHING at startup and nothing else EVER AGAIN?

Edit: Look, I'll just say one more thing on this, because all my points are pretty much clear already...

AlphaWolf, I understand where you're coming from and what you're saying, and it does make sense... for each point individually. But consider the sheer amount of evidence. I could accept if only one or two of the chunks of evidence existed - MAYBE 3 - and consider it a poor remake, but with so much evidence pointing toward emulation... I just don't see how a remake could show that many obvious markers.

 

[nephalim]

I didn't do any of this first hand, so this is second hand info, but I have heard that the GCN doesn't really load the WHOLE game into memory when playing OoT/MQ, it requests the disc/stalls at certain rare points. Try playing the game with the top open and see what happens if you're interested...i'll ask on the GameFAQs OoT GCN board about this i'm sure i'll get the proper info.

In any case, if OoT/MQ IS emulated, it's a very specially designed emulator for one specific ROM, and I don't think it's success (from disc, which is impossible for homebrew,) can be directly related to an emu designed to play all games.

 

[AlphaWolf]

AlphaWolf, I understand where you're coming from and what you're saying, and it does make sense... for each point individually. But consider the sheer amount of evidence. I could accept if only one or two of the chunks of evidence existed - MAYBE 3 - and consider it a poor remake, but with so much evidence pointing toward emulation... I just don't see how a remake could show that many obvious markers.

Well, heres the main thing: cost (note, time is also money). It would cost them a hell of a lot more to write an emulator than it would cost to do a general port. I just don't see why they would go through all of that.

 

[Tagrineth]

Well, heres the main thing: cost (note, time is also money). It would cost them a hell of a lot more to write an emulator than it would cost to do a general port. I just don't see why they would go through all of that.

You don't know that for sure. If they have all the techincal info necessary (and they obviously do), then creating an emulator could actually be easier than porting, depending on how the original was programmed in the first place. Especially considering, as nephalim points out, that it's probably a special emulator specifically designed for OoT/MQ.

And nephalim: I can't run it with the tray open. It asks me to close it again XD

 

[AlphaWolf]

You don't know that for sure. If they have all the techincal info necessary (and they obviously do), then creating an emulator could actually be easier than porting, depending on how the original was programmed in the first place. Especially considering, as nephalim points out, that it's probably a special emulator specifically designed for OoT/MQ.

Well, with porting, all they have to do is translate some API calls and recompile, whereas with emulating, they have to do a lot more, like remap memory, write a translation engine for each hardware component, re-interpret API calls, etc.

 

[Tagrineth]

Well, with porting, all they have to do is translate some API calls and recompile, whereas with emulating, they have to do a lot more, like remap memory, write a translation engine for each hardware component, re-interpret API calls, etc.

Like I said, it depends on how the game was originally programmed.

Zelda on N64 apparently used a lot of standard libs, judging by how well the initial relase of UltraHLE ran it with few to no patches...

It wouldn't be hard to do similar if you even know what the problem spots will be with that approach. I mean, seriously. All they needed was a C interpreter and pre-prepared functions to replace the ones executed by the game... and N themselves would know immediately where the game used specific code (like, in Ganon's Tower, with that one gate that won't open in UHLE no matter what you do unless you cheat the game) and could probably replace those with ease again.

I'm not talking about low level emulation of the hardware, hun... I'm talking about this emulator is to Zelda what Xeon is to HALO.

 

[aprentice]

i'm almost definately sure its emulated, why else would there be a n64 rom on a gc disk? And if it was a port, nintendo wouldnt be giving it away for free, they wouldve done something like they do with gba games, porting snes over.

edit: couldnt help not replying to this old thread

 

[Tagrineth]

By the way: PWN3D. I was gonna dig this up myself right about now.

There's new evidence that supports the emulation theory: The fact that one can use the exploit to use the OoT bonus disc to run... quite a few different N64 ROMs. :flowers:

 

[AlphaWolf]

Well, guess I was wrong

I still can't figure out why on earth they would choose to emulate it instead of port it though.

 

[Davemc]

You can tell it's emulated.
The long pause waiting for the sub-screen menu to come up after you press start gives it away.