Fact-checked by Grok 2 weeks ago

Integer BASIC

Integer BASIC is a of the BASIC programming language, developed by and implemented as an interpreter in for the and original computers. It was designed specifically for the 6502 microprocessor, supporting signed 16-bit integer arithmetic exclusively, without floating-point capabilities, which led to its name and made it suitable for games and integer-based engineering tasks. Released in June 1977 with the , it served as the system's built-in programming environment, accessible via a symbolized by a right-facing arrow (>). Wozniak created Integer BASIC during evenings while employed at , aiming to produce the first for the 6502 to accompany his custom hardware designs. He initially envisioned floating-point support but simplified it to integers for quicker development, dubbing it "Game BASIC" internally, and completed the core engine in about two months using a modular syntax table and stack-based parsing. The language included innovative features such as color graphics commands tailored for the , a built-in mini-assembler for direct 6502 integration, and a interpreter for executing 16-bit efficiently. These elements allowed users to create interactive programs, utilities, and games, with early software like and ColorMath distributed on cassette tapes. Despite its strengths, Integer BASIC had notable limitations, including rudimentary string handling that deviated from standard conventions and no support for floating-point math, which restricted its use in scientific or business applications requiring decimals. It lacked a comprehensive , relying instead on a basic , though enthusiasts dissected its internals through publications like Call-A.P.P.L.E. magazine. By 1978, growing user demand for advanced features prompted Apple to license Microsoft's floating-point , leading to Applesoft BASIC's introduction as Applesoft I in January 1978 and Applesoft II later that year, which offered high-resolution and better compatibility. Integer BASIC was phased out from + ROMs to accommodate Applesoft but remained accessible via cards or commands ( for Integer mode, for Applesoft), preserving compatibility with thousands of early programs until at least 1979. Historically, Integer BASIC played a pivotal role in the Apple II's success, empowering a generation of hobbyists and educators to program directly on the machine and fostering the personal computing revolution. Its efficient, compact design—fitting into just 8 KB of —demonstrated Wozniak's ingenuity and influenced subsequent language implementations, while its loyal user base highlighted the value of accessible, integer-focused programming in the late .

History

Development

Integer BASIC was developed by , beginning in late 1975 and completed by early 1976, specifically for the computer, marking his effort to create the first for the 6502 . Initially referred to as "Game BASIC," the project stemmed from Wozniak's desire to provide immediate programming accessibility on a low-cost , drawing on his evenings spent coding while employed at . Lacking prior experience with , Wozniak self-taught the language's structure by studying an HP 9830 manual, the developed by and for the , and the book 101 BASIC Computer Games by David Ahl, which influenced the inclusion of game-oriented features. The interpreter was entirely hand-assembled in 6502 , with Wozniak manually translating instructions into without the aid of a high-level assembler, a process he repeated frequently to test and refine the code on prototype hardware. This labor-intensive approach took approximately two months to complete the core engine, featuring a with a syntax table storing commands as text strings (such as "PRINT" represented by its five letters) and separate routines for operators and expressions. Wozniak sketched syntax charts and employed stacks for nouns and verbs to parse programs efficiently, enabling the interpreter to fit within the Apple I's constrained environment. Central to the were goals of speed and simplicity for and educational or applications on hardware limited to 4 of , leading Wozniak to prioritize integer arithmetic over more complex floating-point operations. By focusing on 16-bit signed integers ranging from -32768 to 32767, the interpreter avoided the space and time demands of floating-point support, which Wozniak estimated would have delayed development by weeks; this choice aligned with the logical, non-decimal needs of simulations and arcade-style like . The resulting compact implementation required users to supply at least 4 of via external chips, emphasizing accessibility for hobbyists on a budget.

Release and Adoption

Integer BASIC was first distributed with the computer in 1976, provided on a that loaded the interpreter into memory in approximately 30 seconds. The Apple I's standard configuration included 4 of , which was the minimum required to run the interpreter, though the supported expansion up to 8 via additional sockets. Loading from cassette often encountered issues related to quality and tape condition, leading to incomplete or corrupted loads that necessitated manual entry of program patches to resolve bugs. With the release of the Apple II in 1977, Integer BASIC was integrated directly into the motherboard ROM as part of firmware revision 0, occupying four 2 KB EPROM chips. This allowed the system to autostart the interpreter upon power-up, eliminating the need for external loading and making programming immediately accessible. Integer BASIC was bundled as the standard programming environment with all early Apple II units produced from 1977 onward, serving as the primary tool for users until the introduction of the Apple II Plus in 1979. The Apple II Plus replaced Integer BASIC in ROM with the more feature-rich Applesoft BASIC, which supported floating-point arithmetic and became the default interpreter for subsequent models. Despite its phase-out, Integer BASIC saw widespread adoption among educators and hobbyists in the late 1970s, powering introductory programming courses and influencing the development of the initial Apple software ecosystem, including games and utilities distributed via cassette and later floppy disk.

Language Features

Syntax and Program Editing

Integer BASIC employs a line-based program structure, where each program line begins with an integer ranging from 0 to 32767, followed by a or multiple statements separated by colons (:). Lines entered without a line number are executed immediately in direct mode, allowing for on-the-fly testing of commands or expressions without storing them in the . This design facilitates simple program organization and execution via the , which starts from the lowest numbered line. Program editing is managed through dedicated commands that operate in direct mode. The LIST command displays the stored program lines, optionally limited to a range such as 100-200 for lines 100 through 200, aiding in review and . DELETE removes specified lines, as in DELETE 50-100, to refine the program without retyping. RENUMBER reassigns line numbers sequentially, starting from a specified value (e.g., RENUMBER 10), which is essential after insertions or deletions to maintain orderly jumps in . The command automates line entry by prompting for new lines with incrementally numbered suggestions, such as 100,10, streamlining program creation. The interpreter uses a greater-than symbol (>) as the ready prompt in direct mode and during program pauses, indicating acceptance of input. During program execution, the INPUT statement prompts for numeric data with a # symbol, while string inputs receive no additional prompt beyond any user-supplied text. This prompt system ensures clear user interaction without unnecessary output for strings. Text output occurs in a 40-column text window, initially limited to uppercase characters on early Apple II models, though later systems like the support lowercase via hardware flashing or mode switches. The window scrolls automatically when output exceeds the bottom row, with pausing possible using Control-S. Clearing the screen is achieved with the command, which repositions the cursor to the top-left and erases the display. Syntax errors during entry or execution are reported immediately with a such as "SYNTAX ERR RETYPE LINE ?" followed by the offending , preventing invalid lines from being stored and prompting re-entry. This line-specific feedback helps isolate issues efficiently. A distinctive feature is the absence of multi-line statements; all code must fit within a single line up to 128 characters, terminated by pressing RETURN (). Multiple statements per line are permitted using colons, but continuation across lines is not supported, enforcing concise code organization.

Data Types and Variables

Integer BASIC primarily supports a single in its core language: 16-bit signed integers, ranging from -32,768 to 32,767. This design choice optimized for the limited memory and processing capabilities of early microcomputers like the , where floating-point operations were absent to ensure faster execution and simpler implementation. All numeric variables and expressions are thus restricted to whole numbers within this range. Variable names in Integer BASIC can be up to 100 alphanumeric characters long, must begin with a letter (A-Z), and may include digits thereafter, though they cannot incorporate certain reserved substrings such as "AND", "OR", "NOT", "MOD", "AT", "TO", "STEP", or "THEN", nor start with "END", "IF", "INPUT", "LET", "ON", or "REM". Notably, there are no strict reserved words preventing the use of command names as variables; for instance, "PRINT" can serve as a valid variable name, as the parser tokenizes keywords separately from identifiers. Names are case-insensitive during parsing but preserved as entered in memory, allowing flexibility in program readability while maintaining compatibility with the system's uppercase-centric input. String variables are denoted by appending "" to the name (e.g., `A`), and are treated fundamentally as fixed-length arrays of characters rather than distinct types. Arrays are supported only in one dimension and must be explicitly dimensioned using the DIM statement before use, such as DIM A(10) to allocate space for 11 elements (indices 0 through 10). Numeric arrays allocate approximately 2 bytes per element for integer storage, plus overhead for the array header, while strings can be dimensioned to a maximum length of 255 characters using DIM A$(255). Sizing is dynamic in the sense that the last-declared array can be redimensioned with a subsequent DIM call, but attempting to resize a previously defined array results in an error; the maximum size is constrained by available rather than a fixed limit, though practical bounds in minimal configurations often cap elements at around 255 due to addressing constraints. There are no provisions for user-defined types or structures beyond these basics. All variables, including arrays, are stored in dynamic RAM starting from address $0800 (decimal 2048) and growing upward until encountering the program's memory area, which expands downward from the top of available RAM (typically set by HIMEM). Undeclared variables are automatically created upon first assignment and initialized to 0 for numerics or empty for strings; arrays are zero-filled upon dimensioning. The total number of variables is limited solely by free memory after accounting for the program, stack, and system overhead—for example, in a basic 4 KB RAM configuration, roughly 100 simple numeric variables could be accommodated, consuming about 2 bytes of data plus 3-5 bytes of naming and linking overhead each. Exceeding available space triggers a "MEM FULL ERR".

Mathematical Operations

Integer BASIC supports a set of basic operators for numerical computations, limited to 16-bit signed s ranging from -32768 to 32767. The operators include (+), (-), (*), (/), and (^). performs toward zero, such that 5 / 2 yields 2, while the is obtained using the MOD function, as in 5 MOD 2 = 1. is implemented through repeated , restricting its use to non-negative exponents to avoid errors, and results are subject to the range limits. The language provides three built-in mathematical functions: ABS(expr), which returns the of the expression; SGN(expr), which returns -1 if expr is negative, 0 if zero, and if positive; and RND(expr), which generates a pseudo-random . For RND, if expr is positive, it returns a value from 0 to expr-1 inclusive; if expr is zero, it repeats the previous random value; if expr is negative, it returns a value from 0 to -expr-1 inclusive. The random sequence is pseudo-random, starting from an initial of , and can be reseeded by directly modifying the generator's state in via POKE to location 78 (the low byte of the seed). Numerical computations in Integer BASIC lack advanced functions such as trigonometric operations (e.g., , ) or logarithms, requiring users to implement approximations using if needed. Arithmetic overflow occurs when results exceed the 16-bit signed range, triggering an error message like ">32767 ERR" or "<-32768 ERR" and halting execution, rather than wrapping around silently. This behavior enforces strict bounds on calculations, emphasizing the language's design for simple, integer-based tasks. Example of integer division and modulo: 
10 LET A = 17
20 LET B = 5
30 PRINT A / B  REM Outputs 3
40 PRINT A MOD B  REM Outputs 2
Example of random number generation: 
10 PRINT RND(10)  REM Outputs random integer 0-9
20 PRINT RND(0)   REM Repeats previous value
30 PRINT RND(-5)  REM Outputs random integer 0-4

String Handling

In Integer BASIC, strings are handled as a distinct data type, represented by variables suffixed with a dollar sign (e.g., A$), and treated as fixed-length arrays of characters with a maximum capacity of 255 characters. These variables are implicitly declared upon first use, though they can be dimensioned with the DIM statement to set a maximum length (e.g., DIM B$(10) allocates space for B$ up to 10 characters, treating it as an array of characters). Storage occurs in memory with a leading byte indicating the string's length, followed by the character data, enabling efficient but limited manipulation compared to later dialects like . String concatenation is performed using the + operator, which combines two strings into a new one, subject to the 255-character limit; exceeding this triggers a "?STRING TOO LONG ERROR" (error code 176). For example, if A$ = "HELLO" and B$ = " WORLD", then C$ = A$ + B$ results in C$ holding "HELLO WORLD". In output contexts, the semicolon (;) can juxtapose strings without spaces in a PRINT statement (e.g., PRINT A$; B$), but this does not create a new concatenated variable. Key built-in functions for string manipulation include LEN(A$), which returns an integer representing the number of characters in the string (ranging from 0 to 255), and ASC(A$), which returns the ASCII code (0-255) of the string's first character. For instance, PRINT LEN("ABC") outputs 3, and PRINT ASC("A") outputs 65. There is no native CHR$ function to convert an integer ASCII code back to a character; programmers must use direct keyboard input or machine code routines for such conversions. Substring extraction is supported using the syntax A(start, length), where start and length are integers, with 1-based indexing for the starting position. For example, A(3,5) returns the substring starting at the 3rd character for 5 characters. Individual characters can be accessed as A(i,1) or shorthand A(i). String comparisons use relational operators such as =, <, >, <=, >=, and # (for ), performed lexicographically based on ASCII values in a case-sensitive manner. For example, "[ABC](/page/ABC)" < "DEF" evaluates to true because the ASCII value of 'A' (65) is less than 'D' (68), and comparisons proceed character by character until a difference is found or one string ends. Shorter strings are considered less than longer ones if prefixes match (e.g., "AB" < "ABC"). Input of strings is handled primarily through the INPUT statement, which reads user input from the keyboard into a string variable, optionally preceded by a prompt string (e.g., INPUT "Enter name: "; NAME$). The input terminates with Enter, and the resulting string is trimmed of leading/trailing spaces unless specified otherwise; multiple variables can be read in one statement separated by commas. Output uses the PRINT statement to display strings, with semicolons or commas controlling spacing and line breaks (e.g., PRINT NAME$; suppresses a trailing space and newline). These mechanisms integrate strings into control structures like IF for conditional logic based on user-provided text.

Control Structures and Debugging

Integer BASIC provides a set of basic control structures for managing program flow, including conditional branching, unconditional jumps, subroutines, and loops, all implemented using line-numbered statements typical of early dialects. These structures rely on integer expressions for line references and variable conditions, emphasizing simplicity for the 's limited resources. Notably, Integer BASIC lacks dedicated WHILE or DO loops, requiring programmers to simulate them using combinations of IF-THEN and statements. The IF-THEN statement enables conditional execution: IF expression THEN statement evaluates the expression (true if non-zero), and if true, executes the following statement, which can be a single command or an implied GOTO to a line number. For example: 
10 IF A > 5 THEN [PRINT](/page/Print) "High"
This prints "High" only if variable A exceeds 5. Unconditional branching uses : GOTO expression, which transfers control to the specified line number. An example is GOTO 100, jumping to line 100 regardless of conditions. Subroutines are handled by GOSUB and : GOSUB expression branches to the indicated line, saving the return address on a , while RETURN resumes execution after the calling GOSUB. Nesting is limited to 16 levels; exceeding this triggers a "16 GOSUBS ERR". A simple subroutine might appear as: 
50 GOSUB 200
...
200 PRINT "Subroutine"
210 [RETURN](/page/Return)
FOR-NEXT loops provide : FOR variable = start TO end [STEP increment] initializes the , executes statements until the end is reached (incrementing by 1 or the specified STEP value), and NEXT variable advances the loop. Up to 16 nested FOR loops are supported. An example loops ten times: 
10 FOR I = 1 TO 10 STEP 1
20 PRINT I
30 NEXT I
Multi-way branching uses ON: ON expression GOSUB/GOTO line1, line2, ..., selecting the nth line (1-based) from the list based on the expression's integer value. For instance, ON X [GOTO](/page/Goto) 100, 200, 300 jumps to line 200 if X equals 2. Debugging aids in Integer BASIC include built-in tracing and monitoring tools integrated into the interpreter. The command activates line-by-line execution tracing, displaying each executed line number; NOTRACE deactivates it. For variable monitoring, followed by variable names (e.g., DSP A, B) prints the variables' values whenever they change during execution, aiding in tracking state modifications. These features operate directly in the REPL environment without external tools. Program interruption uses Ctrl-C to halt execution at any point, displaying the current line number and returning to the prompt; execution can resume from that point using CONT. Error handling reports specific issues with abbreviated messages, such as ?SN ERROR for syntax violations (e.g., malformed statements) and ?RG ERROR for range errors (e.g., RETURN without a matching GOSUB or index out of bounds). Other errors include ?MEM FULL ERR for insufficient memory and ?BAD RETURN ERR for mismatched subroutine calls. To terminate a program explicitly, END stops execution and clears the prompt, while STOP halts at the current line (resumable with CONT) without ending the session.

Graphics, Sound, and Input/Output

Integer BASIC provided limited support for on the , primarily through low-resolution , which offered a 40 by 40 grid with 16 possible colors. The command switched the display to this mixed , clearing the screen and reserving the bottom four lines for text input, while initializing the drawing color to black. In this , the statement plotted a single or dot at specified coordinates, using the syntax PLOT X, Y where X and Y ranged from 0 to 39; for example, PLOT 20, 15 would draw a point at that location using the current color. The COLOR= statement set the active drawing color for subsequent plots, with values from 0 (black) to 15 (white or bright colors depending on the ), as in COLOR=6 to select ; this affected all operations until changed. To return to , the TEXT command restored the full 24-line by 40-column character display, positioning the cursor at the bottom. High-resolution graphics, offering a 280 by 192 monochrome display with artifact colors, were not natively supported in Integer BASIC through dedicated commands like those in . Instead, programmers accessed hi-res mode by POKEing soft switches, such as POKE 49234, 0 to enable it, but drawing required machine language subroutines invoked via USR calls or direct POKEs to the hi-res page memory starting at $2000; no built-in filled shapes or vector drawing were available, limiting complex visuals to manual manipulation. For instance, a basic hi-res setup might involve POKE -16384,0 to set the mode, followed by USR(1536) for a plotting routine loaded separately. Sound generation in Integer BASIC lacked dedicated statements, relying on direct manipulation of the Apple II's single , which produced square waves at a fixed volume. Programmers used POKE to toggle the port at address $C030 (accessed as -16336 in BASIC), creating tones through timed loops; for example, the code 10 FOR I=1 TO 1000: POKE -16336,0: NEXT I would generate a short beep by rapidly toggling the on and off, with loop length controlling . More sophisticated music required machine language routines POKE'd into memory and called via CALL, as BASIC loops were too slow for precise . Input capabilities included the PDL for reading analog values from the game paddles (0-3), returning an from 0 to 255 representing knob position; for example, PDL(0) sampled the first paddle for game controls like position in a paddle-based game. The GET statement captured a single keypress without echoing or pausing for input, storing the ASCII value in a , as in GET K: IF K="A" THEN ... for non-blocking checks. Output and device handling used PR# n to redirect PRINT statements to peripherals in expansion slots (n=1 to 7, with PR#0 returning to the screen), such as PR#1 for a printer in or PR#6 for a disk drive; similarly, IN# n shifted INPUT from the specified slot. Cursor positioning in was managed by HTAB col (column 1-40) and VTAB row (row 1-24), for example HTAB 20: VTAB 10 to move to a specific location before ; XTAB functioned similarly to HTAB for horizontal positioning in some contexts. These slot-based I/O commands enabled integration with printers, modems, or storage devices without additional software, though compatibility depended on the peripheral's .

Implementation

Interpreter Architecture

Integer BASIC employs a tokenized representation for program storage and execution, where source code lines are parsed into compact tokens during input. Each keyword, operator, and delimiter is replaced by a single-byte , such as $A3 for , to minimize usage and accelerate processing. Numeric constants are preconverted to format, while string literals and variable names remain as nouns in the tokenized stream. These tokens are stored sequentially in the program area of , with each statement prefixed by its for ordered execution. The execution model relies on a two-stack to handle expressions and . The stack manages operands, including addresses, values, and string lengths, while the verb stack (also called the or syntax stack) processes based on operator precedence, executing higher-priority verbs first through recursive descent parsing. Statements are dispatched via token handlers in the interpreter's code, enabling efficient evaluation without recompilation. This design supports immediate execution of non-line-numbered commands and sequential interpretation of stored programs upon invocation. Memory layout is dynamically managed within the available , starting with the area at $0800, followed by the table at $0A00 and beyond. Variables are allocated on first reference, growing upward until reaching the boundary defined by HIMEM (typically $1000 initially, adjustable for expansions up to 48K). Free RAM resides between the variable end and HIMEM, with LOMEM marking the low boundary for program storage; the interpreter automatically adjusts these limits to prevent overlaps. Upon , a loads the interpreter from at E000, initializing stacks and memory pointers before entering command mode. Issuing RUN triggers a warm start at E2B3, clearing variables if needed and commencing execution from the lowest in the area. The interpreter operates independently of an underlying OS, relying on direct hardware access for . Hand-assembled in 6502 by , the interpreter incorporates optimizations such as direct jumps to common operation handlers, reducing overhead for frequent verbs like and assignment. This approach, combined with the virtual machine for compact 16-bit emulation in extensions, ensures efficient performance on limited hardware. Error recovery involves unwinding the stacks upon detection, such as during syntax checks or faults, and resetting the line pointer to the offending statement for user correction. Interruptions via allow inspection and modification of variables before resuming with CONT, preserving the execution context where possible.

ROM Integration and Extensions

Integer BASIC was integrated into the (ROM) of the computer, occupying the address range from E000 to F424 within the overall ROM space of C000 to FFFF. This embedding enabled direct execution without loading from external , with activation occurring through a at E000 via Control-B or a warm start at E003 via , prompting the familiar ">" interface. In contrast to the version, which relied on loading for its , the implementation was permanently stored in ROM, streamlining startup and enhancing accessibility for users. The ROM design also incorporated an autostart mechanism in later revisions, though original non-autostart versions required manual commands to enter the interpreter. A key extension within the ROM was the SWEET16 interpreter, a 16-bit virtual machine invented by Steve Wozniak and located from F689 to F7FC. SWEET16 utilized 16 registers (R0 to R15) mapped to zero-page locations $00 to $1F, supporting opcodes such as *CALL for subroutine invocation and *EXEC for direct code execution, with R15 serving as the program counter and R12 as the stack pointer. Designed for compactness, SWEET16 code was approximately half the size of equivalent 6502 assembly but executed 5 to 8 times slower, making it ideal for high-level subroutines like the program renumbering routine in Programmer's Aid #1. Entry to SWEET16 occurred via JSR F689, with 6502 registers preserved through dedicated SAVE (FF4A) and RESTORE ($FF3F) routines to avoid conflicts during operation. The ROM further included a binary floating-point package from F425 to F65D, providing single-precision with a 5-byte : a combined sign and excess-128 exponent in the first byte, followed by a 24-bit normalized across three bytes, and an implicit leading 1 bit. Essential routines encompassed for ($1F50 or F46E), FSUB for [subtraction](/page/Subtraction) (&#36;1F4A or F468), FMUL for ($1F77 or F48C), FDIV for division (&#36;1F9D or F4B2), FLOAT for integer-to-floating-point conversion (F451), FIX for floating-point-to-integer conversion (F640), along with functions like FABS for and FRND for rounding. Although Integer BASIC operated exclusively on 16-bit signed integers (-32768 to 32767), the floating-point routines could be invoked from BASIC programs using the USR function, which jumped to a user-specified machine language subroutine address stored at $3F8-3F9 via the entry at $FECA; activation often involved SWEET16's *EXEC to interface with the package. These extensions incurred performance penalties due to their interpretive overhead and the additional required—5 bytes per number versus 2 bytes for integers—limiting their use to scenarios demanding non-integer . Additional ROM components supported advanced interactions, including a mini-assembler from F500 to F63C that permitted one-line 6502 code without labels or equates, accessible via the entry at $F666G using the "!" for input. The USR command facilitated seamless calls to custom machine language routines, passing arguments through USR(W) and executing at the poled address in $04-$05. These features, integral to the ROM but absent from the cassette-based Integer BASIC, expanded the system's programmability while maintaining compatibility with the core interpreter architecture.

Performance

Benchmarks and Comparisons

Integer BASIC demonstrated notable performance advantages in benchmarks focused on integer arithmetic and looping, owing to its avoidance of floating-point overhead. In the Sieve of Eratosthenes benchmark published by Byte magazine, Integer BASIC on the Apple II completed the test in approximately 166 seconds, generating 2320 prime flags, compared to over 200 seconds for Applesoft BASIC, which produced 2806 flags under similar conditions. This test emphasized array access and control structures, areas where Integer BASIC's design excelled due to lower loop overhead and direct integer handling. Historical evaluations, including Whetstone-inspired benchmarks adapted for BASIC interpreters, highlighted Integer BASIC's superiority for game-oriented tasks involving calculations and minimal conversions. For instance, loop-intensive programs ran faster in Integer BASIC than equivalent floating-point implementations on the same , as the interpreter bypassed the computational cost of floating-point . Comparisons with variants on comparable 6502-based systems, such as the , showed Integer BASIC outperforming in -heavy workloads by leveraging tighter integration with Apple II routines, though it lagged in floating-point intensive code where Microsoft-derived interpreters like Applesoft provided native support. Memory efficiency further underscored Integer BASIC's strengths, occupying 8 KB in ROM compared to 12 KB for , allowing more space for user programs on memory-constrained systems. However, limitations emerged in areas without dedicated optimizations, such as string manipulation and graphics rendering, where unoptimized routines led to slower execution in complex programs relying on these features.
BenchmarkSystem/InterpreterTime (seconds)Primes Found
Apple II / Integer BASIC165.712320
Apple II / 200.432806

Sample Programs

Sample programs in Integer BASIC demonstrate its syntax and capabilities. These examples are drawn from the official Apple II BASIC Programming Manual and standard references.

Hello World

This basic program prints a greeting to the screen and ends. 
10 [PRINT](/page/Print) "HELLO WORLD"
20 END
When run, it outputs: HELLO WORLD

Simple Number Loop

This program prints numbers from 1 to 10, showcasing the FOR-NEXT loop structure. 
10 FOR I = 1 TO 10
20 [PRINT](/page/Print) I
30 NEXT I
40 END
Output: 1 2 ... 10

Basic Graphics Example

Integer BASIC includes graphics commands for the Apple II. This program enters low-resolution graphics mode and plots a point. 
10 GR
20 PLOT 0,0
30 END
This draws a single at the origin in lo-res mode.

Legacy

Influence and Preservation

Integer BASIC played a pivotal role in shaping early Apple education software, serving as the built-in programming language for the and enabling interactive computing in classrooms during the late and early . Its simple syntax and immediate feedback loop made it ideal for novice users, including students, fostering widespread adoption of personal computing in educational settings. The interpreter's design influenced subsequent developments, notably inspiring the development of , a Microsoft port that added floating-point support and other features while incorporating some command compatibility with Integer BASIC. Steve Wozniak's philosophy emphasized efficient code generation, achieved through hand-assembly in 6502 machine language to optimize for the Apple II's constrained 8 ROM space and deliver fast execution without unnecessary overhead. By the 1980s, Integer BASIC was largely phased out in favor of Applesoft with the introduction of the in 1979, though it remained available as an optional upgrade into the early 1980s and formed the basis for backward-compatible BASIC support in later models like the . Preservation efforts have ensured Integer BASIC's accessibility through emulators such as AppleWin, which simulates the original hardware including the Integer BASIC , and GSport, an emulator for the that supports loading and running Integer BASIC programs. The source code has been disassembled—originally by Eric Smith for the version and extended by Paul R. Santa-Maria for the —and archived on platforms like , where it remains available for study and modification in the . In modern retro computing communities, Integer BASIC continues to be employed for teaching 8-bit programming principles, with enthusiasts using it to explore low-level concepts on emulated or recreated . Ports to FPGA-based recreations of the allow original programs to run on contemporary field-programmable gate arrays, bridging vintage software with current technology. While the original interpreter lacks Unicode support, relying instead on 7-bit ASCII, modern tools like enhanced emulators and text editors provide compatibility layers to handle extended character sets during development and execution. Culturally, Integer BASIC featured prominently in educational literature.