Using GFA BASIC - Part 01

    GREETINGS...

     Welcome to the first installment of "Using GFA BASIC", a new
   monthly column for INSIDE INFO.  If reader response is
   encouraging, each month I will try to pass along a few tips and
   tricks intended to make your GFA BASIC programming efforts more
   effecient, productive, and hopefully... fun!


   WHO IS THIS COLUMN FOR?...

     Sorry, but I don't intend to make this a beginner's
   tutorial series.  There are other sources of information better
   suited to that task (see below).  But neither will I restrict
   discussion of use only to those with considerable programming
   experience.  I will initially assume that most readers of this
   column are somewhat familiar with the GFA BASIC editor, and have
   likely dabbled a little with other BASICs as well.


   WHY GFA BASIC?...

     As of this writing, GFA BASIC is undoubtedly the most
   popular programming language for most ST users.  It's easy to
   use, fast, powerful, and very inexpensive.  This is not to say it
   is best for all purposes (Assembly, C, et al, certainly have
   their place) but if you only have the time or inclination to
   learn one ST programming language, GFA should be it.


    WHERE DO I GET GFA BASIC 2.0?...

     Antic Publications recently bought the distribution rights
   to GFA BASIC 2.0 and included it on their December 88 Start
   magazine disk.  You can get a copy of the disk from the ACE[NSW]
   library but you need to purchase the magazine to legally use it.
   An equally good bargain is that Antic is selling the GFA BASIC
   manual for only $US9.95.  This is an exceptionally good deal so
   be fair and send them the money required for the back issue and
   manual to be a legal user:

                     Start
                     544 Second Street
                     San Francisco, CA  94107
                     USA

     If you have never programmed in BASIC before but want to
   learn, I recommend you purchase a copy of Michtron's book, GFA
   BASIC TRAINING REBOOT CAMP by D.A. Brumleve (US$19.95).  Yes,
   it's a silly title but it is quite an excellent tutorial that
   doesn't treat you like an idiot yet it's not overwhelming either.
   If you can't find it locally, you can order it direct from:

                     Michtron, Inc.
                     576 Telegraph Road
                     Pontiac, MI  48053
                     USA

     Michtron also has available several other books on GFA you
   might be interested in.  George Miller's new book, the GFA BASIC
   REFERENCE GUIDE, VOLUME 1, is a superb, massive volume with loads
   of information for new and experienced users alike.  Another is
   the GFA BASIC BOOK which is a guide for advanced users.


   WHAT ABOUT GFA BASIC 3.0?...

     GFA BASIC 3.0 is the latest version and is jam-packed with
   features including over 300 NEW commands and a 600 page manual.
   It retains all the good features of the 2.0 version while
   improving the editor and overall run-time speed plus full AES
   implementation.  If you already own GFA BASIC 2.0, I strongly
   recommend you upgrade to 3.0 (US$40 for the upgrade).  Otherwise,
   I recommend you start off with GFA 2.0 because it's so cheap.
   This column will be written with the 2.0 user in mind, but since
   3.0 is entirely downward compatible, any routines mentioned will
   work fine with both versions.  [NOTE:  Michtron has just
   announced availability of a NEW BASIC called HiSoft which they
   claim to be even more powerful than GFA 3.0.  I hope to have a
   hands-on review of HiSoft soon so stay tuned!]


   DO I NEED THE GFA BASIC COMPILER?...

     No, but you will probably want it eventually.  Essentially,
   the compiler takes your GFA BASIC source code and converts it
   into a standalone executable program (*.PRG) file.  The end
   result is an even faster running program that anyone can use (and
   your source code is kept private as well).  The 2.0 compiler
   retails for US$80.  The 3.0 compiler is not yet available.


   GETTING STARTED...

     Now that all that rubbish is out of the way, let's get down
   to business.  Load GFA BASIC and when the editor screen comes up,
   press the ESCape key to put you in "immediate" mode.  Now type
   the following line and press RETURN:

                     DEFLIST 0

   Now return to the editor by pressing ESCape followed by RETURN.
   All this did was to change the display mode of your editor so
   that all GFA BASIC reserved words will be displayed in upper case
   and all others in lower case.  This will be the format I will use
   in this column so it will be easier to understand if we all use
   the same mode.


   OPTIMIZING YOUR CODE...

     Let's try a little experiment.  Enter the following code in
   the editor, then press SHIFT+F10 to run it:

                a=1
                start=TIMER
                FOR i=1 TO 1000
                  a=a+i
                  a=a-i
                  a=a*i
                  a=a/i
                NEXT i
                PRINT (TIMER-start)/50;" seconds"
                PRINT FRE(0);" bytes free"

   Note the "seconds" and "bytes free" amounts then make the
   following changes and try it again:

                a%=1
                start%=TIMER
                FOR i%=1 TO 1000
                  ADD a%,i%
                  SUB a%,i%
                  MUL a%,i%
                  DIV a%,i%
                NEXT i%
                PRINT (TIMER-start%)/50;" seconds"
                PRINT FRE(0);" bytes free"

   Quite a difference, isn't it?  The whole point of this little
   exercise is to demonstrate simple ways to optimize your code for
   speed and memory usage.  This leads to Hutch's Optimization Rules
   #1 and #2, namely... "Use INTEGER variables (those with a "%"
   suffix) whenever possible" and "Use GFA's built-in integer math
   functions whenever possible".  INTEGER variables operate much
   faster in loops and require less memory than REAL variables and
   the math functions are considerably faster too.  If your program
   needs REAL numbers then by all means, use them, but only when you
   have to.  Conserving memory may not seem like a big deal when you
   have 1/2 to 4 Megabytes to play with but as your programming
   efforts expand in complexity, it becomes important.

     There are many other ways to optimize your programs, of
   course, and we will deal with some of them when appropriate.  As
   a general rule of thumb, however, simply try to write your code
   so it does what it needs to do in as few lines as possible and it
   will generally be more efficient.  That may seem self-apparent
   but many programmers seem to become "oblivious to the obvious".
   This leads us to Hutch's Optimization Rule #3... "If a given
   routine needs to be duplicated more than twice in a program, make
   it a procedure call".  For example, if you have a program that
   has the following lines repeated at several places in the code:

                     IF key$<>right_key$
                       OUT 2,7
                       SETCOLOR 0,7,0,0
                       ALERT 1,"Wrong key,|  Dummy!|,1," Rats! ",dummy%
                       SETCOLOR 0,7,7,7
                     ENDIF

   it's more efficient (and elegant) to do this:

                     IF key$<>right_key$
                       GOSUB wrong_key_alert        ! User messed up
                     ENDIF
                     '
                     PROCEDURE wrong_key_alert
                       OUT 2,7                      ! Ring the bell
                       SETCOLOR 0,7,0,0             ! Turn screen red
                       ALERT 1,"Wrong key,|  Dummy!|,1," Rats! ",dummy%
                       SETCOLOR 0,7,7,7             ! Turn screen white
                     RETURN

   Again, use your best judgement but if the use of procedures can
   result in fewer lines of code then go for it!  You will likely
   find that your code is easier to read and understand as well.
   One more thing, note the use of my comments, above.  I use a LOT
   of comments in my code.  If you have ever written a complicated
   piece of code, put it away, then came back again after six months
   and scratched your head trying to figure out what the heck you
   were trying to do then you will understand why.

     I believe that's more than enough for this session.  Next
   month we will talk about "structured programming" (ARGHHH!) and
   perhaps demonstrate a couple of handy graphics routines.


   HELP!!!

     Your feedback is IMPORTANT!  Send your comments, questions,
   suggestions, hate mail, etc, to me via E-mail on the ACE [NSW]
   BBS.  We hope to have a GFA SIG up and running on the BBS soon so
   stay tuned for announcements.