notwa/mm
1
0
Fork 0
mirror of https://github.com/notwa/mm synced 2024-11-04 22:49:03 -08:00
Code Issues Releases Wiki Activity

update main readme

Browse source
This commit is contained in:
Connor Olding 2015-12-17 14:13:07 -08:00
parent e65ff9bae6
commit 7568ad18c9
1 changed files with 29 additions and 27 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

56
README.md
View file

@ -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