Compute!'s First Book of Atari Graphics

5 Animation With Player/Missile Graphics

Introduction To Player/Missile Graphics

Bill Wilkinson

This article describes the features of the Atari player/missile graphics system ("P/M graphics" for those of us with lazy typing fingers). Although there are now other systems available with similar capabilities (notably "sprites" on the Commodore and Texas Instruments TI 99-4A computers), there are several aspects of P/M graphics which are uniquely and powerfully Atari.

For reasons having to do with lack of information and (often) an abundance of misinformation, many Atari owners think of players and missiles as some mysterious aspect of the machine which requires convoluted machine language and arcane rites to control properly. In truth, P/M graphics is in many ways less mysterious than the standard Atari "playfield" graphics. Have you yet truly deciphered the relationship between SETCOLOR and COLOR? (I haven't. I usually use trial and error to find the connection that I need.) Have you mastered the concept of display lists? (I didn't ask if you could produce one, just if you understood the level of indirection that is needed to produce even the simplest display on an Atari. ) Player/missile graphics is actually simplecompared to some of these obscurities.

I think the first thing needed to understand P/M graphics is a little flexibility in conceiving how memory is mapped into display in the Atari computer. Consider Figure 1. As far as the Central Processing Unit (CPU) or most of the Atari hardware is concerned, memory is simply one long string of bytes. (Well, some parts of the system like to digest memory in 1K, 2K, or 4K byte blocks, but within those blocks it's all a string of bytes.) But if you look at Figure 1, you will probably soon decide that this is not a reasonable way for human beings to consider memory, especially human beings who are trying to visualize memory being displayed as graphics.

So consider instead what we know of BASIC graphics mode 19 (GRAPHICS 3 + 16). GRAPHICS 19 (which is simply a fullscreen version of GRAPHICS 3) consists of 24 lines of 40 pixels each, where each pixel occupies only two bits of memory, implying that a line is only 10 bytes long. Instead of thinking of memory as one long string of bytes, why not consider it as an array of ten-byte strings? This visualization is presented in Figure 2, and you will probably agree that this is a much clearer representation than that of Figure 1.

One more exercise before leaving this subject: try visualizing the normal text (GRAPHICS 0) display screen as a representation of memory. How many lines are there? How many bytes per line? I hope you answered 24 lines of 40 bytes each; a pictorial representation of this display mode is shown in Figure 3.

So just exactly what is a player or a missile? First, let's note that for most purposes there's no real difference between a player and a missile other than size, so all further references to "players" may be assumed to refer to missiles also, unless otherwise noted. A player, then, is simply the graphic video display of a portion of the Atari computer's main memory. "So what?" you say. "That's how all computers put stuff on the screen: by displaying the memory." True. And we just showed diagrams of how the Atari also displays its main video screen from what Atari calls "playfield memory." But players and missiles are displayed independently of the playfield and from an entirely separate segment of memory.

The "S:" ("Screen") device driver, which is what actually processes such BASIC keywords as GRAPHICS, PLOT, and DRAWTO, knows nothing of P/M graphics. In a sense this is proper: the hardware mechanisms that implement P/M graphics are, for virtually all purposes, completely separate and distinct from the "playfield" graphics supported by "S:". For example, the size, position, and color of players on the video screen are completely independent of the GRAPHICS mode currently selected and any COLOR or SETCOLOR commands currently active. In Atari parlance, a "player" is simply a contiguous group of memory cells displayed as a vertical stripe on the screen.

We again take refuge in a diagram, that of Figure 4. This figure shows a standard playfield display along with that portion of Random Access Memory (RAM) being used to generate the display (and note the representation of RAM as a series of character strings). But notice that the figure also shows another piece of memory being used to display something else on part of the screen. This "something else" is a player. And notice that the player's portion of RAM is shown as an "array" of character strings where each string is only one byte long. This is alwaystrue: allplayers are always displayed as a one-byte wide array. There are no display lists to worry about, no graphics modes (using 10 or 20 or 40 bytes per line, and which is which?), and no visualization problems. It's like being back to thinking of memory as one long string of bytes--almost.

The "almost" is the kicker. First, note that we need to make sure we are thinking of the string as being stacked vertically. Second, the pictorial representation (the player on the screen instead of the string of bytes in memory) is actually the more accurate one, since each player is always a "semi-fixed"-length: Player 1 starts on the very next byte after Player 0, and so on. Third, there are actually two choices open to the user regarding the amount of memory used by each player (hence the words "semi-fixed"): players may have very fine vertical resolution (equivalent to GRAPHICS 8), in which case they occupy 256 bytes each; or they may have relatively coarse resolution (equivalent to GRAPHICS 7), in which case they occupy 128 bytes each. But even with this minor complication, players are fairly simple, since all players must always have the same resolution.

Sounds dull? Consider: each player (and there are four or five, depending on how you think of missiles) may be "painted" in any of the 128 colors available on the Atari (see SETCOLOR for specific colors). Within the vertical stripe which is each player's display, each bit set to 1 paints the player's color in the corresponding pixel, while each bit set to 0 paints no color at all! That is, any 0 bit in a player stripe has no effect on the underlying playfield display.

Why call it a vertical stripe? Refer to Figure 5 for a rough idea of the player concept. If we define a shape within the bounds of this stripe (by changing some of the player's bits to ones as shown), we may move the player vertically by simply doing a circular shift on the contiguous memory block representing the player. Why is that easier than simply PLOTting something on the playfield and then moving it by PLOTting it again? First, since the player does not affect the playfield, any pretty picture (or text or whatever) on the main screen remains unchanged. Second, because it's a lot easier to do a circular shift on a byte string than it is to change memory cells that are 40 (or 20 or 10?) bytes apart in memory.

Finally, the real clincher: even though vertical movement requires some shuffling of a string of bytes, horizontal movement is essentially effortless. Each and every player and missile has its own independent register(i.e., memory location) which controls its current horizontal position on the screen. Moving a player stripe horizontally is as easy as a single POKE from BASIC.

To summarize and simplify: A player is actually seen as a stripe on the screen eight pixels wide by 128 (or 256) pixels high. Within this stripe, the user may POKE or move bytes to establish what is essentially a tall, skinny picture (though much of the picture may consist of 0 bits, in which case the background "shows through"). Using a simple POKE, the programmer may then move this player to any horizontal location on the screen. To move a player vertically, though, one must do some sort of shift or move on the contents of the string of bytes displayed in the stripe.

From standard Atari BASIC, there is no easy way to move these stripes vertically (using a FOR/NEXT loop with PEEKs and POKEs is simply too slow). And while there now exist languages which have built-in mechanisms to do this movement (e.g., MOVE in Microsoft BASIC; MOVE and PMMOVE in BASIC A + ), the overwhelming use of Atari BASIC has prompted many authors to try their hands at providing this movement in a form easily usable from Atari BASIC. This chapter includes sections detailing a few of the methods which have been worked out.

And now some final comments before we leave this introduction to player/missile graphics:

Missiles pretty much work just like players except that (1) they are only two bits wide instead of eight, (2) all four missiles share the same 128 or 256 bytes of memory (each using only its own bits in each byte), (3) each two-bit sub-stripe has an independent horizontal position register, and (4) by default a missile has the same color as its parent player. A later section in this chapter will delve a bit deeper into the mysteries of missiles.

There are essentially only five primary controls available to the P/M graphics user. We have already mentioned three: independent control of the various player horizontal positions, independent control of the player's colors, and system-wide control over the resolution (128 bytes or 256 bytes per player, or simply "off").

In addition, each player and each missile has an independently controllable "width." A player or missile may be specified as single-width (narrow), double-width, or quadruple-width. This width does notaffect the number of bytes or bits used for the display; it affects only the width of each individual pixel. Refer to Figure 6 for a diagram of a four-player system showing independent horizontal position and width control.

Incidentally, single-width players generated in the 128-byte vertical resolution mode have square pixels which are the same size as those in GRAPHICS 7, a presumably not altogether accidental happening.

The last control available to the user is the ability to specify where in memory the player and missile stripes are to be located. The rule is fairly simple: you need 2K bytes for single-line resolution (256 bytes per player), and it must be located on a 2K-byte memory boundary. For double-line resolution (128 bytes per player), you need a 1K-byte segment located on a 1K byte boundary.

Are you quick in arithmetic? How many 256-byte players can you put into 2K bytes? Or how many 128-byte players can 1K bytes hold? If you answered eight, you pass. If you answered five, you can go to the head of your Atari class. Indeed, with the Atari P/M memory map, you "waste" three players if you allocate the full amount of memory called for; see Figure 7 to see why.

Do you see the wasted memory? Does it need to be wasted? No. There is no reason why you can't put data, character sets, or what-have-you in this area. Indeed, in BASIC A +, part of the language is in this otherwise excess area.

And now you are ready to peruse the secrets unveiled herein; the darkest mysteries of player/missile graphics will become open to you. But don't be surprised if you find even more things that can be done with P/M graphics than we told you about here.