
     ICTARI USER GROUP             ISSUE 29                   December 1995

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

                     *   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 29
                              ==================

     ASSEMBLY        Jaguar Pad interface routine.
                     SpeedoGDOS functions MACRO reference guide.

     C               Lasso function code.
                     Incremental circle generator code.
                     Application skeleton code.

     GFA             GFA Patch program.
                     Slider puzzle game code.
                     USA map game code.

     STOS            Stock controller program.
                     ACC loader program.
                     STOS Extensions survey.
                     STOS fix program for the TT.

     MISC            Mrten Lindstrm, GEM Guide. Part 5.
                     ZLIB and Deflate compressed data format information.
                     Ralph Lovesy interview.
                     GEM Bitmap font file format.
                     MODEM programming and MODEM comparison guide.
                     Atari Compendium correction list.
                     XAcc GEM communication protocol specification.
                     Current membership list.

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

     ASSEMBLY

     C               Disk catalogue program source code.

     GFA             Mrten Lindstrm: An introduction to GFA programming.

     BASIC           Lottery program.

     STOS            Seapest game source code.
                     Polygon demo program.

     MISC            Cookie Jar list.
     ----------------------------------------------------------------------
                                   EDITORIAL
                                   =========
     MEMBERSHIP
     ----------
     We have had four more members join  this  month with a couple of other
     enquiries, welcome to them. Just a  reminder  to new members, we would
     prefer text files sent in Protext format,  if possible, if that is not
     possible then plain ASCII is fine. Also,  when sending a disk for next
     months issue, please include a  letter for the correspondence section.
     Ask a question, answer a question or just  say what you want to see in
     ICTARI, and we still need more articles for next year.

     SpeedoGDOS ARTICLE
     ------------------
     Unfortunately Mark Baker  has  not  had  enough  time  to complete the
     SpeedoGDOS article for this  months  issue  so  it  will appear in the
     January issue (hopefully).

     ----------------------------------------------------------------------
                                 CORRESPONDENCE
                                 ==============
     To: John Watson
     From: Michael Harrop

     John, you say you have only the  PD  version of GFA BASIC, well I have
     both V2 and V3. I don't use V2  now  so if you would like the original
     manual for V2 let me know, my address is in the MEMBERS.TXT file or if
     you    have    INTERNET    access    you    can    E-MAIL    me    at:
     100025.2357@compuserve.com
     ----------------------------------------------------------------------
     To: ICTARI
     From: Lee Russell

     Subject : Dave Richards' Database Program

     I was encouraged to see Dave  Richards' database program on the latest
     ICTARI disk. It  proved  to  me  that  programmers  of  all levels are
     members. I was starting to get the  impression that only people with a
     full knowledge of GEM, GDOS  in  all  its  disguises, C, Assembler and
     advanced cryptography were in the group !

     Dave's letter has prompted me to  submit  my code for a disk catalogue
     program I wrote in '92. In  many  ways  the  code is not an example of
     good GEM programming practice,  but  it  works.  Hopefully it may help
     other budding C programmers to make a start with GEM.

     */ See next month for the source code. ICTARI /*
     ----------------------------------------------------------------------
     To: Mrten Lindstrm
     From: Thomas Nilsen

     ZIP deflation/inflation.
     ------------------------
     I have ftp'ed the ZIP-docs  from ftp.uu.net/pub/archive/zip/doc as you
     wanted in last issue. Hopefully there  is space enough to include them
     on ICTARI issue 29. The  files  are  named DEFLT1-1.DOC & ZLIB3_1.DOC.
     Enjoy em!  */ Thanks for the info. See /MISC/DEFLATE/ folder. ICTARI/*

     To: Ictari

     Well, the ICTARI bulletin is now on-line!  It did take a bit more than
     a week to complete the  task,  but  isn't  that normal? Not all things
     turn out the way they   are   planned...   Anyway,  lets  hope some of
     the Norwegian programmers will join Ictari as well.

     I will hereafter make the ICTARI  issues  available on my BBS together
     with one of the more interesting items  from the issue, with a request
     to become a member of ICTARI to get the complete issue every month.

     What about taking it even further.  As   my  BBS is connected into the
     two major ATARI networks, NeST and  ATARInet,  I  could  post parts of
     each  issue  in  the   programming   conferences   together  with  the
     information on registration. There are  a   lot  of  users  around  in
     the programming conferences.

     Now for my programming-question  last  month.  I  guess I didn't quite
     explain myself well enough.  What  I  meant   with  using  an RSC from
     within a window was basically  how   to   display  an  RSC-TREE (ie. a
     FORM with boxes, texts,  etc)   within   a   window,  so  that  it  is
     capable  of multitasking (at least  in   theory).   But  I  would,  of
     course, also be  interested  in  displaying  a  menu  inside a window,
     though  I  believe  this  is  achieved  by  setting  a  bit   in   the
     windowtype, more or less. So if  anyone  has  ever done this before, I
     would very much like to know!

     To: Ictari

     DSP Modem.
     ----------
     When ATARI first released the  Falcon   one  of its selling points was
     that it would be  capable   of   emulating   a   highspeed modem using
     software. Well, during the three years  the   Falcon  has  been on the
     market, no  such  software  has  been  developed,   at   least   to my
     knowledge. I have heard various  rumours  that HiSoft did a  prototype
     of a DSP Modem, but found  it  too  expensive  to complete it.  I have
     also heard other rumours about single  souls trying to make this  kind
     of software, but it's all  rumours.  Anyway,   now  I'm  a  bit  tired
     of  all  these  rumours and therefore  I am thinking of developing the
     software myself. But this is probably going to take more than one mans
     time to finish off, so I am looking for other Falcon coders to  assist
     me on this project.  I  will  also  need  information on  the  various
     Modem  standards. So if  anyone  wants  to  join,  or have information
     about this (or know how  to  get  such  information) I would very much
     like to hear from you.

     To: John E Nicholls.

     Regarding your plea for help in the  last  issue,  I would suggest you
     try out STOS or GFA Basic  v3.  I  myself  started programming in STOS
     and I learned a lot  from  it.   STOS   is  best  used for programming
     games and the like, and  if  you  are  to  develop   a  shell for text
     adventures I guess STOS is more than  adequate. But,  if  you  are  to
     go for more serious  programming  GFA  Basic  v3  is the  only  usable
     choice when  it  comes  to  Basic  programming.  C  is  also  a   good
     programming language, but  with  no  prior   programming  knowledge  I
     suggest  you  learn  the  basics   of  programming  first.  C  can  be
     quite  difficult  for  a  newcomer  to understand, and learn.

     I believe ST Format is selling the complete GFA Basic v3 package, with
     compiler and manual. GFA Basic is  quite  easy  to  get the hang of as
     soon as  one  learns  how  it's  structured,  and  I  would definitely
     recommend it as a first time programming language.

     */ Feel free to  distribute  some  of  the  ICTARI articles around the
     networks, the more publicity we can get the better. Good luck with the
     DSP/Modem project, can anyone help.  ICTARI /*
     ----------------------------------------------------------------------
     To: *.*
     From: Adrian Lovatt

     Has anyone got  a  list  of  the  VDI  function  numbers  available to
     SpeedoGDOS, I would  like  to  write  a  subroutine  library in HiSoft
     BASIC2 but don't have the calling conventions.

     */ The book Modern Atari  System  Software  from  HiSoft lists all the
     SpeedoGDOS functions (Chapter 8) in C,  Assembler and BASIC format but
     with very little  information  on  how  to  use  them.  A  list of the
     Assembler calls is given  in  the  ASSEMBLY\BEZMACRO folder this month
     which may help (if anyone  can  provide more detailed information with
     some practical examples on how to  use  the functions we would be very
     interested). If you haven't got access  to this book we could probably
     send you a photocopy of the relevant  pages (let us know). Also Mrten
     Lindstrms GEMGUIDE article this month  covers  some of the SpeedoGDOS
     calls.  ICTARI /*
     ----------------------------------------------------------------------
     From: Jason J Railton
     To:   Everyone

     *** ME, FALCON AND MONOCHROME ***

     Well, you may think I'm new to ICTARI, but I'm not.  Some of you might
     remember me as 'Falcon' from the first few issues - I sent in loads of
     STOS stuff, although I don't know if my digital rotation demo ever got
     distributed.  No?  Don't remember me?  Oh well...

     If anyone out there remembers me from the Monochrome bulletin board at
     City University, or from Loughborough,  get  in  touch.  For those who
     haven't heard of Monochrome, it's  on   telnet 138.40.17.1  - I think.
     I'm not sure  because  I  haven't  had  access  for  months  now.  I'd
     appreciate it if someone could pass on some messages from me to people
     I knew (if they're still on it).

     Well, I've left  University  and  got  a  job,  so  now  I'm living in
     Gosport, the other side of  Portsmouth  harbour to Portsmouth.  Anyone
     nearby?

     I've sent in two programs  to  ICTARI;  one  STOS game (SeaPest) and a
     graphics demo (Polydemo).  I hope Peter can fit them on the disk...

     Go on Pete, cram them in there...
     Plenty of room...

     Please put a document displayer on each disk, it would be useful.

     Cheery-bye for now.  Have fun.

     */ Sorry, there wasn't enough room,  I  do compile these disks a month
     or two in advance. I'll include them  on  the next couple of issues. I
     have considered a document  displayer  for  the  disk  in the past but
     decided against it because it would  take  up valuable room each month
     and I think everyone will already  have their own favourite editor, WP
     program, etc which they would prefer to use anyway.  ICTARI /*
     ----------------------------------------------------------------------
     To: John E Nicholls
     From: Pete Bailey

     I can't really improve much  upon  Peter  Hibbs'  comments in the last
     issue, but would like to add a thought or two of my own. It's tempting
     to say that C isn't a suitable  first language for a beginner, but I'm
     not sure that it's necessarily true.  It's one of those languages that
     you can  either  cope  with  or  you  can't  -  I  know  at  least two
     professional programmers (workmates, in  fact)  who, though thoroughly
     competent in various Basics, simple  cannot  get their heads around C.
     In fact I suspect that previous  experience  in Basic may even make it
     harder to learn C! What I'm trying  to  say here is don't be afraid to
     give it a go - but don't  expect  it  to  be easy. I think it would be
     reckless to blow 70+ quid on  Lattice, though; more sensible, I think,
     to try Sozobon first and see how you get on with it. It costs nothing,
     and works well - the  only  bugbear  is  setting  it up and getting to
     grips with how to make it do  something  useful. If you want to pursue
     this, then I'll be very happy to help on that front.

     Of the other languages you mention, the  next best choice would be GFA
     Basic in my view. I'm  not  a  regular  Basic  user myself, but I have
     looked at most of them  at  least  once  and  GFA was the flavour that
     impressed me the most. Very capable,  and very fast, even when running
     interpreted code (I  think  there's  a  separate  compiler available -
     correct me if I'm wrong someone). In C's defence I would just add that
     the language is powerful,  flexible,  expressive  and the next fastest
     thing to assembler; but  you  are  perfectly  correct in your comments
     regarding  portability.  Although  it   is,  in  principle,  perfectly
     portable, the differences in  header  files  and libraries between the
     various versions makes porting software for  real quite a nightmare. I
     recently switched from Sozobon v1.something  to  the latest Sozobonx -
     even between different versions of  ostensibly  the same compiler, the
     changeover gave me headaches (literally)  for  a  week. Oh, and as for
     Hisoft C - it's wet, misguided,  ill-conceived and I wouldn't touch it
     with  a  barge-pole  of  any   length  whatsoever.  Just  my  personal
     prejudice, you understand!

     To: Dave Richards

     The answer to your prayers,  Dave,  is... Malloc. Where you've defined
     struct database { ...  }  address[MAX],  define  struct database {...}
     *address instead. This gives you a pointer to a structure, but doesn't
     reserve any storage for it or  carry  any implications as to its size.
     Now before you can use it, you  need  to reserve some storage and then
     make your pointer point at  it.  There  are  C library functions to do
     this, but my personal preference is  to call Gemdos functions directly
     (I'm not interested in  portability).  One  way  to  do  this might be
     something like:-

        unsigned long maxmemory;
        maxmemory = Malloc(-1L);  address = (char *)Malloc(maxmemory);

     The first call to Malloc passes a  longword of -1, which causes Gemdos
     to return the size in bytes  of  the available free memory. The second
     call then uses this value to hog the lot, and sets address to point at
     the start of it.  I'm  not  sure  whether  Gemdos  ever returns an odd
     address, but I usually like to check  and  add  1  if it is just to be
     safe. Purists might also object that  this kind of memory-hogging is a
     bad idea (well it is, I can't  deny  it); in that case, just decide on
     some sensible maximum size and Malloc that much rather than all of it.
     Remember also that, if you pretty the program up with a Gem interface,
     then Gem will need  some  breathing  space.  As  far as accessing your
     database in memory goes, you shouldn't need to change much (I'm sorry,
     I don't have time  right  now  to  go  through  your  code in detail).
     Remember that, when you define  an  array  in C (eg address[MAX]), you
     don't *have* to treat it as an  array  all of the time. The array name
     (address) is in fact evaluated as  a  pointer, and the brackets act as
     an operator which add the bracketed  value  to the pointer to form the
     address at which  the  array  contents  will  be  stored or retrieved.
     Consequently, while the normal  (sane)  method  of  accessing an array
     would be address[n], it is in fact perfectly legal to write n[address]
     which evaluates to exactly the same  thing.  But don't go showing such
     code to anyone  else  unless  you  enjoy  being  laughed  at.  (A less
     laughable variation would be *(address+n); think about it - it's still
     the same thing!) Anyway, the upshot  of  all this is that, even though
     you've changed your original  array  into  a  pointer which isn't even
     initialised until run-time, you can still reference your database with
     expressions like address[n].name and so on  - the pointer acts just as
     though it were an  array  name,  because  essentially they're the same
     thing. Irrespective of how much memory  you  grab, by the way, you can
     calculate the maximum number of  database  entries (ie array elements)
     by:  maxmemory/sizeof(struct  database).  As   regards  the  graphical
     interface - go for it. If  you  have  a  resource editor, use that and
     learn about the AES; if  not,  hand-roll  your own graphical interface
     using VDI calls. It's more tedious,  but  it's  a good way of learning
     about the VDI.
     ----------------------------------------------------------------------
     To: *.*
     From: Mrten Lindstrm

     Inspired by the general GDOS  interest  in  Ictari recently, I at long
     last made the decision to part with the money for NVDI 3, and actually
     received it before I got the FontGDOS that I ordered some weeks before
     it. Experimenting with both NVDI 3(.02)  and  FontGDOS has taught me a
     number of  things  about  beziers  and  outline  fonts  that  I wasn't
     previously aware of, and I have tried  to include them in chapter 5 of
     my GEM Guide. (I only hope  that  our  wonderful editor has managed to
     get it on this disk, since I sent it in a bit late, I think).

     One further thing I have learned  is  that, although in the beginning,
     all GDOS  implementations  -  including  NVDI  -  could  use  the same
     drivers, this seems to no longer  be  true,  and each GDOS now must be
     supplied with its own drivers.

     To: *.*

     Last month I said that a slider  is a touchexit box within an ordinary
     box - the slider bar. I  hope  that everybody, who read this, realized
     that the bar too would normally  be  made a touchexit object, in order
     to facilitate "paging" when the user clicks on the bar above/below the
     slider. Since FORM_DO only returns the exit object number, and not the
     mouse position, you would have to make a call of GRAF_MKSTATE in order
     to establish whether the bar was clicked above or below the slider (or
     else write your own FORM_DO).

     To: *.*

     Does anyone have Gemini,  the  shareware  Desktop  replacement, and is
     willing to share  the  info  on  an  "AV  protocol" (for communication
     between main program and accessories) that  I  have heard should be in
     its documentation?

     To: Pete Bailey

     Hello and thank you for the praise. I  have so far not done any real C
     programming myself, since I've  been  too  parsimonious  to  pay for a
     commercial C and too cowardly to try  a  PD C. But I am considering to
     join the Sozobon gang.

     To: John E Nicholls

     What programming language to choose
     -----------------------------------
     You seem already to have  found  your  main  choice  to be between GFA
     Basic 3 and a some C package  (of  which Pure C and Lattice C probably
     are the top two, at least judging  from  their prices). And as long as
     your object isn't pure "games  programming"  I think that you probably
     have made the right selections thus far.

     "Games  programming"  for  this  purpose  means  any  machine-specific
     programming where SMOOTH AND FAST  SCREEN  ACTION is the all-important
     aim, including e.g. flight simulators,  animator programs etc. But the
     strategy/adventure type games that you (and  I) are interested in, are
     actually on the borderline  to  "serious"  programs,  I  think, in the
     sense that they wouldn't lose much  from making COMPATIBILITY the main
     objective instead. Though most  commercial  offerings have shunned the
     compatibility of GEM,  ostensibly  in  favour  of  smooth animation, I
     cannot see what a game such  as  Civilization  would have lost if made
     100% GEM. (Certainly nothing in its humble animations).

     STOS is a language squarely for  games programming, i.e. if compatibi-
     lity is of no concern. In  addition, although equipped with an arsenal
     of truly impressive functions and utilities for swiftly putting a game
     together, at its heart and  foundation  resides a horridly ancient and
     unfriendly Basic. Just  looking  at  its  LINE  NUMBERS  gives  me the
     creeps.

     For "serious" (i.e.  compatible)  programming  some  modern high-level
     language is easiest to use, and  there ARE other alternatives than GFA
     Basic and C, including the  Hisoft  Basic  as  well  as Pascal (e.g. I
     understand Pure Pascal to  be  a  very powerful Pascal implementation)
     and Modula 2. Without really knowing that much about them, I have how-
     ever got the impression that they all fall somewhat between the stools
     of GFA Basic and C. Neither being as  instant to use as GFA Basic, nor
     as completely dominating  the  serious  programming  world  as  C. (Of
     course, the situation could be different  for those somehow given easy
     access to /experience with a certain language - e.g. at work).

     Assembly programming, finally, can be  used  for  ANYTHING. It is what
     HAS to be used whenever  optimal  speed  and/or compactness is needed,
     since no compiler of any high-level  language is nearly as intelligent
     as an assembly programmer. (Converting  from compiled code to assembly
     can often increase speed  several  times).  For top-of-the-range games
     programming there are thus  no  alternatives.  Assembly programming IS
     slightly more difficult than  high-level  programming though (in spite
     of the Motorola processor  being  more  programmer-friendly than some,
     and assembler macros giving a  high-level  "touch" to assembly). Above
     all,  it  offers   more   opportunities   for   bugs  than  high-level
     programming. And, for general purposes,  assembly programming could be
     a complement rather than an  alternative; any good high-level language
     should allow you to include assembled code in your program, to replace
     those high-level routines that you have found to execute too slowly.

     (ST users who need an assembler, try to get hold of the June 93 cover-
     disk of Atari User, containing the complete Devpac 2. Users of Falcons
     and TTs  must  pay  for  Devpac 3  which,  apart  from  supporting all
     Motorola processors, does also provide  a  better shell and editor but
     otherwise doesn't add that much to Devpac 2).

                               ---------------

     Since I have some experience  of  GFA  Basic  3 and also (without real
     experience) know a little about C,  I  will  try to summarize the pros
     and cons of each.

     GFA Basic 3:
      +      Interpreted language (with  compiler  too).  Meaning much less
             time between error correction  and  seeing  the  effect of the
             correction.
      +      Intelligent editor,  automatically  changing  letter  case  to
             distinguish recognized  GFA  Basic  key  words  from  variable
             names, correcting some syntax errors (and letting cursor point
             to others) and - not least  - adjusting indentation to reflect
             loops, IF-blocks and function/procedure definitions, instantly
             revealing missing ENDIF's etc. (On  the  down side, the editor
             is non-GEM and single-document).
      -      It is a Basic, meaning a non-standard language.
      -      A few of  the  system  functions  are  built  in  to GFA Basic
             commands, complicating references  to  TOS documentation. (See
             the start of my GEM Guide -  in  Ictari 25 - for an attempt to
             relate GFA graphics commands to VDI functions).
      -      Variables do NOT have  to  be  declared  before use, meaning a
             natural opportunity for error checking  is missed. (Though the
             editor can be made to watch for new variable names).
      -      Names cannot be defined for constants (only for variables).

     GFA Basic programs are all-in-one,  and  there are no separate library
     files, which for small programs is  adding to the instantaneousness of
     GFA Basic (I would imagine  those  without  a  hard disk in particular
     appreciating this). There are  no  paths  or  environment variables to
     worry about, just run the GFA Basic interpreter and start programming.
     But for a larger project it could perhaps become a bit unwieldy not to
     be able to split it into several files. (On the other hand programs of
     monumental proportions - Papyrus was  mentioned  here in Ictari - have
     been produced with GFA Basic).

     C (and C++):
      +      The completely dominating language  in the serious programming
             world (on all platforms) assuring a  wealth of source code and
             general support from fellow programmers. (Without really being
             a C programmer myself, I still have found it necessary to pick
             up some C knowledge just  in  order  to read source listings -
             translating to assembler or GFA Basic).
      +      Pointers not only to  data  but  to sub-routines (functions) -
             effectively making  it  possible  to  pass  a  function  as  a
             parameter to another function.
      +      "Structures" (similar to arrays but with elements of MORE THAN
             ONE TYPE, referenced by names instead of by indexes).
     (In GFA Basic this has  to  be  achieved  with arrays, accessing "non-
     standard elements" via pointer operations: {V:x(...)}).
      -      Not possible to run in  interpreted  mode before compiling. (I
             understand the Hisoft C interpreter to  be  more of a tool for
             learning than for serious programming).
      -      No true string variables  (but  strings  can be implemented as
             byte-arrays).

     The syntax of C is very compact, partly thanks to heavy use of braces,
     brackets, parentheses, asterisks  and  other  characters and character
     combinations  where  other  programming  languages  use  keywords  and
     functions with NAMES in English.  And  partly thanks to such legendary
     combinations as  x++  which if used  in an expression will FIRST cause
     x to be read and used  in  the  expression  and THEN ALSO increased by
     one. Or to x+=2 which is equivalent to x=x+2,  x-=y equivalent to x=x-
     y etc. This compact syntax can be regarded as an advantage but also as
     a disadvantage, making  C  more  difficult  to  read,  especially to a
     beginner. (Mean people have called C a Write-Only Language).

     C also has a  way  of  allowing  things  otherwise  only possible with
     assembly. In fact I get the impression that  the main idea of C was to
     make it "as low-level as any high-level language could be".
     Example: C allows access of arrays outside their declared range.

     Of the above pluses and minuses  some are more significant than others
     of course. In short:

     The strong-point of  GFA  Basic  is  its  INSTANTANEOUSNESS. Instantly
     start programming, instantly see many  of  your  errors pointed out by
     editor and instantly try interpreted program.

     The strong-points of C are, I  think,  in order of importance: (1) its
     popularity =  support  (including  well-made  programming  packages  I
     presume). (2) A flexible  programming  environment, better suited than
     GFA Basic for LARGE projects  (though  other languages have this too).
     (3) Capability to  do  some  low-level  things,  most  importantly the
     passing of (pointers to) functions as parameters to other functions.

     (C++ adds further advantages of course, but the only Atari C++ package
     that I have seen is the public domain GNU C++, requiring 4MB of memory
     and a hard disk).

     To: John Watson and any other users of GFA Basic 2
     From: Mrten Lindstrm

     GFA Basic v2 vs v3
     ------------------
     I am afraid that all GFA Basic  related references and material that I
     have contributed are for version  THREE.  Apologies  for that, and for
     perhaps not have made this as clear as I should have done, but v3(.04)
     was the version that I  first  purchased  and  the only version that I
     have really used, and I wasn't  until  now  aware of quite how big the
     difference is.

     I do have a v2 lying around  too  (got for free from somewhere) and on
     reading your message I tried  to  load  a  few  of my v3 listings into
     this, but frankly was surprised by how little of it that was accepted.
     (You may already have performed this experiment for yourself?)

     Improvements have been made to  the  editor  of course. Although still
     looking much the same  and  still  single-document  and non-GEM, a GEM
     menu with the GEM accessories can  be  reached. And among other things
     there is now a "procedure folding" feature to give better overview.
     And the execution speed is boosted.

     But, again and most  importantly,  the  language  itself  is very much
     improved from v2 to v3 of GFA Basic. Here are the additions in roughly
     the order of (my view of their) importance:

      +      The INLINE command,  allowing  assembly  routines (and various
             data such as built-in  GEM  resources)  to  be incorporated in
             program.

      +      Multi-line FUNCTIONs can be defined.
             Plus the parameters passed can  -  with  a  keyword VAR in the
             procedure/function definition -  be  the variables themselves,
             rather than their values,  ALSO  allowing  ARRAYS to be passed
             (not possible at all in v2, except through pointers).
             I find these  two  features  (in  particular  the  latter one)
             invaluable as they allow  the  definitions  of new functions/-
             procedures that can be called  JUST  AS NEATLY as the built-in
             ones. (With v2 you'd have to  use global variables and pointer
             passing as a substitute, but it wouldn't be nearly as neat).

      +      Integer size can be WORD  (16-bit)  and  BYTE (8-bit), and not
             only LONG (32-bit) as in v2.  (In addition to saving some time
             and memory, allows use of  WORD  ARRAYS  for VDI raster MFDB's
             and other OS structures, the  way  they are internally handled
             by the OS).

      +      Much improved means of handling pointers (effectively removing
             the need for PEEK, POKE  and  the  unary * operator, and again
             allowing neater syntax).

      +      All AES  functions  (except  the  newest  ones)  built  in  to
             language, using the  standard  format  (simplifying comparison
             with sources in  other  languages).  A  few  VDI  commands are
             similarly added. (All the  GFA-specific  commands based on VDI
             and AES calls are still there of course).
             Syntax for  making  low-level  GEM  calls  (to  implement  the
             functions not built in) also improved.

      +      Lots of other new commands  and  functions (including a number
             of integer-specific  functions  for  faster  execution  and  -
             amazingly - built-in  commands  for  shell  sorting  and quick
             sorting arrays).

     There are probably ways in v2 to  work around many of its limitations.
     For instance, there is no function  in  v2 to inquire the existence of
     GDOS, but - after thinking for a while  - I realized that one could be
     implemented through the following procedure:-

     PROCEDURE vq_gdos
       LOCAL s$,a%
       s$=MKL$(&H70FE4E42)+MKI$(&H4E75) !Hexadecimal codes for Motorola
       a%=LPEEK(*s$)
       LPOKE gdos%,C:a%()
     RETURN

     which would be called with

             @vq_gdos

     after which gdos% could be evaluated. (If gdos%=-2 then NO GDOS there,
     if  MKL$(gdos%)="_FNT"  then  FontGDOS,   if  MKL$(gdos%)="_FSM"  then
     SpeedoGDOS or similar and otherwise old GDOS there).

     To possibly help you translate v3  code  back  into  v2 here are a few
     further explanations:

     {addr%} corresponds to LPEEK(addr%) or LPOKE addr%,...
     WORD{a%} (or INT{a%}) correspond to DPEEK(a%) or DPOKE a%,...
     Thus the AES version number,  which  I  said  in  chapter 1 of the GEM
     guide could be accessed with  INT{{GB+4}},  can  also be accessed with
     DPEEK(LPEEK(GB+4)).

     V:a$ gives address of string, also accessible with Lpeek(*a$).
     V:a%(0) gives address of first array element (0) <=> Lpeek(*a%())+4.
     V:a%(0,0)             -   "   -            (0,0) <=> Lpeek(*a%())+8.
             etc.
     V:a%  is identical to  *a%.

     ~function(...)  is another way of writing  VOID function(...)

     Access of the elements in the GEM  arrays  can in v3 be done with e.g.
     ADDRIN(2)=a%  corresponding to  LPOKE ADDRIN+4,a%.

     VDISYS x,y,z   is same as   DPOKE CONTRL+6,y
                                 DPOKE CONTRL+2,z
                                 VDISYS x

     VDISYS x,y,z,w  is same as  DPOKE CONTRL+10,w
                                 VDISYS x,y,z

     But, all in all, if I had only  got GFA Basic 2 and were serious about
     it, although I am  a  parsimonious  devil  I  would really consider an
     upgrade to v3(.5).

     */ Another  consideration  when  choosing  a  programming  language is
     platform portability. If you might  want  to transfer your masterpiece
     to another computer system (say a PC) at a later date I think it would
     be unwise  to  choose  GFA  Basic  and  definitely  not  machine code.
     Presumably C would be OK  providing  the  program was not too hardware
     specific and HiSoft BASIC 2 (according to Jon Ellis in Atari World) is
     directly compatible with Microsoft Quick Basic  on the PC. It would be
     interesting to know just how  compatible  these Basics are since there
     are a number of good programming  books  available for Quick Basic, if
     anyone has any info, please let us know. ICTARI /*
     ----------------------------------------------------------------------
     To: Lars Andersson
     From: David Preston

     Re- STOS on a TT030.

     A couple of points -
     1.   I think STOS V2.6 is  the  latest (and last) version, although if
     anyone knows otherwise...
     2.   The answer to running STOS on the TT _may_ be BASICMJH.PRG, which
     was included on the cover  disk  with  ST Format #41. The accompanying
     text file suggests that it  could  cure  your problems. (The text file
     makes no mention of it being copyright  or anything so I have enclosed
     both files  as  they  appeared  on  the  cover  disk,  in  the  folder
     STOS_FIX).  As I understand it, this  will  only get STOS running, any
     completed compiled program files  you  produce  will  need to be fixed
     themselves if you are  to  run  them  on  the  TT. There are utilities
     available to do this for you, try any good PD library.

     */ See folder STOS\STOS_FIX.  ICTARI /*
     ----------------------------------------------------------------------

     ++ And finally something to think about over the Christmas holiday ++
        ===============================================================

     You Know You've Been on the Computer Too Long When...

     *  When you are counting objects, you go -
      "0,1,2,3,4,5,6,7,8,9,A,B,C,D...".

     *  When asked about a bus schedule, you wonder if it is 16 or 32 bits.

     *  When your wife says "If  you  don't  turn off that darn machine and
     come to bed, then I am  going  to  divorce you!", and you chastise her
     for omitting the else clause.

     *  When you are reading a book  and  look  for the space bar to get to
     the next page.

     *  When you look for your car keys using: "grep keys/dev/pockets"

     *  When you get in the  elevator  and  double-press the button for the
     floor you want.

     *  When not only do you  check  your  email more often than your paper
     mail, but you remember your {network  address} faster than your postal
     one.

     *  When you go to  balance  your  chequebook  and discover that you're
     doing the maths in octal.

     *  When you dream in 256 palettes of 256 colours.

     *  You're writing a homework  assignment,  and  get  to the end of the
     line in the middle of a sentence,  tack on a '\', and continue writing
     on the next line.

     *  You try to sleep, and think ... "telnet xxx.dreams.heaven"

     HTML version by Omri Weisman

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