Inventing the Atari 2600

An article originally published by IEEE Spectrum in 1983 and technically not a computer. But some video ‘tricks’ featured here to make the VCS work are probably familiar to those who have pushed the graphics capabilities of their computers (like making more than eight sprites appear on-screen on the C64).

The key to the [VCS] design was simplicity: making the software do as much of the work as possible, so that the hardware could be cheaper—silicon was very expensive in those days. The microprocessor was synchronized to the television scan rate and created the display one or two lines at a time. This synchronization reduces memory requirements for the television interface considerably, but the processor must continually update the registers in the interface to get any display at all. The program that feeds information to the video chip (called Stella, after its designer’s bicycle) is known as a kernel.
To move objects, the prototype blocked out four clock pulses from the position counters during the vertical blanking interval; a programmer could then add pulses to move an object left or right—four pulses had to be added to keep the object in the same place. Mr. Miner added a set of motion registers, which add or subtract pulses automatically when a signal—called H-move—is sent by the microprocessor. The H-move can be sent during the vertical blanking interval, or during the horizontal blanking interval at the beginning of each line.

“This seemed innocuous enough,” said Larry Kaplan, the first software designer hired to develop games for the Stella project. “But I discovered early that it was possible to reposition player objects during a screen [a frame of the TV picture], though that was not a consideration of the design.”
“The VCS was not doing that well—there were only a few million in the field, and it looked like it was dying—then Space Invaders came out, and bam! it exploded,” Mr. Kaplan said. Space Invaders was the most popular game in the arcades, and the VCS, with rows of six objects across the screen (two player-objects, copied three times each) could recreate it in the home.


I’ve seen a couple of references to racing the beam in recent developments in Acorn land - it’s still needed, if the complexity of the graphics and the engine is great enough to need most of a frame to do the work. For example, Pacman from tricksoft - announced and discussed here.

Another example, for Acorn’s slightly underpowered Electron, a demo aptly called Racing the Beam, discussed here:

1 Like

Also, slightly more on-topic, Atari’s Video Chess had to jump through hoops to get all the pieces to show up:

Atari 2600 was only capable of displaying three sprites in a row, or six (such as in Space Invaders) with the right programming. The eight-piece-wide standard chess board exceeded this limitation. To rectify this, Bob Whitehead developed a technique known as “Venetian blinds” where the position of each sprite changes every scan line; this allows for eight or more sprites in a row.

1 Like

The most important idiosyncrasy of the VCS was the implementation of the positional counters. In principle, this replaces the horizontal slipping counter chains of the early arcade video games, but with a crucial difference: in the VCS, these were not linear counters, but linear-feedback shift registers (LFSR), for cost effectiveness. Since LFSRs are not linear, any sprite positioning has do be done in a time-based fashion. Meaning, even, if you are not intending to “race the beam”, you have to align your code with the beam, just the same: Just say “Now!”, i.e. strobe a TIA register, when the beam is on the right spot.
Only once you have accomplished this, it is when any digital positioning comes into the picture (quite literally so), which is required for fine tuning your sprite positions. Since there are three screen pixels for any 6502 clock cycle and the tightest loop on a 6502 performs in 5 cycles, any time-based attempt to provide your sprite position results in a granularity of 15 pixels. Therefor you have to add a correction value for fine positioning in the range of -8…+7, which may – believe it or not – be provided as a digital value. However, in order to do so, you have to figure out the difference of the position given by the runtime of your delay loop and the intended position in pixels, which will result in the proper correction value to be submitted to yet another TIA register!
(Mind that the correction required isn’t always the same, but depends on the individual sprite, just to make things a bit more interesting and cost effective.)

Believe it or not, this is actually fun.

BTW, you have to apply any fine positioning during horizontal blank, otherwise, your nice digital values result in some interesting and probably unexpected behavior (which has been worked out in the homebrew communities since and there are now tables, which will tell you what these are for any given sprite on a given clock cycle for most of the production batches).

On a final note, it’s this final correctional value, which causes the characteristic black combs at the left side of the frame of numerous VCS games, like Space Invaders. Said correction is implemented by letting “slip” the individual sprite counters by 8 pixels at the very beginning of a scan-line (and then adding the correction), which results in a blanking of the signal, whenever this is changed and reapplied inside the visible part of the image kernel. This is actually a bug that was soon resolved, but the fixed design never made it to production (cost effectiveness!). So these black indentations are the tell-tale signature of something nifty going on with sprite repositioning behind the scenes.


There’s an in-browser IDE for the 2600 with many well-commented tutorial examples - here’s a link to one for this sprite fine-positioning.