Atari BASIC
- For the version of BASIC bundled with the Atari ST computer series, see Atari ST BASIC.
| Atari BASIC | |
 | |
| Developer: | Shepardson Microsystems |
| Latest Release: | Revision C / 1983 |
| Release date: | 1979 |
| Platform: | Atari 400/800/XL/XE |
| Genre: | BASIC |
| Media: | cartridge |
| License: | Copyright © 1979 Atari Inc. |
ATARI BASIC was 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.[1] 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 code was essentially undocumented.
Six months and many man-hours 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, Inc. (SMI) to bid on a new custom 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 of 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 MS'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
Atari BASIC used a line-oriented editor, in common with most BASICs of the era. Unlike many BASICs, however, Atari BASIC immediately checked the line for syntax errors. 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, 8116) 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, 8316) and the values were stored in the variable value table (VVTP - 86, 8716). Strings had their own area (STARP - 8C, 8D16) as did the runtime stack (RUNSTK - 8E, 8F16). Finally, the end of BASIC memory usage was indicated by the MEMTOP (90, 9116) 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.
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 a byte for every digit in the number every time it 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.
String 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 suported CIO access with reserve 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 (eg 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 outputted 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, 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 of 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
See 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). [1]
- Wilkinson, Bill. The Atari BASIC Source Book. COMPUTE! Books (1983). ISBN 0-942386-15-9.[2]
- Wilkinson, Bill. Inside Atari DOS. COMPUTE! Books (1982). ISBN 0-942386-02-7. [3]
- De Re Atari Chapter 10: ATARI BASIC – A detailed description of the dialect and interpreter
External links
- Atari BASIC, The Good, the Bad, and the Ugly
- Atari Basic - A Self-Teaching Guide – By Bob Albrecht, LeRoy Finkel, and Jerald R. Brown, published 1979
- Atari Basic - XL Edition – By Bob Albrecht, LeRoy Finkel, and Jerald R. Brown, published 1985
- XFormer, a free Atari Emulator which needs no ROM's and other items
Notes
- ^ Wilkinson, Bill (1983). The Atari BASIC Source Book. Compute! Books. ISBN 0-942386-15-9.