Task: Try Player-Missile Graphics in BASIC
Time: 30-60 minutes
Player-missile (PM) graphics helped make the Atari the premier arcade and graphics machine in its day. A key feature of PM graphics is the ability to draw players and missiles on the screen that are independent of the background or playfield graphics. This is a very powerful feature but can also be difficult to understand and program. Think of PM graphics as a second Atari graphics system that lives on top of the standard one used to draw objects and characters on the screen. There are a number of different books and magazines from back in the day that explain PM graphics to varying degrees of success. I have read a number of these and each is a little different. I present here one approach that makes sense to me. I encourage to read several difference sources and descriptions and find one that resonates.
One of the challenges is that the Atari is set up to move players horizontally with ease by writing the X position to a horizontal position register that is checked by the CTIA/GTIA with free cycles that are left over after it has kept track of the horizontal position of the scan line being drawn on the screen. However, positioning players vertically on the Y axis is slow in BASIC because the memory mapping of the player is upside down requiring PEEKs and POKEs to move the image in the right direction. I have tried this myself and it is indeed very slow. There are two general options. The first is to write your code in fast assembly language. The second is to call from BASIC a routine for player movement written in assembly language. The assembly code is provided in DATA statements and written to memory where it is then called and executed when needed. A variation on this approach is to store it in strings which are fast to manipulate. I personally am less fond of the string approach but I think that is because I am more familiar with executing assembly code from memory.
The particular player movement routine that I like is is provided on page 164 of Compute’s First Book of Atari Graphics. This nice method takes advantage of the vertical blank interrupt (VBLANK) after the screen is done drawing. The Atari naturally pauses to do some housekeeping before the screen starts drawing again. Atari built in the capability to run some assembly code during this VBLANK. So, we can load up our player position code into memory and then tell the Atari to look for it and execute it during the VBLANK. The nice thing about this approach is that we only need to do this once as an initialization step in the program. The Atari takes care of the rest and executes the position changes 60 time per second every time the screen is drawn. This makes this positioning code very fast and efficient.
I have taken the program provided on page 170-171 and modified it to my own understanding. Here is the basic flow of the program. Here is the text file and the ATR file with the code. I refer the reader to the book text for a more detailed description.
Lines 100-130. We first set aside 16 pages of memory for the PM graphics (lower 8 pages – 8 pages * 256 bytes per page = 2048 bytes for single-line resolution) and the display list and screen display (higher 8 pages – handles up to GRAPHICS 5) just below the top of available RAM (i.e. RAMTOP). We then calculate the memory address where the PM graphics will go (pages * 256 bytes per page). There are 160 pages on an Atari 800 with 48K of RAM. We subtracted 16 pages here to leave 144. So, our PMBASE memory start address is 144 * 256 or 36,864. There is a table in Chapter 3 of Atari Assembly Language Guide that lists the memory needed for each graphics model. You will need to set aside more than 8 pages of memory for GRAPHICS modes 6-8.
Lines 200-240. The next step is to initialize the graphics. This is important because the GRAPHICS statement must come right after the top of RAM is reset. This is because this is when the display memory is set as just below the top of memory. Note that, as stated in the book chapter, you must reserve more than 16 pages of RAM if GRAPHICS 6-8 are to be used. We then set the background color to black, turn off the cursor, and set the player color to green.
Lines 300-320. This bit of code sets the memory addresses of the player X and Y coordinates and the initial position.
Lines 400-470. This is the code that reads in the assembly code in the DATA statements to page 6 of memory (1536 = 6 * 256). Some memory is then cleared out with 0s followed by the code that reads the player graphics in (line 440). The next lines set up the PM graphics. Line 470 calls some assembly code that tells the OS to include our movement routine as part of the VBLANK.
Lines 500-520. This code prints a title on the screen.
Lines 600-660. This code is the main loop of the program that moves the player. Here, we POKE the player X and Y coordinates into a memory address that is used by our VBLANK movement routine. The player movement subroutine is called that reads the joystick.
Lines 700-810. This code reads the joystick and increments or decrements the player X and Y coordinates. It also checks the position to wrap the player around the edges of the screen.
Lines 1000-1100. These DATA statements contain the code for the assembly language routines that move the player during the VBLANK.
Lines 2000-2010. This DATA statement contains the line by line shape code for the player. A Star Wars-like tie fighter is drawn.
As I said, there are a number of references for PM graphics that you might consult as you learn. You should start with De Re Atari (see Chapter 4). There is a BASIC program there you can type in to see how slow PM graphics are without assembly language movement routines. I then recommend Chapter 5 of Compute’s First Book of Atari Graphics. The Creative Atari has some nice details you might not find elsewhere (see page 39). I found Chapter 5 of Atari Graphics and Arcade Design to be a good reference. The Atari Assembly Language Guide has some good info in Chapter 3 including a table with the number bytes taken up by each graphics mode. The Computer Animation Primer has a nice chapter on page 239. There is a book called Player-Missile Graphics in BASIC although I didn’t find it as helpful as some of the others. There are also a number of magazine articles you find using Google. See for example this one from Compute! (1985). Here is an earlier one from Chris Crawford in Compute! (1981) that also has a simple BASIC program without the assembly movement routines.
The following instructions are for running the example PM code in the Altirra emulator. You can of course type the code in by hand and run it on original hardware with BASIC or boot the ATR file and load the BASIC file using SIO2PC. Here is the text file. Here is a zip with the ATR file.
Open Altirra and load BASIC. I used Turbo BASIC XL. You can also load the built-in BASIC from Altirra from the File->Attach special cartridge menu.
Open the PM graphics file in your PC text editor or web browser and copy the text to your clipboard. Click on the View tab of Altirra and choose the paste text option from the bottom of the list. Altirra will slowly paste the text into the BASIC command line. It is important to keep focus on the Altirra window or the paste will stop and it will lose some characters.
Also try booting the ATR file in Altirra or on your Atari from your PC using SIO2PC. You must have the BASIC cartridge loaded.
Use the demo to play with different settings to learn. One of the things I noticed is that the demo ran much more slowly on Atari BASIC. The speed was much better on BASIC XL and on Altirra BASIC. Big difference! Now that I have covered custom display lists, redefined character sets, and player-missile graphics, I will try putting these together into a more complete game demo. Stay tuned!