
     ICTARI USER GROUP             ISSUE 36                      July 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 36
                              ==================

     ASSEMBLY        ST Assembly Language Workshop. Chapter 1.

     C               Monochrome fade functions.

     GFA             Date and time setting procedures.

     STOS            Mouse and Joystick test routines.

     MISC            NVDI information.
                     SCSI FAQ.
                     File Viewer program demo.
                     Current membership list.

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

     ASSEMBLY        ST Assembly Language Workshop. Chapter 2.

     C               Richard Harvey. C Tutorial Part 1.
                     Garden Database program.

     GFA             Various font routines.

     STOS            Alert box routine for STOS.

     MISC            Icon images.

     ----------------------------------------------------------------------
                                   EDITORIAL
                                   =========
     POSTAL CHARGES
     --------------
     The postal charges have increased  to  20p  for  a second class stamp.
     Please send the correct value stamps  when  returning a disk. The cash
     rates will stay the same.

     KELSTAR DISKZINE
     ----------------
     I had a letter from  Bob  Kell  telling  me  about a disk magazine for
     Atari users. It doesn't  cover  programming  as  such  but has various
     Atari related articles, etc. If anyone is interested in getting a copy
     you can contact Bob at :-

             22 March Crescent
               Cellardyke
                 Fife
                  Scotland  KY10 3AE

     ARTICLES
     --------
     We still need more programming  articles  and some more correspondence
     would be of interest also. If you haven't written in before (and there
     are quite a few who haven't) perhaps  it is about time you contributed
     in some small way to the magazine.
     ----------------------------------------------------------------------
                                 CORRESPONDENCE
                                 ==============
     To: *.*
     From: John Levon

     Re: VDI Enhancer

     v_opnbm would be very useful, but I'm  not really happy with forcing a
     user to install another  auto  program  just  to  run my program using
     v_opnbm. Is there any  (pref.  C)  code  around  to  install a similar
     function without having to place  anything  in  the auto folder ? Then
     the program could check the  EdDI  cookie,  and if wasn't present, use
     its own routines ...

     Has anyone tried to get  NKCC  2.93  working  with  Lattice C (V5.6) ?
     dr2lc (converting from DRI to Lattice object format) seems to work but
     on compilation Lattice complains that  some  (why only some ?) symbols
     were undefined e.g. nkc_multi isn't defined but others are.

     PS. In case anyone else  hasn't  mentioned  it,  the A.C. (and Lattice
     docs) incorrectly describe the  array  returned by vqt_[f_]extent. The
     bounding box is actually :

                                  1----------2
                                  |          |
                                  4----------3

       which is a lot more logical.
     ----------------------------------------------------------------------
     To: ICTARI
     From: Peter Strath

     Re: File Viewer
     WARNING: The layout of a saved EFI list has been changed to allow for
              future extensions.   EFI lists saved with FVb1 will NOT work
              with any later versions.

     I would like to thank  all  those  who  wrote  in with comments and/or
     suggestions on the first  beta  release  of  my  program, File Viewer.
     I have included the  2nd  beta  version  of  my  program on disk which
     includes some of those suggestions.

     Bug fixes are  mentioned  in  CHANGES.TXT  and  bugs  still present in
     FVMAN.DOC in the FVIEWER directory.

     Below are replies to  the  comments  made  which  I  have answered one
     point at  a  time,  so  the  text  won't  mean  much  unless  read  in
     conjunction with the original comments.

     To: Peter Hibbs
     From: Peter Strath

     Re: BETA TEST PROGRAMS
     I'm glad you found the program  useful,  it  will become more and more
     useful as my understanding of programming and design increases.

     Your request for  file  sorting  has  been  implemented  and file list
     window resizing added to my to do list. More picture formats have been
     added and I have  managed  to  get  them  to  all  be  viewed in the 3
     different ST resolutions accept 16 colour images in ST medium.

     You can hide from  view  'Re-read  directory' and 'Previous directory'
     using the 'File Information\Options' dialog,  opened by right clicking
     on any entry. 'Previous directory' is hidden by default.

     Regarding  file  sizes;  As  yet  I   haven't  looked  into  the  disk
     operations required to  calculate  actual  disk  space  used by files,
     although to display  this  prominently  on  the  information  line may
     confuse novice  users  and  would  be  more  useful  displayed  in the
     File Information dialog for folders and drives.

     I will be looking into converting  between different file formats when
     I've learnt enough about the various file formats.

     To: Jason J Railton
     From: Peter Strath

     Re:   File Viewer
     The program is being developed  to  handle  as many types of file/data
     formats as I can write for  it,  including; static images, plain text,
     formatted text, databases, etc...
     The first beta version only  handled  IMG  and  plain text. The second
     beta version adds support for NEO,  PI[1-3]  and PC[1-3]. I am testing
     a 1st Word Plus viewer  and  I'm  in  the  initial stages of testing a
     simple database viewer interface, nasty  bugs  aside both should be in
     the third beta version.

     If you have any other file  formats  you would really want File Viewer
     to handle then please write in.

     To: Stephen Bruce
     From: Peter Strath

     Re: File viewer Beta test
     Thank you for your encouraging  comments  on  my program. I intend the
     completed project to be uncrippled shareware with a reasonable fee for
     continual usage, although beta testing may  take another few months to
     complete.

     Resizable, multiple  file  lists  and  longer  EFI-long-filenames have
     been added to my to do list.

     In a future version there  will  be  an  option to determine the scope
     of an EFI, local or global.
     A global scope would  mean  any  file  with  the  specified name would
     obtain the EFI data wherever it  was  located.  The EFI would be saved
     in one centralized list on disk called GLOBAL.EFI.
     An EFI with local scope will have  its data saved in the directory the
     specified file was in, in a file called LOCAL.EFI.
     Local EFIs with  the  same  short  name  as  a  global  EFI would take
     precedence.

     I agree with you on  keeping  the  Re-read  directory and removing the
     Previous  directory,   the   new   hide   from   view   option  ('File
     Information\Options'  dialog)  used  in   conjunction  with  the  menu
     option 'Show\Hidden files' enables you to hide/unhide any file.
     Be warned though that it will  hide  from  view any file with the same
     name in any directory (global  scope).  This  only affects File Viewer
     and not any other programs.

     The  drive  list  can  be   quickly   accessed   by  the  menu  option
     'Tree\Drive list'.

     I cannot say if internal  file  editing  will  be added because of the
     time it would take and the large memory requirements required.
     A simpler solution would be to use the current crop of applications as
     file editors and use File Viewer as  a previewer which can load a file
     editor with a specified file if needed.
     ----------------------------------------------------------------------
     To: All (C users)
     From: Mrten Lindstrm

     C++
     ===
     Net trekers: I just saw  (in  Windows  Developer's  Journal - July 96)
     that the draft ANSI C++ standard can be found on the Web address:

             http://www.cygnus.com/misc/wp/draft

     I don't know how big it is  (maybe  it's HUGE) but if anyone checks it
     out and  finds  that  it  could  fit  on  an  Ictari  disk  (or  two?)
     (compressed), then I think many would be interested in it (I would).

     Users of Lattice C: Is Lattice C  a  C  or  a  C++ ?  I have seen some
     Ictari members refer  to  it  as  C++,  but  have  failed  to  see any
     notification from Hisoft or  elsewhere  that  Lattice  C was made into
     C++, and I would have expected them  to make at least some noise about
     it.
     I HAVE understood that Lattice C  apparently recognizes C++ style one-
     line comments (preceded by // rather than  enclosed in /* and */). But
     can it cope with other  C++  features  too? E.g. C++ operators: "new",
     "delete" etc. or even full-fledged C++ CLASSES.

     GNU C++ (FREEWARE but requiring 4  Mb  and hard disk) is otherwise the
     only C++ for Atari computers that I  know  of. From what I have heard,
     GNU C/C++ contains some  irregularities  (non-standard extensions) but
     on the other hand it  is  available  on  all  platforms, and by cross-
     referencing the ANSI C++ standard mentioned above it would be possible
     to avoid using anything  that  isn't  standard.  Does  anyone have any
     experience of GNU C/C++ ?


     To: Jim Taylor and other C programmers
     From: Mrten Lindstrm

     LOW-LEVEL VDI CALLS   (Ref: The VDI Enhancer - Ictari 34)
     -------------------
     Oh dear, I really only intended my  GFA  listing to be a help for some
     of "the poor  devils  who  don't  use  C".  There  were some C-related
     descriptions  bundled  with  the  new   VDI  functions  (in  the  file
     NEW_FUNC.TXT, Ictari 34),  but  I  am  not  exactly  an  experienced C
     programmer and I didn't study these very  much to find out how helpful
     they might be.

     First, here is your translated C  versions  (from Ictari 35) of my GFA
     Basic functions v_opnbm  and  v_clsbm  (Ictari  34),  with  some fresh
     corrections by me. Then follows  some  explanations.  (If, as you say,
     you have absolutely no experience of GFA  Basic, I think you have made
     a good job of translating my GFA code  to C. Perhaps other C users can
     benefit from it?)


      int v_opnbm(short xmax,short ymax,short wpix,short hpix,MFDB *mem)
      {
              short i, junk;
              _VDIintin[0] = 2+Getrez();      /* with Atari GEM */
              for(i=1;i<=10;i++)
              {
                      _VDIintin[i] = 1;
              }
              _VDIintin[11] = xmax;  /* You had left 0 for these indexes */
              _VDIintin[12] = ymax;
              _VDIintin[13] = wpix;
              _VDIintin[14] = 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 */

              _VDIcontrl[0] = 100;  /* OP code for v_opnbm or v_opnvwk */
              _VDIcontrl[5] = 1;    /* Sub-op code for v_opnbm */
              _VDIcontrl[1] = 0;    /* No ptsin elements */
              _VDIcontrl[3] = 20;   /* 20 intin elements */

              _VDIcontrl[6] = graf_handle(&junk,&junk,&junk,&junk);

              vdi();                /* Make the actual VDI call! */

              return  _VDIcontrl[6];
      }


      int v_clsbm(short bm_handle)
      {
              _VDIcontrl[0] = 101;  /* OP code for v_clsbm or v_clsvwk */
              _VDIcontrl[5] = 1;    /* Sub-op code for v_clsbm */
              _VDIcontrl[1] = 0;    /* No ptsin elements */
              _VDIcontrl[3] = 0;    /* No intin elements */
              _VDIcontrl[6] = bm_handle;
              vdi();
              return 1;
      }

     // (I hope this will work!)

     Apart from the small error with  some array indexes, the major problem
     was with the  low-level  VDI  call  itself  (in  GFA  Basic 3: "VDISYS
     100,20,0,1"), where you made a  call  of  v_opnvwk. But that will only
     undo your previous  work  of  filling  in  the  VDI  arrays, since the
     v_opnvwk binding of you C package will  have  its own ideas of how the
     VDI arrays should be filled in.

     vdi() - with no parameters - is  instead the function call to use. The
     simple vdi() function (or similar) will hopefully be defined somewhere
     in your C libraries. If not, it  can be defined based on the following
     small assembly routine:

     _vdi:  move.l  #_VDIpb,D1
            moveq   #115,D0
            trap    #2
            rts

     where _VDIpb is the  address  to  the  VDI parameter block (containing
     pointers to the VDI arrays, in the order contrl, intin, ptsin, intout,
     ptsout). I don't have Lattice C myself,  so you will have to study its
     documentation for  the  details  regarding  how  to  include  assembly
     language routines.

     I also have added  assignments  for  _VDIcontrl  elements 0,1,3 and 5.
     (These were built-in to the GFA VDISYS command.)

     Furthermore, I was a little suspicious  about the use of appl_init and
     appl_exit within your  VDI  function  definitions.  I  think  you will
     normally call appl_init  only  once,  at  the  start  of  your program
     (before you make any other GEM calls) and appl_exit once at the end of
     your program.

     In relation to the VDI, appl_init  (registering your program as an AES
     application) only serves the one  purpose  of making available the AES
     call graf_handle(&junk,&junk,&junk,&junk), which  returns the physical
     screen VDI workstation handle in use by the AES. You need the physical
     screen handle, as input to contrl[6], before you can call v_opnvwk (or
     v_opnbm) to get a virtual one.
     By the way: I think you asked what the parameter "junk" stands for. It
     will return the dimensions of the system character cell (normally 8x16
     or 8x8 depending on screen resolution) and  the minimum size of an AES
     boxchar object. If you were interested  in these you could rewrite the
     call as graf_handle(&wchar,&hchar,&wboxchar,&hboxchar).

     Finally: I think it doesn't do any harm, with Atari GEM, to ALWAYS use
     work_in[0] = 2+Getrez(); (or  _VDIintin[0]  = 2+Getrez();). Regardless
     of whether or not GDOS  is  present.  Though  for PC GEM, work_in[0]=1
     should instead probably be used.

     To: Peter Hibbs and everybody else
     From: Mrten Lindstrm

     "DLLs" for the Atari
     --------------------
     (= External function libraries, callable during run-time)

     This is a very  interesting  topic  you  raise,  and  I  think we have
     already been touching on it  during  discussions  on ways to implement
     universal printer drivers and VDI extensions.

     There already exists, as you say, something  similar on the Atari - in
     the form of memory-resident (AUTO-folder) programs that hook into trap
     vectors or make available  addresses  (via  the  cookie  jar) to where
     programs can jump. Examples are GDOS, NVDI or the VDI Enhancer program
     published in Ictari  34,  all  of  which  make  available  a number of
     functions that aren't  in  TOS  ROM.  I  HAD  already been considering
     turning my  PICPAC  library  into  a  memory-resident  library  module
     similar to these.

     But your proposal was to make  it  possible  to load libraries only on
     demand (and unload them afterwards)  and  also perhaps to provide some
     standardized interface for the opening  and  closing of libraries. And
     the following is the best solution that I can think of:

      +      A library manager program, run from  the AUTO folder, and that
             reserves a separate pool of  memory into which library modules
             can be loaded.  This  way  it  will  work  with  e.g. GEM Desk
             accessories. (Just loading a library  into  any block got with
             GEMDOS MALLOC wouldn't be safe,  since  such memory blocks are
             freed when the main application, that  was running at the time
             of allocation, terminates).
             The size of the pool should be easily configurable by the user
             (e.g. by changing a numerical suffix  of the manager file name
             - similar to how Atari's FOLDRxxx works).

      +      This manager installs a cookie whose  value  is a pointer to a
             function dispatcher (or possibly  to  a  structure in its turn
             containing the  pointer  to  the  dispatcher).  All  calls  to
             library  functions  are  made  via  this  dispatcher.  Special
             "OpenLib" and "CloseLib" calls must  be made by an application
             before and after using any of the functions in a library.
             The way I conceive "OpenLib", it  would  take as a parameter a
             pointer to a (file) name string  for  the library to open, and
             return a (long) value  that  should  be  used with any further
             calls of this library. The  function number within the library
             should be added to  the  value  and  the  result used as first
             parameter  of  each  call.  (Thus   the  library  manager  can
             determine both library and function from the leading parameter
             of each call it gets.)
             If the last byte  of  the  library-identifying  base number is
             always zero, there would be  room  for  up to 256 functions in
             each library.

      +      When the free memory of the  pool  isn't  enough to load a new
             library, any currently unused library modules (closed by every
             caller) can be "unloaded"  and  their  memory  returned to the
             pool.
             (If  library  modules,  according   to   my  above  idea,  are
             identified by a base  function  number,  rather than called by
             direct address, it would perhaps  even be possible to RELOCATE
             (unload and reload) library  modules  in  order to fill memory
             gaps, i.e. "defragmentize" the library memory pool.)

      +      All function  calls  are  made  according  to  the  standard C
             calling convention. (On the low  level meaning that the caller
             is both pushing parameters on  stack  - last parameter first -
             and,  afterwards,  tidying  it.  The  call  itself  is  a  JSR
             instruction to the  address  given  with  the  library manager
             cookie.)
             This should make it maximally easy to make the calls from most
             languages,  but  DOES,  as  far   as   I  can  see,  have  the
             disadvantage that libraries  cannot  benefit  from  any of the
             memory protection that MiNT, or  compatible system, running on
             a 68030 machine could otherwise provide. (I think they must be
             placed in "global" memory  under  MiNT  - freely accessible by
             all - while if instead a TRAP was used, the libraries could be
             placed in "super"  memory  -  accessible  by  all  but only in
             supervisor mode.)
             Another advantage is however that there  is no risk of clashes
             with other systems as there could be with traps.
             Also: to avoid any possible  problems under pre-emptive multi-
             tasking, the library manager could perhaps  set a flag on each
             function entry and clear it  on  exit.  If the flag is already
             set when someone makes  a  call,  I  guess the library manager
             could just execute a loop, waiting for the flag to be cleared?

      +      A library module would be an ordinary TOS program file (easily
             creatable with any assembler  for instance), though containing
             a non-standard "program". No calls  of MSHRINK or PTERM should
             be made. Instead there could  perhaps  be a small routine that
             merely returns (in D0) the pointer to a function pointer table
             and exits with an RTS instruction. I HOPE it still is possible
             to create modules using C (and not just assembly), though this
             would depend on whether  the ordinary initialization procedure
             - inserted by the compiler before  the "main()" function - can
             be changed. CAN C PROGRAMMERS ANSWER THIS?

     I have done a little bit of  drafting  on the above ideas, but nothing
     finalized. Any further views?

     By the way: I  would  prefer  the  default  name  extension of library
     modules to be something else  than  .DLL.  So  that, on a mixed system
     such as a PC with Gemulator,  it  would  be  as easy to keep different
     kinds of library modules apart as it  is to distinguish ones PRGs from
     ones EXEs. My unimaginative proposal is  .LBR (.LIB is already heavily
     used by many  programming  packages)  -  and  perhaps  FUNCLIBS  for a
     default folder name. Does anyone have better ideas?

     */ Since  proposing  this  standard  last  month  I  have  had further
     thoughts on the subject.  I  think  the  main  problem, as you rightly
     point out, would  be  memory  fragmentation,  i.e.  a  program that is
     opened by the user loads a library file into memory. The user may then
     open another program which uses the  same  library file so the program
     then does not need to load the file  again. If the user now closes the
     first program the library file must  remain  in  memory for use by the
     second program, the memory pool is now divided up into smaller chunks.
     What happens if the user now closes the second program, there needs to
     be some way of  closing  down  the  library  program and releasing the
     memory.

     Your idea of a library manager  program  perhaps could handle all this
     but I am not really in  favour  of  another AUTO program being used. I
     already have four or five AUTO folder  programs  that I have to run on
     boot up and I think most  users  would  prefer not to use these unless
     absolutely necessary. It  increases  the  risk  of  different programs
     being incompatible, the user has  to  install  the program in the AUTO
     folder and sometimes decide in which  order  they have to be run, they
     slow down the boot sequence on  floppy  disk only systems and they use
     up more memory. I believe that  the  programmer should make it as easy
     as possible for the user to use his program with a minimum of fuss.

     For these reasons  I  would  like  to  propose  an alternative method.
     Forget about AUTO folders  and  Cookie  Jars,  when  a program runs it
     allocates a memory block of the  same  size as the library program and
     then loads the library program into it,  the program also sets all the
     absolute addresses using the program's relocation table as normal. Any
     library functions are then called via  the  start address by pushing a
     function parameter (together with any  others required) onto the stack
     and jumping to the start address.  Return  values would be returned in
     register d0 as usual. This method  has the slight disadvantage that if
     two (or more) programs should need to  use the same library program at
     the same time, there will be  no  saving  in memory since each program
     will allocate memory space for it  but  I think the likelihood of this
     happening very often is  quite  small  and  in  any  case, the library
     programs would  probably  not  take  up  too  much  memory  space. The
     advantages would be that  when  a  program  is  closed, its associated
     library program will  also  be  closed  and  the  memory automatically
     freed. It would be simpler for the  programmer since there would be no
     Cookie Jars to install,  check  or  relocate  and  the  use of library
     program variables would be easier to  use  since there will not be two
     calls to the same  program  which  may  corrupt  any variables used by
     another application.

     I think also that  any  library  programs  should  not use any AES/VDI
     functions (unless absolutely necessary)  since the application program
     which wants to use the library functions  may not be using GEM. If any
     GEM calls are used the  documentation  provided with the library files
     should state that GEM must  be  initialised before calling any library
     function as well  as  any  other  parameters  required  by the library
     routines.

     I would be quite happy with using  the .LBR extension and FUNCLIBS for
     the library folder. I would  also  suggest  that  on  a hard disk, the
     FUNCLIBS folder should always be in the  root directory of the C drive
     and on a floppy disk system, it should be in the root directory of the
     disk from which the application program  was run. This would allow the
     application program to  find  the  library  programs  easily. When the
     programmer distributes his program  he  would  also supply any library
     files that are required with the instructions to the end user to place
     these files in the  FUNCLIBS  folder  (if  he  has  one) or create the
     folder if he hasn't.

     I would like to hear from other  members  on this subject to see if it
     is worth continuing with this project.   PDH /*
     ----------------------------------------------------------------------
     To: Mrten Lindstrm
     From: Stephen Bruce

     First,   I   should   apologise   for    my   bad   grammar   re   the
     instructions/assembler directives confusion.  As  previously stated, I
     don't have anyone else to talk  to  about  these  things so it can get
     confusing at times. Thanks  for  putting  me  straight, the extra info
     helped clear things in my head.

     Anyway, the main point of this is  to ask another question. Last month
     you stated that User mode was  preferable for most operations when GEM
     or multi tasking are required. Assuming  the programs were not used in
     these circumstances (e.g.  games,  demos,  etc  do  not  require these
     usually),  would  it  be   feasible   to   write   the  program  using
     user/supervisor mode switches when  required  (running  mainly in user
     mode) until debugging is complete & then remove all switches except an
     initial call to Supervisor mode? The  resulting source code could then
     be assembled & run  in  Supervisor  mode  without  the slowdown caused
     during switching. Is this a  real  possibility  or does the removal of
     these instructions cause problems  in  itself?  Is  it worth bothering
     with at all for what might be  a negligible speed increase? And how do
     I know when I really need Supervisor mode anyway?

     To: Jason J Railton
     From: Stephen Bruce

     You spooked me a bit coming up with the same thoughts as myself re PCs
     & PlayStations. Let's hope there are more of us out there.

     I tried the new polydemo &  it's  cool  but the control method's a bit
     clumsy (though it did work this time). Any chance of making one of the
     mouse buttons a 'walk forward' button  as  I kept running off the edge
     of my mouse pad. Also,  is  there  an  exit  to  be found in the maze?
     Personally I just got lost. All  we  need  now is something to shoot &
     it's look out SubStation. Keep up  the  good work, I'm rather enjoying
     following this 'work in progress'  and  I  wouldn't mind knowing where
     you got your 3D maths info from. Has it been sourced from one book?

     */ The demo was excellent,  perhaps  a  joystick control would be more
     practicable for this type of  program.  Any  chance  of a fairly basic
     article on the methods used to generate the maze graphics.  ICTARI /*
     ----------------------------------------------------------------------
     To: *.*
     From: L.Maule-Cole.

     I have the following books which I will send to anybody who would like
     them for the cost of the postage.
          Introduction to MIDI Programming by Dorfman Young.
          GEM Programmers Reference by Gunther Szczepanowski.
          Compute!'s ST Programmers Guide by Compute! Publications.

     I also have a copy of HiSoft C  Interpreter and a copy of HiSoft Basic
     to give to anybody who  would  like  them,  again  for the cost of the
     postage. If I get no reply in  the  next  copy of ICTARI I shall trash
     them.
     ----------------------------------------------------------------------
     To: Martin Milner
     From: David Preston

     What a relief! I haven't  had  the  cross-machine problems you mention
     (only one machine!), but your  comments  reminded  me of a problem I'd
     almost forgotten about. An  earlier  program  had  had problems with a
     'palette' command and  I'd  got  round  it  by  putting  a  'wait vbl'
     directly after. It had never ocurred to me that *other* stuff might be
     interrupt-driven  (apart  from  the  obvious  sprites,  mouse,  colour
     cycling, music etc etc). I must have  a go at the offending prog, with
     your suggestions borne in mind. Thanks!

     To: Jason Railton

     Your polygon demo  works  a  treat  (1Mb  STe,  TOS  1.62), and *very*
     impressive it is, too.

     To: *.*
     Re: Atari/Ictari

     What a refreshing change! How good it is to read such rational and up-
     beat comments as those  offered  in  Ictari  35  by Jason Railton, Lou
     Maule-Cole and  Stephen  Bruce,  on  the  continued  validity  of  TOS
     computers for home use.

     I can't really add to their comments,  save to offer this scenario for
     your consideration - suppose a salesman knocked on your door and, with
     a sickly smile, started this conversation -

     Salesman - "Good morning, Sir. I have  a proposition for you. For only
     about 1,200, I'll take away your ST  and give you a nice new computer
     with smaller pixels and more screen colours."

     You - "Will it run my existing software?"

     Salesman - "No, but you can  replace  all your software for only about
     300 quid an application,  and  some  of  it  works  almost  as well as
     Protext, Calamus, Papyrus and your other stuff."

     You - "Is it any quicker than my ST?"

     Salesman - "Well, the Pentium  processor  rips  along  at  a hell of a
     pace, but with umpteen  layers  of  OS  slowing  it down you'll hardly
     notice a difference. And now we've fixed  the Pentium so it can add up
     properly, we think we're onto a winner!"

     You - "What about it becoming obsolete  -  I've had the ST for quite a
     while?

     Salesman - "Oh  yes,  sir!  We  include  a  guarantee  of almost total
     obsolesence in a very  short  time.  While  your  ST has been plodding
     along, doing its job without  a  problem,  we've  gone from the entry-
     level PC being a 640k 8086  with  a  20mb winchester, through 1mb 286,
     386SX, 2mb 386DX, 4mb 486SX, 8mb  486DX,  as  far as the current 16mb,
     100hz Pentium with a 1gig  hard  drive.  And I shouldn't think that'll
     see the year out!"

     You have two possible responses - will you

     a. Say "Oh, yes,  that's  for  me.  Please  help  yourself  to my bank
     account!", or

     b. Set the dog/cat/hamster/ravenous bugblatter beast of Traal on him?

     Bill Gates is wealthy enough. He's not getting any of my dosh.

     And furthermore (sorry to labour the point, but I can't resist) - have
     you noticed how many very  new and up-to-date PC-contemptible machines
     are _already_ on the  second-hand  market?  After  the initial selling
     glitz has worn off, your  average  Mr/Mrs/Ms PC-buyer hasn't the first
     inkling what they're buying or how  to  get their money's worth out of
     it, so they turn off the  superhighway  at  the first junction and put
     the PC in the Classifieds.

     The Gates/Big  Blue  combination  (singly  and/or  in  tandem)  aren't
     infallible. Remember MSX  (MicroSoft  eXtended  basic) home computers?
     What an earth-shattering  success  they  were!  IBM  have taken twenty
     years to come up with a  decent  machine  and some would argue not yet
     managed it. (The PS/1 & PS/2 were  going  to be the be-all and end-all
     for personal use!?!)

     There have been other crazes related  to technology that were going to
     sweep the world. The  comparison  between  CB  radio  and the Internet
     springs immediately to mind.  That  was  going  to  allow the world to
     communicate in a free and semi-unregulated way. In Britain at least CB
     is now confined to very  sad  individuals (present company excepted in
     case any of you guys  are  breakers)  (Oops,  I  even know some of the
     lingo!) and a few truckers. There's a very strong chance that the 'Net
     will become the sole preserve of  anoraks and wallies before very long
     (not that it isn't already).  Well,  that's  enough bitter and twisted
     rhetoric from me for now on that subject.

     */ Can we take it then, that you are not in favour of PCs ?  ICTARI /*
     ----------------------------------------------------------------------
     To: Jason Railton
     From: Peter Hibbs

     Having tried your Rasters program which  changes the colour palette on
     every raster line without any interference  from the mouse movement, I
     must say I was very impressed.  This  is  because  I am trying to do a
     similar thing in a machine code program  I am writing without too much
     success so far.

     The part of the program which I  am having problems with is the timing
     of the raster displays. Basically I am changing to a different palette
     when the screen display reaches  raster  line  32 and then changing it
     back when it reaches raster line 170. I am using an MFP timer to count
     the number of raster lines (using  the  Hsync pulse) and generating an
     interrupt which then swaps the  palette  colours.  The problem is that
     when the mouse is moved a lot,  the timer matures on lines 33-35 which
     messes up my display. I think the  problem  is that the timer is reset
     during the Vertical blanking pulse and  the timer start can be delayed
     if the mouse is  moved  because  the  mouse  interrupts  have a higher
     priority. I cannot see any way  of  resetting  the timer at a point in
     time which is always constant,  i.e.  not  affected  by the mouse. One
     possible solution would be to  disable the mouse interrupts altogether
     and somehow read  the  mouse  co-ordinates  and  button  status in the
     Vertical blanking period and feed them  to the mouse routines. I would
     still need output from the keyboard however (but not the joystick).

     Is there an  easy  way  of  reading  the  mouse  co-ordinates from the
     keyboard processor with the interrupts  off  and without affecting the
     keyboard. Any suggestions would be welcome.

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