BASIC interpreter

A BASIC interpreter is an interpreter which enables users to enter and run programs in the BASIC language and was, for the first part of the microcomputer era, the default application that computers would launch. Users were expected to use the BASIC interpreter to enter in programs (often from printed listings) or to load programs from storage (often cassette tapes).

BASIC interpreters are of historical importance. Microsoft’s first product for sale was a BASIC interpreter (Altair BASIC), which paved the way for the company’s success. Before Altair BASIC, microcomputers were sold as kits that needed to be programmed in machine code (for instance, the Apple I). During the Altair period, BASIC interpreters were sold separately, becoming the first software sold to individuals rather than to organizations; Apple BASIC was Apple’s first software that it sold. After the MITS Altair 8800, microcomputers were expected to ship bundled with BASIC interpreters of their own (e.g., the Apple II, which had multiple implementations of BASIC). A backlash against the price of Microsoft’s Altair BASIC also led to early collaborative software development for Tiny BASIC implementations in general and Palo Alto Tiny BASIC specifically.

History

First implemented as a compile-and-go system rather than an interpreter, BASIC emerged as part of a wider movement towards time-sharing systems. General Electric, having worked on the Dartmouth Time Sharing System, wrote their own underlying operating system and launched an online time-sharing system known as Mark I featuring a BASIC compiler as one of its primary selling points. Other companies in the emerging field quickly followed suit. By the early 1970s, BASIC was largely universal on general-purpose mainframe computers.[1]

The HP 2000 system was designed to run time-shared BASIC as its primary task.

BASIC, as a streamlined language designed with integrated line editing in mind, was naturally suited to porting to the minicomputer market, which was emerging at the same time as the time-sharing services. These machines had very small main memory, perhaps as little as 4 kB in modern terminology and lacked the high-performance storage like hard drives that make compilers practical. In contrast, an interpreter would take fewer computing resources, at the expense of performance. In 1969 Dan Paymar and Ira Baxter wrote one of the first BASIC interpreters, for the Data General Nova.[2] By the early 1970s, BASIC had become almost universal in the minicomputer market, with the rise of Business BASIC, and competitors to BASIC like FOCAL and JOSS had been forgotten.[3]

The introduction of the first microcomputers in the mid-1970s continued the explosive growth of BASIC, which had the advantage that it was fairly well known to the young designers and computer hobbyists who took an interest in microcomputers, many of whom had seen BASIC on minis or mainframes. BASIC was one of the few languages that was both high-level enough to be usable by those without training and small enough to fit into the microcomputers of the day. In June 1974, Alfred Weaver, Michael Tindall, and Ronald Danielson of the University of Illinois at Urbana-Champaign proved it was possible to produce "A BASIC Language Interpreter for the Intel 8008 Microprocessor," in their paper of the same name, though their application was deployed to an 8008 simulator for the IBM 360/75 and required 16kB.[4]

Altair 8K BASIC on paper tape

In January 1975, the Altair 8800 was announced and sparked the microcomputer revolution. One of the first microcomputer versions of BASIC was co-written by Gates, Allen, and Monte Davidoff for their newly-formed company, Micro-Soft. This was released by MITS in punch tape format for the Altair 8800 shortly after the machine itself,[5] immediately cementing BASIC as the primary language of early microcomputers.

In March 1975, Steve Wozniak attended the first meeting of the Homebrew Computer Club and began formulating the design of his own computer. Club members were excited by Altair BASIC.[6] Wozniak concluded that his machine would have to have a BASIC of its own. At the time he was working at Hewlett Packard and used their minicomputer dialect, HP Time-Shared BASIC, as the basis for his own version. Integer BASIC was released on cassette for the Apple I, and was supplied in ROM when the Apple II shipped in the summer of 1977.[7]

Other members of the Homebrew Computer Club began circulating copies of Altair BASIC on paper tape, causing Gates to write his Open Letter to Hobbyists, complaining about this early example of software piracy. Partially in response to Gate's letter, and partially to make an even smaller BASIC that would run usefully on 4 kB machines,[lower-alpha 1] Bob Albrecht urged Dennis Allison to write their own variation of the language. How to design and implement a stripped-down version of an interpreter for the BASIC language was covered in articles by Allison in the first three quarterly issues of the People's Computer Company newsletter published in 1975 and implementations with source code published in Dr. Dobb's Journal of Tiny BASIC Calisthenics & Orthodontia: Running Light Without Overbyte. This led to a wide variety of Tiny BASICs with added features or other improvements, with well-known versions from Tom Pittman and Li-Chen Wang, both members of the Homebrew Computer Club.[8] Tiny BASIC was published openly and Wang coined the term "copyleft" to encourage others to copy his source code. Hobbyists and professionals created their own implementations, making Tiny BASIC an example of a free software project that existed before the free software movement.

Many firms developed BASIC interpreters. In 1976, SCELBI introduced SCELBAL for the 8008[9] and the University of Idaho and Lawrence Livermore Laboratory announced that they would be publishing to the public domain LLL BASIC, which included floating-point support.[10] In 1977, the Apple II and TRS-80 Model I each had two versions of BASIC, a smaller version introduced with the initial releases of the machines and an MS-based version introduced later as interest in the platforms increased.

Micro-Soft, by this time Microsoft, ported their interpreter for the MOS 6502, which quickly become one of the most popular microprocessors of the 8-bit era. When new microcomputers began to appear, such as the Commodore PET, their manufacturers included a version of the MS code. By 1978, MS BASIC was a de facto standard and practically every home computer of the 1980s included it in ROM.

A few vendors used other firms or wrote their own interpreters. In September 1978, Shepardson Microsystems was finishing Cromemco 16K Structured BASIC for the Z80-based Cromemco S-100 bus machines.[11][12] Paul Laughton and Kathleen O'Brien then created Atari BASIC[13] as essentially a pared-down version of Cromemco BASIC ported to the 6502.[14] In 1979, Texas Instruments released TI-BASIC with its TI-99/4, which would sell nearly 3 million systems when revamped as the TI-99/4A. Sinclair BASIC was developed for the ZX-80 by John Grant and Steve Vickers of Nine Tiles. In 1980, Sophie Wilson of Acorn Computers developed Atom BASIC, which she later evolved into BBC BASIC.[15][16] In 1983, Randall Hyde developed SmartBASIC for the Coleco Adam.[17]

BASIC fell from use during the later 1980s as newer machines with far greater capabilities came to market and other programming languages (such as Pascal and C) became tenable.

While IBM followed the paradigm of prior microcomputers by offering a built-in MS-BASIC for the IBM PC, it was to be PC DOS and MS-DOS that would displace BASIC interpreters as the first program users would see when running their systems.

Today, coding BASIC interpreters has become part of the retrocomputing hobby. Higher level programming languages on systems with extensive RAM have simplified implementing BASIC interpreters. For instance, line management is simple if your implementation language supports sparse matrixes, variable management is simple with associative arrays, and program execution is easy with eval functions.

Compilers vs. interpreters

The first implementation of BASIC, Dartmouth BASIC, was a compiler. Generally, compilers examine the entire program in a multi-step process and produce a second file that is directly executable in the host computer's underlying machine language. This code is mostly made up of calls to pre-written routines in the language's runtime system. This process produces a program that runs with performance similar to that of other compiled languages like FORTRAN, and the executable will normally be smaller than the source code that created it.

The main disadvantage of compilers, at least in the historical context, is that they require large amounts of temporary memory. As the compiler works, it is producing an ever-growing output file that is being held in memory along with the original source code. Additional memory for temporary lookups, notably line numbers in the case of BASIC, adds to the memory requirement. Computers of the era had very small amounts of memory; in modern terms a typical mainframe might have on the order of 64 kB. On a timesharing system, the case for most 1960s BASICs, memory was shared among many users.

In order to make a compiler work, the systems had to have some form of high-performance secondary storage, typically a hard drive. Program editing took place in a dedicated environment that wrote the user's source code to a temporary file. When the user ran the program, the editor exited and ran the compiler, which read that file and produced the executable code, and then finally the compiler would exit and run the resulting program. Splitting the task up in this fashion reduced the amount of memory needed by any one of the parts of the overall BASIC system; at any given time, only the editor, compiler or runtime had to be loaded, the rest was on storage.

While mainframes had small amounts of memory, minicomputers had even smaller amounts: 4 and 8 kB systems were typical in the 1960s. But far more importantly, minicomputers tended to lack any form of high-performance storage; most early designs used punch tape as a primary storage system, and magnetic tape systems were for the high end of the market. In this environment, the idea of storing out the source, compiling it, and then running the result would have taken minutes. It was at this point that interpreters became common.

Interpreters ultimately perform the same basic tasks as compilers, reading the source code and converting that into executable instructions calling runtime functions. The primary difference is when they perform the various tasks. In the case of a compiler, the entire source code is converted during what appears to the user as a single operation, whereas an interpreter converts and runs the source one statement at a time. As soon as the statement completes, the compiled code is cleared out of memory and the process repeats with the next statement.

The advantage of this style of operation is that the output of the "compiler" is a single statement. This dispenses with the need for some form of secondary storage while the executable is being built; even the smallest machines have room in their internal memory for a single line of code. The primary disadvantage is that you can no longer split the different parts of the overall process apart - the code needed to convert the source into machine operations has to be loaded into memory along with the runtime needed to perform it, and in most cases, the source code editor as well.

Producing a language with all of these components that can fit into a small amount of memory and still has room for user's source code is a major challenge, but it eliminates the need for secondary storage and was the only practical solution for early minicomputers and most of the history of the home computer revolution.

Development

Language design

Language design for the first interpreters often simply involved referencing other implementations. Wozniak's references for BASIC were a copy of 101 BASIC Computer Games and an HP BASIC manual. Based on these sources, Wozniak began sketching out a syntax chart for the language.[18] He did not know that HP's BASIC was very different from the DEC BASIC variety used in 101 Games. The two languages differed principally in terms of string handling and control structures: HP added GOTO ... OF ..., and BASIC-PLUS added IF-THEN with conditional statements (as opposed to just a line number to branch to), WHILE and UNTIL modifiers, and later ON ... GOTO ...).[19]

Dennis Allison, a member of the Computer Science faculty at Stanford University, instead wrote a specification for a simple version of the language.[20] Allison was urged to create the standard by Bob Albrecht of the Homebrew Computer Club, who had seen BASIC on minicomputers and felt it would be the perfect match for new machines like the Altair. Allison's proposed design only used integer arithmetic and did not support arrays or string manipulation. The goal was for the program to fit in 2 to 3 kilobytes of memory. The overall design for Tiny BASIC was published in the September 1975 issue of the People's Computer Company (PCC) newsletter, along with an 8080-version of the intermediate language runtime.

The grammar is listed below in Backus-Naur form.[21] In the listing, an asterisk ("*") denotes zero or more of the object to its left — except for the first asterisk in the definition of "term", which is the multiplication operator; parentheses group objects; and an epsilon ("ε") signifies the empty set. As is common in computer language grammar notation, the vertical bar ("|") distinguishes alternatives, as does being listed on separate lines. The symbol "CR" denotes a carriage return (usually generated by a keyboard's <key>Enter</key> key). A BREAK from the console will interrupt execution of the program.

    line ::= number statement CR | statement CR
 
    statement ::= PRINT expr-list
                  IF expression relop expression THEN statement
                  GOTO expression
                  INPUT var-list
                  LET var = expression
                  GOSUB expression
                  RETURN
                  CLEAR
                  LIST
                  RUN
                  END
 
    expr-list ::= (string|expression) (, (string|expression) )*
 
    var-list ::= var (, var)*
 
    expression ::= (+|-|ε) term ((+|-) term)*
 
    term ::= factor ((*|/) factor)*
 
    factor ::= var | number | (expression)
 
    var ::= A | B | C ... | Y | Z
 
    number ::= digit digit*
 
    digit ::= 0 | 1 | 2 | 3 | ... | 8 | 9
 
    relop ::= < (>|=|ε) | > (<|=|ε) | =

This syntax, as simple as it was, added one innovation: GOTO and GOSUB could take an expression rather than a line number, providing an assigned GOTO[22] rather than the switch statement of the ON-GOTO/GOSUB structure more typical of BASIC.

Sinclair BASIC used as its language definition the 1978 American National Standards Institute (ANSI) Minimal BASIC standard, but was itself an incomplete implementation with integer arithmetic only.[23] The ANSI standard was published after the design of the first generation of interpreters for microcomputers.

Since ROM-based BASIC interpreters often functioned as shells for loading in other applications, implementations added commands related to cassette tapes (e.g., CLOAD and CSAVE), binary disk files (e.g., BLOAD, BSAVE, and BRUN), and BASIC programs on disk (e.g., LOAD, SAVE, and CATALOG). Business BASIC implementations added commands for random-access files. (Even ROM-based BASIC interpreters were not designed or intended to be used as operating systems, and smaller microcomputers simply lacked any OS at all.[24])

First implemented in Altair BASIC, the POKE command and the PEEK and USR functions were conceived to allow direct memory access, for a variety of purposes,[25] especially for modifying special memory-mapped hardware registers to control particular functions of the computer such as the input/output peripherals. "Memory maps" (in the archaic sense of lists of memory addresses and their functions) were popular for use with PEEK and POKE.

Architecture

Common components of a BASIC interpreter:[26]

  • I/O and interrupt handling
    • Keyboard and screen
    • File input/output (if any)
  • Editing routines
    • Command line
    • Program editing and storage
  • Execution routines
    • Parsing and interpretation
    • Arithmetic package
    • Memory management
      • Symbol table
      • Garbage collection (if any)

Coding

Early microcomputers lacked development tools, and programmers either developed their code on minicomputers or by hand. For instance, Dick Whipple and John Arnold wrote Tiny BASIC Extended directly in machine code, using octal.[27] Robert Uiterwyk handwrote MICRO BASIC for the SWTPC (a 6800 system) on a legal pad.[28] Steve Wozniak wrote the code to Integer BASIC by hand, translating the assembler code instructions into their machine code equivalents and then uploading the result to his computer.[29] (Because of this, the program was very hard to change, and Wozniak was not able to modify it quickly enough for Steve Jobs, who subsequently licensed BASIC from Microsoft.[30])

Gates and Allen did not have an Altair system on which to develop and test their interpreter. However, Allen had written an Intel 8008 emulator for their previous venture, Traf-O-Data, that ran on a PDP-10 time-sharing computer. Allen adapted this emulator based on the Altair programmer guide, and they developed and tested the interpreter on Harvard's PDP-10.[31] When Harvard stopped their use of this system, Gates and Allen bought computer time from a timesharing service in Boston to complete their BASIC program debugging. Gates claimed, in his Open Letter to Hobbyists in 1976, the value of the computer time for the first year of software development was $40,000.[32]

While on final approach into the Albuquerque airport on a trip to demonstrate the interpreter, Allen realized that they had forgotten to write a bootstrap program to read the tape into memory. Writing in 8080 machine language, Allen finished the program before the plane landed. Only when they loaded the program onto an Altair and saw a prompt asking for the system's memory size did Gates and Allen know that their interpreter worked on the Altair hardware.[33][34]

One of the most popular of the many versions of Tiny BASIC was Palo Alto Tiny BASIC, or PATB for short. PATB first appeared in the May 1976 edition of Dr. Dobbs, written in a custom assembler language with non-standard mnemonics. Li-Chen Wang had coded his interpreter on a time-share system with a generic assembler.

The source code of interpreters was often open source (as with Tiny BASIC) or published later by the authors. The complete annotated source code and design specifications of Atari BASIC were published as The Atari BASIC Source Book in 1983.[35]

Virtual machines

Some BASIC interpreters were coded in the intermediate representation of a virtual machine to add a layer of abstraction and conciseness above native machine language.

Virtual Machines in Prominent BASIC Interpreters
Dialect of BASICVirtual Machine LanguageNative Machine
Tiny BASICTiny BASIC Intermediate Language (TBIL)6800
NIBLIntermediate Language (IL)SC/MP
TI BASICGraphics Programming Language (GPL)TMS9900

While virtual machines had been used in compile and go systems such as BASIC-PLUS, these were only for executing BASIC code, not parsing it.[36] Tiny BASIC, in contrast, was designed to be implemented as a virtual machine that parsed and executed (interpreted) BASIC statements. For some implementations, including Tiny BASIC Extended, 6800 Tiny BASIC,[37] and NIBL a virtual machine was used. In a virtual machine implementation, the Tiny BASIC interpreter is itself run on a virtual machine interpreter.[38] The length of the whole interpreter program was only 120 virtual machine operations, consisting of 32 commands.[39] Thus the choice of a virtual machine approach economized on memory space and implementation effort, although the BASIC programs run thereon were executed somewhat slowly. (See Tiny BASIC: Implementation in a virtual machine for an excerpt and sample commands.)

For its TI-99, Texas Instruments designed a virtual machine with a language called GPL, for "Graphic Programming Language".[40] (Although widely blamed for the slow performance of TI-BASIC, part of the problem was that the virtual machine was stored in graphics ROM, which had a slow 8-bit interface.)[41]

A misunderstanding of the Apple II ROMs led some to believe that Integer BASIC used a virtual machine, a custom assembler language contained in the Apple ROMs and known as SWEET16. SWEET16 is based on bytecodes that run within a simple 16-bit virtual machine, so memory could be addressed via indirect 16-bit pointers and 16-bit math functions calculated without the need to translate those to the underlying multi-instruction 8-bit 6502 code.[42] However, SWEET16 was not used by the core BASIC code, although it was later used to implement several utilities, such as a line renumbering routine.[43]

Program editing and storage

Program editing

Most BASIC implementations of the era acted as both the language interpreter as well as the line editor. When BASIC was running, a > command prompt was displayed where the user could enter statements.[44] This was known as "direct mode". Upon boot, a BASIC interpreter defaulted to direct mode.

Statements that were entered with leading numbers are entered into the program storage for "deferred execution",[45] either as new lines or replacing any that might have had the same number previously.[46] Statements that were entered without a line number were referred to as commands, and ran immediately. Line numbers without statements (i.e., followed by a carriage return) deleted a previously stored line. Line numbers could typically be from 1 to 32767[47][48] and line length varied (120 characters in Atari BASIC, for instance, 128 characters in Integer BASIC[49], and 255 characters in MS-BASIC).

When a program was present in memory and the user types in the RUN command, the system enters "indirect mode". In this mode, a pointer is set to point to the first line of the program, for instance, line 10. The original text for that line is then retrieved from the store and run as if the user had just typed it in direct mode. The pointer then advances to the next line and the process continues.

Different implementations offered other program-editing capabilities. Altair BASIC 8K had an EDIT command to shift into an editing mode for one line. Integer BASIC, also included the AUTO command to automatically enter line numbers at a given starting number like AUTO 100, adding 10 to the last number with every new line. AUTO 300,5 would begin numbering at line 300 by fives; 300, 305, etc. Automatic numbering was turned off by entering MAN.[50] Some interpreters offered line-renumbering commands or utilities.

Tokenizing and encoding lines

To save RAM, and speed execution, all BASIC interpreters would encode some ASCII characters of lines into other representations. For instance, line numbers were converted into integers stored as bytes or words, and keywords might be assigned single-byte tokens (for instance, storing PRINT as the byte value 145, in MS-BASIC). These representations would then be converted back to readable text when LISTing the program.

Encoding and Tokenization in Prominent BASIC Interpreters
Dialect of BASICLine NumbersKeywordsNumeric ConstantsVariable Names
Tiny BASICYesNoNoNo
Altair BASICYesYesNoNo
Integer BASICYesYesYesNo
Atari BASICYesYesYesYes

Abbreviations

As an alternative to tokenization, to save RAM, early Tiny BASIC implementations like Extended Tiny BASIC,[51] Denver Tiny BASIC[52] and MINOL[53] truncated keywords: PR for PRINT, IN for INPUT, RET for RETURN. The full, traditional keywords were not accepted.

In contrast, Palo Alto Tiny BASIC accepted traditional keywords but allowed any keyword to be abbreviated to its minimal unique string, with a trailing period. For instance, PRINT could be typed P., although PR. and other variations also worked. This system was retained in Level I BASIC for the TRS-80, which used PATB, and was also found in Atari BASIC and the BASIC of various Sharp Pocket Computers.[54]

To expand an abbreviation, the Atari BASIC tokenizer searches through its list of reserved words to find the first that matches the portion supplied. More commonly used commands occur first in the list of reserved words, with REM at the beginning (it can be typed as .). When the program is later LISTed it will typically write out the full words. MS BASICs also allowed ? as a short-form for PRINT, but did expand it when listing, treating it as an abbreviation, not a synonym.

Tokenization

Most BASIC interpreters perform at least some conversion from the original text form into various platform-specific formats. Tiny BASIC was on the simple end: it only converted the line number from its decimal format into binary. For instance, the line number "100" became a single byte value, $64, making it smaller to store in memory as well as easier to look up in machine code (initial implementations of Tiny BASIC permitted line numbers from only 1 to 255, though later implementations used double byte values and line numbers from 1 to 32767). The rest of the line was left in its original text format.[55] In fact, Allison argued that, given memory constraints, tokenization would take more code to implement than it would save.[56]

MS-BASICs went slightly further, converting the line number into a two-byte value and also converting keywords, like FOR or PRINT, into a single-byte value, the "token".[57]. In MS BASIC, for a statement such as 20 GOTO 100, the line number 20 and GOTO would be tokenized,[58] while the 100 was left in its original format and had to be re-parsed into a 16-bit integer every time the line was encountered.[59]

In contrast, Integer BASIC would convert the line 20 GOTO 100 entirely into tokens that could be immediately read and performed. Since Integer BASIC processed more of the original source code into tokens, the runtime was faster than versions that required additional runtime parsing. Numeric literals, like the value 500, were converted into their 16-bit (two-byte) binary representation, in this case, $01F4 hexadecimal. To indicate this was a value and not a keyword, a single byte between $B0 and $B9 was inserted in front of the two-byte value. String literals, like "HELLO WORLD" were instead encoded by setting the high bit of each character so that A was stored as $C1. Variable names were converted in the same fashion, with the letters encoded to have their high-bit turned on, and any digits in the name represented by the corresponding $B0 through $B9, so that the variable A5 would be encoded as $C1B5 (not reduced to a token).[60]

Carrying this even further, Atari BASIC's tokenizer parses the entire line when it is entered or modified. Numeric constants are parsed into their 40-bit internal form and then placed in the line in that format, while strings are left in their original format, but prefixed with a byte describing their length. Variables have storage set aside as they are encountered, and their name is replaced with a pointer to their storage location in memory. Shepardson referred to this early-tokenizing concept as a "pre-compiling interpreter".[61]

Tokenization at the keyboard
Main article: Sinclair BASIC § Keyword entry
Key combinations are used to enter BASIC keywords.

Some interpreters, such as the Bally Astrocade and Sinclair systems, basically had the user do the tokenization by providing combined keystrokes to enter reserved words. The most common commands need one keystroke only; for example, pressing only P at the start of a line on a Spectrum produces the full command PRINT. Less frequent commands require more complex key sequences: BEEP (for example) is keyed by pressing CAPS SHIFT plus SYMBOL SHIFT to access extended mode (later models include an EXTENDED MODE key), keeping SYMBOL SHIFT held down and pressing Z. Keywords are colour-coded on the original Spectrum keyboard to indicate which mode is required:[62]

  • White: key only
  • Red on the key itself: SYMBOL SHIFT plus the key
  • Green above the key: EXTENDED MODE followed by the key
  • Red below the key: EXTENDED MODE followed by SYMBOL SHIFT plus the key

The BASIC interpreter could quickly determine any command or function by evaluating one byte (the keyword token). Given the syntactic requirement that every line start with a command keyword (e.g., LET is not optional), pressing the one keypress for a command at the start of a line changes the editor from command mode to letter mode. Tokenization at the keyboard meant keywords were not reserved words like in other BASIC dialects, e.g., it is allowed to define a variable named PRINT and output its value with PRINT PRINT.

Line management

Most of the memory used by BASIC interpreters was to store the program listing itself. Many Tiny BASIC implementations stored lines as follows, storing lines in sequential order:

  • Binary equivalent of line number (two bytes, though one byte in MINOL)
  • ASCII source statement (variable length)
  • Carriage return

LLL BASIC instead represented lines as follows, so that they could be stored out of order:[63]

  • Binary equivalent of line number (two bytes)
  • Forward pointer to next sequential line (two bytes)
  • Length of ASCII source statement (one byte)
  • ASCII source statement (variable length)

In Tiny BASIC and Altair BASIC,[59] the interpreter would search its memory, a line at a time. Lines were stored in a block of memory. While the new line number was higher than the current line number, the pointer would be advanced to the next carriage return, to find the next line. If it were lower than the new line number, the later lines would be moved in memory to make room for the space required for the new line. If it were the same line number, and not the exact same length, subsequent lines would need to be moved forward or backward.[64]

When the user typed LIST into the command line the system would loop over the array of lines, convert the line number back to decimal format, and then print out the rest of the text in the line, decoding any tokens or other encoded representations.

Variables and data types

Variable names

Dartmouth BASIC and HP-BASIC limited variable names to at most two characters (either a single letter or a letter followed by one digit). MS-BASIC allowed variable names of a letter followed by an optional letter or digit but ignored subsequent characters: thus it was possible to inadvertently write a program with variables "LOSS" and "LOAN", which would be treated as being the same; assigning a value to "LOAN" would silently overwrite the value intended as "LOSS".

Integer BASIC was unusual in supporting any length variable name (e.g., SUM, GAMEPOINTS, PLAYER2), provided it did not contain a reserved word. [65] Keywords could not be used in variables in many early BASICs; "SCORE" would be interpreted as "SC" OR "E", where OR was a keyword.

String variables are usually distinguished in many microcomputer dialects of BASIC by having $ suffixed to their name, and values are often identified as strings by being delimited by "double quotation marks". Later implementations would use other punctuation to specify the type of a variable: A% for integer, A! for single precision, and A# for double precision.

With the exception of arrays and (in some implementations) strings, and unlike Pascal and other more structured programming languages, BASIC does not require a variable to be declared before it is referenced. Values will typically default to 0 (of the appropriate precision) or the null string.

Symbol table

Because Tiny BASIC only used 26 single-letter variables, they could be stored as an array, using a formula based on the ASCII value of the letter as the index.

Most BASICs provided for the ability to have far more than 26 variables and so needed symbol tables, which would set aside storage capacity for each variable.

In LLL BASIC, each entry in the symbol table was stored as follows:[66]

  • Variable name (byte 1: ASCII letter; byte 2: 0-9 ASCII or binary 0)
  • Forward pointer (2 bytes)
  • Value (4 bytes per element, 1 element if a scalar variable, otherwise as many elements as DIMensioned for an array)

Unlike most BASIC interpreters, UIUC BASIC had a hash function, hashing by the letter of the variable/function/array name, then conducting a linear search from there. In UIUC BASIC, a symbol table entry was:[67]

  • Flag (bit 0: entry in use; bit 6: user-defined function; bit 7: array}
  • Variable name (byte 1: ASCII letter; byte: 0-9 ASCII, " ", or "(") or function name (byte 1: ASCII letter or token 154 for FN; ASCII letter)
  • Value (5 bytes):
    • Floating-point value for a scalar
    • Array definition (last 3 bytes: upper dimension of first, second, third dimension, all assumed to start at 0)
    • User function (first 2 bytes with the address of the function; byte 3 is symbol table displacement to the dummy variable parameter in function definition).

In Atari BASIC, a set of pointers (addresses) indicates various data: variable names are stored in the variable name table (VNTP – 82, 8316) and their values are stored in the variable value table (pointed to at VVTP – 86, 8716). By indirecting the variable names in this way, a reference to a variable needs only one byte to address its entry into the appropriate table. String variables have their own area.

One BBC BASIC performance optimization included using multiple linked lists for variable lookup rather than a single long list, as in Microsoft BASIC.

Memory management

Because of the small RAM capacity of most systems originally used to run BASIC interpreters, clever memory management techniques had to be employed. Altair BASIC let users reclaim the space for trigonometry functions if those weren't being used during a session. PATB placed the start of the most common subroutines at the front of the program for use by the 1-byte RST 8080 opcode instead of the 3-byte CALL opcode. In LLL BASIC, some variables occupied the same memory locations, in cases where the different variables were used only in command mode or only at runtime.[68]

Mathematics

Integer BASIC, as its name implies, uses integers as the basis for its math package. These were stored internally as a 16-bit number, little-endian (as is the 6502). This allowed a maximum value for any calculation between −32767 and 32767. Calculations that resulted in values outside that range produced an error.[69]

Most Tiny BASIC interpreters (as well as Sinclair BASIC 4K) supported mathematics using integers only, lacking floating-point support. Using integers allowed numbers to be stored in a much more compact 16-bit format that could be more rapidly read and processed than the 32- or 40-bit floating-point formats found in most BASICs of the era. However, this limited its applicability as a general-purpose language.

Other computer number formats were sometimes used. For instance, the MINOL Tiny BASIC supported only unsigned bytes,[70] and the MICRO-BASIC Tiny BASIC used Binary Coded Decimal.[71] But floating point would come to predominate.

Floating point

The original prototype of the TRS-80 Model I ran Li-Chen Wang's public domain version of Tiny BASIC. This required only 2 KB of memory for the interpreter, leaving an average of another 2 KB free for user programs in common 4 KB memory layouts of early machines. During a demonstration to executives, Tandy Corporation's then-President Charles Tandy tried to enter his salary but was unable to do so. This was because Tiny BASIC used 2-byte signed integers with a maximum value of 32,767. The result was a request for floating-point math for the production version.[72] This led to the replacement of the existing 16-bit integer code with a version using 32-bit single-precision floating-point numbers by Tandy-employee Steve Leininger.[73]

SCELBAL used floating point routines published by Wadsworth in 1975 in Machine Language Programming for the 8008 based on a 32-bit (four byte) format for numeric calculations, with a 23-bit mantissa, 1-bit sign for the mantissa, a 7-bit exponent, and 1-bit sign for the exponent. These were organized in reverse order, with the least significant byte of the mantissa in the first byte, followed by the middle and then most significant byte with the sign in the high bit. The exponent came last, again with the sign in the high bit.[74] The manual provides well-documented assembly code for the entire math package, including entry points and usage notes.[75] 32-bit formats were common in this era, while later versions of BASIC, starting with Microsoft BASIC for the MOS 6502, generally adopted a 40-bit (five byte) format for added precision.[76]

Consultants were typically brought into handle floating-point arithmetic, a specialist domain well studied and developed for the scientific and commercial applications that had characterized mainframes. When Allen and Gates were developing Altair BASIC, fellow Harvard student Monte Davidoff convinced them to switch from integer arithmetic. They hired Davidoff to write a floating-point package that could still fit within the 4KB memory limits. Steve Wozniak turned to Roy Rankin of Stanford University for implementing the transcendental functions LOG, LOG10, and EXP;[77] however, Wozniak never finished adding floating-point support to Integer BASIC. LLL BASIC, developed at the University of Idaho by John Dickenson, Jerry Barber, and John Teeter, turned to David Mead, Hal Brand, and Frank Olken for their floating-point support.[78] For UIUC BASIC, a Datapoint 2200 floating-point package was licensed.[79]

Operators and functions

Infix operators typically included + (addition), - (subtraction), * (multiplication), / (division), MOD (remainder) and exponent using the ^ character. Binary operators included AND, OR and NOT. Binary comparisons included the standard set of =, >, <, >=, <=, and for "not equal" either <> or the HP-TSB-inspired #.[80]

Mathematical functions were sparse in Tiny BASIC implementations and Integer BASIC. In fact, a newsletter article prior to the Design Note for Tiny BASIC requested only a RND random-number function, though Palo Alto Tiny BASIC added an ABS absolute value function and SIZE, to determine the remaining available RAM. Integer BASIC added to this SGN (sign) but its RND [81] used the parameter; RND(6) returned an integer from 0 to 5.[82]. This was in contrast to MS-derived versions, where the parameter was ignored and the function always returned a value above 0 and below 1.

Arrays

The second version of Dartmouth BASIC supported matrices and matrix operations, useful for the solution of sets of simultaneous linear algebraic equations; MAT matrix operations such as assignment, addition, multiplication (of compatible matrix types) and evaluation of a determinant were supported.

In contrast, Tiny BASIC as initially designed didn’t even have any arrays, due to the tiny main memory available on early microcomputers, often 4 kB, which had to include both the interpreter and the BASIC program. But Tiny BASIC Extended, which ran in 3K of RAM, by Dick Whipple and John Arnold, added a single numeric array, the size of which did not have to be dimensioned but used RAM not used by the interpreter or the program listing. Palo Alto Tiny BASIC and Level I BASIC both adopted this approach of having a single array.

SCELBAL supported multiple arrays, but taken together these arrays could have no more than 64 items. Integer BASIC supported arrays of a single dimension, limited in size only by the available memory.[83]

Even though Microsoft and other BASICs did support matrices, matrix operations were not built in but had to be programmed explicitly on array elements.

Strings

Like the original Dartmouth BASIC, Tiny BASIC implementations typically lacked string handling. Palo Alto Tiny BASIC would allow users to enter mathematical expressions as the answer to INPUT statements; by setting variables, such as Y=1 and N=0, the user could answer “Y” or “1” at a yes/no prompt.

Two competing schools of string-handling evolved, pioneered by HP and DEC.

The simplest string handling copied HP Time-Shared BASIC and defined string variables as arrays of characters that had to be DIMensioned prior to use. Strings in HP TSB are treated as an array of characters, rather than a single multi-character object. By default, they are allocated one character in memory, and if a string of longer length is needed, they have to be declared. For instance, DIM A$[10] will set up a string that can hold a maximum of 10 characters. The maximum length of a string in TSB is 72 characters.[84]

Substrings within strings are accessed using a "slicing" notation: A$(L,R) or A$[L,R], where the substring begins with the leftmost character specified by the index L and continues to the rightmost character specified by the index R, or the A$[L] form where the substring starts at the leftmost character specified by the index L and continues to the end of the string. TSB accepts () or [] interchangeably. Array and substring indices start with 1.

This is in sharp contrast to BASICs following the DEC pattern that use functions such as LEFT$(), MID$(), and RIGHT$() to access substrings. Later adopted by ANSI BASIC, HP's notation can also be used on the destination side of a LET or INPUT statement to modify part of an existing string value, for example 100 A$[3,5]="XYZ" or 120 B$[3]="CHANGE ALL BUT FIRST TWO CHARS", which cannot be done with early implementations of LEFT$/MID$/RIGHT$.

Later versions of Dartmouth BASIC did include string variables. However, they did not use the LEFT/MID/RIGHT functions for manipulating strings, but instead used the CHANGE command which converted the string to and from equivalent ASCII values. HP included identical functionality, changing only the name to CONVERT.[85] Additionally, one could use the single-quote to convert a numeric constant to an ASCII character, allowing one to build up a string in parts; A$='23 '64 '49 "DEF" produced the string "ABCDEF", without the need for the CHR$() function.[86]

Integer BASIC, North Star BASIC[87] and Atari BASIC[88] mimicked this, which contrasted with the style found in BASICs derived from DEC, including Microsoft BASIC, where strings are an intrinsic variable-length type.[89] Having strings use a fixed amount of memory regardless of the number of characters used within them, up to a maximum of 255 characters, may have wasted memory but [90] had the advantage of avoiding the need for the garbage collection of the heap that was notoriously slow in MS BASIC or even broken in some versions.[91]

Garbage collection
Main article: Garbage collection (computer science)

Interpreters that didn’t require DIMensioning of strings instead required garbage collection, a form of automatic memory management used to reclaim memory occupied by strings that are no longer in use. On early microcomputers, with their limited memory and slow processors, BASIC garbage collection could often cause apparently random, inexplicable pauses in the midst of program operation. Some BASIC interpreters, such as Applesoft BASIC on the Apple II family, repeatedly scanned the string descriptors for the string having the highest address in order to compact it toward high memory, resulting in O(n2) performance, which could introduce minutes-long pauses in the execution of string-intensive programs.

Other functionality

Graphics and sound

Most BASIC interpreters differed widely in graphics and sound, which varied dramatically from microcomputer to microcomputer. Altair BASIC lacked any graphics or sound commands, as did the Tiny BASIC implementations, while Integer BASIC provided a rich set.

Level I BASIC for the TRS-80 had as minimal a set as possible: CLS, for CLear Screen; SET(X,Y), which lit a location on the display; RESET(X,Y), which turned it off; and POINT(X,Y), which returned 1 if a location was lit, 0 if it was not. The coordinates could be any expression and ranged from 0 to 127 for the X-axis and 0 to 47 for the Y-axis. Only black-and-white display was supported.[92]

In contrast, Integer BASIC supported color graphics, simple sound, and game controllers. Graphics mode was turned on with the GR statement and off with TEXT.[93] Drawing was modal and normally started by issuing a command to change the color, which was accomplished by setting a pseudo-variable; COLOR=12 would set the drawing color to 12, light green. One could then PLOT 10,10 to produce a single spot of that color,[94] HLIN 0,39 AT 20 to draw a horizontal line at row 20 that spanned the screen, or VLIN 5,15 AT 7 to draw a shorter vertical line down column 7.[95] A=SCRN X,Y returned the color of the screen at X,Y.[96][lower-alpha 2] The Apple II supported a game controller, a paddle controller, which had two controllers on a single connector. The position of the controller could be read using the PDL function, passing in the controller number, 0 or 1, like A=PDL(0):PRINT A, returning a value between 0 and 255.[97][lower-alpha 3] Producing sounds was accomplished by PEEKing the memory-mapped location of a simple "beeper", −16336.[lower-alpha 4]

Input/output

Integer BASIC lacked any custom input/output commands, and also lacked the DATA statement and the associated READ. To get data into and out of a program, the input/output functionality was redirected to a selected card slot with the PR#x and IN#x, which redirected output or input (respectively) to the numbered slot. From then on, data could be sent to the card using conventional PRINT commands and read from it using INPUT.[96]

Included assembler

The Integer BASIC ROMs also included a machine code monitor, "mini-assembler", and disassembler to create and debug assembly language programs.[60][99][100]

One of the unique features of BBC BASIC was the inline assembler, allowing users to write assembly language programs for the 6502 and, later, the Zilog Z80, NS32016 and ARM. The assembler was fully integrated into the BASIC interpreter and shared variables with it, which could be included between the [ and ] characters, saved via *SAVE and *LOAD, and called via the CALL or USR commands. This allowed developers to write not just assembly language code, but also BASIC code to emit assembly language, making it possible to use code-generation techniques and even write simple compilers in BASIC.

Execution

Debugging

As in most BASICs, programs were started with the RUN command, and as was common, could be directed at a particular line number like RUN 300.[101] Execution could be stopped at any time using Ctrl+C[102] and then restarted with CONTinue (CON in Integer BASIC.[103]

For step-by-step execution, the TRON or TRACE instruction could be used at the command prompt or placed within the program itself. When it was turned on, line numbers were printed out for each line the program visited. The feature could be turned off again with TROFF or NOTRACE.[104]

Unlike most BASICs, Atari BASIC scanned the just-entered program line and reported errors immediately. If an error was found, the editor re-displayed the line, highlighting the text near the error in inverse video.

In many interpreters, including Atari BASIC, errors are displayed as numeric codes, with the descriptions printed in the manual.[105] Many MS-BASIC used two-character abbreviations (e.g., SN for SYNTAX ERROR). Palo Alto Tiny BASIC and Level I BASIC used three words for error messages: "WHAT?" for syntax errors, "HOW?" for run-time errors like GOTOs to a line that didn't exist or numeric overflows, and "SORRY" for out-of-memory problems.

Parsing

While the BASIC language has a simple syntax, mathematical expressions do not, supporting different precedence rules for parentheses and different mathematical operators. To support such expressions requires implementing a recursive descent parser.[106]

This parser can be implemented in a number of ways:

  • As a virtual machine, as discussed above for many Tiny BASIC implementations. The value of the Tiny BASIC initiative was in specifying an implementation of a parser.
  • As a finite-state machine, as in UIUC BASIC IUC, where it was implemented as a control table.[107]
  • Directly in code, as in Palo Alto Tiny BASIC and Integer BASIC. In Integer BASIC, the runtime interpreter used two stacks for execution: one for statement keywords and the other for evaluating the parameters. Each statement was given two priorities: one that stated where it should occur in a multi-step operation, like a string of mathematical operations to provide order of operations, and another that suggested when evaluation should occur, for instance, calculating internal values of a parenthesis formula. When variables were encountered, their name was parsed and then looked up in the symbol table. If it was not found, it was added to the end of the list. The address of the variable's storage, perhaps freshly created, was then placed on the evaluation stack.[60]

Performance

The range of design decisions that went into programming a BASIC interpreter were often revealed through performance differences.

Line-management implementations often affected performance. Delimiting each line with a CR would make a GOTO or GOSUB to a later line would take longer, as the program would need to iterate over all the lines to find the target line number. In some implementations, such as Atari BASIC, the length of each line was recorded and stored after the line number, so that the program did not have to scan each character of the line to find the next carriage return. Many implementations would always search for a line number to branch to from the start of the program; MS-BASIC would search from the current line, if the destination line number was greater. Pittman added a patch to his 6800 Tiny BASIC to use a binary search.[108]

Working solely with integer math provides another major boost in speed. As many computer benchmarks of the era were small and often performed simple math that did not require floating-point, Integer BASIC trounced most other BASICs.[lower-alpha 5] On one of the earliest known microcomputer benchmarks, the Rugg/Feldman benchmarks, Integer BASIC was well over twice as fast as Applesoft BASIC on the same machine.[110] In the Byte Sieve, where math was less important but array access and looping performance dominated, Integer BASIC took 166 seconds while Applesoft took 200.[111] It did not appear in the Creative Computing Benchmark, which was first published in 1983, by which time Integer BASIC was no longer supplied by default.[112] The following test series, taken from both of the original Rugg/Feldman articles,[110][109] show Integer's performance relative the MS-derived BASIC on the same platform.

SystemCPUBASICTest 1Test 2Test 3Test 4Test 5Test 6Test 7
Apple II6502 @ 1 MHzInteger BASIC1.33.17.27.28.818.528.0
Apple II6502 @ 1 MHzApplesoft BASIC1.38.516.017.819.128.644.8

In theory, Atari BASIC should have run faster than contemporary BASICs based on the Microsoft pattern. Because the source code is fully tokenized when it is entered, the entire tokenization and parsing steps are already complete. Even complex mathematical operations are ready-to-run, with any numerical constants already converted to its internal 40-bit format, and variables values are looked up by address rather than having to be searched for. In spite of these theoretical advantages, in practice, Atari BASIC is slower than other home computer BASICs, often by a large amount.[113] In practice, this was not borne out. On two widely used benchmarks of the era, Byte magazine's Sieve of Eratosthenes and the Creative Computing benchmark test written by David H. Ahl, the Atari finished near the end of the list in terms of performance, and was much slower than the contemporary Apple II or Commodore PET,[114] in spite of having the same CPU but running it at roughly twice the speed of either. It finished behind relatively slow machines like the Sinclair ZX81 and even some programmable calculators.[115]

Most of the language's slowness stemmed from three problems.[113] The first is that the floating-point math routines were poorly optimized. In the Ahl benchmark, a single exponent operation, which internally loops over the slow multiplication function, was responsible for much of the machine's poor showing.[113] Second, the conversion between the internal floating-point format and the 16-bit integers used in certain parts of the language were relatively slow. Internally, these integers were used for line numbers and array indexing, along with a few other tasks, but numbers in the tokenized program were always stored in binary coded decimal (BCD) format.[116] Whenever one of these is encountered, for instance, in the line number in GOTO 100, the tokenized BCD value has to be converted to an integer, an operation that can take as long as 3500 microseconds.[117] Other BASICs avoided this delay by special-casing the conversion of numbers that could only possibly be integers, like the line number following a GOTO, switching to special ASCII-to-integer code to improve performance. Third was how Atari BASIC implemented branches and FOR loops. To perform a branch in a GOTO or GOSUB, the interpreter searches through the entire program for the matching line number it needs.[118] One minor improvement found in most Microsoft-derived BASICs is to compare the target line number to the current line number, and search forward from that point if it is greater, or start from the top if less. This improvement was missing in Atari BASIC.[113] Unlike almost all other BASICs, which would push a pointer to the location of the FOR on a stack, so when it reached the NEXT it could easily return to the FOR again in a single branch operation, Atari BASIC pushed the line number instead. This meant every time a NEXT was encountered, the system had to search through the entire program to find the corresponding FOR line. As a result, any loops in an Atari BASIC program cause a large loss of performance relative to other BASICs.[113]

gollark: PotatOS just prints random messages while it's loading.
gollark: See, Windows loading is uncool.
gollark: Ah, hi.
gollark: Anyway, you hold shift to boost in the direction you look, and it has limited anti-fall-damage capability.
gollark: It vanished mysteriously and I got refunded.

See also

Notes
  1. Microsoft BASIC left 780 bytes free for user program code and variable values on a 4k machine, and that was running a cut-down version lacking string variables and other functionality.
  2. Note the odd syntax of the SCRN, which is technically a function because it returns a value, but does not use function-like syntax which would be A=SCRN(X,Y).
  3. The manual suggests, but does not outright state, that the actual range of values is less than 0 to 255.[97]
  4. The negative number is a side-effect of the integers being stored in signed format, so any memory location over 32767 appeared as a negative value in BASIC.[98]
  5. Bill Gates complained about this, stating that it was unfair to compare Integer BASIC to a "real" BASIC like MS.[109]

References
  1. "IBM VS the World: That's How It Is". Computerworld. 5 December 1973.
  2. "Can we get a complete timeline on the IRIS Operating System for Data General Novas?". Retrieved 2020-08-05.
  3. Savetz, Kevin (April 2013). "Dave Ahl and Betsy Ah" (Interview).
  4. A BASIC Language Interpreter for the Intel 8008 Microprocessor. Department of Computer Science, University of Illinois at Urbana-Champaign (published 1974). June 1974.
  5. "We have a BASIC". New Mexico Museum of Natural History and Science. Archived from the original on November 30, 2012. Retrieved April 18, 2007.
  6. Fisk, Nathan (2009). Understanding Online Piracy. ABC-CLIO. p. 14.
  7. Hertzfeld 1985.
  8. Pittman, Tom. "you had to pay $5 up front to get it…". www.ittybittycomputers.com. Retrieved June 14, 2017.
  9. Arnold, Mark; Wadsworth, Nat (February 1976). "SCELBAL - A Higher Level Language for 8008/8080 Systems". Dr. Dobb's Journal. pp. 30–53.
  10. "Part 1 Of LLL 8080 BASIC Interpreter" (PDF).
  11. Wilkinson 1982, pp. iv–v.
  12. Cromemco 1978.
  13. Wilkinson 1982, p. ix.
  14. Wilkinson 1982, p. v.
  15. "Video processor for Acorn/BBC computer". BBC News. Retrieved 30 November 2010.
  16. "BBC Micro ignites memories of revolution". BBC News. 21 March 2008. Retrieved 30 November 2010.
  17. http://www.sacnews.net/adamcomputer/09.html
  18. Wozniak 2014.
  19. BASIC-PLUS Language Manual (PDF). Maynard, Massachusetts: Digital Equipment Corporation. 1972. p. 3-13.
  20. Allison, Dennis (July 1976). "Design notes for TINY BASIC". SIGPLAN Notices. ACM. 11 (7): 25–33. doi:10.1145/987491.987494. The ACM Special Interest Group on Programming Languages (SIGPLAN) reprinted the Tiny Basic design notes from the January 1976 Tiny BASIC Journal.
  21. Allison, Dennis (1976). "Build Your Own BASIC". Dr. Dobb's Journal. Vol. 1 no. 1. p. 9.
  22. Allison, Dennis (1976). "Quick Reference Guide for Tiny BASIC". Dr. Dobb's Journal. Vol. 1 no. 1. p. 6.
  23. "ZX80 – 8K BASIC ROM UPGRADE".
  24. "Would some BASIC interpreters for microcomputers be considered operating systems?". Retrieved August 7, 2020.
  25. Altair 8800 BASIC Reference_Manual 1975, Page 68 of PDF, "Using the PEEK function and OUT statement of 8K BASIC, the user can write a binary dump program in BASIC. Using INP and POKE it is possible to write a binary loader. PEEK and POKE can be used to store byte oriented information. When you initialize BASIC, answer the MEMORY SIZE? question with the amount of memory in your ALTAIR minus the amount of memory you wish to use as storage for byte formatted data."
  26. A BASIC Language Interpreter for the Intel 8008 Microprocessor. Department of Computer Science, University of Illinois at Urbana-Champaign (published 1974). June 1974. pp. 16–19.
  27. "TB Code Sheet". Dr. Dobb's Journal of Computer Calisthenics & Orthodontia, Running Light Without Overbyte. 1 (1). December 1975.
  28. "Robert Uiterwyk's Micro Basic".
  29. Weyhrich 2001, The [Integer] BASIC, which we shipped with the first Apple II's, was never assembled — ever. There was one handwritten copy, all handwritten, all hand-assembled..
  30. Wozniak 2018.
  31. Wallace, James; Jim Erickson (1992). Hard Drive: Bill Gates and the Making of the Microsoft Empire. John Wiley & Sons. pp. 81–83. ISBN 0-471-56886-4.
  32. Gates, Bill (January 1976). "An Open Letter To Hobbyists". Homebrew Computer Club Newsletter. Mountain View, California: Homebrew Computer Club. 2 (1): 2.
  33. "We have a BASIC". New Mexico Museum of Natural History and Science. Archived from the original on March 23, 2012. Retrieved 2007-04-18.
  34. Wallace, James; Jim Erickson (1992). Hard Drive: Bill Gates and the Making of the Microsoft Empire. John Wiley & Sons. p. 78. ISBN 0-471-56886-4.
  35. Wilkinson, O'Brien & Laughton 1983.
  36. "BASIC-PLUS inline operators, do they actually make sense?". Retrieved 2020-08-05.
  37. Veit, Holger. "Tom Pittman's 6800 tiny BASIC". Retrieved 2 May 2017.
  38. Allen, Dennis. "TINY BASIC". People's Computer Company. 4 (3).
  39. Dr. Dobb's Journal, Volume 1, Number 1, 1976, p. 12.
  40. Nouspikel, Thierry. "GPL: Graphic Programming Language". Retrieved 2 August 2020.
  41. "I grew up and learned basic on a TI-99/4a. It was a wonderful and simple time..." Hacker News. Retrieved 2 August 2020.
  42. Wozniak 1977, p. 43.
  43. Apple Programmers Aid (PDF). Apple. 1978.
  44. Raskin 1978, p. 11.
  45. Raskin 1978, p. 46.
  46. Raskin 1978, pp. 49–55.
  47. Raskin 1978, p. 48.
  48. Helmers 1978, p. 24.
  49. Raskin 1978, p. 118.
  50. Raskin 1978, pp. 65–67.
  51. "Tiny BASIC Extended". Dr. Dobb's Journal of Computer Calisthenics & Orthodontia, Running Light Without Overbyte. 1 (2). February 1976.
  52. "Denver Tiny BASIC". Dr. Dobb's Journal of Computer Calisthenics & Orthodontia, Running Light Without Overbyte. 1 (3). March 1976.
  53. "MINOL". Dr. Dobb's Journal of Computer Calisthenics & Orthodontia, Running Light Without Overbyte. 1 (4). April 1976.
  54. Rauskolb, Roger (December 1976). "Dr. Wang's Palo Alto Tiny BASIC" (PDF). Interface Age. pp. 92–108.
  55. Allison, Dennis (January 1976). "Design notes for Tiny BASIC". D. Dobb's Journal. p. 11.
  56. Allison, Dennis (1976). "Build Your Own BASIC". Dr. Dobb's Journal. Vol. 1 no. 1. p. 11.
  57. Steil, Michael (13 January 2015). "Microsoft BASIC for 6502 Original Source Code".
  58. "MBASIC tokenized file". Just Solve the File Format Problem. Retrieved 2 August 2020.
  59. Hardiman, Roger. "Altair BASIC 3.2 (4K) – Annotated Disassembly". p. 1.11. Archived from the original on 5 November 2001.
  60. Wozniak 1977, p. 42.
  61. Wilkinson, O'Brien & Laughton 1983, p. 5.
  62. Vickers 1983, p. 7–8.
  63. "Part 1 Of LLL 8080 BASIC Interpreter" (PDF).
  64. Wang, Li-Chen (May 1976). "Palo Alto Tiny BASIC". Dr. Dobb's Journal of Computer Calisthenics & Orthodontia, Running Light Without Overbyte. 1 (5): 12–25.
  65. Raskin 1978, p. 38.
  66. "Part 1 Of LLL 8080 BASIC Interpreter" (PDF).
  67. A BASIC Language Interpreter for the Intel 8008 Microprocessor. Department of Computer Science, University of Illinois at Urbana-Champaign (published 1974). June 1974. pp. 16–19.
  68. "Part 1 Of LLL 8080 BASIC Interpreter" (PDF).
  69. Raskin 1978, p. 27.
  70. "MINOL". Dr. Dobb's Journal of Computer Calisthenics & Orthodontia, Running Light Without Overbyte. 1 (4). April 1976.
  71. "Robert Uiterwyk's BASIC".
  72. Welsh, David; Welsh, Theresa (2007). Priming the Pump: How TRS-80 Enthusiasts Helped Spark the PC Revolution. p. 7.
  73. Reed, Matthew. "Level I BASIC". TRS-80.org. Retrieved 27 August 2017.
  74. Arnold & Wadsworth 1976, p. 10.1.
  75. Arnold & Wadsworth 1976, p. 10.
  76. Steil, Michael (20 October 2008). "Create your own Version of Microsoft BASIC for 6502".
  77. "Floating Point Routines for the 6502". Dr. Dobb's Journal of Computer Calisthenics & Orthodontia, Running Light Without Overbyte. 1 (7). August 1976.
  78. "Part 1 Of LLL 8080 BASIC Interpreter" (PDF).
  79. A BASIC Language Interpreter for the Intel 8008 Microprocessor. Department of Computer Science, University of Illinois at Urbana-Champaign (published 1974). June 1974. p. 20.
  80. Raskin 1978, p. 61.
  81. Raskin 1978, p. 40,120.
  82. Raskin 1978, p. 40.
  83. Raskin 1978, p. 94.
  84. Ref 1976, p. 4-3.
  85. Ref 1976, p. 4-6.
  86. Ref 1976, p. 4-2.
  87. North Star BASIC version 6 (PDF). North Star Corporation. 1977.
  88. The ATARI BASIC Reference Manual. Atari Inc. 1980.
  89. "Integer, Floating Point and String Variables". C64 Programmer's Manual. Commodore.
  90. Raskin 1978, p. 89.
  91. "Create your own Version of Microsoft BASIC".
  92. Lien, David (1977). User's Manual for Level I (First ed.). Fort Worth, TX: Tandy Corporation. pp. 105–108, 137. Retrieved 9 August 2020.
  93. Raskin 1978, p. 31.
  94. Raskin 1978, p. 32.
  95. Raskin 1978, p. 33.
  96. Raskin 1978, p. 120.
  97. Raskin 1978, p. 36.
  98. Mini 1977, p. 18.
  99. Helmers 1978, p. 18.
  100. Weyhrich 2001.
  101. Raskin 1978, p. 100.
  102. Raskin 1978, p. 15.
  103. Raskin 1978, p. 52.
  104. Raskin 1978, p. 107.
  105. Manual 1980, Appendix B.
  106. "What type of interpreter were most 8-bit BASIC implementations?". Retrieved August 9, 2020.
  107. A BASIC Language Interpreter for the Intel 8008 Microprocessor. Department of Computer Science, University of Illinois at Urbana-Champaign (published 1974). June 1974. pp. 24–36.
  108. Pittman, Tom (1981). "The First Book of Tiny BASIC Programs". Retrotechnology.com. Itty Bitty Computers. Retrieved August 5, 2020. Because TA is so large (19,703 bytes), I found that execution became excruciatingly slow, simply due to the memory scan for GOTOs, GOSUBs, and RETURNs. A simple patch to the interpreter converts it to a binary search, for about an order of magnitude speedup in execution time. The necessary changes are listed in the Appendix.
  109. Rugg, Tom; Feldman, Phil (October 1977). "BASIC timing comparisons… revised and updated". Kilobaud. pp. 20–25.
  110. Rugg, Tom; Feldman, Phil (June 1977). "BASIC Timing Comparisons… information for speed freaks". Kilobaud. pp. 66–70.
  111. Gilbreath, Jim (September 1981). "A High-Level Language Benchmark". Byte. p. 192.
  112. Ahl, David (November 1983). "Benchmark Comparison Test". Creative Computing. p. 260.
  113. Wilkinson 1985, p. 139.
  114. Ahl, David (November 1983). "Benchmark comparison test". Creative Computing. pp. 259–260.
  115. Ahl, David (January 1984). "Creative Computing Benchmark". Creative Computing. p. 12.
  116. Wilkinson, O'Brien & Laughton 1983, p. 17.
  117. Crawford 1982, p. 8.45.
  118. Winner, Lane (1982). "De Re Atari, Chapter 10: Atari BASIC". Atari, Inc.

Bibliography

Further reading

Source code and design documents, in chronological order of the release of the BASIC implementations:

This article is issued from Wikipedia. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.