From 7568ad18c92be8dba703544693fac49d6263bdc9 Mon Sep 17 00:00:00 2001 From: Connor Olding Date: Thu, 17 Dec 2015 14:13:07 -0800 Subject: [PATCH] update main readme --- README.md | 56 ++++++++++++++++++++++++++++--------------------------- 1 file changed, 29 insertions(+), 27 deletions(-) diff --git a/README.md b/README.md index 0c7d5e4..de52bbb 100755 --- a/README.md +++ b/README.md @@ -2,6 +2,11 @@ i like to muck around in the memory of these games. +those who are more interested in the ROM will find [the binary template repo][bt] +more resourceful. + +[bt]: https://github.com/EntranceJew/zelda-binary-templates + # Majora's Mask for brevity, all addresses written here are given for the original US version. @@ -15,59 +20,58 @@ some sheets have been put together to dump data in. some of them can be used to are being documented here. * [Memory Addresses][gs_addrs] - updates more frequently than [MM addrs.lua.][noice] + updates more frequently than [the Lua equivalent.][noice] + +* [Entrance Data][ed] + a huge laggy mess that brings google docs to its knees. + this has pretty much been deprecated by the [exit calculator][calc] script, + which uses updated names, among other things. + a [4 megabyte csv dump of all exits][csv] is also available. * [Get Item Manipulation][gim] mzxrules did the original OoT one, i just jammed in MM's data for the item table and chest contents. *spoilers:* no desirable results besides light arrows, if it were even possible. _potential crashes are not taken account for._ -* [Entrance Data][ed] - this is a huge laggy mess that brings google docs to its knees. - enter an "exit value" in hex and it'll figure out exactly where it takes you. - the three known wrong warps are in bold. - [eventflags]: https://docs.google.com/spreadsheets/d/181V9dR5vBROdCVB4FkljG5oz2O4gGU5OTAkoPQX9X10/edit?usp=sharing [gs_addrs]: https://docs.google.com/spreadsheets/d/1HD8yZM1Jza3O8zO28n3k_Rjwdx58RSMA03915l51oDA/edit?usp=sharing -[noice]: /MM%20addrs.lua +[noice]: /Lua/addrs/M/common.lua [gim]: https://docs.google.com/spreadsheets/d/17LsLbF6aRePVRxisui8azPtDBfPmjugWIf91wPuXTsY [ed]: https://docs.google.com/spreadsheets/d/1e9kDyAW0gxXHFWS-GNEtVIo-rp39wQJJOtf3B0ehhqY +[calc]: /Lua/exit%20calculator.lua +[csv]: https://eaguru.guru/t/_exits.csv ## save files -save files are just memory dumps of some important data. save data is loaded into 801EF670, and extends roughly 0x4000 bytes. +save contents are mostly documented by [the save file binary templates.][savebt] -in the versions with owl saves, regular saves are 0x100C in size, and owl saves are 0x3CA0. +[savebt]: https://github.com/EntranceJew/zelda-binary-templates/tree/master/filetypes/Save + +in the versions of the game with owl saves, +regular saves are 0x100C in size, and owl saves are 0x3CA0. owls use the extra space primarily to store the pictograph picture. -note that some values don't are reset when reading/writing save files, even owl saves. - the game checks a checksum, and for the text "ZELDA3". each slot has one backup copy of itself, though they don't seem to be used? if a slot is corrupted, it will show up as empty in the menu. the checksum is a 16-bit sum of all bytes up to that point, allowing overflows. i've written [a checksum-fixing program][chksum] in python for bizhawk savefiles. +i've also written an [010][010] Editor [script][chksum2] +and its [OoT variant][chksumOoT] +for properly formed save files, such as those made by nemu64. owl saves always have 0x24 added to their checksum for some reason. [chksum]: /chksum.py - -save files are ordered as such, offset from the first: - -* 0x00000 - slot 1 -* 0x02000 - slot 1 backup -* 0x04000 - slot 2 -* 0x06000 - slot 2 backup -* 0x08000 - slot 1 (owl) -* 0x0C000 - slot 1 backup (owl) -* 0x10000 - slot 2 (owl) -* 0x14000 - slot 2 backup (owl) +[chksum2]: https://github.com/EntranceJew/zelda-binary-templates/blob/master/scripts/FixSaveMM.1sc +[chksumOoT]: https://github.com/EntranceJew/zelda-binary-templates/blob/master/scripts/FixSaveOoT.1sc +[010]: http://www.sweetscape.com/010editor/ bizhawk save files, at the time of writing, have the first file offset to 0x20800. also, their byte order is wrong. -here's my usual process for hacking on save files: +here's my usual process (in bash) for hacking on save files: ``` alias revend='objcopy -I binary -O binary --reverse-bytes=4' s="Legend of Zelda, The - Majora's Mask (USA).SaveRAM" @@ -86,10 +90,8 @@ because no one likes first cycle. sometime i'll bother checking what the bombers/lottery codes are for these. -* [Bizhawk US 1.0 race file](https://dl.dropboxusercontent.com/u/9602837/temp/MM%20US%20Race%20File%20for%20Bizhawk.zip ) -* [mupen64plus US 1.0 race file](https://dl.dropboxusercontent.com/u/9602837/temp/Legend%20of%20Zelda%2C%20The%20-%20Majora%27s%20Mask%20%28U%29%20%5B%21%5D.zip) -* [Bizhawk US 1.0 tampered](https://dl.dropboxusercontent.com/u/9602837/temp/bizhawk%20saves.zip ) - one slot with a bunch of 00s, another with a bunch of FFs. +* [Bizhawk US 1.0 race file](https://eaguru.guru/t/MM%20US%20Race%20File%20for%20Bizhawk.zip ) +* [mupen64plus US 1.0 race file](https://eaguru.guru/t/Legend%20of%20Zelda%2C%20The%20-%20Majora%27s%20Mask%20%28U%29%20%5B%21%5D.zip) ## bitfields