Ch-ch-ch-ch-changes (what the 2600 can/can't do)
Entry posted by Guest
622 views
IntroductionOne of the first steps in creating a game is often designing a screen layout. On some systems this is fairly straightforward. On something like the Channel F, the screen has a certain resolution (e.g. 128x64) and a certain number of colors; any screen layout with the proper resolution and number of colors is feasible.The 2600, however, is another story. Although it's possible to look at some proposed screen layouts and say "Yeah, that would be easy" or to look at others and say "No way", determining the feasibility of a screen layout on the 2600 requires an understanding of how one might go about producing it.On most video game systems, there is an area of memory along with a collection of registers which, together, control what is displayed on screen. Generally, these are used on a set-and-forget basis: the game code will set things up to show a screen, and then go do something else while the display controller outputs the data to the TV. Changing something in display memory or changing a display register while the picture is being scanned will often cause the affected property of the display to change mid-scan (e.g. if on every frame one changes the background color from blue to green when the beam is 1/3 of the way through scanning, and then changes it back to blue when the beam is 2/3 through the scan, this would cause the background to appear green in the middle of the screen and blue on the top and bottom) but most video game systems do not make it very easy or practical to do mid-screen updates.The 2600, however, is completely different. All its video hardware knows now to do is produce one scan line. If one doesn't do mid-screen updates, it will keep doing the same scan line over and over again. Fortunately, the 2600's design facilitates mid-screen updates (it would be really feeble if it didn't!); by changing the proper registers at the proper times during a frame it's possible to produce interesting displays.Basic hardwareThe Atari 2600 will output a scan line constructed from the following components:
- Background -- A user-specified color will be output wherever no other object is present. While in one sense the background isn't so much an object as the lack of anything else, changing the background color mid-screen allows the background to play an active role in screen design.
- HMOVE blanker -- If the HMOVE blanker is activated on a scan line, the left 8 pixels will be forced to black independent of any other objects there.
- The Playfield -- This object consists of 20 quad-width pixels and appears twice per scan line. Each pixel may be on or off, and the second copy of the playfield may either display its 20 pixels in the same order as the first copy, or in reverse order. The playfield has one 4-bit shape register and two 8-bit shape registers as well as a color register and a mode register.
- Two players -- There are two independent "player" objects, each with its own color register, 8-bit shape register, "reverse" control (which flips the shape bits left to right), horizontal position counter, and options register which allows the player to be 'cloned' up to three times or be displayed in double- or quad-width.
- Two missiles -- There are two independent "missile" objects, each with its own enable control (on or off) and horizontal position counter. Each missile shares color and options registers with a player. The options register clones each missile up to three times (the same number of times as the corresponding player) and allows the missile to be displayed as a blob 1, 2, 4, or 8 pixels wide.
- The Ball -- The Ball is like a missile, except that it cannot be cloned and shares its color with the Playfield.
The Atari 2600 supports three display modes:
- Players-in-front: Objects are assigned the following priority: HMOVE blanker, Player 0 and Missile 0, Player 1 and Missile 1, the Playfield and the Ball, and the background.
- Playfield-in-front: Objects are assigned the following priority: HMOVE blanker, the Playfield and the Ball, Player 0 and Missile 0, Player 1 and Missile 1, and the background.
- Score mode: The left and right halves of the playfield use the player color registers instead of the playfield color register; the Ball still uses the playfield color register, however. Objects are assigned the priority: HMOVE blanker, Player 0 and Missile 0, Player 1 and Missile 1, the Ball, the Playfield, and the background.
The players support the following modes:
- One copy, single-width
- One copy, double-width
- One copy, double-width
- Two copies, spaced 16 pixels apart (left edge to left edge)
- Three copies, 16 pixels apart
- Two copies, 32 pixels apart
- Three copies, 32 pixels apart
- Two copies, 64 pixels apart
For the 2600 to output a particular screen display, it must be possible to combine the display elements listed above to produce it.Ch-ch-ch-ch-ch-changesThe display components listed above are controlled by number of registers. These registers may be changed at any time by the microprocessor. Changes generally take effect almost immediately (certain changes have slight delays but they generally don't matter too much from a design perspective) so it's possible to do things like make the three cloned copies of a sprite show different shapes (just change the shape register between copies) or different colors (likewise). It's also possible to show different contents on the left and right halves of the playfield (just change the playfield registers at the right times) and do many other neat things.Just one problem.The processor on the 2600 doesn't run terribly fast. By 1977 standards, it wasn't a slouch but it wasn't a speed demon either. And compared with a Pentium IV...In practical terms, what matters is not how fast the 2600's processor is numerically (1.19Mhz) but how much work it can get done. The simplest way to figure that is in terms of "changes". Count up how many display registers changes are necessary on each scan line. If two or more consecutive changes use the same value (e.g. setting both player sprites to the same shape), count the additional changes as 1/2 change each. If there are less than six changes, things should be okay. If more than eleven, things are doubtful. If somewhere between, things will probably be tricky but may be possible.Note that because of the odd way the Atari handles horizontal motion, counting "changes" when moving sprites can be tricky. A few guidelines:
- Motion can be performed as "big moves" or "nudges". The 2600 can't do very many changes on a scan line with a big move; it's generally possible to do a big move of two or more sprites on the same scan line if and only if they move in lockstep.
- To perform nudges, the 2600 must do a "change" to set up how far each object must move, and then perform a "half-change", called HMOVE, to trigger the actual motion.
- A standard HMOVE can move objects any distance from 7 pixels left to 8 pixels right; it will also cause the HMOVE blanker to appear on the next scan line.
- A trick called an "early HMOVE" will move all objects to a position 8 pixels left of where they'd appear with a standard HMOVE (the range is thus 0 to 15 pixels left); it will not cause the HMOVE blanker to appear.
- An object can generally not be relied upon to appear on a scan line where a "big move" is done to it.
Examples of changesThe main part of the Combat screen does seven changes every two scan lines: the three playfield registers, the two player shape registers, and the two missile enables. Easily within the realm of feasibility. Note that it would only be necessary to perform the playfield updates on the scan lines where the playfield changes, but it's easier to perform them every other scan line than to avoid doing so unnecessarily.Casino does ten changes per line (five player shape; five player color). Tricky, but obviously possible (since Casino does it).Hunchy 2 does 15 changes every two lines (two playfield registers have to each be updated twice per scan line [total 8 changes]; both missile's nudge and enable registers need up be updated; in addition, one player's control register need to be updated to change the size of its missile. Finally, both player shape registers need to be updated for a total of 15 register changes every two lines.Save Mary probably does about 9.5 changes on the "busy" scan lines: one for Mary's color, one for Mary's shape, one for the falling-brick shape, two for the central playfield shape, two for playfield color (it's set to gray for the central portion of the screen and brown for the edge), and two for the falling-brick color (it's set to gray for the central portion of the screen and brown for the right edge of the cliff (which is drawn using a missile); the 1/2 change is for the HMOVE (note the HMOVE-blanker bar down the left side of the screen). It's worth noting that there are gaps in the brick pile that correspond with the scan lines where the sides of the cliff edge inward. On these scan lines, it's only necessary to do one central playfield change (to blank it) and no playfield color changes, so it's possible to change the outer playfield register and a the "nudge" registers for Missile 1 and the Ball.Additional commentsAlthough the Atari 2600 can do 11 changes per line (and in a few carefully-constructed cases even more, up to a theoretical maximum of 25) that doesn't mean you should prescribe that many. If any calculations are involved in determining how to perform a particular change, the time required for that calculation will reduce the number of changes that can be performed on that line. In addition, loop overhead will also often reduce the number of allowable changes. Although the availability of 16K and 32K cartridges makes it practical to "unroll" loops to a certain extent, it's generally good to avoid having too many consecutive "maxed-out" scan lines, so that the "looser" scan lines between them can accommodate looping instructions.One of the 'arts' of 2600 programming is drawing different parts of the screen in different ways, without the differences being obvious. For example, in Strat-O-Gems Deluxe, the portion of the screen above the foul line is actually drawn completely differently from the portion below, even though it looks much the same. In the portion above the foul line, however, one player is set for a single copy (used to draw the falling gem in the middle of the screen); the other player is set for two copies, 64 pixels apart (used to draw both the "remaining gems" counter and the "next gem" indicator). In the part of the screen below the foul line, both sprites are set for three copies, 16 pixels apart, and their positions are set 8 pixels apart. Things are done this way because above the foul line there can only be one gem per row in the middle portion of the screen, so only one player needs to be used for that; the other player can be used for the other indicators. Below the foul line there may be six gems on a row, so both players need to have all three copies available for that purpose.BTW, in Strat-O-Gems, there are two blank scan lines between rows of gems. Aside from 1.5 changes to blank both player shape registers, there are no changes during these lines. Instead, the time is used to calculate the colors for the next row of gems. It's not visually obvious that the processor is taking a break from outputting display data, but such respites are an essential part of often an essential part of 2600 display programming; if objects can move smoothly over such areas of the screen, however, it will be necessary to provide code for one or two changes even on those scan lines.Designing games for the 2600 is an interesting combination of art and science. An understanding of how displays are generated will help greatly in producing designs that fit well with the machine's abilities.
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
7 Comments
Recommended Comments