Add scripts to generate IPS files and ROM map from patch ASM files

[PJBoy]

Added python scripts:

• build_asar.py - runs the CMake commands to build asar from the submodule
• build_patches.py - runs the above built asar on all the ASM files in patches/src/ and Moasaic/Projects/Base/ASM/ to generate IPS patches to patches.ips/
• dump_rom_map.py - aggregates modified address intervals from IPS patches and feeds them to patches/rom_map/

Repointed asar submodule to newly created fork. Fork has been updated to generate IPS patches (which bitwise match the ones currently checked in) and to report an error if a readN command is used.

Moved some source unavailable IPS patches to patches/ips/no source/ directory.

The ROM map files as currently checked in are mostly using half-open intervals and I've changed this to closed intervals just to make intervals ending with FFFF work; I hope no one particularly minds this.

dump_rom_map.py will respect labels written without a leading semicolon (to support changes not originating directly from a patch).

It does aggressively separate address intervals in vanilla free space (to Bank N.txt) from intervals overwriting vanilla (to vanilla_hooks.txt). Thoughts on this are welcome, I'm not entirely sure I see the value of this separation.

[blkerby]

I think this looks fine to merge, just will let @jeboo and/or @nn357 take a look to confirm that the changes to the ROM map look fine.

I agree it would seem better to include all the address intervals in the Bank N.txt files whether in vanilla free space or not. So I think it could be simplified to do that, and then the vanilla_hooks.txt could be dropped. That would probably be good to put in a follow-up PR if that sounds good.

When I ran build_asar.py, the asar binary ended up in asar/build/asar/bin rather than at asar/build/asar/bin/Release as expected by build_patches.py. Maybe it's just some platform-specific behavior from CMake, not sure if there's a clean way around it, but it might be nice to have some workaround (not necessary to be solved in this PR).

There is some functionality in the current build_ips.py that doesn't seem covered by the new build_patches.py:

• It has a --verify option which is used in the Dockerfile build to check that none of the IPS change when rebuilt, i.e. ensuring that the IPS checked into the repo are consistent with the ASM.
• It checks for overlap between the patches to warn about conflicts.
• It shows diagnostic messages from asar.
• It uses timestamps to check what needs to be rebuilt. This is a bit fragile (e.g. doesn't work properly with includes) so I wouldn't mind dropping this behavior. The only issue is that it's going to be hard to sift through all the diagnostic messages to find what you're looking for if everything gets rebuilt. Probably a good simple solution would be to just add a command-line option to be able to assemble a single, selected ASM file instead of globbing all of them like it does by default. Then you can get super-fast results and just the relevant diagnostic messages. And eventually we'll clean things up so there shouldn't be so many messages.
• It can be run from the project root directory, while build_patches.py requires running it from the directory where the script is. I guess ideally it could just use __file__ to find where it's located so that it can set the working directory itself.

None of these create an issue with merging the PR since we can just continue primarily using build_ips.py for now, treating build_patches.py as an experimental alternative in the meantime.

[blkerby]

On the other hand, I am remembering having problems in the past when I would only assemble a specific ASM file, because it's easy to modify another ASM file and forget to reassemble it. So assembling all of them is probably better/safer than just assembling a hand-picked one.

I see that build_patches does display the diagnostics when it fails to assemble. So maybe that's good enough. I only worry a bit about completely suppressing the warnings when it succeeds. So I'm not sure what the best solution is. But it can be a problem for later.

[nn357]

Had a quick look over the results (will try it out tomorrow).

One thing I did notice is in the output of the bank logs.

There's a couple of chunks of vanilla code in bank 91 that are replaced with code from split_speed / x_mode fix that are currently noted but don't seen to have been included in the updated bank logs.

[PJBoy]

Thanks for the generous feedback.

I'll resolve the CMake binary path issue in this PR, that's an unfortunate platform-dependent behaviour I didn't anticipate, but it seems resolvable.

The proposed enhancements for build_patches.py all sound good, I'll work on that (targeting a future PR).

The addresses for the replaced code in bank $91 are now in vanilla_hooks.txt; perhaps a good example of why forsaking vanilla_hooks.txt might be the play.

[PJBoy]

CMake build should be working now, outputting to the location a single-config generator (like makefiles) would place it. There's no way to query the CMake binary output directory outside of a CMake script; I would either have to modify the asar CMake scripts to note down the directory somewhere or write a miniature CMake project in this repo that imports the asar one. Meh.

Added a conflict detector for build_patches.py that uses the ROM map as a reference. Consequently, I've removed all the vanilla address intervals from vanilla_hooks.txt (which would otherwise conflict with everything).

Added a command-line option to be able to assemble a single, selected ASM file as suggested. Added some other output control options whilst I was in the neighbourhood.

Added the os.chrdir calls to let the python scripts work from other directories.