POV Pong Mouse

A Real Pong on a Fake Display

POV Pong Mouse does exactly what it says: it runs a game of Pong inside a mouse and renders the graphics by whipping the cursor across the screen fast enough for human persistence of vision to stitch the afterimages into a picture.

It sounds like conceptual art, but it actually works. Two paddles, one ball, one AI opponent — all squeezed into three source files: game_mouse.ino, pong.h, and usbh_helper.h. The physics engine, collision detection, AI logic, USB HID cursor reporting, and the critical POV rendering timing are all packed into a single microcontroller's firmware. No display, no external output. The cursor itself is the pixel. The mouse's movement path is the framebuffer.

This is the purest form of indie hardware hack in 2024: "Can I do this?" followed by actually doing it.

The Hardware Truth: Where Does This Actually Run?

The HN post hit 173 points and 25 comments, but the hottest thread wasn't about the technical implementation — it was a philosophical argument: does this actually count as running inside "the mouse's firmware"?

User nottorp fired the first shot: "It doesn't run on the actual mouse's firmware, it has an extra RP2040 inserted between the mouse board and the computer. Still nifty though." The project doesn't rewrite the stock mouse firmware. Instead, dupontgu cracked open a cheap HP mouse, desoldered the internal USB connection, and wired in a Seeed XIAO (RP2040-based board) that intercepts USB traffic and hijacks cursor control. The original mouse sensor feeds data to the XIAO, which forwards it to the PC while also running a full Pong game.

Author dupontgu's defense was cheerful and lawyerly: "The RP2040 is running firmware. It is inside the mouse. It's now the mouse's firmware!" nottorp conceded: "I can't afford lawyers so you win." freestyle24147 pushed harder, comparing it to swapping a Honda Civic's engine for one with 10x the horsepower, then claiming you achieved 10x "using the Civic's engine."

The real question buried in this debate: when you inject a completely new controller board into existing hardware, where does "firmware" end and "hardware modification" begin? For indie developers, that blurry boundary is exactly the point. You buy a $5 HP mouse, gut it, reroute the USB connections through a $7 XIAO, and suddenly the original sensor becomes a peripheral of your peripheral. Physically, it's still a mouse. Logically, it's something else entirely.

POV Rendering: Fighting Physics with Timing

The hardest part isn't the Pong game — that's textbook stuff. It's the rendering layer that translates game frames into cursor trajectories.

Persistence of vision is simple in principle: move something fast enough and human eyes smear it into a continuous image. But on a mouse cursor, every frame's displacement must be pixel-accurate and locked to the game's tick rate. Move too fast and the picture dissolves into noise. Too slow and the afterimage breaks into disconnected dots. No GPU, no framebuffer, no vsync — you have nothing but microsecond-level timing control in firmware and the tension against USB HID report rates (typically 125Hz–1000Hz).

Every rendered frame is a choreographed sequence of cursor positions. The paddles and ball trajectories get translated into coordinate points delivered to the OS at fixed intervals. The entire "display" is an illusion sculpted in air through timing precision. The fact that it works at all is the engineering achievement.

Who Should Look at This, and Its Honest Limitations

Let's be blunt: zero practical value, and the author knows it. You can't actually play a round of Pong this way. Image quality depends on your monitor's refresh rate and your patience. The AI opponent probably "sees" better than you do, since it doesn't need persistence of vision to track the ball.

But the project's value isn't utility. It's a textbook for three audiences:

Embedded beginners — three files, Arduino framework, native USB HID library. Tiny codebase, but it covers USB protocol handling, interrupt timing, and sensor data passthrough. A complete "take over hardware from scratch" case study. Hardware hackers — the full workflow of cracking open a mouse, soldering jumpers, and stuffing an extra controller into an existing shell. Far lower barrier than designing a PCB from zero. Believers in "if it runs, it ships" — woodrowbarlow on HN suggested porting this to open-source mice like Ploopy, which would be the true endgame of "games inside mouse firmware." numpad0 dreamed further: if cheap mouse sensors themselves could be reprogrammed with a pixel dump command, that would be genuine firmware-level hacking.

dupontgu's project sits in the middle — not rewriting stock firmware, not building hardware from scratch, but brute-forcing a complete standalone system into an off-the-shelf shell. 163 stars say it all: nobody needs this, but everyone wants to applaud it. That's indie hardware at its finest.