Blog

If you’ve ever tried to get two-player Atari paddle games working on modern hardware, you know the frustration. Maybe it’s MiSTer FPGA where Player 2 is completely invisible. Maybe it’s RetroArch where you spent an hour buried in input configuration menus trying to map the Y axis to a second virtual player. Maybe it’s a standalone emulator that simply doesn’t support two paddles on one gamepad at all.

Your paddles are fine. Your adapter is fine. The problem is how USB adapters have traditionally reported paddle data — and it creates headaches on virtually every platform. Some emulators can work around it with enough manual configuration. Most can’t. And even when they can, the process is error-prone, poorly documented, and different for every emulator. Until now, nobody has solved this at the adapter level where it belongs.

The Problem: Two Paddles, One Gamepad

Atari paddles come in pairs. A single DE-9 connector carries two paddles — each with its own potentiometer and fire button — sharing the same port. The original 2600 handled this natively because it was designed around this exact hardware. Paddle A and Paddle B were simply two separate inputs on the same controller port.

When USB adapters came along, they had to translate this into something a modern computer could understand. The standard approach became: map Paddle A to the X axis of a gamepad, Paddle B to the Y axis, and the two fire buttons to buttons 0 and 1. One physical port, one USB gamepad, two axes. Simple, clean, and it works — for emulators that know how to read it.

Even emulators that theoretically support this — like RetroArch or Stella — aren’t straightforward. You might get lucky after spending hours digging through input configuration menus, remapping axes, and praying it sticks between sessions. And then you update the emulator or switch cores and get to do it all over again. The reality is that no platform handles the “two paddles on one gamepad” approach gracefully.

Why Most Platforms Struggle with Dual Paddles

The root of the problem is simple: most platforms expect one gamepad per player.

MiSTer FPGA’s Atari cores expect Player 1 on gamepad 1’s X axis and Player 2 on gamepad 2’s X axis. It never looks at the Y axis for a second paddle — it looks for a second USB device entirely. Player 2 is completely invisible.

But MiSTer is just the most obvious example. The same issue appears everywhere:

• RetroArch can technically handle it, but you have to manually configure input remapping to bind the Y axis of gamepad 1 to Player 2’s paddle input. The process is buried in nested menus, varies by core, and resets if you change controllers. Most users never get it working.
• RetroPie inherits RetroArch’s complexity and adds its own layer of input configuration on top. Getting dual paddles working often means editing config files by hand.
• Standalone emulators like Atari800 or MAME each have their own input mapping systems, each with different assumptions about how paddles should arrive over USB. What works in one breaks in another.
• FPGA platforms beyond MiSTer — including Analogue devices and other retro FPGA projects — generally follow the one-gamepad-per-player model.

The common thread is that every platform requires you to solve the same problem from the receiving end, with platform-specific configuration that’s fragile, frustrating, and easy to get wrong. Change your adapter, update your emulator, or switch platforms, and you’re starting over.

The real fix belongs at the source — in the adapter itself.

Our Solution: Split Mode

The iCode Duo Ultimate Adapter now includes a Dual Paddles setting with two modes: Combined and Split.

Combined is the traditional behavior. Both paddles from a port map to the same USB gamepad — Paddle A on X, Paddle B on Y, fire buttons on buttons 0 and 1. This is the default and may work on some emulators with manual input configuration — if you have the patience.

Split solves the compatibility problem at the source. When activated, the adapter remaps the paddle data across both USB gamepads:

Every platform — MiSTer, RetroArch, RetroPie, MAME, standalone emulators, FPGA devices — now sees exactly what it expects: two independent controllers, each with a paddle on the X axis. Player 1 and Player 2 just work. No input remapping, no config file editing, no per-emulator workarounds. Flip one setting on the adapter and you’re done.

What About Four Paddles?

This is where it gets interesting. If you have paddles connected to both ports — the full four-paddle setup for games like Warlords — Split mode handles that too.

Gamepad 1 carries both “A” paddles, Gamepad 2 carries both “B” paddles. Platforms that expect one paddle per gamepad pick up Players 1 and 2 from the X axes automatically, and emulators that support four paddles can read all four from the two gamepads.

The adapter intelligently manages this — Split mode only activates when both ports actually have paddles available. If you’ve got a joystick on Port 1 and paddles on Port 0, the adapter stays in Combined mode regardless of the setting. No conflicts, no confusion.

Settings Follow the Destination

One design decision we’re particularly happy with is how settings work in Split mode. Each USB gamepad’s paddle behavior — resolution, jitter control, button mapping — is controlled by the port settings for that gamepad’s slot. Gamepad 1 uses Port 1’s settings, Gamepad 2 uses Port 2’s settings.

This means you can configure each player’s paddle experience independently through the menu, and the settings make intuitive sense: what you configure under “Port 1” always controls what comes out of USB Gamepad 1, regardless of which physical paddle is being mapped there.

Stick + Paddles Still Works

For Stick+Paddles mode, Split works seamlessly alongside digital joystick input. The joystick from Port 0 routes to Gamepad 1, and the joystick from Port 1 routes to Gamepad 2 — exactly where you’d expect them. The paddle split only affects the analog data and fire buttons, so your digital controls remain unchanged.

How to Enable It

That’s it. No reboot required, no firmware changes, and — most importantly — no configuration needed on the emulator side. No input remapping in RetroArch, no config file editing in RetroPie, no per-core setup on MiSTer. The adapter sends the data the right way from the start, so every platform just works.

The Bigger Picture

This is part of our ongoing effort to make the iCode Duo Ultimate Adapter work everywhere, not just in the most common setups. Paddle support has always been a pain point for the retro gaming community — between jitter issues, calibration problems, and now platform compatibility — and we’ve been systematically knocking down every barrier.

Combined with our four-stage jitter elimination pipeline, auto-calibration, and adjustable resolution control, Split mode means Atari paddles finally work the way they should on every platform. Whether you’re playing Breakout on RetroArch or Warlords on MiSTer, the iCode Ultimate Adapter handles it — and your paddles just feel right.

If you’ve ever plugged vintage Atari paddles into a USB adapter and watched your on-screen paddle twitch and dance while sitting perfectly still, you’ve experienced paddle jitter. It’s the number one complaint from retro gamers trying to play Breakout, Kaboom!, or Warlords on modern hardware. But what actually causes it — and can it be fixed?

We spent months studying the problem at the hardware level, and built a multi-stage signal processing pipeline into the iCode Ultimate Adapter that eliminates jitter while preserving the instant, zero-lag response that makes paddle games feel right. Here’s how it works.

The Root Cause: RC Timing and Analog Noise

Atari paddles aren’t digital devices. Each paddle contains a 1-megaohm potentiometer — a variable resistor that changes based on the knob’s position. The original Atari 2600 read this resistance using an RC (resistor-capacitor) timing circuit: charge a capacitor through the paddle’s resistance, and measure how long it takes. High resistance (knob turned one way) means a long charge time; low resistance (the other way) means a short one.

Modern adapters replicate this same RC timing approach. The microcontroller discharges a capacitor, then counts how many microseconds it takes to charge back up through the paddle. That count — the RC time — becomes the paddle’s position value.

The problem? Analog circuits are inherently noisy. The capacitor’s charge time fluctuates by a few counts every single read. Temperature, component tolerances, electrical interference from the USB bus, and even the age of the potentiometer all contribute. On a 40-year-old paddle with worn carbon traces, the noise can be significant. And unlike a digital joystick where you’re either on or off, even a 1–2 count fluctuation in RC time translates to visible on-screen jitter.

Dirty or worn paddles make it worse. A momentary loss of contact — common with oxidized wiper contacts — causes the RC time to spike wildly before snapping back. Traditional adapters faithfully pass these glitches straight through to the game, resulting in the paddle teleporting across the screen and back in a single frame.

Our Approach: A Four-Stage Signal Pipeline

Rather than applying a single heavy-handed filter that kills responsiveness, we built a pipeline of four lightweight stages. Each one targets a specific type of noise, and together they produce a clean, stable signal with effectively zero added latency for real paddle movement.

Stage 1: Spike Rejection

This is our defense against dirty contacts. If a reading jumps more than 50% from the previous value in a single frame, we throw it away entirely. Real paddle movement is smooth and continuous — even the fastest flick of the wrist produces a gradual ramp across multiple readings. A spike from a dirty wiper contact, on the other hand, appears as an instantaneous jump with no ramp.

By rejecting these outliers at the source, we prevent them from corrupting everything downstream. The paddle simply holds its last known good position for that frame, and resumes tracking normally on the very next read. In practice, this is completely invisible — you can’t perceive a single skipped frame at 1000+ reads per second.

Stage 2: Moving Average

To understand why this works so well, we need to talk about capacitors.

The original Atari 2600 used a 68nF capacitor in its RC timing circuit. Combined with the paddle’s 1-megaohm potentiometer, this meant each read cycle took long enough that the console could only squeeze in a single scan per frame — and at 60 frames per second, that was it. One reading, one chance, take it or leave it. Atari’s engineers knew this was noisy, which is partly why they clipped the paddle range so aggressively. Less range meant less time per scan, which helped keep things within the tight timing budget of the TIA chip.

When Atari moved to their 8-bit computer line (the 400/800 series), they switched to a 47nF capacitor — smaller, faster charge times, slightly better performance. But the fundamental constraint remained: one scan per frame, no room for averaging.

The iCode Ultimate Adapter breaks this limitation entirely. We use a 22nF capacitor — roughly a third the size of the original 2600’s. Combined with the RP2350 microcontroller running at 150MHz (compared to the 2600’s 1.19MHz), each RC scan completes in a fraction of the time. Where the Atari could barely fit one scan into a frame, we can comfortably perform four complete scans in the same window — with time to spare and zero additional lag.

This is what makes our 4-sample moving average practical. Every output value is the average of four independent RC readings taken in rapid succession. Random analog noise — those 1–2 count fluctuations from electrical interference, temperature drift, and component variation — cancels itself out across the four samples. Real paddle movement, which is consistent across all four reads, passes through cleanly.

The result is a noise floor that’s effectively halved compared to a single-scan approach, with no perceptible latency added. Four samples at our scan rate span just a few milliseconds — far below the threshold of human perception, but enough to tame the analog noise that plagues every other adapter on the market.

Stage 3: Hysteresis (Jitter Control)

This is where the remaining low-frequency drift gets eliminated. Even after averaging, the signal might wobble by a few counts when the paddle is sitting still. Hysteresis solves this by requiring the value to change by more than a configurable threshold before we update the output.

Think of it like a deadband around the current position. If the paddle’s stable RC time is 1000 and the threshold is 8, readings between 992 and 1008 are ignored. The moment you actually turn the knob and the value hits 1009, the new position passes through immediately — no delay, no lag. It only suppresses the idle wobble.

We expose this as a user-adjustable setting with six levels. Different paddles have different noise characteristics, so what works perfectly for a pristine set of Atari CX30s might need a higher setting for a well-loved pair from 1978. Most users find the Low setting eliminates all visible jitter without affecting gameplay feel.

Stage 4: Auto-Calibration

The final stage maps the filtered RC time to the 0–254 output range that games expect. Rather than using fixed conversion values, we continuously track the actual minimum and maximum RC times seen from each paddle. This means the adapter automatically adjusts to any paddle — regardless of component tolerances, capacitor quality, or manufacturing variations.

The calibration range only grows, never shrinks, so it can’t be corrupted by a single bad reading (those were already caught by spike rejection). If a paddle’s true range is 200 to 1400, that’s the range we map — not some hardcoded guess that might clip your paddle’s travel or leave dead zones at the ends.

Resolution Control: Matching the Atari Feel

There’s one more piece of the puzzle that experienced Atari players appreciate. The original 2600 didn’t use the full range of the potentiometer — it clipped the RC timing at roughly 60–80% of the paddle’s physical travel. This meant you only needed a small wrist movement to cover the entire screen, giving paddles their characteristic snappy, responsive feel.

Our Resolution setting replicates this by controlling how much of the RC timing range maps to full output. At 50%, a small physical movement covers the whole screen — fast and twitchy, just like the original hardware. At 100%, you get the full range for fine-grained precision. The default of 80% matches the feel most players remember from their Atari 2600.

Because this clipping also determines when the RC timing loop can exit early, lower resolution settings actually improve adapter performance — the microcontroller spends less time waiting for each read cycle, leaving more headroom for everything else.

The Result

The combination of these techniques — spike rejection, moving average, hysteresis, and auto-calibration — produces a signal that’s rock-solid when idle and instantly responsive when you move. No jitter, no teleporting, no dead zones, and no perceptible lag.

Every stage is lightweight by design. There’s no heavy digital filtering that mushes your inputs, no prediction algorithms that guess where you’re going, and no frame buffering that adds delay. The pipeline processes each reading in microseconds, and the result is a paddle experience that feels exactly like the original hardware — just without the noise.

Whether you’re threading the needle in Breakout, dodging bombs in Kaboom!, or battling friends in Warlords, the iCode Ultimate Adapter lets vintage Atari paddles perform the way they were always meant to.