A Line at a Time: The Atari 2600, Now with S-Video

From Pitfall II to the Channel F to the NES cartridge port, a spectre has lurked in the background of Nicole Express: the spectre of the Atari 2600. The best-selling console of the second generation, an icon, and yet to date, I have not covered it, or even owned one. That all changes today, and we’ll find out what the deal is with this strange artifact from the past. Plus, we’ll get some S-Video.

The Atari

This is my Atari 2600. There are many like it, but this is mine. Don’t mind that it sprouted a tail, that tends to happen to consoles that hang around here.

This specific Atari is a 2600jr, even more specifically a “short rainbow” model. (Note that the linked site is a bit inaccurate, as I believe there were RF boxes included with this model– mine isn’t boxed though so I can’t confirm. The signal coming out of the RCA jack on the back is modulated)

The 2600jr was released in 1986 by Jack Tramiel’s Atari Corp., but seems to have been a product of predecessor Warner Communications subsidiary Atari Inc., shelved when Atari collapsed in 1984. Some “short rainbow” machines, especially PAL models, have stickers reporting Atari Inc., though mine, like most NTSC 2600jrs, does have an Atari Corp. FCC notice. This is a contemporary of the NES! But a bargain basement console for sure. It’s super lightweight and feels cheap, because it was.

The model is not really that big a deal; this console isn’t special. There is one very late 2600jr model with a one-chip design, but this isn’t it. Like pretty much any Atari 2600, this is a three-chip design:

Those three chips are right in the center:

• The MOS Technology 6507 CPU. This is a 6502 die, with some pins not hooked up. The implications of this are important. The fact that this particular 6507 is made by Taiwan-based UMC probably isn’t.
• The MOS Technology 6532 RIOT. This does exactly what the name implies: it contains 128 bytes of RAM (twice the Channel F!), provides two 8-bit I/O ports, and a programmable Timer. It’s also made by UMC.
• The Atari Television Interface Adapter (TIA). The only real custom chip onboard, the TIA is what made the 2600 the 2600. It generates a video signal using various internal registers, as well as handling paddles, sound, and some other functions. Someone wrote on this one.

What’s the appeal?

Atari 2600 games are shockingly primitive by 2023 standards. They probably look shocking primitive even by the standards of someone used to the 1983 Famicom. At least that could do a more arcade-accurate Space Invaders.

But be fair: this is a 1977 home console. It’s older than Space Invaders’s (expensive and RAM-heavy) arcade release. And that’s the thing about the 2600. From a visual, sound, and gameplay perspective, its version of Pac-Man is so bad that it is often given much of the blame for North America’s video game market collapsing in 1983. It’s got flicker so nightmarish I had to heavily doctor this screenshot just to see more than one ghost.

But once you realize the limitations and programming model, well, as a software developer myself, and one who’s dabbled with 6502-based console game development, well, even something like Pac-Man looks like a masterpiece of code, if not of game.

Atari Football

To contrast with the hardware of the Atari 2600, here’s an arcade game of comparable vintage: 1978’s Football. In 1978, Atari could get away with just naming their football game Football, and since this is an American game, it’s American football. Don’t worry, Atari used similar hardware for a game we call Soccer.

If you’re like me and have nothing better to do, take a look at the MAME source for this game. The programming model is pretty simple.

There are three areas with tilemaps; the two sides scoreboards (this is a game intended for a cocktail cabinet) and the center scrolling playfield. These are handled in hardware. (“SWEEP” and “BOMB” at the top are MAME’s way of handling some external lights and selection options that aren’t on-screen, as was common in 1970’s games. These are also hardware controlled.)

There are movable objects, the X’s and O’s representing the two sides. These sprites are handled in hardware, the programmer merely needs to set the character, the x position, and the y position, along with some flags. This is similar to the NES sprite model.

Timing for the game is accomplished by using the IRQ (interrupt request) pin on the MOS Technology 6502 CPU. Four interrupts per frame, which is more than the NES will give you, but that’s arcade technology, baby.

Oh, and there are no colors.

Here’s Atari 2600 Football. Well, okay, it’s actually running on an Atari Flashback 8. I don’t have the cartridge for Football. What are you, a cop? In any case, this game came out in 1978, so it’s contemporary with its arcade counterpart.

So there’s fewer players on screen, sure. And it scrolls vertically; well, this isn’t a cocktail table. And this is definitely a game where you need to read the manual. But it is in color. And the programmer didn’t have any of those niceties I described above.

A tilemap and sprites are niceties? Oh no…

The limitations

The Television Interface Adapter has to paper over two big problems. First off, CPU’s are expensive. Second off, RAM is expensive. The Fairchild Channel F had to solve the same problems, but Atari took a very different path.

The CPU is too expensive

Specifically, pins on the CPU are too expensive. It’s an interesting thing about CPU packaging; the die itself is generated through photolithography, but the connections to the outside world are a bit more complicated.

Fairchild’s solution: Eliminate pins on the address bus by having everyone on the bus keep track of the address separately. Use a five-bit “C” bus for address commands, keeping a full 64kiB address space at the cost of random access.

Atari’s solution: Just cut pins off the 6502. Well, you don’t need to cut them off. Just make sure they were never there.

Specifically, the 6507 CPU eliminates the following pins:

• A15-A17: The addressable memory drops from 64kiB to 8kiB.
• IRQ and NMI: The processor has no interrupts

It’s also missing a bunch of other signals that aren’t used as much (“set overflow”, anyone?) as well as some non-connected pins, but those aren’t a great loss. The missing address bus and interrupt lines, though, those hurt.

The 6507 die is a 6502 die. So it shares pretty much all the other properties of a 6502. That means that it has no IO space, so that 8kiB address space has share room with the various control lines, and it also includes RAM. (The Fairchild F8 did not have external RAM per se, but you can’t get away with that on a 6502 with so few registers)

Long story short, Atari took the simplest path for address decode, and only left 4kiB, half of the 8kiB address space, to the cartridge ports. On the plus side, you can use a standard mask ROM pinout for that. Since unlike Fairchild, Atari was not a chip fabricator, a C-bus type solution wouldn’t have realistically been an option.

RAM is too expensive

Fairchild’s solution: The Fairchild Channel F has 64 bytes of register space in its Fairchild F8 CPU. It uses 2kiB of external video RAM; to draw a full color screen with it, it drastically lowers the resolution available compared to an arcade framebuffer. (The RAM is dynamic RAM, and isn’t on the F8’s bus; it can’t actually be read by the F8, only written to.) Framebuffer game Space Invaders is 256x224 rotated. The Channel F is 102x58.

Atari’s solution: Draw the screen one line at a time.

The Television Interface Adapter has no video RAM. It has a few registers, but only enough internal state to draw one line on screen. On the Famicom, you update the registers for the next frame in the vertical blanking period. On the Atari 2600, you update the registers for the next line in the horizontal blanking period.

What does this actually mean? Let’s do a quick Famicom digression, as is traditional on this blog. Here’s F-1 Race, an early Famicom title that wasn’t released here in North America. (We got Mach Rider, which shares a lot of code, though)

Now, if I hold down the RESET button on the Famicom, you’ll notice that the screen tiles glitch, which is normal. But also notice that the curve in the road disappears. Once the CPU is held in RESET, it stops doing any work. So what we’re seeing here is just the PPU trying to draw without any CPU interference.

The curve is gone, because in F-1 Race, the CPU constantly updates the scroll registers on every line, known as a raster effect. On the Famicom, especially early in its life, this was considered an advanced technique. F-1 Race is attributed to programming genius Satoru Iwata, who’s appeared on this blog before.

Here’s another Iwata game, one which that doesn’t use raster effects: Balloon Fight. Notice that when I hold down the reset button for comparison, the image is glitched, but the layout is essentially the same.

In 1977’s Indy 500, the game uses far more intensive raster effects to draw some chunky cars on a simple non-scrolling racetrack. And you have no interrupts, remember. Instead, the TIA offers a register called WSYNC. It puts the CPU to sleep until the next line starts. So the CPU now knows its on the next line; at the cost of wasting cycles.

Oh, and remember the vertical blanking period? Yeah, the TIA gives you a register, but the programmer is the one who needs to make sure that’s there, in the right amount of time, after drawing the right number of lines. That’s generally what the RIOT timer is used for; of course, the timer can’t trigger an interrupt either. Almost all Atari games run at crisp consistent framerates, because the console can’t do slowdown; instead, your television will lose sync. So don’t let that happen.

You might wonder if the same reset button trick would result in the Atari 2600 drawing a single line over and over again. And in theory it would; except for the fact that unlike the Famicom, the Atari 2600 reset button isn’t actually hooked up to the reset line. It’s an input the game code has to read, just like every other button and switch other than the power button. (The Sega Master System also has reset as a software-interpreted button, so this isn’t that strange.)

Of course, we can fake the effects. Notice that I’ve had the line cover what’s “screen border” area above. If you were to actually get the Atari into this situation, perhaps by bumping the cartridge or messing with the lines manually, it would never do any vertical blanking, so you’d get a rolling picture on a CRT. Well, it would roll, if the lines differed at all.

Hardly sprites

Despite working line by line, the Atari 2600 does not give you a “line-buffer” like a linear version of a framebuffer. Even that would be too much RAM for the penny-pinchers at Atari. The “playfield” has only a 20-bit register, which is mirrored or copied across the screen. That’s a 40-pixel wide resolution, which on its own would be even worse than the Channel F. The playfield also has a single foreground and background color.

Sure, you can “race the beam” and update them while the screen is being drawn in the middle of a line if you don’t want them to be symmetric. So most games find excuses for symmetry. Note that, as this screenshot of Slot Racers shows, this only applies to horizontal symmetry; vertical symmetry is no easier to implement than any other vertical arragement.

So how do you handle moving objects?

The Atari 2600 was designed with two arcade games in mind. Atari’s 1974 Tank, which featured two tanks that shoot at each other, and of course, 1972’s Pong, which features two paddles, and a ball. I’d give you MAME screenshots, but these games predate using CPUs in arcade games.

So it included several movable objects. But these aren’t general purpose sprites.

• Two “players”, which are 8 pixels wide, one color and transparency. Those pixels can be stretched, but at it’s smallest, it’s an effective resolution of 160px wide. You can duplicate them to create rows of up to three, like in Football above.
• Two “missiles”. These are rows of solid pixels. They share a color with their respective player.
• The “ball”: This is like a missile, but uses the playfield foreground color. (Famously, the main character in Adventure)

Note that these exist on every line the screen is drawing. So if “player 1” shouldn’t be on a certain line at all, the programmer will need to make sure to clear that sprite.

Even more work for the programmer, the horizontal position is not just an 8-bit value written to a register. Instead, there’s a “strobe”. If you strobe it while a line is drawn, the sprite will be drawn at that position for future scanlines. This simplified the silicon. (Steve at BMOW gives more detail, it’s pretty wild) On top of that there’s a horizontal fine-positioning system called HMOVE that could be a blog post unto itself.

The one nicety you do get? Hardware collision detection. So at least you don’t have to keep track when these items collide with each other– and unlike the Master System version that game so much trouble during the Alf fiasco, it even tells you what collided with what. Amazing what you can do when you have five sprites.

The big benefit here? Look at the playfield in Yars’ Revenge. Specifically, the “neutral zone” in the center (actually only drawn every other frame)– the color is changed on every line. The Atari 2600 allows a huge number of on-screen colors, and with its large 128-color palette in NTSC territories, it has a lot to choose from, even if only a few can be on each line.

I could go on, but long story short: give Pac-Man developer Tod Frye some respect. Of course the ghosts flicker– but how is Pac-Man eating all those individual dots? Wild! And this is all in 4kiB; code a sixth of the size of even a tiny NES game like Aspect Star “N”.

Of course, modern developers have done some even more amazing things within those limits, and when you get a little more ROM…

Overall, you can really see how the 2600 puts pretty much all of the impetus on the programmer to wrangle the hardware, whereas something like Atari arcade Football saw the program as just the glue between pieces of hardware. Putting so much work on the programmers, without giving them more recognition, probably wouldn’t bite Atari in the future, right?

Really getting into it

The NES exposes its entire internal video bus to the cartridge slot, which allowed a lot of neat techniques. But as I noted in that blog post, the Atari 2600… doesn’t. The hardware developers got to suffer a bit too.

Not only is the address range limited to 4kiB, but the Atari 2600 doesn’t even provide enough cartridge signals to use a normal RAM chip. It’s missing the signal that tells whether something is a “read” or a “write”; Atari’s engineers, quite sensibly in 1977, assumed that the cartridge would always be read from, so it didn’t matter. Why write to ROM? Later Atari cartridges that included RAM on board had to use different addresses for writing and reading to get around this.

You might know that games like Pitfall II: Lost Caverns use a special chip. But don’t get it crossed: special chips on the Atari 2600 don’t free you from the TIA’s limitations. David Crane has to time his sprites and call HMOVE just like everyone else. That’s not to say the chip doesn’t help; what the DPC actually does and what’s possible is discussed in great detail on Big Mess O’ Wires, so I recommend you read there.

Interestingly, the DPC chip used in Pitfall II was designed not as a one-off for that particular groundbreaking game, but as a general-purpose chip Activision could continue to use for multiple releases. Unfortunately, with the video game crash, and then the 2600’s post-crash afterlife as a below-budget-basement level discount console, that never happened.

Getting the picture

So I could go on gushing over the Atari 2600. (Look, here’s Atari’s internal TIA documentation!) But there’s a problem: the Atari 2600jr, like all other 2600s, relies on an internal RF modulator. This means that I’d have to rely on my RF demodulator, which is… not good.

Since an RF modulator needs a composite signal to modulate, any RF modulator-using system must be possible to composite mod. But what if you want the highest quality video output?

Tim Worthington has an RGB solution which intercepts the TIA signals, but that bypasses the 2600’s color’s circuit an recreates it. As you might have realized above, color is the 2600’s strong suite, so it’d be nice to keep it original. Honestly though my more realistic objection is that installing a 2600RGB in a 2600jr requires soldering to a flex cable, among other things that I’d be very likely to foul up.

Here’s the TIA’s pinout (source: Atari Compendium). What does it use to build its video circuit?

• LUM0, LUM1, LUM2: A 3-bit digital luminance output
• COLOR: A modulated color (chrominance) signal. Can be adjusted with a pot attached to CADJ. (Never Twice the Same Color, as they say)
• BLK': Blanking signal

This isn’t RGB, and the combined color signal means that we can’t use component video. But unlike, say, the NES PPU, which only outputs a composite video signal, luminance is separated from chrominance. That means that the Atari 2600 is a great fit for S-Video.

And that’s how I came to The Brewing Academy’s Ultimate Atari Video solution. It promises to fit the Atari 2600jr and provide a clean S-Video output. It also provides a composite out, but you can passively convert S-Video to composite with a cheap adapter, so I won’t bother exposing that signal.

Overall the UAV came with a pretty good manual. Long story short, the goal here is to intercept the signals we need, primarily from underneath this chip:

This is a simple non-inverting buffer IC which the Atari 2600jr, along with the original Heavy Sixer, uses to buffer the luminance signals. The Atari has a ton of models, though, and some don’t use this chip at all– the UAV board is also designed to support a bunch of other models. So again, I won’t go into too much specifics, because the guide will hopefully be updated over time more often than this blog post.

I followed the advice of the guide and cut off the legs of the CD4050, soldering it to the underneath. Apparently on the 2600jr this chip is also used to buffer the reset signal, so we can’t just cut it out of the circuit entirely.

At that time I was planning to try to keep the RF shielding in place (this is basically required if you want to keep the RF output), but later on I decided not to keep it and repurposed the RF output RCA jack for audio. I could have just used the extra space to avoid this horrific chip massacre. However, it actually worked quite well.

What didn’t work well was the S-Video signal. First off I switched the chroma and luma signals by mistake. This is pretty typical and was probably inevitable. Then I plugged in Pitfall II, and got… this:

Chrominance looks like it might be okay; trees are green, the Activision logo has a rainbow. But the luminance is clearly out of control. Thankfully, it turned out that this was an easy fix, covered in this thread on the AtariAge forums. The UAV is covered in two rows of pin headers, to route the CD4050’s signals to the correct place. The guide claims you should use a certain pattern for the 2600, but that’s only valid for the Heavy Sixer.

It makes perfect sense that with the entirely different circuit board, the inputs to the CD4050 were switched around. In case the AtariAge forums go down at some point, here’s the layout I used.

Unfortunately, you need an arrangement that doesn’t allow for simple pin jumpers, so I had to solder a wire. Here’s how the final outcome looks. Note that I just grabbed audio from the A3 VIA, and did not use the universal audio board also sold by the same company.

And you’ve already seen the outcome of this: it produced all the 2600 screenshots from this blog post. (Except for Atari Football. I know, I know, it’s a super common game…) But here’s RealSports Boxing. Seriously, why can’t the 2600+ play this? I’m just really curious now.

Looking good even over the Framemeister. And here it is over composite; this is using a “StarTech”-branded adapter, I’m not sure if others might have less noise. But you can see a big difference; especially look at “(C) ATARI 1987” text. But that’s composite video for you.

Future plans

So you might wonder whether I intend to make my own 2600 game. And the answer to that is no. I think the later 6502 systems (NES, PC Engine) are more my style to play around with.

As for the 2600 itself, there are a few things I’d like to do. They’re all pretty minor, so if something interesting happens while doing them you might hear about them, but otherwise, I probably won’t bother.

Improve the video port

This 2600jr was quite cheap. Part of why that was is because its plastics were damaged, with a big hole on the side near the front, where I shoved the cables for the S-Video port through.

It’d be nice to clean this up, enlarge the hole enough to make the port flush with the console. This would also have the benefit that putting in and removing the cable wouldn’t result in straining the wires. Just needs some time with a file.

Improve the power port

The Atari 2600 uses a 9V DC power supply, which is pretty common. What’s less common is the port– it uses a 3.5mm TRS jack, like a pair of headphones, except mono. One wonders how many Walkmen got destroyed by these things. Not only is the jack different (though the contemporary Pinball Breakaway does use the same), the TRS jack isn’t great for power purposes; it’s very easy to short.

Interestingly, the connector used on the 2600jr has a small internal switch you can just barely see on this contrast-adjusted image, which doesn’t activate its pin until the connector is fully seated. But the circuit board doesn’t take advantage of this. I’ll probably just replace it with good old-fashioned 9VDC center-negative barrel jack, which will let me use the same plug I use for the Famicom and Master System. Just need to find a jack that fits with minimal filing.

Improve the power regulator

Finally, while putting things together and testing I burned my finger slightly on the power regulator, a linear 7805. This thing gets hot! And it’s not well heat-sunk on the board, even when the RF shielding was present, it didn’t make good thermal contact.

I’ve got the parts for this in the mail and will install them as soon as I get them, because this doesn’t feel quite safe.

Now I have played Atari today, are you happy?

So that’s the Atari 2600. Or the Video Computer System; I didn’t call it by that name in this post because my 2600jr is most definitely a 2600. I don’t think with any other consoles is the way the limitations of the hardware come across in the games so obvious; as are how herculean the efforts to overcome those limitations are. Anyway I don’t know how to end blog posts here’s Air-Sea Battle