A Self-Modifying P/M Graphics Utility

Kenneth Grace, Jr.
Colts Neck, NJ

The utility in Program 1 sets up a skeleton program for player/missile graphics. It presents a series of questions about the P/M situation you want to create and then modifies itself according to your responses. I hope you will find the program useful. But I also hope it will stimulate your thinking on other ways to use the self-modification ability, introduced by Bruce Frumker in COMPUTE! (August, 1981 #15). I also want to give some further publicity to a method for controlling P/M motion using string manipulations, as introduced by George Blank in the April 1981 issue of Creative Computing.

There are several steps involved in setting up P/M graphics, and they have been covered in COMPUTE! and elsewhere. The steps are easy, but there are several choices available along the way (resolution, number of players, colors, positions, etc.). That's where this utility comes in. It contains all the basic steps, and where there are choices to be made, they are presented to you. The program then uses Frumker's technique to add lines to the program. At the end it uses the same technique to delete lines that are not needed, including the lines which ask the questions.

When the utility has finished, you are left with the skeleton of a P/M graphics program. You can RUN it at this point to check things out. But to make it a real program, you will have to draw the playfield and add the main loop for controlling motion, checking collisions, etc. In other words, the utility does just the P/M setup. However, note that there are some subroutines included which you can use for player motion.

Since I make extensive use of Frumker's technique, I have split it into two subroutines, at 9900 and 9910-9920. Between the two subroutine calls I put PRINT statements for the lines to be added to, or deleted from, the program.

Aside from these two subroutines, the heart of the program is in lines 3-66. Lines 3-55 present the series of questions through which you define your particular P/M arrangement. The self-modifying feature is used after every question or two to add the appropriate statements to the section beginning at line 9000. At a few places the program STOPs while you enter lines containing SETCOLOR statements for the playfield colors or DATA statements containing the bytes defining the shapes of the players and missiles.

At the end of this sequence lines 56-66 and 9930 delete lines 3-66, the unneeded P/M motion routines in 100-185 (when you have less than four players and four missiles), and other unneeded lines in 9000-9700. I couldn't figure out how to get rid of all the unnecessary lines, so later you may wish to delete lines 9900-9960.

When the utility has finished, you are left with lines 1-2, 99, appropriate subroutines from 100-185, a trivial loop at 200, and the P/M setup steps starting at 9000. Note that lines 20-24 and 9030 take account of Fred Pinho's rules (COMPUTE! September '81, #16) for placing P/M memory so that it doesn't overlap the memory for the BASIC GRAPHICS mode. Starting from this skeleton, I suggest that you use lines 3-98 for REMarks, opening titles, instructions, etc., and begin your main program at line 200.

Motion Using Strings

The string manipulation method for player motion is based on Mr. Blank's column mentioned above. I refer you to that article for a detailed explanation. The basic idea is that you trick your Atari into treating the Player/Missile memory as the string array storage area for PO$,P1$,...,M$. Lines 1-2 and 9500-9580 do this. Atari's fast string handling routines can then be used for vertical motion of the players or for animation.

In order for this to work, PO$,PI$,...,M$ must be the first variables mentioned in the program. I suggest that you turn off power momentarily, then key in line 1 and the rest of the program. In line 2, VTAB is a pointer to the start of the variable table, which contains eight bytes for each variable. ATAB points to the start of the string array table, which is where the actual values are stored. Each pass through lines 9530-9570 modifies the eight bytes for PO$ (or Pl$, etc.) in the variable table, including the offset from ATAB where the actual values for PO$ are stored (the P/M graphics memory).

The bytes defining the players are stored in strings DO$,D1$,... at lines 9090, 9140, 9190, etc. Each character in a string is stored in memory as a byte containing the corresponding ATASCII value. In this case, we want our data BYTE treated as though it were already an ATASCII value, so we use D0$(I,I) = CHR$(BYTE). Note that this is a different way of using strings for P/M from Alan Watson's method (COMPUTE! September 1981, #16). The demo mirrors Watson's example.

The descriptions D0$,Dl$,... are initially read into P/M memory (i.e., into P0$,Pl$,...) at lines 9600-9680. The string variable B$ will be our "blanking" string, so we fill it with ATASCII values of zero at line 9690. If you have a player which is no longer than 30 bytes, adjust the DIMension of B$ accordingly.

To produce vertical motion of a player, the subroutines at 100-133 write over the active part of the existing P$ with blanks from B$. Then D$ is written into P$ at the new position, higher or lower than before.

Vertical motion of a missile is slightly more difficult. The problem is that all four missiles are stored in the same memory. Each missile occupies a two-bit slice of the eight-bit bytes in this memory. Thus, we cannot simply write whole new bytes or blanks into this memory.

Instead, using a machine language routine, we AND the existing memory with a binary mask, such as 11111100, leaving zeroes in the appropriate two-bit slice. To this we add the new image from DMx$ or B$. The images being added have zeroes outside the two-bit slice, so they won't affect the images of the other missiles.

Lines 9700-9730 read the machine language routine into the string MOVE$. The missile motion subroutines at 150-185 make two USR calls to this routine, once to write the new missile image and once to blank out the rest of the old image. The last variable in the USR call is the decimal equivalent of the binary mask.

Program 2 presents a demonstration of the use of the utility and of the motion routines. The demo attempts to duplicate Watson's animation program. The top part of the listing shows the answers you should give to the questions presented by the utility. The bottom part shows the lines to be added to the skeleton. Lines 300-530 match Watson's line numbers as closely as possible. A comparison of this demo with Watson's program shows that the motion here is somewhat faster – listen to the rate of the "footsteps."

There you have it – a useful utility, a thought-provoker on self-modifying programs, and a neat way to move those spaceships!

Mr. Grace has offered to save you the work of keying in this lengthy program. Just send a stamped, self-addressed mailer, $3 and a blank cassette to 33 Dana Lane, Colts Neck, NJ 07722.