IAN'S QUEST

Ian Chadwick

I was having a coffee with some fellow ST enthusiasts the other day and one of them asked me, "What language do you program in?"

"BASIC," I said.

The other looked at me aghast. One even gagged, "BASIC? You're not serious!"

"I am," I replied evenly.

"But, but..." he spluttered, "Why not C? Everyone programs in C."

"I don't."

Another one banged his fist on the table and declared, "Pascal. That's the high-level language to use. It's easier than C."

"It's not easier than BASIC," I retorted mildly. "BASIC is about the easiest language I know."

"What about speed? BASIC is so slow."

I shrugged. "Not if you use a compiler."

"But what about GEM calls? VDI? AES? BIOS? XBIOS? ST BASIC can't do any of them without some heavy poking. You might as well write in assembly if you're going to do everything that way."

High-level programmers generally agree that assembly language programmers are really nocturnal aliens who think in hexadecimal.

"You can get a lot of direct access to system calls in GFA BASIC 2. In Version 3, you can access all of them directly, the same way you can in C or Pascal, and it's a structured language," I said.

Anyway, the conversation continued in that vein. No one asked me if there was, in fact, a compiler available for GFA BASIC 3 (there isn't, at least not in early January when I wrote this, and I'm not going to phone Germany to find out right now).

Anyway, I like BASIC, and I refuse to apologize for the language. I am particularly fond of interpreted languages. Most languages like C, Pascal, Modula 2 and some variations of BASIC have no inherent interpreter. The process of writing and debugging code with them goes something like this:

1. Start the text editor. Write your code. Save same. Exit the text editor.
2. Start the compiler. Compile the code (sometimes this is a two- or three-step process involving linkers and multiple-pass compilation), and wait until it's finished (a period anywhere from a minute to forever). Exit the compiler.
3. Run the new program. Write down any problems, changes or bugs on a piece of paper. Exit the program.
4. Start the text editor again. Load the source code. Look at the piece of paper. Try to rewrite the code from your notes. Save the code. Exit the text editor.
5. Start the compiler and go through the whole process again, watching the hard-disk light blink on and off. Try to think up a song that matches the rhythm. Exit the compiler.
6. Run the new program and write down any problems, changes or bugs on another piece of paper. Exit the program.
7. Start the text editor again. Load the source code. Look at the new piece of paper. Try to decipher what EXC.IN MNU COL 2 means. Rewrite the code from your notes as best as possible. Save the code. Exit the text editor.
8. Start the compiler. Consider using this waiting time to finish reading War and Peace, or take a night school course. Tap your fingers on the desk. Look up the word "glacial" in the dictionary. Exit the compiler.
9. Run the program again and wonder how you managed to miss another great gaping hole in the code. Scribble furiously any problems, changes or bugs on yet another piece of paper. Exit the program.
10. Start the text editor and load the source code. Think seriously about taking a handwriting course. Try and remember what was so important about the "screen shrink" that caused you to write it in big letters all over the page. Edit and rewrite the code from your notes, and hope you got it right this time. Save the code. Exit the text editor.
11. Start the compiler. Give serious thought to throttling the computer dealer who promised you this was the fastest compiler on the market. Then wonder what the guy using the slowest one is thinking right now. Consider a new career in shoe sales. Exit the compiler.
12. Run the program. Scream and shout and curse about the one stupid mistake where you forgot a matching quotation mark, and watch the program spew a series of bombs on the screen. Tear several pages off the pad, and write savage remarks about the code, the origin of the language, the stupidity of programming and the need for artificially intelligent text editors. Reboot the system, and try again.
13. Start the text editor, and load the source code. Look at your notes and wonder how and when they got changed from English to Babylonian script. Try and remember which piece of paper is the most recent. Try and remember if the change you're making is really correcting the problem, or if you're just undoing the last change you made and writing the code back the way it was 17 compiles ago, when it didn't work then either. Try to remember why you wrote "ghj shgs jahsf!!!!" and what it means. It's probably very important. Exit the text editor in frustration.
14. Start the compiler. Watch the error messages scroll by too fast to note on the wads of paper covering your desk. It's the only fast thing in the entire process. Ignore them, and compile anyway. Wait. Wait. Wait. Practice, patience. Chant your mantra. Wait some more. Exit the compiler.
15. Run the program. Smile and clap your hands as everything seems to work properly. Then watch in dismay as a simple file I/O turns into an unexpected hard-disk format. Search frantically for more paper to make little notes as the program runs itself rapidly into oblivion and erases weeks of hard work. Write madly. Weep openly.

Get the picture? Me, I like to test and hack in the interpreter before I get to the compiler stage. That way, I am reasonably assured of a stable program, fewer pieces of paper, a lot less hair pulling and considerably less time spent watching my hard-disk light flash.

It's no secret that I'm a fan of GFA BASIC 2.x (and will be of Version 3.x when bugs are ironed out and when a compiler makes the scene). I'm leery of GFA, now that it no longer (as of this writing) has a North American support and service group, MichTron having been dropped under circumstances that appear less than savory. How is it going to be able to update all the current 3.x owners with a non-buggy version?

MichTron is not asleep at the wheel, however. It is bringing out a new BASIC—one very popular in U.K., Highsoft BASIC. It doesn't have an interpreter. That worries me. I've been told online that the system is so constructed that you can go from text-editor to compiler to running the program and back to text editor seamlessly, without any significant pauses. That may alleviate the syndrome described above; we'll see in a future review.

In the meantime, another U.K. product has made it to our shores in the guise of STOS "The Game Creator," from Mandarin Software, distributed by Terrific Software out of San Francisco.

STOS bills itself as a "revolutionary package that has everything you need to create fast, exciting games quickly and easily." I'd hesitate to call it revolutionary, but I'll agree with the rest. STOS is really BASIC: line numbers, spaghetti code, the whole bit. But it has more than 300 commands with many game-specific functions not found (as such) in any other language I know of.

For example, you can create sprites easily, display up to 15 on the screen, move them, animate them, change their colors and so on—all easily, with fairly direct commands. STOS provides not only a decent sprite editor, but simple means to cut sprites out of DEGAS and Neochrome pics, or to copy them from another program. Take a look at these lines:

SPRITE 1, 10, 160, 2
MOVE X 1, "326(2,-6, 0)L" : MOVE ON

This translates as: Put Sprite #1 from Bank 2 on the screen at Location 10,100. Move Sprite #1 in the X axis, starting from Location 320, at Speed 2 (fast), six pixels to the left each time (a positive number moves it to the right), indefinitely (a number other than 0 is the iteration count, the number of times the step is repeated). L is for loop and means continue this instruction from the start once done (the sprite moves off the screen). MOVE ON activates the command. Pretty straightforward. Then add this line:

ANIM 1, "(2, 5) (3, 5) (4, 5) (5, 5)L" : ANIM ON

This is the animation sequence: Sprite 1, Images 2 through 5, are each displayed in sequence for a duration of 5/50; of a second. L is the loop and ANIM ON activates it. In two lines, we've placed, moved and animated a sprite! This simplicity and ease for otherwise difficult constructions makes STOS a joy to work with.

STOS has more than 20 sprite-related commands alone, including collision detection, tests for location, pixel detection and synchronization with a scrolling background.

Other STOS commands include joystick read commands; numerous sound and music commands; screen fade, shrink, grow and appear commands; screen copy, pack, shrink and zoom, window and menu commands and many others; not to mention the usual BASIC command and function list—over 300 commands altogether.

To facilitate game construction, STOS also comes with—among other accessories—a sprite, font, icon and music designer (accessed from within the BASIC program itself!). There is also a "map" editor for creating games with scrolling backgrounds such as Time Bandit and Gauntlet. These accessories can be loaded as background tools or as BASIC: programs to edit and change or run. Some of them are a tad awkward, but all perform reasonably well.

STOS has some unusual but powerful features. For example, there are 15 memory banks reserved for program use. These can contain sprites, screens, music, data, machine language programs, icons, character sets or be used as temporary workspaces. Banks are saved with your program—that's why the accessories can take music, sprites and so on from other STOS programs so easily. STOS also uses two levels of screens, a background screen for sprites and another for foreground display. "Physic" and "Logic" differentiate between two foreground screens, which can be exchanged with the SWAP command. Banks can also be reserved for other screens and exchanged with the display through a few simple commands.

There are commands to list and print bank information. STOS can switch back and forth between low and medium resolution within a program, without crashing. You can store up to four programs in memory at once and switch between them easily.

STOS has a "smart" file save feature: It automatically saves a file in the correct format according to the extension: .ASC for ASCII, .BAS for tokenized BASIC, .PRG to create a run-time program, .ACB for accessories, .MBK and .MBS for memory banks, .VAR for a list of variables and .PI1, .PI2, .PI3 or .NEO for DEGAS or Neochrome graphics.

Probably the only fault I can find with STOS is in the manual. It's not badly written, but the organization and layout are confusing and awkward. Commands are grouped by function (e.g., sprites), but are not in any order within a group (alphabetical order seems not to have occurred to the writers). This makes it difficult to find things by browsing. The "Guided Tour" section shows off some dazzling effects with simple commands, but doesn't tell how or why—a source of great frustration for the newcomer. You're not always told everything you need. For example: How many windows can be opened at once?

There are few graphics and screen shots, when many would ease comprehension problems. And there are a few typos that may cause a few headaches. For example, if you use their example DIR$=[ \ STOS", you'll get an error—the syntax is DIR$ = [STOS" to go down one directory level. Another: On page 164, it says 8 × 16 fonts can be used "happily" in all three resolutions, but on page 170, it says they're only usable in high and medium resolution.

Because of the clumsy manual, you'll find yourself jumping all over the place, trying to understand features, trying to find associated commands, but one saving grace is the abundance of example code. I only wish they'd included some examples of the results of that code.

STOS isn't a GEM program, so it doesn't use or have access to any GEM (or GEM-DOS), AES or VDI calls. Nor can you get at the BIOS or XBIOS calls. It uses its own equivalents, although some, like the file selector, are rather inelegant. The menu commands do not equal those found in GFA BASIC; however, you can use icons, not just text in STOS menus. You can gain an extra 32K or so of workspace by auto-booting STOS rather than loading it through the GEM desktop.

Finally, you can easily create "run time" versions of your games for commercial release. There are special utilities and commands to do this from within the BASIC interpreter itself. These save a .PRG file and a reduced version of STOS, similar to GFA's run-only program.

STOS comes with three games: a horizontally scrolling train-race game, a Galaxians clone and a Blockade clone. The latter, called Orbit, is itself worth the price of the package. Each also has a construction set for designing your own screens and levels! All three demonstrate STOS's amazing speed and flexibility plus they can be listed and changed. I added a high-score file-save to Orbit after a few minutes of listing and examining code for a suitable location.

Overall, for BASIC buffs and would-be game designers, STOS is an excellent buy and a fun alternative to the other BASICs. It's one of the better buys on the ST right now.

Parting shots

First the good news: I was amazed to discover that Borland—a major software publisher in the PC/MS-DOS world, known for its superb products such as Sidekick, Paradox, Sprint and the Turbo languages—has published Turbo C for the ST. Yes, an amazingly fast, powerful, beautifully crafted C! I watched a demonstration of it recently (Calamus was written in Turbo C). It simply out-does everything else in the category.

Now the bad news: It's only available in Germany. Why? I don't know. If you want to find out, write to Borland, 4585 Scotts Valley Drive, Scotts Valley, California 95066. Apparently the company doesn't think the North American market is the right place to sell its own product.

Ian Chadwick is a Toronto-based freelance writer and editor, specializing in technical writing, software manuals and computer documentation.