TASVideos

Tool-assisted game movies
When human skills are just not enough

Console Verification Guide

Console Verified Movies | Console Verification Tests

Introduction

This guide will explain how console verification works and take you through the steps to play back movies on the actual console. This page assumes you are already knowledgeable about playback of movies in the emulator. If not, consult Emulator Resources for advice on how to set that up first. You will also need some knowledge about electrical circuits, and the required hardware (components, console, games, etc).

Bot designs

NESBot was the first bot that was publicly announced and was created by micro500. This bot can be built by following the Instructables NESBot guide created by micro500. The basic steps, based off the article, are as follows:
  1. Build the circuit given in the guide.
  2. Load FCEUX and the rom for the game you want to use.
  3. Load the Lua script given in the guide and run it.
  4. Download the .fm2 file for the movie you want and start playback in the emulator.
  5. Let the movie playback until completion or for as long as you would like, then stop the Lua script.
  6. Upload the file the Lua script creates onto the bot.
  7. Load the game cartridge into the console and make sure it starts correctly.
  8. Activate the bot and turn on the console.

Later, true released his NES / SNES Replay Device which was capable of playing back both NES and SNES games. This is the version that was used during AGDQ 2014 and was also employed during AGDQ 2015 for Pokemon Red / Pokemon Plays Twitch.

micro500 followed this up with his N64Bot which was used for the MK64 run at AGDQ 2014.

In 2014, true released his MultiReplay board which added Genesis, SMS, and other platform support and incorporated a built-in display. This version was used during AGDQ 2015 for SMB on SMW.

TASBot as a person (from the perspective of dwangoAC)

When true released his board he called it true's NES / SNES Replay Device. I subsequently hacked together a Lego case and put it on ROB and dubbed it ROBBerry Pi. Then, due to being frazzled because of last-minute issues and being in front of 60,000 people I proceeded to do an absolutely horrible job of introducing who TASVideos was, who I was, and what the name of the bot was. Later, GDQMonitor and Masterjun's SMW executes arbitrary code submission both referred to the combination of true's replay board, the Pi, and ROB as "TASBot". (As an aside, there was previously an unrelated project named TASBOT but no new development appears to have happened on it since 2013)

TASBot as a "person" has become something far larger than I ever imagined. There's fanfic out there about @GDQMonitor (apparently a girl) and @MrTASBot having an ongoing relationship. The SDA community seems to refer to TASBot about the same way the Nico Nico Douga community references TAS-san (TASさん, known as "Mr. TAS"). I know true has never particularly felt comfortable with calling his board "TASBot" and at this point I think the name transcends any particular replay device. I've come to think of TASBot as the combination of ROB holding a controller or board and participating in his favorite pastime, playing games perfectly in front of a TV and a loving audience. What could be better?

NES controller technical information

An NES controller is simply a shift register, with the 8 inputs being the 8 buttons on the controller. When a game is looking for input from a controller, a pulse is sent to the controller. When the shift register receives this pulse, the state of the 8 buttons are read in and stored until the game reads them in one button at a time. Some games read in the button state once per frame, while others read them in multiple times per frame. A game is not required to read in input every frame however, and will commonly not read in input for some frames to allow time to handle other things such as changing the screen. Due to a hardware problem, using the PCM channel of the NES to output sound causes random invalid button presses to be read in. Games that use this channel commonly read in the button state multiple times to find which buttons are valid.

In FCEUX input from the user is read once per frame and "held" until the next frame. The emulator doesn't care how many times per frame the game asks for input; it gives it the same input each time in the same frame. The emulator also accepts and saves buttons which are pressed even when the game doesn't ask for them.

To play back movies on the console, the recorded buttons need to be modified to remove buttons pressed when the game isn't asking for any. The remaining buttons need to be pressed and held for the correct frame for the console to read them in correctly. To accomplish this, a micro-controller was wired to a shift register and the pulse from the console was sent to both the micro-controller and the shift register. With each pulse, the micro-controller changes the "button" signals sent to the shift register, according to the movie uploaded to it.

SNES

To be added.

SMS

To be added.

Genesis

To be added.

N64

To be added.

Game Boy Advance

To be added.


Combined RSS Feed
ConsoleVerificationGuide last edited by Spikestuff on 2015-03-26 02:49:35
Page info and history | Latest diff | List referrers | View Source