Game objectives
- Emulator used: BizHawk 2.9.1 (SubNesHawk core)
- Aims for fastest time
- Corrupts memory
- 2 players (in order to manipulate the CPU stack)
This run beats NES "SWAT: Special Weapons and Tactics (J)" under a second, using a glitch which stalls the input processing routine with subframe inputs.
Note: I don't know whether this movie syncs on a real console, but I believe theoretically you can beat this game like this way on a real console.
About the game
"SWAT: Special Weapons and Tactics" is a strange 3-d dungeon RPG.
You control a five member SWAT team, and you have to resque hostages from terrorists occupying a building.
This game is notorious for having many nasty bugs.
This game was never released outside Japan.
Comments
This run uses a technique similar to the SMB3 game end glitch.
I think this game is quite friendly to TAS which abuses the DPCM conflict.
The input processing routine of this game has a code to workaround the DPCM conflict, and it loops until two consecutive inputs match.
This means you can stall the routine infinitely with subframe inputs.
And, this input processing routine is also called from NMI thread. So, you can let the CPU stack continue to grow and finally overflow.
And, the input processing routine pushes values depending on your inputs. So, when the stack overflows, you can write any value as a return address.
I write 0xC0C8 as a return address for
rts on the stack. So, the program counter jumps to $C0C9. This code calls the ending routine and resets the game.
This game processes a player1 input and a player2 input separately, and you can stall both of them.
When you stall processing a player2 input, the program consumes a less amount of the stack, comparing for player1. (Because, the input processing routine is called with
jsr for player1, but called with jmp for player2.)
You can manipulate the stack pointer with this fact.
Here is a memory map:
| addr | type | description |
|---|---|---|
| $02 | u8 | player1 raw input |
| $03 | u8 | player2 raw input |
| $04 | u8 | player1 edge input |
| $05 | u8 | player2 edge input |
| $C0C9 | code | calls the ending routine, and resets the game |
| $C6D5 | code | ending routine |
| $CAA9 | code | input processing routine |
Inputs are RLDUTSBA format.
Trivia
This game is developed by Shouei System. On many games developed by this company (e.g. Hokuto no Ken series), you can also stall the input processing routines with subframe inputs. But, I haven't found a game on which you can easily let the stack overflow like this game.
nymx: Claiming for judging.
nymx: I'm glad that TaoTao made mention of the SMB3 "Game End Glitch", because that was exactly what this reminded me of. I saw the demo of that TAS on one of the GDQ events with Dwango, a number years ago.
I used to not be a fan of memory corrupting glitches, but over the years I've learned to appreciate them more and more. This one...no exception, as it demonstrate good knowledge of the game and how to exploit it. I don't pretend to understand how this was accomplished, but I have certainly been exposed to many different game breaking techniques and I'm slowly getting there.
Accepting!
nymx: Reuploading for clarity's sake. I know this run is heavily on the subframe side, which accounts for the weird calculations...but I just want to make sure the cycle count. just in case.
despoa: Processing...