Thanks tepples. Getting 10 lives with the code + warping to 1-2 suffices. Pretty easy to beat the few hands right before Adobo. The below is on a front-loading NES (NTSC), no mods, just the cheat code.
Test 1: Adobo punched through the wall and began to approach, disappeared (!), and then I automatically beat the level.
Power-cycled NES, went through usual menu, picked ROM, loaded game, cheat code, etc...
Test 2: Adobo punched through the wall and began to approach, screen shifted abruptly (wrong PPU scroll register offsets or unexpected PPU write values) + some graphical corruption, game crashed (noise channel stuck on, so CPU is still actively running in a loop doing something)
I can make a video + upload to YouTube if folks would like to see the behaviour in question.
So, I have a gut feeling this is essentially a quirk/bug with the game being used on a PowerPak. It is not necessarily a game bug, nor is it a PowerPak bug. Several games are like this. (That said, it COULD actually be a real bug in the game that isn't immediately evident with a real cart, but it could also be by design).
Expanding: odds are there's a part of ZP/RAM that has a different value in it on actual hardware (cart) compared to the PowerPak. The PowerPak, like the EverDrive and similar devices, to function ends up using parts of ZP/RAM on the NES (for the menuing system and several other things) that an actual cartridge wouldn't use. There is no "standard" for this on the NES (i.e. the hardware itself does not "initialise" memory a certain way -- it varies slightly based on power-off vs. reset, how long it was powered off for, etc.). This is all covered in the first bullet items here:
PowerPak:
https://wiki.nesdev.com/w/index.php/Pow ... imitationsEverDrive N8:
https://wiki.nesdev.com/w/index.php/Everdrive_N8 -- see bottom of page
NES itself:
https://wiki.nesdev.com/w/index.php/CPU_power_up_state -- see "Internal memory" explanation
This same problem affects emulators, though it may vary per emulator because different ones (and different versions of those emulators) pre-initialise RAM to different values -- they cannot "simulate" a NES in this regard. So this puts more focus on it being a "quirk/bug" in the actual game that use of a PowerPak or EverDrive or possibly an emulator triggers.
Confirming this requires someone to actually reverse-engineer the game and figure out what ZP/RAM locations the game uses for Adobo busting out of the wall + what is used right as he begins to approach you. Rare games are notorious for being extremely well-written (i.e. highly optimised and complex), which makes this task likely even more difficult.
If someone wants to RE this game and figure it out, that'd be awesome, but then a patched ROM would be required. Use of a Game Genie code may be an alternate workaround/solution.
I'm trying to think of a way to debug this using the pre-selectable RAM value features of things like FCEUX SVN (rainwarrior recently added this, I think) or Mesen, but the problem is that you'd need to compare "bad/broken" ZP/RAM contents (e.g. after a crash) to that of "working" ZP/RAM contents **at that exact moment of the crash** (since a working game likely tinkers with tons of ZP/RAM variables).
I'll see if I can reproduce it in an emulator that lets me change the ZP/RAM pre-init at least.