Slashdot Mirror
NESBot: Tool Assisted Speedrun On Real Hardware
Xistic writes "For many years tool assisted speedruns were purely theoretical and the domain of emulators. No longer! Using an Arduino Duemilanove microcontroller to drive an actual Nintendo console, pjgat09 plays back prerecorded input to beat Super Mario Bros. in record time. The selection of possible games is limited: 'If the game relies on any uninitialized memory for randomness, or if it is heavily based on console timing, it may not work. In the case of Super Mario Bros however, as long as the button presses start play back at the right time, the movie will play back correctly.' The author includes complete instructions on how to setup the device."
Welcome Slashdotters.
An introduction might be in order. Please note we have many other movies for other consoles. We also have a list of recommended movies for first-time viewers.
Please don't beat up our poor server too badly.
That run exploits bugs from SMB that I didn't even know where there. I counted at least 4 times that he ran through walls in one way or another; to say nothing of the way that he would jump on the edge of a pipe while the flower was out and not take a hit.
Damn_registrars has no butt-hole. Damn_registrars has no use for a butt-hole.
This won't work with all games. Many games made by Konami use aggressive random number generators which depend on the number of clock cycles consumed while the game waits for the next frame.
Then the game also plays digital samples through the DMC channel, and the DMC channel does not have a known consistent power-on state. Because the DMC channel periodically interrupts the CPU to fetch bytes, that will affect the number of cycles it takes while it waits for the next frame.
So we have two issues coming together, number of leftover cycles from power-on state, and initial DMC state, so when you play one of these games, the game's own demo mode isn't even consistent between multiple power-ons.
You can try it with Blades of Steel or Double Dribble, and see that their demo modes aren't always identical between different power-ons, even when you are aren't touching the joypad.
No chance of those games being TASed on hardware.
Other games are far more friendly, and don't rely on exact timing for their random number generator behavior.
Sure looks like he's going through the flesh-eating flowers and the rotating balls to me
Hitboxes for most enemies in SMB1 are only half as tall as small Mario.
One of the key things that makes this work is that on the nes the game controls polling of the controller and the controller polling process involves controlling a shift register in in the controller. Afaict his board locks to one of the signals that controls the shift register and uses it to stay in sync with the game. This allows it to play through an entire game with frame accurate timing. Something that would be MUCH harder to do by mechanically actuating a real controller even if you took a sync source from the console.
And doing it without a sync source would be basically impossible.
was not an easy task because of the way lag is handled
Lag probablly isn't a particaully good term for the issue. AIUI the issue is that there is not a 1:1 mapping between controller input cycles and frames out output. Since his device is locked to controller input signals rather than dispaly frames he needs to strip out the frames that don't have a corresponding input cycles.
note: i'm known as plugwash most places but i screwd up registering that here somehow in the past and now can't register
Next up, High Frequency Tetris on sub millisecond collocated hardware!!
Though I am impressed that someone got an Arduino to do something like this, I still think that it's impressive that it only barely squeaked by the "real" record. Here's a human player (not Tool-assisted):
http://www.youtube.com/watch?v=bRyhpxR3l_g
By my count (seconds are "game-seconds"):
1-1 Tie
2-1 Arduino up 1
4-1 Tie
4-2 Arduino up 3
8-1 Tie
8-2 Human up 4
8-3 Arduino up 2
8-4 Arduino up 2
So if my reckoning is correct, the Arduino, with all its glitches, only beats a human player by 4 in-game seconds. Though SDA counts time from when the games starts to finishes, including loading times between stages, in which case it looks like the Arduino may have won by 5 real seconds. Still, the human players have done incredibly well on this game to fine-tune it to the point they have. Yes, I am a geek.
Interestingly I once saw this in some C code: