Applesoft BASIC

Applesoft BASIC was a dialect of Microsoft BASIC, developed by Marc McDonald and Ric Weiland, supplied with the Apple II series of computers. It superseded Integer BASIC and was the BASIC in ROM in all Apple II series computers after the original Apple II model. It was also referred to as FP (from "floating point") because of the Disk Operating System (DOS) command used to invoke it, instead of INT for Integer BASIC. Applesoft BASIC was supplied by Microsoft and its name is derived from the names of both Apple and Microsoft. Apple employees, including Randy Wigginton, adapted Microsoft's interpreter for the Apple II and added several features. The first version of Applesoft was released in 1977 only on cassette tape and lacked proper support for high-resolution graphics. Applesoft II, which was made available on cassette and disk and in the ROM of the Apple II Plus and subsequent models, was released in 1978. It is this latter version, which has some syntax differences from the first as well as support for the Apple II high-resolution graphics modes, that most people mean by the term "Applesoft."

Background

The Apple II was unveiled to the public at the West Coast Consumer Electronics Expo in April 1977 and became available for sale in June. As Apple began to get buyer feedback, one of the most common complaints about the computer was BASIC's lack of floating-point capability. Steve Wozniak had not bothered to implement it because he'd primarily been interested in writing games, a task for which integers alone were sufficient. This meant that Integer BASIC was limited to whole numbers between -32768 and 32767 and caused problems for users attempting to write business applications on it. As Steve Wozniak, the creator of Integer BASIC and the only person who understood it well enough to add floating point features, was busy with the Disk II drive and controller and with Apple DOS, Apple turned to Microsoft.

In 1976, Microsoft had developed a BASIC interpreter for the newly-released 6502 microprocessor, but as there was not yet any production computer that used it, the program merely sat on the shelf. Upon learning that Apple had a 6502 machine, they called on the phone and asked if there was any interest in purchasing BASIC. However, Steve Jobs merely told them "We appreciate the offer, but sorry we already have a BASIC."

Now in need of an upgrade, Apple contacted Microsoft and asked for help. They reportedly obtained an eight-year license for Applesoft BASIC from Microsoft for a flat fee of $21,000, renewing it in 1985 through an arrangement that gave Microsoft the rights and source code for Apple's Macintosh version of BASIC. Applesoft was designed to be backwards-compatible with Integer BASIC and used the core of Microsoft's 6502 BASIC implementation, which included using the GET command for detecting key presses and not requiring any spaces on program lines. While Applesoft was slower than Integer BASIC, it had many features that the older BASIC lacked:

• Atomic strings: A string is no longer an array of characters (as in Integer BASIC and C); it is instead a garbage-collected object (as in Scheme and Java). This allows for string arrays; DIM A$(10) resulted in a vector of eleven string variables numbered 0–10.
• Multidimensional arrays (numbers or strings)
• Single-precision floating point variables with an 8-bit exponent and a 31-bit significand and improved math capabilities, including trigonometry and logarithmic functions
• Commands for high-resolution graphics
• DATA statements, with READ and RESTORE commands, for representing numerical and string values in quantity
• CHR$, STR$, and VAL functions for converting between string and numeric types (both languages did have the ASC function)
• User-defined functions: simple one-line functions written in BASIC, with a single parameter
• Error-trapping, allowing BASIC programs to handle unexpected errors by means of a subroutine written in BASIC

Conversely, Applesoft lacked the MOD (remainder) operator that had been present in Integer BASIC.

Speed issues, features

Whereas Wozniak originally referred to his Integer BASIC as "Game BASIC," having written it so he could write a Breakout clone for his new computer, few action games were written in Applesoft BASIC for several reasons:

• In that era of carefully counting clock cycles and limited memory, it was inefficient to write speed-dependent programs that ran on a runtime interpreter.
• The use of "real" (floating-point) numbers for all math operations created unnecessary overhead and degraded performance, although this could be improved somewhat using hardware accessories such as ALF's Formula Transfer Link. A common feature of all Microsoft 6502 BASICs was the lack of double-precision variables or true integer math. BASIC normally always worked in single-precision and although a % could be placed after a variable to mark it as integer, its value would merely be converted back into single-precision, slowing down program execution and wasting memory (as each "%" required one extra byte of code). The integer variable type on Microsoft 6502 BASIC was really only designed for arrays because each element would take two bytes (versus, in the case of Applesoft, five for floating-point).
• Shape tables were a slow alternative to bitmaps and were usually even larger than their respective bitmaps in the amount of bit space they consumed. No provision existed for mixing text and graphics, except for the limited "hardware split screen" of the Apple II (four lines of text at the bottom of the screen). Many graphics programs thus contained their own bitmap character generator routines. No provision was added in the 128 kB Apple IIe and Apple IIc models' BASIC interpreters for the new machines' extra memory and double-resolution graphics, or for the Apple IIGS's 16-color mode. (Beagle Bros offered machine-language workarounds for these problems.)
• The Applesoft high-resolution graphics mode was extremely limited; a user was limited to six colors (black, green, violet, orange, blue and white), two of which did not appear in odd-numbered columns and two that did not appear in even-numbered ones. A hardware hack on the Apple IIe's 80-column character card could expand the mode to even higher resolution and open up the possibility of other colors. To its benefit, the language allowed for easy use of vector graphics, a feature unavailable in the lower-resolution graphics modes.
• The program was stored as a linked list of lines; a GOTO or GOSUB took O(n) (linear) time, and although Applesoft programs were not very long compared to today's software, on a 1 MHz 6502 this could be a significant bottleneck. Large programs were often written with the most-used subroutines at the top of the program to reduce the processing time for GOSUB calls.
• No sound support aside from a PEEK command that could be used to click the speaker, though one could also PRINT an ASCII bell character to sound the system alert beep. The language was not fast enough to produce more than a baritone buzz from repeated clicks anyway. However, music spanning several octaves could be played by repeated calls to a machine-language tone generator.

Other language features:

• Applesoft lacked some commands and functions common to most of the non-6502 Microsoft BASIC interpreters, such as:
  • INSTR (search for a substring in a given string)
  • PRINT USING (formatting numbers in printed output)
  • INKEY$ (check for a keypress without stopping the program) although a PEEK location did provide this functionality.
  • LPRINT (outputted printed content to a printer instead of the screen; Applesoft, like Integer BASIC, required the user to use a PR# command to select the slot on the motherboard where the printer card was connected, then PRINT)
• Applesoft could be extended by two means: the ampersand (&) command and the USR() function. These were two features that called machine-language routines stored in memory. Routines that needed to be fast or required direct access to arbitrary functions or data in memory could thus be called from a higher-level interpreted BASIC program. The USR() function took one numerical argument, and could be programmed to derive and return a calculated function value, to be used in a numerical expression. "&" was effectively a shorthand for CALL, with an address that would be predefined. The 1978 Applesoft II Manual essentially ignored the & command, merely listing it among reserved words in an appendix, and stating, "The ampersand ( & ) is intended for the computer's internal use only; it is not a proper APPLESOFT command. This symbol, when executed as an instruction, causes an unconditional jump to location $3F5. Use reset ctrl C return to recover", referring to the command's "hook" address. The 1982 Applesoft manual for the Apple IIe (also in an appendix) did not call it "improper", and said slightly more about it, adding to the "internal use" clause, "...and for user-supplied machine-language routines", but giving no further documentation beyond describing the hook address.
• Applesoft, like Integer BASIC before it, did not come with any built-in commands for dealing with files or disks, other than a feature to save programs to, and load programs from, cassette tape. The Apple II disk operating system, known simply as DOS, augmented the language to provide such abilities.
• Unlike in Integer BASIC, Applesoft variable names were significant only to two letters; they could be made longer, but only the first two letters would be used. For instance, "LOW" and "LOSS" would be treated as the same variable, and attempting to assign a value to "LOSS" would overwrite any value assigned to "LOW." Furthermore, because the language used tokenization, a programmer had to avoid using any consecutive letters that were also Applesoft commands or operations (one could not use the name "SCORE" for a variable because it would interpret the OR as a Boolean operator, thus rendering it SC OR E, nor could one use "BACKGROUND" because the command "GR" invoked the low-resolution graphics mode, in this case creating a syntax error).
• A deficiency in Applesoft's error-trapping with ONERR meant that the system stack would not be reset if an error-handling routine did not invoke RESUME, potentially leading to a crash. Error-handling that did not employ RESUME could avoid the problem with a CALL -3288 or (equivalent) 62248 before exiting the routine.
• Through several early models of the Apple II, Applesoft did not support the use of lowercase letters in programs, except in strings. (Thus, Applesoft could display lowercase letters, but could not recognize them as part of a program; thus, PRINT would be a valid command but print or Print would be unrecognizable and result in a syntax error.)

Early evolution

The original Applesoft, stored in RAM as documented in its Reference Manual of November 1977, had smaller interpreter code than the later Applesoft II, occupying 8½ kb of memory, instead of the 10 kb used by the later Applesoft II. Consequently, it lacked a number of command features developed for the later, mainstream version:

• All commands supporting Apple's "high resolution" graphics (9 total)
• Error-trapping with ONERR...GOTO and RESUME
• Machine-routine shorthand call "&"
• Screen-clearing HOME (a call to a system ROM routine)
• Text-output control NORMAL, INVERSE, FLASH and SPEED=
• The print-space function SPC() is listed among reserved words in the manual, but is not otherwise documented (the TAB() print-function is documented)
• Cassette tape storage of numerical arrays: STORE and RECALL
• Device response: WAIT

as well as several the later version would have, that had already been present in Apple's Integer BASIC:

• Program-line deletion: DEL
• Machine-routine access: CALL
• Peripheral device access: IN# and PR# (although IN without "#" is listed among reserved words)
• Memory range control: HIMEM: and LOMEM:
• Execution tracking for debugging: TRACE and NOTRACE
• Screen-positioning: HTAB and VTAB
• Subroutine aborting POP
• Functions PDL() to read the analog controllers, and SCRN() to read the low-resolution graphics screen (both accessing system ROM routines)

In addition, its low-resolution graphics commands had different names from their Integer BASIC/Applesoft II counterparts. All command names were of the form PLTx such that GR, COLOR=, PLOT, HLIN and VLIN were called PLTG, PLTC, PLTP, PLTH, and PLTV, respectively. The command for returning to text mode, known as TEXT in other versions, was simply TEX, and carried the proviso that it had to be the last statement in a program line.

The USR() function was also defined differently, serving as a stand-in for the absent CALL command. Its argument was not for passing a numerical value to the machine-language routine, but was instead the call-address of the routine itself; there was no "hook" to pre-define the address. All of several examples in the manual used the function only to access "system monitor ROM" routines, or short user-routines to manipulate the ROM routines. No mention was made of any code to calculate the value returned by the function itself; the function was always shown being assigned to "dummy" variables, which, without action to set a value by user-code, would just receive a meaningless value handed back to them. Even accessed ROM routines that returned values (in examples, those that provided the service of PDL() and SCRN() functions) merely had their values stored, by user-routines, in locations that were separately PEEKed in a subsequent statement.

Unlike in Integer BASIC and Applesoft II, the Boolean operators AND, OR and NOT performed bitwise operations on 16-bit integer values. If they were given values outside that range, an error resulted.

The terms OUT and PLT (and the aforementioned IN) appeared in the list of reserved words, but were not explained anywhere in the manual.

Sample code

Hello World, with inverse video and bell character, run then listed

Hello World in Applesoft BASIC could be entered as the following:

10 TEXT:HOME
20 ?"HELLO WORLD"

Multiple commands could be included on the same line of code if separated by a colon (:). The ? can be used in Applesoft BASIC (and almost all versions of Microsoft BASIC) as a shortcut for "PRINT", though spelling out the word is not only acceptable but canonical—Applesoft converted "?" in entered programs to the same token as "PRINT" (thus no memory is actually saved by using "?"), thus either would appear as "PRINT" when a program was listed. The program above would appear in a LIST command as:

10  TEXT : HOME
20  PRINT "HELLO WORLD"

This article includes text from Everything2, licensed under GFDL.

When Applesoft BASIC was initially released in mid-1978, it came on cassette tape and could be loaded into memory via the Apple II's machine language monitor. When the enhanced Apple II+ replaced the original II in 1979, Applesoft was now included in ROM and automatically started on power-up if no bootable floppy disk was present. Conversely, Integer BASIC was now removed from ROM and turned into an executable file on the DOS 3.3 disk.

Apple Business BASIC

Apple Business BASIC shipped with the Apple /// computer. Donn Denman ported Applesoft BASIC to SOS and reworked it to take advantage of the extended memory of the Apple ///. Following the trend of avoiding absolute addresses, the PEEK and POKE commands were replaced with INVOKE and PERFORM statements that loaded and executed separately-assembled code modules.

See also

• Chinese BASIC — a Chinese-localized version of Applesoft BASIC

External links

• Disassembled ROM