4 ms·

Thank you. I imagine not all Technology Assisted Speed-run techniques are even possible on original hardware, even if you’re pumping electrical input directly

Thank you. I imagine not all Technology Assisted Speed-run techniques are even possible on original hardware, even if you’re pumping electrical input directly into the controller port, since the TAS ‘implementation’ or ‘driver’ would depend on the cycle-correctness of the emulator used to record the inputs, the literal physics in terms of analog input, etc....? What a fascinating topic. Are there any good starting points you can think of to explore it more? This is pretty awesome, for example: “TAS replay device hidden in NES controller” https://www.reddit.com/r/speedrun/comments/kewjhd/tas_replay_device_hidden_in_nes_controller/ https://www.reddit.com/r/speedrun/comments/kewjhd/tas_replay...

toast0 1y ago
You might look at the tas videos that have been console verified and use arbitrary code execution [1], especially look at the submission notes and forum threads. I think you might conceivably have trouble with running TAS replays on consoles on the Atari 2600, since the inputs on that are just direct pins and afaik, there's no way for the controller to know it's been read. The NES input is a serial read, so a smart controller can use that to sync up playback. That said, I did see an Atari 2600 console verified TAS for Dragster, so there must be a way to sync. Once you've synchronized the controller playback to the console, the only limitation on playback would be how accurate the emulator is, and/or if there's anything that's not really reproducible. On the NES, there's no source of real randomness, but some (many?) of the games don't clear all the ram at boot, so you could have residual data if the system hasn't been off for long enough (there's some fun things you can do with cartridge swaps on real hardware); that one is solvable by making sure your TAS goes from an appropriate RAM off state, and that you leave the console off for long enough that RAM decays all the way. Also on the NES, the CPU and PPU have different clock rates (they both run from the master clock, but with different dividers) and there's different ways the clocks can align, which can result in different behavior especially at the limits. My understanding is that most emulators pick one alignment and emulate that, but if your TAS timing is very tricky, you might have to run multiple trials before you got the alignment you want. Clock alignment is a deep topic, but this should get you started [2]. Newer consoles may have more features that are effectively non-deterministic, which could make TAS harder. Addressable ROMs have essentially fixed access times, but optical media, spinning hard drives and flash memories typically don't; this can lead to unpredictable delays that make TAS on real hardware more difficult. See also TASBot [3] and TAStm32 [4] [1] https://tasvideos.org/Movies-ace-verified https://tasvideos.org/Movies-ace-verified [2] https://forums.nesdev.org/viewtopic.php?t=6186 https://forums.nesdev.org/viewtopic.php?t=6186 [3] https://tas.bot/wiki/Main_Page https://tas.bot/wiki/Main_Page [4] https://github.com/Ownasaurus/TAStm32 https://github.com/Ownasaurus/TAStm32

toast0 1y ago

You might look at the tas videos that have been console verified and use arbitrary code execution [1], especially look at the submission notes and forum threads. I think you might conceivably have trouble with running TAS replays on consoles on the Atari 2600, since the inputs on that are just direct pins and afaik, there's no way for the controller to know it's been read. The NES input is a serial read, so a smart controller can use that to sync up playback. That said, I did see an Atari 2600 console verified TAS for Dragster, so there must be a way to sync. Once you've synchronized the controller playback to the console, the only limitation on playback would be how accurate the emulator is, and/or if there's anything that's not really reproducible. On the NES, there's no source of real randomness, but some (many?) of the games don't clear all the ram at boot, so you could have residual data if the system hasn't been off for long enough (there's some fun things you can do with cartridge swaps on real hardware); that one is solvable by making sure your TAS goes from an appropriate RAM off state, and that you leave the console off for long enough that RAM decays all the way. Also on the NES, the CPU and PPU have different clock rates (they both run from the master clock, but with different dividers) and there's different ways the clocks can align, which can result in different behavior especially at the limits. My understanding is that most emulators pick one alignment and emulate that, but if your TAS timing is very tricky, you might have to run multiple trials before you got the alignment you want. Clock alignment is a deep topic, but this should get you started [2]. Newer consoles may have more features that are effectively non-deterministic, which could make TAS harder. Addressable ROMs have essentially fixed access times, but optical media, spinning hard drives and flash memories typically don't; this can lead to unpredictable delays that make TAS on real hardware more difficult. See also TASBot [3] and TAStm32 [4] [1] https://tasvideos.org/Movies-ace-verified https://tasvideos.org/Movies-ace-verified [2] https://forums.nesdev.org/viewtopic.php?t=6186 https://forums.nesdev.org/viewtopic.php?t=6186 [3] https://tas.bot/wiki/Main_Page https://tas.bot/wiki/Main_Page [4] https://github.com/Ownasaurus/TAStm32 https://github.com/Ownasaurus/TAStm32