Classic Computer Magazine Archive ST-Log ISSUE 28 / FEBRUARY 1989 / PAGE 78

REVIEW

GFA BASIC Version 3.0

Michtron
576 S. Telegraph
Pontiac, MI 48053
(313) 334-5700
$99.95

Reviewed by Mario Perdue

Mario Perdue is a programmer and CAD systems manager for a small engineering firm in Indiana.

In late 1986 and early 1987, the ST community was discovering a new BASIC programming language: GFA BASIC was written by Frank Ostrowski of GFA Systemtechnik and distributed in the U.S. by Michtron Inc. It seemed that everyone was talking about GFA back then; every ST magazine reviewed it, and several started monthly columns to cover its use. Soon, the ST SIGS on all of the major BBSs had a huge selection of GFA BASIC programs available for downloading. Some of these programs were quite impressive. But what was the big deal? After all, it's not like they were talking about a new version of C; they were talking about BASIC—Beginners All-purpose Symbolic Instruction Code—a language that would get you laughed at in many programming circles. Why was everybody so excited?

There were several reasons for the excitement. First, GFA BASIC was fast—much faster than any of the other BASICs available for the machine at the time. Also, it could be compiled to make it run even faster. Second, GFA had a much better editor and fewer bugs than ST BASIC. Third, GFA was a structured BASIC, which made the programs easier to read and debug. But most important of all these items was the range of GFA BASIC commands. Here was a BASIC that supported approximately 270 commands and/or keywords and added some commands and structures that were previously unavailable to BASIC programmers. There were the REPEAT...UNTIL, DO...LOOP and WHILE...WEND looping structures, and the MENU and ON MENU commands for custom user interfaces, to name a few.

After a short time using GFA BASIC, most programmers concluded that it was a winner, a rose among other ordinary flowers. But like its flower counterpart, GFA BASIC had some thorns. The first and worst thorn was the original manual. In all fairness, it was probably not the worst manual ever written, but it was the worst manual that I have ever encountered. Michtron quickly responded to this deficiency with a new manual. This one was written in English and was quite good. Other commonly mentioned thorns were GFA's lack of direct GEM support and lack of any interrupt-handling commands. Well, Michtron and GFA Systemtechnik have heard our complaints (constructive criticisms?) and have responded, this time with GFA BASIC, Version 3.0.

What you get

Version 3.0 comes in a package with a 646-page manual and a disk containing the GFA BASIC program, the run-only program and some sample codes. Also on the disk is Digital Research's resource construction program, its resource file, a READ.ME file describing its use and a program to convert .DEF files (like the ones used by the Megamax RCP) to .DFN files. Some of you may now be thinking. If GFA now supports resource files, what do I do with my GFA Companion? That is a good question. I formatted mine. They make excellent blank disks!

The manual

The new manual is considerably larger than its predecessor, a total of 646 pages. This is because the descriptions and examples are more detailed and require more space—and because there are more than 300 new commands and keywords.

The manual opens with two introductions: one for everyone and one for first-time GFA users. From there you are taken through the editor. There are some changes in the editor, so everyone should read this section. Next comes a section on variables and memory management. This section is not only better written than it was in the previous manual; it is also located in a better place. The earlier manual didn't discuss variables until the end, which made many examples hard to follow. After the variables are covered, we move into a section on math and string operators.

Starting with Chapter 5 the manual makes a radical departure from the format of the Version 2.02 manual. Chapters 5 through 14 cover every command in the language, which in itself is no big thing. The difference is that in this manual the commands are not just tossed at you in alphabetical order. They are grouped according to function; all input and output commands are grouped together, as are graphics commands, etc. I know, you're saying, "Big deal, that's the way it should be done." You're right, but how many manuals have you seen that are actually done that way?

Compatibility with earlier versions

There are some minor compatibility issues when converting programs written in earlier versions of GFA BASIC to Version 3.0. The file structure is completely different; so you can't just load your older code with the new program. What you have to do is save your old code in ASCII and then merge it into a new program. This will re-tokenize your program, which will allow you to save it in the new format. (Note that the new default extension is .GFA, not .BAS.)

Another compatibility problem occurs when you have used a variable name that is the same as a 3.0 command. I encountered this problem when I converted a program that used the variable select. SELECT is now a keyword in 3.0; so whenever I assigned a value to it, I had to add LET to the beginning of the line.

Some commands also work a little differently. MUL and DIV now work only with integer variables. In the new version the following code will return a value of 20, not 25, as it would have in 2.02:

a%=10
MUL a%,2.5

On the plus side, these commands now execute much faster. These are the only commands whose differences will cause a real problem with program execution. The other command changes are very minor and may not be noticed by most users.

Speed comparison

For the most part, Version 3.0 is faster than Version 2.02. To verify this, I devised a benchmark program (see Listing 1) to exercise various functions. The benchmark consisted of the following tests:

The first test is what I call the "handy dandy, inefficient, prime-number counter." It counts the primes from one to 500 (I don't know if it really works, but it consumes time).

The second test calculates the sum of the sines from one to 360.

Test 3 calculates the sum of the square roots of the integers from one to 1,000.

Test 4 counts from one to 10,000 with real numbers.

Test 5 counts from one to 10,000 with integers.

Tests 6 and 7 perform 1,000 write operations to the hard disk and floppy disk respectively.

The last test is the dreaded sieve. For this test I extract primes to 10,000. (I didn't write this portion; I "lifted" it off a BBS. It was originally written by Neil Harris when he was still with Atari.)

I ran these tests several times and as Table 1 shows, the results were surprising.

TEST DESCRIPTION GFA V2 GFA V3 Diff % Change
Count primes from 1 to 500 28.59 20.41 8.18 40.07
Sum of sines 0.56 0.64 -0.08 -12.50
Sum of square roots 1.03 1.06 -0.03 -2.83
Count 1 to 10,000—real 1.18 0.55 0.63 114.54
Count 1 to 10,000—integers 0.43 0.38 0.05 13.15
Write 1,000 times to hard disk 3.84 3.24 0.60 18.51
Write 1,000 times to floppy 10.69 9.05 1.64 18.12
Sieve 12.25 10.21 2.04 19.98
OVERALL 58.57 45.54 13.03 28.61
Table 1: Benchmark results

The above percentages are what I call "marketing percentages." To understand this, suppose you have a program that runs in 100 seconds and an equivalent program that runs in 75 seconds. The difference in their execution times is 25 seconds. If you compare this difference to the slower program, you can say that the second program is 25% faster than the first program because 25 is 25% of 100. However, if you are trying to sell the second program, you want it to look as good as possible, so you say it is 33% faster than the first program because 25 is 33% of 75. It's all in the way you look at it.

But back to the numbers, the first surprise was that there was any increase in speed at all. GFA was already very fast. It was going to be difficult to improve upon that. But just about everything was faster. My benchmark showed some significant changes in the area of looping. An empty FOR... NEXT loop showed the largest increase in speed, more than 114% when using real numbers. Other functions increased in speed by 13 to 40%, as shown in the table. I was amazed.

Then I noticed something that didn't fit the pattern. The "sum of sines" and "sum of square roots" routines actually ran slower. At first I didn't understand what the problem was. Everything indicated that these routines should also run faster, but they didn't. Finally, I noticed that the accuracy of real numbers in Version 3.0 had been increased from 11 digits to 13 digits. (When all else fails, read the manual.) This extra accuracy undoubtedly is the cause of the slowdown. Unfortunately, there is no way to turn this extra accuracy off. It would be nice if you could make a choice between accuracy and speed.

What's new?

Now we come to what has to be the most exciting part of the GFA 3.0: the new commands. This version has added literally hundreds of new commands, mostly to support GEM functions. There are complete libraries of functions to support the BIOS, XBIOS, GEM-DOS, Line-A, AES and VDI. There are so many new commands that even if I had this whole magazine to work with, it would not be possible to describe them all. Instead, I'll just hit some of the high points:

Programming with the AES is much easier than before. For instance, to load a resource file and get its address using GFA 2.02, you needed to do the following sequence of instructions:

Lpoke Addrin,Varptr(Fn$)
Gemsys 110
Dpoke Gintin,Tx
Dpoke Gintin+2,Which
Gemsys 112
P,tree=Lpeek(Addrout)

In GFA 3.0 this same program would look like this:

RSRC_LOAD(Fn$)
RSRC_GADDR(8,l,addr)

I think you'll have to agree that this is much shorter, easier to follow and (need I say) faster.

All of the AES and VDI functions are supported in a similar manner. What this means is that you now have full access to real menus and real windows. Everything to do with the screen display seems to be there. Some "C"ynical programmer is out there right now saying, "But I can use GDOS!" Guess what? Version 3.0 supports that too!

Interrupt processing is another new feature with this release. Two commands, AFTER and EVERY, provide a fair measure of interrupt control. For instance, suppose you want to play a tone for half a second. You could do this in 2.0 by specifying a duration in the SOUND command, but the result was that everything else stopped while the tone was being played. In 3.0 you would turn the tone on with the SOUND command, then do an AFTER command that calls a PROCEDURE to turn the tone off. The AFTER command would specify the time in 1/200 of a second. With this method, processing continues until the time expires. Then a GOSUB to the specified PROCEDURE is executed. Finally processing returns to where the interrupt occurred. This works well in game programming where smooth movement of a sprite is necessary.

Array handling has also been improved with the addition of QSORT, SSORT, INSERT and DELETE. The contents of an array can be sorted according to value by either a shell sort (SSORT) or a quick sort (QSORT). These sorts can be done in ascending or descending order. INSERT allows the insertion of an element into an array. When an element is inserted, all elements after it in the array are moved up one location. DELETE performs the opposite, removing an element and closing up the hole.

Another welcome addition to the language is the inclusion of the SELECT/CASE structure, which is very similar to SWITCH/CASE supported by C. For those of you who are unfamiliar with it, SWITCH/-CASE works like this:

SWITCH a
     CASE 1 to 5
          PRINT "1 to 5"
     CASE 6
          PRINT "6"
     DEFAULT
          PRINT "OUT OF RANGE"
ENDSELECT

The above routine would be equivalent to the following routine using IF/ELSE/ELSEIF/ENDIF:

  IF a >= 1 AND a <=5
   PRINT "1 to 5"
ELSEIF a = 6
   PRINT "6"
ELSE
   PRINT "OUT OF RANGE"
ENDIF

It doesn't make the code any shorter, but it sure does make it easier to read.

Summary

Although GFA BASIC 3.0 is an enhanced version of 2.0, there are far too many improvements for it to be considered "just an upgrade." I have been using it for a number of weeks, and still I am finding new features every day. The versatility and speed of the language are incredible. As a professional programmer, I must say that GFA BASIC 3.0 is by far the most enjoyable programming environment I have ever used. In my opinion, when Michtron releases the Version 3.0 Compiler, GFA BASIC will become a true development language. The compiler is "on its way," and may well be available by the time you read this. Now, if they can just come up with a way to easily merge machine-language routines with GFA programs....