Homebrew Others I have a question on creating my own N64 to 3DS

[Walegy0569]

Okay, I need a favor of some people who know how to make .n64 to .elf formats. The reason why is because I'm trying to port Banjo-Kazooie to the 3DS. I've been trying to learn how to set up .elf to .cia. So, to any creators out there I can honestly use the help and here are the scripts I've been using to make sure this works. Can someone point for me towards the right direction because, I honestly want to make this happen!

(THESE AREN'T MINE FYI & IN THE BOTTOM I'VE BEEN USING THE CURRENT PROMPT.)

1. #!/usr/bin/bash
   		# Get entry point from N64 ROM
   		dd if=test.z64 bs=1 skip=8 count=4 of=entrypoint >& /dev/null
   		# Convert entrypoint to little endian
   		#mips-elf-objcopy -I binary -O binary --reverse-bytes=4 entrypoint entrypoint
   		# Construct an ELF
   		mips-elf-objcopy -I binary test.z64 -O elf32-bigmips -B mips --adjust-section-vma .data+0x80000000 foo.elf
   		# Patch to MIPS III
   		printf '\x20\x00\x00\x00' | dd bs=1 seek=36 count=4 conv=notrunc of=foo.elf >& /dev/null
   		# Set entrypoint
   		dd if=entrypoint bs=1 seek=24 count=4 conv=notrunc of=foo.elf >& /dev/null
   		rm entrypoint
   		# Dump the headers
   		mips-elf-objdump -x foo.elf

(I've been using Windows Powershell, but if anybody has any suggestions, please comment them down.)​

 

[Winduss]

What do you mean by porting Banjo Kazooie to the 3ds? Are you just making a .cia forwarder for a n64 emulator?

 

[godreborn]

iirc, cia are done through makerom. you need to get the bnr and icon, which you can do so with pngs and bannertool. you also need a wav for the bnr.

 

[Walegy0569]

What do you mean by porting Banjo Kazooie to the 3ds? Are you just making a .cia forwarder for a n64 emulator?

I mean by importing the .z64 ROM to .elf and then .elf to .cia

 

[godreborn]

I mean by importing the .z64 ROM to .elf and then .elf to .cia

can't without the source code or reverse engineering it. what I said about elf to cia is correct.

 

[Walegy0569]

iirc, cia are done through makerom. you need to get the bnr and icon, which you can do so with pngs and bannertool. you also need a wav for the bnr.

I know that, but I'm more of converting .z64 to .elf I just need help with knowing if this script can be modified to ensure it could happen

Post automatically merged: Nov 17, 2022

can't without the source code or reverse engineering it. what I said about elf to cia is correct.

Also, I may as well try getting the source code for Banjo Kazooie through some Romhacking tools.

 

[godreborn]

jesus, man, you can't just make an elf from a z64. it's not that easy.

 

[Walegy0569]

jesus, man, you can't just make an elf from a z64. it's not that easy.

What do you mean? Have you seen the script that I'm using for it? Besides, I just need the correct commands, so I can convert it .elf. Then, I can go and create a .cia by tampering with code.

Post automatically merged: Nov 17, 2022

What do you mean? Have you seen the script that I'm using for it? Besides, I just need the correct commands, so I can convert it .elf. Then, I can go and create a .cia by tampering with code.

 

[godreborn]

What do you mean? Have you seen the script that I'm using for it? Besides, I just need the correct commands, so I can convert it .elf. Then, I can go and create a .cia by tampering with code.

maybe if you grew a few intelligent points, you could do it. say hello to my ignore list. I can't waste my time on the stupid. sorry.

 

[Walegy0569]

maybe if you grew a few intelligent points, you could do it. say hello to my ignore list. I can't waste my time on the stupid. sorry

This stupid, sorry**

 

[Winduss]

What do you mean? Have you seen the script that I'm using for it? Besides, I just need the correct commands, so I can convert it .elf. Then, I can go and create a .cia by tampering with code.

Post automatically merged: Nov 17, 2022

So you don't know anything about programming or how the n64 is different from the 3ds?? It isn't a matter of changing the file type so it'll magically run on the 3ds.
Otherwise we would've had every n64 game running natively on the 3ds years ago already.

Or maybe I'm understanding it wrong and you're not a case study of the Dunning-Kruger effect

 

[Kwyjor]

Okay, I need a favor of some people who know how to make .n64 to .elf formats. The reason why is because I'm trying to port Banjo-Kazooie to the 3DS. I've been trying to learn how to set up .elf to .cia.

Has it ever occurred to you to look up exactly what "elf" means?
https://en.wikipedia.org/wiki/Executable_and_Linkable_Format

All kinds of different platforms can use files named ".elf", but that does not mean that you can magically use a .elf file from one platform on an entirely different platform.

Like @Winduss said: if getting an N64 game running on a 3DS was as easy as mashing a bunch of scripts together, do you seriously think you would be the first person to ever do this? Don't you think there would be someone else out there maybe just a little smarter than you who could figure that out without making a forum post?

 

[RyanxGwG]

This stupid, sorry**

With some easy searching youd know banjo kazooie is one of the games that runs fine on the 3ds homebrew n64 emulator, DaedalusX64

 

[Deleted member 607440]

One can't really convert binaries between architectures that easily. Even if you did, the problem becomes that the n64 binary expects n64 hardware, not only controller inputs but memory addresses, that the 3ds won't have. If you managed to convert it, you will basically need to write an emulator around it to get the 3ds to run it. Take for example the ocarina of time port to pc. It wasn't as simple as throwing an n64 rom into a few commands, they had to deconstruct it into source code, then they had to modify the source code to work in a way a pc would expect.

So if you want a true port to 3DS, your first step is to start decompiling it. That's going to take a ton of time, it took the ocarina of time people, which was a team, over a year. Probably someone in the zelda64dev or mario 64 community could give you some pointers. After that you're going to need to rewrite core functions to work on the 3DS, 3dbrew could help.

If your persistent you can do it. I however would give up and instead just run the n64 rom in an emulator.

 

[Walegy0569]

So you don't know anything about programming or how the n64 is different from the 3ds?? It isn't a matter of changing the file type so it'll magically run on the 3ds.
Otherwise we would've had every n64 game running natively on the 3ds years ago already.

Or maybe I'm understanding it wrong and you're not a case study of the Dunning-Kruger effect

Well, I'm am experienced coder when it comes to Python. Maybe I should perhaps ask, Gericom to perhaps give me info on which programs he used to encode the SM64 3DS port?

Post automatically merged: Nov 20, 2022

Well, I'm am experienced coder when it comes to Python. Maybe I should perhaps ask, Gericom to perhaps give me info on which programs he used to encode the SM64 3DS port?

Also, I did a bit more research and turns out" there's a Decomp of this on Github whcih is not quite finished, but its extremely clise.

Post automatically merged: Nov 20, 2022

Well, I'm am experienced coder when it comes to Python. Maybe I should perhaps ask, Gericom to perhaps give me info on which programs he used to encode the SM64 3DS port?

Post automatically merged: Nov 20, 2022

Also, I did a bit more research and turns out" there's a Decomp of this on Github whcih is not quite finished, but its extremely clise.

Also, sorry for the bad spelling. I'm busy making an N64 ROMHack lol. I just wish I had someone to help me with character models.

 

[Urbanshadow]

I´ll bite the bullet and do some write up on this just so users reading this willing to learn can get something out of value from all this. I'll apologize beforehand for any mistakes in the post as it has been quite a chunk of time since I messed with any of this stuff.

First of all he/she is not completely in the wrong... it should be possible to read all code in the ROM of an n64 cartridge or extract the ROM part of a z64 file and then:

1. Detect all code subroutines
2. Find all loose machine code and try to organize it in sections without breaking the code
3. Find a suitable entrypoint
4. Build the elf manually as per standard

And you would have a N64 elf file to load... if the N64 had a elf loader in the first place to load the software. Obviously an elf file with NEC VR4300 code would never run natively on the 3DS's ARM and I don´t remember in this point in time if the libretro N64 cores for 3DS support dynarec so I will not go futher in that direction. And even if the N64 had an elf loader capable of loading this hypothetical file, it could even get loaded and start executing but it will crash a bunch of instructions in.

The thing is... the N64 games are a specific pain in the ass to work with because the N64 is not meant to run without a cartridge as the hardware is incomplete in itself. A regular N64 cartridge is much more than just the software as it does not only serve game software to the system but completes and extends the system capabilities. Allows the system to actually work just like the jumper/expansion pak does. One could say the N64 is a fundamentally different machine depending on which cartridge is in and believe me on this, some specific cartridges are an astonishing piece of hardware architectural design...

Due to this inherited design from NES and SNES, each N64 cartridge has specific hardware built-in with quirks and normally (but not at all always... see pokemon snap!) that hardware triggers using developer assigned addresses so what those addresses actually do changes from game to game. There were not a lot of these addresses available so in many cartridges developers had creative ways to communicate with the hardware such as but not all:

• calling the memory controller to read restricted memory areas in the ROM. each address in the read attempt meant undocumented stuff to do in the cartridge, most of the time asynchronously
• calling the memory controller to write on rom addresses. each value in the write attempt to a specific address meant undocumented stuff to do in the cartridge, most of the time asynchronously
• calling the end of the frame (entering VBLANK). Many cartridges have completely async hardware wating to read the end of the frame sent to the N64 to do undocumented stuff
• Some or all of the above together
• And more!

Most this information for the more popular titles was luckily enough reverse engineered at the time to be able to hit or miss emulating the games in much powerful hardware able to orchestrate not only the software but enough of the hardware for the game to run. Even to this day there are games that just don´t work emulated and many have visual or non important glitches to enjoy the game. Asking a 3DS to do this is... overkill depending on the complexity of the game, how complete and accurate is the n64 file and the skill of the emulator developer.

Believe me, this gets as tough as it can possibly be.

 

[Walegy0569]

I´ll bite the bullet and do some write up on this just so users reading this willing to learn can get something out of value from all this. I'll apologize beforehand for any mistakes in the post as it has been quite a chunk of time since I messed with any of this stuff.

First of all he/she is not completely in the wrong... it should be possible to read all code in the ROM of an n64 cartridge or extract the ROM part of a z64 file and then:

1. Detect all code subroutines
2. Find all loose machine code and try to organize it in sections without breaking the code
3. Find a suitable entrypoint
4. Build the elf manually as per standard

And you would have a N64 elf file to load... if the N64 had a elf loader in the first place to load the software. Obviously an elf file with NEC VR4300 code would never run natively on the 3DS's ARM and I don´t remember in this point in time if the libretro N64 cores for 3DS support dynarec so I will not go futher in that direction. And even if the N64 had an elf loader capable of loading this hypothetical file, it could even get loaded and start executing but it will crash a bunch of instructions in.

The thing is... the N64 games are a specific pain in the ass to work with because the N64 is not meant to run without a cartridge as the hardware is incomplete in itself. A regular N64 cartridge is much more than just the software as it does not only serve game software to the system but completes and extends the system capabilities. Allows the system to actually work just like the jumper/expansion pak does. One could say the N64 is a fundamentally different machine depending on which cartridge is in and believe me on this, some specific cartridges are an astonishing piece of hardware architectural design...

Due to this inherited design from NES and SNES, each N64 cartridge has specific hardware built-in with quirks and normally (but not at all always... see pokemon snap!) that hardware triggers using developer assigned addresses so what those addresses actually do changes from game to game. There were not a lot of these addresses available so in many cartridges developers had creative ways to communicate with the hardware such as but not all:

• calling the memory controller to read restricted memory areas in the ROM. each address in the read attempt meant undocumented stuff to do in the cartridge, most of the time asynchronously
• calling the memory controller to write on rom addresses. each value in the write attempt to a specific address meant undocumented stuff to do in the cartridge, most of the time asynchronously
• calling the end of the frame (entering VBLANK). Many cartridges have completely async hardware wating to read the end of the frame sent to the N64 to do undocumented stuff
• Some or all of the above together
• And more!

Most this information for the more popular titles was luckily enough reverse engineered at the time to be able to hit or miss emulating the games in much powerful hardware able to orchestrate not only the software but enough of the hardware for the game to run. Even to this day there are games that just don´t work emulated and many have visual or non important glitches to enjoy the game. Asking a 3DS to do this is... overkill depending on the complexity of the game, how complete and accurate is the n64 file and the skill of the emulator developer.

Believe me, this gets as tough as it can possibly be.

I know it's tough, and it's very TIME-consuming, However, I know it's possibly workable. It just may take WHOLE millennia for it to work.

I know (again) Gericom, worked on SM64 with some forms of code to not only make it stable, but to make it as the framerate is possible, but only in a newer version of the 3DS. So, that's exactly what I'm going to do is to make sure I can get it as clean and as well formatted to such a way, there can be some forms of code written that can run the game of Banjo-Kazooie.

Besides, I may be working on other stuff, like the N64 RomHACK I mentioner afterward, but believe me I actually want and I believe if I need to learn anything else, like JavaScript, C++, or any kinds of code to make this workable... I'll do so!

Also, thanks for your comment man, I could actually benefit from this research you just told me about the Expansion Pack for the N64, and attempt working it out into the source code once it's completed by the N64Decomp team!

 

[Kwyjor]

I know it's tough, and it's very TIME-consuming, However, I know it's possibly workable. It just may take WHOLE millennia for it to work.

Is this really something you "know"? Because earlier you were thinking you could get this running with a couple of scripts.

I know (again) Gericom, worked on SM64 with some forms of code to not only make it stable, but to make it as the framerate is possible, but only in a newer version of the 3DS.

Maybe they did, but they already had the complete reverse-engineered C++ source code – and once people had that source code, they weren't all rushing to port it to the 3DS first.

Once the reverse-engineering project is complete and people are releasing PC ports of Banjo-Kazooie, maybe then you can think about porting it to the 3DS, but odds are someone who actually knows what they are doing will beat you to it.

 

[Winduss]

Well, I'm am experienced coder when it comes to Python. Maybe I should perhaps ask, Gericom to perhaps give me info on which programs he used to encode the SM64 3DS port?

I just think you just have no idea what you're talking about. Learning to make some lights light up with python in computer class is a bit different than decompiling Banjo Kazooie and then porting it to a 3DS.

 

[Urbanshadow]

Also, thanks for your comment man, I could actually benefit from this research you just told me about the Expansion Pak for the N64, and attempt working it out into the source code once it's completed by the N64Decomp team!

Using the expansion pak requires the cartridge memory controller to be able to address 8MB of RAM (instead of 4) and the ROM specifically programmed to make use of that space. Banjo-Kazooie is not a Expansion Pak game so it has no use to research for it.