HiSoft BASIC ($79.95)
HiSoft BASIC Professional ($159.95)
MichTron Inc., 576 South Telegraph
Pontiac, MI 48053
Reviewed by Ian Chadwick,
Depending on how you look at it, this is either a great time for ST BASIC users or a terrible time. It's great because there are so many options from which to choose, including ST BASIC, Fast BASIC, GFA BASIC 2.0 and 3.0, STOS and now HiSoft BASIC. You can pick the language style you prefer: Microsoft-like, structured, game-oriented, compiled, GEM or TOS based and so on. However, because of the proliferation of BASICs, it's unlikely one will become the de facto ST standard, and portability among the various products is limited. Translation is all too often very difficult.
The latest entry into the arena is HiSoft BASIC (with its enhanced version, HiSoft BASIC Professional). MichTron obviously hopes to capture the hearts and minds of the ST users with what is their replacement for the lost GFA BASIC. With the latter emerging as the most popular of the lot, it's natural to compare the two.
Since HiSoft has made a considerable impact in England, where it originated, MichTron must assume that it should find a good following on this continent. But first they must undo the good job they did in selling GFA BASIC over the past two years. And it won't be easy.
HiSoft BASIC (referred to as HSB from here on) is a structured language based on the popular Microsoft QuickBASIC design, offering a high degree of code compatibility with QuickBASIC 3.0. Note that QuickBASIC is already at Version 4.5 on the PC, a couple of generations beyond 3.0. By now, ST users should be accustomed to the lag between product levels.
While there's nothing unique in the commands and functions to set HSB apart from other BASICs, it does stand out from the rest in that it combines a text editor and a compiler into one package. The highlight of HSB is the "seamless" interface between the two: When you write your code, you actually compile it to memory, then run it and return to the editor. This is a far cry from the cranky process of writing, exiting, compiling, testing, rewriting and so on that I complained about in a recent Ian's Quest column. Unlike GFA, you don't need to quit the program to go to the compiler.
The other side of the coin is that HSB lacks GFA's interactive parsing and syntax-checking. With HSB, you discover errors only at runtime or compilation. For the novice (or, like me, anyone who has trouble typing on the abysmal ST keyboard), this may not be a worthwhile tradeoff. However, the error messages produced by HSB are clear enough and more informative than GFA's. If you choose not to continue your program when an error is found, the program halts at that line with the cursor on the problem.
The second major tradeoff is in simplicity. HSB is not as easy to use as GFA. The two (HSB and GFA 3.0) compare favorably when measuring functionality, but GFA comes out on the plus side with more features. GFA has some nice commands and functions, like PI, INP?(), TRUE, SGET and SPUT, BREAK and ON BREAK, array-swapping and sorting, plus full VT-52 terminal support that HSB lacks. On the plus side, HSB shows a considerable improvement in speed over GFA.
To its credit, HSB performs very well; the interface is fast and smooth. I haven't been able to crash it, something I cannot say for any GFA BASIC release. Compilation is equally fast, with the unfortunate caveat that you cannot change drive and path when compiling from the program, except through the inclusion of an $OPTION command within the code itself.
HSB supports the full range of GEM AES, DOS and VDI calls, as well as BIOS and XBIOS calls, in a manner similar to the standard C conventions-including the need to include the proper libraries for proper compilation and execution. This is where the simplicity prob-lem arises.There are no simplified com-mands available in GFA for creating alert boxes, handling menus or most other GEM functions. HSB does have some more sophisticated window commands than GFA, but they require a little more effort to program.
HSB has one advantage for the user converting from ST or older BASICS: It allows optional line numbers and line labels. The choice of using numbered or unnumbered code is up to the user.
Following the Microsoft standard is a good move, since it brings us closer to compatibility with the PC world. However, HSB is a hybrid and compatibility is only partial. HSB adds some commands, such as REPEAT/END REPEAT and RESET, not found in QuickBASIC, while ignoring others like DRAW, DECLARE and KEY (in some cases these are available as different commands or through one of the GEM calls). HSB's command set may prove a trifle disconcerting to ST users more familiar with other BASIC commands and syntax, but the changeover should not be difficult.
The big question is: Is it worth the effort to move to a new BASIC, especially one that currently has no large base of support on this continent? Should you stick with GFA or should you move u p to C?
Professional programmers have disdain for BASIC, although it's quite possible-often even easier-to write commercial applications with a compiled BASIC as long as the result works at a reasonable speed. Professionals tend to use C for its portability, power and wide acceptance across a variety of platforms, such as Unix and MS-DOS. It's mostly novices and aging hackers like myself who choose BASIC.
Most C packages come with better documentation, resource construction kits, utilities and examples, not to mention an enormous local user base for support, literature and code. By now, GFA BASIC has enough of a user base here to offer considerable user support too. HSB has none.
HSB is good and could well have taken the market by storm had it been released at the same time as GFA. But the package flaws and the sparsity of support materials make me hesitate to recommend it strongly, unless you're moving directly from the PC QuickBASIC language and can afford to buy all the books on GEM you'll need.
If you're unsure, I'd suggest you wait and see if MichTron releases a better manual and perhaps some support materials first.
Entry lelel vs. Professional level
Although there is a considerable price difference between the two
versions of HiSoft BASIC, there really isn't much difference as far as
the average programmer is concerned. Certainly not enough to justify
$80 worth in this reviewer's mind.
Professional level lets you write your own libraries in assembly language. Somehow, I doubt that assembly language users accomplished enough to write libraries will be using anyone's BASIC.
Professional level has a stand-alone compiler with a command line interface environment. On the PC this is necessary, but on the ST it's peripheral.
The Professional level manual describes conversions from ST BASIC Version 2, has an appendix on assembly language details and memory formats and an ASCII character table.
Professional level has a profile program to help determine where your program spends most of its time. While interesting, this is of minimal use to the casual user.
The most important difference is that Professional level can compile code directly into desk accessories. Unfortunately, the appendix describing this powerful feature is, like the rest of the manual, inadequate and contains mistakes. Beginners will not be able to understand the process involved, let alone write an actual accessory, from what little description they give you.
It's hard to see how these features are worth twice the price. The actual program code is some 3K larger in the Professional level, but whether this indicates hidden features or simply improvements and bug fixes, isn't documented.
The DocumentationLike many MichTron products, HiSoft BASIC (HSB) is compromised by the quality of the documentation, which is wholly inadequate for the product. The entry- level version even lacks an index. Without an index, the manual is next to useless. It has a fair number of typos and errors, some serious. For example, it mistakenly labels the VOI call vqf attributes as vql attributes (p.305).
Both versions' manuals exhort you to purchase the ST BASIC, Microsoft Quick-BASIC and Borland's Turbo BASIC handbooks to get the information and explanations you need to use HSB! This astounding suggestion serves only to further point out the weaknesses of the HSB documentation.
The Professional-level manual is somewhat better, with a marginal (but still woefully incomplete) index and many (but not all) of the typos and errors in the junior version corrected. On the other hand, it fails to name chapters and appendices in the table of contents. I don't understand why MichTron has such a difficult time producing documentation that is at least equal to the product.
Worse is the manner in which the GEM and BIOS material is presented. The descriptions are terse, incomplete and opaque, with few examples to ease the confusion. Anyone not intimately familiar with the topic will find it almost impossible to use most of the functions presented here without yet more support books (I heartily recommend Sheldon Leemon's ST Trilogy, from Compute! Books). You'll also need a resource construction set (supplied with later versions of GFA BASIC). The GEM and BIOS calls are the real heart of the language and provide complete control over the ST's features. My own opinion is that anyone already familiar enough with these (developers or professional programmers) is currently using a language such as C, so what's the impetus to change to BASIC?
Some areas of the manuals are simply dismal. For example, you are recommended to use an AES constants header file, supplied on disk, but you are only told that these constants are most of those in the original Digital Research documentation; you are not told what they are, how they are used or what's missing. Would that HiSoft had not merely copied the language standard but had also taken the manuals Microsoft provides with QuickBASIC.
Newcomers will find themselves forced to do heavy hack-and-slash experimentation in order to figure out what the language can do and can't do. The examples on the disk do not begin to cover what the program can do, especially in the critical area of GEM. In fairness to buyers, MichTron should redo the manual, add tutorials, examples, a proper index and table of contents, then provide it, free of charge, with suitably abject apologies.
| The Classic Sieve
of Eratosthenes Benchmark:
Program 1a: GFA BASIC 2.0
Print "Sieve - 25 iterations"
For Iter=1 To 25
For I=0 To 8190
For I=0 To 8190
If FIags(I) Then
Print count;" primes in "; z;" seconds"
interpreted: 394.16 seconds
compiled: 122.75 seconds
file size: 6916 bytes
Program 1b: HiSoft BASIC
PRINT "Sieve - 25 iterations"
X# = TIMER
FOR Iter = 1 TO 25
count = 0
FOR I = 0 TO 8190
Flags(I) = 1
FOR I = 0 TO 8190
IF Flags(I) THEN
Prime = I + I + 3
K = K + Prime
WHILE K <= 8190
Flags(K) = 0
K = K + prime
count = count + 1
XX# = TIMER
PRINT USING "#### primes in ##.### seconds"; XX# - X#
This version, from Turbo BASIC,
ran unmodified in HiSoft BASIC
and QuickBASIC when loaded as a text file.
run from program:
compiled: 57.24 second
file size: 12588 bytes
file size: 32048
|Program 2a: GFA BASIC 2.0
Print "BYTE SIEVE, 7000 numbers done 5 times"
For J=1 To 5
For I=0 To Size
For I=0 To Size
If Flags(I)=0 Then
If K>Size then
Print Acount;" primes found"
Print "Took ";Y;" seconds"
interpreted: 73.88 seconds
compiled: 22.46 seconds
file size: 6893 bytes
Program 2b: HiSoft BASIC
rem next line turns overflow,
rem array checks and line numbers off
rem $option a-o-n-
10 PRINT "BYTE SIEVE, 7000 numbers done 5 times"
30 DIM FLAGS(7001)
for j=1 to 5
50 FOR I=0 TO SIZE
70 NEXT I
80 FOR I=0 TO SIZE
90 1F FLAGS(I)=0 THEN GOTO 170
120 IF K>SIZE THEN GOTO 160
150 GOTO 120
170 NEXT I
180 PRINT ACOUNT;"prints found"
Print "Took" t!/5 "seconds"
This version also ran,
unmodified, in QuickBASIC.
run from program: .87 seconds
compiled: 87 seconds
file size: 10812 bytes