Can We Get A N64 Emulator At All?

[PokeParadox]

Heeeeeeeeeere's Johnny!

Well I can't see it happening and being fast enough. It would be nice... but I can't see it happening tbh. We do have OGL ES for the GP2X but it ain't going to be able to render 3D and process a shitload of CPU emulation.

 

[Gruntfuggly]

OK, you can lock it now...

 

[DaveC]

I am suprised there is even a debate here. This thread should have been 2 posts. "can you emulate an N64?" "No you idiot, of course not" End of thread. You might as well be debating as to whether you can emulate an Xbox 360 on the GP2X, it is ridiculous :rolleyes:

 

[Squidge]

I think people are getting confused here and arguing over slightly different things...

LordJohnnie: Right, so your saying that instead of emulating the N64 hardware, we should instead port the code of the rom to run on the GP2X with some kind of abstraction layer?

That would mean that each and every N64 game would have to be ported seperately, yes?

To get each game working correctly, it would be so damn near emulation of the hardware that you might as well emulate the hardware in the first place.

Remember that the game is expecting to be able to talk to the N64 hardware directly, so unless you emulate this hardware exactly as it being expected, the game isn't going to run correctly.

Now, contrast this to how most Commercial PSP games are built. All games use functions provided in the PSP's kernel and in the SDK. Nothing talks to the hardware directly (Some homebrew games and emu's talk to the hardware directly, but lets ignore those for now). This means that instead of emulating the PSP's hardware, we can instead watch for the calls to the kernel and simulate what those calls would normally do. No need for any hardware emulation past the point of having the same memory map (so RAM for example is in the expected place). This would indeed be much faster than hardware emulation.

But that's not going to work on the N64 where most games attack the hardware directly, and most SDK calls are actually built into the final games rather than being in an OS kernel.

 

[LordJohnnie]

wow... okay, no, not an abstraction layer, but simply rewriting the code of a rom so that an authentic yet simplified version or port of the game could run natively on the GP2X.

For example, instead of the rom's code attacking N64 hardware, it attacks the GP2X's hardware, or that of a standardized engine written for the GP2X. What is the real challenge for emulating the N64 other than simulating hardware or making the rom think its being run on N64 hardware? Cut that out of the loop and virtualize the user experience.

Let's instead translate the code of a Rom so that a virtualized, simplified, mock-up of the original can be run on the GP2X natively.

 

[garteth]

That would be a port wouldn't it?

 

[DijiTao]

Perhaps it is the word "emulation" that is the killer of this thread and gives fuel to screamers of the word "NO."

Right the GP2X is incapable of running a N64 emulator, glad to see you coming around on that point.

You all seem to be experts as to what the GP2X cannot do, but do any of you actually know what the GP2X can do?

Right again, there seem to be quite a few of us "experts" around here that have a pretty good handle on what the GP2X cannot do. As far as an expert of what the GP2X can do Squidge comes to mind, and his opinion seems to agree with the consensus of “NO”.

An early reply here in this thread responded to my notion that we can "clone" an N64 game, and his regurgitated response was a mumbling about the availablity of "source code" to allow for "porting" of a game.

Right again - I'm so glad we can agree... Yes we can make remakes, and clones of N64 games, and if you have an army of source code stealing ninja ready to break into whatever vault Nintendo keeps it’s source code in, well then you might even could do a port.

Emulated hardware works directly with the "source" of a rom and emulation developers reverse engineer both. Whats more available than that?

Awww shucks, and you were doing so good, but now you've gone off and said that. Please go read those Wikipedia links I gave you earlier and I’ve even got a couple more for you:
http://en.wikipedia.org/wiki/Source_code
http://en.wikipedia.org/wiki/Object_code

Roms are Object Code, not Source Code. Now you might be thinking what about Decompiling the Object Code (roms) to produce Source Code which could then be compiled back into native gp2x object code? We’ll it’s just not that easy. First of all even if a perfect decompiler existed for N64 object files there would still be all the work of porting, which would be quite complex given the differences in hardware. It would be as difficult as porting Tux Racer to the GP2X. Now the “IF” on the existence of a perfect decompiler is a massive, gigantic, unbelievably large, GYNORMOUS, leap because the creation of such a decomplier while not tynically impossible is enormously difficult. For more information on how decompliation works, I’ve got a whole new wiki for you:

http://www.program-transformation.org/Tran...m/DeCompilation

To give you an idea of just how hard decompiling is, it’s often be referred to as “Making Pigs from Sausage”, which is to say once you’ve turned a pig (source code) into sausage (object code) it’s damn near impossible to get the pig (source code) back.

there is a link between the concept of dynamic recompilation and that of "cloning" or "porting" a game/engine/software.

That statement shows your fundamental lack of understanding of the problem, here are some quick definitions, but really go read the Wikipedia articles already:
Cloning is recreating the game from sratch
Porting is taking the source code and modifying it to deal with new hardware
Dynamic Recompilation is an assembly level process of converting the instructions of one cpu to another and in the process using more efficient instructions if they are available

The three are totally different

I actually feel bad for the monkies that bang thier head against the wall over this, wearing T-shirts that say "N64 emulation = impossible." So, I'm going to point out that if the definition of "emulation" is the full and complete simulation of videogame/console hardware, then no, of course the GP2X cannot "emulate" the N64.

The definition of emulation isn't up for debate, and your just dead wrong on your understanding of what the word means in a computer science context.

However, if the definition of "emulation" is infact "the practical and satisfactory virtualization of a videogame/console" then the answer is Yes, the GP2X can emulate N64 games.

I don’t know how many times I'm going to have to tell you this, but the word emulation already has a meaning, and you’re not allowed to just make up a new one. You can remake/clone N64 games for the GP2X, but not emulate them. Remaking/Cloneing, to the point of being indistinguishable from the original, the entire software library of the N64 would literally require hundreds of thousands of man hours. If you narrowed it down and just stated a goal of remaking Mario64 for the GP2X it would still be extremely difficult as it took Nintendo over 2 years, with a very large staff and a very large budget to make this game. AND IF you somehow, completely recreated Mario64 for the GP2X to such a degree that it was completely indistinguishable from the original Mario64 for the N64, you will have committed quite a few trademark and copyright infringements, and Nintendo would sue you into poverty.

 

[DijiTao]

wow... okay, no, not an abstraction layer, but simply rewriting the code of a rom so that an authentic yet simplified version or port of the game could run natively on the GP2X. For example, instead of the rom's code attacking N64 hardware, it attacks the GP2X's hardware, or that of a standardized engine written for the GP2X.

Squidge already explained in depth why even IF you could get the source code (which you can't) why it would still be extremely difficult to rework the code to have it run on natively on the GP2X given that the N64 code would be directly access the N64’s hardware instead of going through a kernel. Go re-read his post, and hopefully you'll get it this time.

What is the real challenge for emulating the N64 other than simulating hardware or making the rom think its being run on N64 hardware? Cut that out of the loop and virtualize the user experience.

Virtualize the user experience -- you really love that phase don't you, to bad you seem to have no idea just how hard that is. Hundreds of thousands of man hours...

Let's instead translate the code of a Rom so that a virtualized, simplified, mock-up of the original can be run on the GP2X natively.

Pretty please, don’t post again until you have a clue.

 

[Ravnos]

Diji, it's safe to just ignore this guy. It's obvious at this point that he's just an idiot troll.

 

[sand_man]

This is the dumbest thread ever,

 

[DijiTao]

This is the dumbest thread ever

I hardly think my side of the argument is dumb, maybe a waste of keystrokes but hardly dumb. I’m just trying to intelligently debate the point despite the fact that the opposing point of view is fairly ridiculous. Ridiculous on a scale of a child arguing with a Meteorologist that thunder is “god bowling”…

 

[Squidge]

wow... okay, no, not an abstraction layer, but simply rewriting the code of a rom so that an authentic yet simplified version or port of the game could run natively on the GP2X.

For example, instead of the rom's code attacking N64 hardware, it attacks the GP2X's hardware, or that of a standardized engine written for the GP2X. What is the real challenge for emulating the N64 other than simulating hardware or making the rom think its being run on N64 hardware? Cut that out of the loop and virtualize the user experience.

Let's instead translate the code of a Rom so that a virtualized, simplified, mock-up of the original can be run on the GP2X natively.

​

Ok, let say your doing a static recompilation of a N64 rom, and even converting all the calls to the graphics hardware to calls of an equivalent nature on the GP2X.

First problem - how do you identify calls to the N64 graphics co-processor during the static recompilation phase? The original code could retrieve an address from an address in RAM, and write a value in that address (for example, it's cycling through setting up the palette registers). How do you know that address points to the graphics co-processor without executing all the code upto that point so you know the value of that RAM location? The answer is of course that you don't, so that means you'll have to do each and every one by hand (possible, but would take well over a year in most cases), or you need to check the address every time something like this happens, which means we are back to emulation of the hardware...

 

[trooper]

An intelligent debate is good in my opinion, But intelligence has to come from both side for it to be health.

This thread is going in the same direction as a one wooden legged person with said leg nailed to the floor.

LOCKED

Trooper