{"id":2507,"date":"2019-09-02T14:48:46","date_gmt":"2019-09-02T05:48:46","guid":{"rendered":"https:\/\/www.codedojo.com\/?p=2507"},"modified":"2020-06-11T22:41:00","modified_gmt":"2020-06-11T13:41:00","slug":"input-lag-fun-measuring-atari-2600-latency-from-controller-to-display-with-an-arduino","status":"publish","type":"post","link":"https:\/\/www.codedojo.com\/?p=2507","title":{"rendered":"Input lag fun – measuring Atari 2600 latency from controller to display with an Arduino"},"content":{"rendered":"

\"\"<\/a><\/p>\n

Input lag.\u00a0 It’s a catch-all name people use when talking about the latency that gets added in the various places between when you push a button and finally see results on your screen.<\/p>\n

Many (especially console) games these days are designed to hide it because the developers cannot predict the latency of the display device the player is using.<\/p>\n

There are often additional considerations such as video drivers, vsync, “Game mode” display options, refresh rate, back buffering and dealing with high latency wireless controllers.<\/p>\n

If I add 100 milliseconds of additional lag to Red Dead Redemption 2, I’d doubt you’d notice with its mushy-ass controls.\u00a0 But if you try that with old school platformers and bullet hells designed for ultra-low lag, well, it ain’t gonna be pretty.<\/p>\n

If you’re skeptical of the difference input lag can make, try this:<\/h1>\n
\"\"<\/a>

Super Mario Bros. 2 (Japan) is just mean. See that mushroom? It kills you!<\/p><\/div>\n

Play the murderous Super Mario Brothers 2 (Japan) directly from a Famicom on an old school CRT and then try the same thing on your Raspberry Pi, PC, or even the same NES console through an upscaler\/LCD tv.<\/p>\n

As you switch back and forth you’ll probably feel the difference.\u00a0 The game is more difficult and less comfortable<\/em> with the extra lag.<\/p>\n

It’s not just about reaction times<\/strong> – there is this thing your brain does where it’s forced to jump and move slightly earlier than the onscreen action.\u00a0 We can all automatically do it, sure, but it’s… different.\u00a0 It doesn’t feel as connected.\u00a0 It’s too.. I don’t know, milky.\u00a0 A lot depends on the number of frames missed as well as when the console polls. (for example, the Atari 2600 polls 30 times a second, during the vertical blank interrupt but )<\/p>\n

This goes for much of the 8 and 16 bit action content from consoles and computers of yesteryear.<\/p>\n

So real hardware and CRTs are the only way to go for fast response controls?<\/h1>\n

Woah, settle down, I didn’t say that!\u00a0 Retro emulation is astonishing and with the right gear and settings it should<\/em> be possible to match or even beat old-school latency in specific cases such as with Run Ahead<\/a> on the NES.<\/p>\n

That said, I have not been able to do it yet with my setups.\u00a0 Additionally, there are sometimes trade-offs like screen tearing and visual artifacts when you’re aiming at ultra-low latency.\u00a0 I’m sure things will continue to improve given the recent focus on reducing input lag on both displays and controllers.<\/p>\n

(Note: I was going to say “twitch gaming”\u00a0 instead of “fast response controls” but I’m guessing that term is too ambiguous these days)<\/em><\/p>\n

Measuring input lag accurately<\/h1>\n

Instead of getting lost in subjective testing by “feel”, let’s get scientific about it.\u00a0 For my purposes, I wanted to measure the exact latency between a button press on an Atari 2600 console and the display pixels changing.\u00a0 The full trip.<\/p>\n

<disclaimer – I’m an electronics amateur and don’t know what I’m doing.\u00a0 Breaking stuff is how you learn, right?>\u00a0<\/em><\/p>\n

I used a cheap Arduino Uno with an LCD\/button shield (they call things you stick on them shields, ok?) to do it.\u00a0 It’s so simple you don’t even need a breadboard!<\/p>\n

\"\"<\/a><\/p>\n

The light sensor<\/h1>\n

First I wired up an LDR (Light Dependent Resistor) to the board’s analog in pin A0, and connected the other end to the ground.\u00a0 We can now detect light with a analogRead(A0) command.\u00a0 Oh right, I also put a 100K resistor in there.<\/p>\n

\"\"<\/a><\/p>\n

To get the light sensor to physically stick on the screen (so it will hover over the pixels in question) I commandeered the suction cup that came in a iFixit kit and glue-gunned a rubber earbud cover to house it.<\/p>\n

Just nod and smile please, without commenting how there is glue everywhere and it looks ridiculous.<\/p>\n

My light sensor returns a number between 300 and 1024 or so.\u00a0 When stuck onto a monitor more like 800 to 1000 (black and white… black pixels still have a lot of light coming through I guess) but good enough.<\/p>\n

Getting the Arduino Uno to push the Atari fire button digitally<\/h1>\n

Next I cut the cable off a broken Atari 2600 controller (it was a cheap clone from Ebay that I broken during a particularly exuberant C64 performance) and using this diagram<\/a> figured out the wires for the fire button and ground.<\/p>\n

I connected the controller ground wire to the Arduino’s ground pin, then the fire button wire in the D2 pin.\u00a0 I can now control the fire button like this:<\/p>\n

 pinMode(C_ATARI_BUTTON_PIN, OUTPUT);\n\n\/\/To turn button off\n digitalWrite(C_ATARI_BUTTON_PIN, HIGH);\n\n\/\/To turn the button on\n digitalWrite(C_ATARI_BUTTON_PIN, LOW);<\/pre>\n
I didn’t know you could directly wire it like that, mixing the 5v high signals from both the Atari and Arduino, but whatever, it works.\u00a0 Read this post by BigO<\/a> to understand why setting it to LOW causes it to be “on” as far as the Atari is concerned.<\/p>\n
I noticed if the Arduino is NOT powered buts its joystick lead is plugged into the Atari, there are weird video glitches.\u00a0 I guess due to the unpowered Arduino draining amperage from the fire button lead, enough to cause fluctuations in the entire system?\u00a0 Ignore any smoke, move along.<\/p>\n
Adding support for more buttons would be as easy as plugging the additional wires into more Arduino pins.\u00a0 In the picture of the whole device above, it’s only the Red and Yellow wires I’m using, the blue\/white ones aren’t connected to anything.<\/p>\n
The code<\/h1>\n
All that’s left is to write some code so the device can be controlled with the LCD shield’s buttons.\u00a0 \u00a0Here’s what those buttons do:<\/p>\n
    \n
  • Select – Show current light level reading<\/li>\n
  • Left – Nothing<\/li>\n
  • Up – Increase light change timing required to trigger<\/li>\n
  • Down – decrease light change time required to trigger<\/li>\n
  • Right – Start measuring.\u00a0 (Will cause the Atari’s fire button to click, then it waits until the light has changed enough.<\/li>\n<\/ul>\n
    Here is the code for the Arduino sketch.<\/a> (I did all this in a messy few hours, don’t judge me)<\/p>\n
    Tip:<\/strong> I leave the button in the “pressed” state for 100 MS (I guess 33.333 MS would technically be enough for an Atari 2600, but whatever, doesn’t matter), and I look for about a 60 change from the light sensor to count as “hey, this part of the screen has\u00a0 definitely changed, stop the timer, we’re there”.<\/p>\n
    \n
    Blog: Input lag fun – measuring Atari 2600 latency from controller to display with an Arduino https:\/\/t.co\/XEMarxuzSJ<\/a> pic.twitter.com\/KlpYkLMTow<\/a><\/p>\n
    — Seth A. Robinson (@rtsoft) September 2, 2019<\/a><\/p><\/blockquote>\n