-
Notifications
You must be signed in to change notification settings - Fork 363
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Build Guide #17
Comments
The Wii uses elf files, right? Could a game converted to be a Wiiware retro console title and then used? |
You can also use MSYS2 on Windows. If I remember correctly, clone the repo with
I would also like to know how to do this.
ELF is basically just a standard executable extension that many systems use; they're not actually the same, similar to how Wii WADs and Doom WADs aren't the same. |
As far as I can tell, you need to decompile an N64 ROM in order to get an ELF file for it. I was able to generate the ELF file for Duke Nukem Zero Hour by using this Decompilation project for the game: https://github.com/Gillou68310/DukeNukemZeroHour You also need to figure out the memory address for a given game's program "entrypoint" however, and include that in the TOML file (This page might be useful: https://n64brew.dev/wiki/CIC-NUS#Variants). In the case of Duke Nukem Zero Hour, it seemed to use a nonstandard entrypoint, but I put in 0x80003940 as a guess (I chose the memory address referenced in the main function at the bottom of main.c in the decompiled source), and that seemed to work. |
a little question, after you found the entrypoint, how exactly did you generated the elf file? |
I followed the instructions in that Duke Nukem decomp repo under "BUILDING", and the ELF file was generated along the other files in the build directory. Truth be told, I'm still not entirely sure what these ELF files are in the context of N64 games, but the readme for this Recomp repo said that decompilation was the easiest way to get an ELF file, and I happened to know of the decomp project for Zero Hour, so I gave it a shot. For the record I couldn't figure out how to actually use the output of the Recomp binary. After supplying it with the ELF and entrypoint address it generated a bunch of c files, and I was able to generate object/o files from these by including the "include" directory from the Zelda64Recomp repo with GCC, but I couldn't figure out how to actually link the object files to an executable. I figure it might have something to do with the lib directory submodules from the Zelda64Recomp repo, but I didn't have any luck. It could be that there was an earlier entrypoint address than the one I supplied, but in any case I'm giving up for now. |
Compiling an N64 rom with this method also compiles an ELF alongside it. CaveHermit [edit, I put the wrong name], what did you use for the TOML? Here's what I tried:
... but I'm getting a bunch of |
That looks about the same as what I wrote for my TOML file, although make sure that you have the correct relative paths for elf_path and output_func_path (The way you have it written, it'll only work if the elf file is right next to the Recomp binary). Did you get any c files in your output_func_path directory? I think I remember my output having "jal resolution ambiguities". but I'm not entirely sure. |
just tried this (with paper mario 64), and yes it did have the resolution ambiguity and produce a recompiledFuncs full of c files |
Just to add onto the discussion here, I ran across a bash script here that is said to convert .z64 to .elf here. While using the .elf file generated from the script doesn't work with the built executable for recompilation, by opening the .elf in a text editor, you get the same entry point for the ROM as you would by opening it in Ghidra (as I did with Pilotwings 64). |
My TOML is indeed next to the Recomp binary, so it's fine. I have 1,362 C files plus three other files in my output_func_path, but still running into those warnings and that error.
I found that same script earlier but couldn't get it to work (I probably just don't have the right mips toolchain or something). Could you just use something like Ghidra to generate an ELF for any rom? |
Funny you should mention this, I'm experimenting with exactly this right now. Here is a library for using n64 roms in Ghidra: https://github.com/zeroKilo/N64LoaderWV I'm poking around, seeing if I can find a way to reverse engineer the entry point for some arbitrary rom. Ill report back with any updates if I make any progress. |
I did find this https://gist.github.com/JayFoxRox/5eaa45b374a44ce27143388bab1753b7 in my searching.... but I can't get it to work. A better option will turn up sooner or later so I am putting this on the back-burner for now. |
ooh, interesting and i see, i need this .elf from a game in order to have the recompile program to work? |
incase anyone needs it here is what i could find for a base toml config file:
|
interesting so i just need a entry point value and the elf path then the tool will generate the recompiled game? |
That's consistent with what was shown in this video as well the example toml file in the Majora's Mask repo, so yeah that's all we should need I do honestly believe that Ghidra and similar tools will probably be our best bet for figuring out a way to generate an elf file for games that don't have decompilation projects yet |
at 2:27 if anyone is interested, shows Rocket: Robot on Wheels being converted |
https://n64decomp.com/basics/rom/rom_image_specification.html might help somewhere |
click on CIC Specification get 'to do' lol |
You know what might work.... the Ares emulator https://github.com/ares-emulator/ares/tree/master/ares/n64/cartridge An extra function to dump an elf file from that could work. I honestly don't know, just throwing ideas in the air. |
Is that an actual feature of Ares, or are you speaking hypothetically? |
hypothetically, I am just compiling information for people who are smarter than I to be able to do something... Currently looking at https://github.com/HerbieHSSO/PyN64 but it makes little sense to me. |
I mentioned this in my issues thread but gonna send it here too for everyone else because it is important: I was able to generate an elf file with this bash script https://gist.github.com/JayFoxRox/5eaa45b374a44ce27143388bab1753b7 |
If you ever need to convert to any of the 3 existing format of N64 roms you can use Tool 64 https://www.zophar.net/utilities/n64aud/tool-n64.html |
Apologies for not having this out yet, but I will be creating a minimal recomp example in the near future that should help clear up how to use the tool. The main requirement is that you have an elf file (which can be generated from a disassembly or decompilation) or a symbol file and the ROM. |
i did find this to convert a z64 file to elf https://gist.github.com/JayFoxRox/5eaa45b374a44ce27143388bab1753b7 |
That elf won't work here, it just packages the ROM up into an elf without providing any symbols. The recompiler needs to know where the code is in the ROM, which is what the symbols in elf are used for. |
oh ok |
I guess that a lot of people (myself included) come from this video which gives the impression that the tool only needs a ROM. It is my understanding, and it seems to be what you're saying, that this tool won't bypass the decompilation step which still has to be done manually as it need an elf file that you get through a manual decompilation. |
The work needed to produce a viable elf file for a recomp is only days worth of effort with modern N64 reverse engineering tools, such as splat. You don't need to decompile any code; a disassembly works fine. If you know how to use the reverse engineering tools then it's practically automated nowadays with how good all the tooling is. That's why Nerrel mentioned that it took me a couple of days each to get MM, Rocket and Superman running initially. With that said, it still requires knowledge of reverse engineering as they (and this recompiler itself) are very technical tools. The symbol file mechanism I'm adding will let you throw a ROM directly at the program without an elf, but the symbol file will still require a similar amount of reverse engineering to get running. I wouldn't be surprised if somebody makes a tool in the future to generate a symbol file mostly automatically from a ROM, which would reduce that already small amount of work required even further. |
Sorry if this is redundant or completely wrong, I'm new to N64 modding, but I really enjoy emulation and game preservation, and this project absolutely fascinated me. Does this this create a sufficient structure of symbols to create an adequate ELF file, or would there still be more work to be done? If not, can you link to a resource explaining how in a future README? I ask because I think a lot of people are attracted to this idea, and it would be a shame to have them be turned off by this roadblock so quickly. Thank you for making such a great advancement in the space. |
It looks like that only searches for specific symbols, rather than generating a list for all the code in the ROM, so no. Depending on how well it works it would be a good start, but you'd still need to find where all the code in the ROM is besides what this tool looks for. I'm not sure I could write instructions on how to learn reverse engineering in general (and for N64 specifically), given the scope of what that'd have to cover. It took me a while to learn what I know about it, which I got from working on ROMhacks and helping with decompilations (among other things), so I wouldn't really know how to encapsulate all that knowledge into a guide. This tool is mostly focused on reducing the effort and time needed, but like I mentioned it's still a very technical process. There are communities where people do N64 reverse engineering that do exist, but given how popular this project has gotten (a fact I couldn't be happier about), I'd be worried about overwhelming them with how many people would end up joining if I linked them directly. As I mentioned, I could imagine that people may make other tooling to make the recompilation process easier in the future. If that happens, I'll be sure to link them in the description of this tool. |
For those building in Windows, I was having this error when attempting to run
|
Personally, the command EDIT: ---------------------------------------------------------------------------- It seems that I have successfully retrieved the ELF file of I had to switch to Ubuntu on VMware and get help from Copilot to succeed in doing this.
It is also necessary to put these files ( I hope I have helped you, I will continue my research on my side. You will notice that I have the same problem as some others, the SYMBOL TABLE start, end, and size are all numbered at 00000000, yet the ELF file is exactly the size of my ROM. Consequently… it is impossible for me to recompile it. |
I get 4 error popups after installing it with that C++ toolset. I'm on Win10 x64 Pro, if that matters. Msys2 and Cygwin won't compile this thing either. Can someone just share the compiled binary file already? This is annoying as shit. |
Oh, man, reading all this I have a question - is it theoretically possible to recompile a PS4 game like this? |
The only way you’re getting a PC port of Bloodborne is if Sony makes it themselves or someone leaks the source code. |
Not true. There is a potential emulator in development (though it seems like there is a possibility that the dude who develops it was already contacted by Sony and paid to not develop it LMAO), and, theoretically, somebody could actually reverse-engineer the source code, like modders do. I just asked the person who created the "Tool to statically recompile N64 games into native executables" if this is possible to do with PS4 as it was with N64. |
i need a makefile, it wont work without one? |
Please make a video or something going through the process. These are the steps I've come to understand needs to happen from scratch: Git Cloned N64Recomp *Digging around for methods to generate the ELF Step 2 -> ???? |
This project isn't at the point where a checklist like that is going to work. Like wiseguy said earlier, this process requires knowledge of several tools and how n64 games are structured. Hopefully at some point, various components of the pipeline can be streamlined. But right now, you have to really understand a lot of the inner workings of things |
Guess I'll have to deep dive into reverse engineering resources / documentation then. |
Just throwing in my experience so far. I was able to get my ROM in an elf format using the existing WIP Pokemon Snap decomp project https://github.com/ethteck/pokemonsnap. |
This project is fascinating, but there are many doubts and a lack of documentation. Let's hope there are more concrete answers. What I want to know is how to link the graphical API, or how this process is done. I kind of understand the .elf thing, and it won't always work because there are games that use overlays. |
If you are still playing this game (Conker BFD) I would like to know if I can contact you, I am currently making some mods |
Would be helpful!
Trying to build it from the vague guide that is available
The text was updated successfully, but these errors were encountered: