How does ‘Trent’s circuit board strategy’ work?

Question

For those of you who are unaware, professional speedrunner Trent Hall discovered a now-banned speedrunning trick in GoldenEye 007 for the Nintendo 64. The trick (called ‘Trent's circuit board strategy’) consisted of plugging a dismantled second controller into the second controller port. Then, when there is a countdown timer, pushing down on the exposed circuit board to freeze the game while the countdown continued. Because the Elite GoldenEye Rankings are ranked in IGT (in-game time) as opposed to RTA (real-time attack), this strategy would save tens of seconds on many levels.

My question is... well, what causes the N64 to behave in this way? This seems like an extremely unlikely result.

A video by former GoldenEye champion Ryan "RWhiteGoose" White on the strategy: https://www.youtube.com/watch?v=tr6txZdNcc0

Read more about Trent: http://www.shootersforever.com/forums_message_boards//viewtopic.php?t=6332&view=previous&sid=6a6704f2fa89f78f2d42239d5cd4205f

Answer 1

Many devices that may receive inputs at arbitrary times are designed to interrupt the processor whenever input arrives. When the interrupt is triggered, it will be disabled until code finishes processing it, but in many cases, the interrupt will be re-enabled as soon as processing on that particular input is complete. If something causes the interrupts to arrive much faster than expected, this may result in the CPU spending almost all of its time servicing the interrupts, and having very little time left over to do anything else.

On my first Commodore 64, one of the CIA chips had a defect which would cause it to interrupt continuously and also reset the "real time clock" if certain combinations of keys were held down (a weird behavior that was probably a result of a poor power-supply connection somewhere internal to the chip). On that machine, games could be "paused" by pressing down such a key combination, though they would resume if the keys were released; such behavior did not occur on other machines. I think something similar may be happening in this game, though I don't know enough about the particulars of how the controllers work to know the precise mechanism.

Answer 2

Here is my theory: the N64 controller uses basically a UART protocol. The console (as instructed by the game code) sends a command to the controller and then receives a response. Because this is an asynchronous protocol, there's no required timing (like there would be in a SNES controller, which is synchronous). So the console will wait until it receives the response.

If the console doesn't receive a response it might try sending the same command again. And again. And again. And again. And so on until it actually receives a response.

By physically breaking your hardware messing with the circuit board in a specific way, if you can stop the responses getting back, it may cause the controller input function in the game code to get stuck, sending retries over and over. N64 games can be multithreaded. If the controller reading happens in the main game loop, but the countdown timer is its own thread, it could cause the described symptoms.

However, this is just a theory based on the described symptoms and the technical documentation of the controller protocol. It seems very likely, which is why I've dared to write it as an answer. Someone would need to actually test this on real hardware to confirm it.