Why can't the Atari 2600 display better graphics?

[pojr]

It sounds like a really stupid question, but let me explain.

 

 

This is Double Dunk on the Atari 2600. For a game made in 1989, it sure looks unappealing. Why are the pixels so large on the basketball court? Look at the sprites, their pixels are much smaller. I'm guessing the background pixels are larger than sprite pixels in every Atari game, right? Compare it to this game:

 

 

This is Robot Tank, released in 1983. Look at the extreme detail. The background isn't pixelated like it is in Double Dunk, and the Activision logo looks perfect. If a game released in 1983 has decent graphics, why can't a game released 4 years later have it?

 

Now I have another question. It's something that has boggled my mind for many years. It's regarding Centipede on the Atari 2600.

 

 

That's a pretty nice title screen. Nice logo, nice centipede animation, now lets check the gameplay.

 

 

What?! Why does it look worse than the title screen? Couldn't they copy and paste those mushroom things to the gameplay itself? My understanding of the Atari 2600 is limited, but why couldn't they have the graphics in the gameplay look like they do on the title screen?

 

Anyway, those are all my questions. I know the Atari hardware is limited, but it seems like part of the reason the graphics on these games were so bad was because they weren't work on at full potential. Anyone know? Thanks in return.

[Kiwi]

The Atari 2600 can only display 2 8-bit sprites, 2 missile and 1 ball object on one scan line. There's 20 pixel register playfield that can be symmerical or mirrored to get 40 pixel one one scanline. The atari 2600 draw each scanline every frame.

 

As for Double Dunk, the developer during that year are really avoiding flickering sprites to get more object on one scanline, like it is a poison. Missile Command could not be done without sprite flickering. They could have put more color into that court. Probably ran out of processor cycle, plus the Atari 2600 only has 128 byte of RAM. Who knows what's up with that game.

 

The sprite can be sized or cloned. I produced this image to show you what the sprite looks like.

 

 

The missile can be clone like the sprites. Also can be 1x,2x,4x,8x the size. The ball object is the same, except it can't be cloned.

 

There's more reasons, like the Atari 2600 only has 4 colors, but it'll take all night explaining everything.

[SeaGtGruff]

It sounds like a really stupid question, but let me explain.

No, it actually isn't a stupid question at all.

 

 

This is Double Dunk on the Atari 2600. For a game made in 1989, it sure looks unappealing. Why are the pixels so large on the basketball court? Look at the sprites, their pixels are much smaller. I'm guessing the background pixels are larger than sprite pixels in every Atari game, right?

That's right, the playfield pixels-- which, together with the background color, can draw a two-color "background" against which the sprites move-- are each as wide as those fat vertical lines, as well as the big pixels. But the playfield pixels can be very thin in the vertical dimension-- as thin as one scan line, which is why those horizontal lines are so thin.

 

Compare it to this game:

 

 

This is Robot Tank, released in 1983. Look at the extreme detail. The background isn't pixelated like it is in Double Dunk, and the Activision logo looks perfect. If a game released in 1983 has decent graphics, why can't a game released 4 years later have it?

The playfield pixels are still just as fat, as you can see in the mountains in the background. The rest of the screen, where it looks like the pixels are much smaller-- including the Activision logo-- are drawn using players, missiles, and the ball, which can have much thinner (width-wise) pixels.

 

Now I have another question. It's something that has boggled my mind for many years. It's regarding Centipede on the Atari 2600.

 

 

That's a pretty nice title screen. Nice logo, nice centipede animation, now lets check the gameplay.

 

 

What?! Why does it look worse than the title screen? Couldn't they copy and paste those mushroom things to the gameplay itself? My understanding of the Atari 2600 is limited, but why couldn't they have the graphics in the gameplay look like they do on the title screen?

 

Anyway, those are all my questions. I know the Atari hardware is limited, but it seems like part of the reason the graphics on these games were so bad was because they weren't work on at full potential. Anyone know? Thanks in return.

The title screen is drawn using mostly player sprites, so the mushrooms can look like mushrooms. But in the actual game screen the mushrooms have to be drawn with those fat playfield pixels, because all the other objects on the screen (the bugs and the DDT bombs) are drawn with the players, and there's a limit to how many times you can draw the players on each line-- there are only two player sprites, but you can display up to three copies of each player on a line. In fact, the game has to flicker the screen to be able to draw all the bugs at once. So the mushrooms look like little blocks instead of mushrooms. This actually isn't so bad when you're playing the game, because the gameplay is so frantic that you're too busy blasting or dodging the bugs to be worried about what the mushrooms look like. On the other hand, it does make it difficult to tell how many times you've shot a mushroom.

 

Michael

[R. Jones]

It sounds like a really stupid question, but let me explain.

Sounds like the beginning of a fascinating discussion.

 

Sorry I don't have more to add.

[Armonigann]

Because its the 2600, anything else would be uncivilized. (in charles barkleys' voice)

[Nukey Shay]

You could also mention that Centipede's title screen is using sprite copies (i.e."clones") to make most of those mushrooms. Sprite copies cannot be drawn just anywhere...they are preset to happen at very specific distances from the sprite actually being drawn - at an 8, 24, or 56 pixel distance to the right of it's original. Worse yet...if you were to shoot away the actual sprite, the program would have to intelligently reposition it so the copy didn't go away as well. But to even get that far, the program also would need to be able to recognise if the original or one of it's clones was hit (a sprite copy shares it's collision register with the original). Add to that the problem that the machine needs to burn time just to move the drawing position of a sprite for others that follow below it.

 

All of these decisions take cycle time to execute...and the 2600 only has a very limited time to draw (which happens to be the time it takes the electron beam in your television to get from one side to the other). You gotta keep in mind that this thing was designed to only display 5 movable objects in an entire screen (2 8-pixel sprites, 2 1-pixel missiles, and the "ball").

 

In addition, the 2600 has no "screen memory". The native hardware provides 128 bytes and that's it (which was plenty in 1977 terms...seriously underpowered in 1982). It doesn't even "remember" what had been drawn...it'll just keep spilling the same pixels onto the screen until instructed to write a different value.

 

Centipede uses the compromise of drawing mushrooms with those fat playfield pixels everyone is familiar with, and reserves more of it's screen time to drawing the actual enemies with the sprites.

 

 

However, some impressive displays can be done if a program takes advantage of advanced techniques - such as very-specific code portions decided beforehand, or using a larger "cache" of ram memory to spool a whole lot of data to the screen...rather than deciding the if's and when's as it's being drawn.

 

 

It may not look it, but Centipede is still impressive because it's keeping track of all those "blocks" representing mushrooms, and all the other enemies and variables without using ANY added ram. It's using the native 128 bytes only...just like the old days.

Edited March 11, 2011 by Nukey Shay

[pojr]

I read every post. So from what I understand:

 

The more sprites that line up horizontally, the more flickering since the Atari scans horizontally. If sprites line up vertically, they don't flicker?

 

Sprites can make copies, but they have to be a certain length apart. The sprite copies don't contribute to flickering?

 

Background pixels are extremely wide, but are not very tall, which is why backgrounds can make narrow horizontal lines.

 

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

[Kiwi]

In summary:

The Atari 2600 is designed to be a pong machine. 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 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.

 

 

PO = Player 0

M0 = Missile 0 basically 1-bit graphics with 3 different sizes with cloning.

BL = Ball which is an object that can be anywhere on screen with 3 different size 1x 2x 4x.

P1 = Player 1

M1 = Missile 1

 

Player 0 and missile 0 share their color. Player 1 and missile 1 has their color to share. Ball has to use Playfield color. I hope this clear some more things up.

 

(Yes I am a little nutty and making that mock-up to make it look like it can be display on an atari, and I need to sleep.)

[Nukey Shay]

Hiding HMOVE by calling it 1 or 2 cycles early existed long before Halo It also doesn't work on some with some console versions (late model Jr cannot hide HMOVE in this manner).

[Lord Helmet]

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.

[Nukey Shay]

The more sprites that line up horizontally, the more flickering since the Atari scans horizontally. If sprites line up vertically, they don't flicker?

Basically, that is correct (if we are dealing with a single sprite object of the available five). To implement the latter, sprite muliplexing would need to be used. Multiplexing is ignoring the sprite definition that existed on preceding scanlines, and repositioning/rewriting it during the display to act as a new sprite. This method robs resources...you'd normally need to create some kind of sprite list that has all of this decided before entering the display kernel to draw the screen...and pull these variables out of the "cache" and deal with them individually as the screen is being drawn.

Depending on the complexity of the display (and what resources you have available), multiplexing may not always be an option.

 

 

Sprites can make copies, but they have to be a certain length apart. The sprite copies don't contribute to flickering?

No flicker...because a copy is just a double or triple image of the sprite. However, a sprite's bitmap image may be altered before the copy needs to be displayed. This is how games are able to create 48-pixel images (like the Activision logo) using just the 2 8-bit sprites. Another advanced method is to rewrite the copy or positioning registers AS the line is being displayed (this is how Galaxian gets 7 sprites on a line with no flicker).

 

 

Background pixels are extremely wide, but are not very tall, which is why backgrounds can make narrow horizontal lines.

Playfield pixels are 4 sprite pixels wide. Bitmap information is sent to 2 8-bit registers and 1 4-bit register (20 pixels). That creates the left side of the display. The same bitmap image is either reversed or mirrored to create the 20 pixels on the right. If you wanted the 2 sides to differ (asymmetrical...such as dot patterns in Pac-Man), the registers' bitmaps need to be altered as the scanline is being drawn.

 

But "tall" does not really apply to anything. The 2600's sprite and playfield registers are used to create a single scanline. Doing nothing on the next scanline will simply cause the same information to display for the next (this is a problem if your original scanline is designed to rewrite the registers as it's being drawn, tho). An image can therefore be as "tall" as you want. Most are familiar with the random color bars that appear if the console is powered up with no cartridge present. This is simply the random values that exist in the display registers spilling out to the screen over and over - there is no program present to alter them.

 

 

 

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

Just Atari's names for the sprites. These have no bitmap register that the players do (Atari's name for the 8-pixel sprites)...they can just be enabled or disabled. These 3 additional sprites have limitations, tho. Missile sprites take some of their characteristics from their corresponding player sprite (such as number of copies and color), while the ball sprite gets it's information from the playfield registers (color and whether it overlaps the other sprites...called sprite priority). However, each one of them can use their own amount of stretching.

To save setup time, a missile sprite can also be "locked on" to it's corresponding player's position. This makes it easy for a program to initialize a missile from it's corresponding player's horizontal position on a scanline. In other words, if you "shoot a gun", just have the missile sprite lock on to wherever the player is when the "gun" is fired...and begin moving it from there.

 

Another handy set of registers contain horizontal motion information. By setting the HM's to move a sprite a given number of pixels whenever HMOVE is called, the program does not need to deplete from it's resources...it just updates wherever the given sprite(s) is drawn horizontally. In this manner, a "bullet" only needs to be tracked vertically to decide when to enable the missile sprite. The HM register can handle the horizontal. A simple Pong game can be programmed using only a few bytes of ram...2 holding the vertical location of when to draw the paddles, and one to hold the vertical location of when to enable the ball. A forth byte keeps count of the number of scanlines drawn to match either one.

Pong is such a simplistic game that the entire program can be fit into the native ram (so you could powerup the console with a cartridge that puts the program in ram, and be able to play the game even if you remove the cartridge later).

[atari2atari]

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.

 

As well, picking up a copy of "Racing the Beam" is a great way to get a solid, and entertaining, understanding of the limits and abilities of the 2600.

 

I just re-read it again recently, and it is STILL a great book!

 

-a2a

[0078265317]

Maybe after all these years you mod guys can make a super 2600 with 4gb ram 1tb hd to hold all the games and supped up graphics.

 

But even back would of probably costed too much to add more than 128k of ram amd better graphics.

[Nukey Shay]

The 2600 can do amazing things with what it DOES have...and the hardware doesn't even need all that big of a push to make a program seem as if it's not the 2600 at all (like Starpath's Frogger).

[tz101]

That's right, the playfield pixels-- which, together with the background color, can draw a two-color "background" against which the sprites move-- are each as wide as those fat vertical lines, as well as the big pixels. But the playfield pixels can be very thin in the vertical dimension-- as thin as one scan line, which is why those horizontal lines are so thin.

 

Ummm, doesn't that background in Robot Tank have more than two colors? Sort of looks that way to me.

[Nukey Shay]

He's referring to "per scanline"**. Robot Tank "draws" the sky, dark part of the mountian, ground, and status display portions simply by changing the background color. The only playfield pixel data being sent to the display are the upper parts of the mountians and the crosshairs.

 

EDIT: I forgot to include the rainbow effect of the logo...that was done by having the playfield pixels turned on partway through altering the 6-sprite data. By altering the playfield color at the start of each scanline, the logo gets it's trademark effect.

 

**However, even that limitation does not apply if a program is altering playfield/background colors mid-scanline. There's even a "cheat" of sorts built-in to the system. The register that controls playfield aspects can be written with "score mode" activated. On any scanline it's active, the playfield color for the left and right sides of the screen will take it's data from the player sprite colors instead. That is how all those old games drew different-colored scores on either side of the screen.

Edited March 12, 2011 by Nukey Shay

[Nukey Shay]

Also, playfield pixels have one advantage over the background color. Sprite priority (part of the same playfield register) can be set to display playfield pixels OVER sprites instead of under. Background color does not have this advantage...it's always "underneath" everything else.

[tokumaru]

Ummm, doesn't that background in Robot Tank have more than two colors? Sort of looks that way to me.

The graphical limitations (number of colors, players, missiles, etc.) usually refer to what can be done at any given time (not necessarily a scanline), but those parameters can be modified as the image is rendered by the console. The image is drawn from top to bottom, left to right, at the same time as the program is running. During this time, the program is free to modify sprites, colors, nearly everything. If the program keeps track of the image rendering process, it can make strategic changes to the display at appropriate times.

 

This makes it possible for a program to set the background color to blue at the top of the frame to draw the sky, but at some point down the image modify that color to brown to draw the ground. From the point of view of the hardware, there is only one active background color at any given time, but the program is free to modify what that color is several times per frame. The same "trick" can be used for all the other graphical elements, allowing for much more complex graphics than the raw specs would have you believe is possible.

 

The problem is that all these changes have to be done by the CPU, which has limited processing power. This means that the amount of changes you can do to the video is limited by how that processing power is distributed. It's much easier to go crazy with tricks in a title screen because they are very predictable. Since title screens are mostly static, you know where each graphical element will be, so you can focus the CPU power in specific screen regions. During gameplay, however, all kinds of objects can fly all around the screen, which means you need much more generic logic in order to be able to display all possible combinations of positions the game allows.

 

This is why you can't just "copy" a more detailed sprite from the title screen into the game, as the logic responsible for drawing the screen in both cases is completely different. Unlike an image in MSPaint, which is just a 2D array of equally sized pixels, the Atari display is composed of several objects that look and behave differently from each other, and they need a program behind the scenes to manage them. Because of this, the complexity of Atari graphics is not only dictated by the limitations of the video hardware, but also by how well the CPU is used to manage it and how much CPU time is dedicated to each aspect of the video, and this will change from programmer to programmer.

 

Another limiting factor that plays a part in the graphical complexity of the games is ROM space. The earlier games had only 2KB and 4KB of space, not enough to store the game program and a lot of detailed graphics. This is why most early games were very blocky and used few colors. Even if there was enough CPU time to modify the colors mid-frame, there wasn't any space left in the ROM to store the list of colors to use.

 

Nowadays, since we can have huge amounts of ROM (like, 512KB or even more), I believe games could have very impressive graphics. Very detailed sprites with incredibly smooth animation, backgrounds with new colors nearly every scanline, things like that.

[SeaGtGruff]

That's right, the playfield pixels-- which, together with the background color, can draw a two-color "background" against which the sprites move-- are each as wide as those fat vertical lines, as well as the big pixels. But the playfield pixels can be very thin in the vertical dimension-- as thin as one scan line, which is why those horizontal lines are so thin.

 

Ummm, doesn't that background in Robot Tank have more than two colors? Sort of looks that way to me.

Yes, the playfield pixels and the background basically form a lo-res two-color backdrop composed of a foreground color (the playfield color) and a background color (the, uh, background color). Computers and video game consoles usually have a certain number of "paint cans" or color registers that you can draw with, and the 2600 has only four such "paint cans"-- the COLUBK register (background color), the COLUPF register (playfield and ball color), the COLUP0 register (player 0 and missile 0 color), and the COLUP1 register (player 1 and missile 1 color). So in essence, you can draw with only four colors at a time, and each color is used to render a specific portion of the graphics display-- e.g., you can't use the player 0 or player 1 colors to draw the playfield, at least not normally (there *is* a special playfield mode where the left side of the playfield is drawn with the player 0 color and the right side of the playfield is drawn with the player 1 color, but it has its own limitations).

 

But even though you can draw with only four colors at once, and each color is used to render a specific graphics feature (or pair of features), the 2600 has a minimum of 8 total colors (SECAM model) and a maximum of 128 colors (NTSC model) that it can display, and you can change the color that's loaded in any of the four color registers. Color changes are normally made during the horizontal blank between one scan line and the next, so that's why you often see backgrounds or playfields or sprites that display horizontal stripes of different colors. But you can also change colors while a scan line is being drawn, although this is done less often (except in static types of displays) due to timing considerations-- e.g., if the screen is scrolling horizontally, then the color change(s) would need to occur at different times so they stay in step with the scolling screen.

 

However, you've just exposed a misconception on my part, which I discovered as I was about to discuss a way you can see how specific screens were created. 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.

 

This is Robot Tank with everything turned on:

 

 

This is with player 0 turned off:

 

 

As you can now see, the right side of the farther mountains is gone. So that means player 0 is being used to draw part of the farther mountains! I had mistakenly assumed that the mountains were drawn with the playfield, because the pixels are so wide.

 

This is with player 0 turned on again, but player 1 is turned off:

 

 

Now you can see that player 1 is used to draw the left side of the farther mountains. But if you wait until the demo mode kicks in and the screen starts to scroll, you'll see that player 0 and player 1 move, so player 1 isn't always on the left and player 0 isn't always on the right.

 

This is with everything except the playfield turned off:

 

 

Everything you see now is drawn by either the playfield or the background.

 

And this is with the playfield turned off, too:

 

 

This may be the most interesting picture of all, because it shows just how much of the screen is drawn using nothing but the background, but changing the background color from line to line-- or even, in the bottom area of the screen, in the *middle* of the scan line. Note that the bottom part of the screen is stationary-- it doesn't scroll-- so that's why it's feasible to change the background color mid-line.

 

So I stand corrected-- the mountains (and sky) are actually rendered using a combination of the background, playfield, player 0, and player 1.

 

Michael

[+Random Terrain]

For those who know nothing about assembly language, but know a little about BASIC, once the latest beta version of batari Basic is all fixed up, you'll be able to make your own Atari 2600 games that have better graphics:

 

• Support for 10 multicolored sprites (player0-player9)
  _
  
• Asymmetric multicolored playfield, any resolution.
  _
  
• Simultaneous single line background and foreground colors.
  _
  
• Playfield allows independent resolution control for each 8-pixel column.
  _
  
• Use of extra RAM in DPC+ (extra 256k can only be used for data).
  

 

 

Related Links:

 

http://www.atariage.com/forums/blog/134/entry-7832-batari-basic-11-beta-with-dpc-kernel/

 

http://www.atariage.com/forums/blog/134/entry-7932-bb-11-beta-build-release-b/

Edited March 12, 2011 by Random Terrain

[ScumSoft]

The engine I've been working on for my game changes things quite a bit. I've more or less taken the limits on horizontal positioning of P0/P1 and threw them out the window.

(I had to go fetch my Atari from the neighbors yard afterwards but this is another story)

 

Instead of worrying about a P0 sprite being placed all over the screen for multiple things, I've decided to lock it in place along with P1 in a 3 by 3 config, 8 pixels apart then splitting this between 2 frames. At the end of the first frame and in the overscan, I move P0 and P1 over 8 pixels which fills in the gaps. This causes some flicker to happen, but only when the entire screen is one color, for smaller sprites it provides very little flicker, more like a shimmer effect.

 

So what this effectively did, was give me a 96x192 software controlled playfield with 12 sprites per scanline and 24 rows for a total of 288 unique sprites.

How one uses this is another story, as I am still creating the control logic behind it all. But so far it is VERY flexible and should allow for all sorts of new and neat things to be drawn. After drawing a scanline I have 27 cycles left, and in the interlaced lines I have 64 cycles free. This allows just enough time to stuff a 12-byte pixel buffer with the next scanlines data. Couple this with smart masking and you have a nice display that can do per pixel stuff. It also allows me to set 2 unique colors per sprite, so that is 24 colors per scanline total. I am currently coding the rotation kernal for moving images left and right.

 

The only sad limit, is while you can do so much, it is limited to 96 pixels wide. So to get around this limit, I've come up with the idea(not completely implemented yet) to move the 96 pixel viewport around the screen as my player moves. This gives the illusion that the world is staying still and only the viewport is moving within the screen bounds.

 

I was hoping to have a demo up today, but there are some delays I didn't foresee. Hopefully before this weekend is over I'll have something nice to show everyone.

Edited March 12, 2011 by ScumSoft

[maiki]

Centipede is still impressive because it's keeping track of all those "blocks" representing mushrooms, and all the other enemies and variables without using ANY added ram. It's using the native 128 bytes only...just like the old days.

 

And that's why I consider games like Centipede and Pitfall 1 as the real 2600 masterpieces. Sorry, but by adding extra hardware like RAM or sound chips it's not Atari 2600 anymore hence games like Defender 2 are really not 2600 masterpieces anymore.

[Nukey Shay]

It is banking, tho...and you could theoretically redo some of the superchip etc. games by throwing a virtually unlimited (well, more than you could ever use) amount of rom banks at the problem areas. Need the fine scrolling mountians of Defender II without wasting cycles? Just bank to a kernel dedicated to drawing the mountian at that specific location...that sort of thing. (bad example I know...since the game doesn't really rely on the SC's ram to do this).

 

How many banks of ROM is a game allowed before it ceases to be a 2600 game?

[+Random Terrain]

If you can plug it into the Atari VCS cartridge slot and play it, it's an Atari 2600 game. Doesn't matter if it has 20 gigabytes of RAM and a magical half unicorn fairy living inside of the cartridge.

 

From 1982 through 1984 when I was still in high school, the kids I knew were happy and impressed when a cartridge had extra stuff in it. It was a selling point. Who wouldn't want better graphics and larger or more complex game worlds? With new tricks discovered and constant advancements in cartridge technology, the Atari 2600 really could have been what they promised:

 

http://www.atarimania.com/pubs/hi_res/pub_everything_you_always_wanted_to_know.jpg

Are they a passing fancy,

like Hula Hoops?

 

They're exactly the opposite. The ATARI

Video Computer System™ Game is not a toy

to be put in the closet and forgotten. It's a

permanent part of a home entertainment

center. And just as there are constantly new

records available for your stereo, Atari will

constantly offer new Game Program™

cartridges for your system.

 

If the Atari 2600 is supposed to be a permanent part of our home entertainment centers, of course the cartridges should become more advanced over time. Atari cartridges grew with us. As we demanded more complex games with better graphics, Atari and some third-party companies delivered. If Atari could have kept their promise, who knows how advanced Atari 2600 cartridges might be today with nonstop advancements through the 1990s and 2000s?

Edited March 12, 2011 by Random Terrain

[SeaGtGruff]

Centipede is still impressive because it's keeping track of all those "blocks" representing mushrooms, and all the other enemies and variables without using ANY added ram. It's using the native 128 bytes only...just like the old days.

 

And that's why I consider games like Centipede and Pitfall 1 as the real 2600 masterpieces. Sorry, but by adding extra hardware like RAM or sound chips it's not Atari 2600 anymore hence games like Defender 2 are really not 2600 masterpieces anymore.

 

It is banking, tho...and you could theoretically redo some of the superchip etc. games by throwing a virtually unlimited (well, more than you could ever use) amount of rom banks at the problem areas. Need the fine scrolling mountians of Defender II without wasting cycles? Just bank to a kernel dedicated to drawing the mountian at that specific location...that sort of thing. (bad example I know...since the game doesn't really rely on the SC's ram to do this).

 

How many banks of ROM is a game allowed before it ceases to be a 2600 game?

 

If you can plug it into the Atari VCS cartridge slot and play it, it's an Atari 2600 game. Doesn't matter if it has 20 gigabytes of RAM and a magical half unicorn fairy living inside of the cartridge.

 

I agree with Random Terrain, although I can see all sides of the issue. A game that pushes the envelope without using any extra ROM or RAM is more impressive than one that uses extra ROM or RAM, but only if the two games are accomplishing the same things through different methods, I think-- that is, they're indistinguishable from each other as far as having identical screen displays, identical game play, the same number of levels, etc. The reason I say this is because a game with extra ROM or RAM can push exactly the same envelopes as a "pure genius, pure 2600" game, using exactly the same programming tricks, and I don't see why the game should then be given a lower score on the "how impressive" scale just because it also happens to use extra ROM or RAM to do even more, such as adding many more levels, creating a larger map in an adventure game, etc. On the other hand, if the game that has extra ROM or RAM is accomplishing exactly the same things as the "bare bones 2600" game, but is accomplishing them more easily because of the extra ROM or RAM, then I'd say that it *is* less impressive as far as the programming is concerned.

 

Nevertheless, just because a game uses extra ROM or RAM doesn't mean it isn't a 2600 game, because it still has to contend with the same hardware limitations of the 2600-- the TIA chip, the 6532 RIOT chip, the 6507 CPU with its 8K address space (which is reduced even further by the way the chip select lines connect the TIA and RIOT and 6507 together), the clock speed, and of course the console design with its switches and I/O ports. In fact, you might even say that *every* 2600 game uses "extra ROM," since the ROM is on the cartridge and is added to the 2600 by plugging in the cartridge-- which is how the 2600 was designed to work. If you add more ROM with bankswitching, it's still conforming to the original "plug it in" design. If you replace some of the cartridge ROM with RAM, it's still conforming to the original design. Commavid's "Video Life" doesn't even use bankswitching, but it does replace some of the plug-in cartridge ROM with RAM.

 

I think where you truly begin to cross the fuzzy line as to whether a game is "a true 2600 game" is when you have to rely on something extra that isn't provided on the cartridge-- some kind of add-on module that must be purchased separately from, and in addition to, the cartridge. The Supercharger is an example of this, because a Supercharger game on cassette is unplayable unless you also have the Supercharger itself, as well as a cassette tape player to load the games with. They're still 2600 games, but they're *Supercharger* 2600 games. A game that has some kind of additional processor chip in the cartridge is also beginning to cross the fuzzy line, but at least you get everything you need on the cartridge and don't have to purchase anything else just to be able to play the game. Likewise, games that rely on something extra like the SaveKey are also beginning to cross the fuzzy line, at least if they *rely* on the SaveKey-- not as far as being able to save your games or your high scores, but in the sense that the game will not function correctly at all unless a SaveKey is also used. But they're still 2600 games.

 

The thing is, "the line" (as I see it) isn't a clear, sharp, 1-pixel wide black line drawn on a white background-- it's really a wide boundary that gradually changes from white to black, with every shade of gray in between. From a purist's point of view, anything that takes even one tiny step into the lightest gray area of that boundary isn't a "true 2600 game." That would mean "Video Life" isn't a "true 2600 game," because even if doesn't use any bankswitching, it does add extra RAM. You could try to devise a scheme for assigning a game's position within that boundary-- does it use bankswitching, how much extra ROM does it bankswitch, does it add extra RAM, is the extra RAM bankswitched as well, is there an additional processor chip on the cartridge, does the game rely on something extra that must be purchased separately, etc. But I don't think you really cross over into the black "definitely not a 2600 game anymore" zone until you have a game that no longer plugs into a stock 2600 and plays on a stock 2600-- and by "stock 2600" I mean one that hasn't been taken apart and modified to replace the TIA or RIOT or 6507 with something else, some change to the basic internal workings of the 2600 (which does not include modifications for the outgoing video signal to get a better picture).

 

Michael