Write up on Tech Geek History: ATARI BASIC Programming revision 3
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.
BASIC language instructions must be translated or interpreted (by the BASIC language cartridge) before the computer can understand what is to be done. Because of this extra step for translation, instructions in BASIC cannot be executed as quickly as instructions written in machine language. A program writ ten in BASIC also uses more memory space than the equivalent program written in machine language. It is possible to write most of a program in BASIC and write parts ~hat must be done quickly and efficiently in machine language. The machine language parts of the program are accessed as subroutines from the BASIC program. These subroutines can be “understood” directly by the computer, and no time is wasted for interpretation.
Although the computer can execute machine language instructions faster than it can execute BASIC instructions, it takes the programmer longer to write a machine language program. There are several disadvantages to machine language:
- Each instruction has its own numeric code which the computer understands. The programmer must either memorize these codes (Heaven for bid!) or look them up in a table each time they are used:
Hex Code A9 AO 80 Operation Performed Load the accumulator with the number following the hex code. Load the accumulator with the number contained in the memory location that follows the hex code. Store the value in the accumulator into the memory location that follows the hex code.
2. Each machine language Operation Code (Op Code) must be placed in memory in the correct sequence for the successful operation of the program.
3. When branches are made to change the sequential operation of a pro gram, the programmer must calculate and include in the instruction exactly how many memory locations must be skipped to arrive at the correct instruction.
4. The detail work involved in machine language programming is tremen dous, and the chance for programming errors is very high. Assembly language eliminates many of the drawbacks of machine language programming. Compare the following list to the disadvantages of machine language.
1. Each assembly language instruction has its own mnemonic code which is an abbreviation of the operation to be performed. Examples: Mnemonic Code LOA LOA STA Operand # 14 $1100 $11 05 Operation Performed Load the accumulator with the number 14. Load the accumulator with the value contained in memory location 1100. Store the value contained in the accumulator in memory location 110
These mnemonic codes are much easier for a programmer to work with than the numeric codes of machine language.
2. The assembly language program has line numbers similar to BASIC, and the program is automatically placed into the correct sequence of memory locations by the assembler.
- Through the use of labels (combinations of words, letters and/or numbers) branches are made to labeled instructions, and no calculations are required (the assembler does it for you). 4 INTRODUCTION 4. The assembler creates the machine language program for you from the mnemonic codes, eliminating all the time-consuming detail work. The chance for programming errors is much less than for programs con structed by hand in machine language.
COMPUTER ARCHITECTURE
We assume that you are familiar with your Atari BASIC programming language and now wish to investigate the computer’s capabilities through its own language. Programming in the machine’s language requires that you become familiar with the fundamental building blocks {or architecture} of the Atari computer. The two building blocks that you will be most concerned with are the Central Processing Unit and the computer’s memory. 6502 Central Processing Unit (CPU) Memory
Atari Building Blocks You will need an understanding of how the computer’s memory is used for storage and retrieval of information. You will get to know the binary codes used to “instruct” the computer. These codes are referred to as the instruction set of the Central Processing Unit. It sounds very complicated, but we will move slowly. One thing will be introduced at a time, and we will repeat previously discussed information at frequent intervals. The Atari 400 and 800 model computers use a Central Processing Unit {CPU} called the 6502. The 6502 is a member of a family of microprocessors developed by MOS Technology, Inc., the MCS650X product family. This CPU can process, or execute, a set of instructions {listed in Appendix A} that are identi fied by their machine language codes. The codes are composed of binary num bers that are 8 binary digits {bits} long.
Binary digits come in two denominations. A binary digit is either a 1 {one} or a 0 {zero}. A machine language code which can be recognized by the 6502 CPU is made up of 8 of these binary digits.
COMPUTER ARCHITECTURE: Binary code 10101001 10101101 10001101 Instruction Load the accumulator with the number following this instruction. Load the accumulator from the memory location that follows this instruction. Store the value that is in the accumulator in the memory location that follows this instruction. Note that each code is exactly 8 binary digits (8 bits) long.
The block of 8 bits is called a byte. The accumulator, mentioned in the instruction, is a special storage location called a register. It can hold one byte of data at a time. The accumulator (often referred to as register A) is probably the busiest register (a special temporary storage location) in the system. All operations be tween memory locations must be communicated through the accumulator or one of the other registers. The accumulator is used as a temporary storage when moving data from one memory location to another. Operations on data are performed in the accumulator.
Therefore, it is used in many of the machine language and assembly language instructions. It “accumulates” the results of successive operations on data as the instructions request. It is convenient for a programmer to think of the 6502 microprocessor as consisting of several functional elements.
The 8-bit accumulator (A) The 8-bit X Index register (X) The 8-bit Y Ind ex register (Y) The 16-bit program counter (PC) The 16-bit stack pointer (S) The 8-bit Processor Status Register (P) Figure 7-5. 6502 Functional Elements Data is transferred between memory and the processor’s internal registers over 8 bidirectional data lines called the data bus. Each bit of a data byte passes along its own line. However, the transfer of the whole byte (all 8 bits) of data takes place at the same time. Even though each bit travels along a separate path (line) of the data bus, the byte is transferred as one complete unit. Thus the structure of the 6502 microprocessor is said to be a byte-oriented structure. The 8 lines together are referred to as a bus.
An example of a pattern of 8 computer bits {a pattern with a size and shape that the computer can understand} is shown. OFF o 1 o 1 1 o 1 1 ON OFF ON ON OFF ON ON The computer would recognize this pattern as a unique number code and would respond by taking a specific action or using the number as a specific piece of data. The Central Processing Unit {CPU} of the Atari computer was originally manufactured by MOS Technology, Inc
This unit is named the 6502 microprocessor. It is called a Central Processing Unit because all instruc tions and numerical values are routed there for processing.
The 6502 microprocessor {and hence, the Atari computer}, like many other microprocessors, only understands instructions which are coded in blocks of eight binary digits, called bytes. Therefore, the biggest hurdle to machine language programming is to learn to work with information in binary form. 0 0 +- block of 8 bits or 1 byte OJ +- one bit 01 0 0 0 +- two bits {not worth much these days} +- four bits {sometimes referred to as a nybble} +- eight bits (commonly called a byte)
The Atari uses words that are eight bits in length, that is, it can digest words whose size is one byte. All instructions and numerical values must be sent to its Central Processing Unit in th is byte size.
A typical instruction, shown be low, loads the computer’s accumulator with the one byte of data following the instruction in a machine language program.
The BASIC Language Cartridge, provided with your Atari, automatically interprets BASIC language statements and decimal numbers so that the computer can understand them. Therefore, when you are programming in BASIC, you enter decimal numbers and the results are displayed as decimal numbers even though the computer is working with binary numbers. HEXADECIMAL NOTATION Machine language codes are usually given in a third number system called hexadecimal. The hexadecimal system has a base of 16 and is used as a shorthand to represent binary numbers.
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 materialized.
{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.
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.
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 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.u/docs/kb/kb-software-0005-atari-basic-overview.html
References:
https://www.atariarchives.org/dere/chapt10.php
https://www.atarimania.com/documents/The-Atari-Assembler.pdf
https://www.atariarchives.org/dere/chapt10.php
Bottom of Form