The Torchinsky Files: The Insane Restrictions Of Old Ataris Made This Classic Racing Game Possible

I think I’ve made it pretty clear that these little shows are going to be painfully geeky, and I assure you that this week’s episode will absolutely live up to that claim. Fundamentally, what I’m talking about here is something that I think is one of the greatest catalysts to creativity: restrictions. Specifically, the very significant restrictions of the old Atari 2600.

This is still car-related because I’m talking about a racing game, Activision’s 1982 release, Grand Prix. Here’s an old commercial for the game:

Despite what the commercial implies, you would have to have an extremely distorted view of reality to mistake this game for anything approaching reality, but that doesn’t mean it wasn’t an impressive achievement for its time, on the Atari 2600 hardware.


You’ll notice that the cars are, surprisingly, non-terrible looking, with actual shading and racing stripes and all that. The reason they look the way they do has to do with some very specific quirks about the absurdly limited 2600 hardware, and it’s actually the look of these cars, and the very clever methods used to get them, that inspired the whole game itself.

Illustration for article titled iThe Torchinsky Files/i: The Insane Restrictions Of Old Ataris Made This Classic Racing Game Possible

I explain the whole thing in the video—why the game is horizontal and why that matters, the incredible restrictions old Atari programmers had to deal with, why these very limitations ended up making the system far more flexible than anyone ever imagined it could be, and so on.

If you want to know more about this, MIT Press has an incredible book called Racing the Beam that you should read—it’ll make you respect the hell out of this humble little machine and the brilliant women and men that squeezed so much out of it.

Anyway, watch the painful geekery up there. Someone has to, right?

Senior Editor, Jalopnik • Running: 1973 VW Beetle, 2006 Scion xB, 1990 Nissan Pao, 1991 Yugo GV Plus, 2020 Changli EV • Not-so-running: 1977 Dodge Tioga RV (also, buy my book!:

Share This Story

Get our newsletter



I have to say, I developed a HUGE amount of respect for these early Atari devs in my senior year of college. My CS final project was to help add CRT-style artifacts into the 2600 Emulator Stella. Since we wanted to do this right, and not just fake up a pretty fragment/vertex shader combo, we went looking at how other emulators were doing similar things, and that led us to Blargg’s NTSC emulation library. I thought, “oh, this shouldn’t be too hard to port over from the NES to the 2600, right?” OH GOD WAS I WRONG. Everything in that damn emulation library was directly based on hardware specs of the system being emulated, from the electrical frequencies used to initialize the system color palette to the number of pixels painted per cycle of the carrier beam’s waveform. And the worst thing was that some of those constants had already been combined in certain ways (usually multiplication and division) to generate OTHER base constants, and there were no comments or anything to explain what these numbers were or how they’d been arrived at. I just had to sit down with a reference manual for the 2600's hardware, a reference manual for the NES’s hardware, and the NES version of the library, and painstakingly reverse engineer the lib based on the NES’s hardware specs. Once I managed that, I was finally able to start changing things over to reflect the Atari’s hardware instead... and of course, the day I finally finished it up was the day Blargg finally responded to my emails and sent over his own COMPLETE copy of the goddam NTSC emulation library for the 2600. Thankfully mine worked just as well as his, otherwise I’d probably have punched myself in the face.

ANYWAY, in the process of all of this, I learned a LOT about the various tricks and restrictions the 2600 developers faced. I had no idea prior to that project that the 2600 actually had a “portrait” resolution, but the slowness of the processor meant that every horizontal pixel got painted twice, stretching the image to a double-wide aspect ratio. My favorite trick, though, was when they’d double the number of available sprites on screen by BLASTING the phosphor tube with the electron beam in a sprite’s “original” location, and then, while the same “frame” was being painted, they’d go ahead and move that same sprite to another location that the beam hadn’t reached yet. Because of the strength with which they hit the phosphor tube at the sprite’s original location, its “glow” would last well into the next frame, and so when it got painted in its “new” location, you’d have the same sprite showing at two difference places in a single frame. So by doing this same thing with every available sprite (and a little intelligent planning of the path the beam would need to take), they could double the number of possible sprites in one frame.