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.
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:
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.
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.