Why can't the Atari 2600 display better graphics?

[+batari]

In summary:

The Atari 2600 is designed to be a pong machine.

This is false. The presence of player graphics is enough to disprove it. Also, Combat was co-designed with the console so if anything it's a Combat machine (but even that isn't quite true. It was designed to play multiple, advanced (at the time) games.

If you read the documentation(Atari-age), then you might understand how this machine was designed and why I stated it is designed as a pong machine.

I've read all docs and nothing suggests it's a pong machine. Someone later may have incorrectly inferred this though.

I think this system had to be the most exploited system out there. For example, the high resolution 6 digit scoring system. The 12 digits letters and numbers text using alternating lines. Now just recent, Halo 2600, discovered early HMOVE to remove the pisky black line that is on the left side. HMOVE is used to reposition sprite.

Halo 2600 did not pioneer this technique. The earliest known use of this was around 1983 for an unreleased prototype. Also, batari Basic kernels have been using it since 2005.

[Joe Musashi]

In summary:

The Atari 2600 is designed to be a pong machine.

This is false. The presence of player graphics is enough to disprove it. Also, Combat was co-designed with the console so if anything it's a Combat machine (but even that isn't quite true. It was designed to play multiple, advanced (at the time) games.

 

Yep. There is an iphone app by David Crane ("The internal magic of the ATARI 2600") where he writes:

 

"Two tanks, to missiles and a ball - not a coincidence. This system was given a removable ROM cartridge so that Atari could sell 'Tank' and 'Pong'. Every other game was a bonus."

[Nukey Shay]

Is there a technical reason that the system was limited to handling 5 sprites instead of, say, 8 as the 8-bit computer does? I understand that would have required a handful of additional bytes of ram for the processor to deal with...but would it have had the power to do so?

[ScumSoft]

I read somewhere else here, that it was a compromise of the Tia designers realized only too late. There wasn't an expectation during design that programmers would exploit more potential from the system than originally anticipated.

 

It was designed for basic games...

 

"Programmers break free. Programmers expand to new territories. Painfully, perhaps even dangerously. But Programmers find a way"

[littleman jack]

Seems like this discussion comes up from time to time and its always interesting. If you haven't seen Stella At 20 you should try and track down a copy and watch it. Listening to the people that were there talk about the development of the 2600 is amazing.

 

It really is insane the variety and quality of games that have been squeezed out of the old 2600. For a pong machine its simply incredible.

 

Also, the book Racing the Beam does a pretty good job at explaining how the 2600 displays graphics. And it does a pretty good job at explaining a lot of other things about Atari as well. It's an interesting read.

 

PS-Post 12 says this same thing. Sorry I posted before reading the entire thread. I second post 12. Racing the Beam is a good intro to a lot about the 2600.

[Schizophretard]

My line would be modifying the 2600. If you could play a game without modifying the 2600 then it is a 2600 game.

[MegaManFan]

Old fart time: I remember thinking even as a kid that Atari 2600 graphics were pretty shitty. (WAIT! Don't get up in arms yet, I'm going somewhere with this.) Pac-Man and Space Invaders were the killer apps at the time, but to me they killed it dead. I could spend a quarter at the arcade and get a vastly superior experience. I could save up my money and get the Commodore 64 version and not spend the quarters any more. I truly, honestly, didn't get it. BUT...

 

... my parents had a Pong console when I was 3 or 4 years old that I thought was the greatest thing EVER.

 

The problem is that technology developed lightning fast for video games, both in terms of what arcades could offer, and in terms of what home consoles and computers could simulate/recreate/innovate. The Atari VCS was the cutting edge of console technology at the time. Now you know what they say about computer processing power right? (If you don't, look up Moore's law.) If you think in those terms, the Atari VCS was dated the moment they started producing it, and two years later it was obsolete.

 

What you have to evaluate, when you look at why the Atari VCS is not only historically important but still so beloved, is because (1.) gameplay was superior to graphical display and (2.) some people found some HELLAFIED ways to tweak out that obsolete hardware to the maximum. If you've never played Thrust+ before, you could hardly have the "why do the graphics suck" question after that answer.

 

It's not that the system can't display better graphics, it's that you need a better programmer to achieve the maximum potential out of the minimum that's available to work with. But even when the graphics on a game like Centipede or Defender might suck ass compared to the arcades, let alone the other consoles and computers available from the same era, they replicated the gameplay well enough to make it enjoyable.

 

And eventually, someone came along and hacked the vastly superior Ms. Pac-Man 2600 into Pac-Man, and all was right in my world.

[Joe Musashi]

Is there a technical reason that the system was limited to handling 5 sprites instead of, say, 8 as the 8-bit computer does? I understand that would have required a handful of additional bytes of ram for the processor to deal with...but would it have had the power to do so?

 

Interesting question, why this odd number? Then again the sprites aren't all the same and each group (player, missiles, ball) has either 2 or 1 sprites.

 

I would guess this was just limited by transistor count. When looking a the schematics for the player-missile logic ( http://www.atariage.com/2600/archives/schematics_tia/TIA_1A_400dpi_3.zip ) there is a note: "This circuit must be duplicated. Serial names in paren. are for duplicate circuit.". Having 4 our 8 of them was probably too expensive.

[Rik]

I'm no adept at 2600 programming or the technical details, but it just blows me away at how much of a versatile machine the 2600 really is.I mean look at the 1st games done on the 2600, then look at the fantastic home brews of today.Another question would be,"What other programming tricks can be done on the 2600 that improve graphics, sound etc.?", has the 2600 reached it's limit?It seems this machine never ceases to amaze, truly an amazing piece of video gaming history.The 2600 really is the KING of video gaming consoles IMO.

[potatohead]

Yeah, agreed. It's been very interesting to watch people continue to squeeze more out of it over the years. Remarkable.

 

And I like the VCS graphics. Always have. To me, they just feel right, and that's totally because the VCS was the first machine I ever spent time with, that was not one of those analog PONG machines.

 

The different sounds, lots of colors, and for the time, cool controllers were just techy in a way that is notable.

[R. Jones]

[ . . . ]

 

I have no ideas what missiles and "the ball" are.

They're one bit graphics. The TIA can only remember one horizontal line at a time. Each line consists of the background colour and a symmetrical playfield composed of twenty blocks (They're drawn as four pixels wide.) Each line also five movable objects: two players, two missiles, and the ball. The players are 8 bit graphical objects(pitfall harry and the treasure) and the ball/missiles are one bit pixels that can turned on or off and set at different widths (vines in Pitfall!).

 

AD's tutorial explains it better than me.

[+Nathan Strum]

The Stella and z26 emulators let you turn specific graphics features on or off, and doing that can reveal which graphics features were used to draw specific parts of a screen.

You can also enable "fixed debug colors", which color codes each graphic type. I think it's a fascinating way to reveal the underpinnings of a game:

 

 

[tz101]

But why all the differing specs for the different on-screen icons? Even if the VCS was originally only intended to be a pong and tank machine, why did Atari's engineers make ball and missile sprites so different from the horizontal blocks from the vertical blocks. Though it is all most likely speculation, I would like some input as to why the wasn't simply made to display and move pixels around the screen no matter their size or color configuration. It couldn't have been that hard to figure this out in 1976.

[Nesbroslash]

Well, not all the games are good by graphics. I for one, kind of enjoy Star Ship and a few of the earlier things. Except for Golf and Miniature Golf. Those are damn AWFUL, in both graphics and gameplay.

[Nukey Shay]

But why all the differing specs for the different on-screen icons? Even if the VCS was originally only intended to be a pong and tank machine, why did Atari's engineers make ball and missile sprites so different from the horizontal blocks...

Because it's impossible to get the playfield pixels any smaller under TIA's design.

 

...from the vertical blocks

"Vertical" is a figment of your imagination. Everything is done scanline-by-scanline on the VCS.

 

Though it is all most likely speculation, I would like some input as to why the wasn't simply made to display and move pixels around the screen no matter their size or color configuration.

Cost vs. function. Computers had the ability at the time...for a price. Some of these "enhancements" were going to be part of the VCS' successor until they realised it would make a better home computer (400/800) than a console. The punchline is that it eventually did, in a sense (5200).

[SeaGtGruff]

The Stella and z26 emulators let you turn specific graphics features on or off, and doing that can reveal which graphics features were used to draw specific parts of a screen.

You can also enable "fixed debug colors", which color codes each graphic type. I think it's a fascinating way to reveal the underpinnings of a game:

 

 

Thanks, Nathan! I actually have never tried the "fixed debug colors" before. It *is* easier to see what's what on the game screen that way.

 

But one thing I like about turning the graphics features off and on is that if you turn all of them off, you can see how much of the screen was drawn using just the background-- which you can't really see/appreciate if all the background has a fixed color.

 

Still, I'll be checking out the "fixed debug colors." It looks like the two methods complement each other rather nicely.

 

Michael

[+SpiceWare]

Though it is all most likely speculation, I would like some input as to why the wasn't simply made to display and move pixels around the screen no matter their size or color configuration. It couldn't have been that hard to figure this out in 1976.

As Nukey Shay says, cost. Atari had to do things like use just 128 bytes (not KB, not MB, just bytes) of RAM in order for it to be affordable. When the VCS was released in 1977 it sold for $199, which would be equivalent to $726 today.

[+wood_jl]

As Nukey Shay says, cost. Atari had to do things like use just 128 bytes (not KB, not MB, just bytes) of RAM in order for it to be affordable. When the VCS was released in 1977 it sold for $199, which would be equivalent to $726 today.

 

And there I was, criticizing PS3 launch price. Heck, even the 3DO was up there. If they'd have put a "relative to Atari VCS in 1977 dollars" reference price, it wouldn't have looked so bad. LOL.

[potatohead]

Good grief! That's about 70 cents per bit of storage!

[Keatah]

In simple layman's terms: The appeal of the 2600 would be how close the graphics on the TV set are to the main microprocessor. The data comes out of the microprocessor and goes to a tiny custom chip of only a few thousand transistors and then straight to the TV set. There is nothing in between to get in the way.

[pojr]

While I'm still here, might I ask the difference between the background and playfield? Is there only a limited amount of time you can use playfield pixels?

Edited May 19, 2011 by pojr

[Nukey Shay]

Playfield and background utilize their own color settings (COLUPF, COLUBK). COLUBK always has the lowest "priority". Although COLUPF can be overridden by a flag in CTRLPF - called "Score mode", the left and right halves of the screen will be drawn using whatever color is currently used for the 2 player sprites. The hardware can detect if any of the 5 sprites are touching the playfield (via collision registers).

 

I don't know what you mean by the second question. Playfield pixels are set by writing to the playfield registers PF0(upper nybble), PF1, and PF2. Just as with the sprites, whatever the last bitpattern(s) sent to them is continued to be used until rewritten with different value(s). This creates the 20-pixel pattern on the left half of the screen. The pattern on the right is determined by the setting of CTRLPF...either a reversed image of those 20 pixels (PF0-PF1-PF2-PF2-PF1-PF0), or a mirror image (PF0-PF1-PF2-PF0-PF1-PF2). If an asymmetrical pattern is desired, a program must rewrite the PF register(s) as the scanline is being drawn. In such a case, rewriting the register(s) too soon or too late (as the scanline is being drawn) would result in a garbled image.

[Nukey Shay]

I think the timing goes something like this for ®eversed CTRLPF to create an asymmetrical image:

 

Register/cycle range
|     PF0   |     PF1   |     PF2    |  PF2 |     PF1    |     PF0    |
| -2 to +22 | -7 to +27 | -18 to +38 |  +48 | +38 to +59 | +27 to +70 |

 

If you, for example, rewrote PF2 so that the storing instruction ended at cycle 46 instead of cycle 48 into the current scanline...the bitmap pattern on the left side of the screen would have it's last 2 playfield pixels overwritten by the new pattern intended for the right half of the screen.

[pojr]

For the second question, I meant whether or not there is a limited amount of playfield pixels you can use in a scanline.

[Nukey Shay]

For the second question, I meant whether or not there is a limited amount of playfield pixels you can use in a scanline.

 

It's always 40 pixels. The on/off states for the left side of the screen are defined in PF0 (4 pixels), PF1 (8 pixels), and PF2 (8 pixels)...then mirrored or reversed for the right side of the screen.

 

Mirrored CTRLPF:
|     PF0 (left)    |               PF1 (left)              |               PF2 (left)              |    PF0 (right)    |              PF1 (right)              |              PF2 (right)              |
|bit4|bit5|bit6|bit7|bit7|bit6|bit5|bit4|bit3|bit2|bit1|bit0|bit0|bit1|bit2|bit3|bit4|bit5|bit6|bit7|bit4|bit5|bit6|bit7|bit7|bit6|bit5|bit4|bit3|bit2|bit1|bit0|bit0|bit1|bit2|bit3|bit4|bit5|bit6|bit7|

Reversed CTRLPF:
|     PF0 (left)    |               PF1 (left)              |               PF2 (left)              |              PF2 (right)              |              PF1 (right)              |    PF0 (right)    |
|bit4|bit5|bit6|bit7|bit7|bit6|bit5|bit4|bit3|bit2|bit1|bit0|bit0|bit1|bit2|bit3|bit4|bit5|bit6|bit7|bit7|bit6|bit5|bit4|bit3|bit2|bit1|bit0|bit0|bit1|bit2|bit3|bit4|bit5|bit6|bit7|bit7|bit6|bit5|bit4|