In issue 9 David Eaton
showed how to use Player Missile Graphics with strings in a rather
elegant way by making the computer do all the work. The method worked by
dumping the Player Missile area into a string but in this article we
will explore the alternative method of dumping the strings into the
Player Missile area. This method saves memory as you need only dimension
one string for each Player used. For a two-line resolution Player
therefore only 128 bytes are used in the string.
In order to move strings
we must fool around with the Variable Value Table (VVT) and the
string/array area (STAR). The accompanying program demonstrates how to
do this but we will also have a look at what else you can do with VVT
and STAR. First though to the program.
|
|
|
 |
The program is called
Turtle and once running, there will be a little joystick controlled
animated turtle on the screen. It draws a line behind it which can have
any of three colours chosen by the Option, Select or Start buttons.
Pressing the fire button stops the line being drawn while the turtle
moves and Shift-Clear will clear the screen.
The animation is done
entirely by string manipulation. A$ is the turtle shell string,
superimposed over the Player Missile Graphics area. B$ is the head and
legs P/M string. C$ contains eight turtle shells, one for each
direction, and two blanks. It is analogous to the character set in the
computer except each 'character' is ten lines high (like Antic mode 3).
D$ and E$ contain eight head and legs shapes, one for each direction,
and are mirror images of each other.
The joystick direction,
minus 4, is put into variable S1. This variable, via S2 and S3, selects
the correct turtle shell and head and legs shapes to be transferred from
the character strings into A$ and B$. With each step, the loop gets the
head and legs shape from D$ and E$ alternately which gives a stepping
motion. This occurs in lines 100-150 but otherwise all movement is as in
David Eaton's article.
To get A$ and B$ up into
the Player Missile area we have to look at STAR. This has a pointer
telling you where it starts which is called STARP and is at decimal
locations 140 (low) and 141 (high). It is important to get the variables
into the table in the right order and therefore A$ and B$ must be the
first variables typed. If not the method simply will not
work. A$ is DIMensioned to 128 and therefore takes up the first 128
bytes of STAR. The first byte is where STARP points. B$ takes up the
next 128 bytes and C$.follows with 100 bytes and so forth. Whilst
strings take one byte for each character, arrays use six bytes for each
number so DIM X(100) would use 600 bytes.
STAR is a passive area
allocated by BASIC for the data in strings and arrays and so is
controlled by a set of pointers and length definers which reside in the
Variable Value Table. There is a pointer telling you where the VVT
starts at decimal locations 134 and 135 (VVTP). The Variable Value Table
contains three types of information:
a) It holds all simple
variables directly.
b) It holds the pointer
and lengths of arrays.
c) It holds the pointer
and lengths of strings.
Table 1 shows the VVT for
a program that first DIMensioned a string, then an array and then had a
normal variable. Each entry takes 8 bytes. Note that, once in, a
variable is never deleted except by LISTing to storage and ENTERing.
SAVEing or CSAVEing saves the VVT first and therefore it will remain the
same even if you have unused and unwanted variables.
After this digression
let's get back to the program. We need to manipulate the offsets as
shown in Table 1. In Turtle, the first string - A$ - will have an offset
from STARP of 0. Look at line 2030. ATAB gets
the value of STARP, where STAR begins and also where A$ begins. In line
2000 we set I as the Player Missile base, in pages. In 2040 we find
OFFS1, the difference between where the first Player should be (512 from
PMBASE) and the start of STAR. This is calculated in bytes. Lines 2050
and 2060 break OFFS1 into low and high values and POKE these values into
the offset pointer for A$ at VVTP+2 and VVTP+3. The process is exactly
the same for B$ which via OFFS2 is 128 bytes higher up than A$. That's
all there is to it! BASIC now thinks that the STAR for these two
variables is in the P/M Graphics area.
Before we leave, let's
take a look at what else you can do with the Variable Value Table. If
you type in Program 2 you can see a demonstration of changing the
DIMension of strings. A$ and B$ both grow from a length of 3 to 10. Here
both the offset bytes and the DIMension bytes of VVT are being altered.
As we are not moving the string contents around in STAR, however, this
is a 'destructive' re-dimensioning and the strings will be full of
garbage which needs to be cleared. If you wanted to keep the contents of
the strings while making them larger you would need to move the string
contents in STAR to the right places. I won't go through this program
but I hope that I have given you enough information for you to work out
what is going on.
|
|
|
|
Table 1. Organisation of an example
VVT
| Bytes of Table |
1 |
2 |
3 |
4 |
5 |
6 |
7 |
8 |
| String |
129 |
ID No. |
Offset
from STARP |
Present
Length |
DIM |
| ARRAY |
65 |
ID No. |
Offset
from STARP |
First DIM
+ 1 |
Second DIM
+ 1 |
| Simple Variable |
0 |
ID No. |
--- Six
byte binary-coded decimal number --- |
First byte gives type of variable (for
a string or array this will be one less if undimensioned). Zero means a
simple variable. All numbers are in decimal.
Second byte gives the number of the
variable. The first entry is 0, the second is 1 and so on.
top
