It began with an Atari 400, a small computer similar to the Commodore 64. There existed a BASIC for that computer. This BASIC was neither fast nor comfortable to use, but, with only 16K of RAM, large programs could not be written anyway. After upgrading the computer to 48K of memory and 88K of disk space, I wrote some programs in assembly code. Eventually I ended up with a number of help routines, and a BASIC language with which I could marginally use with these routines. After trying FORTH, I decided to take a closer look at BASIC, and slightly modified it. These modifications eventually became so numerous that I decided to completely replace many of the routines. To remain compatible, some of the routines were left untouched. There were a lot of commands I did not like, such as computed GOTOs, and line numbers were a nuisance.

This new BASIC was published in a computer magazine. Shortly thereafter I received an offer from GFA Systemtechnik GmbH to write a workable BASIC for the new computer, the Atari ST.

The Atari ST incorporates a fresh modern processor. Its operating system, although certainly not the newest or fastest (nor is it very compact, having been written in C language) is very powerful. And, even though it lacks multitasking, one can write programs in high level languages that offer exciting performance.

Shipped with a BASIC language that did not even measure up to the one included with the Atari 400, the ST was destined to become a language developers dream. It was possible to now develop a BASIC that did not have to conform to the standard of any other interpreter.

This new BASIC should have the simplicity of BASIC combined with the possibility of writing well structured code. The first step was to eliminate the line numbers. This made the task difficult from the outset because a solution had to be found to avoid the usual confusion of GOTOs and GOSUBs. It was important to be able to pass parameters to procedures and to declare local variables, thus enabling the programmer to use recursive programming techniques. The BASIC should also make sure that all loops are properly closed before the program starts execution.

The GOTO statement was one of the last statements added to this BASIC. After much thought, I even allowed the GOTO command to be used between different procedures.

In an Interpreter it is possible to use segmented PEEKs and POKEs to simulate one of the Intel-processors. In a compiled program, this would greatly affect execution time.

The unsuitable 16 bit integers would not be used either, as this makes it harder to address all of the memory. Besides, the processor already uses 32 bits internally, thus allowing it to process larger numbers without speed loss.

The editor of this BASIC had to be screen oriented and not use the windows of GEM. It would be virtually impossible to create non GEM programs from within the GEM interface. Other reasons exist for not having the editor run under GEM.

In the case of a program error, it is often possible to save program changes that were made. Something that cannot always be done from within GEM because the windows lock up. So it happened that a relatively fast editor, one that could be used without a mouse, was created.

I wanted to write the BASIC completely in machine language so that it would be fast and take up only a small portion of memory. Other languages like C use only a few machine instructions outside of the library, and they always pass parameters through the stack. The MC68000 has a very powerful instruction set that can be better utilized with an Assembler.

Taking all this into consideration, Version 1.0 of GFA BASIC came into existence less than 6 months later.

While I was writing the interpreter, I carefully made sure that the finished programs could be easily compiled. That is why the MERGE command is missing. This command may be useful in an interpreter, but is of little value in a compiler.

While I was working on the compiler, I was confronted with requests to expand the command set. Some of those requests I was able to incorporate in Version 2.0 of the interpreter. Most new commands, like VOID, BASEPAGE, and OPTION, were inserted to give the compiler more optimization opportunities, and to provide the programmer with more control over the compiling process.

Even an extensive computer language cannot fulfill all the wishes of everyone who uses it. This book will, therefore, show you how to create necessary routines using GFA BASIC.

This book does not present you with complete applications; it gives routines that can be incorporated into your own programs.

GFA BASIC is only a BASIC and not a Modula 2, therefore you cannot create modules in quite the same way. Modula 2 takes a lot more coding and a multitude of small modules to write an application. Modula 2 can only be used as a compiler. BASIC includes numerous commands that would have to be created within libraries in Modula 2.

Part of this book discusses many different operating system routines which include examples wherever I felt they were needed. Naturally, there are routines that can be run directly without going to the low-level operating system routines, but rather with built in commands.

An important part of this book is the last chapter, where a complete GEM program is shown. It demonstrates how to use all parts of a window. This is not easy to do in GEM, but it makes it convenient for the user of the program. For the programmer, GEM always means extra work. There are many programs where most of the code is written just to manipulate the window.

I hope that you find the routines and tips in this book useful, and I wish you much success.

Taken from the 'Introduction' section of the book "The GFA BASIC Book"
Written by Frank Ostrowski
Text Translation by Wilford Niepraschk
Published in the U.S.A. by MichTron, Inc.
(C)1987 GFA Systemtechnik
1st English Edition: September 1987
ISBN 0-923213-85-6