Atari BASIC

Shepardson Microsystems

The 8K ROM Atari BASIC cartridge for Atari 8-bit computers.

In September 1978, Shepardson Microsystems won the bid on completing BASIC.^[3] Shepardson had written a number of programs for the Apple II family, which used the same 6502 processor, and were in the middle of finishing a new BASIC for the Cromemco S-100 bus machines (Cromemco 32K Structured BASIC).^[5]

Shepardson examined the existing work and decided it was too difficult to continue cutting it down to size; instead, they recommended developing a completely new version, originally 10k in size.^[6] To make it fit on an 8k ROM, some of the common routines would be moved to the operating system ROMs. Atari accepted the proposal, and when the specifications were finalized in October 1978, Paul Laughton and Kathleen O'Brien began work on the new language.^[3]

The contract specified a delivery date on or before 6 April 1979 and this also included a File Manager System (later known as DOS 1.0).^[6] Atari's plans were to take an early 8K version of Microsoft BASIC to the 1979 CES and then switch to the new Atari BASIC for production. Development proceeded quickly, helped by a bonus clause in the contract, and an 8K cartridge was available just before the release of the machines. Atari took that version to CES instead of the MS version.^[7] Atari Microsoft BASIC later became available as a separate product.^[8]

Releases

The version Shepardson gave to Atari for the CES demo was not supposed to be the final version. Between the time they delivered the demo and the final delivery a few weeks later, Shepardson found several bugs in the code and had developed fixes for them.^[7] However, unknown to Shepardson, Atari had already sent the CES version to manufacturing.^[9]

This version was later known as Revision A. Among several problems, this version contains a major bug in a subroutine that copies memory; under certain conditions, deleting lines of code causes a lockup. This was sometimes known as the "two-line lockup" because it triggered when the next line of code or command was entered. It was notorious as it was one of a very few problems that could not be fixed by pressing the Reset key.^[10]

Revision B attempted to fix all of 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 "fix" 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.^[10] Another major problem in Revision B was a bug that added 16 bytes to the memory of the program every time it was SAVEd and LOADed, eventually causing the machine to run out of memory even on the smallest programs.^[11][12] Mapping the Atari described them as "awesome bugs", and advised Revision B owners "Don't fool around; get the new ROM, which is available on cartridge" from Atari.^[12] The book provided a type-in program to patch Revision B to Revision C for those without the cartridge.^[13]

Revision C finally eliminated the memory leaks in Revision B.^[12] This version was built-in on later versions of the 800XLs,^[11] all XE computers, and the XEGS. Revision C was also available in a cartridge production run.^[12]

The version can be determined by typing PRINT PEEK(43234) at the READY prompt. The result is 162 for Revision A, 96 for Revision B, and 234 for Revision C.^[14]

Program editing

Atari BASIC uses a line editor, like most home computer BASICs. Unlike most BASICs, Atari BASIC will scan the program line and stop the user if he makes a typo. The tokenizer/error checking routine had bugs in it and would sometimes refuse to accept a program line if the user "crunched" it, this typically occurred if the program line contained an expression like IFA<>12THEN40.RUN.

This technique saved memory, theoretically improved performance, and had the advantage of immediately displaying problems. If the line failed to tokenize, the editor re-displays the line, highlighting the text near the error in inverse video. This can make catching syntax errors on the Atari much easier than on other editors; most BASICs will not display the errors until the program is executed.

Atari BASIC does not display descriptive errors like Commodore BASIC or some other BASIC variants, instead an error code is printed which the user must look up in a manual.

Like with Microsoft BASIC, Atari BASIC supports "crunching" of program lines in that spaces were not necessary anywhere on the program line, although when LISTed, the program text will be displayed with spaces.

Program lines can be entered by starting with a line number, which will insert a new line or amend an existing one. Lines without a line number are executed immediately. When the programmer types RUN the program executes from the lowest line number. Atari BASIC allows all commands to be executed in both modes. For instance, the LIST command can be used inside a program.

The LIST statement can be used to display either the entire BASIC program or a section of program lines by specifying the starting and ending line. These are separated with a comma rather than a hyphen like in Microsoft BASIC and Atari BASIC also does not support the "display entire program listing up to or following the specified line" feature of Microsoft BASIC (eg. LIST -50 will display everything up to line 50 and LIST 50- will display everything from line 50 onward).

Program lines ("logical lines") can be up to three screen lines ("physical lines") of 40 characters, so 120 characters total, whereas Microsoft BASIC limits the user to 80 characters per program line. The cursor can be moved freely in these lines, unlike in other BASICs where to get "up" a line one has to continuously scroll leftwards until the cursor is wrapped at the left margin (and similarly to go down when wrapping at the right margin) – though that works too, except the cursor when wrapping left to right or right to left does not move up or down a line. The OS handles tracking whether a physical line flowed to the next on the same logical line.

The cursor can be moved freely around the screen, and it will wrap on all sides. Hitting ↵ Enter sends the tokenizer the (logical) line on which the cursor sits. So, in the example pictured above (with PRUNT), all the author needs to do to fix the error is move the cursor over the U, type I (the editor only has an overwrite mode) and hit ↵ Enter. This is a common editing technique for, say, renumbering lines. Atari BASIC has no built-in renumbering command, but one can quickly learn to overwrite the numbers on a set of lines then just hit ↵ Enter repeatedly to put them back into the program.

The tokenizer

Atari BASIC uses a token structure to handle lexical processing for better performance and reduced memory size.^[15] In contrast to MS-derived BASICs, which perform this tokenization on a line-by-line basis while the program runs, in Atari BASIC this occurs when the user hits Return. The immediate syntax checking described in the "Program editing" section is a side effect of converting each line into a tokenized form before it is stored. Shepardson referred to this early-tokenizing concept as a "pre-compiling interpreter".^[16]

The tokenizer converts lines using a small buffer in memory, and the program is stored as a parse tree.^{[lower-alpha 1]} The token output buffer (addressed by a pointer at LOMEM – 80, 81₁₆) is 256 bytes, and any tokenized statement larger than the buffer generates an error (14 – line too long). The output from the tokenizer is then moved into more permanent storage in various locations in memory. A set of pointers (addresses) indicates these locations: variables are stored in the variable name table (pointed to at VNTP – 82, 83₁₆) and the values are stored in the variable value table (pointed to at VVTP – 86, 87₁₆). By indirecting the variable names in this way, a reference to a variable needs only two bytes to address its entry into the appropriate table. Strings have their own area (pointed to at STARP – 8C, 8D₁₆) as does the runtime stack (pointed to at RUNSTK – 8E, 8F₁₆) 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 – 90, 91₁₆) pointer.

Atari BASIC uses a unique way to recognize abbreviated reserved words. In Microsoft BASIC, there are a few predefined short forms like ? for PRINT and ' for REM. Atari BASIC allows any keyword to be abbreviated using a period at any point in writing it. So L. is expanded to LIST, as is LI.. 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.

In the keywords for communicating with peripherals (see the Input/Output section, below) such as OPEN # and PRINT #, the " #" is actually part of the tokenized keyword and not a separate symbol. For example, "PRINT" and "PRINT #0" are the same thing,^{[lower-alpha 2]} just presented differently.

String handling

Atari BASIC differs considerably from Microsoft-style BASICs in the way it handles strings. In the Microsoft model, originally from BASIC-PLUS, strings are variable length without a specified maximum size. In Atari BASIC, strings are arrays of characters like Fortran or C. A string is allocated a fixed size using the DIM statement; its actual length can vary at runtime from 0 to this maximum size.

Strings are not initialized with a default value like "empty" and care has to be taken not to interpret random data in RAM as part of a string. The following trick allows fast string initialization:

10 REM Initialize A$ with 1000 characters of x
20 DIM A$(1000)
30 A$="x":A$(1000)=A$:A$(2)=A$

Another difference is that Atari BASIC uses a single syntax for "slicing" up strings, where A$ refers to the entire string and A$(4,6) slices out the three characters at locations 4, 5 and 6. These replace the LEFT$, MID$, and RIGHT$ commands in Microsoft BASIC. However, this is the same syntax that one would use to access a multi-dimensional array, so there is no way to define an array of strings in Atari BASIC. Additionally, the MS MID$ is based on starting location and length, whereas the Atari slicing are start and end locations, so it is easy to create off-by-one errors. Attempting to access or enter a string greater than the allocated size of a string variable will result in the excess characters being truncated.

String handling routines written for Microsoft BASIC will require considerable modification for Atari BASIC, especially if arrays are used since each string array element refers to a character instead of a string like in Microsoft BASIC. A common workaround was to create a single large string variable that could be used as a pseudo-string array (eg. a string of 100 characters can be "divided" into five blocks of 20 characters each).

Input/Output

The Atari OS includes a subsystem for peripheral device input/output (I/O) known as CIO (Central Input/Output). Most programs can be written independently of what device they might use, as they all conform to a common interface; this was rare on home computers at the time. New device drivers could be written fairly easily that would automatically be available to Atari BASIC and any other program using the Atari OS, and existing drivers could be supplanted or augmented by new ones. A replacement E:, for example could displace the one in ROM to provide an 80-column display, or to piggy-back on it to generate a checksum whenever a line is returned (such as used to verify a type-in program listing).

Atari BASIC supports CIO access with reserved words OPEN #, CLOSE #, PRINT #, INPUT #, GET #, PUT #, NOTE #, POINT # and XIO #. There are routines in the OS for graphics fill and draw, but they are not all available as specific BASIC keywords. PLOT and DRAWTO for line drawing are supported while a command providing area fill is not. The fill feature can be used through the general CIO entry point, which is called using the BASIC command XIO.

The BASIC statement OPEN # prepares a device for I/O access:

10 REM Opens the cassette device on channel 1 for reading in BASIC
20 OPEN #1,4,0,"C:MYPROG.DAT"

Here, OPEN # means "ensure channel 1 is free," call the C: driver to prepare the device (this will set the cassette tape spools onto tension and advance the heads keeping the cassette tape player "paused". The 4 means "read" (other codes are 8 for write and 12 = 8 + 4 for "read-and-write"). The third number is auxiliary information, set to 0 when not needed. The C:MYPROG.DAT is the name of the device and the filename; the filename is ignored for the cassette driver. Physical devices can have numbers (mainly disks, printers and serial devices), so "P1:" might be the plotter and "P2:" the daisy-wheel printer, or "D1:" may be one disk drive and "D2:" and so on. If not present, 1 is assumed.

Typing "DOS" from BASIC will exit the user out to the Atari DOS command menu. Any unsaved programs will be lost. Unlike most BASICs, there is no command to display a disk directory from within BASIC and this must be done by exiting out to DOS.

Graphics and sound support

Atari BASIC has good built-in support of sound, (via the SOUND statement), graphics (GRAPHICS, SETCOLOR, COLOR, PLOT and DRAWTO), joysticks (STICK, STRIG), and paddles (PADDLE, PTRIG). There isn't a supplied FILL command to fill an arbitrary shape with pixels, but a limited operating system function exists and can be called with the XIO command.^[17]

There is no dedicated command for clearing the screen in Atari BASIC, this is usually done with PRINT CHR$(125), which PRINTs the clear screen control code (analogous to PRINT CHR$(147) in Commodore BASIC).

Advanced aspects of the hardware such as player/missile graphics (sprites), redefined character sets, scrolling, and custom graphics modes are not supported at the language level. Some of the graphics modes of the underlying hardware are also not directly supported in BASIC, notably what came to be known as "GRAPHICS 7.5", as it offered resolution halfway between GRAPHICS 7 and GRAPHICS 8. Support was added to the XL/XE operating system, accessible from BASIC as GRAPHICS 15.^[18]

Line labels

Unlike MS-derived BASICs, Atari BASIC allows numeric variables and expressions to be used to supply line numbers to GOTO and GOSUB commands. This can be used to clarify code. For instance, a subroutine that clears the screen could be written as GOSUB CLEARSCREEN, which is much easier to understand than the typical GOSUB 10000.

Loops

FOR...NEXT loops in Atari BASIC must have a variable name referenced by the NEXT statement while Microsoft BASIC did not require it. Multiple variables are not permitted with NEXT statements as they are in Microsoft BASIC (a line like NEXT X,Y is illegal in Atari BASIC).

Atari BASIC does not support ELSE clauses with IF...THEN statements (also not supported in all Microsoft BASIC implementations).

Includes

Most BASICs of the era allow the LIST command to send the source code to a printer or other device. Atari BASIC also includes the ENTER command, which reads source code from a device and merges it back into the program, as if the user had typed it in. This allows programs to be saved out in sections, reading them in using ENTER to merge or replace existing code. By carefully using blocks of line numbers that do not overlap, programmers can build libraries of subroutines and merge them into new programs as needed.

Embedded machine language

Atari BASIC can call machine code subroutines. The machine code is generally stored in strings, which can be anywhere in memory so the code needs to be position independent, or in the 256-byte Page 6 area (starting at address 1536₁₀, 600₁₆), which is not used by BASIC or the operating system. Code can be loaded into Page 6 by reading it from DATA statements.

Machine code is invoked with the USR function. The first parameter is the address of the machine code routine and the following values are parameters. For example, if the machine language code is stored in a string named ROUTINE$ it can be called with parameters as ANSWER=USR(ADR(ROUTINE$),VAR1,VAR2).

Parameters are pushed onto the hardware stack as 16-bit integers in the order specified in the USR function in low byte, high byte order. The last value pushed to the stack is a byte indicating the number of arguments. The machine language code must remove all of these values before returning via the RTS instruction. A value can be returned to the BASIC program by placing it in addresses 212₁₀ and 213₁₀ (D4₁₆ and D5₁₆) as a 16-bit integer.

Citation

Bibliography