Atari also felt that they needed to expand the language to support the hardware features of their computers, similar to what Apple had done with Applesoft BASIC.

[a] After six months the code was pared down to almost fit in an 8 KB ROM,[7] but Atari was facing a January 1979 deadline for the Consumer Electronics Show (CES) where the machines would be demonstrated.

[1] Cromemco BASIC includes an extended floating point implementation using a 14-digit binary-coded decimal (BCD) format made possible using all 16 registers of the Zilog Z80 processor.

As it converts all data to the internal format at edit time, small constants like "1" use ~8 bytes of memory, and this could be a particular issue when storing arrays of numbers.

[14] Atari accepted the proposal, and when the specifications were finalized in October 1978, Laughton and O'Brien began work on the new language.

Development proceeded quickly, helped by a bonus clause in the contract, which led to the initial version being delivered in October.

It contains a major bug in a routine that copies memory: deleting lines of code that are exactly 256 bytes long causes a lockup after the next command is entered.

In the example pictured above (with PRUNT), the error can be fixed by moving the cursor over the U, typing I (the editor only has an overwrite mode), and hitting RETURN.

During entry, keywords can be abbreviated using the pattern set by Palo Alto Tiny BASIC, by typing a period at any point in the word.

So L. is expanded to LIST, as is LI.. Only enough letters have to be typed to make the abbreviation unique, so PLOT requires PL.

To expand an abbreviation, the tokenizer searches through its list of reserved words to find the first that matches the portion supplied.

Slicing functions simply set pointers to the start and end points within the existing allocated memory.

The following trick allows fast string initialization, and it is also useful for clearing large areas of memory of unwanted garbage.

Most programs can be written independently of what device they might use, as they all conform to a common interface; this was rare on home computers at the time.

A replacement E:, for example could displace the one in ROM to provide an 80-column display, or to piggyback on it to generate a checksum whenever a line is returned (such as used to verify a type-in program listing).

Atari BASIC supports CIO access with reserved words OPEN #, CLOSE #, PRINT #, INPUT #, GET #, PUT #, NOTE #, POINT # and XIO #.

PLOT and DRAWTO for line drawing are supported while a command providing area fill for primitive linear geometric shapes is not.

The BASIC statement OPEN # prepares a device for I/O access: Here, OPEN # means "ensure channel 1 is free," call the C: driver to prepare the device (this will set the cassette tape spools onto tension and advance the heads keeping the cassette tape player "paused").

Advanced capabilities of the hardware such as higher pitch resolution, high-pass filters, digitised sound and waveforms, player/missile graphics (sprites), redefined character sets, scrolling, and custom graphics modes are not supported by BASIC; these will require machine language routines or PEEK/POKE statements.

[29] Bitmap modes in BASIC are normally set to have a text window occupying the last four rows at the bottom of the screen so the user may display prompts and enter data in a program.

If bitmap mode in full screen is invoked Atari BASIC will gracefully switch back into text mode when program execution is terminated, avoiding leaving the user with an unresponsive screen that must be escaped by typing a blind command or resetting the computer.

This allows the rapid memory-shifting routines underlying string and substring assignment can be applied from BASIC to the memory used for the screen or player/missile graphics.

The TRAP statement jumps to a line number when an error occurs, and this reduces the need for manual error-checking.

The ENTER command reads source code from a device and merges it into the current program, as if the user had typed it in.

This allows programs to be saved out in sections via LIST, reading them in using ENTER to merge or replace existing code.

By using blocks of line numbers that do not overlap, programmers can build libraries of subroutines and merge them into new programs as needed.

Even complex mathematical operations are ready-to-run, with any numerical constants already converted to the internal 40-bit format, and variables values are looked up by address rather than having to be searched for.

[30] 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 and PET,[31] in spite of having the same CPU running at roughly twice the speed.

To perform a branch in a GOTO or GOSUB, the interpreter searches through the entire program for the matching line number.

The reason for this poor performance is best illustrated by a quote from one of its primary authors, Bill Wilkinson; in 1982 he stated: Personally, I have never been sure it is necessary for an interpreted language (e.g., BASIC) to be fast.