Atari Basic

The BasicLanguage interpreter for Atari 8-bit computers could be purchased on cartridge. Atari XL and XE machines had BASIC built into ReadOnlyMemory.

Unique features include:

Bit-mapped graphics commands -- GRAPHICS <mode>; COLOR <number>; PLOT <column>,<row>; DRAWTO <column,row>; and you could read the screen with LOCATE <column>,<row>,<variable> All rather intuitive when compared to AppleComputer's HLINE and VLINE. Commodore computers had to do all their graphics with POKEs until later models like the C128 came out. (See CommodoreBasic.) Unfortunately, there were no built-in commands for sprites.

Computed GoTos. --- The argument to goto could be a variable.

Primitive string indexing. Instead of LEFT$(A$,3), you used A$(1,3). Instead of MID$(A$,4,2), you used A$(4,5). RIGHT$ required the use of LEN(). Instead of A$ = A$ + B$, you used A$(LEN(A$)+1) = B$.



Atari BASIC was rather wasteful when it dealt with integers. It treated all numbers as floating-point numbers, which took six bytes and was rather processor-intensive (the 6502 had no native floating point support). You could save a considerable amount of RAM by defining constants at the beginning of the program.

  1 O0=0:O1=1:O2=2:O3=3:O53248=53248:O10=10
  10 FOR x = O1 TO O10
String literals in a program could contain any byte except 34 (quote) or 155 (ATASCII CR). So you could put in-line AssemblyLanguage into your program by combining the ADR function, which returned a pointer to any string, with the USR function, which executed a system call. This was often done to load larger MachineLanguage programs or font data into a BasicLanguage program.

Atari 8-bit sprites are essentially eight- or two-pixel wide bitmaps that run the entire height of the screen. So you had to use some kind of machine language code if you wanted to move them vertically, or even to set them up without making the user wait. (A FOR loop to move the sprite through memory would take about a second to run; that's how slow AtariBasic was.)

AtariBasic was, for a long time, the only reasonable "high" level language [HighLevelLanguage] available for the 8-bit Atari line. Pilot and LogoLanguage were available but they were even slower than AtariBasic was, and AtariBasic was plenty slow (most serious programming was done in AssemblyLanguage). ForthLanguage was also available, but not often used. There was also a Forth dialect called WSFN (Which Stands For Nothing).

The 6502 was far too wimpy to host anything resembling a reasonable CeeLanguage environment. The processor only supported a 256-byte stack, for instance. I believe there was a C compiler for the Atari, but it wasn't widely used. (There was a commonly-used compression program called ARC that boasted of being compiled with Lightspeed C.)

Deep Blue C:

Incidentally, there are no curly braces in the ATASCII character set. That changed when OSS (Optimized Systems Software) release the ActionLanguage.

A system where you actually had to use digraphs to write C code.

The best thing about AtariBasic was that they had abbreviations for nigh all its commands. In fact, some programs took advantage of the abbreviations to squeeze the most into the max line length. Of course, a listing would not show the abbreviations, so if you were typing in a listing of somebody else's program, you might have to know all the abbreviations to be able to do so. Best of all, though, since the abbreviations all ended in period (.), many of the abbreviations, which only dropped a single character, took just as many characters to type as the original! (IIRC, "DIM" was abbreviated "DM.")

''Actually, if you typed a dot, it would interpret that word as the first token in its list that began with the letters leading up to it. So DM. wouldn't work, but DI. would. A period expanded to REM. It's not like they could fit another table of abbreviations in 8K of ROM, could they. And it would store the token, not the abbreviation, so the program listing would always have the full word, except in the case of the question-mark for PRINT.


EditText of this page (last edited March 6, 2008) or FindPage with title or text search