Hacker News Reader

Comment by crankylinuxuser | Hacker News Reader

Maybe someone smarter than me can explain this:

"Also, in a bizarre move, Nintendo didn't use the traditional "one side pulled-up other side to ground" way of reading buttons, instead they used a keypad configuration where buttons are arranged in rows and columns. They used the keypad scanner built-in inside the BCM20734 with 128KHz clock for reading the buttons. That means it would be extremely hard to spoof button presses for TAS and twitch-plays. Maybe the Pro controller is different, need to buy one though."

Why would a 128KHz polling prevent spoofed button presses? Seems like a NPN transistor could easily spoof that - if TAS players are looking at that. Or am I just missing something how TAS players do it now?

View on HN

I didn't think TAS or Twitch Plays used real hardware anyways.

Console verification is an important part of ensuring TASes are accurate. For that, we need an interface into the console's controls among other things.

Well, given that this controller talks bluetooth, wouldn't a logical way to control the input be to write a BT stack that emulates the controller?

I know its not the legit real controller, but buttons are buttons (analog or digital). As long as you don't mod the console itself, that should be fine for the TAS community, no?

I'm curious about this too. There's also a physical connection between the joycons and tablet which can be used instead of the Bluetooth.

I believe the main issue is that it's very easy to electrically simulate button presses and be confident that the rest of the system is functioning correctly. Once you start simulating the entire controller and its protocol for communicating with the console, you start to enter a realm where it may be possible to trigger inputs that are not physically possible with the actual controller hardware.

I'd assume for precise play/speedruns you'd use the controller in the physically connected mode, not over Bluetooth? (with random delays potentially)

They've been doing tool-assisted runs on real hardware for a while now:

http://tasvideos.org/TASBot.html

In addition to TASBot, there's also a growing practice of using physical rigs to "verify" tool-assisted runs:

http://tasvideos.org/ConsoleVerificationGuide.html

This isn't generally regarded as necessary for a TAS to be valid, but it allows it to work on TASBot and similar rigs, which can help it get in front of a wider audience. It also helps figure out which TAS techniques are theoretically possible in non-TAS runs.

the importance of console verification is to make sure a TAS isn't relying on any emulator bugs (such as timing, uninitialized memory, etc) and would theoretically be possible on the actual hardware. it also speaks to the accuracy of the emulations themselves

Neat, I've always been into speed running, but my neighbour introduced me to TAS not too long ago.

This is all super cool, thanks everyone.

For a specific example of something like this being important, remember the (very impressive) Watch for Rolling Rocks in 0.5 A presses video from a couple years ago? https://www.youtube.com/watch?v=kpk2tdsPh0A (For the uninitiated, this video presents a TAS of Super Mario 64 which beats the level Watch for Rolling Rocks without pressing the A button outside of keeping it held from entering the level.) It turns out that the route presented in the video actually fails console verification, since the crazy things he does trigger some annoying FPU crashes on console, but not on emulator. There is a happy end, though: a fixed route was published after this was discovered, and it passes console verification just fine (assuming the inputs dont desync over the 13 hour run)

answer is simple - author doesnt know about transistors, maybe started learning electronics with Arduino or some other end more important than the means tools.

Reply on news.ycombinator.com