Using GFA BASIC - Part 01


 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!


 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.


 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.


 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:

                 544 Second Street
                 San Francisco, CA  94107

 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

 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.


 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!]


 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.


 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.


 Let's try a little experiment.  Enter the following code in

the editor, then press SHIFT+F10 to run it:

            FOR i=1 TO 1000
            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:

            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

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

                 IF key$<>right_key$
                   GOSUB wrong_key_alert        ! User messed up
                 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

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.


 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.
John Hutchinson


Copyright-Bestimmungen: siehe Über diese Seite
Classic Computer Magazines
[ Join Now | Ring Hub | Random | << Prev | Next >> ]