Hacker News Reader

Comment by ksherlock | Hacker News Reader

"The way the paddles in particular are drawn is especially ingenious; in fact, the firmware doesn't even need to position them. The paddle controls are simple potentiometers feeding into an R-C circuit (external to the chip, not shown here) that discharges at a rate based on the pot's resistance. This then feeds into an on-chip comparator in the region marked "paddles," delaying drawing the paddle a number of scanlines based on the pot's position until the comparator triggers, thus eliminating the need for a more complex solution like an A-D converter (cheap!) and automatically drawing the paddle at the proper location without any intervention from the firmware."

I love it!

View on HN

It's a nice hack. I think this is how Woz did the Apple II paddles, too (albeit with discrete components and a timer IC). It sounds familiar.

Yes, the Apple II also uses a resistor-capacitor timing circuit to determine the paddle position. The big difference, however, is that the Apple II uses the timer and a counter to produce a paddle position 0-255. Software can then use this value to e.g. draw a paddle at a position on the screen.

The game chip, on the other hand, doesn't produce a value. Instead, the timer is synchronized to the screen drawing, so when the timer fires, it indicates to draw the paddle now. So the system never has the paddle position as a digital value and there's no register that holds the paddle position.

How is intersection with the ball detected?

I think that the circuit at the top center of the chip detects collisions. E.g. if the paddle is being drawn at the same screen position as the ball, then you know that the paddle has hit the ball. This way, you don't need to store the paddle position and you don't need to compare the paddle and ball positions, you just check if a paddle pixel and a ball pixel happen at the same time.

I haven't figured out how the ball position is stored. It seems like they'd need a register for the X and Y position, along with an incrementer/decrementer, but I couldn't find that. Maybe there's something tricky going on. Or maybe I haven't looked in the right place.

The brilliance of this is there's no chance of bugs caused by the internal paddle position (that causes the ball to bounce) not matching the drawn position, which would make the ball either pass through the paddle or bounce off nothing. Whether that was any part of a motivation for this design or it was purely driven by technical limitations, it's just a very elegant solution.

capacitor charge/discharge timing is actually pretty common way to make ADC, even precision ones,

https://en.wikipedia.org/wiki/Integrating_ADC

That's sweet. The paddle is a component of the "register" directly. I didn't stop and think about that deep enough. Thanks!

If you want the least amount of lag possible, you now know which device to turn to. I'm thinking of the famous lag table of character entry for 80s 8-bit computers and modern PCs.

This device should be remade for a 120 Hz display to halve the maximum lag from 17 ms to 9 ms.

Using these machines on a 2022 display adds so much lag, it really makes them unplayable. On a CRT the connection between your movement and the paddle on screen is so immediate and undamped, it can be quite a powerful experience as you embody it despite its crudity. Helps to understand how simple games like this were so popular.

I have a few, but sadly I don't have the space to keep a CRT monitor too.

Reply on news.ycombinator.com