Homebrew n64 games on ds?

[AMPonzi]

A few comments:

First of all, my point about N64 game porting is that games like Mario 64 or Banjo Kazooie wouldn't be so difficult to port to DS because of their lack of extreme graphics. Majora's Mask and Ocarina of Time would be a bit more difficult I'd imagine. Though, with some craftiness it could be done... don't forget that Zelda only ran at 30FPS as opposed to Mario which is 60FPS.

Second of all, the PSP is only capped at 222MHz but most homebrew that needs it enables it to go to the true PSP speed of 333MHz.

And finally, N64's CPU is a cheaper model (MIPS R4300i) of the PSP CPU (MIPS R4000) so the instruction architecture is very very similar therefore emulating requires less power. This is sort of why I'm a little puzzled that Xbox hasn't been emulated yet since it uses an x86 architecture CPU much like nearly all PCs. Emulating on the same architecture is always much more efficient than emulating a different architecture. Because some instructions in one architecture could require multiple instructions on another.

 

[imgod22222]

I wished some ultra haxzor guys could invent an converter that converts the N64 Games into games runnable by the DS.

I think emulating the N64 is the wish we all have for our beloved DS, but which will never happen

BTW: WTF ? eight times more powerfull ? PSP runs those games Fullspeed with ONLY 222 Mhz... the DS has 99 if you count both Arm Processors...

Yeah, IF YOU COUNT BOTH! Emulation is not really a multi-threaded thing. Because one instruction may rely on another. If you talk to archeide (maker of SNEmulDS) he could give you the skinny on DS Emulation but I'm (fairly) sure that the only way that stuff is emulated using both is having sound emulated via ARM7 and video emulated via ARM9 and other various hardware support helping both, such as anything resembling a GPU on the DS. And that's one reason why with DS emulation, sound and video sync isn't always implemented.

And as a matter of fact, Oot and Majora's Mask are not near as graphically intensive. Why do I say this? Because Majora's mask needed the N64 Expansion Pak (extra RAM) to run. Oot did not.

Now if the process to doing this didn't matter there would be two feasible options: 1) Port the game (rewrite the whole damn game) or 2) Patch the game having x instructions translated to y instructions for the ARM processors, which is more-or-less the porting process automated.

Also, in what I've seen:
1) I think the N64 could support much higher res textures than the DS
2) I think the DS is much better at rasterizing 2D objects. (Such as instead of making a 32-poly sphere, it draws a 2D circle there instead, roughly shading to make it appear 3D) (I'm not sure if that's correct usage of the word rasterizing)
3) The N64 being a cheaper model of the PSP's CPU making emulation easier for PSP makes sense, due to SNES emulation on the GBA, because SNES and GBA shared alot of common hardware. (Or something along those lines)

ThaiGrocer, the rule is generally 10 or more times faster. Not sure if its not in wikipedia, if not it should be.

And IMO i think the reason the Phantom Hourglass looks the way it does is because big heads look better on a low res screen. A link that has human proportions would have a head about 3-12 pixels large.

O yeah, and there are a couple of XBOX emus. But they're all crappy. The reason why is because there's probably no reason really to. Most of the good XBOX games have PC ports already. The rest of the people have XBOXs because you can run linux on them, (quite effectively, for what I've read) and play backups. As a matter of fact, a regular XBOX doesn't look like such a bad idea ATM.

 

[Inu268]

the PSP emulates N64 at 333, and there is like, 4 playable games as it is now....

 

[iTech]

I wished some ultra haxzor guys could invent an converter that converts the N64 Games into games runnable by the DS.

I think emulating the N64 is the wish we all have for our beloved DS, but which will never happen

BTW: WTF ? eight times more powerfull ? PSP runs those games Fullspeed with ONLY 222 Mhz... the DS has 99 if you count both Arm Processors...

Yeah, IF YOU COUNT BOTH! Emulation is not really a multi-threaded thing. Because one instruction may rely on another. If you talk to archeide (maker of SNEmulDS) he could give you the skinny on DS Emulation but I'm (fairly) sure that the only way that stuff is emulated using both is having sound emulated via ARM7 and video emulated via ARM9 and other various hardware support helping both, such as anything resembling a GPU on the DS. And that's one reason why with DS emulation, sound and video sync isn't always implemented.

And as a matter of fact, Oot and Majora's Mask are not near as graphically intensive. Why do I say this? Because Majora's mask needed the N64 Expansion Pak (extra RAM) to run. Oot did not.

Now if the process to doing this didn't matter there would be two feasible options: 1) Port the game (rewrite the whole damn "game) or 2) Patch the game having x instructions translated to y instructions for the ARM processors, which is more-or-less the porting process automated.

Also, in what I've seen:
1) I think the N64 could support much higher res textures than the DS
2) I think the DS is much better at rasterizing 2D objects. (Such as instead of making a 32-poly sphere, it draws a 2D circle there instead, roughly shading to make it appear 3D) (I'm not sure if that's correct usage of the word rasterizing)
3) The N64 being a cheaper model of the PSP's CPU making emulation easier for PSP makes sense, due to SNES emulation on the GBA, because SNES and GBA shared alot of common hardware. (Or something along those lines)

ThaiGrocer, the rule is generally 10 or more times faster. Not sure if its not in wikipedia, if not it should be.

And IMO i think the reason the Phantom Hourglass looks the way it does is because big heads look better on a low res screen. A link that has human proportions would have a head about 3-12 pixels large.

O yeah, and there are a couple of XBOX emus. But they're all crappy. The reason why is because there's probably no reason really to. Most of the good XBOX games have PC ports already. The rest of the people have XBOXs because you can run linux on them, (quite effectively, for what I've read) and play backups. As a matter of fact, a regular XBOX doesn't look like such a bad idea ATM.

Sure, you could do that. It's pretty easy - just a one-to-one translation of opcodes. The only problem you will face is that of The Halting Problem but that just a very small thingy.

No wait, I lied.

Suppose the actual program file inside the ROM is 2 Megs. The entry point (the place in the program image where the N64 will start running the game - usually main()) is located about half-way into that program (both in the file, and once loaded in memory). The first half of the program contains uninitialised or initialised data (such as array, structures, etc.) and the rest contains opcodes. Each opcode is 64-bits wide (that's 8 bytes). Since the CPU is 64-bit, basic integer values are 64-bits wide (and since the N64 uses a MIPS processor the CPU can't access anything smaller - "bytes" can not be stored seperately but must be aligned and padded into 8-byte integers). Data is stored exactly the same as an instruction (opcode). Each opcode van be used as data and all data can be used as an opcode.
You want to start doing a naïve translation of opcodes from MIPS to ARM.
My question to you is;
where do you start?

At the first byte in the program? (Offset 0)
But that contains data, the program doesn't start until about half-way into the file. You would be translating data values to ARM instructions!

At the entry point?
Sure you can do that, but you will only be able to translate until you come across the first dynamic jump or branch.
Suppose the entry point code (main()) calls a function called "init()" and uses its result to determine wether to coninue or to abort with a "init failed OMG!" message by calling some function called "abort()". How do you know which the next instruction to translate is? The one that is executed when initialization was successful or the one that is executed when initialization failed (= the first instruction in abort())? You can't know because you'd have to solve the Halting Problem by predicting wether or not the condition will be true which you can't do unless you executed all the instructions normally up to that point. And you can't just simply skip the branch test and go and translate both paths because branches are Program Counter-relative. That means that the number of the current instruction being executed (for example: a PC of '10' could mean the tenth instruction in the program) is added to an offset of to get the branch target address, you'd have to keep track of two different PCs up to this point one for each given path (and each path can take any number of other paths, all which must have their PC tracked).
This might all still not be impossible but just hard to do, but when a program jumps to a dynamic location, no translator can continue with the translation. Suppose I tell the processor to go to address "contents_of_some_register + 1" - the translator will not know what the contents of the register will be, and the contents of the register is added to a number to form the address of the next instruction to translate. The program must have being executed normally up to that point in order for the value of that register to be known.

"Dynamic" recompilation (DynaRec) however *can* and *does* translate the instructions to native instructions. (A DynaRec is just a dynamic version your translator). The "Dynamic" part is key and reveals why it is possible for it to translate to native instructions while a static translator can't. What the DynaRec does is twofold; execute an instruction, and store a translated version of it into a (fixed-size) cache. Then, the next time that given section of code in the program is executed, it simply jumps natively to the start of the cache and thus has the CPU execute the block of translated instructions. When the cache is full, it is cleared and filled again. The bigger the cache, the faster program execution will be since more translated instructions will be in it (so always set a high "dynarec memory" value for emulators) Since a DynaRec executes each instruction up to the point of a dynamic branch or jump, it *does* know what the next instruction to execute (or load into the cache) is.


And on the topic of N64 emulation on the DS? Forget about it. It is possible using the DS Browser's RAM expansion pack, but I wouldn't count on it being very fast. Off course, emulating any turing-complete system on any other that has enough memory to hold all registers is likely to be possible (you could emulate a PS3 on an 386 if you wanted to. Hell, you could emulate it using just a piece of paper and a pencil by executing the opcodes yourself) but it wouldn't be very nice.
The biggest problem will be ROM caching (you simply cant with the DS' tiny memory - even the memory expansion adds only 10 megs of high-latency memory and most is needed for the DynaRec)
I might look into it however once I have implemented a working portable MIPS DynaRec (yes, portable) for embedded systems for a project I'm working on... But I doubt it's worth the trouble.

 

[pasc]

@Inu268:

LIE ! The originial PSP Emulator Daedusaöfahöfhdl WTF it was called.... could run Roms with 222 MHz only, and for me that proves that those 222 MHz reached: Youtube - PSP N64 Emulation

 

[iTech]

As someone already stated, the PSP uses virtually the same processor as the N64. Doing the same on an ARM processor will be harder and requires a programmer with intricate knowledge of both platforms.

 

[Hadrian]

I wished some ultra haxzor guys could invent an converter that converts the N64 Games into games runnable by the DS.

I think emulating the N64 is the wish we all have for our beloved DS, but which will never happen

BTW: WTF ? eight times more powerfull ? PSP runs those games Fullspeed with ONLY 222 Mhz... the DS has 99 if you count both Arm Processors...

I'd rather have an Amiga emulator working.

 

[chuckstudios]

@Inu268:

LIE ! The originial PSP Emulator Daedusaöfahöfhdl WTF it was called.... could run Roms with 222 MHz only, and for me that proves that those 222 MHz reached: Youtube - PSP N64 Emulation

You shouldn't Rickroll if you can barely speak English >.>

 

[mellowman]

Well I have no idea if it's real or not (it hasn't been released.) but look at dsin64 on youtube it runs like 10 fps, only supports super mario 64 and has no sound. yippe

 

[iTech]

Well I have no idea if it's real or not (it hasn't been released.) but look at dsin64 on youtube it runs like 10 fps, only supports super mario 64 and has no sound. yippe

http://www.youtube.com/watch?v=T-DUawYUtXo
http://www.youtube.com/watch?v=9TmDjjewVj8...related&search=
^^ That shit is a fake.

He's clearly opening a .dpg video file in Moonshell.

I love it when haters are creating this fake shit, because when the real hardcore coder releases something everyone else thought couldn't be done and was faked on youtube a dozen times in the past, the chaos and hilarity that ensues is classic.

Watch this thread carefully the following week.

 

[.TakaM]

ill be buying oot and MM if it comes out for the ds...

i miss those games

perhaps nintendo should port it to the rock you're living under.
OOT and MM are playable on every console since the N64, and I'll bet money they're going to make sure (at least for oot) that it stays that way.

all the milking nintendo is doing to oot is just destroying the memories I have of it, I really do not want it to come out on DS

 

[Hadrian]

People seem to forget that the DS wasn't created to play the 3D Zelda games. They just won't play as well with the D-pad. They don't even play as well with the GC controllers, OoT is for the N64 controller and thats that! Just play the games on the N64 like it was intended, you can get a cheap N64 for a tenner and copies of both Zeldas for about the same.

 

[suppachipmunk]

I agree that the Zelda Games for the N64 were the best on the N64 due to the controller setup. Playing those games on the cube was fun, but not as fun as the central analog from the N64. If the two Zelda games were ported to the DS, I am sure that everyone would pick up a copy, to include those that own the game for every system and those that have never played it.

The fact that the games would be portable would be the ultimate selling point. Look at the Final Fantasy series on the GBA. Those games were made for the SNES, then PSOne, GBA, now PSP. And they still charge $30 for Final Fantasy 1 on teh PSP, when you can buy FF 1&2 for the GBA for $15 brand new or on PSOne for $15. Another example is the Nintendo Classic Series. They charged $20-30 for those games. The old Zelda and Metroid, Mario, etc. ported onto the GBA. Those games are the easiest to emulate, yet people still bought them to play on the DS.

Everyone has played Zelda OoT, but never portable. I think that with a $20-30 price tag, everyone would pick up a port of the Zelda games on DS. Or any other N64 port for that matter.

With the Wii, Zelda is $10, and it is not even a physical copy of the game. VC is a bit pricey for most games if you ask me.

 

[rhyguy]

I think it would be nice to see Zelda Ot ported to the ds, as i loved the storey line and the game play, and i'd like to play it anywhere i go

as for the issue with the d-pad, couldnt they make it like the smario port and control with the stylus?

 

[ubersk8kid]

I think it would be cool if Nintendo made some kind of N64 Emulator commercially. The emulator part would go in Slot-1, and you would buy the N64 games seperately. The Games would be for Slot-2, and it would come with like a MEGA HUGELY BIG RAM Expansion as well as the game on the slot-2 cart. So it would work like NDS-GBA Linkage. Maybe they could up the performance some other way also, like putting more stuff on the Slot-1 card. Of course they would price it at maybe normal NDS game prices or lower, since they would be older games, but maybe they would up the price for marketing reasons, which would be the smarter choice for Nintendo to make. Although this most likely wont happen, but a COOL idea anyway!

 

[Mangofett]

I think it would be cool if Nintendo made some kind of N64 Emulator commercially. The emulator part would go in Slot-1, and you would buy the N64 games seperately. The Games would be for Slot-2, and it would come with like a MEGA HUGELY BIG RAM Expansion as well as the game on the slot-2 cart. So it would work like NDS-GBA Linkage. Maybe they could up the performance some other way also, like putting more stuff on the Slot-1 card. Of course they would price it at maybe normal NDS game prices or lower, since they would be older games, but maybe they would up the price for marketing reasons, which would be the smarter choice for Nintendo to make. Although this most likely wont happen, but a COOL idea anyway!

Well, here are the things that the DS doesn't have enough of to emulate the N64

-proccessr
-ram
-video ram
-a big enough screen
-buttons

o hey lets make an expansion the size of the original gameboy that costs 300$

 

[becker2384]

I think that the lack of buttons would have a large affect on gaming.

 

[Nintendo Maniac]

Now, I know people are saying an N64 emulator is IMPOSSIBLE, but is it PHYSICALLY impossible, including with the extra RAM some devices have? I think it would still be hilarious to have an N64 emulator on the DS running at like 0.1 fps XD

 

[leetdude_007]

You can emulate N64 on the DS, but it will verrrrrrrrrrrrrrry slow. It has to be ported to the DS... Maybe Nintendo has a converter, but that would never see the light of day.

Hardware is different. An emulator is an emulator. It emulates the N64 hardware. Besides, the 3D graphics on the N64 are a lot better than NDS.

 

[ubersk8kid]

I think that the lack of buttons would have a large affect on gaming.

Well you could use the "X" or "Y" button for "Z" and the "C" buttons and "D Pad" would be on the touch screen. But then you still have the small screen issue still.