Document Title: [AtariBWvec.html (html file)]
(Extreme thanks to Duncan Brown for passing along this time consuming information!!)
VECTOR ROM OR DISPLAY LIST CODE (as seen by the State Machine):
Byte 1 Byte 2
8 7 6 5 4 3 2 1 8 7 6 5 4 3 2 1
| | | | | | | | |
| | | | | | +--+--+- Y length (or rise)
| | | | | |
| | | | +---------------------------+---------- Overall scale factor
| | | |
| | | | (8 7 6 5)
| | | | | | | |
| | | | +--+--+--+------------- Command (or scale)
| | | | (3 2 1)
| | | | | | |
| | | | +--+--+----------------------------- X length (or run)
| | | |
+--+--+--+----------------------------------------- Brightness
For the X and Y values, it's like taking the byte1bit4 and byte2bit4
bits and prepending them to EACH of the X and Y values (i.e. both
directions scale the same simultaneously.) If a Y value is 111, and
the other two bits are 00, then it has a length of 7 units (which is
something like 1/1024th of the screen width if I recall correctly???),
but if those bits are 01, then it is twice as long, if they are 10 it
is 4 times as long, and if they are 11 it is 8 times as long.
The brightness is just 16 levels, the few bottom of which are all
invisible anyway, and the top couple of which all look the same, and of
course all of which depends on your monitor brightness setting!
The command-or-scale byte is the one I'm a tad hazy on. Commands can
have the values A through F, and some of the other (lower) values have
some bearing on overall size, but not all of them do, and you can
easily make the state machine crash by playing around...
COMMAND NYBBLE:
A- Position the beam at the X/Ypos contained in these two bytes.
*RARELY* used in the ROM, since most drawing routines were subroutines
to "draw relative to current beam position", but used by the program to
position the beam for drawing each object.
B- HALT. Usually placed at the end of the display list (and again,
rarely if ever found in the ROM)
C- JSR. This is a "state machine format" address in two bytes.
D- RTS. Seen typically as 00 D0. Lots of these in ROM, needless to
say! Can also be meshed with a drawing command to save 2
bytes where possible.
E- JMP. Jump absolute to the "state machine format" address contained
in these two bytes.
F- Draw immediate. I have no idea what this note to myself means...ALL
codes that aren't one of the special codes above are "draw immediate
using data contained in these bytes"! I vaguely remember that maybe
the F-code lines were the smallest, 0 was next, then 1, and so on, but
invariably by the time you got to 9 it was too big... Actually, maybe
F was just a drawing command, but the others also set an overall scale
factor, which applied to all further drawing commands, until a
different scale factor was set. Or something like that... Yeah, so
F=DRAW, 0-9= SET OVERALL SCALE TO LEVEL <0..9>. That sounds about
right.
STATE MACHINE FORMAT ADDRESSES:
Whenever you had an address in a display list or a subroutine that was
going to be executed by the state machine, you had to format it NOT in
the realm of the 6502 addresses, but rather in the sense that made
sense to what the state machine could "see". To turn a 6502-address
into a state machine address, start by subtracting $4000. SO a
display-list address in the $4000's becomes a $0000's address. A ROM
address in the $5000's becomes a $1000's address. This is because of
how the addressing is wired. Now shift right a bit because all state
machine commands take two bytes, so we can save a bit here! So for
instance, $5314 (0101 0011 0001 0100) has become $098A
(000 1001 1000 1010) Add the "C" command for instance for a JSR, and
now you have C9 8A. Swap the bytes in little-endian fashion, and now
you have 8A C9, and you're done! So if you ever see 8A C9 in a display
list or in the ROM, you know that's a State Machine "JSR $5314"
command.
Simple as that (cough cough)...
DISPLAY LISTS AND VECTOR ROMS:
The state machine processes commands it finds in the DISPLAY LIST,
which is an area of dual-port RAM addressed starting at $4000 (for the
6502; it's $0000 for the state machine!) The State machine can munch
on this independently of the main processor's actions. Consider it a
"display coprocessor". So the main program can write drawing
instructions directly into the display list and create whatever it
wants.
But there are some things it knows it's going to want over and over and
over...like characters, and rocks, and ships, and explosion pictures,
and... So those are saved in the vector ROM as callable SUBROUTINES
(all with an RTS [00 D0] command at the end). SO the main program
writes some commands to the display list to position the beam, followed
by a "8A C9", which tells it to JSR $5314, i.e draw picture number 4 of
the player ship. When the display list gets processed, it hits the JSR
and starts processing the commands at $5314 until it reaches RTS (00
D0), then it reverts to where it left off in the display list. So the
stored shape subroutines are inherently RELATIVE- they draw a picture
by moving the beam in increments from wherever it happened to be when
the routine was invoked.
A QUICK MAP OF THE VECTOR ROMS (version 2/3):
$5000-$508F: test pattern direct draw instructions, ends in 00 00 which
I guess halts drawing? Hmmmm
$5090-$50A3: JSR's to write "BANK ERROR" on the screen (final call is
actually JMP to the "R" routine.)
$50A4-$50DF: drawing instructions for copyright symbol, followed by
JSR's to write "1979 ATARI IN", followed by a JMP to $551A, which is
the routine for "C"
$50E0-$50EB: state machine commands for pieces of wrecked ship
$50EC-$50F7: ???? (Maybe more wrecked ship pieces)
$50F8-$50FF: JSR table for the various ship explosion pictures (the
main game uses this table, which is all compact and easily handled by
an indexed addressing instruction, so supply the JSR code for each of
the 4 explosion pictures, which take up too much room to allow direct
indexed addressing to them. So it's inexed indirect addressing!
Holy shades of later processors Batman!)
$5100-$512B,
$512C-$5169,
$516A-$519F,
$51A0-$51DD: four explosion pictures.
$51DE-$51E5: indirect JSR table for 4 rocks.
$51E6-$51FD: subroutine for rock with V notch in top (10 sides)
$51FE-$5219: subroutine for X-shaped rock (12 sides)
$521A-$5233: subroutine for with bottom and left notches (11 sides)
$5234-$524F: subroutine for rock with left and right notches (12 sides)
$5250-$5251: indirect JSR table (one entry long!) for saucer.
$5252-$526D: subroutine for saucer (preceeded in display list by sizing
instructions, to allow two types of saucers!)
$526D-$528F: table of addresses for the 17 different pictures of the
player ship. But they're in 6502 format! But at least the
nybbles are reversed... 17 pictures covered a 90 degree
span (with a picture at BOTH axes and 15 in between), and
then they just get mirrored about one or both axes to make
the others. That explains the 6502-compatible address
table! It has to index into these routines and COPY THEM
to the display list, altering them along the way for
mirroring about an axis or two.
$5290-$54C1: 17 ship picture routines, spelled out individually in the
table above.
$54C2-$54EF: Extra ship picture (as in "I have 43 extra ships")
$54F0-$56D3: subroutines for drawing character set (in A-Z, space, 1-9
order)
$56D4-$571D: indirect table of addresses (state machine format) for the
character set (in space, 0-9, A-Z order). Yes, they just
point the 0 entry at the routine for O!
$571E-$5728: table of "offset from $571E" for each of the messages
$5729-$57B8: 11 different canned messages, "Asteroids packed text"
format.
$57B9-$57F9: table of values for, um, well, it escapes me at the
moment. Drag? Thrust? A smooth(ish) sweep from 00 to 7F
[Sin or cosine or something...]
$57FA-$57FF: all 00's. This is the extra space!
Note that starting at $571E, this is stuff that belongs in the main
ROMS, but they obviously ran out of space! Ooops....
ASTEROIDS PACKED TEXT FORMAT:
This belongs in a discussion about the main game, but since it happens
to be stored in the vector ROM, here goes!
Make a list, in the order space, 0-9, A-Z. Assign space the value 01,
and go up from there.
Write your message down. Now write the code from above for each
letter, but only the first 5 bits are used so write just those down.
Now group the char's in threes, and add a "0" bit at the end of each
group of 3 (15 bits), and re-block back into two 8-bit bytes. Use
those for two bytes of the message. If your message is over, use the
code 00. If your message does not contain a multiple of 3 characters,
use 0 *bits* as filler on the last byte for any missing characters,
this will also end the string. (Any 00 code for a character ends the
string). If you have an exact multiple of 3 characters, you can
make the last BIT a one instead of the normal 0. This saves a byte, so
you don't have to also add a 00 at the end!
Example:
"012"
= 00001 00010 00011 0
= 0000 1000 1000 0110
= 08 86
If it's in the middle of a string...or 08 87 to MARK the end of a
string with that very character.
That's it for tonight! Next up, a memory map of $00-FF (scratchpad
space) and $200-$2FF (player state variables; replicated for player 2
in $300-$3FF)...and the cute trick they use to save code space when
dealing with 2 players!
