"If you smoke on the premises, we shall assume you are on fire
and treat you accordingly."
"THE ATARI COMPENDIUM" BY SCOTT SANDERS
Errata Sheet: 11/1/1993
Part 3 of 3
Letter extracts published in "ST Applications" Issue 42 page 41
by David Bolton
For someone starting to program in assembler and wanting to use
GEMDOS, BIOS or XBIOS calls they will need to do some hunting
unless they have any other reference books for the o/s.
Mr Sanders has omitted to mention that return values are to be
found in d0.L. Each of the relevant sections in the book has a
part entitled "Function Calling Procedure" but none of them tells
the reader where return values can be found! Since the procedure
is given in assembler I feel this is a bad oversight.
The remaining errors/omissions I've found so far have been in
the AES, VDl and CPX sections. Those in the AES are associated
with the table of opcode/control values on page 6.38. The
statement at the start of the table about no AES calls using
addrout is wrong: rsrc_gaddr uses it to pass back the address of
the object being looked for. Some entries in the table have the
wrong values; the entries should read for:
appl_search 18, 1, 1, 3;
rsrc_rcfix 115, 0, 1, 1;
appl_getinfo 130, 1, 4, 0;
The VDI section mentions device drivers but unfortunately Scott
Sanders hasn't taken the opportunity to pass on any information
or guidelines on how to write them (a subject that has been
mentioned on more than one occasion in STA). The errors are:
v_bez_on() p7.29, contrl[1] should equal 0 not 1;
v_load_cache() p7.59, contrl[3] should be i not --i (intin[0]
holds the mode so the last i++ counts that word also);
vqt_cachesize() p7.104, the assignment to *size should access
intout[0] and [1] not the corresponding intin fields;
vgt_fontheader() p7.109, the opcode should be 232;
vqt_name() p7.113, the assignment to fontname requires a cast
as intout is a word array and fontname is a char/byte array,
ie fontname = (char)intout[i + 1].
The v_bez() (and v_bez_fill()) explanations on p7.26/27 have
a couple of errors and are not as clear as they should be (or
maybe I'm as thick as two short planks!).
The control points are actually expected in the following order:
anchor - 1, control - 1, control - 2, anchor - 2
(if you believe the book then there are some interesting curves
produced!). The first line in the first "for" loop is rather
curious as it won't achieve the desired result. Each word of
intin should contain two consecutive characters from bezarr, the
code given will only pass the first half of bezarr to the VDI and
with $00 between each value. The following code should give the
desired effect:
for (i = O; i < count; i += 2)
intin[i / 2] = ((WORD)bezarr) * 256 + (WORD)bezarr[i + 1];
When bit 0 of a value in bezarr is set the control points start
in the NEXT corresponding position in the pxy array, the use of
bit 1 is also important.
Here are a two examples (the origin is at the top left in each
case):
count = 4
bezarr = 3, 0, 0, 0, 0
pxy = 50, 50 ignored here
400, 50 anchor - 1
400, 200 control - 1
300, 50 control - 2
300, 200 anchor - 2
Resetting bit 1 to give
bezarr = 1, 0, 0, 0, 0
results in this second curve where the first point in pxy is now
used.
[ images of 2 bezier curves not included here ]
v_bez_fill() behaves in the same way but additionally the first
and last points are connected with a line before doing the fill.
Using the same values as above gives:
[ images of 2 filled bezier curves not included here]
The section on the extensible control panel has some omissions
in its explanation. The flags structure in the header (p10.3) is
actually a word with each flag in the corresponding nybble. Also
for some reason known only to Atari the values in the two colour
words are not stored as you would expect. The icon colour
(i_color()) is in the high nybble of the word as 0xi00, and the
text colour (t_color()) in the low nybble of the high byte of the
word as 0x0t00. For anyone writing CPX's in assembler all the
cpx_*** functions expect the return value to be passed back in
d0.L.
Disclaimer
The text of the articles is identical to the originals like they appeared
in old ST NEWS issues. Please take into consideration that the author(s)
was (were) a lot younger and less responsible back then. So bad jokes,
bad English, youthful arrogance, insults, bravura, over-crediting and
tastelessness should be taken with at least a grain of salt. Any contact
and/or payment information, as well as deadlines/release dates of any
kind should be regarded as outdated. Due to the fact that these pages are
not actually contained in an Atari executable here, references to scroll
texts, featured demo screens and hidden articles may also be irrelevant.