The Priority Registers
Bill Wilkinson
Those of you who have studied the Atari Hardware Manualhave probably been overwhelmed by the number of "registers." There are registers that define the start of the character set, the origin of the display list, the graphics mode, the Direct Memory Access modes, the amount of horizontal and vertical scrolling, the colors of the playfields and players, and much, much more. And yet, for the most part, the use of these registers is fairly clear and distinct, one from another. For example, you certainly know that a register called "COLPF2" (COLor of PlayField 2) wouldn't be used to define the start of the player/missile graphics area (that's the job of "PMBASE").
But are there some exceptions to this "separation of work" philosophy? Well, one might seem to be "DMACTL", which can turn players and missiles on and off, turn the playfield on and off, and determine whether players and missiles have single- or double-line resolution. And yet the register's varied functions can all be justified under the heading of "Direct Memory Access ConTroL".
However, there is one register which does seem to have several unrelated functions. From the viewpoint of both software and article authors, the functions which this register controls are all extremely interesting. Yet little has been written about this register's dominant function. Naturally, I hope to change that.
What's In A Name?
The register in question was named "PRIOR" by Atari. It is important enough that it was even given an Operating System shadow location, "GPRIOR", at 623 (decimal). (A "shadow location" is a RAM location into which a program may store a value actually intended for a hardware register. During the vertical blank interrupt processing--that is, every 60th of a second with U.S. NTSC television and every 50th of a second with the European PAL system--the Operating System ROM code moves each shadow location to the corresponding register. The purpose of this is usually to force the register load to occur at a time when the screen is blanked, thus avoiding strange and bizarre visual effects.)
So just exactly what does this location control? Several things. Let's start with a recap of the table in Atari's Hardware Manual.
|
Bits Bit Bit Bits |
0-3 4 5 6-7 |
Priority Select Fifth Player Enable Multiple Color Player Enable Special GTIA Display Mode Selects |
Well, at least it's true that half of the register is used for "PRIORity" work, but wow! Look at all the other goodies.
This article is not going to deal with the extra GTIA modes (GRAPHICS 9, 10, and 11 in BASIC parlance), but I would like to invite you to court disaster. If your machine has a GTIA chip (as do most recent models), then sometime when you have a nice listing or display on the screen, try using POKE 623,128 or POKE 623,64 or POKE 623,192. If you do it when a listing is on the screen, you will quickly see why Atari doesn't provide mixed mode (text window) graphics for modes 9, 10, and 11. (Incidentally, if nothing happens when you do the POKEs, you don't have a GTIA.) Oh, yes, you can POKE 623,0 to return to normal.
The real "discoveries" to be explored in this section are the influences of bits 4 and 5, but before I delve into them, I would like to at least touch on the capabilities of the priority select bits.
Who's On First? What's On Second?
Atari states that each of the four priority select bits will produce a single type of supposedly mutually exclusive priority ordering of the various players and missiles. For example, if bit 0 is turned on (POKE 623,1), all the players have "priority" over all the playfields (and everything always has priority over the background). Within the group of players, a lower-numbered player has priority over a higher-numbered one.
But what does it mean to say something has priority? Simply this: since each player moves independently not only of the playfield but also of every other player, it is possible for one or more objects to appear at the same spot on the display screen at the same time. "Priority" simply answers the question of who gets displayed first, second, etc. An important point to remember: only those parts of player stripes containing "on" bits (i.e., only those parts to be made visible) participate in the priority contest! The "off" portion of all players is totally ignored by the system.
In theory, a lower-numbered playfield takes precedence over a higher-numbered one. In actuality, there is no way for two playfields to occupy the same video space, so the distinction is a moot one (except for one obscure case, as we shall see below). Anyway, here is a table of the various available priorities:
Bit 0 (POKE 623,1): All players, all playfields.
Bit 1 (POKE 623,2): Players 0 and 1, all playfields, players 2 and 3.
Bit 2 (POKE 623,4): All playfields, all players.
Bit 3 (POKE 623,8): Playfields 0 and 1, all players, playfields 2 and 3.
Although the bits are described as mutually exclusive, there is nothing to prevent you from turning on two or more (e.g., POKE 623,7). The theory says that if you overlap any two objects whose priorities are "in conflict" as a result of the multiple bits being on, the display will turn black in the overlap region. This would mean that if you used "POKE 623,5" all players would turn black except when over the background. I have yet to see a program use this to advantage, but no doubt somebody will someday.
And one final note: the whole reason for having priorities is so that you can gracefully control what happens to players when they meet the background display. Imagine that we select bit 3. Then if we have an airplane made from players, clouds in playfield color 0 or 1, and mountains in playfield color 2 or 3, the plane will fly in front of the mountains and yet behind the clouds!
When Is A Missile Not A Missile?
Atari would have you believe that the answer is "When it's a player." The name of Bit 4 of PRIOR is enticing: "Fifth Player Enable." Wow! We can turn this bit on and all of a sudden we have five players, right?
By default (i.e., if this bit is not set), each player takes on the same color as its "parent" player. Turn this bit on, and all missiles share a single common color. And that is all this bit does. Period.
What color do the missiles use? Playfield Color 3. Why was that color chosen? Because, in the normal graphics modes, the only way to get that color is in GRAPHICS 1 or GRAPHICS 2, the large text modes. Notice that there are five SETCOLORs available, even though most graphics modes allow only two or four colors to be displayed. Since the background (SETCOLOR 4 in four-color modes) is always one of these (COLOR 0), one of the SETCOLORs--in point of fact, SETCOLOR 3--goes unused. Until now.
So how can you use the four missiles as a single player? From BASIC, it's not easy. Each missile still retains its own independent horizontal position. Each missile still retains its own independent horizontal width. And, naturally, you still have to move the player/missile stripe vertically (although that is easier to do for a player than for a missile). This means that, for such a simple operation as moving the new "player" horizontally to (say) position X, you must perform this series of BASIC statements:
POKE HPOSM0,X
POKE HPOSM1,X + 2
POKE HPOSM2,X + 4
POKE HPOSM3,X + 6
And even thatonly works if you have previously specified that all the missiles have single horizontal width (admittedly the SYSTEM RESET default).
Any other caveats? Yes. The missiles still act independently as far as the collision registers are concerned. And the Atari documentation claims that the priority of the new "player" is the same as that of Playfield 3, but that's only partially true. In particular, when considering which playerhas priority, it is true that the fifth player behaves according to the chart. But, strangely enough, the fifth player alwayshas priority over anyplayfield color. This might imply some interesting consequences for a creative game designer.
So, is this "Fifth Player Enable" bit actually useful? From pure BASIC, I think not. With some machine language support, probably. And, of course, from pure machine language (or C or FORTH or Pascal), you can probably do some really interesting things. After all, how many moving objects do you see in PacMan or Jawbreaker?
All Colors Of The Rainbow
How many times have you read that, even though the Atari can display 128 different colors, it can display only four of those at a time? Well, you probably know by now that it's simply not true. First of all, if you have a GTIA, it's actually possible to display 16 different colors on the playfield in two of the GTIA graphics modes, and nine colors in the other mode. But let's go after the maximum number of colors possible.
To begin, choose GRAPHICS 11. That will get you 16 possible hues, each with the same luminance. Great.
Now, let's add four players, each with its own color and each different from any of the playfield colors. Now we are up to 20 colors!
But we're not done: why not use the "Fifth Player Enable" bit to get yet another color (since Playfield 3 is not involved in the GRAPHICS 11 playfield display). Twenty-one colors!
But.... Yep, you guessed it, there's more. Remember that bit titled "Multiple Color Player Enable"? If you turn on that bit (POKE 623,32 or POKE 623,49 to also do all we just described), then pairs of players that overlap will generate yet another color in the overlap region! Actually, the valid overlap pairs are limited to Player 0 joined with Player 1 and/or Player 2 overlapping Player 3. (If Player 0 or 1 overlaps Player 2 or 3, the priority rules still apply. )
So there you have it. Twenty-three colors displayable at the same time. And I believe that, without resorting to display list interrupts or similar chicanery, that is the Atari computer's maximum.
But that isn't the real reason I introduced the Multiple Color Player Enable. Do you have an object that you want to animate that is just begging to be multicolored? Here is your method of implementation. And if you need even more than three colors, you could use all four (or three, or five) players to display it. If you need to animate only a single object, the multicolor players could give you some very nice control over both detail and color.
Unfortunately, to do effective multicolored work, you must devote two players to each animated object. Even if you use the "fifth player" trick, this limits you to three moving objects. Yet I can't help but think that this is a solution waiting for a problem. Come on, game designers, get to work.
We need to make a couple of points before we leave this subject: by default, missiles behave the same as their parent players. That is, if the multiple color players are enabled and missile 0 overlaps missile 1, then the overlapped region will result in the third color being displayed. But Atari did it right: if you choose the fifth player option, the missiles all take on that fifth player color and the missile overlaps have no effect.
And, finally, I would like to say that I have not yet figured out how to predict what the third color, displayed in the overlap region, will be. The hue and intensity in the region do not seem to directly relate to that of the overlapping colors. Generally, the intensity is brighter than the duller of the two, but it is not always brighter than the lighter. It seems to me that the resulting color might be some sort of vector addition of the other two colors, but I don't know that. Want to write an article for COMPUTE! ? Here's a topic for a good one.
A Hair-Trigger Reaction
Before we leave this section, I think an example of some of the capabilities we have been discussing might be in order. In the discussion that follows, we will be referring to the diagrams in the figure.
The aim here is to design a "crosshair" using players. Obviously, we could make an adequate crosshair with a single player, but that wouldn't give us a chance to try out what we've been discussing. So examine the first three parts of the figure.
First, we define Player 0. Note that I have supplied the hexadecimal and decimal values necessary to produce each line (i.e., byte) of the player for those of you who would like to actually try this. Anyway, notice the gaps in what is otherwise a nice cross shape.
But if we now define Player 1 as shown, and purposely overlap the two players correctly, notice that we get a nice, two-colored crosshair. This is version one.
For version two, we assume that PRIOR=1 (POKE 623,1). We redefine Player 1 so that its "hole" in the middle is gone. And yet, when we overlap it with the original Player 0, we get the same results we did with version one. Why? Simply because Player 0 has higher priority than Player 1, so the bits in the middle of Player 0 effectively override those in Player 1.
But finally we get to version three. The only difference between this version and version two is that now we have turned on the Multiple Color Player Enable bit. Lo and behold, since the very center has bits turned on in both Player 0 and Player 1, we achieve yet a third color. A most satisfactory and colorful crosshair.
So there you have it. Some fairly impressive displays have been generated using players, and yet I have still not seen one that takes advantage of all the features we have discussed here. So, if you are a "do-er," do it!
Return to Table of Contents | Previous Section | Next Section
