
     ICTARI USER GROUP             ISSUE 31                   February 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 31
                              ==================

     ASSEMBLY        Saucers game source code.
                     Line drawing routines source code.

     C               SCSI Interface Library for C programmers.

     GFA             GFA Interface dialog utility code & program.

     STOS            Polygon demo program.
                     Stock Controller data files.

     MISC            Pexec function Cook-Book.
                     Current membership list.

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

     ASSEMBLY        Non-modal dialog box code.

     C               Dictionary game source code.

     BASIC           Card shuffling techniques.

     GFA             Text adventure game source code.

     STOS            Starfield screen code.
                     Disk manager program.

     MISC            Ottos Resource Construction Set (ORCS) program.
                     ORCS review.

     ----------------------------------------------------------------------
                                   EDITORIAL
                                   =========
     MEMBERSHIP
     ----------
     Another two members have joined the group this month, welcome to them.
     Also some members addresses have changed this month so it is advisable
     to always use  the  current  membership  list  when  contacting fellow
     members.

     KEYBOARD SHORT CUTS
     -------------------
     In this months  Atari  World,  Jon  Ellis  mentions  the  GEM Standard
     keyboard short cuts that programmers should use for GEM type programs.
     This  information  which  is   available   on  Compulink  (at  address
     gemkeys@ogal.compulink.co.uk) may be useful for  Ictari members who do
     not have access to the Internet. If  any member with access would like
     to download it and send me  a  copy  I  will publish it in next months
     issue. There is a similar list published in the Atari Compendium but I
     don't know whether they are the same.

     SAUCERS GAME
     ------------
     In the ASSEMBLY folder is a Saucers  game  source file. I can't get it
     to work on my machine, perhaps  someone  could  have  a look at it and
     find out why. I have had a  quick  look  and it seems that the problem
     (the  first  problem  anyway)  is  the  stack  pointer  position,  the
     programmer seems to have set the  stack  pointer address to the bottom
     of the hidden screen  which  seems  a  bit  odd.  Maybe  it only works
     properly on a  1M  or  500K  machine.  Anyway,  if  anyone  can get it
     working, send it in to me  for  a  later issue. Of course, whether the
     game is any good is another matter.
     ----------------------------------------------------------------------
                                 CORRESPONDENCE
                                 ==============
     To:   Jason Railton
     From: David Seaman

     Thanks for at least trying  to  help with Stoc Controller. To the best
     of my  knowledge,  the  only   commands  I  used  in it from the Misty
     extension where MOUSE  ON  and  MOUSE  OFF,  which  I  used to try and
     speed  up  certain  routines  by disabling the mouse pointer.  I would
     love to  submit the MISTY extension  for  ICTARI  to put on this disk,
     but unfortunately Top Notch  are  a  bit,  erm,  touchy  about  people
     putting  their  stuff on disks without  asking first.  I know  it's  a
     pain, but if you  delete  all  the  occurrences  of  the commands, the
     program will still work just as well,  only a tiny bit slower.  Or, of
     course, you could get the  Misty   extension   from  a  PD  library...
     I'll try to remember to put what extensions I've used in future, too!

     To:   David Preston

     Regarding the Squasher  extension,  perhaps  my  comments  were  a bit
     unfair since I haven't really  used  it much, as I use my trusty Pack-
     Ice and the Missing  Link  to  decompact  it.  If you find pleasure in
     using the Squasher, then all the best to you!

     STock  Controller...  well,   there    are    basically  two problems.
     I can't remember which  version  I  gave  Peter;  there's the original
     version, and a  version  that  I'd  fixed  to bypass the disk problem,
     which always  used the default  directory.   By  the way, if you don't
     have  a  hard drive this problem wouldn't have occurred anyway so that
     is maybe why you didn't notice it!

     Here's a bit more information on the disk problem:

     The  only  two   commands    which    cause    a   disc  error  (after
     successfully performing the operation) are:

     DIR
     DRIVE$

     Commands which do not cause a disc error include:

     PREVIOUS
     DIR$=
     DIR FIRST$
     OPEN IN #1,

     ETC, ETC.

     This problem has only existed  since  I  got a hard drive. STOS is run
     from drive H,  the  drive  (a  Gasteiner 270 meg) is partitioned  C-P.
     (DRVMAP=65535)    The   extensions   I  have installed are as follows:

     BLITTER
     COMPACT
     COMPILER
     CONTROL
     EXTRA
     GBP
     THE MISSING LINK
     MIDI
     MISTY
     NINJA TRACKER
     STOS TRACKER 14KHZ

     The other problem is related  to   the  sort code.  Although I'd spent
     absolutely AGES getting it  to work  perfectly  (it was on an issue of
     ICTARI  even....  oops!),  it  seems not  to work properly still and I
     can't  find  what's  wrong with  it.   I've  also sent some sample STC
     files  (which  are  hopefully  on  this  disk)  with the corresponding
     STOCK.DAT  file.   Try printing  a  stock  take   or  price  list  and
     you  can  see   what   I   mean.  HELP!!!!!!!!    */ See STOS\STOC_CON
     folder /*

     From: David Seaman (for the last time this issue, I promise!)
     To: Everyone

     Also on this disk (or  soon,   anyway)  is  Disk Manager 2.0, which is
     hopefully both useful and  a  good  example  of structured code.  It's
     certainly the  tidiest,  most  structured code I've ever written, and,
     best  of  all,  gets  round  the  disc  problem mentioned earlier (has
     anyone else had problems getting STOS  to  behave on a  hard  drive?!)
     by  using  the  file  selector.   I  hopefully  can use the same  sort
     of  technique in STC,  but  I'd  rather  not  have  to resort to  such
     drastic measures... (I still hope to avoid doing a nearly complete re-
     write...)  */ See next month /*

     Finally, while  I'm  on  the   subject   of   STOS extensions (well, I
     wasn't  actually,   but   still..),   could   anyone   do  a deflation
     routine for ZIPed files?   I   know   it  would be mega-slow in BASIC,
     but surely it's a practical possibility?  If  you do it, please let me
     know!
     ----------------------------------------------------------------------
     To: All
     From: Jim MacLeod

     By way of intro, this  being  my  first  letter,  I am a self!! taught
     assembly programmer crashing merrily about the system but not, as yet,
     producing anything of note.

     I have tried writing an extremely  basic non-modal dialog, ie only one
     window on screen, and include a working version + listing. Although in
     M/C code it uses macros and  I  have  put notes before each section so
     that hopefully anyone should be able to make sense of it.  */ See next
     month. /*

     If anyone wants to write/ring be glad to hear from you.

     To: Marten      Form_keybd,tree,ed_obj,key,ed_obj

     In your excellent &  informative  articles,  for  which thank you, you
     advised that the second ed_obj  should  be  set  to '1'. After various
     experiments I believe I now see  why.  If 'key' is Up/Down arrow keys,
     Tab/shift+Tab or  the  Return  key,  int_out(2)  returns  the relative

     object number.  However  if  'key'  is  alpha-numeric  then int_out(2)
     returns whatever value is placed in the second ed_obj.
     So, call form_keybd, compare ed_obj  and  int_out(2).  As long as they
     are  the   same   then   go   straight   to   objc_edit   function   2
     (validate/update). Obviously if different,  user  is changing ed_obj's
     or exiting the dialog so handle accordingly.

     To: David Preston    Object redraws

     Calling objc_offset for obj_n  returns  the  X/Y  co-ordinates of that
     object which is actually the  offset  relative  to the screen. In fact
     the X/Y of obj_0 will  always  be  screen relative, while its children
     all have offsets relative to it. All the AES probably does is add them
     to those of the object you want to give the result.

     Each object data is 24 bytes long  held sequentially in memory. If you
     get the tree address, the X/Y/W/H are held in 2-byte blocks at offsets
     of 16,  (for  X),  18  (for  Y),  20(W)  &  22(H),  ie  if  you called
     objc_offset for obj_0 the returned values  should be the same as those
     at tree+16 & 18.

     To find the W/H for  any  object  add  24*obj_number to the tree start
     address and then read the data  at  offsets  20  &  22. As you see, it
     could be just as quick to read the X/Y of obj_0, read X/Y/W/H of obj_n
     and add the X's & Y's to get the result.

     To: Owen Rogers    Reading GFA editable objects

     Somewhere I have some GFA v2 routines which I will try and dig out for
     you. Meantime here are a couple but  I can't guarantee that they won't
     bring things to a halt. Basically  you  need  the start address of the
     tree, a manual should show you  how,  which  is shown as T% below. The
     object number is N%.

     Tv$=""                         Space for the returned string
     @G_text(T%,N%,*Tv$)            Tree start addr, editable object number

     Procedure G_text(T_%,N_%,Tx%)
         Local X_$
         X_$=Space$(80)
         T_%=Lpeek(Lpeek(T_%+24*N_%+12))        Get editable object address
         Tx_len%=Dpeek(Lpeek(T_%+24*N_%+12)+24) Get text length
         Bmove T_%,Varptr(X_$),Tx_len%          Read string into variable
         *Tx%=Left$(X_$,Instr(X_$,Chr$(0))-1    Get string length
     Return

     If you want to try  something  safer  first,  try changing an object's
     status from Normal (0) to Selected (1) and back.

     Procedure G_state(T%,N%,X%)
         *X%=Dpeek(T%+24*N%+10)     Object status flags are offset by 10
     Return                         X% holds current status of object N%

     Procedure S_state(T%,N%,X%)
         Dpoke(T%+24*N%+10),X%
     Return                         X% is the status to set eg 0 or 1

     To: Jonathan      Double linked lists

     I've got a book with single &  double  linked lists in it, but they're
     in assembler. If they could be of  help  ring/write & I'll be happy to
     send/fax them to you

     To: John Oakes     68000 programming

     If you're totally new to 68K I found quite a good book is "First Steps
     in 68000 Assembly  Language"  by  Robert  Erskine,  Glentop  Press Ltd
     Standfast House, Bath Place, Barnet, Herts  EN5 5XE. I've also got odd
     mag articles which may be of interest, glad to help.

     To: Peter         TSR's

     Again somewhere I had a TSR routine which used one of the spare Traps.
     It set itself up on boot-up and then ran when the Trap was called from
     within a program. I had an idea  though that TSR's were supposed to be
     completely self-contained, ie no M_alloc  calls  etc,  so I don't know
     how that would affect loading a file?

     */ See letter from Jason Railton below.  PDH /*
     ----------------------------------------------------------------------
     To: All
     From: Mark Foot

     Does anybody have any useful  information  on  using LISP/XLISP on the
     Atari. I have the XLISP v2.1 disk  from FloppyShop but would like more
     information.
     ----------------------------------------------------------------------
     To: ICTARI / Jonathan Leckie
     From: David Preston

     File conversion utilities

     Having had a  quick  look  through  my  Atari  Worlds  (all  bar No.1,
     regrettably), I couldn't  find  the  program  Jonathan  referred to in
     Ictari 30. However there  was  a  program  on  ST Format coverdisk #62
     called TUC which might (probably with some work) do some or all of the
     the jobs you wanted. I've included it (\TUC102), though whether or not
     you put it on the Ictari disk  is  up to you. Another possibility as I
     understand it is that Protext  can  be  programmed  to do all sorts of
     clever things (see Mark Baines' article  in  Atari World #8), but only
     having the coverdisk  version  4.3  of  Protext  (in  truth  90% of my
     software is from coverdisks! sad but true...)  so I'm no expert on the
     finer points of its use.

     */ I'll try and include the TUC program  on  a later disk as it may be
     of interest to some programmers,  if  Jonathan  or anyone else needs a
     copy urgently, please send a disk and I will return a copy. ICTARI /*

     To: Owen Rogers

     I think the problem  with  your  editable  strings  is that the second
     parameter to form_do should be  the  index  of the first editable text
     object in the form ie. ex%=FORM_DO(tree%,comline%) if that's the first
     editable item.

     To: Jason Railton

     Seapest
     Nice game, nice code.  However,  the  executable  (PRG)  locked up and
     didn't seem to accept any  mouse  input.  The  BAS  file loaded, ran &
     compiled fine. It's not terribly  important,  but I thought you should
     know. I have a 1meg STe if that has any bearing on the problem.
     ----------------------------------------------------------------------
     To: Peter Hibbs
     From: Jason J Railton

     Re: TSR programs
     Last month's TSR listing was fairly straightforward, and you shouldn't
     have any problems basing your  code  on  that.   However, you could do
     things a bit neater so that if you make a few mistakes you don't bring
     the whole system down.

     1.   Firstly, if you  intend  to  intercept  (i.e.  steal) an existing
     vector, it's a good idea to make  the first command of your function a
     jump, to skip over the next few  bytes.   Next  you put  a copy of the
     original vector, then a key word (such  as the name of your program in
     eight characters), as follows:

     new_routine:
         BRA   do_stuff
     old_vec:
         DS.L  1
     my_id:
         DC.B  "MY_PROG "
         EVEN
     do_stuff:
         Your routine...

     Then, your program can take the value of the sum:

         (my_id - new_routine)

     and add the  current  value  of  the  vector  you  intend to redirect.
     Compare the eight bytes starting at  this address with the eight bytes
     held at 'my_id'.  Thus  your  program  can  tell  if it's already been
     installed. (Don't forget the EVEN command,  just in case your key word
     has an odd number of letters).

     I don't know if you can get  one  TSR  routine to wipe out another and
     free up its memory, but  if  you  store  the  original contents of the
     vector at 'old_vec', just before the  key word, then your installation
     program can not only  identify  previously  installed routines, but it
     can kill them off by picking up the original vector, and re-installing
     it.  This  is  useful  in  development,  so  you  don't  have  to keep
     resetting the machine when  you  want  to  try  a  new version of your
     program.

     Also, if you do this at the start of all your routines (rather than at
     the end), the data  is  always  in  the  same  place,  relative to the
     modified vector, so your programs can identify each other.

     2.  Another safety device is to give your routine its own stack space.
     Do this by adding some extra  space  to  the amount of memory you tell
     the system to preserve around your TSR program.  Calculate the address
     of the end of this free  space,  and  use  that as your stack pointer.
     Save this address in four bytes reserved at the end of your program.

     When your routine is called, it  should  save the current registers to
     the normal stack, then copy  the  value  of  the stack pointer to four
     bytes reserved at the end of your  program.  Then, load your new stack
     pointer and carry on.  When you  come  to exit your program, you don't
     need to tidy up the stack.  You can save the new stack pointer, or you
     can just lose it and start from  the  top again next time your program
     is called (safest). Then, load  the  stack  pointer value you saved on
     entry, and restore the registers from there.

     The memory preserved  around  your  program  consists  of  the program
     itself, 256 bytes preceding  it,  called  the  basepage, plus any data
     space after your program that you  want  to keep free for your program
     to use.  If the TSR program needs  a  lot of spare RAM, you can't rely
     on being able to request it  from  the system when activated.  If your
     routine is triggered whilst another  program  is running, that program
     may not have freed the RAM it doesn't  need, so all the memory will be
     allocated to it with  none  available  for  the  system to allocate on
     demand.

     3.  If your installation program is  fairly  large, you can always put
     your new routine first in the  listing,  with  a jump to the installer
     just beforehand (below).   Then,  you  need  only  tell  the system to
     preserve the memory up to the  end  of  the TSR routine, and its data,
     and cut off the installer code.  After all, you don't need it once the
     TSR code is installed.

     start:
         BRA    installer
     new_routine:
         This is your new routine, followed by
         its variable storage area.
     cut_off:

     installer:
         This is the procedure that installs
         'new_routine', and is programmed to
         exit, preserving the amount of
         memory between 'start' and 'cut_off',
         plus 256 bytes plus data space.

     If you reserve  extra  memory  for  workspace,  some  of the installer
     routine could end up as  part  of  this  workspace.  Don't worry about
     over-writing it once it's done its job.

     4.  If you're going to  have  an  installation message, put a keypress
     pause after displaying it, so at least it can be read.

     test_space_bar:
         CMP.B  #$39,$fffffc02.w
         BNE    test_space_bar

     ...is an old favourite, which  waits  for  someone  to press the SPACE
     bar. It's also very  useful  if  you're  playing  around with vectors,
     since it enquires of the keyboard  chip  directly - it doesn't rely on
     system keyboard interrupts.  Switch  all  the  interrupts  off, and it
     still works.

     By the way,

     "COMPUTE!'s Technical Reference Guide
                    ATARI ST
                  VOLUME THREE
                      TOS
                by Sheldon Leemon"

      ISBN 0-87455-149-8
     $24.95, or 22.95 from Foyle's, Charing  Cross  road, London - where I
     got my copy -

     ...is a brilliant book on  this  sort  of  thing.   I mean, I've never
     written a TSR routine myself, but  look  at all the stuff I've managed
     to come up with...  And hunting  round  Foyle's  is a great day out in
     itself...

     */ Thanks for  the  extra  info  Jason.  Actually  I  seem to remember
     reading somewhere that it is  not  possible  to  use any GEM/VDI calls
     (which I need to do) from  an  Auto  folder program because GEM hasn't
     been initialised at that point in the boot up sequence. If this is the
     case I will  probably  have  to  install  the  program  as  a standard
     accessory first and then hook  into  the  keyboard  vector so that the
     user can call up my program with  a  key combination (even if the main
     program does not allow access to the menu bar) which is what ImageCopy
     does. Any further information  on  this  subject  from anyone would be
     very interesting.

     I have got the Compute series of  books, the problem with them is that
     there is so much information  in  them  that  I  tend to just read the
     chapters that I am interested  in,  I  will  have to have another look
     through them. I actually visited Foyles  myself  a couple of weeks ago
     and purchased a  book  called  'Practical  Algorithms for Programmers'
     which looks very interesting  although  it  is  not Atari specific, in
     fact the number of Atari  books  available  there, seems to be getting
     less each year.  PDH /*
     ----------------------------------------------------------------------
     To: ICTARI.
     From: C Singleton

     Can anyone tell me how to  send  a  FORM  FEED code to a printer using
     Lattice C5.6.  All I seem to get  for  my  effort is a printing of the
     control code 'FF'. Thanking someone in anticipation of a reply.
     ----------------------------------------------------------------------
     To: All
     From: Peter Hibbs

     Are you good at drawing graphics ?  I  am  in the process of writing a
     Dungeon Master type game (in fact  it  is  almost identical to DM) and
     while the basic layout of the dungeon  will  be the same, I would like
     to add some different monsters to the game. If anyone is interested in
     designing some new monsters, please let  me  know (or telephone) and I
     will send you a disk with  some  example images (in Degas .PC1 format)
     and information on what is needed. There  is no fee payable I'm afraid
     although you would get a free copy of  the game, of course, when it is
     finished.

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