An Atari BASIC program ready to run
Revision C / 1983
|Platform||Atari 8-bit family|
|License||Commercial proprietary software|
Atari BASIC is an interpreter for the BASIC programming language that shipped with the Atari 8-bit family of 6502-based home computers. Unlike most 8-bit BASICs, 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, for example.
The language was originally an 8 KB ROM cartridge for the first machines in the 8-bit series, the 400 and 800. Starting with the 1200XL, BASIC was built-in to the machines, but can be disabled by holding down the
OPTION key while booting. The XEGS disables BASIC if powered without the keyboard attached.
- 1 History
- 2 Description
- 3 Advanced techniques
- 4 Performance
- 5 Differences from Microsoft BASIC
- 6 Keywords
- 7 See also
- 8 Notes
- 9 References
- 10 External links
The machines that would become the Atari 8-bit family had originally been developed as second-generation video game consoles intended to replace the Atari 2600. Ray Kassar, the new president of Atari, decided to challenge Apple Computer by building a home computer instead. This meant the designs, among other changes, needed to support the BASIC programming language, then the standard language for home computers.
In 1978, Atari purchased the source code to the MOS 6502 version of Microsoft 8K BASIC. The original 8K BASIC referred to its memory footprint when compiled on the Intel 8080's instruction set. The lower code density of the 6502 expanded the code to about 9 kB. This was slightly larger than the natural 8 kB size of the Atari's ROM cartridges.
Atari felt that they also needed to expand the language to add better support for the specific hardware features of their computers, similar to what Apple had done with their Applesoft BASIC. This increased the size from 9 kB to around 11 kB. Paring down the code from 11 to 8 kB to fit in a ROM turned out to be a significant problem. Adding to the problem was the fact that the 6502 code supplied by Microsoft was undocumented.
Six months later they were almost ready with a shippable version of the interpreter. However, Atari was facing a January 1979 deadline with 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.
In September 1978 Atari asked Shepardson Microsystems to bid on completing BASIC. 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).
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. 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.
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). 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 it to CES instead. Atari Microsoft BASIC later became available as a separate product.
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. However, unknown to Shepardson, Atari had already sent the CES version to manufacturing.
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.
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. Another major problem in Revision B was a bug that added 16 bytes to the memory of the program every time it was
LOADed, eventually causing the machine to run out of memory even on the smallest programs. 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. The book provided a type-in program to patch Revision B to Revision C for those without the cartridge.
Revision C finally eliminated the memory leaks in Revision B. This version was built-in on later versions of the 800XLs, all XE computers, and the XEGS. Revision C was also available in a cartridge production run.
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.
Atari BASIC uses a line editor, like most home computer BASICs. Unlike most BASICs, Atari basic and immediately attempts to tokenize the line as soon as the ↵ Enter key is pressed, and if successful, stores only the tokenized version in memory. In contrast, most BASICs of the era stored the original source text in memory and only processed the lines when the program was
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.
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.
Program lines ("logical lines") can be up to three screen lines ("physical lines") of 40 characters, so 120 characters total. 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 always 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.
Atari BASIC uses a token structure to handle lexical processing for better performance and reduced memory size. The tokenizer converts lines using a small buffer in memory, and the program is stored as a parse tree.[a] The token output buffer (addressed by a pointer at LOMEM – 80, 8116) is 256 bytes, and any tokenized statement larger than the buffer generates an error (14 – line too long). Indeed, the syntax checking described in the "Program editing" section is a side effect of converting each line into a tokenized form before it is stored.
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, 8316) and the values are stored in the variable value table (pointed to at VVTP – 86, 8716). 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, 8D16) as does the runtime stack (pointed to at RUNSTK – 8E, 8F16) 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, 9116) pointer.
Atari BASIC uses a unique way to recognize abbreviated reserved words. In Microsoft BASIC, there are a few predefined short forms like
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:
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 #0" are the same thing,[N 1] just presented differently.
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
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.
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.
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
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"
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.
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
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.
Unlike MS-derived BASICs, Atari BASIC allowed numeric variables and operators to be used to supply line numbers to
This could 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. This offered some level of structured programming at the cost of having to define these variables at some point in the program.
Line numbers were stored in the tokenized code as 6 bytes of binary coded decimal, and thus every instance of a line number in the code required 6 bytes. Variables only required one byte per letter of the variable name. By replacing oft-used line numbers with a short variable, say
A=10000, memory could be saved. Depending on the number of instances of that number, this could be significant in the era of 32 kB accessible memory.
Most BASICs of the era allow you to use the
LIST command to write out the source code to a printer or other device. Atari BASIC also included the
ENTER command, which read source code from any device and merged it back into the program, as if the user had typed it in.
This allowed 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 (simulating functions as above) and merge them into new programs as needed.
Embedded machine language
Atari BASIC does not have a built-in assembler, but it 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 153610, 60016), which is not used by BASIC or the operating system. Code can be loaded into Page 6 by reading it from
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
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 21210 and 21310 (D416 and D516) as a 16-bit integer.
Running on original hardware, Atari BASIC is slower than other BASICs on contemporaneous equipment for the same home market, often by a large amount. On two widely used benchmarks of the era, Byte Magazine's Sieve of Eratosthenes and Creative Computings test written by David H. Ahl, the Atari was typically much slower than machines like the Apple II, and even machines like the Sinclair ZX81. In the case of Ahl's test, where the Atari was near the end of the list, it took almost seven minutes to complete the benchmark, while the ostensibly slower Commodore VIC-20 did so in just under two minutes, despite that the Atari's CPU ran twice as fast as most other 6502-based computers of era, and that the language was pre-tokenized. Most of the language's slowness stemmed from two problems.
The first is that all numeric values in Atari BASIC are stored in floating-point binary coded decimal (BCD) format, and this includes numbers that could only ever be integers, like line numbers or array indexes. Every time such a number is encountered, the interpreter has to convert it from the BCD format to an internal binary representation using routines in the operating system. Floating point math routines on the Atari were very slow, including the BCD to binary function, and this affected any program that used them. In the case of the Ahl benchmark, a single exponent operation in the code was responsible for much of the machine's poor showing.
The second is how Atari BASIC searches for line numbers as the program is run. To perform a
GOSUB, the interpreter searches through the entire program for the matching line number it needs. In Atari BASIC, the same lookup code is also used to implement
NEXT in a
NEXT loop, causing the interpreter to scan the entire program code every time through the loop. Other BASICs of the era improved loop performance by storing a pointer to the location of the
FOR, eliminating the scan. Any loops in an Atari BASIC program cause a large loss of performance relative to other BASICs.
Several BASICs for the Atari's addressed some or all of these issues, resulting in large performance gains. BASIC XL reduced the time for the Byte benchmark from 194 to 58 seconds, over three times as fast. This was accomplished by caching not only the location of FOR/NEXT loops, but also GOTO and GOSUBs using the same mechanism. Turbo-BASIC XL included a similar feature, as well as a re-written very high-performance floating-point library. On the Ahl benchmark, Atari BASIC required 405 seconds, while the exact same code in Turbo-BASIC took 41.6 seconds, almost ten times as fast. Using these BASICs, the Atari was one of the fastest home computers of its era; on the Ahl benchmark, Turbo BASIC XL's result places it far ahead of other MS BASICs running on similar machines, approaching the performance of much faster hardware like the IBM PC.
As with all Atari 8-bit family programming languages, the performance of Atari BASIC programs can be increased by as much as 50% by disabling display processing hardware (though this results in a black screen).
Differences from Microsoft BASIC
- Atari BASIC uses a different string model and does not allow arrays of strings. String concatenation is not supported.
DEF FNis not supported.
INPUTcannot include a prompt.
- There is no support for integer variables.
- All string variables and arrays must be dimensioned prior to use while Microsoft BASIC does not require this if there are ten or fewer elements.
- Variable names can be of arbitrary length.
TABfunction is not supported. To get around this limitation, the user must
POKEcertain memory locations utilized by BASIC's screen editor.
?as in Microsoft BASIC, but Atari BASIC does not tokenize it into
LIST-ing a program will still show the question mark.
|ABS||Returns the absolute value of a number|
|ADR||Returns the address in memory of a variable (mostly used for machine code routines stored in variables)|
|ASC||Returns the ATASCII value of a character|
|ATN||Returns the arctangent of a number|
|BYE||Transfers control to the internal "Self Test" program ("Memo Pad" on early models)|
|CHR$||Returns a character given an ATASCII value|
|CLOAD||Loads from cassette tape a tokenized program that was saved with CSAVE|
|CLOG||Returns the common logarithm of a number|
|CLOSE||Terminates pending transfers (flush) and closes an I/O channel|
|CLR||Clears variables' memory and program stack|
|COLOR||Chooses which logical color to draw in|
|COM||Implementation of MS Basic's COMMON was cancelled. Recognized but the code for DIM is executed instead|
|CONT||Resumes execution of a program after a STOP at the next line number (see STOP)|
|COS||Returns the cosine of a number|
|CSAVE||Saves to cassette tape a program in tokenized form with fast method (short inter-record gap on tape) (see CLOAD)|
|DATA||Stores data in lists of numeric or string values|
|DEG||Switches trigonometric functions to compute in degrees (radians is the default mode) (see RAD)|
|DIM||Defines the size of a string or array (see COM)|
|DOS||Transfers control to the Disk Operating System (DOS); if DOS was not loaded, same as BYE|
|DRAWTO||Draws a line to given coordinates|
|END||Finishes execution of the program, closes open I/O channels and stops any sound|
|ENTER||Loads and merges into memory a plain text program from an external device, usually from cassette tape or disk (see LIST)|
|FOR||Starts a for loop|
|FRE||Returns the amount of free memory in bytes|
|GET||Reads one byte from an I/O channel (see PUT)|
|GOSUB||Jumps to a subroutine at a given line in the program, placing the return address on the stack (see POP and RETURN)|
|GOTO and GO TO||Jumps to a given line in the program. GOTO can be omitted in "IF ... THEN GOTO ..."|
|GRAPHICS||Sets the graphics mode|
|IF||Executes code depending on whether a condition is true or not|
|INPUT||Retrieves a stream of text from an I/O channel; usually data from keyboard (default), cassette tape or disk|
|INT||Returns the floor of a number|
|LEN||Returns the length of a string|
|LET||Assigns a value to a variable. LET can be omitted|
|LIST||Lists (all or part of) the program to screen (default), printer, disk, cassette tape, or any other external device (see ENTER)|
|LOAD||Loads a tokenized program from an external device; usually a cassette tape or disk (see SAVE)|
|LOCATE||Stores the logical color or ATASCII character at given coordinates|
|LOG||Returns the natural logarithm of a number|
|LPRINT||Prints text to a printer device (same result can be achieved with OPEN, PRINT and CLOSE statements)|
|NEW||Erases the program and all the variables from memory; automatically executed before a LOAD or CLOAD|
|NEXT||Continues the next iteration of a FOR loop|
|NOTE||Returns the current position on an I/O channel|
|ON||A computed goto - performs a jump based on the value of an expression|
|OPEN||Initialises an I/O channel|
|PADDLE||Returns the position of a paddle controller|
|PEEK||Returns the value at an address in memory|
|PLOT||Draws a point at given coordinates|
|POINT||Sets the current position on an I/O channel|
|POKE||Sets a value at an address in memory|
|POP||Removes a subroutine return address from the stack (see GOSUB and RETURN)|
|POSITION||Sets the position of the graphics cursor|
|PRINT and ?||Writes text to an I/O channel; usually to screen (default), printer, cassette tape or disk (see LPRINT and INPUT)|
|PTRIG||Indicates whether a paddle trigger is pressed or not|
|PUT||Writes one byte to an I/O channel (see GET)|
|RAD||Switches trigonometric functions to compute in radians (see DEG)|
|READ||Reads data from a DATA statement|
|REM||Marks a comment in a program|
|RESTORE||Sets the position of where to read data from a DATA statement|
|RETURN||Ends a subroutine, effectively branching to the line immediately following the "calling" GOSUB (see GOSUB and POP)|
|RND||Returns a pseudorandom number|
|RUN||Starts execution of a program, optionally loading it from an external device (see LOAD)|
|SAVE||Writes a tokenized program to an external device; usually a cassette tape or disk (see LOAD)|
|SETCOLOR||Maps a logical color to a physical color|
|SGN||Returns the signum of a number|
|SIN||Returns the sine of a number|
|SOUND||Starts or stops playing a tone on a sound channel (see END)|
|SQR||Returns the square root of a number|
|STATUS||Returns the status of an I/O channel|
|STEP||Indicates the increment used in a FOR loop|
|STICK||Returns a joystick position|
|STOP||Stops the program, allowing later resumption (see CONT)|
|STRIG||Indicates whether a joystick trigger is pressed or not|
|STR$||Converts a number to string form|
|THEN||Indicates the statements to execute if the condition is true in an IF statement|
|TO||Indicates the limiting condition in a FOR statement|
|TRAP||Sets to jump to a given program line if an error occurs (TRAP 40000 cancels this order)|
|USR||Calls a machine code routine, optionally with parameters|
|VAL||Returns the numeric value of a string|
|XIO||General-purpose I/O routine (from "Fill screen" to "Rename file" to "Format disk" instructions)|
- BASIC A+, BASIC XL, BASIC XE – Extended BASICs for the Atari, from Optimized Systems Software
- Turbo-Basic XL - Freeware BASIC compatible with Atari BASIC, also available with a compiler for greater speed and extra commands.
- Although Wilkinson implements the parse tree as a set of tables which is really an implementation detail.
- Although 0 is actually explicitly disallowed here by BASIC assuming it to be a coding error, isn't it?
- Wilkinson, O'Brien & Laughton 1983.
- Decuir 2004.
- Wilkinson 1982, p. ix.
- Steil, Michael (20 October 2008). "Create your own Version of Microsoft BASIC for 6502". Some Assembly Required.
- Wilkinson 1982, pp. iv-v.
- Wilkinson 1982, p. v.
- Wilkinson 1982, p. x.
- Cherry, Charles (June 1987). "BASIC Bonanza". Antic.
- Wilkinson 1982, p. vi.
- "Atari BASIC Bugs". Compute!. July 1986. p. 10.
- Radcliff, Matthew (September 1995). "Revision C Converter". Antic.
- Chadwick 1985, p. 230.
- Chadwick 1985, pp. 250-251.
- Hardy, Bob (February 1993). "Keycode Getter". Atari Classics. p. 18.
- Winner, Lane (1982). "De Re Atari, Chapter 10: Atari BASIC". Atari, Inc.
- Atari BASIC Reference Manual. p. 54.
- "ATR: chpt.15: Display Lists".
- Ahl, David (November 1983). "Benchmark comparison test". Creative Computing. pp. 259–260.
- Ahl, David (January 1984). "Creative Computing Benchmark". Creative Computing. p. 12.
- Wilkinson 1985, p. 139.
- "Ahl's Benchmark?". 28 November 2007.
- The ATARI BASIC Reference Manual, Atari Inc, 1980, archived from the original on May 1, 2005
- Chadwick, Ian (1985). Mapping the Atari. Compute! Publications. ISBN 0-87455-004-1.
- Wilkinson, Bill (1982). Inside Atari DOS. Optimized Systems Software,Inc. ISBN 0-942386-02-7. Retrieved 2009-04-04.
- Decuir, Joe (December 30, 2004). 3 Generations of Game Machine Architecture (Speech). Classic Gaming Expo 2004. San Jose Convention Center.
- Wilkinson, Bill; O'Brien, Kathleen; Laughton, Paul (1983). The Atari BASIC Source Book. Compute! Books. ISBN 0-942386-15-9.
- Wilkinson, Bill (February 1985). "INSIGHT: Atari". Creative Computing. pp. 139–140.