Instruction manual
V, V,
V,
BYTE =
BYTE+64"V,
Z2YYYXXX
are
to
remain unchanged. This is done
by multiplying
V,
by
8:
In
the event
that
V, is neither a
move-up nor a plot-then move vector, it
is
added to the byte, for it then
consists
of an unambiguous two-bit code (Figure
4)
that
can fit
into
the remaining
two
bits
of the byte. Addition
of
V, requires a 6-bit
left
shift
of V,
to
avoid changing the bits
already present. This
is
done
by
multiplying V, by
64(
= 2
6
):
THE PROGRAM(S)
Three programs were written
to
im-
plement the computer-guided formula-
tion
of
a shape table:
A)
a shape file in-
itialization program (Figure
5);
B)
a
shape creating program (Figure
7);
C)
a
shape display program (Figure
8).
These
will
be
discussed briefly. I hope that the
folowing discussions coupled with the
comments scattered through the pro-
grams will enable you
to
follow the pro-
grams
without
difficulty.
these dubious bytes. This can
be
done
easily-especially
with
a
computer
program-by introducing dummy right-
and left-moves. The technique is simple:
check the value
of
the assembled byte; if
it is less than de.cimal
8,
the second vec-
tor
in the byte must correspond
to
the
move-up
(000)
vector.
In
that case,
replace the left-most zero bits
by
a non-
zero, move-right vector, transfer the
move-up
(000)
vector to the next byte and
follow it by a move-left vector.
By
plac·
ing the move-up
(000)
vector into the
right-most three bits
of
the next byte,
you ensure that it will
be
recognized as
an up-vector. The succeeding move-left
vector un-does the effect
of
the move-
right vector installed in the preceeding
byte so that the correct shape is main-
tained. Implementation
of
this routine in
a computer program is actually quite
easy, and resolves the problems
in-
troduced by the up-vector. Frankly, I
don't
see how anyone could
be
expected
to
obtain predictable shapes from
AP-
PLE'S procedure using hand-methods
for creating shape tables, considering
the inherent problems posed by the zero
up-vector.
Plotting
3-bit
Decimal
Vectors
Codes
Equivalents
i
000
0
~
001
1
J,.
010
2
~
011
3
t
100
4
~
101
5
!
110
6
~
III
7
00101000 (decimal
40).
Fig. 4: Representation
of
Plotting Vectors as 3·bit Codes and
decimal equivalents
00000101
(decimal
5)
and a move-up command followed
by
a
plot-then-move right command,
plot-then-move-right:
move-up:
plot-then-move·right: move-up
...
The
two
problems described in the
preceding paragraph-premature end-of-
record mark and non-plotting up-vectors
that
appear in the left bits-arise from the
definition
of
the up-vector as a zero 3-bit
string. In fact, a concise statement
of
the problem is that any byte with a value
less than decimal 8 can
be
expected
to
misbehave, unless it is the last byte in
the shape table. The solution
to
the pro-
blem lies in preventing the occurence
of
Presumably, these commands should
give the same net result. That's what you
think, and what I thought also!
In
fact,
the move-up command implied in the left
bits
of
decimal 5 is not recognized by the
system, and the byte is interpreted as a
plot-then-move right instruction only.
Therefore,
if
you try
to
generate a
45
0
line with the sequence
you will get a horizontal line, whereas
the sequence
move-up:
plot-then-move-right:
move-up: plot-then-move-righL
will give the desired
45
0
line!! There is
nothing in APPLE'S literature that would
lead the unwary
to
suspect that these
two sequences will not plot alike. Now
you
know
the
source
of
those
misshapen shapes.
~
OOYYYXXX
BYTE = BYTE + 8"V,
Now for
V,.
To
refresh your memory, you
will observe in Figure 4
that
all plot-then-
move 3-bit codes have their left-most
bits
"on."
Since there are only two bits
remaining unfilled in the byte, there is no
way in which the plot status
of
the third
3-bit code can
be
entered
into
the byte.
In
this
case, processing
of
the byte
stops, and it is stored in the shape table,
while V, is used to initialize the next
byte. This is the reason that plotting vec-
tors cannot
be
stored as end vectors in a
byte, one
of
APPLE'S
restrictions
previously noted.
In
similar fashion,
if
V,
corresponds
to
a move-up vector, with
all bits zero,
it
is not loaded
into
the cur-
rent byte, but is used
to
initialize the
next byte. The reason for
this
is not so
obvious, but is related
to
the aforemen-
tioned deduction that plotting vectors
cannot appear as end vectors in the
byte. For, suppose that the zero move-up
vector V,
could
be stored as an end vec-
tor; then everytime V, happened
to
be
a
plotting vector, the last two
bits
in the
byte would be a zero, and undesired up-
moves would
be
enabled whenever a
plot-then-move vector happened
to
oc-
cur in
V,.
APPLE'S restrictions make
sense!
Earlier, I
mentione~
glitches design-
ed
into
APPLE'S shape procedure
that
would
offer
problems in obtaining cor-
rect shapes in graphics. There are ac-
tually
two
kinds
of
glitches, one predic-
table and the other not. The predictable
one is a consequence
of
two facts:
1)
AP-
PLE
uses a zero byte as
an
end-of-record
mark to terminate every shape;
2)
the
move-up vector is represented by a 3-bit
code
of
000.
It follows that several move-
up vectors in a row will generate an end-
of-record mark and any part
of
the shape
following thereafter will be forgotten.
That's bad enough. Worse is the unex-
pected fact that move-up codes
(000)
that lie on the left part
of
the byte (most
significant bits) are not recognized. For
example, consider the two cases
of
a
plot-then-move right command followed
by
a move-up command,
19:14
MICRO
--
The 6502 Journal
December, 1979