REVIEW
BASICs FOR THE ST
START COMPARES FIVE
by DAVID PLOTKIN
START compares five BASICs for the ST: Atari's ST BASIC, SoftWorks BASIC, Logical Design Works Compiler, Computer Concepts' Fast ST BASIC, and MichTron's GFA BASIC--including a critical analysis of each program's features, documentation and support.
File BENCHMRK.ARC on your START disk
BASIC is the language of choice for many programmers and aspiring programmers. It is quick, compact, and does its job. As of March 1987 there are five BASICs available for the Atari ST computers. They are very different, and the purpose of this article is to compare their merits and drawbacks.
The first BASIC is Atari's ST BASIC, packaged free with your ST. Much has been written about this language and its shortcomings, and it is a standard of sorts: everyone has a copy, and listings you see printed in magazines are likely to be written in ST BASIC.
LDW BASIC is not really a separate BASIC at all, but a compiler for ST BASIC, and it shares many of the limitations of ST BASIC. But LDW BASIC solves the problem of ST BASIC's slow speed: LDW's compiled code is very fast. Revision 1.1, which arrived just before we went to press, includes some significant enhancements over the original version.
SoftWorks BASIC is totally different from ST BASIC; I had to completely rewrite the benchmarks to test it. It is compiled and fast, as well as being portable--applications which don't use GEM or other ST-specific features will run unmodified on a Macintosh or Amiga.
Computer Concepts' Fast BASIC is the first ST cartridge BASIC. An import from England, it is without a doubt the easiest to use and most powerful of the languages I surveyed.
Finally, GFA BASIC is a German import that's powerful and very fast, but currently suffers from a poor manual. It includes a run-time package and should have a compiler available soon.
(Editor's note: Readers may notice that Philon's FAST/BASIC-M has not been included in this comparison. At the time we prepared this article, Philon was revising their program extensively and asked that it not be included. We hope to present a review of the revised program in a future issue of START.)
BASIS OF COMPARISON
The comparisons I make in this article are different from those you may have seen in other language comparisons, since users generally require different things from BASIC than they would of a language like C. BASIC users don't expect lightning-fast execution, though speed is important for writing complex applications. BASIC users tend to be hobbyists, not developers, and often do not have access to technical information about the machine, so special features (such as GEM) must be implemented within the language if they are to be used extensively.
BASIC users also have varying levels of experience with the language (and computers, for that matter). Documentation that is adequate for an experienced user may leave a novice totally lost. None of the manuals that come with these BASICs are designed to teach the language, but even as reference manuals they vary widely in quality and usefulness.
With all these points in mind, we will look at each BASIC: calculating speed, quality of documentation (including GEM support) and ease of use.
SPEED AND BENCHMARKS
A benchmark is a short program that performs a task on a computer; it's used to measure how fast and accurately the task was performed. Benchmarks don't always test what they claim to measure, but no comparison would be complete without some measure of performance
Benchmarks canmeasure some important features. Floating-point math and trigonometric functions are important to an engineer like me--and so is the speed penalty for using floating-point numbers instead of integers. String handling is essential for applications like telephone and address books and other mini-databases, and the time required to write large chunks of data to disk is also significant.
On your START disk you'll find four different benchmark files, because I had to significantly modify the benchmark program for the different BASICs. The changes help highlight the differences between the languages. For example, ST BASIC uses GOTOXY to position text on the screen. GFA uses PRINT AT. Two others use PRINT TAB: SoftWorks BASIC puts the y-coordinate first, while Fast ST BASIC uses the more familiar order of x-coordinate first. SoftWorks also has no screen clearing command, and instead of LPRINT you must open a channel to the printer. Fast ST BASIC has an LPRINT command, but it didn't work--I had to use the VDI function to echo screen PRINT to the printer.
String handling also had some significant differences. ST BASIC and GFA BASIC use the STRING$ command to fill a string with characters. With MID$ they can pick out a portion of a string or set the contents of a substring. SoftWorks cannot set the value of a substring using MID$, so I used substring operators instead. Fast ST BASIC has a STRING$ command, but it didn't work--and neither did setting a substring using MID$. In each case concatenation was used to build the string.
Finally, to time a benchmark, you must have access to a timer. The ST has a timer that counts in jiffes(60ths of a second), using the four bytes starting at $462. In ST BASIC, you can use DEF SEG and a double precision variable to read all four bytes at once. SoftWorks uses the LONG function to do the same job. Fast ST BASIC has multiple byte operators called "indirection operators," but they crash the machine, so I was reduced to using single-byte PEEKs and multiplying out the results. GFA BASIC has a built-in timer calibrated in increments of 1/200 of a second, so I had to do a conversion to get comparable times.
ST BASIC
Ah, ST BASIC. If you want to write a BASIC program that anyone with an ST can run, this is the language to use. ST BASIC is a full-featured generic BASIC that allows access to rudimentary graphics and sound. It supports random and sequential disk access and program chaining; string-handling is good, and multiple-byte PEEKs and POKEs are possible (though clumsy). WHILE and PRINT USING make structured programming and printing easier, and a full range of debugging tools including TRACE and FOLLOW are available.
However, many ST BASIC operations are sloooow, and in its current version there are significant bugs. The floating-point package, for example, is not particularly accurate. In fact, I have not been able to obtain satisfactory results from ST BASIC on a number of engineering calculations.
ST BASIC supports GEM only in a limited way. Some graphics and sound functions can be used with keywords, but alert and dialog boxes, menus, windows and fancy graphics are only available using POKEs and a pair of generic GEM commands, VDISYS and GEMSYS. The syntax of these commands is given in the manual, but little else; for detailed information or examples of how to use GEM calls, you will have to turn elsewhere. I think many people who purchase the ST to program it in BASIC fully expect to be able to use the GEM features in a straightforward manner; for them, ST BASIC will be a disappointment.
DOCUMENTATION
The ST BASIC documentation includes instructions to get you started, an alphabetized list of keywords and a few sample programs. It is a good reference manual--better than I've seen with other languages--and should be adequate even if you are only moderately experienced with another version of BASIC. With some perseverance, you could learn to program in ST BASIC from it.
Listing the keywords alphabetically often gives strange results: ENDWHILE is listed before WHILE, and ELSE before IF, so the explanations of these keywords make little sense if you read the manual straight through. Atari did some rearranging, explaining some closely related keywords at the same time. Each keyword is accompanied by several short examples, which help clarify the uses for the keyword.
USING ST BASIC
Entering programs in ST BASIC is a chore. The editor consists of four different windows: EDIT, OUTPUT, LIST and COMMAND. These windows shift distractingly, moving in front of one another as you execute different commands. Further, changes to text in the EDIT window leaves difficult-to-read "ghost" text in its place. Having two windows, one for the program listing and one for the output, can sometimes be an advantage, but too many windows make programs slower and programming more difficult. (My article on using ST BASIC in the Winter 1986 issue of START gave some pointers on how to circumvent some of this clumsiness.)
Running a program is made simple by the fact that ST BASIC is a GEM application. Thus, attempting to load a file will bring up the familiar File Selector Box, so that you don't have to remember what files are on the disk. Pull-down menus can RUN or BREAK the program, and give easy access to the editing tools. ST BASIC is interpreted, so that you can run the program right away, make changes, check variable values, and run it again. This simplifies debugging considerably. The program, of course, runs slower than if it were compiled.
SUPPORT
Support for ST BASIC is only fair. Atari has a customer service number (408-745-2367) that may be able to answer your questions. Because ST BASIC has been widely distributed, you can probably also get answers from your local user group, a friend, or magazines like ANTIC and START. If you own a modem, you can post a notice on a bulletin board or information service like CompuServe or GEnie and get a quick answer. Atari users are well known for their willingness to help others, and I suspect this is the best support of all.
SUMMARY
ST BASIC will cost you nothing extra, and is a good learning tool, with decent documentation and widespread help available. But if extreme accuracy, speed or GEM access are very important to you, then you should probably explore another BASIC.
LDW BASIC COMPILER
The LDW BASIC Compiler is a compiler for programs written in ST BASIC that also implements a number of enhancements. A compiler converts a program into machine code, so the final result of the LDW compiler will usually run many times faster than the interpreted ST BASIC version could.
There are two reasons why many people prefer interpreters over compilers. First, a compiled program must normally be written, compiled and tested; if anything doesn't work properly (usually the case), you must go back to your original program, correct it and recompile--a process that can be very lengthy. Second, it can be very difficult to find the problem in a compiled program, since you can't just print out the values of variables to see what is going wrong. To get at variable values, you must build debugging statements into your program to print them out, then remove those statements after the program is working.
The LDW BASIC Compiler gets around these problems by compiling ST BASIC. Thus, you can write a program in interpreted ST BASIC and debug it; once everything works properly (but slowly), you can compile to produce a fast version. Although you may not get exactly what you want the first time (it may be toofast), the amount of back-and-forth debugging is kept to a minimum.
Since the LDW BASIC Compiler is designed specifically to compile ST BASIC, it has most of the same drawbacks, except speed. Some enhancements have been built-in: line numbers are optional, and the constraints on array and string size as well as number of lines, have been removed; there's double-precision math, and a multiple-pairs version of LINEF lets you draw many lines using one command. Of course since these enhancements are not available in ST BASIC, you will have to go back to the compile-debug-fix cycle if you want to use them. A very few normal ST BASIC commands do not work in the compiler, but they are well documented and not likely to cause trouble.
The newest version of the LDW compiler, revision 1.1, adds many new commands including some to read and set the time and date, enable and disable the break key ([Control] [C]), and enable the output window. Unlike the original version, it has no copy-protection, and it includes a variety of batch files for compiling and linking your ST BASIC program. Also available is the option to not produce the assembler source code, which saves a great deal of time and disk space. Using a RAMdisk or hard disk cuts the time required still further. One of the batch files for two-drive systems allows you to simply walk away and come back later to find everything done, with the .PRG file on your disk.
Another enhancement is the inclusion of GEM bindings--subroutines that do all the dirty work of calling GEM and AES for you. For example, to create an alert box you simply set two variables and GOSUB FORM_ALERT. The subroutine will even return the number of the button in the alert box you clicked on. The use of the GEM bindings is muchmore straightforward than POKEing and PEEKing in ST BASIC. The bindings are well documented, noting what variables must be set and what they are and what special arrays must be dimensioned; the documentation includes page numbers in Atari's GEM manuals and Abacus Software's Atari ST GEM Programmer's Referencefor finding further information. The GEM bindings will even work in regular ST BASIC programs, and they are a valuable addition to the LDW package
DOCUMENTATION
The manual is dedicated strictly to how to use the compiler, and generally does a good job. The first section tells you what enhancements have been added to ST BASIC, and then how to actually compile a program. It is explicit about the disks you must set up and the exact steps to follow.
The balance of the manual discusses the options available during compile, and contains more details about the language implementation (such as double-precision and bugs in ST BASIC). The details tend to be overly technical and the language is often stilted--but you canfigure out what's going on. The explanation of GEM access is no better than in the ST BASIC manual, but the GEM bindings available in revision 1.1 make GEM access easier. While the technical section will be incomprehensible to most BASIC users, you don't need this section to make the compiler package work.
USING THE LDW BASIC COMPILER
The package consists of an assembler, linker and compiler, along with the EMACS editor. If you are using straight ST BASIC code, you can just use the ST BASIC editor. If you don't want to use ST BASIC, or are going to be using some of the enhancements, I suggest you try a word processor such as 1ST Word; the EMACS editor is pretty unwieldy and entirely command driven (no GEM).
After you've created your BASIC program, you follow the manual's instructions for your system configuration. The LDW BASIC Compiler will take your BASIC source code and create assembler source code (if you choose that option), assemble to object code, link the necessary files, and modify the resulting code to make it relocatable. When the compile(assemble)-link-RELMOD cycle is complete and you have created your final .PRG file, you can transfer it to another disk and use your working disks to compile your next effort. The working disks will fill up fast, since some huge intermediate files can be created while compiling, but most of these files are automatically erased when the program finishes.
SUPPORT
Support for the LDW BASIC Compiler is surprisingly good, both by phone (408-435-1445) and mail. LDW has mailed several bulletins to all registered owners, addressing common problems. Their enhancement policy is also fair: revision 1.1, with a brand new manual and two disks, is available for only $25 to registered users.
SUMMARY
The LDW BASIC Compiler is the only one that can compile ST BASIC. It does a good job of it, and if you have written a good (but slow) ST BASIC program, this may be what you need. The benchmark results are impressive, and with its new lower price ($60 less than the original price) it is an excellent value for those who need its unique capabilities.
SOFTWORKS BASIC
SoftWorks BASIC bears little resemblance to ST BASIC. It is a compiled BASIC, with all the inherent disadvantages compilers present for debugging. This was brought home forcefully to me when I programmed the benchmark, since it took several passes to get it to run successfully
A SoftWorks BASIC program actually compiles to an intermediate code called p-code,which does not run as fast as the machine code generated by LDW, but compiles much faster. A run-time package (provided with SoftWorks BASIC) must be present on the disk for your compiled program to run. Using the compiler itself and running the compiled .RUN file was very simple, since version 2.0 supports standard GEM file selector boxes.
SoftWorks BASIC supports a fairly complete set of commands, although it is missing such advanced features as procedures, WHILE, and CASE. Many of the keywords that experienced BASIC programmers expect to find are missing or have different names, which can cause some confusion. On the other hand, this BASIC has some powerful extensions, such as mapped variables (similar to RECORD types in Pascal), substring operators, routines to move blocks of memory, and arrays up to seven dimensions. You can also do multiple-byte PEEKs much more easily than in ST BASIC.
GEM support in SoftWorks BASIC is there, but you have to know how to use it. All the special (not generic) ST GEM functions are available through the TOOLBOX command. You can use not only VDI and AES, but XBIOS and GEMDOS as well. The TOOLBOX commands mirror the C language calls closely, so if you know your way around GEM, you can construct a fully GEM-based application. The catch is, you must know your way around GEM; I suspect many BASIC programmers do not, and the documentation is no help. Since there is absolutely no supportfor any kind of graphics, sound, windows, alert and dialog boxes, and menus outside of the TOOLBOX command, the programmer who isn't familiar with GEM will not be able to use any of these features. This is much worse than ST BASIC, which at least lets you do some graphics and sound. The GEM-ignorant programmer will be able to produce only "plain vanilla" generic BASIC programs with SoftWorks BASIC. Of course, this may be all you want--it's enough for engineering problems. But even dry applications can benefit from a little spicing up.
DOCUMENTATION
The SoftWorks BASIC manual begins with four pages explaining what a program is, followed by the section on using the compiler. One place where this manual gets high marks: Instead of using strictly alphabetical listings of the keywords, they are broken up into sections such as General Statements, File I/0, and Error Trapping. Unfortunately, the explanations that accompany the keywords are quite technical, and will be difficult for the beginner to understand. In fact, the manual is called a "technical reference manual," and that is primarily what it is. I would have to categorize this as a BASIC for the moderately advanced programmer; the documentation is adequate for someone who has learned another version of BASIC.
As I mentioned before, the only access to any GEM support at all is via the TOOLBOX command. Here the manual falls down. Although the TOOLBOX command parameters are in a separate section, the descriptions are cryptic and of little help. There are no examples of how the various commands tie together to, say, open a window. Since this sort of information is currently very hard to find, the average user is left without any access to GEM.
SUPPORT
Numerous calls to SoftWorks have convinced me they are serious about their support. A programmer is available most of the time, and SoftWorks seemed genuinely interested in helping me find out why something wouldn't work. They were never condescending, although not all of their programmers are as familiar with the ST version of SoftWorks BASIC as with other versions.
SUMMARY
If you don't need any GEM support, but want speed of execution without mind-numbing compile times, this BASIC will probably fit the bill. Its GEM support may become accessible later, as the documentation for the Atari ST and GEM gets better. It is very different from any other BASIC I have used, so there is a fairly steep "learning curve" until you begin to think in this new language. (Editor's note: For another perspective on SoftWorks BASIC, see Chris Chabris' article "Shoestring Development" in the Winter 1986 issue of START.)
FAST ST BASIC
Computer Concepts' Fast ST BASIC is the most powerful of the currently available BASICs. It sports a tremendous number of commands, giving the user unprecedented control over the program. It is also simple to use, provided on cartridge and totally GEM-driven. The desktop includes printer, disk and clipboard icons, as well as icons for each of the up to 10 programs that can be loaded in at once. LOADing, SAVEing and PRINTing are simply matters of dragging one icon on top of another. The drop-down menus are helpfully arranged, and the arrangement of the screen makes it easy to see both the output and listing at the same time.
Fast ST BASIC comes with a powerful editor for entering programs. It includes many features found in word processors, such as sophisticated cursor control, case and letter swapping, cut and paste, search and replace and auto-indent. There is no syntax checking when you enter a program, so debugging must take place at run-time (but Fast ST BASIC's variety of commands help with debugging). It even has a built-in assembler so that assembly language source code can be part of the program listing, and the code will be automatically assembled when you run the program.
The scope of built-in commands is impressive. Besides all the "normal" keywords you would expect to find, Fast ST BASIC allows for elements of structured programming (PROCEDURES and FUNCTIONS), advanced loop and decisions (WHILE, CASE, REPEAT), access to the system (folders, directories, time and date, drive information, screen resolution and location), single- and double-precision variables and functions, and two ways of bit-blitting. The built-in keywords for moving blocks of bits around the screen are fast and easy to use.
Fast ST BASIC also has the best GEM support of any of the BASICs. All VDI graphics are available allowing you to put lines and shapes on the screen, set drawing mode and color, and print text using built-in commands rather than using ST BASIC's numbered calls. This BASIC even supports many of the GEM AES calls, such as alert boxes, windowing, menus, and events, although notdialog boxes.
There are still some bugs in Fast ST BASIC, including key words that don't work and less crash protection than usual. The latter is probably because of the enormous power of the language. It allows you to do so much that you can get yourself into trouble! Fast ST BASIC is also very sensitive to syntax: Failing to capitalize a keyword will cause BASIC to treat it as a variable, and an extra space or semicolon in the wrong place will cause an error. There is virtually no support for sound, and only single-byte PEEKs and POKEs are allowed into system memory--the multiple byte operators will crash the machine and cannot be used to work with the more interesting memory locations.
DOCUMENTATION
Fast ST BASIC's thick manual has a section on the editor (which doesn't cover all the options), some information on variable types, and then the alphabetical listing of all keywords. No mention of strings or arrays is made and file handling is left for an appendix. The explanations of the keywords themselves are pretty good, with sample program illustrations. The keywords dealing with GEM AES support are in a separate section, also arranged alphabetically. This makes little sense and I found it confusing. The AES explanations are not as complete as they could be but are still better than any other BASIC.
SUPPORT
This is an easy one--currently, there is no support. Computer Concepts is based in England, and there is no customer support contact in the US or Canada. A program such as this one, which is fairly expensive and still has some bugs, needs technical support to make it a success.
SUMMARY
This is a great language to experiment with. Its implementation is extremely powerful, but is limited by the lack of support, some bugs, and the absence of a run-time package. A big plus for the "power user" is the excellent GEM support and built-in assembler.
GFA BASIC
MichTron's GFA BASIC is both powerful and very fast. It has a large number of commands--not as many as Fast ST BASIC, but GFA is not as prone as Fast ST BASIC to crash. Included with the package is a run-time version of the language, which you can give out freely so that people who do not own the language can use your applications.
GFA BASIC has two screens: one is a powerful text editor, the other is used for output from your program. The text editor's features include copy, cut, paste, find, and replace. You may enter commands using short abbreviations, and the editor will print out the commands on the screen in their entirety when you press [Return]. Syntax checking is immediate as in ST BASIC, and there is also a command to check the structure of loops. The text editor does not use drop-down menus, but does have commands across the top of the screen that you can click on with the mouse. You can also use keyboard commands.
The text editor indents lines automatically when they are within a loop or Procedure, so that you can easily tell where the bounds of the loop are. It even lets you switch into the high resolution mode where 48 lines of text will fit on one screen. GFA BASIC uses labels instead of line numbers. Because of the two screen set-up, you can switch back and forth between your listing and the output whenever you like.
All standard features of BASICs are well represented. You also have some powerful extras, such as DO/LOOP, REPEAT/UNTIL and WHILE/WEND (but no CASE statement). You have access to a timer, and to the system time and date; you can define your own functions and procedures with local variables. Bit blitting via both built-in commands and the GEM BitBlt is supported.
GFA BASIC offers quite a bit of GEM support, although not as much as Fast ST BASIC. Commands for graphics shapes, fills, colors, text and markers are all built into the language. Full mouse control, including coordinates and condition of the mouse buttons, and the ability to set the shape of the mouse pointer are available. You can build and install your own menus, control various aspects of any of four different windows, and detect most important occurrences (keyboard input, mouse position, GEM messages and menu selection). There is even support for Alert boxes, although not for Dialog boxes. You can access VDI and AES by numbered calls for any function not supported, as in ST BASIC. You use XBIOS and BIOS functions the same way.
The windowing system is a little clumsy, and the GEM support is not as effective as it could be because the documentation doesn't provide enough information. There are also some minor bugs in GFA BASIC--for example, PRINT USING doesn't work properly under certain circumstances.
DOCUMENTATION
GFA BASIC comes with a thick manual that launches straight into the editor, and then proceeds to document the commands in alphabetical order. A few notes about such important matters as variable types are not included until the very end, leaving you somewhat confused when those variable types show up in the main body of the documentation. Some items, such as arrays, are not mentioned at all.
The manual is also laced with typographical errors and language that is incomprehensible in some places and just too technical in others. MichTron assures me that the manual is being completely rewritten to correct the language and typos. Each keyword is accompanied by an example, which goes a long way toward clarifying how the command works. Unfortunately, even these examples have typos. The explanations accompanying some of the GEM features (such as windows and messages) are extremely sketchy and will likely not be of much use to anyone but an experienced GEM programmer. Perhaps the manual rewrite will correct this as well. There are only a very few example programs on the disk, and one of these is not complete--several procedures are missing.
SUPPORT
GFA BASIC was created in Germany, but support is provided by MichTron. A programmer at their offices answers questions, and the support seems to be pretty good, especially for a product as new as this one.
SUMMARY
GFA BASIC is very fast and easy to use, due to its editor and variety of commands. It is really not for the inexperienced, and some important information is missing from the current version of the manual. If you are mildly proficient in another BASIC, though, you will enjoy using this powerful version. The presence of the run-time package will also allow distribution of your efforts. A compiler will be available by the time you read this.
CONCLUSIONS
Of the five BASICs we have looked at, three are interpreted (ST, GFA and Fast ST), and two are compiled (LDW and SoftWorks). Each has its advantages and disadvantages; what is right for you depends on your needs. If you are a hacker/experimenter or advanced user, Fast ST BASIC is fast and very powerful. If speed is very important and GEM is not, SoftWorks BASIC could fill your needs. If speed and some GEM support are necessary, GFA BASIC is it. If you are a beginner, need only limited GEM functions and/or lots of support, the ST BASIC you already own may be ideal. If speed of final execution becomes a problem, that can be solved by the LDW BASIC Compiler.
Finally, remember that you are not locked in to using BASIC. There are many other languages available for the ST, each with inherent advantages and disadvantages. Determine what's best for your needs and shop around. I hope my overview of BASICs for the ST will help you make an informed choice.
ST BASIC
Atari Corporation
1196 Borregas Avenue
Sunnyvale, CA 94086
(408) 745-2000
Disk--Free
LDW Compiler
Logical Design Works
780 Montague Expressway #205
San Jose, CA 95131
(408) 435-1445
Disk--$69.95
Fast ST BASIC
Computer Concepts
Gaddesden Place, Hemel Hempstead
Hertfordshire, England HP26EX
Cartridge--$139.95
SoftWorks BASIC
SoftWorks Limited
2994 N. Broadway
Chicago, IL. 60657
(312) 975-4030
Disk--$79.95
GFA BASIC
MichTron Inc.
576 South Telegraph
Pontiac, MI 48053
(313) 334-5700
Disk--$79.95
Compiler--$79.95
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|