Skip to main content

 "If you smoke on the premises,  we shall assume you are on  fire
and treat you accordingly."

                     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

   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

    [ 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

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.