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.
--- 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.
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
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, 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: http://www.atariarchives.org/APX/showinfo.php?cat=20166
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.