

    ICTARI USER GROUP             ISSUE 11                       June 1994

         ___   ______     ___       _________   _________   ___
         \__\  \   __\    \  \__    \______  \  \   _____\  \__\
           ___  \  \       \  __\     _____\  \  \  \         ___
           \  \  \  \       \  \      \  ____  \  \  \        \  \
            \  \  \  \_____  \  \____  \  \__\  \  \  \        \  \
             \  \  \       \  \      \  \        \  \  \        \  \
              \__\  \_______\  \______\  \________\  \__\        \__\

                     *   m   a   g   a   z   i   n   e   *

     =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
                       I C T A R I   U S E R   G R O U P
       63 Woolsbridge Road, Ringwood, Hants, BH24 2LX   Tel. 0425-474415
     =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

                              INDEX FOR ISSUE 11
                              ==================

    FOLDER                          SUBJECT
                              
    ASSEMBLY       Binary to decimal conversion routine.
                   Decimal to binary conversion routine.
                   Code to play chip music in interrupts.
                   Code to set up time and date when booting up.
                   Routine to convert number to a binary string.
                   Routine to convert number to hex string.
                   Routine to enter hex number from keyboard.

    C              GEM Tutorial by J White. Part 1 Introduction.
                   Using floating dialogue boxes in Lattice C.
                   Porting IBM PC RSC/Doodle to Atari GEM.

    GFA            Code to generate circles, spheres, etc.
                   Picture image cutter and saver program for GFA.

    PASCAL         Code to display boolean expressions as a Karnaugh map.

    STOS           Code for number guessing game that talks to you.

    MISC           Blitter chip manual.
                   Click anywhere title box using Resource File editor.
                   Index for issues 1-10.
                   Membership list.

    In next months issue of ICTARI (this may change) :-

    ASSEMBLY       Loading files.
                   Palette fading routines for STFM and STE.
                   User defined mouse shapes for GEM programs.
                   Sprite drawing routines.
                   Sprite tutorial. Part 1.

    C              Fractal drawing code.
                   GEM Tutorial by J White. Part 2

    GFA            GFA Manual Section 1 of 3.
                   GFA Alert form designer.

    STOS           Bootview program code.
                   Pipe Perfect game code.

    MISC           Analyzer program to display info on system crashes.
                   Atari Questions and Answers file No 1.
                   STE hardware information.


    For future issues :-

    Polyline drawing routines in machine code.
    Bezier curve drawing routines.
    Picture decompression routines for IMG, Degas, Tiny, PCX, PAC, etc.
    Picture compression routine for IMG pictures.
    HP DeskJet/LaserJet compression routines (Mode 2 TIFF).
    Using the Xbtimer chip.
    Playing sound samples on non STE machines.
    Picture switching techniques.
    VBL queue information.
    Printer driver code for printing mono/colour images.
    Sprite tutorial and code.
    C Graphics extensions.
    C functions using dialog boxes.

    -----------------------------------------------------------------------
                                   EDITORIAL
                                   =========
    MEMBERSHIP
    
    The ST Applications magazine, issue 42,  has  now published a full page
    article on the ICTARI  group  and  we  have  had  a  few inquiries as a
    result. A few more programmers have  joined  the group this month which
    gives us a membership of about 44 including the committee.

    HELP68 ACCESSORY
    
    In issue 8 I complained  that  the  HELP68 accessory which displays the
    68K instruction set and their various parameters, etc, etc did not work
    on my machine and asked if anyone could fix it. I have since discovered
    that it does work OK but  will  not  work  if  the GEM speed up program
    QUICKST3 is also loaded, which I usually  use. Does anyone know why and
    whether it works with the NVDI or Warp 9 accelerators.

    TEXT and IMAGES
    
    Regarding the use of pictures in  text  tutorials, the few that replied
    suggested that separate .IMG files in conjunction with a standard ASCII
    file would be the preferred option so that anyone who wants a print out
    can make up their own documents using their own WP/DTP program. We can,
    for a small fee,  also  provide  Laser  printed  copies  of  any of the
    text/picture files that are published  in  ICTARI. Please contact us if
    you are interested.

    CIRCUIT DIAGRAMS
    
    Does anyone have a circuit  diagram  of  the  Atari computer and/or the
    Monochrome monitor SM124 which they  could  let  us  have a copy of. We
    will, of course, pay for any photocopying costs.
    -----------------------------------------------------------------------
                                CORRESPONDENCE
                                ==============

    Hello ICTARI members! I'm  Ralph  Lovesy  and  I've been programming in
    68000 assembler for 3-4 months. I've owned an ST since 1985 and a 2 meg
    STE since 1989 and I now specialise  in STE programming. I've written a
    shareware Pacman-style game called Snacman which has STE-enhanced sound
    and graphics and I'm currently working on  a 1 meg STE-only game called
    Supreme Soccer which will be commercially released later this year.

    P.S. If anyone has a copy of ST  Internals, I would be very grateful if
    you could let me know, as I need to photocopy 50 pages or so...
    -----------------------------------------------------------------------
    To *.*
    From Jim Taylor

    I  desperately need definitive and  complete  info  on the DXF (Drawing
    eXchange  File)  structure  so that I  can  implement  it in a CAD type
    application I'm developing in C++. I  have  some  info from a PD source
    but I do not fully understand it. Can anyone help.

    I  would  also  appreciate  help   with  info  on HPGL (Hewlett Packard
    Graphics Language).

    Thanks in advance.

    */ Can anyone help with  the  DXF  information, perhaps if we published
    the PD info you've got,  someone  might  be  able  to  expand on it and
    produce a better explanation.  ICTARI /*
    -----------------------------------------------------------------------
    To *.*
    From Paul Brookes

    Can anyone give me basic information on the DSP chip in the Falcon. For
    example, how to perform  simple  communications  with  the chip (in any
    language) like writing  two  values  to  it,  adding  them together and
    returning the result, or  whatever.  A  simple  tutorial  would be very
    helpful.
    -----------------------------------------------------------------------
    To ICTARI
    From Paul Laddie (BYTEMAN)

    Does anyone fancy doing a tutorial on using RSC files and using windows
    in GFA BASIC  3.5,  I  have  written  programs in GFA 3.5 which use GEM
    pull down menus and simple windows, but I would like to write GEM based
    programs which display  pictures in  windows,  which can be resized and
    scrolled, etc.  I  currently  use AUTOZEST  to create the interface for
    my Hi-Rez programs, but I  would   like  to  be  able to use GEM to its
    full advantage.

    I noticed in the  letters section in  issue  #10, that a future article
    will be on  playing  sound samples in BASIC, I have written a GFA BASIC
    routine which plays a large sample  straight  from a hard disk, it only
    uses two channels of the sound chip. I  will  tidy it up and send it in
    to a future issue.

    I think any diagrams or  pictures  in  future issues should be included
    as just  plain   IMG   files   on   the   disc,   then   they  will  be
    accessible to more people, besides the  graphics handling in First Word
    Plus is pretty basic anyway.

    That's all folks!

    */ Any offers on a RSC/Windows  tutorial.  We look forward to the sound
    sample playing code.  Starting  next  month  we  are  publishing a very
    comprehensive three part GFA manual by  Han Kempen which does cover GEM
    windows, menus, dialogues, etc albeit fairly briefly.  ICTARI /*
    -----------------------------------------------------------------------
    To ICTARI U.G.
    From Mic Barnard

    To our dear esteemed editor.

    Sorry I didn't send anything in for  the last issue, it's a combination
    of being disorganised, having  my  mum-in-law  here  and  having my STE
    break down on me. I don't  know  which  was worse... but, I've tried to
    catch up with this letter. Hope it's not too long.

    You'll be glad to know  that  your  postage arrangements have been fine
    with me so far. There seems no need to spend money on jiffybags.

    This may seem silly, (IT  IS,  very!)  but  I  havn't got an anti virus
    program. Until now I haven't got  disks  from  friends as no one I know
    uses an Atari and I only  ever  buy  original  disks. (See my halo?). I
    think I'm clean, I've never had  any problems other than hardware ones,
    but I'll have to make sure. UVK it is.

    The 'Explorer Journal' bit from the  States was quite good although, of
    course, not all bits are anywhere near my (low) level of understanding.
    It'll be good to see more of it.

    */ When we can get some more we will use it.  ICTARI /*

    Sorry about the 'Puuurrrrr' bit. I read it on the disc and my blood ran
    cold. I don't know why I did it. I really am 37 years old!

    Also, I'm not a prude. I  swear  enough  both  at home and at work, but
    somehow seeing a bit of swearing in one of the files in your editorials
    also made me cringe a bit. Remember,  this stuff's liable to be read by
    anyone. Let's make it look good.

    That makes me ask. Is ICTARI being sent  to PD libraries too, or are we
    members the only ones who get to read it? Does Ictari hold a copyright?
    Can any non-Ictari members  use  the  source?  I  only  found out about
    Ictari from a PD library, so  if  it  is released we could increase the
    membership. Just a thought.

    */ We don't send the ICTARI disks  to  any PD libraries (see below). As
    far as we are concerned any  source  code published in the magazine can
    be used by anyone, ICTARI member or  not, since there would not be much
    point in publishing  it  otherwise.  If  any  members  wish  to put any
    restrictions on the code they send  in,  they  should put a note in the
    code or the associated text  file  to  that effect. However, if members
    use another members source code  in  a  published  program, we think it
    would be courteous  to  acknowledge  the  members  contribution  in the
    program documentation.  ICTARI /*

    Wordprocessors. I'm writing this on  Protext  V4.3  as given away by ST
    Format issue 41. (Document mode,  standard  ruler.)  I hope it's easier
    for you. And, as you  use  Protext  regularly,  can  you tell me how to
    alter the border colour to black to match main screen 'paper' colour? I
    can change all the settings from within  the config program but not the
    border.

    */ We use Protext in monochrome  so  the  problem doesn't arise. We did
    try it on our colour  monitor,  however,  and changing the colours with
    the CONTROL panel accessory  it  seems  that  Arnor  have used colour 0
    (which is used for the border) in the  main part of the display so that
    changing this colour to black  will  mess  up  the  text area. We would
    assume from this that it can't  be  done but if anyone knows different,
    please let us know.  ICTARI /*

    I've also got Calligrapher  Pro  (ST  Review  24),  First word plus (ST
    Review ? ), Write on (ST Review 13  &  ST Format ? ) and Word Flair (ST
    Format 52). So, whichever one you decide  on as the standard for Ictari
    is OK by me. You're right about  the printing speed of Cal Pro. There's
    a crippled snail in there somewhere.

    Now to ask for more help. I  need  to understand more about the logical
    and physical screen concepts. As  I  understand  it  the ST's O/S keeps
    track of 2 addresses. That of  the  physical screen, the area of memory
    which the hardware uses to send as  data to the monitor and the logical
    screen, the area of memory used by the  O/S to write to. On bootup they
    are the same, the ST writes to the displayed screen memory.

    Using XBIOS 5 - SETSCREEN  I  can  alter these addresses. Therefore, by
    reserving 32k of memory (on a 256  byte boundry) somewhere in RAM I can
    use it as a second screen, passing  the  parameters to TOS via xbios 5.
    So far so good. I did  that.  I  passed  the contents of my screens new
    addresses  to  my  variables,  waited  for  the  VBL  then  passed  the
    parameters to TOS via xbios 5.  I  should  now have 2 separate screens,
    with all O/S output going to  the  screen  who's address is held as the
    logical screen.

    I then wrote a message using GEMDOS 9 - PRINT LINE. It should go to the
    logical screen. It wasn't displayed so  it  must be written as I wanted
    to the logical  (hidden)  screen.  I  did  a  screen  swap. The message
    appeared. Also good, I was now looking at the previously hidden screen.
    Now I wrote a second  message  with  gemdos  9.  I thought it should be
    written to the logical  (hidden)  screen,  i.e.  my previously physical
    screen. But it immediately appeared  next  to  the first message on the
    physical screen. Now I'm confused.

    The obvious answer is that I  failed  to  swap the addresses or to pass
    them to the O/S. But, I have followed them with MONST and the variables
    change correctly. I also put XBIOS  3  -  LOGBASE  in the code at a few
    strategic places and found the  addresses  had  been swapped within the
    O/S where I expected them to and to the correct values. So whats wrong?
    Does GEMDOS not write to the logical screen address a second time?

    I've included  the  files  'MICSMACS.S'  (my  budding  macro  file) and
    'TESTMACS.S' (the file with  my  problem.  I  was/am  testing my macros
    before I use them to tidy up my mouse shell.) Help, please.

    To Si(gh).

    Thanks for the comments on my listings in issue 9. But it does leave me
    with one or two (or three) questions. Such as...

    Why use 'bsr.s' and 'bsr' instead  of 'jsr'? Looking these instructions
    up in my  timing  tables  (which  everyone  must  have  because  no one
    contacted me for a copy) it  seems  that  'jsr' takes between 16 and 22
    cycles, 'bsr' takes 18 cycles and I  don't know how many cycles 'bsr.s'
    takes because it's not listed as  a  separate instruction. So 'jsr' can
    be quicker than 'bsr'. Or is it  the  amount  of memory they take up? I
    could save up to 4 bytes using  'bsr.s'  but  is it worth the hassle of
    finding at assembly that your code has  grown  since you used it and it
    now produces an assembly error?  Also,  surely  it's not so critical to
    worry about the few cycles saved  for jumping to subroutines? Now loops
    are critical. They may be repeated thousands  of times so the couple of
    cycles adds up tremendously, but subroutine  jumps? Don't get me wrong,
    please, it's just that I  want  to  know  WHY  one thing is better than
    another, not just to be told that IT IS!

    You say "It's quicker to add words  to address registers as all 32 bits
    of address registers are still affected!".  Again, I say why? According
    to my timing tables:

    addq (b/w)     2 bytes   4 cycles for data registers
    addq (b/w)     2 bytes   8 cycles for address registers

    addq (l)       2 bytes   8 cycles for all registers

    Adding words OR longs to address  registers  seems  to take 8 cycles. I
    have the same problem with  your  comment  "Use clr.l instead of move.l
    #0". I read them as both taking  28 cycles in absolute addressing mode.
    Am I misreading the tables?

    */ I tend to use BSR and BRA  in preference to JSR and JMP instructions
    in my  programs  because  JSR  and  JMP  instructions  require absolute
    addresses while  BSR  and  BRA  are  relative  branches.  All  absolute
    addresses have  to  be  relocated  when  the  program  is  loaded which
    increases the size of  the  program  (the  relocation table anyway) and
    also slows down the  loading  time  slightly.  Obviously  this is not a
    major consideration on small programs but  could be more significant on
    very large programs. Also, if you are using Devpac, it is not necessary
    to use the .w or .s on  instructions since Devpac assumes these anyway.
    Even the .l indicator is  not  needed  on address register instructions
    (i.e. add.l    #10,a0) since Devpac  uses  the correct instruction code
    when address registers are used as  the destination operand. Si(gh) may
    have other reasons, of course, maybe he will enlighten us.  PDH /*

    You'll be glad to know I agree fully with your comments about the logic
    of my mouse routines and that I've  fully rewritten them and they work!
    Thanks. It's the core of a  basic  shell  I'm  (trying) to do next, and
    when it's done I'll send  it  in.  Now  all  I  need  to do is draw the
    pointer...

    As for my jumping about the  code,  I  was more interested in trying to
    get it to work. I tend to  tidy  it  up later. Sometimes. Not that I've
    written much to tidy yet.

    The loop counter was accidentally left  in.  I  was trying to count how
    many times a frame I could read the mouse.

    My maths is terrible. Being logical,  with  maths like mine I shouldn't
    be looking at code let alone try  to  write it! Still, I'm learning and
    that's what this disc is about isn't it.

    Again, thanks Si(gh).

    To James Collett.

    Just a short note. Watch out for  the copyright for the Repton games. I
    know they are out of date as  such,  but someone must own the copyright
    to them, unless they were PD. If  you  get any old disks or tapes write
    to the publishers  who's  addresses  are  on  them  and  ask  for their
    permission. As they haven't released it for  the ST (I assume) and they
    are old hat, they would probably agree. I've just read an article about
    this same thing in the June '94  issue  of PC HOME magazine. (Page 124,
    an article called  'RETROSPEC').  Someone  is  re-writing  old Spectrum
    games for the PC. He's been  given  permission by a couple of companies
    and apparently refused by none. Good luck.

    To Steven and Andrew, Diamond Software.

    You have offered to release some  of  your routines. First, thanks, but
    secondly could the fast sprite routines  be  one  of the first out as I
    need to be able to draw/undraw/redraw, etc, my mouse pointer as quickly
    as possible. At the moment I just  have  a simple but slow routine. How
    is it done much quicker? Hope I don't sound greedy.

    To everyone. Be safe and ta for your help and patience.

    Mic.

    */ Steven and Andrew have already sent in some sprite routines which we
    will publish next month, Nik Bates  has  also sent in a sprite tutorial
    which we will also start next  month.  Since sprites are a fairly major
    aspect of programming on the Atari, we  would like to see other members
    code on this subject,  especially  for  the  higher  resolutions of the
    Falcon (at least seven members have Falcons at this time).  ICTARI /*
    -----------------------------------------------------------------------
    To ICTARI
    From Andrew Martin & Steve Jordan <Diamond Software>

    Afetr passing a few  ICTARI  disks  around  various friends the general
    impression was that the disk  was  not presented well. The introduction
    of a DESKTOP.INF file to  boot  the  desktop in medium resolution would
    make a great deal of  difference.  We  presume  the reason you have not
    done this is because of members with hard disks. This is fair enough to
    the people who own hard disks  and  have  a  DESKTOP.INF file set up to
    their own needs but the  vast  majority  of people (including those who
    purchase the  disk  from  PD  libraries)  don't  have  hard  disks  and
    therefore boot their computer with the  disk  in the floppy drive. This
    results in a  rather  ugly  looking  low  resolution desktop appearing,
    which is most unfriendly when beginners are trying to read text files.

    We also feel that the group needs  a more varied spread of members. How
    this will be achieved we're not sure,  the  only way we can think of is
    by time.

    We understand your concern with  boot  sectors  and will, therefore, no
    longer be sending in any disks with bootsectors on them.

    */ Point taken  about  booting  in  medium  rez,  DESKTOP.INF  file now
    included. Incidentally, according to  the membership questionaires, out
    of the 40 or  so  current  members  we  have  at  present, 24 have hard
    drives, an  absolute  essential  for  programmers  we  think.  We don't
    actually distribute the ICTARI disks  to  PD libraries for two reasons,
    (1) the costs and (2) we  want  potential programmers to join the group
    so that they  will  contribute  programming  material  rather than just
    receive it from a library. We have, however, written to all the main PD
    libraries informing them of  ICTARI  and  we  hope  they will pass this
    information on to their customers.  ICTARI /*
    -----------------------------------------------------------------------
    TO: All
    FROM: Mark Baker

    The second edition of the Atari  Compendium  is now available, it fixes
    many of the errors in the first edition.

    If you have the first  edition  there  is  an official errata available
    which lists all errors known when  the second edition was published and
    therefore now fixed. I  found  the  following  message which lists some
    other errors, almost all of which are still in the second edition.

              ###################################################

    The Atari Compendium
    by Scott Sanders
    Additional Errata
    Compiled by Mark S Baines (msbaines@cix.compulink.co.uk)
    09 06 94

    6.46 (appl_getinfo)
    Available from AES 4.00 not  3.40.  ap_gtype  4 and above are available
    from AES 4.10.

    6.63 (evnt_mesag)
    MN_SELECTED - msg[4] contains the object number of the menu item or the
    submenu item if submenus are available.
    msg[5], msg[6] and msg[7] contain this  data  as from AES 3.30 not 4.0.
    msg[7] contains the parent object index of the menu item or the submenu
    item.

    WM_TOPPED - the wind_set parameters  should be wind_set(handle, WF_TOP,
    0, 0, 0, 0). msg[3] contains the handle.

    WM_ARROWED - msg[4] indicates  which  action  was actually selected not
    msg[3] which contains the handle.

    6.64 (evnt_mesag)
    WM_HSLID - msg[4] contains  the  new  slider  position not msg[3] which
    contains the handle.

    WM_VSLID - msg[4] contains  the  new  slider  position not msg[3] which
    contains the handle.

    6.99 (menu_attach)
    Caveat
    menu_attach on AES 3.40 has a problem  with scrolling sub menus if more
    than 1 sub menu is in the OBJECT tree. The solution is to only have one
    submenu per OBJECT tree. (Simon Robins)

    B.7 System variables
    Which of these are available for  a  particular TOS is very confused as
    laid out here. The Addendum notes don't fully explain either.
    Addresses $400 - $4FE TOS 1.0
    Addresses $400 - $57E TOS 1.2
    Addresses $400 - $5A0 TOS 1.4
    Addresses $400 - $5B0 TOS 1.6 and later

    There is an additional system  variable  at  $600 patchzone, used as an
    area for patching  TOS  and  other  routines.  If  empty  it  is set to
    $0BADC0DE.

    B.15 System variables
    ramtop should be called fmemtop
    ramvalid  should  be   called   fmemvalid   both   in  accordance  with
    nomenclature used elsewhere.

           #########################################################

    Letter extracts published in  ST  Applications  Issue  42 page 41 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[i] =
    (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[i]) * 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.

                                 ++++ End of file ++++
