Atari BASIC

: "For the version of BASIC bundled with the Atari ST computer series, see Atari ST BASIC".

ATARI BASIC is a ROM resident BASIC interpreter for the Atari 8-bit family of 6502-based home computers. The interpreter originally shipped on an 8 KB cartridge; on later XL/XE model computers it was built in, and would load by default when the machines were booted without other carts in place. The complete commented source code and design specifications of ATARI BASIC had been published early as a book. [Wilkinson, Bill (1983). "The Atari BASIC Source Book". Compute! Books. ISBN 0-942386-15-9.] This marked the first time source code was made available for a commercial language.

Background

The machines that would become the Atari 8-bit family had originally been developed as a second-generation games console intended to replace the Atari 2600. Ray Kassar, the then-new president of Atari, decided to challenge Apple Computer by building a home computer instead. This meant Atari needed the BASIC programming language, then the standard language for most home computers.

Atari did what many of the other home computer companies did: they purchased the source code to the MOS 6502 version of Microsoft 8K BASIC with the intent to port it to run on the new machines. The name was something of a misnomer, however, as the 8K referred to its original size on the Intel 8080's instruction set. On the 6502's "less dense" instruction set the language was somewhat larger, over 11K. Atari had designed their ROM layout in 8 kB blocks, and paring down the code from 11 to 8 kB turned out to be a significant problem. Adding to the problem was the fact that the 6502 code supplied by Microsoft was basically undocumented.

Six months later, they were almost ready. But Atari had a deadline with the Consumer Electronics Show (CES) approaching and decided to ask for help.

Shepardson Microsystems

In September 1978 Atari asked Shepardson Microsystems (SMI) to bid on completing BASIC. Shepardson had written a number of programs for the 6502-based Apple II, and were in the midst of finishing a new advanced BASIC for the Cromemco S-100 bus machines (Cromemco 32K Structured BASIC). SMI examined the existing work and decided it was too difficult to continue paring it down; instead they recommended developing a completely new version that would be easier to fit into 8 kB. 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 result was a rather different version of BASIC, known as ATARI BASIC. In particular, the new BASIC featured string handling very different than Microsoft's version, patterned like Data General's BASIC rather than MS's version which used strings similar to those from DEC BASIC.

The contract specified a delivery date by April 6, 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. Thanks to a bonus clause in the contract, development proceeded quickly and an 8K cartridge was available just before the release of the machines. Because of the speed in getting Atari BASIC, Atari ended up taking it to CES instead of the pre-production Microsoft BASIC.

Shepardson's programmers found bugs in the first-pass review and managed to fix some of them, but Atari had already committed BASIC to manufacturing. This initial buggy version became known as Revision A.
*Revision A - First Atari BASIC cartridge. 8kB ROM.
*Revision B - Fixed all of the major bugs in Revision A, but introduced a leaking memory bug. Found built-in on the 600XL and early 800XLs. No cartridges.
*Revision C - Eliminated memory leak in Revision B. Found on later 800XLs, the 800XLF, XEGS and all XE computers. Limited cartridge production run.

Description

Program editing

s. If a problem was found it re-printed the line, highlighting the text near the error. This made catching errors on the Atari much easier, as most BASICs would not display most errors until the program was later RUN, when the new line would no longer be fresh in the author's mind.

When not running a program, Atari BASIC is in "intermediate mode", where lines can be entered (with a line-number) or immediate commands can be entered (without a line-number) that are executed immediately. Unlike most other BASICs, however, Atari BASIC allowed "any" command to be executed in either immediate mode or within a program. For instance most BASICs would allow LIST to be used only in immediate mode, while Atari BASIC would also allow it to be used inside a program.

The tokenizer

Like most BASIC interpreters, Atari BASIC used a token structure to handle lexical processing for better performance and reduced memory size. The tokenizer converted lines using a small buffer in memory as a scratchpad. The token output buffer (LOMEM - 80, 81₁₆) was 256 bytes in size, any tokenized statement that was larger than the buffer would generate an error (14 - line too long).

The output from the tokenizer was then moved into more permanent storage in various locations in memory. Variables were stored in the "variable name table" (VNTP - 82, 83₁₆) and the values were stored in the "variable value table" (VVTP - 86, 87₁₆). Strings had their own area (STARP - 8C, 8D₁₆) as did the runtime stack (RUNSTK - 8E, 8F₁₆). Finally, the end of BASIC memory usage was indicated by the MEMTOP (90, 91₁₆) pointer.

Atari BASIC used a unique system for abbreviating reserved words. Unlike MS BASIC where there were a few "pre-rolled" short forms, ? for PRINT and ' for REM for instance, Atari BASIC allowed any word to be typed in using a period, more like written English. For instance, L. would be expanded to LIST. To expand an abbreviation the tokenizer would search through its library of reserved words (see below) and stopped at the first one that matched. In order to make the abbreviations "work" properly, the list of reserved words was sorted to place the most commonly used commands closer to the top of the stack.REM was placed at the very top of the stack, and could be typed in as .. It should be noted that the MS solution used separate tokens for their (few) short forms, whereas Atari BASIC had only one token for any possible short form of PRINT (PL., PR.), and when the program was later LISTed it would always write out the "real" expanded form.

There was a single exception to this. While the official abbreviation for PRINT was PR. you could also use a ?. And this had a separate token, hence would remain in a program listing.

The expanding of tokens in the listing could cause a problem when editing a program. The Atari line input buffer was 3 screen lines (120 characters). But using abbreviations when typing in a line could result in an expanded line that was significantly longer than 120 characters. If you then wanted to edit the line, you would need to replace the expanded commands with their abbreviations, otherwise it wouldn't be accepted.

Additionally, line numbers found in commands were calculated at runtime using the same math routines as other BASIC functions. This calculation allowed routines to be referred to by variables, for instance GOTO EXITOUT, as long as one remembered to initialize EXITOUT sometime prior. This was much more useful than it might sound; tokenized variables were stored in a six-byte format only once in memory, whereas explicit line numbers took up six bytes every time they appeared in the program. If many parts of a program jumped to a single line number, which is fairly common in BASIC, replacing the explicit line numbers with variables could save considerable amounts of memory.

tring handling

Atari BASIC differs dramatically from Microsoft-style BASICs in the way it handles strings. In MS-like BASICs, strings are special types that allow for variable length and various operations. Atari BASIC has no strings of this sort, instead using arrays of characters. This allowed the programmers to remove all the special-purpose code needed for strings, replacing it with the code already being used to handle arrays of numbers.

Of course, strings are not "used" in the same fashion as arrays of numbers—at least not normally—so Atari BASIC also included a selection of commands for "slicing" up arrays. A$ referred to the entire string, whereas A$(4,6) "sliced" out the three characters 4, 5 and 6. In theory, this was a more elegant solution than MS BASIC's LEFT$, MID$, and RIGHT$ solution, as this syntax replaces three separate commands with a single one.

Although this simplification reduced the size of Atari BASIC and offered some theoretical performance benefits, it also made it much more difficult to port BASIC programs onto the Atari, arguably more so than any other difference. Users would have to scan programs for instances of LEFT$, et al., and replace them with slicing commands.

Strings in Atari BASIC were limited to one-dimensional arrays, so arrays of strings had to be implemented by the programmer. According to Bill Wilkinson, a programmer at SMI, the decision to go with strings larger than 255 characters in size made string arrays unfeasible.

Input/Output

The Atari operating system included routines for device input/output known as CIO (Central Input/Output). Atari BASIC supported CIO access with reserved words OPEN, CLOSE, PRINT, INPUT, GET, PUT, and XIO.

The I/O channels in the OS were known as "Input/Output Control Blocks" (IOCB). The BASIC OPEN command was used to open devices for I/O access.

Example: Opens the cassette device on channel 1 for reading in BASIC OPEN #1,4,0,"C:"

There were eight IOCBs in total, but a number of them were reserved. IOCB 0 was for the screen editor and couldn't be accessed from BASIC. IOCB 7 was used by built in BASIC commands for I/O (e.g. LPRINT, SAVE, LOAD, CSAVE, CLOAD). IOCB 6 was used for accessing the Graphics device in Graphics mode. Common devices were C: for the cassette, D: for disks, P: for printers and so on. SAVE and LOAD output the tokenized form of the BASIC program, LIST and ENTER the text source.

For the other CIO functions, BASIC uses the XIO statement for access. This included screen functions and serial (RS-232) functions as well as disk operations like format or deleting a file.

Example: Fill command in BASIC XIO 18,#6,12,0,"S:"

Hardware support

Other features of ATARI BASIC, in comparison to the BASICs of some competing machines at the time, were its built-in support of sound and high-resolution graphics (SOUND, GRAPHICS, SETCOLOR, COLOR, PLOT and DRAWTO) as well as peripheral units like joysticks (STICK, STRIG) and paddles (PADDLE, PTRIG). Other home computer users were often left with cryptic POKE's for such programming.

Performance

"Atari BASIC" was slower than other BASICs, sometimes by a surprising amount given the higher speeds of the underlying hardware. Most of these problems stemmed from two particularly poorly implemented bits of code.

One was a side-effect of the way that Atari BASIC re-calculated line numbers as the program was being run. This meant that a GOTO had to run a small amount of additional code in order to find the line to jump to. This would normally be a minor issue, but the same code was also used to implement the "reverse jump" at the end of FOR...NEXT loops, dramatically lowering overall performance of these very common structures.

Atari BASIC also didn't support integer variables, all numeric operations and numeric values were in floating point. Atari BASIC relied on the Atari OS's built-in floating point routines (BCD notation), which were slow. Most of this was due to a particularly poor implementation of the multiply code that was used throughout the math libraries. This was arguably not a problem of the language itself but the underlying OS, but it added to the general poor performance.

Several commercial and shareware BASICs were available on the platform that addressed some or all of these issues, resulting in performance that was 3 to 5 times faster than the Atari version. Using these BASICs, the Atari was one of the fastest home computers of its era.

Atari later sold a diskette-based version of MS BASIC, Atari Microsoft BASIC, and later managed to fit it onto a cartridge as well, but no compiler or runtime was available for redistribution.

Advanced techniques

Despite its small footprint (8k), Atari BASIC had some features that gave it some powers of more-advanced versions of BASIC.

Functions

Atari BASIC had no implementation of user functions. However, programmers could simulate user functions because of the way the GOSUB command could reference a variable. For example, a programmer could start a subroutine at line 10000 and have the program initialize a variable with that number, i.e. "TEST = 10000". When that subroutine was needed the program could load some predetermined variables then use the command "GOSUB TEST". The subroutine at line 10000 would do its operation on the predetermined variables and could put a return result in another predetermined variable.

Includes

Atari BASIC could import lines of code and merge them into a single program as long as the line numbers didn't conflict. By careful use of non-conflicting line numbers programmers could build libraries of subroutines (simulating functions as above) and merge them into new programs as needed.

Embedded machine language

String variables could hold any of the 256 characters available in the ATASCII character set and thus each byte of memory reserved for a string variable could hold any number from 0 to 255. Short 6502 machine language routines could be converted to ATASCII characters and stored as a string variable. The machine language routine could be called as a function with the USR command specifying the address of the string variable as the location in memory to execute. For example, if the machine language code was stored in a variable named ROUTINE$ it could be called and parameters passed to it with the following command: "ANSWER=USR(ADR(ROUTINE$),VAR1,VAR2)". Such routines had to be relocatable (no jump commands, only branch-type jumps) because the actual location in memory was unpredictable.

Reserved words

ABS DRAWTO NEW RESTORE VAL ADR END NEXT RETURN XIO AND ENTER NOT RND ASC EXP NOTE RUN ATN FOR ON SAVE BYE FRE OPEN SETCOLOR CLOAD GET OR SGN CHR$ GOSUB PADDLE SIN CLOG GOTO PEEK SOUND CLOSE GRAPHICS PLOT SQR CLR IF POINT STATUS COLOR INPUT POKE STEP COM INT POP STICK CONT LEN POSITION STRIG COS LET PRINT STOP CSAVE LIST PTRIG STR$ DATA LOAD PUT THEN DEG LOCATE RAD TO DIM LOG READ TRAP DOS LPRINT REM USR

ee also

*BASIC A+ – An extended BASIC for the Atari, from "Optimized Systems Software (OSS)"
*Turbo-Basic XL - Freeware BASIC compatible with "ATARI BASIC", also available with a compiler for greater speed and extra commands.

Tips

*In the XL/XE models, BASIC could be disabled by holding down the OPTION key while booting the computer. XEGS powered without the keyboard would disable BASIC.

*The program "States and Capitals" initially did not work with the 600XL computer. This was caused by the Revision B BASIC being slightly larger memory-wise than the older Revision A, causing the "States and Capitals" program to abort with an "out of memory" error. The solution was to insert the older Revision A BASIC cartridge until Atari could fix the "States and Capitals" program!

References

*"The ATARI BASIC Reference Manual". Atari Inc. (1980). [http://www.strotmann.de/twiki/bin/view/Infothek/AtBasicReferenceMa]
*Wilkinson, Bill. "The Atari BASIC Source Book". COMPUTE! Books (1983). ISBN 0-942386-15-9. [http://users.telenet.be/kim1-6502/6502/absb.html]
*Wilkinson, Bill. "Inside Atari DOS". COMPUTE! Books (1982). ISBN 0-942386-02-7. [http://www.atariarchives.org/iad/introduction.php]
* [http://www.atariarchives.org/dere/chapt10.php "De Re Atari" Chapter 10: ATARI BASIC] – A detailed description of the dialect and interpreter

External links

* [http://www3.sympatico.ca/maury/other_stuff/atari_basic.html Atari BASIC, The Good, the Bad, and the Ugly]
* [http://www.atariarchives.org/basic/ Atari Basic - A Self-Teaching Guide] – By Bob Albrecht, LeRoy Finkel, and Jerald R. Brown, published 1979
* [http://www.atariarchives.org/basicxl/ Atari Basic - XL Edition] – By Bob Albrecht, LeRoy Finkel, and Jerald R. Brown, published 1985
* [http://emulators.com/xformer.htm XFormer, a free Atari Emulator which needs no ROM's and other items]

Notes