The GBI-compatible script for the GameBoy and GameBoy Color can be found here. GameBoy Advance script details are found here.

Bigbass has written scripts for use with Bizhawk and FCEUX that dump to the .r08 format.

Some much older scripts can also be found 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).

A few scripts for the SNES (.r16m format) can be found here. The latest builds of the lsnes emulator now have built-in dump support.

NES controllers internally are just simple 8-bit shift registers, controlled by the game reading/writing to special memory-mapped registers. Each controller port contains a latch (LAT), clock (CLK), and serial data (SER or DAT or OUT) signal pin, as well as power, ground, and two other pins that are unused by standard controllers. The latch is shared across ports, so a HIGH signal on the first port's LAT pin will also be HIGH on the second port's LAT pin. The clock is manually pulsed by the game, and each pulse will shift the data in the respective controller by 1 bit. The serial pin is tied to the shift register's current output.

Since NES games are technically able to latch or clock controllers in any order they want, not all games will work the same way. However, in nearly all cases, games will follow the same general order of operations: pulse LAT HIGH for a short period, then alternate between pulsing CLK LOW and reading the current state of the serial data pin, typically 8 times. Some games may latch twice per frame, once for each controller port (even though the latch pin is shared across ports). Some games may poll the first controller before the second, some games the second before the first.

For replay devices, there are two critical mechanics that must be understood: latch filtering and clock filtering.

Most emulators will represent inputs as having only a single state per frame (SubNESHawk is one exception). However, this does not reflect how games actually poll controllers. Quite often games will latch multiple times per frame.

This multiple latching becomes a problem if a replay device believes that each latch is equivalent to each movie frame, in which case the replay will likely desync very early in a game. Historically, dump scripts for emulators would often dump one input value for each frame, rather than for each latch. This means that a replay device needs some way to duplicate input values for games that latch multiple times per frame.

The easiest, albeit not fool-proof, solution is called a latch filter (also referred to as windowed mode). Essentially it's just a length of time, typically 8 milliseconds. After the first latch of a frame, any new latches within that time limit will reset the controller's input state with the same value as the first. Only after the time limit is reached, will the next dumped input be used.

Alternatively, if the dump script dumps inputs based on emulated latches (via a memory watch callback, or SubNESHawk), the latch filter is completely unnecessary and should be disabled. This is also required for verifying some games, because they poll across frame boundaries (e.g. the first few bits are read during one frame, and the remaining bits are read during the next frame).

Notice: The .r08 dump format does NOT differentiate between these two dumping methodologies. There is no way to tell with just an .r08 file whether the inputs represent whole frames, or individual latches.

Games that utilize the NES's DPCM audio, can encounter a bug when polling controllers at the same time a DPCM sample is being played. The bug can randomly cause the CLK pin to pulse an extra time shortly after a real pulse, without the game knowing. Most, but not all, games will deal with this by continually polling the controller until two successive polls return the same value. This could be mitigated by using a latch filter, but that won't be possible or helpful in all cases.

Instead, a replay device should ignore all additional clock pulses for some amount of time, typically 4 microseconds, after each initial pulse.

TODO

TODO

TODO

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 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 allowing 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) 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 a 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.

TODO

TODO