Literature Review
(Beginners All-Purpose Symbolic Instruction Code) programming language was born in 1964 at the Dartmouth College, New Hampshire (USA), where it was developed by John G. Kemeney (1926-93) and Thomas E. Kurtz (Kemeney, who had been working at the Manhattan Project (1945) and afterwards (1948-49) as Albert Einstein’s assistant, met Kurtz at Dartmouth in 1956. At that time Kemeney was chairman of the Dept. of Mathematics and Kurtz just joined the faculty coming from Princeton University. The two started immediately working together to a new simplified programming language. Their efforts ended up with the Darsimco or Dartmouth Simplified Code which did not attract much interest. The Dartmouth Oversimplified Programming Experiment or DOPE which was their second experiment got even less attention. Nevertheless, they kept working on Kemeney’s idea that a new language was necessary both for teaching and learning computer science to all the world of unexperienced users. It is noteworthy to remember something about that era of computing. Computers were completely different than they are now; they were rather big, expensive and difficult to program. Moreover only a few of these machines were able to accept programs provided by the user and even in that case users needed to provide programs coded on small strips of paper or punched cards. In the latter case the whole procedure was more or less the following. A programmer with his program ready went to a punching center where, on the basis of the program, a series of cards were punched. Afterwards he would go to the computer room and place his punched card ‘deck’ on the queue. Once his punched cards reached its turn, the program was read by the computer, the instructions compiled and executed. It can be left to the imagination of the reader the case of a program with a bug. It is easy to imagine the whole approach to programming was, under those conditions, rather inefficient. Kurtz, who had become director of Dartmouth’s Kiewit Computational Center, realized all this and, strongly beliving that every student should have had computing facility available, got the idea of what he called “Time Sharing System”. This system also needed a new, simple and efficient language. Thus, while Kemeney was writing the programming language Kurtz was developing his Time Sharing System. They both recognized that the new language should meet the following specifications:
1) general purpose
2) easy of use
3) expandable
4) interactive
5) with debugging help
6) efficient
7) hardware independent
8) OS independent To obtain all this they started from FORTRAN and ALGOL, taking from them the general structure and the English words. Program lines were numbered both because as such the flow of the program was unequivocally determined, and because it helped simplify editing (rows could be deleted just writing the line number or changed by writing a new line with the same number). The final version of what was called “Dartmouth BASIC” had 14 instructions.
Limitations were present because programs should contain only one instruction per row and every row should start with a command, but the “Dartmouth BASIC” was compiled and rather fast for that time. The efforts of Kemeney and Kurtz were repaid on May 1, 1964 when, at 4:00 am, two BASIC programs ran simultaneously on the General Electric 225 mainframe at Dartmouth College.
WHAT IS ATARI BASIC?
ATARI BASIC is an interpreted language. This means programs can be run when they are entered without intermediate stages of compilation and linking. The ATARI BASIC interpreter resides in an 8K ROM cartridge in the left slot of the computer. It encompasses addresses A000 through BFFF. At least 8K of RAM is required to run BASIC.
To use ATARI BASIC effectively, you must know its strengths and weaknesses. With this information, programs can be written that make good use of the assets and features of ATARI BASIC.
Strengths of ATARI BASIC
o It supports the operating system graphics – Simple graphics calls can be made to display information on the screen.
o It supports the hardware – Such calls as SOUND, STICK and PADDLE are simple interfaces to the hardware of the computer.
o Simple assembly interface – The USR function allows easy user access to assembly language routines.
o ROM based interpreter – The BASIC interpreter is in ROM, which prevents accidental modification by the user program.
o DOS support – Specialized calls such as NOTE and POINT (DOS 2.0S) allow the user to randomly access a disk through the disk operating system.
o Peripheral support – Any peripheral recognized by the operating system can be accessed from a BASIC program.
Weaknesses of ATARI BASIC
o No support of integers – All numbers are stored as 6-byte BCD floating point numbers.
o Slow math package – Since all numbers are six bytes long, math operations become rather slow.
o No string arrays – Only one-dimensional strings can be created.
https://www.atariarchives.org/dere/chapt10.php
The very beginning in 1978, Atari’s intention was to buy a licence for a BASIC that was commonly used at the time — Microsoft BASIC — and to offer it as standard BASIC on the future Atari 400 & 800. Two slightly different versions of Microsoft BASIC were available for 6502 CPU/microprocessor, but they were poorly documented. What’s more, Atari obviously wanted to add instructions to take advantage of the Atari 400 & 800’s extraordinary graphics and sound capabilities, joysticks and paddles, and so on.
Since Microsoft wasn’t much help, Atari solicited the help of an outside company in September 1978: SMI (Shepardson Microsystems Inc), which already had a great deal of experience in developing BASIC on the 6502. Very quickly, SMI suggested dropping the idea of using Microsoft BASIC{2}{3} and proposed another version, built using Atari’s technical specifications. SMI delivered Atari BASIC (along with Atari DOS I) in December 1978.
{2} To stop reading reccurent, unpleasant comments in magazines pointing out that Atari BASIC was not an offshoot of Microsoft BASIC, Atari ended up offering its own Atari Microsoft BASIC in 1981, two years after the launch of Atari BASIC.
{3} This is how Atari advertised the Atari Microsoft BASIC and the Atari BASIC in publications around 1982. I have scrupulously respected the use of upper and lower case letters as they appear in the advertisement.
ATARI Microsoft BASIC — Now we offer the industry standard, the most powerful Microsoft BASIC yet. With simple commands, it allows you to take advantage of unique Atari hardware features such as our well-known player/missile graphics [that is, sprites]. For ease of programming, it includes n-dimensional arrays for numerics and string handling. And importantly, conversion procedures are simple.
ATARI BASIC — An affordable and easy to use BASIC that requires only 8 KiB of memory. It allows you to take advantage of the spectacular ATARI graphics and sound capabilities. And its immediate mode error messages greatly simplify debugging.
And now the question on everybody’s lips: “Why can’t Atari BASIC handle string arrays?”
Positioning Atari computers in the educational market was a real priority for Atari.
It should also be pointed out that a very strong technical constraint had to be respected for the creation of Atari BASIC: as the Atari 400 & 800 were designed as easy-to-use machines, BASIC would be offered on an 8 KiB cartridge so that it would be available immediately, when the computer was started up — and not in the form of software to be loaded from diskette or cassette tape{4}. So, the “must fit on an 8 KiB cartridge” constraint was central to the user experience. Atari at one point considered using the 2nd cartridge slot (“RIGHT CARTRIDGE”) of the Atari 800 to offer a 2nd cartridge that would complement the existing Atari BASIC in the 1st cartridge slot with an extended version, of 8 KiB + 8 KiB = 16 KiB. This 2nd cartridge never materialised.
{4} Loading an external BASIC from diskette or cassette tape complicates and slows down the boot process. Of course, there are also advantages, such as the possibility to have a BASIC on 10 KiB or more. Or the possibility to offer a new version more quickly, and at a limited cost. But it also assumes that the computer user owns a floppy disk drive or a cassette tape player/recorder.
So, to “squeeze” Atari BASIC into 8 KiB, compromises had to be made.
For instance:
• The FPP (Floating Point Package) routines module has been moved to ROM, and is part of the system OS — although it is never used by the OS.
• No classic instruction like CLS in Atari BASIC, because an equivalent exists: GR.0 abbreviation of GRAPHICS 0.
• The I/O routines as well as the graphics{5} routines are in fact implemented in the OS, and simply “called” with the expected parameters by Atari BASIC.
One oversight: the FILL function for filling a shape on the screen exists in the OS but is not available directly in Atari BASIC: you have to use the generic XIO 18 instruction.
• There are no graphical instructions for drawing circles or ovals in Atari BASIC: you have to draw them yourself point by point, with the slowness you can imagine for sine and cosine calculations in BASIC.
• More embarrassingly, there were no instructions for building and managing sprites (players-missiles in Atari’s vocabulary) in Atari BASIC, a decisive factor in the graphic superiority of Atari 400 & 800 computers over their competitors at the time: you had to use PEEK and POKE instructions to implement them.
• The Atari BASIC SOUND instruction allows you to create fairly basic sounds on 4 separate 8-bit channels with the POKEY chip, whereas you can aggregate 2 channels to obtain a 16-bit channel with POKE instructions for instance. Even worse, the SOUND instruction does not manage the duration of the sound, nor its envelope…
{5} Have you ever wondered how the same Atari BASIC, REV. A from 1979, miraculously handles the additional graphics modes that were implemented in 1982 and 1983, long AFTER that version of Atari BASIC was released? I’m talking about the additional graphics modes that appeared when CTIA was replaced by GTIA, and about the additional graphics modes that appeared with the 1200XL?
The answer is simple: Atari BASIC doesn’t know which graphics modes are actually available on the computer it is running on. More generally, Atari BASIC knows nothing of graphic modes, display lists, character sets, color registers, etc. Atari BASIC simply knows which parameters to use to call routines which, in fact, are implemented in the OS (operating system), and are therefore subject to change and update.
It may seem surprising and puzzling, but all the graphic instructions available in Atari BASIC are in fact simple instructions, nice and friendly to use, which all mask simple calls to routines that are all implemented in the OS.
The Atari BASIC editor offered enormous flexibility compared with other computers of the time.
Atari BASIC is not a compiled language.
https://www.atari800xl.eu/docs/kb/kb-software-0005-atari-basic-overview.html
The programming language which has become the de facto standard for the Atari Home Computer is the Atari 8K BASIC Cartridge, known simply as Atari BASIC. It was designed to serve the programming needs of both the computer novice and the experienced programmer who is interested in developing sophisticated applications programs. In order to meet such a wide range of programming needs, Atari BASIC was designed with some unique features. In this chapter we will introduce the concepts of high level language translators and examine the design features of Atari BASIC that allow it to satisfy such a wide variety of needs. Language Translators Atari BASIC is what is known as a high level language translator. A language, as we ordinarily think of it, is a system for communication. Most languages are constructed around a set of symbols and a set of rules for combining those symbols. The English language is a good example. The symbols are the words you see on this page. The rules that dictate how to combine these words are the patterns of English grammar. Without these patterns, communication would be very difficult, if not impossible : Out sentence this believe, of make don’t this trying if sense you to! If we don’t use the proper symbols, the results are also disastrous: @twu2 yeggopt gjsiem, keorw? In order to use a computer, we must somehow communicate with it. The only language that our machine really understands is that strange but logical sequence of ones and zeros known as machine language. In the case of the Atari, this is known as 6502 machine language. When the 6502 central processing unit (CPU) “sees” the sequence 01001000 in just the right place according to its rules of syntax, it knows that it should push the current contents the accumulator onto the CPU stack. (If you don’t know what an “accumulator” or a “CPU stack” is, don’t worry about it. For the discussion which follows, it is sufficient that you be aware of their existence.) Language translators are created to make it simpler for humans to communicate with computers. There are very few 6502 programmers, even among the most expert of them, who would recognize 01001000 as the push-the-accumulator instruction. There are more 6502 programmers, but still not very many, who would recognize the hexadecimal form of 01001000, $48, as the push-the-accumulator instruction. However, most, if not all, 6502 programmers will recognize the symbol PHA as the instruction which will cause the 6502 to push the accumulator. PHA, $48, and even 01001000, to some extent, are translations from the machine’s language into a language that humans can understand more easily. We would like to be able to communicate to the computer in symbols like PHA; but if the machine is to understand us, we need a language translator to translate these symbols into machine language. The Debug Mode of Atari’s Editor/ Assembler cartridge, for example, can be used to translate the symbols $48 and PHA to the ones and zeros that the machine understands. The debugger can also translate the machine’s ones and zeros to $48 and PHA. The assembler part of the Editor/ Assembler cartridge can be used to translate entire groups of symbols like PHA to machine code . Assemblers An assembler – for example, the one contained in the Assembler/Editor cartridge – is a program which is used to translate symbols that a human can easily understand into the ones and zeros that the machine can understand. In order for the assembler to know what we want it to do, we must communicate with it by using a set of symbols arranged according to a set of rules. The assembler is a translator, and the language it understands is 6502 assembly language. The purpose of 6502 assembly language is to aid program authors in writing machine language code . The designers of the 6502 assembly language created a set of symbols and rules that matches 6502 machine language as closely as possible. This means that the assembler retains
One disadvantages of machine language. Por instance, the process of adding two large numbers takes dozens of instructions in 6502 machine language. If human programmers had to code those dozens of instructions in the ones and zeros of machine language, there would be very few human programmers. But the process of adding two large numbers in 6502 assembly language also takes dozens of instructions. The assembly language instructions are easier for a programmer to read and remember, but they still have a one-to-one correspondence with the dozens of machine language instructions. The programming is easier, but the process remains the same. High Level Languages High level languages, like Atari BASIC, Atari PILOT, and Atari Pascal, are simpler for people to use because they more closely approximate human speech and thought patterns. However, the computer still understands only machine language. So the high level languages, while seeming simple to their users, are really much more complex in their internal operations than assembly language. Each high level language is designed to meet the specific need of some group of people. Atari Pascal is designed to implement the concept of structured programming. Atari PILOT is designed as a teaching tool. Atari BASIC is designed to serve both the needs of the novice who is just learning to program a computer and the needs of the expert programmer who is writing a sophisticated application program, but wants the program to be accessible to a large number of users. Each of these languages uses a different set of symbols and symbol-combining rules. But all these language translators were themselves written in assembly language. Language Translation Methods There are two different methods of performing language translation – compilation and interpretation. Languages which translate via interpretation are called interpreters. Languages which translate via compilation are called compilers. Interpreters examine the program source text and simulate the operations desired. Compilers translate the program source text into machine language for direct machine execution.
One The compilation method tends to produce faster, more efficient programs than does the interpretation method. However, the interpretation method can make programming easier. Problems with the Compiler Method The compiler user first creates a program source file on a disk, using a text editing program. Then the compiler carefully examines the source program text and generates the machine language as required . Finally, the machine language code is loaded and executed. While this three-step process sounds fairly simple, it has several serious” gotchas.” Language translators are very particular about their symbols and symbol-combining rules. If a symbol is misspelled, if the wrong symbol is used, or if the symbol is not in exactly the right place, the language translator will reject it. Since a compiler examines the entire program in one gulp, one misplaced symbol can prevent the compiler from understanding any of the rest of the program – even though the rest of the program does not violate any rules! The result is that the user often has to make several trips between the text editor and the compiler before the compiler successfully generates a machine language program. But this does not guarantee that the program will work. If the programmer is very good or very lucky, the program will execute perfectly the very first time. Usually, however, the user must debug the program. This nearly always involves changing the source program, usually many times. Each change in the source program sends the user back to step one: after the text editor changes the program, the compiler still has to agree that the changes are valid, and then the machine code version must be tested again. This process can be repeated dozens of times if the program is very complex. Faster Programming or Faster Programs? The interpretation method of language translation avoids many of these problems. Instead of translating the source code into machine language during a separate compiling step, the interpreter does all the translation while the program is running. This means that whenever you want to test the program you’re writing, you merely have to tell the interpreter to run it. If things don’t work right, stop the program, make a few changes, and run the program again at once. 4 Chapter One You must pay a few penalties for the convenience of using the interpreter’s interactive process, but you can generally develop a complex program much more quickly than the compiler user can. However, an interpreter is similar to a compiler in that the source code fed to the interpreter must conform to the rules of the language. The difference between a compiler and an interpreter is that a compiler has to verify the symbols and symbol-combining rules only once – when the program is compiled. No evaluation goes on when the program is running. The interpreter, however, must verify the symbols and symbol-combining rules every time it attempts to run the program. If two identical programs are written, one for a compiler and one for an interpreter, the compiled program will generally execute at least ten to twenty times faster than the interpreted program. Pre-compiling Interpreter Atari BASIC has been incorrectly called an interpreter. It does have many of the advantages and features of an interpretive language translator, but it also has some of the useful features of a compiler. A more accurate term for Atari’s BASIC Language Translator is pre-compiling interpreter. Atari BASIC, like an interpreter, has a text editor built into it. When the user enters a source line, though, the line is not stored in text form, but is translated into an intermediate code, a set of symbols called tokens. The program is stored by the editor in token form as each program line is entered. Syntax and symbol errors are weeded out at that time. Then, when you run the program, these tokens are examined and their functions simulated; but because much of the evaluation has already been done, the execution of an Atari BASIC program is faster than that of a pure interpreter. Yet Atari BASIC’s program-building process is much simpler than that of a compiler. Atari BASIC has advantages over compilers and interpreters alike . With Atari BASIC, every time you enter a line it is verified for language correctness. You don’t have to wait until compilation; you don’t even have to wait until a test run. When you type RUN you already know there are no syntax errors in your program. 5 – – The programming language which has become the de facto standard for the Atari Home Computer is the Atari 8K BASIC Cartridge, known simply as Atari BASIC. It was designed to serve the programming needs of both the computer novice and the experienced programmer who is interested in developing sophisticated applications programs. In order to meet such a wide range of programming needs, Atari BASIC was designed with some unique features. In this chapter we will introduce the concepts of high level language translators and examine the design features of Atari BASIC that allow it to satisfy such a wide variety of needs. Language Translators Atari BASIC is what is known as a high level language translator. A language, as we ordinarily think of it, is a system for communication. Most languages are constructed around a set of symbols and a set of rules for combining those symbols. The English language is a good example. The symbols are the words you see on this page. The rules that dictate how to combine these words are the patterns of English grammar. Without these patterns, communication would be very difficult, if not impossible : Out sentence this believe, of make don’t this trying if sense you to! If we don’t use the proper symbols, the results are also disastrous: @twu2 yeggopt gjsiem, keorw? In order to use a computer, we must somehow communicate with it. The only language that our machine really understands is that strange but logical sequence of ones and zeros known as machine language. In the case of the Atari, this is known as 6502 machine language. When the 6502 central processing unit (CPU) “sees” the sequence 01001000 in just the right place according to its rules of syntax, it knows that it should push the current contents of 1 Chapter One the accumulator onto the CPU stack. (If you don’t know what an “accumulator” or a “CPU stack” is, don’t worry about it. For the discussion which follows, it is sufficient that you be aware of their existence.) Language translators are created to make it simpler for humans to communicate with computers. There are very few 6502 programmers, even among the most expert of them, who would recognize 01001000 as the push-the-accumulator instruction. There are more 6502 programmers, but still not very many, who would recognize the hexadecimal form of 01001000, $48, as the push-the-accumulator instruction. However, most, if not all, 6502 programmers will recognize the symbol PHA as the instruction which will cause the 6502 to push the accumulator. PHA, $48, and even 01001000, to some extent, are translations from the machine’s language into a language that humans can understand more easily. We would like to be able to communicate to the computer in symbols like PHA; but if the machine is to understand us, we need a language translator to translate these symbols into machine language. The Debug Mode of Atari’s Editor/ Assembler cartridge, for example, can be used to translate the symbols $48 and PHA to the ones and zeros that the machine understands. The debugger can also translate the machine’s ones and zeros to $48 and PHA. The assembler part of the Editor/ Assembler cartridge can be used to translate entire groups of symbols like PHA to machine code . Assemblers An assembler – for example, the one contained in the Assembler/Editor cartridge – is a program which is used to translate symbols that a human can easily understand into the ones and zeros that the machine can understand. In order for the assembler to know what we want it to do, we must communicate with it by using a set of symbols arranged according to a set of rules. The assembler is a translator, and the language it understands is 6502 assembly language. The purpose of 6502 assembly language is to aid program authors in writing machine language code . The designers of the 6502 assembly language created a set of symbols and rules that matches 6502 machine language as closely as possible.
One disadvantages of machine language. Por instance, the process of adding two large numbers takes dozens of instructions in 6502 machine language. If human programmers had to code those dozens of instructions in the ones and zeros of machine language, there would be very few human programmers. But the process of adding two large numbers in 6502 assembly language also takes dozens of instructions. The assembly language instructions are easier for a programmer to read and remember, but they still have a one-to-one correspondence with the dozens of machine language instructions. The programming is easier, but the process remains the same. High Level Languages High level languages, like Atari BASIC, Atari PILOT, and Atari Pascal, are simpler for people to use because they more closely approximate human speech and thought patterns. However, the computer still understands only machine language. So the high level languages, while seeming simple to their users, are really much more complex in their internal operations than assembly language. Each high level language is designed to meet the specific need of some group of people. Atari Pascal is designed to implement the concept of structured programming. Atari PILOT is designed as a teaching tool. Atari BASIC is designed to serve both the needs of the novice who is just learning to program a computer and the needs of the expert programmer who is writing a sophisticated application program, but wants the program to be accessible to a large number of users. Each of these languages uses a different set of symbols and symbol-combining rules. But all these language translators were themselves written in assembly language. Language Translation Methods There are two different methods of performing language translation – compilation and interpretation. Languages which translate via interpretation are called interpreters. Languages which translate via compilation are called compilers. Interpreters examine the program source text and simulate the operations desired. Compilers translate the program source text into machine language for direct machine execution.
The compilation method tends to produce faster, more efficient programs than does the interpretation method. However, the interpretation method can make programming easier. Problems with the Compiler Method The compiler user first creates a program source file on a disk, using a text editing program. Then the compiler carefully examines the source program text and generates the machine language as required . Finally, the machine language code is loaded and executed. While this three-step process sounds fairly simple, it has several serious” gotchas.” Language translators are very particular about their symbols and symbol-combining rules. If a symbol is misspelled, if the wrong symbol is used, or if the symbol is not in exactly the right place, the language translator will reject it. Since a compiler examines the entire program in one gulp, one misplaced symbol can prevent the compiler from understanding any of the rest of the program – even though the rest of the program does not violate any rules! The result is that the user often has to make several trips between the text editor and the compiler before the compiler successfully generates a machine language program. But this does not guarantee that the program will work. If the programmer is very good or very lucky, the program will execute perfectly the very first time. Usually, however, the user must debug the program. This nearly always involves changing the source program, usually many times. Each change in the source program sends the user back to step one: after the text editor changes the program, the compiler still has to agree that the changes are valid, and then the machine code version must be tested again. This process can be repeated dozens of times if the program is very complex. Faster Programming or Faster Programs?
The interpretation method of language translation avoids many of these problems. Instead of translating the source code into machine language during a separate compiling step, the interpreter does all the translation while the program is running. This means that whenever you want to test the program you’re writing, you merely have to tell the interpreter to run it. If things don’t work right, stop the program, make a few changes, and run the program again at once. The interpreter, however, must verify the symbols and symbol-combining rules every time it attempts to run the program. If two identical programs are written, one for a compiler and one for an interpreter, the compiled program will generally execute at least ten to twenty times faster than the interpreted program. Pre-compiling Interpreter Atari BASIC has been incorrectly called an interpreter. It does have many of the advantages and features of an interpretive language translator, but it also has some of the useful features of a compiler. A more accurate term for Atari’s BASIC Language Translator is pre-compiling interpreter.
Atari BASIC, like an interpreter, has a text editor built into it. When the user enters a source line, though, the line is not stored in text form, but is translated into an intermediate code, a set of symbols called tokens. The program is stored by the editor in token form as each program line is entered. Syntax and symbol errors are weeded out at that time. Then, when you run the program, these tokens are examined and their functions simulated; but because much of the evaluation has already been done, the execution of an Atari BASIC program is faster than that of a pure interpreter. Yet Atari BASIC’s program-building process is much simpler than that of a compiler. Atari BASIC has advantages over compilers and interpreters alike . With Atari BASIC, every time you enter a line it is verified for language correctness. You don’t have to wait until compilation; you don’t even have to wait until a test run. When you type RUN you already know there are no syntax errors in your program.
https://ia601407.us.archive.org/31/items/ataribooks-the-atari-basic-source-book/theataribasicsourcebook.pdf
References:
https://www.atariarchives.org/dere/chapt10.php
https://www.atari800xl.eu/docs/kb/kb-software-0005-atari-basic-overview.html