How were the 70s versions of pong and similar games implemented without a programmable computer?

Question

My Dad once commented "Back in the 70s - when Wozniak was working at Atari - they were building games using electronics - not programming computers."

As a Computer Science graduate without an Electrical Engineering background, I was trying to wrap my head around how that was even possible.

When we research the game systems of the 1970s we see:

Dabney soon thought of a way to manipulate the video signal on the screen without a computer controlling it, and from there Syzygy Engineering came up with the idea of removing the computer altogether and building specialized hardware to handle everything for the game instead.

In my head I can visualise electronic logic for binary adders, and running a square root operation on a number in a binary representation. But how do you represent the logic for 1970s game console pong or tennis? (Writing the software to do it seems comparatively easier to visualise.)

My question is: How were the 70s versions of pong and similar games implemented without a programmable computer?

Answer 1

They were made by mostly avoiding 'computing' concepts altogether, and treating it more like a mechanical thing.

For example with Pong a major component is usually timers - every xth of a second the timer will emit a signal. You have timers calibrated to match the horizontal refresh of the screen, so they'll 'ring' at the same point on each scanline. Then you have timers calibrated to the vertical refresh, so they'll ring on the same scanline each frame.

The ball is then just two discrete timers for vertical and horizontal position, and their rings are sent through an AND gate that will raise the voltage going to the display when both are ringing causing a white dot to appear. The paddles build on this concept with a medium length timer that can be started and stopped to define the length.

To move the ball or paddles the timers can be advanced or delayed by a control signal. Or more accurately the timers are always paused at a certain point, like during half of the horizontal blanking period. This pausing is then shortened once to advance the timer (move left/up) or increased once to delay it (move right/down).

Since both the paddle and the ball timers are emitting a '1' when they are to be displayed you can impliment collision detection by performing another AND operation. So if both a paddle and the ball are being drawn at the same moment you know they've collided and can adjust a latch controlling the ball direction accordingly.

If you get into the Atari 2600 you'll find that it's really weird compared to other consoles (sprites with no clearly defined X coordinate, instead only the ability to place it at the actual current location of the CRT beam or nudge it a small amount either way), but that it starts to make a lot of sense when you realize they were implementing their Pong logic for a programmable chip.

Answer 2

OMG, if you haven't seen this yet - you are in for a treat!

I am trembling with excitement, as I share this link:

https://www.falstad.com/pong/

This is a full, working, online emulation of all the components of pong, including the sound. You can modify and tweak anything and see exactly how it works. I spent a lot of time just looking at those circuits work and marveling at human ingenuity.

Answer 3

Hardware and software are interchangeable

To a point - you always need enough hardware to run software, but anything you can do in software, you can build a hardware replacement for. Albeit, it’s usually a lot easier to build a Turing complete machine in hardware and do the rest in software.

Now, I don’t know how they implemented pong, but 20 years later, water utilities were still implementing pumping stations and treatment plants wholly using relays and contactors - none of this new-fangled electronics for them. I know because one of my designs was the first to use a PLC (aka a Turing machine) as the primary control mechanism for Sydney Water - it still had a complete redundant implementation in relay logic. It only took a few more years before the relays were phased out.

To this day, the programming interface (or one of them because there are usually several) for PLCs looks exactly like relay logic. You build your program by combining various types of virtual relays. Now, you could print it out and build it with actual relays.

Answer 4

Based on CS background, if you know how logic gates work (or how an FPGA works instead of CPU), then that's how anything operates. It's just a bunch of logic gates doing their stuff. Even a CPU is nothing more than a bunch of logic gates, which are wired to implement the logic, whose task is to execute any program you give to it.

So these games were just a bunch of logic gates, executing the logic of the game, sort of like running a fixed program but in a way that the program is not a separate entity but the hardware is just fixed to run the logic it needs to implement the game.

So in same way that you can make an FPGA description to describe a CPU that can execute code, you can make an FPGA description to be a pinball machine, taking inputs from buttons and sensors and giving outputs to actuator solenoids and lamps, and the logic to increase score when you hit something etc.

Of course such pinball machines were not made with digital logic gates but electromechanical gates such as relays. Later TV games were made with digital logic gates, either with separate stangard logic chips or custom ICs that implement the logic.

Answer 5

Not a direct answer, but you could think of Pong as the next evolution from pinball machines.

TechnologyConnections has done a great series over the past year with a deep dive into the inner workings of a pinball machine that uses no (or very little) electronics, Pinball!. All the controls are eletromechanical.

Answer 6

If you're a CS graduate, you'll know what a state machine is. (I really, really hope you do!) You'll be used to writing them in code, of course.

There's a whole area of digital logic around building state machines out of flip-flops and basic logic gates though. Just like your code, each pass you check the conditions and (if met) transition to the next state. This is almost exactly how code (typically Verilog or VHDL) runs in FPGAs.

I'm slightly worried about your course syllabus though, because in order to be confused about this, you have to have not been taught about FPGAs and likely other significant areas of processing such as GPUs. Those are fairly major areas of CS to be missing. The good news is that you're asking those questions now, so you can go and play with that kit now instead. :⁠-⁠)