Part 12: Tech Post 4: The Status Window

Tech Post 4: The Status Window

Are you getting tired of this screen yet? I kind of am.



Let's finish it off. The only remaining component is the status window—the brown part at the bottom of the screen.

The Radar

I'm paying no attention to how the radar decides what to draw, or which numbers or directions it decides to draw. I'm just going to focus on how it actually draws what it draws.

First things first: Notice that, except for the line down the middle of it, the black parts of the radar display are symmetric. This is again mostly playfield work. There's one cute trick here which is that on the line before and the line after the radar display, the playfield color is set to the same brown as the background. This gives us hundreds of cycles worth of wiggle room to actually configure the playfield the way we want.

Once it's been configured, the playfield color is set to black and altered as needed to produce the little pips around the edges. Meanwhile, the background color is changed from brown to blue and back to brown again over the course of each scanline to make the body of the radar. If the radar is damaged it picks a random color to display and then that's it for your radar.

That does leave the vertical line and its little pips. That, as it happens, is the Ball. The Ball is placed once as part of the preparation for this display and then the little pips on the display are constructed by altering the Ball's horizontal expansion. Graphically, the Ball is treated as an extension of the playfield, so we don't have to worry about things like color divergence, and when the playfield is made the same color as the background, the Ball follows suit. Very convenient.

The object in the radar is played by Player 0. This is actually the first time in this entire investigation we've encountered a player graphic that hasn't been set to "three copies, closely spaced." There's no real surprises there, but we do see a feature of the 2600 we haven't looked at yet: you can configure whether the player and missile graphics are above or below the playfield. So that the "crosshairs" of the radar are superimposed over the tracked object, we've set them to "under the playfield" priority. And since the Ball is considered equivalent to the playfield, that works for the vertical bar, too!

That leaves the arrows and the numeric display. These are portrayed by Player Sprite 1, in the "two copies, widely spaced" configuration. Wide spacing starts the two copies 72 pixels apart, for 64 pixels of actual blank space between them. That's plenty of room for the radar display in the middle.

Easy, right? Well, no. There's something wrong with my description. With everything I've described so far, the radar numbers should be invisible, buried underneath the playfield. After all, we've set the playfield priority to supercede the player and missile graphics, right?

The solution is almost traditional at this point—alter the priority value as needed, mid-scanline. This is another comfort afforded us by the playfield chunks being broad enough to hold a complete sprite; it lets us alter both the screen background and sprite priority without either effect showing up too soon. We just barely have time for two writes before and after the radar display before we're back to what needs to be blank, brown background. The background color is changed on the outer write, then the priority is changed on the inner write. The end result juggles each piece of the display for just long enough to produce the visual effect they wanted.

With me so far? Great, because now the gloves are coming off.

Fuel and Lives

This is a fairly complex display.



We've got a series of flags on the left and then a fuel gauge that decays pixel by pixel. Pixel level operations are always a nightmare, but studying the player graphics as they are drawn over time confirms two things: the flags and the gauge are both drawn with player graphics, with 0 and 1 next to one another, and they're actually always drawn completely (that is, a full gauge and four flags signaling five lives).

This also means, since the fuel gauge is the same 8-bit pattern repeated four times, that you don't need the 6-digit score trick—you're only actually doing two writes during the sprite display and then you can leave it alone from there on out.

Now, that alone gives you an incorrect display, but we've actually got a bigger problem here. Four flags at two per sprite, two sprites to spell out FUEL, and then four sprites worth of fuel gauge is eight sprites. Even with player replication we only have six! What gives?

When I went digging into this I expected to find that the player sprites were somehow being repositioned each scanline. But no; the Player sprites are firmly placed with their leftmost location as the start of their respective halves of the word FUEL. However, once the gauge is drawn, the replication parameter was changed from "three copies, 16 pixels apart" to "two copies, 72 pixels apart." Apparently the replication logic inside the Television Interface Adapter isn't tracking what it's already drawn—man, what a waste, why would you do that—but is instead checking to see "well, given where it is, has it been the right number of pixels worth of time since then to start drawing?" And it is, so it does. But the fuel gauge is so far to the right of the screen that the "second" (actually fourth, but who's counting? Certainly not the Atari) sprite has wrapped around and is on the left side of the next line.

Which means we then need to ask an additional question: what's a "next" line? The Atari only knows about one line at a time. So once you've placed the sprite and set up this replication strategy, you're just loading graphics into place exactly as if you had eight sprites spread out over each scanline.

Awesome. Now there's just the issue of how we don't always have five lives and a full tank.

The key insight here is that each life flag, and each complete unit of fuel, is four pixels wide. So is each unit of the playfield. So the playfield color is set to the background color, given priority over the player graphics, and then each time you die or burn a full unit of fuel an additional brick is added to the playfield.

That's all you need for lives, but fuel needs pixel level control. So, what's like the playfield but can be independently positioned with pixel accuracy and also might be expandable out to four pixels in length?

Yep, it's the Ball. With the Ball covering any fractional fuel use, and the playfield covering any entire unit consumed, you can block drawing the right-hand side with pixel precision.

NEXT TIME: We start cracking the secrets of the flight screen.