search

glankk / gz

Ocarina of Time trainer
https://glankk.github.io/gz
197 stars 50 forks source link

Generating UPS patches #1

Closed terry-au closed 8 years ago

terry-au commented 8 years ago

Hi,

I'm currently installing the toolchain and waiting for gcc to compile. I'm just curious on how UPS patches are created. I can only assume that CodeBlocks will generate an elf file, which I imagine you are passing to the N64 via a GameShark. I don't have access to a GameShark or anything outside of a regular N64, OOT cart (probably v1.1) and NO N64 developer tools (Everydrive, 64Drive, etc).

I'm hoping to at some stage work to port this over to v1.2 for installation on Wii/WiiU. I just want to know if I have any chance of generating UPS patches without a GameShark. If a GameShark is required, is there a chance that it could be accomplished via an emulator?

Great work by the way, awesome stuff!

glankk commented 8 years ago

Hey Terry, glad you like the project!

I'm not sure exactly what you're asking. UPS patches can be created by any patching tool that supports the UPS format and is capable of making patches, such as the one that is bundled with the latest release. The included patch files were created with that tool, using an unmodified rom as the "original file", and a hacked rom as the "modified file".

If you're asking about modifying the rom, which needs to be done before a patch can be created, that process is a little more involved. Currently, this is done completely by hand using a hex editor, and this repository does not have everything needed to accomplish this. However, I am currently working on automating this process. That will be my main focus before any further development of this project.

Hopefully I've answered your question. Let me know if there's anything else you're wondering.

terry-au commented 8 years ago

Thanks for the reply. I'm happy to hear I don't need a game shark, if I understood correctly.

I setup the tool chain and emulator and managed to compile. I also created a save state with the same name of the OOT save state mentioned in the code blocks project file. I imagine you intent to implement some kind of injection routine to inject the compiled binary into the save state, or is this already implemented and not working for me?

With regards to the hex editing, how involved is it exactly? Does it simply consist of trimming the compiled binary's header and dumping a certain section into the ROM or is it much more in depth? I noticed you're using the text hook address, I can only imagine that is a frequently accessed function in the ROM where you are calling your code and jumping back after. I've not had a really good look but it looks like a really great project and I'd love to contribute if I can.

One more thing, do you know of any limitations with implementing it on the 1.2 ROM or was the decision just personal preference?

Thanks a lot!

terry-au commented 8 years ago

I've taken a shot at comparing patched and unpatched files. I noticed that there are a few stages that you have made changes, namely, the header, with regards to CRC1 & CRC2 and of course the injection of the binary itself (0x01F7B720 onwards).

I also noticed changes at 0x00001001, 0x000010D4. There is also a rather big change spanning from 0x00A8ADD1 to 0x00AFD880. If you could clarify on these changes, I'd appreciate it a lot.

Cheers

glankk commented 8 years ago

The load-state argument that is being passed to the emulator is only there to make testing easier, as it saves you from having to go through the title screen every time. Other than that it serves no purpose, and isn't needed. Testing with BizHawk is done by loading the original rom, then executing the patch script from the lua console. This will inject the binary and hooks into the game's memory and let you test it without having to modify the rom. Porting the hack to version 1.2 shouldn't be more difficult than adjusting all the memory addresses, though it might be tedious to find them all.

Injecting the code into the rom starts with replacing the bootloader, located at 1000h. The replacement bootloader copies the binary to its assigned address in ram, and then passes control to the original bootloader, which has been moved elsewhere. The big change you mentioned is the file that contains the game's main code base, which has been modified to include all of the necessary hooks. Finally, the CRC is updated to reflect the changes.

Happy hacking!