'Atari 2600, video, and the PIC'
> >Actually, the Atari 2600 video computer system (came out in '77)
> >tended to
> >use a "virtual display system"; the display hardware on that thing is
> I think it was just a couple of clock generators and a shift register.
> Did it have any DMA logic or did the 6502 have to stoke it constantly
> during the visible part of the scan?
There was no DMA logic, but there was a fair bit more to it than "just a
couple of clock generators and a shift register". To be precise, the
hardware consisted of the following (BTW, if you have a "COMBAT" cartridge
convenient it shows these concepts perfectly)
 A horizontal-timing generator. No CPU intervention is needed to maintain
HORIZONTAL sync, or to show a scan line repeatedly. All of the display
circuitry in the 2600 is designed to show one scan line; anything beyond
that must be done by CPU trickery. Each scan line consists of 228 dot
clocks (colorburst rate); every 3 dot clocks is a CPU clock.
 A wait-control latch; if the CPU does a store to address $02, it will
suspend program execution after the next instruction fetch until the
start of the next horizontal blanking interval (i.e. the end of the
current scan line).
 A "playfield" generator; this generates the lores background you see in
most games. It stores the left 20 bits, addressed as 3 bytes. For some
reason these bits are in rather strange order. The right half of the
playfield may be a repeat or mirror of the left (in the tank modes, it's
mirrored; in some other modes it's repeated).
 Two "player sprite" generators; these each have an 8-bit shape register,
a buffered shape register, a size/placement register, and a horizontal
position counter. Each sprite may be selected to appear in any of the
following eight configurations: (a) Once, small; (b) Once, double size;
(c) Once, 4x size; (d) Twice, 16 pixels center-to-center; (e) Twice, 32
pixels center-to-center; (f) Twice, 64 pixels center-to-center; (g) 3x,
16-pixels center-to-center; (h) 3x, 32-pixels center-to-center. Either
second sprite may optionally be reflected about its axis. Note that
unless the shape register is rewritten between instances of a sprite,
all will have the same shape.
 Two "missle sprite" generators, associated with the two players, and a
"ball sprite" generator, associated with the playfield. These each
generate a single blob 1, 2, 4, or 8 pixels wide unless the correspon-
ding player is replicated on the scan line, in which case the missles
are as well.
 A color-control circuit with four color registers: background color,
playfield/ball color, player1 color, and player2 color. One of these
four colors (or black) is output based upon a priority encoder; either
the playfield or player sprites may have priority. In addition, there
is a special mode, called "score mode", in which the left half of the
playfield is the player1 color and the right half is the player2 color
(play "COMBAT" or any other similar-vintage game to see why it's called
score mode). Each color is defined by a 3-bit luminance (the chip has
3 outputs which are resistor-DAC'ed) and a 4-bit hue (gray or 1 of 15
colors). This yields a total of 128 distinct output colors, a number
which compares quite favorably with other systems.
 The "hmove" circuit, a hack for controlling the positions of the sprites.
Rather than using position registers, all of the sprites have counters.
The CPU has the following abilities:
(a) Reset a sprite's counter to zero; if this is done mid-scan-line,
this will change the sprite's position to the current raster
location, more or less (different sprites work a little different-
(b) Reset a missle's counter to match it's player's (not really all that
useful generally, though Combat uses this ability).
(c) Perform an HMOVE in which the video-enable signal is inhibitted for
an extra 8 pixels at the start of the next scan line (which would
cause each sprite to move 8 pixels to the right) and from 0 to 15
extra clocks are given to each sprite counter (moving it 0 to 15 pix
to the left). This allows each sprite to be moved 7 pixels left to
8 pixels right, but causes an 8-pixel-wide black area on the next
scan line (readily visible in many 2600 games--ever wonder what all
those black bars were?)
 A full range of collision-detectors, conveniently arranged two per byte
in positions 6 and 7 (useful on a 6502 since those bits are most readily
 A VSYNC gating circuit (which the CPU must turn on and off at the proper
times each frame--the CPU is responsible for VSYNC timing!)
 A RIOT chip which consists of 128 bytes' RAM, I/O for the switches and
joysticks, and a TIMER. Not really part of the video circuitry, but
it's very important to video generation since otherwise it would be hard
for games to keep vertical sync consistent.
If you play any of the games before about 1981, you'll see that they all fit
the above model pretty well; the only readily apparent common diversion is
that the playfield is altered mid-scan when displaying people's scores. A
close examination of Space Invaders will reveal that when one of the invaders
is shot and others remain on the line, the sprite shape register is actually
reprogrammed mid-line to show the explosion.
> The really interesting thing is that there was nowhere near enough RAM in
> the box to store a whole picture in dot-matrix form at once (128 bytes?).
> So the software had to generate each line of video right before it was
> displayed. All that was stored in the RAM was the line being displayed,
> the one being generated, and game variables like the position of each
> object on screen. During the vertical blanking interval, there was time
> to make high-level analysis of who is worthy of redisplay in the next
Pretty much correct; the display registers are as I indicated above--not
a whole lot there, really. Abilities such as the ability to display a
hires score were not part of the original Atari concept, but someone
discovered that if you put the two sprites 8 pixels apart, set them to
display 3 times each, and change the shape registers a bunch of times at
just the right points each scan line (everything must be in registers
beforehand and there aren't any spare cycles; you even have to put one
of the shape bytes in the stack pointer since TSX is only 2 cycles but
LDX is 3!).
> This combination of big ROM, small RAM, and fast CPU sounds a lot like a
> PIC chip. It should be possible to clone many of the 2600 games
> (especially simple ones like Pong, Space Invaders, maybe even Pac-Man)
> into a PIC, using the SSP to shift video out, making a single-chip game
> (not that GI didn't already have dedicated single-chip games).
Actually, the 2600's CPU isn't really terribly fast. It runs at colorburst
over 3, which is about 1.19MHz and the average instruction time is about 3
cycles (helped by the fact that all the RAM and display registers are in
zero-page!). Nonetheless, the paradigm of a virtual display system seems
to apply since a typical game will look like:
wait_for_timer(); /* So we put VSYNC in the right spot */
where the game stuff sets up the registers for the "virtual hardware" which
is embodied in scan_display. Because different games need to display diff-
erent things, they can push the hardware different ways. For example, in
my "columns" 'game' [unfinished] I display 6 colored gems on each scan line;
all the gems are the same shape. To do this, I used a technique similar to
that for showing hi-res graphics but I changed the color many times instead.
Had Atari simply put in a 48-bit hires mode but not allowed for such close
CPU/display synchronization, this would not have been possible.
An even more extreme variation upon this idea is Galaxian; this game can
show seven striped monsters in formation as well as a swooping monster,
all on the same scan line, without flicker. To do this, it has to hit
the reset-player-position register once every 5 CPU clocks (for those
monsters that are present) but it manages to do that. Majorly cool.
By the way, other than a few programs (like Chess) which require a "big
think", how many other 2600 carts have you seen that don't manage to always
maintain VSYNC perfectly even when you restart the game? The only one I
can think of is Tron: Deadly Discs (or whatever it was called) which would
glitch the screen when you hit reset. How people managed to pay so much
more attention to detail then I have no idea.
As for cloning games with just a PIC, I think going beyond PONG would be
very difficult without some sort of hardware to handle line scanning. The
Cyrix part might be able to manage that stunt better, though its smaller
address field (12-bit-PIC-style) would make programming a pain.
> In color? If the PIC will go 57.28 MHz, this allows a dot clock of
> 14.7456 MHz, allowing several awful shades of color (Why "Cyan" and
> "Magenta" rather than nice pure red and blue? Because the phase is
> even). A persistent rumor claims the 16C5x parts will wail away at 50
> MHz with external clocking. Otherwise some external color logic may be
> needed. Maybe using the USART and the SSP at the same time could
> generate 2-bit pixels for the color matirx.
If I were trying to to standalone video with a PIC, I'd use some external
programmable logic to handle color; probably the horizontal timing as well.
Vertical timing could easily be managed by the PIC of course.
Really excellent explanation of how the 2600 worked.
Check out "Programming and Customizing the PIC Microcontroller" at:
More... (looser matching)
- Last day of these posts
- In 1997
, 1998 only
- New search...