Findings from the Deep

 Observations only a Famicom archaeologist could love!

Even if you play a game straight through, you're going to miss out on a lot of code and data. The same is true when you skip around using the debugger cheats. Thus, once I got 87% of the ROM mapped, I went for a deep dive to try to find and address any unmapped code. In some cases, I just ignored the data when it was clearly a data set, but other times I went back and tried to coerce the game into reading (and mapping) said data. For the actual game code, however, I have tried to get it to run whenever possible. Knowing what each variable does naturally makes it easier to figure out what I need to do in the game in order to run said code.

Enter the character swapping states. Certain aspects of the game are broken up into two parts - a horizontal state and a vertical state. Character swapping is one such aspect. Game state #0b handles character swapping in a horizontal room, while game state #0c handles character swapping in a vertical room. 

I noticed an unmapped block of code I eventually traced back to game state #0b. Part of it had been mapped, so in order to get to the unmapped parts, I had to meet some conditions. One of which was if the room was flooding. Another was if the character was farther up the screen than #4e pixels (or something like that), or farther down the screen than #dc pixels (or whatever). Testing the flood room was simple enough using the debugger, so off I went to the stage 08:04:00 with Grant as my partner. Once there, I swapped characters. I was unimpressed, but I checked and new code was indeed mapped.

I decided to test out game state #0c, so I jumped to stage 01:00:00. The code for #0b and #0c was nearly identical, so I looked to see if there was another branch that would point to the unmapped data. Once again, I saw a conditional for being between #4e pixels and #dc pixels (or whatever), but no flood requirement (because vertical rooms don't flood). Rather than crawling to the top of the room, I just set the y-coordinate to #30, which conveniently there was a already a block there. Since I didn't actually move up there, the screen did not scroll with me. Now that I was in a vertical room positioned above #4e (or whatever) pixels, it was time to map that code! I swapped characters once more, and... Nothing extraordinary happened.

At that point, I had an epiphany. The code which was already mapped had an IRQ control value. In other words, by default the game messes with scanline rendering when swapping characters. Specifically, the game creates this odd "horizontal banding" effect with the character sprites during a normal transition. The unmapped code skipped the IRQ control values. I slowed the game down, disabled the background, and swapped characters one more time....

It turns out the game will use the horizontal banding effect during character swaps only if no part of the character is off-screen or overlapping the status bar, or if the room isn't flooding. The rest of the effect still happens, just without the banding.

I warned you it'd probably be a boring observation. More such observations to possibly come later.

 

Postscript: What exactly is  background palette set #15 used for? It's the only background palette set not yet mapped for me. Every room's palette set is mapped, so I know I didn't miss a room. Sprite palletes #03, #12, #14, and #18 are also not mapped for me. I even checked the intro, the epilogue, the ending credits, the map screen, and the password screen. Nada!