Revision (current)
Last Updated by adelikat on 8/19/2022 1:48 AM
[Console Verified Movies] | [Console Verification Tests]
This guide will explain how console verification works and take you through the steps to play back movies on physical consoles.
%%TOC%%
!!! Introduction
Verifying a TAS on console consists of a TAS movie file (.bk2, .fm2, etc.), typically a Lua "dump" script, a replay device that emulates the controller, and the console itself. In order for a replay device to know when to supply the next controller input, it uses some method of staying in sync with the console. The most common method is to keep track of when the console polls the controller, but not all consoles behave this way, so alternative methods like monitoring VSYNC or counting clock cycles is necessary.
TAS movies are almost always made in an emulator, and the emulator decides how to save those inputs. Often, this is not directly compatible with how controllers actually work, or how the replay device stays in sync. Because of this, the movie inputs must be filtered for only the information the replay device truly needs. This is where dump scripts come in.
While playing the TAS movie in an emulator, a script (usually in Lua) is used to gather the information needed by the replay device. What this involves will depend greatly on the console in question, and may be affected by game-specific quirks. On rare occasions, an emulator may produce a TAS movie which already provides the proper inputs needed for verification, in this case a dump script is not typically needed (mupen64 movies are an example of this).
Usually, the main issue is that emulators will save inputs based on frames, even if the console doesn't actually poll/read any controller inputs during the frame. If the replay device relies on the polling sequence for staying in sync, these extra inputs in the TAS movie need to be filtered out. Or sometimes games will poll multiple times per frame, while the emulator only saves a single input for each frame.
----
!!! Dumping
Once the inputs have been dumped from a TAS movie, they need to be stored in a structured file format so that replay devices (and the software that interfaces with them) can easily read the necessary information. Historically, these dump formats have been largely inadequate and highly dependent on the replay device being used.
!! Formats
[user:TheMas3212] created the [https://pastebin.com/98eXgnRL|.r08 and .r16m] formats for use with the NES and SNES respectively, however these formats do not differentiate between poll-based and frame-based inputs, and provide no way to specify console resets. Nonetheless, these are the most common publicly available formats for those consoles. For GB/C/A replays, [user:Extrems] created the GameBoyInterface (GBI) software for the GameBoy Player, which uses it's own format for storing inputs based on the number of audio PWM cycles since power-on, and similarly does not support resets or inputs that require more precision.
In 2021, [user:ViGreyTech] and [user:Bigbass] started work on a unified dump format that would be compatible with all consoles, and would provide much more information than just the basic inputs (such as reset handling and attributions). However, this has not been completed yet.
!! Scripts
Only a few scripts are openly/easily available to download. And what scripts exist, aren't always free of bugs or odd quirks which may affect whether or not the dumped inputs actually work on console.
%%TAB_START%%
%%TAB Hide%%
%%TAB GB/C/A%%
The GBI-compatible script for the GameBoy and GameBoy Color can be [https://runs.tas.bot/GBC.html|found here]. GameBoy Advance script details are [https://runs.tas.bot/GBA.html|found here].
%%TAB NES%%
[user:Bigbass] has written scripts for use with Bizhawk and FCEUX that dump to the .r08 format.
%%TAB_START%%
%%TAB Hide%%
%%TAB Bizhawk%%
[https://cdn.discordapp.com/attachments/376529700039688202/946105888547164241/r08-bizhawk.lua|Download script]. Instructions:
# Load rom
# Open Tools > Lua Console
# Open dump script (but do not start it)
# Select the movie in File > Movie > Play movie...
# Do not check the "Stop on frame" or "Last frame" options
# Press ok in the dialog.
# Start the script
%%TAB FCEUX%%
[https://cdn.discordapp.com/attachments/376529700039688202/946093855680397402/r08-fceux.lua|Download script]. Instructions:
# Load rom
# Open Lua Script window, and load dump script
# Optional: Run the script, if it's not already (the game will play, but that's no problem)
# Select the movie in File > Movie > Play movie...
# Do not check/enable the "pause movie at frame" option
# Press ok in the dialog.
# If the script is already running, the dump should begin now. Otherwise, start the script.
%%TAB_END%%
Some much older scripts can also be found [https://github.com/dwangoac/TASBot-Projects/tree/master/Dump_Scripts|here] but the NES scripts are harder to use reliably, and can produce off-by-one dumps under certain circumstances due to Lua API lag-frame quirks (discovered by ViGreyTech).
%%TAB SNES%%
A few scripts for the SNES (.r16m format) can be [https://github.com/dwangoac/TASBot-Projects/tree/master/Dump_Scripts|found here].
%%TAB_END%%
For the moment, finding scripts for any other console is up to you. If you are using a replay device someone else created, which supports the console you're interested in, ask the creator for any script recommendations. They may have scripts tailored specifically to their device. Otherwise you'll need to create your own or find some other method to stay in sync which allows you to use the original movie file.
----
!!! Console Specifics and Protocols
Each console has its own methods for grabbing user inputs, and its own unique quirks which can inhibit verification efforts. Each tab below explains what is known for each console, and includes replay device design strategies.
%%TAB_START%%
%%TAB Hide%%
%%TAB NES%%
__''TODO''__
%%TAB SNES%%
__''TODO''__
%%TAB GB/C%%
__''TODO''__
%%TAB GBA%%
__''TODO''__
%%TAB N64%%
Officially known as the Joybus Protocol, the N64 uses a much more complex polling protocol than other consoles before it. The N64 homebrew community has extensively documented the protocol on [https://n64brew.dev/wiki/Joybus_Protocol|their wiki]. Replay devices only usually need to be concerned with the 0xFF, 0x00, and 0x01 commands for the standard controller. If multiple controllers are used, note that they are polled sequentially, one after the other. Except on the iQue Player, where they are polled in parallel.
The N64 has historically been very difficult to verify TASes on. This is primarily due to poorly implemented emulators that do not emulate timing well enough for console verifications. As such, even as emulators progress, existing TAS publications are unlikely to work. Nevertheless, there are a few games that happen to verify consistently because they poll controllers in an uncommon way, that allows us to ignore timing-related emulator inaccuracies.
As long as the emulator in question properly emulates the game logic with reasonable accuracy, it should be possible to verify TASes for games that only poll controllers based on the game's internal main loop. Games that automatically poll during the Video Interface Interrupt (similar to vsync) on every frame, are significantly less likely to verify.
----
__Lag/Polling Technical Explanation__
All official N64 games, except Namco Museum, use the N64's Reality Coprocessor (RCP) to generate the next video frame. The frame is generated using a list of graphical commands supplied to the RCP (typically) once the game logic has finished updating the game's state. When the RCP finishes creating the frame, the frame is transferred into memory, and then rendered out to a TV by the Video Interface. Games will typically also employ Double Buffering, which means the finished frame is saved to memory that's not being drawn, and then during an interrupt, the buffer is swapped to the new frame.
If the game logic, and/or the RCP, takes too long to generate the next frame, the Video Interface will redraw the previous frame from memory, and will continue to do so until the next frame is ready. In this situation, most games will continue to poll controllers for input on every video frame, even if the game logic has already taken inputs into account and is just waiting for the rest of the process to finish.
Emulators that do not accurately emulate timings, will produce varying number of these "lag frames" and thus in such cases, a replay device will see a different number of controller polls (and a different number of vsync's) than what the emulator thought would occur. Thus a desync will happen.
Rarely, a game such as Super Mario 64, will only poll once per game loop, regardless of how long it takes to generate the next frame. In this case, the replay device can stay in sync. Other games known to verify include only Mario Kart 64, and Mortal Kombat 3.
%%TAB Genesis%%
__''TODO''__
%%TAB A2600%%
__''TODO''__
%%TAB_END%%
----
!!! Replay Devices
Sometimes known as a "bot", a replay device is effectively an electronic device which emulates a controller's behavior (aka [https://en.wikipedia.org/wiki/Hardware_emulation|Hardware Emulation]). However, instead of using physical buttons to convey inputs, it automatically provides a sequential set of inputs from internal memory and/or streamed over USB from a computer.
Replay devices are usually made using a programmable microcontroller. Depending on the demands of a console, 8-bit microcontrollers like PIC or Arduinos can be used, otherwise more powerful devices like 32-bit STM microcontrollers can also be used. It's rarely necessary to use FPGA's, but they have been used before for specific situations.
!! Design History
Many replay devices have been created by a variety of talented people. Below is the known history of replay devices. Note that there are certainly more devices than those included here. More may be added over time.
Around 2011, NESBot was the first device to be publicly announced, which was created by [user:micro500]. They also wrote an [http://www.instructables.com/id/NESBot-Arduino-Powered-Robot-beating-Super-Mario-/|Instructables guide] for creating and using their device. micro500 later also created the [https://github.com/micro500/TASLink|TASLink device] capable of replaying NES, SNES, and N64 TASes.
In 2013, [user:true] released his [http://truecontrol.org|NES / SNES Replay Device] which was capable of playing back both NES and SNES TASes. This is the version that was used during [Forum/Posts/353915|AGDQ 2014] and was also employed during [GamesDoneQuick/AGDQ2015|AGDQ 2015] for Pokemon Red / Pokemon Plays Twitch.
Sometime between micro500's first NESBot and TASLink, they developed the [Forum/Posts/305411|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.
Much later in 2018, [user:tuvok302] (aka TheDot) developed an [https://github.com/tuvok302/TAS_Replay|Arduino-based device] that supports the NES and SNES.
Around February 2019, [user:Ownasaurus] began work on the open-source [https://github.com/Ownasaurus/TAStm32|TAStm32] which has since gone through four major iterations and is still in active development and usage. It supports the NES, SNES, N64, Gamecube, and Genesis. It's the first device to be sold to and actively used by multiple people. It's also been used during many TASBot appearances at GamesDoneQuick and other speedrunning marathons.
In late 2020, [user:Bigbass] started on another open-source replay device, the [https://github.com/bigbass1997/PICTAS|PICTAS] which is still being improved. It currently supports the NES, N64, and Atari 2600. It was used to verify a large portion of the TASes first verified during 2021 and 2022.