Atari BASIC is an interpreter for the BASIC programming language that shipped with Atari 8-bit computers. Unlike most American BASICs of the home computer era, Atari BASIC is not a derivative of Microsoft BASIC and differs in significant ways. It includes keywords for Atari-specific features and lacks support for string arrays.
The language was distributed as an 8 KB ROM cartridge for use with the 1979 Atari 400 and 800 computers. Starting with the 600XL and 800XL in 1983, BASIC is built into the system. There are three versions of the software: the original cartridge-based "A", the built-in "B" for the 600XL/800XL, and the final "C" version in late-model XLs and the XE series. They only differ in terms of stability, with revision "C" fixing the bugs of the previous two.
Despite the Atari 8-bit computers running at a higher speed than most of its contemporaries, several technical decisions placed Atari BASIC near the bottom in performance benchmarks.
Development The machines that would become the Atari 8-bit computers were originally developed as second-generation video game consoles intended to replace the Atari VCS. Ray Kassar, the new president of Atari, decided to challenge Apple Computer by building a home computer instead.
This meant the designs needed to include the BASIC programming language, the standard for home computers. In early 1978, Atari licensed the source code to the MOS 6502 version of Microsoft BASIC. It was offered in two versions: one using a 32-bit floating point format that is about 7800 bytes when assembled, and another using an extended 40-bit format that is close to 9 KB.
Even the 32-bit version barely fit into the 8 KB size of the machine's ROM cartridge format. Atari also felt that they needed to expand the language to support the hardware features of their computers, similar to what Apple had done with Applesoft BASIC. This increased the size of Atari's version to around 11 KB; Applesoft BASIC on the Apple II+ is 10,240 bytes long. After six months the code was pared down to almost fit in an 8 KB ROM, but Atari had a January 1979 deadline for the Consumer Electronics Show (CES) where the machines would be demonstrated. They decided to ask for help to get a version of BASIC ready in time for the show.
Shepardson Microsystems
In September 1978, Shepardson Microsystems won the bid on completing BASIC. At the time they were finishing Cromemco 16K Structured BASIC for the Z80-based Cromemco S-100 bus machines. Developers Kathleen O'Brien and Paul Laughton used Data General Business Basic, an integer-only implementation, as the inspiration for their BASIC, given Laughton's experience with Data General on a time-sharing system.
Cromemco BASIC includes an extended floating point implementation using a 14-digit binary-coded decimal (BCD) format made possible using all 16 registers of the Zilog Z80 processor. As it converts all data to the internal format at edit time, small constants like "1" use ~8 bytes of memory, and this could be a particular issue when storing arrays of numbers. To address this, the language also supports a smaller 6-digit BCD format.
Even the smallest BASICs on the 6502 used about 10K. For instance, Commodore BASIC used 9K but also relies on support from the KERNAL, while Applesoft BASIC is 10,780 bytes. To meet the goal of fitting in an 8K ROM, the new BASIC would be in two parts: the language itself on the cartridge and a 2K floating point library in the system's 10K ROM supporting only the 6-digit format.
Atari accepted the proposal, and when the specifications were finalized in October 1978, Laughton and O'Brien began work on the new language. The contract specified the delivery date on or before 6 April 1979 and this also included a File Manager System (later known as DOS 1.0). Atari's plans were to take an early 8K version of Microsoft BASIC to the 1979 CES, then switch to Atari BASIC for production. Development proceeded quickly, helped by a bonus clause in the contract, which led to the initial version being delivered in October. Atari took an 8K cartridge version to CES instead of Microsoft's. Atari Microsoft BASIC was later a separate product.
Releases The version Shepardson gave to Atari for the CES demo was not intended to be final, and Shepardson continued to fix bugs. Unknown to Shepardson, Atari had already sent the CES version to manufacturing. This version is known as Revision A. It contains a major bug in a routine that copies memory: deleting lines of code that are exactly 256 bytes long causes a lockup after the next command is entered. The key does not fix it.
The language was distributed as an 8 KB cartridge for use with the 1979 Atari 400 and 800 computers and included the Atari BASIC Reference Manual written by Carol Shaw and Keith Brewster.
Revision B attempted to fix the major bugs in Revision A and was released in 1983 as a built-in ROM in the 600XL and 800XL models. While fixing the memory copying bug, the programmer noticed the same pattern of code in the section for inserting lines, and applied the same fix. This instead introduced the original bug into this code. Inserting new lines is much more common than deleting old ones, so the change dramatically increased the number of crashes. Revision B also adds 16 bytes to a program every time it is SAVEd and LOADed, eventually causing the machine to run out of memory for even the smallest programs. Mapping the Atari described these as "awesome bugs" and advised Revision B owners "Don't fool around; get the new ROM, which is available on cartridge" from Atari. The book provides a type-in program to patch Revision B to Revision C for those without the cartridge.
Revision C eliminates the memory leaks in Revision B. It is built-in on later versions of the 800XL and all XE models including the XEGS. Revision C was also available as a cartridge.
The version can be determined by typing at the READY prompt. The result is 162 for Revision A, 96 for Revision B, and 234 for Revision C.
The complete, annotated source code and design specifications of Atari BASIC were published as The Atari BASIC Source Book in 1983.
Description
Program editing
Atari BASIC is anchored around its line editor. Program lines can be up to three physical screen lines of 40 characters, 120 characters total. The cursor can be moved freely, with the editor automatically tracking which BASIC program line the current screen line is part of. For instance, if the cursor is currently positioned in line 30 and the user uses cursor-up into line 20, any editing from that point will be carried out on line 20.
Atari BASIC's editor catches many errors that are ignored in Microsoft-derived versions. If an error is found, the editor re-displays the line, highlighting the text near the error in inverse video. Errors are displayed as numeric codes, with the descriptions printed in the manual. Because of the way the line editor works, the user can immediately fix the error. In the example pictured above (with PRUNT), the error can be fixed by moving the cursor over the U, typing (the editor only has an overwrite mode), and hitting .
A line entered with a leading number, from 0 to 32767, is inserted in the current program or replaces an existing line. If there's no line number, the interpreter assigns it the number -1 ($8000) and the commands are executed immediately, in "immediate mode". The RUN command executes the stored program from the lowest line number. Atari BASIC allows all commands to be executed in both modes. For example, LIST can be used inside a program, whereas in many interpreters this would be available in immediate mode only.
During entry, keywords can be abbreviated using the pattern set by Palo Alto Tiny BASIC, by typing a period at any point in the word. So L. is expanded to LIST, as is LI.. Only enough letters have to be typed to make the abbreviation unique, so PLOT requires PL. because the single letter P is not unique. To expand an abbreviation, the tokenizer searches through its list of reserved words to find the first that matches the portion supplied. More commonly used commands occur first in the list of reserved words, with REM at the beginning (it can be typed as .). When the program is later LISTed it will always write out the full words with three exceptions: PRINT has a synonym, ?; GOTO has a synonym, GO TO; and LET has a synonym which is the empty string (so 10 LET A = 10 and 10 A = 10 mean the same thing). These are separate tokens, and so will remain as such in the program listing. MS BASICs also allowed ? as a short-form for PRINT, but this used the same token so it expanded back to when ed, treating it as an abbreviation, not a synonym.
Tokenizer When the user presses while editing, the current line is copied into the BASIC Input Line Buffer in memory between and . Atari BASIC's tokenizer scans the text, converting each keyword to a single-byte token (for example, is ), each number to a six-byte floating point value, each variable name to an index into a table, and so on, until the line is fully turned into an easy to interpret format. The result is stored in an output buffer located at the first 256 bytes of the lowest available free memory, pointed to by the LOMEM pointer stored at , . The output from the tokenizer is then relocated. The program is stored as a parse tree.
Shepardson referred to this complete-tokenizing concept as a "pre-compiling interpreter". The resulting tokenized code eliminates any parsing during runtime, making it run faster. It has the disadvantage that small constants, like 0 or 1, are six bytes each, longer than the original text.
A set of pointers (addresses) indicates various data: variable names are stored in the variable name table (VNTP – , ) and their values are stored in the variable value table (pointed to at VVTP – , ). By indirecting the variable names in this way, a reference to a variable needs only one byte to address its entry into the appropriate table. String variables have their own area (pointed to at STARP – , ) as does the runtime stack (pointed to at RUNSTK – , ) used to store the line numbers of looping statements (FOR...NEXT) and subroutines (GOSUB...RETURN). Finally, the end of BASIC memory usage is indicated by an address stored at MEMTOP – , ) pointer.
Math functions Atari BASIC includes three trigonometric functions: sine, cosine, and arc tangent. DEG and RAD set whether these functions use radians or degrees, defaulting to radians. Eight additional functions include rounding, logarithms, and square root. The random function, RND, generates a number between 0 and 1; the parameter not being used.
String handling Atari BASIC copied the string-handling system of Hewlett-Packard BASIC, where the basic data type is a single character, and strings are arrays of characters. Internally, a string is represented by a pointer to the first character in the string and its length. To initialize a string, it must be DIMensioned with its maximum length. For example:
10 DIM A$(20) 20 PRINT "ENTER MESSAGE: "; 30 INPUT A$ 40 PRINT A$
In this program, a 20 character string is reserved, and any characters in excess of the string length will be truncated. The maximum length of a string is 32,768 characters. There is no support for arrays of strings.
A string is accessed using array indexing functions, or slicing. A$(1,10) returns a string of the first 10 characters of A$. The arrays are 1-indexed, so a string of length 10 starts at 1 and ends at 10. Slicing functions simply set pointers to the start and end points within the existing allocated memory.
Arrays are not initialized, so a numeric array or string contains whatever data is in memory when it is allocated. The following trick allows fast string initialization, and it is also useful for clearing large areas of memory of unwanted garbage. Numeric arrays can only be cleared with a FOR...NEXT loop:
10 REM Initialize A$ with 1000 characters of X