Talk:Super Sprint (NES):RAM map

Finish Line Pause Glitch

There is a glitch that lets a player sit on the finish line while mashing the Start button, resulting in the lap counter increasing until the player wins the race. The game runs parallel code, relying on interrupt requests to pause one code while the program catches up on some other code, then returning back to the previous code. The issue with this is the programmer needs to be careful not to reuse any WRAM bytes currently in use in the paused code. Unfortunately, the programmers used byte 0x01B for both polling the gamepads and for keeping track of what the track attributes are for the player's current position. Pausing the game forces an interrupt, which may result in the gamepad polling function running during the finish line crossing function.

When a car crosses a checkpoint, the program compares it to the next checkpoint in sequence. The finish line is always tile #4E, meaning it is checkpoint #0E. Typically when you cross the finish line, the next checkpoint is #0E, so it increases the lap counter because the values match, then it sets the next checkpoint to #00. This prevents the lap counter from increasing more than once per crossing. When the game is paused and the gamepad polling function runs, it is possible the current checkpoint value (0x01B) is set to #00, making the program think the car just completed a lap. In a two-player race, this glitch is unlikely to occur for player 1 because gamepad 2 is the last one polled, so if any button on gamepad 2 is detected, the glitch will not occur. It is also worth noting this glitch could potentially allow a player to skip checkpoints in a two-player game by using the pause trick over a checkpoint prior to whatever buttons player 2 is pressing as long player 2 is only holding the D-pad and no other buttons.

I "fixed" this by setting 0x1DBA9, 0x1DBB5, 0x1DBBF, and 0x1DBCB each to #13, since byte 0x013 seemingly isn't used during races.