|
For the version of BASIC bundled with the Atari ST computer series, see Atari ST BASIC. 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. 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 2nd generation games console intended to replace the Atari 2600. Ray Kassar, the new president of Atari, decided to challenge Apple Computer Corp. by building a home computer. This meant Atari needed the BASIC programming language, the standard language for many home computers. Atari did what many of the other home computer companies did: they purchased the source code to Microsoft 8K BASIC with the intent to port it to run on the new machines. This turned out to be more difficult than expected; the 8K code expanded to over 11K when ported from the Intel 8080's instruction set to the Atari's 6502 instruction set, and the maximum cartridge size was 8k of ROM. 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 BASIC (the Cromemco 32K structured BASIC). When the specifications were finalized in October of 1978, Paul Laughton and Kathleen O'Brien began work on the new Atari 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. The result was a rather different version of BASIC, known as ATARI BASIC. Unlike the MS BASIC which patterned itself after DEC BASIC, the new BASIC was patterned on Data General's BASIC and had a number of obvious differences. 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 version became known as Revision A. Description ATARI BASIC used a token structure to handle processing. After the user entered a line, BASIC would do syntax checking, then tokenize the statement. This "pre-compiling" reduced memory and enabled faster execution. Variables were stored in the variable name table (VNTP - 82, 8316) and the values were store in the variable value table (VVTP - 86, 8716). The string arrays 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. The token output buffer (LOMEM - 80, 8116) was used by BASIC for tokenizing a line of BASIC code. 256 bytes in size, any tokenized statement that was larger then the buffer would generate an error (14 - Line too long). 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 System Input/Output ATARI BASIC interacts with the system via the Central Input/Output functions (CIO). Some of the functions have a corresponding BASIC reserve word (OPEN, CLOSE, GET, PUT, etc). The Input/Output channels were known as Input/Output Control Blocks (IOCB). Although there were eight IOCBs, a number of them were reserved. IOCB 0 was for the screen editor and couldn't be accessed from BASIC (although it could from Machine Code). IOCB 7 was used by built in BASIC commands for IO (eg LPRINT, SAVE, LOAD, CSAVE, CLOAD). IOCB 6 was used for accessing the Graphics device in Graphics mode. And when using SpartaDOS, IOCB 4 and 5 were used for console input and output redirection. Example: Opens the cassette for reading in BASIC OPEN 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, String handling ATARI BASIC differs from Microsoft-style BASICs primarily in the way it handles strings. Strings were character arrays, like those in Data General-like systems. The C programming language also treats strings as character arrays. While this is in theory much faster than MS's solution, it was also much harder to port BASIC programs to the machine because ATARI BASIC didn't directly support string arrays. Finally, according to Bill Wilkinson, the decision to go with strings larger than 255 characters in size made string arrays unfeasible. On the upside they were easy to work with, using "slicing" commands. A$ referred to the entire string, whereas A$(4,6) "sliced" out the three characters, 4, 5 and 6. In general this was a more elegant solution than MS BASIC's LEFT$, MID$, and RIGHT$ solution.Sound and graphics Other features of ATARI BASIC, in comparison to the BASICs of some competing machines at the time, were its built-in support of simple sound effects and high-resolution graphics as well as peripherial units like joysticks, paddles, and floppy disk drives. Other home computer users were often left with cryptic POKE's for such programming.Program editing
Performance Atari BASIC was slower than that of other BASICs. Most of these problems stemmed from two particularly poorly implemented bits of code, one for handling loops like the FOR...NEXT that required the system to re-scan the entire program to find the starting point once again every time through the loop, and a particularly poor implementation of the multiply code that was used throughout the math libraries. Several commercial and shareware BASICs were available on the platform that addressed these issues, resulting in performance that was 3 to 5 times faster than the Atari version.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. 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. Imbedded machine language String variables could hold any of the 256 characters available in the ATASCII character set and thus each byte of memory reserverd 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 varible 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. See also Tips | |||||||||
|
| ||||||||||
 |
|
| |