Assembly Language
MULTI-COLORED PLAYERS
How the pros enhance moving images
by PATRICK BASS, Antic ST Program EditorHere's an advanced, professional method for creating as many as four multiple-colored players. This tutorial article is designed for advanced asssembly language programmers. Included is a short demonstration program writtne in MAC/65, which should be easy to adapt for the Atari Assembler Editor.
By the time you get to be an intermediate Atari programmer, you are probably aware that one of the most powerful features of Atari computers is Player/Missile graphics for moving pictures around. All Atari 8-bit computer models have four 8-dot-wide "players" each with their own 2-dot-wide "missile".
These can be moved around the screen without disrupting the background "playfield," using a completely electronic means that closely mimics the "chroma-key" process which movie studios use to "paste" a small part of one picture into a larger picture.
But one of the bigger stumbling blocks in this process is the fact that each Player/Missile combination can be assigned only one color at a time. You may choose to have a "multi-colored player" only if you design two or more players to overlap, and set a special bit in the GTIA chip. The trouble here is that the overlapping section of the players cannot be assigned a color of its own, and two or more players are used where one should be enough.
TAKING OVER
However, it is possible to take over the responsibility of coloring the players ourselves – instead of leaving it to the GTIA chip. Then we can design individual Player/Missiles with as many as 256 colors in them, in any order.
This article is now going to describe techniques that go beyond the Atari's normal performance envelope. So please be forewarned that from here on, I am assuming that the reader is a seasoned 8-bit Atari machine language programmer.
A while back, I needed to animate four human figures running across the screen simultaneously. I had to use Player/Missile graphics for the figures, but the players wouldn't look very human if they were each a single color from head to toe.
Interestingly, I got my answer from talking to people who were programming the Atari 2600 Video Cartridge System. You see, the 2600 game machine doesn't have fancy smart chips inside it that know how to draw a TV picture – like the ANTIC or GTIA chips inside Atari computers.
The programmers had to tell the 2600, scan-line by scan-line, what to draw and what to color. Thinking along these lines, I figured that if I told the Atari 8-bit to stuff Player/Missile colors scan-line by scan-line, I might be able to get line-by-line coloring for my players.
THE SOLUTION
Basically, my routine worked out like this. I chose a section of the screen that the players never ventured out of. For this example, let's say the players never get higher than scan-line 32 ($20) and never get lower than scan-line 182 ($B6). We need to take over player coloring control from the computer between scan line 32 and scan line 182. In the Display List for that screen, insert a Display List Interrupt on the scan-line you want to start coloring on. In our example, it's scan-line 32.
When the interrupt (an NMI) happens, you will enter your interrupt routine just as the scan-line is ending. Now for the next 150 scan-lines, perform a WSYNC – stuff player color cycle. The WSYNC will sync you to the start of each scan-line in turn.
When released from WSYNC, increment a scan-line counter. Using the value of the counter as an index into a table of colors, pick up the indexed player color for the new scan-line and stuff the new color into the player color hardware register – NOT the shadow location. When you have reached the scan-line to stop coloring on (in our case, line 182), clean up our mess and return from the interrupt.
Notice that this loop will, quite literally, slave the 6502 processor to the TV scan rate for a short period, and during this time it will not allow any processing of game code to go on. Keep in mind how quickly the computer operates, as compared to how fast the TV is drawing its picture.
However, since the WSYNC will release the processor after the scan-line beam has started its travel from (our) left to right we have time for only three or four LDAs and STAs before the scan-line becomes visible from within the HBLANK interval. Our current demonstration does more work than can be hidden. So a LDA...STA process shows up in the Hamburger, whose shape and colors get updated on the left side of the visible screen.
SUBROUTINE THEORY
Player color for each scan-line is in a map that matches the player shape exactly. Since a player shape maps out as a vertical strip of horizontal bytes, if a player shape is ten scan-lines high, then the player color shape should be ten scan-lines high. When the player shape moves one scan-line up or down, move the player color shape one scan-line up or down. In this way, the player's colors will follow the player's shape. The DLI loop transfers the entire player shape strip and color strip from the starting scan-line to the ending scan-line during each displayed frame. As long as the shape and color strip are synchronized, the player remains properly colored.
With this in mind, let's examine the demonstration program. Type in Listing 1 and SAVE a copy before you RUN it. The program is written in 6502 assembly language using the MAC/65 assembler-editor from Optimized Systems Software.
This program will design and bounce four multi-colored players around a video screen. Each player has a different shape and 14 to 16 separate colors. Note that most of the program is just preparation for the main coloring routine. The section that you would include to color your own players is only one subroutine long.
PROGRAM TAKE-APART
Lines 100-2280 contain label definitions and equates. Also in this section are the Display List and portions of reserved memory.
Lines 2300-2640 define two useful macros, a "Load Word" macro and a macro to force the program counter onto the next higher even-page boundary.
Lines 2670-2830 contain the entire section of main run-time code. Notice the short loop in which the section winds up waiting. This would be the area where normal game processing takes place.
Lines 2850-3130 contain the main work of the coloring routine. This code is called from a DLI. You would include a section very much like this one in your own multi-colored player program.
Lines 3160-3560 are called from Vertical Blank. They detour each player to its proper movement routine.
Lines 3590-3810 contain the Vertical Blank Routine. This decides a new direction, moves the player's position there and moves the player image and color.
Lines 3840-4350 contain initialization code. This does things like setting the playfield and initially drawing the players.
Lines 4380-4640 contain each player's color image.
Lines 4670-5260 decide the source and destination of each player image, and then move the images.
Lines 5290-6300 try to move the player in one of four directions. If that direction is not available, the image position is moved back and the direction flag is toggled.
So here's a small package that proves Atari 8-bit computers can have multi-colored Player/Missiles. The concepts here may be a bit advanced. But after all, the capability is already there in the Atari. All you need to do is use it.