User Files for Gimmick!

I've uploaded a 15 frame TAS of Gimmick! in the past, where I press the reset button twice. This TAS only presses the reset button once, though it only works if address $00F4 is initialized as a 00 instead of FF. Since the CPU power up state is inconsistent on actual hardware, I'm assuming this is (for some consoles) a valid power up state, and would run just fine.

As a brief recap of how this works, Gimmick! initializes every byte except addresses $F0 - $FF with zeroes. (then overwrites $FA - $FF) The NMI on frame 5 happens whether the PC is spinning or not, and I abuse this by stalling on frame 4 with 59 subframe inputs. The PC is at address $88E1 with PRG bank 0x7 when the NMI occurs, some banks are swapped out, and the RTI sends us to $88E1 with PRG bank 0x1B, which happens to be JSR $00A2. The controller data is stored at addresses $F5 - $F8.

The idea is to execute JSR $E0F0 which jumps to the credits, specifically for the good ending. This is done by pressing 0xC0 on controller 2 (A + B) and no buttons on controller 1, resetting the game, then pressing 0xE0 on controller 2 (A + B + Select) and 0xF0 on controller 1 (A + B + Select + Start) after the subframe stalling. That leaves addresses $F4 through $F8 as 00 F0 20 F0 E0, or BRK, JSR $E0F0. Again, this only works if address $F4 is initialized as 00, instead of Bizhawk's power up state of FF for that byte.

a

Use the Bizhawk SubNesHawk Core to watch. (Or the youtube link)

This has not been console verified yet, so if anybody wants to give it a go, it would be very appreciated. But you should know this run involves executing uninitialized RAM as code, (using bizhawk's 00 00 00 00 FF FF FF FF pattern) so keep that in mind. I'm hesitant to submit a Subframe Input TAS without console verification.

In this TAS, I complete the Game "Gimmick" by utilizing subframe inputs, not unlike my TAS of Super Mario Bros. 3. More info on the technical details if verified, but I'll explain a general idea of how the "route" works.

At the moment I execute RAM as code, the game has uninitialized RAM from address $F1 through $F4. This is a bit problematic for verification, but it's also the key idea of how this run works. Controller data is stored at $F5 through $F8, in pretty much the same manner as SMB3.

Circling back to the uninitialized RAM, bizhawk's "00 00 00 00 FF FF FF FF" pattern for RAM on console boot leaves address $F2 with "00" and $F4 with "FF". Both of those bytes get executed, and "FF" is a 3 byte instruction. That limits the number of "controller bytes" from 4 to 2. (Those are also the only uninitialized bytes that get executed. Gimmick! Clears the first 240 bytes of the zero page, leaving $F0 - $FF uninitialized, but by the time I execute code, the only uninitialized bytes are $F1 through $F4)

On the first frame with inputs, I 'stall' for 58 inputs, then using both controllers, I write STY $00F4. This replaces the "FF" at address $F4 with "08", as that's what was held in the Y register. This creates a PHP instruction, but what's more useful is that it's only 1 byte long. Now I have the full 4 "controller bytes"

I reset the console, and recall that address $F4 is uninitialized. That means when resetting, Gimmick doesn't clear the 08. I might go back and try to improve this TAS, but the subframe mashing to execute code seems to only work on the first frame with inputs. I need to strategically write JSR $E0F0, or 20 F0 E0 written as bytes. I need to hold down E0 (A + B + Select) on controller 1, while the new inputs are 20 (Select) so I use the first possible frame after resetting to hold down A + B. Then I reset again.

On the third and final loop, I repeat the same subframe mashing as before, and hold down the buttons that write JSR $E0F0, which wins the game when executed.

If I could find a way to offset the code so I can execute 3 controller bytes while also lining up the 20 F0 E0 for loop 2, I could save 5 frames. Likewise, if I can execute RAM after the first frame with inputs, it's likely I could cut out the second reset, saving time.

5f in first section
+3f in second section, due to some time dependend behaviour of the game physics. If I delay 1f in first section I don't lose frames.