The math concept, I think, is where I get lost. I'd need step by step, line diagram drawings showing every single change, with an explanation of why and how. Probably with Elmo and Big Bird. I had someone try explaining how to multiply without a calculator and after a while I just went "But that CAN'T work with a NES! The numbers aren't connected at all! 256 times 2 doesn't make 512, it makes 256+256!"
After staring a bit, I think I can sense how it works. The distribute line makes the most sense. That's how I handled math in school. Break larger numbers down into easier ones, then re-build the final number. Kind of what I was trying to do--which was correct except for where to add in the high bits?
Anyway, just glad that's all over! Time for another update!
* Added sequence data to restore default Duty settings to all original songs, since my new Marsh Cave song changes it but there was nothing to change it back for other songs.
* Battle and Prologue music's Square 2 channel is now played by the MMC5's SQ2 channel so its not interrupted by SFX.
* Re-wrote Hiding code to be even more space-efficient!
* Wrote some un-space-efficient code to allow buying 1-99 items in Item shops only.
* Re-organized Character Stat data storage. Now have 24 continuous free bytes for each character.
* Re-organized my new MMC5 variables to share space where possible.
* Did a few more spots of data cleanup. Enemy stats now ready for direct editing thanks to the FFbytes docs by Dienyddiwr Da -
http://www.romhacking.net/documents/81/To-Do:
* Figure out how ChaosDeath erases the battle background, because the background is now smaller and it will erase the boxes...?
* Go through the zero-page RAM wossits to find any unused spots and see if I can shift things around to put more audio channel stuff there instead of in MMC5 RAM. Might not be worth the effort.
* Use 24 leftover ch_stat bytes to index spells. 3 spells, 8 levels, 24 bytes!
* Combine ch_class and ch_sprite into high/low bytes. 1 more byte to use.
* ch_exptonext probably doesn't have to be saved. If it can be calculated and saved, it can be calculated and printed each time the status screen is looked at. 2 more bytes saved.
* ch_hidden doesn't need to be in the 64 bytes per character. 4 bytes saved in total!
* Character level can be used to index max MP. Current MP can be squeezed into 4 bytes possibly. First byte high: level 1. First byte low: level 2, and so on.
* This would free up 256 bytes for more game_flags (chests, npcs, events?). Possibly makes room to save more than 1 game at a time??
Question: Is it normal for an MMC5 rom's save file to be 64kb (using Mesen)? First $400 bytes is the "unsram" stuff, which I figured was UNSaved RAM. Second $400 bytes is a copy; the saved RAM. Then $1200 bytes of other stuff (I see its map data) and then like $8000 of 0s. So uh. Do I even need to be making space to make more save game slots??
Even the original game's save file is 8kb...
I suppose I could make a "Save and quit" feature that over-writes the map data, and be more vigilant about the original variables while moving them over to the work RAM in $5C00--freeing up another $400 for save data. Makes 2 save games and a third save file that gets clobbered on load and clobbers map data when saving and shutting down...?