It is not much. Most of the work is done automatically by just playing the game, using FCEUX to make a code and data log (to know what is what), and then poking some values here and there with some formatting.
It is a far cry from, say, the Mario 1 or Mario 3 disassemblies, which are for the most part well-documented and commentated. This is the beginning of that.
More updates today. The assembly is now byte-for-byte identical to the original game, by using .db xx xx xx for instructions that are not supported. (The correct instruction is added as a comment in the disassembly.) You can turn on the other behavior of using proper zero-page accesses by removing a flag from build.bat, namely -d_COMPATIBILITY_.
Also, the disassembly is now capable of building a byte-for-byte identical version of PRG1 / REV-A, too.
It is on a separate branch for now while I continue to work on the main pre-split assembly. Revision A mostly fixes a bug involving the Fryguy boss, where under certain conditions you can softlock the game. (There is also another small fix with PAL consoles that displayed only a blank screen for the bonus game.)
The hard part is going through the result, figuring out what everything does, and assigning names and nice macros to make it readable and editable. The output from just going through code/data logging won't have any names.
Yeah, and labeling everything, finding all the places where "$8137" should actually be a label and not a value, that sort of thing. Otherwise you run into a ton of issues if you rearrange code.
Currently you still can in a lot of places, but you should be able to just build most of it without too much trouble. I'm slowly fixing the places that falls apart, but some of it will require a lot of work to figure out a good format for, like the music (which has a main pointer, then a bunch of relative one-byte addresses to the data within)
Anyway, I'm working on making a debug menu that can jump to different parts of the game, to help testing (so we stop having to make a bunch of savestates everywhere )
Right now it's still very much a work in progress. The menu will load and show text, but you can't actually do anything. I'm still trying to figure out how it should work under the hood and what variables are safe to overwrite, since you can call this from anywhere... even though you can't really go back afterwards
Most of the code for this right now lives in this file on the "debug" branch, but in true to how I want to do this you can still build this version with the debug components optional. When it's closer to being done I'll probably merge it into the main branch.
I recently implemented a similar menu in Pokemon Crystal. It's a lot of work but the way I ended up designing it is:
Each item has:
A pointer to text
A pointer to a RAM address
A pointer to an "activate" method (called when you press A)
A pointer to an "adjust" method (called when you press left/right)
A pointer to a "draw" method (called whenever the item is drawn)
Any of the pointers can be null to use a suitable default.
n-byte variable displayed as decimal (n=1 to 4)
n-byte variable displayed as hex
1-byte variable displayed as Pokemon ID and name
etc for items, moves...
The default "adjust" method for all types except "text only" increments/decrements the variable pointed to (if it's not null). The default "draw" method draws the text followed by the variable. The default "activate" method does nothing. Left/Right call the adjust method with -1/+1 as parameter, or -16/+16 if Select is held. Start does nothing, B exits the menu.
It's complex, and it's tedious to adjust large values (something I should fix), but it makes nested menus really simple, and macros help with defining items:
db "MAP @"
ld de, SFX_WARP_TO
ld a, -1
ld [wDefaultSpawnpoint], a
ld a, MAPSETUP_WARP
ld [hMapEntryMethod], a
ld a, 1
ccf ; return carry=0 from activate method to close the menu
I was planning on doing something similar, but not quite exactly the same. The current option would be a number, which would index into a list of pointers to the main "run the menu code", and those would handle their own button presses. Basically: