
     ICTARI USER GROUP             ISSUE 35                      June 1996

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

                     *   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. 01425-474415
     =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

                              INDEX FOR ISSUE 35
                              ==================

     ASSEMBLY        PICPAC update.
                     Assembly Language Tutorial. Part 3.
                     Mouse routines using Absolute Mode.

     C               Dynamic memory debug library.
                     File listing functions.
                     Progress bar.

     GFA             File selector routine.

     STOS            STOS demo code.
                     Pie Chart maker.

     MISC            Rich Text format spec Part 2.
                     3D Maze Demo program.
                     Iconify Server (ICFS) code and CPX.
                     Current membership list.

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

     ASSEMBLY        Assembly Language Tutorial. Part 4.

     C               Monochrome fade functions.

     GFA             Date and time setting procedures.

     STOS            Mouse and Joystick test routines.

     MISC            NVDI information.
                     SCSI FAQ.

     ----------------------------------------------------------------------
                                   EDITORIAL
                                   =========
     POSTAL CHARGES
     --------------
     As I'm sure you all know, postal  charges are due to increase in July,
     the second class stamp increases from 19p  to 20p. I'm not sure at the
     moment whether overseas charges will also increase but if there is any
     need to change our charges I will sort it out next month.

     RTF
     ---
     In the MISC folder  is  a  very  comprehensive  description of the RTF
     format by Mrten Lindstrm, if  you  are  considering writing any text
     applications it  should  provide  an  invaluable  reference  guide. Be
     warned, however, it  runs  to  over  50  pages  when  printed out. The
     RTFREADR.ZIP file is a compressed file  which needs to be decompressed
     first with a program  like  STZIP.PRG  and  is  an  RTF reader program
     written in C (for the PC),  if  anyone  could provide an ST version we
     would be interested to see it.

     DYNAMIC LINK LIBRARIES
     ----------------------
     Over the last few weeks I have been looking at PC software (especially
     programming software)  and  there  are  some  interesting  programming
     techniques which could be used to advantage on the Atari. For example,
     Dynamic  Link  Libraries  (DLLs)  are   used  extensively  in  Windows
     Applications and can save  the  programmer  a  lot of development time
     when writing complex code  and  which  may  already  have been done by
     another programmer.

     A DLL is a  stand  alone  program  block  which  is  stored  in a sub-
     directory on  the  disk  and  which  is  loaded  into  memory  when an
     application program requires it. Once the  code is resident in memory,
     any other application  (or  accessory)  can  then  use  the  same code
     without having  to  load  it  again  thus  saving  some  memory space.
     Hundreds of DLLs are available on  the  PC which can provide all sorts
     of facilities such image  manipulations,  sorting functions, etc, etc.
     The advantage, for the programmer anyway, is  that to use any of these
     libraries he just calls up the  code  to perform the required function
     without having to know how it works  and  also the DLLs will work when
     used from any language.  Another  advantage  is  that  the DLL code is
     usually written in machine code so that a big speed increase is gained
     when called from an interpreted  language  such as BASIC. The (slight)
     disadvantage for the user is  that  he  has  to have the required DLLs
     available on his disk at run time which  on the PC is not a problem as
     ALL PCs have hard disks.

     I believe we could use this  same  technique  to some advantage on the
     Atari. The easiest way, I think, would  be  to write a DLL and save it
     to disk with the usual re-location  table attached and also allocate a
     'cookie-jar' identification code.  When  another  programmer wishes to
     use the DLL, his program would  first  check  the cookie jar to see if
     the DLL has already been loaded into  RAM by another application (on a
     multi-tasking system) or an accessory.  If  it  is present, the cookie
     jar would provide the address in memory  of the DLL code through which
     all access to the function would be  done.  If the DLL is not present,
     the program would look  for  it  in  a  sub-directory called 'DLL' (or
     whatever) in the root  directory  of  the  current  drive. The program
     would then load the program and install  the  cookie jar ID for use by
     other programs.

     The DLL would have its own  DATA  and  BSS  segments but would use the
     main program stack  pointer  for  stack  operations.  Any large memory
     requirements would probably  need  to  use  'malloc'  to  allocate and
     release temporary memory. Since the  code  could  be called by two (or
     more) programs in quick  succession,  any  variables  would need to be
     maintained by the calling programs to  avoid data corruption. Data and
     control codes would be passed  to  the  DLL  code  (via the cookie jar
     vector) by pushing them onto the stack in the same way as the GEM BIOS
     does. Data or error codes would be returned in register D0 as normal.

     The Atari does already have  something  similar  to this, the GDOS for
     example, but I think this  system  would  be  more flexible and easily
     expandable. There are a number of functions which could be provided in
     this format, perhaps a  fast  text  sort  function  or possibly Mrten
     Lindstrms PICPAC routines to load  different picture image formats. I
     think it would be a big advantage  for Assembler, C, GFA BASIC, HiSoft
     BASIC, PASCAL (and maybe even STOS) programmers  to be able to use the
     same code easily.

     If anyone has any more thoughts on this subject, please let me know.
     ----------------------------------------------------------------------
                                 CORRESPONDENCE
                                 ==============
     To: All
     From: Jonathan Leckie

     I am sad to hear about Atari World  going down the toilet, the various
     musings on the state  of Atari got me  a bit depressed  but I found my
     happy thought and I am  better now.  Maybe all the Atari clubs can get
     together  and get something  organised or  is there  a millionaire out
     there with a magic wand and a global instant PC compatible virus?

     To: David Preston
     Re.: UDO

     Yes I was a fool, a  moronic fool, the kind  of fool you get if you go
     somewhere and ask for a fool (I am not very  good at examples).  I had
     thought that it  would convert a  document format to another - in much
     the same way as a word processing program would convert RTF to ASCII -
     without  any interference.  But  yes you  are correct  it takes  a UDO
     script (with strict syntax) and converts it into one of its  supported
     document types.  I got UDO  from the  HENSA (not my 'Net connexion), I
     found the commands (and document conversion) to be similar in style to
     TEX, I suspect its illustrious author  has done some studying of Knuth
     and compiler writing.
     ----------------------------------------------------------------------
     To:- George Hodgson
     From:- Martin Milner

     Hope the following is of assistance:-

     There are two ways of  incorporating  data  from  a separate file into
     your STOS programs. The first is by storing your data in a memory bank
     in a pre-defined format, and then bsaveing it to a disk file. It could
     then be loaded using the bload command.  You'd have to have a means of
     transferring in and out of the memory bank, perhaps with peek/deek and
     poke/doke or by using a command  from  an  extension such as the write
     command from Les Greenhalgh's  excellent  Control extension which will
     write a string into a memory bank.

     The second and by far easier method  is  by using a simple serial file
     to store the data and input  #  to  read  it  and  print # to write it
     thus:-

     111 rem   ***** read in hi-score table *****
     112 FIL$=CDRIVE$+FLDR$+"scores.hi" : open in #1,FIL$
     113 for N=0 to 5 : input #1,PLYER$(N),PLYSCRE$(N) : next N
     118 close #1

     21101 rem    level/hi-score save routine
     21110 FIL$=CDRIVE$+FLDR$+"scores.hi" : open out #1,FIL$
     21115 for N=0 to 5
     21120 Z$="," : print #1,left$(PLYER$(N),15);Z$;PLYSCRE$(N)
     21125 next N

     The hi-score file would look something like this:-

     bibble         , 3100
     bobble         , 2500
     blobby         , 1800
     wibble         , 700
     babble         , 400
     bubble         , 200

     The comma between each field is  a  field separator. Hope the above is
     of some help.

     To:- Jason Railton
     From:- Martin Milner

     It's worth giving the missing link joystick commands a try as well, as
     they also  provide  support  for  2  joysticks  and  seem  to  be  TOS
     independent.

     STOS Games:- I'd be happy to try your  games out on my STE and Falcon,
     pre-fixed or not. You'd  be  surprised  at  the  problems you can come
     across. (See below). Just let Ictari  know  when you want the disks or
     whatever.

     To:- David Preston
     From:- Martin Milner

     YES!!! I too have had these  problems, especially when moving programs
     from the STE to the Falcon. (But also back again!) Most of my problems
     seem to have arisen from using screen  copy to display screens full of
     graphics, (including scrolling text), and  not waiting long enough for
     the copy to finish.  I've  had  problems  with screen fades corrupting
     palettes on the Falcon, (when tested initially  on my STE), due to the
     fact that the Falcon runs much faster. For a fade 2, wait at least 30.
     I've  also   had   initially   very   puzzling   palette  corruptions/
     unpredictable results when  testing  programs  on  the  STE  that were
     written on the Falcon. It seems as  if  the screen copy is carried out
     on interrupt, and you must  wait  a  similarly  long  time for them to
     finish before continuing with the  rest  of  your  program as with the
     fade. Or... use a faster command  which doesn't run on interrupt, such
     as blit from  the  missing  link  or  turbocopy  from  Control. End of
     problems. (For me anyway).

     To:- *.*
     From:- Martin Milner
     Subject:- PC Contemptibly/Atari magazines, etc.

     I'm as  worried  about  the  glossy  situation  as  much  as  anybody,
     but....think VERY carefully about abandoning your friendly Atari for a
     PC. I use a  486/33  Mhz  PC  at  work  and  it's  slow and it crashes
     ...regularly.  If  you  get   any   really  up-to-date  software  like
     Wordperfect 6, it takes an  age  to  do anything, especially load, (30
     seconds upwards sometimes), after loads  of  disk thrashing. Click the
     mouse on OPEN, and 10 seconds  later  you  might be allowed to enter a
     file name! Don't forget to add  VAT  onto the already expensive prices
     of software, and the market is so  huge, that you'll find it very hard
     to come up with applications that haven't been written already.

     Solution:-  Get  a   Falcon!   ST/256/True   colour  graphics/extended
     resolutions as standard, DSP chip, SVGA support, built in midi (if you
     need it), 16 bit sound, runs  your  familiar TOS OS, pretty compatible
     with most of your ST  applications,  fast,  can connect to SCSI disks,
     CD-ROMS, modems, etc.  The  more  people  that  keep  supporting Atari
     computers the more likely  ST  Format  and  companies supporting Atari
     computers are likely to continue. Think  about all the Atari computers
     in Europe, it's  about  time  we  started  writing  some software that
     they'll buy off us and not  the  other  way around. (I've got Magic 4,
     NVDI 4, CAB, getting STIK, etc. for WWW browsing.) These programs give
     Atari users many of the same facilities as their PC counterparts.

     The best thing about the Atari  using  community is of course the fact
     that there are things like Ictari where people can get help with their
     problems. (Hopefully).

     Anyway, that's enough of that for now. Food for thought, however.
     ----------------------------------------------------------------------
     To: George Hodgson
     From: Owen Rogers

     To read a file I  use  the  commands   OPEN IN #n,"Filename"  and then
     read each line of text in by using  INPUT #n,Variable. I finally close
     the file using  CLOSE #n. The   n   stands  for  a number from 1 to 10
     which is called a channel. Many channels can be opened at once.

     10 OPEN IN #1,"ADDRESS.DAT"
     20 INPUT #1,NAME$
     30 INPUT #1,ADR$
     40 CLOSE #1

     This would open a  file  called  ADDRESS.DAT  and  store the first two
     lines of text as the  variables  NAME$  and  ADR$.  It then closes the
     file. The channel number is 1.  See  PAGE  201 of THE STOS USER MANUAL
     for more info on loading and saving files.
     ----------------------------------------------------------------------
     To: All Members
     From: Paul Pickering

     If  anybody  has  any   of   the   following   ST   Format  disk  No's
     1,2,5,7,10,11,14,36B I would like to  either  buy  them from you or if
     possible a copy of them would  be  good.  I am also interested in some
     early ST Format magazines No's 1  to  19,22,27,29,31 to 34,38 to 41,43
     to 48,51,52,54 to 58 and I will buy them from you. Also if anybody has
     any books on the Atari ST they would  like to sell please let me know.
     If anybody is interested my address is in the MEMBERS.TXT file.
     ----------------------------------------------------------------------
     To: STOS users
     From: Jason J Railton

     Re:     Incompatibility

     It turns out I've got TOS 1.02, not 1.04 as I had previously believed.
     This could explain some problems people have had.  Still, I've sent in
     a program (PLODDERS.PRG) using  the  latest  compiler and Generic STOS
     fixer, so please test the  different  control  modes  in it and let me
     know if any still don't work.  If  I ever get around to commenting the
     code, I'll send that in too. It is fairly complicated and not much use
     to anyone though.  */ See next month for this program. ICTARI /*

     To:     *.*
     From:   Jason J Railton

     Re:     Polygon demo

     The polygon demo has now been re-written  in assembly, and a small 3-D
     maze has been  developed.   Anyone  whose  mouse  didn't  work with it
     before should now find it works perfectly,  and a lot faster too.  Let
     me know if you have any problems with it.  Press both mouse buttons to
     exit it, by the  way.   It  must  be  run  from  the  same folder that
     contains the two data files.  */ See MISC folder. ICTARI /*

     To: Assembly programmers
     From: Jason J Railton

     Re:    Reading the mouse

     I've also sent in two routines for reading the mouse in absolute mode.
     The latter of the two actually  processes the results to give relative
     mouse movements.  Rasters are used at the  same time as the mouse, not
     previously possible.  Unfortunately, you'd have to re-write the entire
     keyboard response interrupt (not just  the  mouse handler) to stop the
     rasters wobbling when you press a  key.   It  should be alright if you
     only use the rasters for one  or  two palette switches however. Again,
     both mouse buttons to exit.

     To:     *.*
     From:   Jason J Railton

     Re:     Atari / ICTARI

     As Peter suggested in  ICTARI  #34,  I  think  it's  time to seriously
     consider the future of Atari machines  and the ICTARI group.  However,
     I've noticed that the discussion  usually  turns to a pessimistic view
     of the decline  in  ST  users  and  magazines.   But  why  take such a
     depressing view? Why not stop for a  minute and consider the future of
     YOUR machine in YOUR home?

     Peter said that serious programmers  are  likely to consider moving to
     the PC, because that is where the majority of users are.  But who here
     really thinks that they can produce  a  program  that will make them a
     fortune?  If programming is your  hobby,  then  why  the urge to throw
     away everything you've done so far  and start from scratch again?  Why
     not keep tinkering with the ST?

     If you intend to learn to use various  facilities of a PC to help with
     your work, then why not do it at work?  Why bring it home with you? Go
     on a training course or something, that way you get paid.

     If you want to learn about  PCs  in  order  to  get a job, then by all
     means go ahead - although if you don't  have a job, it may not be such
     a good idea to spend that much money on a new computer.

     If you want a PC for the  family, that's worthwhile too.  The software
     is much more user-friendly.   But  why  not  keep  your  ST?  No doubt
     you've got some software you don't want  to lose.  And what else could
     you do with it?  You can't really sell it now.

     I'll admit that new, professional ST  software is somewhat thin on the
     ground, but haven't you  got  everything  you  need  by now?  The only
     thing missing, you'll agree, is  a  steady  stream of new games.  Now,
     this I'll admit is a major issue.  PC  games are far in advance of the
     latest crop of ST games, and are improving rapidly.  However, I have a
     simple response to this - PC GAMES ARE UTTER RUBBISH.

     Why do I say this?  Simple;  I've got something better.  At Christmas,
     soon after I'd  started  work  (I  graduated  in  June  last  year), I
     seriously considered buying a  PC.   I  weighed  up the advantages and
     disadvantages, and realised that I  wouldn't  be  happy unless I could
     play the  latest  games.   Certainly  I  wanted  to  keep  programming
     something, and be able to print  letters  and so forth, but I realised
     that the programming is largely  for  my  own  amusement, and my 9-pin
     printer in NLQ mode is quite adequate for basic correspondence.

     Then two facts came to mind - firstly, I would need to spend upward of
     a thousand pounds to acquire a suitable system for playing the best PC
     games around, plus maybe one or two  hundred  a  year to keep it up to
     date;  and  secondly,  that  the  best  games  around  simply  weren't
     available on the PC.  That is why, since February, I've been the proud
     owner of a Sony PlayStation.

     The PlayStation graphics and sound are  far  superior to even the most
     powerful Pentium PC.  The advent  of  PC  3D  accelerator cards may go
     some way to redress this balance,  but  bear  in mind that these are a
     year behind and are an extra cost.  The PlayStation cost me 300 pounds
     - I recently saw it down to  200  in  Dixons.  Games cost no more than
     those on the PC, if not slightly  less on average (particularly with a
     growing, good quality second-hand market),  plus  you get an excellent
     music CD player.  Some PC games  (Doom, Hi-Octane) have been converted
     to the Playstation, and  even  though  the  results  match these games
     running on high-spec PCs, with  better  shading (the corridors in Doom
     darken much more  smoothly),   they  look  far  inferior to equivalent
     PlayStation original titles (Alien  Trilogy,  Wipeout).  And how about
     Actua Soccer and  F1,  with  actual  interactive  commentary  by Barry
     Davies and Murray Walker respectively,  not  to mention Dolby Surround
     sound?

     My point is, if you want  something  to  play  games on, buy a machine
     dedicated to playing games.  The  PlayStation isn't clogged with Sega-
     type kiddies games.  Top PC stuff, improving upon even CD-ROM versions
     of the games, is being ported  across,  and,  best of all, you can get
     Tekken on it. And, you can still  power  up your ST to play about with
     programming.  I doubt any  home  hobbyist  really  needs anything more
     powerful.

     What about the Internet?  Well, you can go on-line (text-only, really)
     with your ST.  So you miss  out  on waiting hours for the ridiculously
     large images or sounds to download -  so what?  Anyway, until BT sorts
     itself out and more local service  providers start up, you're going to
     be spending a lot of money and  getting  very little out of it.  Trust
     me, I've used  the  Internet  and  Web  and  whilst  there's  a lot of
     information out there, most of it  is fairly irrelevant.  It's all too
     easy to get sucked in and think  it's  useful when it isn't.  It won't
     be  long  before  you  can  access   the  Internet  with  a  dedicated
     machine/console at far less cost than with a PC. Such units could even
     be leased by the service  provider,  like BT does telephones.  Perhaps
     this may be a long way  off,  but  who  knows?  There may be something
     worth connecting to by then (besides the ST web pages of course :-).

     So, am I suggesting you  become  a self-sufficient luddite hippy?  No,
     I'm just suggesting that you sit  down  and think about what you want,
     instead of what the publicity managers  tell  you that you need.  A PC
     costs a fortune, and the cost  of  constantly upgrading means that you
     effectively replace the entire system every  three to five years.  PCs
     may be getting more powerful, but this  just serves to keep the prices
     high.  New software releases invariably waste  the power and hard disk
     on features you  will  never  use,  and  are  often  full  of bugs and
     shortcomings to ensure you upgrade  to  the  next version (this is not
     paranoia - it is actually  the  standard  marketing strategy).  The PC
     may be a general machine, but  if  you  think  about it you can do all
     that you want from your PC far cheaper elsewhere.

     I would love a brand new Pentium  PC, Internet account and lots of new
     CD-ROM games to play with,  but  I'd  rather  have  the money to spend
     myself.

     I, for one, will stick with my ST  for some time to come.  I don't buy
     ST Format very often, because there isn't much in it for me.  However,
     I would seriously miss ICTARI if it  stopped.  I'd still keep in touch
     with anyone interested, although I  wouldn't  have the time to produce
     anything on a regular basis.  Even if  there's just me left, I'll keep
     tinkering.
     ----------------------------------------------------------------------
     To: Mrten Lindstrm & Peter Hibbs
     From: Jim Taylor

     Re - virtual VDU's/off-screen bitmaps

     I've had a go at converting the  GFA  code  you gave in iss 34, to C++
     and came up  with  the  listing  below.   Since  I  have absolutely no
     experience of GFA Basic, needless to say  it  does not work and I need
     further help.

     My v_opnbm does not seem to make any difference as the VDI still draws

     on     the     VDU     screen     when     the     program     reaches
     v_circle(v_handle,100,100,50).

     What am I doing wrong Mrten?

     /* ================================================================ */

     #include <aes.h>
     #include <vdi.h>
     #include <stdlib.h>
     #include <osbind.h>

     /* These are defined elsewhere in my main program */
     extern short    v_handle;               /* screen handle */
     extern short    scw, sch, scbw; /* screen sizes */
     extern int      dpi;         /* printer dots per inch (usually 300) */
     extern short    work_in[];
     extern short    work_out[];

     /* My attempt at v_opnbm */
     int v_opnbm(short xmax,short ymax,short wpix,short hpix,MFDB *mem)
     {
             short i, junk;

     /* What is this parameter Mrten */
     //      _VDIintin[0] = 2+Getrez();      /* Using GDOS */
             _VDIintin[0] = 1;    /* Not using GDOS according to HiSoft */
             for(i=1;i<=10;i++)
             {
                     _VDIintin[i] = 1;
             }
             _VDIintin[0] = xmax;
             _VDIintin[0] = ymax;
             _VDIintin[0] = wpix;
             _VDIintin[0] = hpix;
             for(i=15;i<=19;i++)
             {
                     _VDIintin[i] = 0;
             }
             _VDIcontrl[7] = (short)((int)mem>>16);  /* bits 31-16 */
             _VDIcontrl[8] = (short)mem;             /* bits 15-0 */

     /* according to the HiSoft C++ manual this should come next */
             appl_init();

             _VDIcontrl[6] = graf_handle(&junk,&junk,&junk,&junk);
             v_opnvwk(work_in,&_VDIcontrl[6],work_out);
             return  _VDIcontrl[6];
     }

     int v_clsbm(short bm_handle)
     {
             _VDIcontrl[6] = bm_handle;
             v_clsvwk(bm_handle);

     /* according to the HiSoft C++ manual */
             appl_exit();

             return 1;
     }


     /* Draw on the virtual screen */
     void draw_on_vscreen(void)
     {
             int     old_handle;     /* old window handle */
             int     mem_avail;      /* memory available from system */
             int     mem_reqd; /* memory required for a page of graphics */
             MFDB    vscr;     /* virtual screen Memory Form Def'n Block */

             float   drgs, drgl;     /* drawing short & long edges (mm) */

     /* INITIALISE */
             drgs = 210;             /* paper short side = 210mm */
             drgl = 297      ;       /* paper long side = 297mm */
             old_handle = v_handle;

     /* get available system memory */
             mem_avail = (int)Malloc(-1);

     /*      Formula for calculating memory required */
             mem_reqd = (((drgl/25.4)*dpi)*((drgs/25.4)*dpi))/8
     ie      mem_reqd = (       scw      )*(       sch      )/8
     ie      mem_reqd = (       scbw     )*(       sch      )
             mem_reqd = (int)(((drgs/25.4)*dpi*(drgl/25.4)*dpi)/8);

     /* If there is more memory than is needed use what is required
        else use what is available */
             if(mem_avail>mem_reqd)
             {
                     mem_avail = mem_reqd;
             }

      Calculate the screen sizes */
             scw  =  (int)(((drgl/25.4)*dpi)/8)*8;    /*  screen  width  in
     pixels */
             scbw = scw/8;                   /* screen width in bytes */
             sch = mem_avail/scbw;           /* screen height in pixels */

     /* Setup the MFDB */
             vscr.fd_addr = (void *)malloc(mem_avail);
             vscr.fd_w = scw;
             vscr.fd_h = sch;
             vscr.fd_wdwidth = scw/16;
             vscr.fd_stand    = 1;
             vscr.fd_nplanes = 1;

     /* Get its handle */
             v_handle = v_opnbm(0,0,scw,sch,&vscr);

             if(v_handle)
             {
             /* We should now be able to draw on the virtual screen,
                but in actual fact we are still drawing on the vdu !!?? */
                     v_circle(v_handle,100,100,50);
                     v_circle(v_handle,200,200,50);
             }
             else
             {
             /* print an error message */
             }

     /* Finished with the virtual screen */
             v_clsbm(v_handle);
             v_handle = old_handle;
     }

     */ The NVDI article next month also covers 'off-screen bit maps' which
     may help. ICTARI. /*
     ----------------------------------------------------------------------
     To: Peter Hibbs.
     From: Lou Maule-Cole.

     I joined the ICTARI club because  as  a retirement project I wanted to
     teach myself to program in C.   My  reason  for  doing so is because I
     have found on many occasions when  using  a  PC there are times when I
     needed a simple little program to  do  just precisely what I wanted to
     do  without  getting  involved  in  the  sometimes  extremely  complex
     applications supplied by the commercial company's such as Microsoft.
     I bought an ATARI STFM  about 8 years ago and I have never felt really
     frustrated with it, a comment I cannot make about 'IBM' type PC's.
     I retired before Windows NT was  available  so  I don't know what it's
     performance is like but I do know that running Windows 3.1 on a 486 PC
     at 60MHz was noticeably slower than my ATARI.

     Now this comes to the point of my letter -
     What a shame ATARI UK never  managed  to  market it properly. Even now
     the ATARI ST's have several  advantages  over  PENTIUM PC's. For those
     who want simply a machine to Word  Process, Desk Top Publish for their
     club or keep the accounts, home finance etc. For those who want simple
     but effective video  titling  or  want  to  do  the  odd architectural
     designs such as laying out the new  kitchen and also for those who are
     into music, the ATARI is the  cheapest  and simplest machine which can
     do all these things very well.

     Here is what I advise my friends  who  feel  they want to get to grips
     with technology and get into  word  processing but really can't afford
     to splash out 2000 to 3000  on  a  PC. Buy a secondhand ATARI 1040ST
     and a ink-jet or laser printer. Buy a high res monitor  to go with the
     ATARI but don't bother with a  hard  disc drive. Buy a word processing
     package such as 1st Word. Load up  the word processor and don't switch
     the machine off until you have completed all your typing.

     The ATARI has such a low consumption that this will cost you about the
     same in electricity as leaving  your  television  on stand-by and will
     make it far quicker and easier to use  than having to wait for a PC to
     boot up, and load a word processing  program before you can use it.  I
     wouldn't recommend leaving a  PC  with  a  hard  disc running for long
     periods if  your  worried  about  cost  of  ownership!!  Getting  into
     computers this way means that if you  find  it's not for you it hasn't
     cost an arm and a leg and you can always sell the printer.

     I'm certain there is still a wide  market out there for an entry level
     computer which can do these things  and  connect  to the Internet at a
     low price. The ATARI is ideal but nobody has marketed it properly, the
     public think it's a games machine with no games.

     On another subject,  I  am  just  completing  my  program, a gardening
     database, which I have written  using  my completely self-taught C and
     GEM and I hope that when it's completed someone out there will be kind
     enough to Beta test it.  I joined  ICTARI  because I thought that if I
     got completely baffled I could  always  ask  a  member for help.  I am
     proud to say that, so far, I have been able to work out how to achieve
     what I wanted to do by  myself.   On  occasions  it has taken a lot of
     trial and error I must admit. What  do  you reckon my chances of being
     able to do the same using a  PC?   I'm not into machine language and I
     don't really want to be.

     Good luck to you if you decide to  get a PENTIUM. My son-in-law let me
     use his the other  day  and  upon  switching   on  the DOS prompt said
     "Select operating system:-

                       1. MS-DOS
                       2. Windows 3.1
                       3. Windows NT.

     and at that point I switched off!!

     I know the difference between them but what a thing to ask my wife for
     instance. Later,  I  loaded  up  Word  for  Windows.  Now  I  was  the
     WordPerfect expert for my company before  I  retired.  All I wanted to
     do was to put a date on the left  hand side of a margin in a document.
     It was not obvious how to do it.  I clicked on Help and got the A to Z
     index but it was then almost impossible to guess what subject I needed
     in order to look up how to  achieve  that which I wanted to do.  After
     two hours  and  a  lot  of  experimental  clicking  with  the  mouse I
     eventually worked out how to do it.  That is not good software.
     ----------------------------------------------------------------------
     To: Richard Evans
     From: Mrten Lindstrm

     CLEAN SYSTEM-VECTOR CHANGES
     ===========================
     As far as I know, there are three general rules:

     1)      Adhere to the XBRA  protocol,  i.e.  precede your routine with
             the 12-byte structure:
       L: 'XBRA'  ;So that others can see that this IS an XBRA routine
       L: 'MyID'  ;ID of your program, or perhaps of its author
       L: The old vector (as read just before installation of your own)

     Then comes your routine.
     (Typically, the final action of  your  routine  should  be to read the
     third longword of its XBRA structure -  the pointer to the old routine
     - and jump to this address.)

     NOTE: Some routines need to  preserve processor registers while others
     don't. The Trap 2 vector is one where at least 2B make sure they don't
     touch a single register,  but  e.g.  an  etv_timer  routine is allowed
     unrestrained use of all registers.

     2)      Use BIOS SETEXC in preference to direct memory accesses (since
             this  will  allow  MiNT  or  MagiC  to  register  your  vector
             changes).

     3)      Try to confine  any  vector  changes  to  AUTO-folder programs
             only. If you break this third rule:

             A)      In a non-resident program you will, obviously, have to
                     uninstall your routine before program termination.

                     The cleanest way to do this  must be to trace the XBRA
                     chain back to your  own  routine (other programs COULD
                     have installed their own routines on top of yours) and
                     then unlink your routine  by  copying the "old vector"
                     of your XBRA structure to  the "old" (=your) vector of
                     any later XBRA routine (or,  if  your routine is still
                     on top, just restore the old vector).
                     If the XBRA chain has been broken by some sloppy devil
                     (overwriting the vector without adhering to XBRA) then
                     you CANNOT  terminate  normally  with  PTERM!!!  (That
                     would lead to a crash). Instead you must use PTERMRES,
                     or you could perhaps    tell   the   user    of   your
                     predicament and (on a multitasking  system) ask him to
                     try and kill the vandal  process  in  the hope that it
                     will tidy its mess  and  allow  you  too to unhook and
                     terminate with PTERM.

                     (Obviously, you can't use  Setexc for manipulations in
                     the XBRA chain, but I think  the real use of Setexc is
                     to allow the OS a  chance  to  register NEW vectors of
                     NEW processes (e.g.  for  the  management  of process-
                     specific vectors or perhaps  for  changing the process

                     memory status). When  the  process  terminates, the OS
                     probably knows everything it needs to know anyway.)

             B)      For the  event  that  your  program  will  find itself
                     running under MiNT (or MagiC  ?),  make sure that your
                     routine resides  in  "GLOBAL"  or  "SUPER"  memory. An
                     AUTO-folder  program   exited   with   PTERMRES   will
                     automatically have  all  its  memory  made  global (or
                     super?), but the default  is  otherwise PRIVATE (which
                     means that,  on  a  68030  machine  with  MiNT,  other
                     programs won't be able to access the memory).
                     The easiest way is to set  bit  4  and clear bit 5 (or
                     vice versa) of the PRGFLAGS longword (at offset 22) in
                     the .PRG file header. (These  flags cause no harm with
                     older TOS versions which merely ignore them.)

             C)      For MiNT (or MagiC?)  use  PSIGNAL ("GEMDOS 0x112") to
                     install a "signal handler" (i.e. a routine taking care
                     of any MiNT "signals").  This  is  somewhat similar to
                     redirection of the old etv_term  vector but neater and
                     more sophisticated.
                     The signal handler should  react  on  signals that can
                     kill the  process  by  trying  to  unhook  all changed
                     vectors (you don't  have  to  worry  about  the signal
                     handler itself though) and  then  terminate with PTERM
                     or PTERMRES according to the  success of this attempt.
                     (GEM calls are  not  allowed  from  the handler; other
                     system calls are.)

     The installation of the signal handler could look like (in C):

               Psignal(SIGTERM,handler);     /* Watch for SIGTERM */
               Psigsetmask(~(1L<<SIGTERM));  /* Block out other signals */

             Where "handler" is the (pointer to the) signal handler.

             Or, the same thing, in assembly:

                pea     handler(PC)      ;where "handler" labels routine
                move.l  #$112000F,-(SP)  ;Psignal - SIGTERM (signal 15)
                trap    #1
                addq.l  #8,SP

                move.l  #$FFFF7FFF,-(SP) ;Mask off all but SIGTERM (15)
                move.w  #$117            ;Psigsetmask
                trap    #1
                addq.l  #6,SP

             Note that the above calls should  be  harmless to make even if
             MiNT isn't there, since the ordinary GEMDOS will merely return
             -32 = "Invalid function number".

     One more note: To play it safe, it  could be a good idea to first read
     the old vector and write  it  to  the XBRA structure before installing
     your routine - avoiding any  possible  problems should your routine be
     called before it knows the old vector.  This means that TWO calls have
     to be made of SETEXC (the  first  one  merely inquiring the address by
     using a parameter -1). You may think  it  paranoid but it IS how 2B do
     their vector changes in the Enhancer  program that I disassembled last
     month as well as in NVDI.

     In a non-AUTO program, running  under  pre-emptive multitasking, I can
     see a potential further problem should another vector-changing program
     intervene just when you have read  the  old vector but before you have
     installed your own. Performing the  whole operation in supervisor mode

     would prevent that under current  versions  of  MiNT (and probably (?)
     MagiC too).

     Those are the  general  rules.  Now,  you  specifically  mentioned the
     etv_term vector, of which each  process  has its own version according
     to your MagiC documentation. I THINK this  applies to MiNT too, and it
     would seem to be the only safe  thing for a multitasking system to do.
     The way it works must  presumably  be  for  MiNT  /MagiC, on each task
     switch, to  copy  the  process-specific  etv_term  version  to address
     0x408. In any case,  it  isn't  anything  that  your  program needs to
     concern itself with; the normal rules  for vector changes can be used,
     though it is probably safer  than  with  other vector changes to break
     some of them. But I think you should stick to rule 2: Use SETEXC!

     Finally: I am NOT an expert on MiNT  and I know even less about MagiC,
     so if you would like to  convey  any  useful info that your MagiC docs
     reveals, or that your  experience  with  MagiC  has  taught you, in an
     article or two, that would be most valuable I think.

     This obviously applies to anyone else  too, with experience of MiNT or
     MagiC (or Geneva)!

     To: John Cove and all assembly programmers following his series
     From: Mrten Lindstrm

     First of all, the tutorial is  very  good,  clear and to the point and
     allows fast visible result from  very  few  lines of source. But there
     are some things I would like to comment on:


     1) HARDWARE ACCESSES vs SYSTEM CALLS
     ------------------------------------
     I think it should be  pointed  out  (if  by  any chance anybody hasn't
     already understood this) that John's  series  is highly geared towards
     GAMES programming, where speed  is  the  priority and compatibility is
     not. Thus, most of the  things  he  does by directly accessing various
     hardware registers are possible to do  with system calls (the "traps")
     too (the notable exception being  the screen frequency). The advantage
     of using system calls, is that  OS extensions or graphics card drivers
     etc, may redefine the system functions to work with new hardware or an
     improved OS, while if you access the Atari hardware directly, there is
     no such chance and you are  definitely  stuck with the bog standard ST
     configuration. (One further advantage of  system  calls  is you can do
     them from user mode - see  my  reply  below to Stephen Bruce on super-
     visor and user modes.)

     On the other hand, the system calls are slower than directly accessing
     hardware registers. Taking the screen colours for example: if you only
     change them a few times, there  is  no problem ("slow" in this context
     still only means small fractions  of  a millisecond). But for advanced
     colour trickery, like in the  Spectrum  512  paint program and in some
     games, you need to change colours  in  a  few MICROSECONDS and have no
     alternative to accessing the hardware directly.

     I also recognize that there may be an educational value in direct (and
     concrete) hardware accesses compared to  (more abstract) system calls.
     (Plus the former usually  require  less  code  lines than the latter.)
     Even if you later are to use system  calls, it may also be of interest
     to know how, in the end, the  system  will probably do it if you don't
     yourself.

     But in ONE case - the key_loop  routine presented last month - I think
     John may have overdone it a bit, when  he  even had to throw in a call
     of VSYNC to make the direct reading  of the keyboard ACIA chip work. I
     cannot see much point in  accessing  this particular hardware directly

     anyway and would strongly  suggest  the  following, less problematical
     and not really more complicated, alternative:

     key_loop  move.l  #$20002,-(SP)   ;BCONIN - Console (= keyboard)
               trap    #13             ;BIOS
               addq.l  #4,SP           ;(Correct the Stack Pointer)
               cmp.b   #' ',D0         ;Space character?
               bne.s   key_loop        ;Loop back if not


     2) DS and DC
     ------------

     In part one I did notice an error (or two even). The line:

            sts_colour_bank      dc.l     16

     was used to allocate storage space for  an ST hardware palette. But it
     really should have read:

            sts_colour_bank      ds.w     16
     ( or   sts_colour_bank      ds.l      8 )

     Of course this must have been  only  an  oversight on John's part, but
     for the assembly learners here is the explanation:

     DS means that the given  number  of  "storage  units" (Bytes, Words or
     Longwords) will be placed in the program,  just where you wrote the ds
     line. All of them initialized to zero.

     DC, on the other hand, means that  single units (bytes, words or long-
     words) will be allocated, INITIALIZED TO THE GIVEN VALUE.

     Thus "dc.l 16" will  give  you  a  single  longword initialized to the
     numeric value 16. "ds.w  16"  will  allocate  16 WORDS (initialized to
     zero) which is just the  amount  of  space  needed  for an ST hardware
     palette.

     By the way, the following two lines:
           dc.w  0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0  ;16 zeros
           ds.w  16
     are entirely equivalent.


     3) Assembler directives - processor instructions. Data - code
     -------------------------------------------------------------
     (This is not in  response  to  John's  tutorial,  but  to last month's
     discussion - Stephen Bruce and  the  Ictari  reply  - relating to it.)
     Just to straighten out some possible misunderstandings here:

     In assembly contexts I  think  there  is  normally  a distinction made
     between "INSTRUCTIONS", referring to  commands  to  the PROCESSOR i.e.
     what will eventually make up the  program, and "DIRECTIVES" = commands
     directed purely to the ASSEMBLER. Examples:
      +      "RTS" (ReTurn from Subroutine)  is  an  instruction - that the
             assembler will directly translate to  a certain hex code $4E75
             - associated with a specific processor action (on encountering
             it the processor will pop  a  longword - presumably the return
             address - from the stack  and  load  it  into the PC register,
             causing a jump to this address).
      +      "DC" (Data Constant),  on  the  other  hand,  is  an assembler
             directive. There is  no  specific  processor action associated
             with DC, and the  only  hexcode(s)  that  a  DC directive will
             result in, is what  is  used  for  its  operands, and could be
             anything.

     You COULD, if it amuses you,  write  "DC.W $4E75" instead of "RTS" and
     the  end  result  (in  the   assembled   program)  would  be  entirely
     equivalent. But in most cases you will use DC only for DATA. (The most
     notable exception is Line-A "instructions" which per definition aren't
     real instructions and have to  be  written  with DC. E.g. "DC.W $A000"
     for a call of L-A Init.)

     "Self-modifying code" is  something  that  should  be  avoided  in any
     program intended to run on machines with instruction caches (including
     MegaSTEs and all  68030  machines:  TTs  and  Falcons).  But  for this
     purpose you really only  need  define  the  "code"  of your program as
     those bytes and words  that  might  actually  be  traversed  by the PC
     (Program Counter - an  address  register  always  pointing to the next
     instruction to execute), and executed as processor instructions.
     Again, memory locations created with  DC  or DS directives are usually
     NOT in this category, simply because you will normally not place these
     directives in the middle of the instruction flow.

     And don't confuse the DC (Data Constant) of the assembly language with
     constants  of  high  level  languages.  The   name  of  DC  is  really
     misleading, since it  only  means  that  the  memory  (bytes, words or
     longwords) allocated by it will  be  INITIALIZED  to the given values.
     There is no prohibition against  CHANGING  it (except, again, in those
     very rare cases were DC is placed  in the instruction flow to serve as
     a processor instruction).


     To: Stephen Bruce

     Supervisor mode vs User mode
     ----------------------------
     There are, I think, essentially two reasons to remain in user mode:

      1)     System variables and hardware addresses are protected, meaning
             that unintended writing  to  them  (due  to  program  bugs) is
             prevented and instead leads to a bus error exception. This may
             reduce the effects  of  a  program  crash,  in particular with
             debuggers, TOS extensions and  newer  TOS  versions capable of
             intelligently trapping bus errors and other error exceptions.
             Plus a bus  error  is  easier  to  spot  (and  correct) during
             debugging than a corrupted system variable.

      2)     Under (current versions  of)  MiNT/MultiTOS,  no task switches
             occur  while  in  supervisor  mode   -  i.e.  the  pre-emptive
             multitasking doesn't work.
             In addition, AES  calls  are  trickier  to  do from supervisor
             mode, (although still possible, see my message in Ictari 32).

     But, as long as you (1)  are  sure  your program contains no bugs that
     could be alleviated by the user mode,  and (2) don't care about GEM or
     MiNT, I guess you  could  run  constantly  in supervisor mode, without
     problems.


     To: Kevin Cooper
     From: Mrten Lindstrm

     PC GEM
     ------
     I have only seen PC GEM once in my life, and very briefly. It was on a
     PC running DynaCADD - the Canadian ST  power CAD program ported to the
     PC. (Now that I have a  PC  it  might  perhaps  be  fun to have PC GEM
     though, but where  would  I  get  it?)  Nevertheless  here  is  what I
     BELIEVE. Provided that ...


     A)      you have a C compiler with GEM  libraries on the PC as well as
             one on the ST

     B)      you don't use any  XBIOS  (or  BIOS)  or low-level accesses of
             hardware or system variables (i.e. use only GEM and (GEM)DOS)

     ... I THINK you should be able  to  port your Atari GEM programs to PC
     GEM without too much trouble.

     GEM file formats are much the same  on  PC and ST. Thus, GEM Metafiles
     (.GEM files) are in Intel format on  both  Atari and PC, IMG files are
     in Motorola format on both Atari  and  (I  recently found out) PC. GEM
     bitmap font files (.FNT files)  have  a  Motorola  format flag, but in
     practice are nearly always in Intel format on the Atari as on the PC.
     Regarding GEM resource files (.RSC files)  I am uncertain (they are in
     Motorola format on the Atari). But, on  the other hand, you can always
     convert them into C source (there  are many RSC-to-C converters in the
     PD and maybe there was one published in Ictari?).

     Some of the more recent GEM functions  may  not  be the same on PC and
     Atari, but I KNOW that at  least  Bzier  curves came to PC GEM before
     they were implemented on the Atari, and I would be highly surprised if
     they aren't entirely compatible with Atari FontGDOS and SpeedoGDOS.

     On a PC in "16-bit mode", which  I'm  sure is what PC GEM uses, memory
     addresses are represented in a very  peculiar  way. On the other hand,
     the C language may to some extent be able to conceal these differences
     from you, if you  don't  make  any  too  tricky  and low-level pointer
     manipulations.
     (You may possibly also  have  to  redefine  pointer  types and integer
     types with some DOS calls (?).)

     If you do carry out  this  project,  even  with  just a very small GEM
     program, it would be interesting to hear your experiences.


     To: Owen Rogers
     From: Mrten Lindstrm

     Changing AES objects
     --------------------
     If you study the structures that  make  up  the different kinds of AES
     objects, you will be able to manipulate  them in all kinds of ways, at
     runtime or, if you like, in  the  RSC  file. (For instance, I wrote an
     article for Ictari about GEM  resources,  published  in Ictari 21. The
     GFA Basic 3 manual also contains some info.)

     Your specific question concerned BOXTEXT  (=  type 22) objects, and in
     these the OB_SPEC field  (see  below)  is  the  address of a "TEDINFO"
     structure. The first longword  of  the  TEDINFO,  in  its turn, is the
     address of  the  (null-terminated)  text  string,  and  changing  this
     address to point to some other  null-terminated text string means that
     the text of the BOXTEXT object  will  be  changed. However, if the new
     string is of different LENGTH, you  will  also have to change the word
     at offset 24 in the TEDINFO,  which  gives the string length including
     the ending null byte. You may  possibly  also  have to change the OB_W
     field in the OBJECT structure, giving  the  object width in pixels. On
     the other hand you could  dimension  the  object with some extra space
     from the start.

     *       OB_SPEC is the longword at  offset  12 in an object structure;
             in GFA Basic 3 you can access it with OB_SPEC(tree%,obj&)

     *       OB_W is the word at offset  20  in an object structure; in GFA
             Basic 3 you can access it with OB_W(tree%,obj&)

             NOTE: In objects prepared for use (e.g. loaded with RSRC_LOAD)
             all coordinates and dimensions  are  given  IN  PIXELS (in RSC
             files  on  disk,  on  the  other   hand,  they  are  given  in
             characters).

             Call GRAF_HANDLE(width,...)  to  get  the  width  of  a system
             character, if  you  need  it  in  calculations  of  new object
             widths.
             You COULD instead use 8  pixels  per  character but that would
             NOT be the 100% clean  way  since,  although any normal system
             font is  always  8  pixels/character  wide,  other  widths ARE
             conceivable.

     Users of GFA Basic  (and  probably  of  other  Basics  too  as well as
     Pascal) should note that the native  strings  of your language are NOT
     null-terminated (but the ones of  C  are).  However,  you can create a
     null-terminated string simply by  adding  a  null character CHR$(0) to
     the end of a  normal  string.  Users  of  GFA  Basic  3  also have the
     alternative to read and write null-terminated strings with CHAR{addr%}


     To: Any users of my PICPAC library (for picture packing/unpacking)
     From: Mrten Lindstrm

     NEW PICPAC ?
     ------------
     I have sent in corrected versions  of  some  of the files published in
     Ictari 24, and these may perhaps be  found on this disk. However, when
     starting to dig in my PICPAC  source  again,  I have realized that the
     library could have  been  made  neater  in  many  ways,  so you should
     perhaps be warned that  PICPAC  soon  MIGHT  (?)  reappear  in a (once
     again) revised form.

     Don't take this promise  (threat?)  TOO  seriously  since for the time
     being I have  got  many  other  things  to  do,  but  the  changes and
     additions that I would LIKE to make are as follows:-

     1)      Colour sorting and remapping routines. Colour remapping can be
             generally useful to adapt the palette  of one image to that of
             another. But, as  I  have  come  to  realize  the  more I have
             thought  about  it,  GEM  programs  in  particular  need  this
             capability in order  to  minimize  interference  with  the GEM
             "system palette"!

             Atari recommends that the first 16  VDI pens be left as system
             colours* and not changed  by  applications,  and although that
             may be hard to strictly abide  by  (in particular on a display
             that doesn't have more  than  16  colours),  it would be worth
             something if  picture  colours  could  be  remapped  to  their
             closest "system" equivalents  (retaining  at  least the system
             white, black and red perhaps).

     2)      Fully integrated VDI use in the  library (so that for instance
             GEM colour sorting can be  integrated, and perhaps easy-to-use
             VDI sprite-blitting routines too).
             I have so far  refrained  from  that,  partly because I didn't
             want to rely on the  Devpac  -  or  any  other - GEM libraries
             (sure, most assembly GEM  programmers  probably  use these but
             still) and partly because  I  didn't  want  to internally call
             V_OPNVWK for all the potential problems that could create (not
             least with GEM ACCESSORIES  which  in principle shouldn't open
             any VDI workstation except when loading).
             I now intend to leave out  the  opening of a VDI virtual work-
             station, but require  that  its  HANDLE  be  passed to PICPAC,
             which will then perform any  further  required VDI calls, low-
             level and without requiring any macro libraries to assemble.

     3)      A single unified routine  for  unpacking  and  perhaps one for
             packing (instead of one  for  each  picture  file format). And
             instead of passing  a  pointer  to  a  memory  block  with the
             already loaded file, I would like the routine to simply take a
             FILE SPECIFICATION and perform the  loading itself (as well as
             the analysis of what file format it is).
             If this is implemented, would there  be any interest for still
             keeping the functions unpacking pre-loaded files in memory?

     4)      Perhaps support of the PICTURE MASK  of IFF ILBM pictures (and
             possibly other formats). Peter Hibbs recently asked about some
             system for compressing sprites, and  one simple solution could
             be to save the sprite collection as  one or a few ordinary IFF
             ILBM  images,  of  arbitrary  dimensions,  WITH  a  mask.  The
             vertical word compression  of  this  (Deluxe  Paint) format is
             quite effective.

     ......................................................................
     * "FOOTNOTE" TO THE ABOVE REMARK ON "SYSTEM COLOURS": PC Windows, on a
     screen in palette mode, also reserves  a number of system colours: the
     first 16 of these are the only  ones  used for colour icons (further 4
     are apparently (?) reserved in the  event  that  the user wants a non-
     standard colour for the desktop or something).
     The 16 "PC icon colours" are:   black  and white,  two shades of gray,
     two shades each of red, green, blue, yellow, cyan, magenta.
     As you see, very similar to  the  default (first 16) Atari colours (as
     long as we don't go into the  ORDER  of the colours). But a difference
     is that - instead of the  Atari  LIGHT  (or pale) red (="pink"), light
     (pale) green etc. - DARK versions are used. There is no doubt that the
     PC dark colours are more usable  than  the  Atari pale ones (e.g. dark
     red or dark yellow can be  used  for  brown,  and all dark colours can
     provide "shadow" for the intense  versions).  But  any Atari user - or
     configuration program - could change  that  of  course.  Thus, may I -
     just for icons  and  similar  GEM  purposes  and  provided that enough
     colours are available - suggest  that  everybody  tries to use the "PC
     icon colours" (given below in VDI  colour  pen  order, NOT Atari or PC
     hardware colour order, and on an  intensity scale 0-255 - i.e. 255=max
     intensity, 128=half intensity):

     pen:red,green,blue
      0: 255,255,255    4:   0,0,255      8: 192,192,192   12:   0,0,128
      1:    0,0,0       5:  0,255,255     9: 128,128,128   13:  0,128,128
      2:   255,0,0      6:  255,255,0    10:   128,0,0     14:  128,128,0
      3:   0,255,0      7:  255,0,255    11:   0,128,0     15:  128,0,128

     The first 10 VDI pens  have  (approximately)  the normal Atari default
     colours while the last 6 are changed  (darkened). (In my view the dark
     colours are a bit TOO dark,  and  I  prefer to turn up their intensity
     slightly, but that's not a big issue.)

     Neodesk (allowing colour icons on bog standard STs too) is one program
     that defaults to, approximately, the above.
     ----------------------------------------------------------------------
     To: Jason Railton
     From: Stephen Bruce

     R.E. Polygon demo, ICTARI 31

     Just a short note to let you know that the generic STOS fixer supplied
     on ICTARI 34 was  successful  at  enabling  the  mouse on your polygon
     demo. Previously, there was no response from  my mouse, but I must say
     I was surprised by its speed now that  I've seen it. N.B. My system is
     a plain 520STe with 1 Meg RAM & 2 floppies.

     To: All
     From: Stephen Bruce

     I've just invested in a copy of  Instant C Programming by Ivor Horton.
     It seems to be very well presented &  easy to understand but I trust I
     can rely on your support should I run into any problems. I'm currently
     trying to get a pseudo 3D landscape running in real time (as in Virus)
     but I would like to  know  if  using  C's  floating point math library
     routines will slow things down greatly,  or should I use precalculated
     look up tables. I've already figured out most of the theory behind the
     maths involved, but I'd like to establish this before I start actually
     programming. Most of my routine  relies on basic triangulation (Sines,
     Cosines, etc).

     P.S. I will NOT be defecting to the PC. At present my old Atari serves
     all my 'serious' computer needs, &  I've just bought a PlayStation for
     games. If anyone else is  considering  upgrading  to  a PC, I strongly
     suggest you look at the Sony first  if  games are what you want as the
     price has just dropped to 200.  Some  PC titles are already available
     on PlayStation & many more are to come (e.g. Dark Forces).

     ------------------------------ End of file ---------------------------
