|Latest Release:||Revision C / 1983|
|License:||Copyright © 1979 Atari Inc.|
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. This marked the first time source code was made available for a commercial language.
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.
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.
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 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,
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
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
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.
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
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.
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
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.
LOAD output the tokenized form of the BASIC program,
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
SOUND, GRAPHICS, SETCOLOR, COLOR, PLOTand
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.
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
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.
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