I'd like to provide some updates and additional information that I know of regarding some of the named consoles, as I've been working on my own replay device recently.
NES: There's definitely a lot of NES games that are available to be verified. ViGreyTech and myself have very recently begun to grind out verifications for this console. Some games are much harder to verify than others, and it's not always easy to nail down what is causing a desync. The easiest games are those that don't employ DPCM (Delta PCM audio), don't have their reset vector point to the same location as power-on, don't use save files (aka SRAM), and don't base their RNG on uninitialized system RAM. Some of these hurdles can be overcome more easily than others.
DPCM will cause the console to poll input multiple times in one frame. The replay device must be able to detect these extra latches, and repeat the inputs, instead of advancing a frame as it normally would. This is also known as "window filtering" or "latch windows". The typical period allotted to a window is about 8ms, which is about half a frame. Meaning any latch+clock polls from the beginning of the frame, over 8ms, will get the same input values. Games that use save files or save data of some kind, can be verified by either using a programmer to clear memory, using a flash cart, or maybe by removing the battery (if it is battery-backed). Some games may work by just deleting the save file normally in-game, but this doesn't always clear all necessary data.
On some games, when you press the console reset button, it will reset to a point after the splash/intro screen(s), which usually desyncs the run. This is trickier to get around, and the solution depends on the replay device in use, and how you are loading the game (physical cart vs flash cart). On a real/repro cart, if the replay device supports it, you can start from console power-on. Flash carts are much trickier. I believe it's possible to start a run from the menu of a flash cart, if the right number of blank frames are inserted before the actual TAS, or otherwise detecting when the game actually starts (such as looking for long periods of no input polls). On the Everdrive N8 for example, I've noticed that a different amount of input frames will happen depending on which game you play.
Uninitialized system RAM is the hardest difficulty. ViGreyTech has developed a ROM that can initialize RAM, and then hold the console in a loop so that the user can swap out that ROM with the real game cartridge, and reset from there. However, it hasn't been tested whether this would work when using a flash cart for the game. There may also be some way to change the flash cart's firmware/software to initialize RAM just before starting up a game.
There is also a chance for random, extraneous, clock pulses during an input poll. This is fixed by using "clock filtering". Upon seeing a clock pulse, a replay device will ignore all new clock pulses for a set amount of time. The value needed can vary. Usually 2-4us is plenty.
N64: Like Alyosha said, this console really boils down to inaccurate emulators. The only reason that SM64 and MK64 are reliably verifiable, is because of a rare way in which they handle inputs. While the N64 effectively uses a single clock source (though the CPU is scaled up from it), there are multiple components which can run different tasks at the same time as each other. But most importantly, the way laggy frames are handled can easily desync runs if emulators aren't accurate enough.
According to fraser from the N64 homebrew community: The SDK used to create N64 games will use the Video Interface interrupt to trigger a request to get the input state of controllers. Ideally this would happen 60 times per second (60 FPS, or 16.66ms per frame), but in practice it turned out to be more like 20-30 FPS when lag frames are taken into account. The request will be sent to the Peripheral Interface (aka PIF), and returned to system RAM during a different interrupt. While the PIF does that task, the CPU and RCP will be at work with the rest of that frame's processing. If the frame takes too long to render (say, 17ms),
the frame before that, will be rendered again. When this happens, the frame after that, will still poll for input again. At the end of the frame, the previous (17ms) frame's render will finally be displayed. However, because the 17ms frame used the input from when that frame first started, the following frame's input is essentially discarded.
Certain games, like SM64 and MK64 will not poll multiple times after laggy frames, thus lag cannot cause discarded inputs. Bottom line is, either emulators must become far more cycle accurate, or we have to figure out some way to detect when these lag frames occur, and thus which inputs are discarded. The former is likely the most viable option. There are two emulators I know of that are in development, and could become accurate enough for TASing purposes (
https://ares.dev/ and
https://github.com/Dillonb/n64/). CEN64 is not, and will likely never be accurate enough for TASing. It claims to be cycle accurate, but it isn't. MAME is likely the most accurate emulator right now for the console, but to what extent I don't know, and it doesn't have TASing tools.
