Commodore BASIC

Later PETs featured BASIC 4.0, similar to the original but adding a number of commands for working with floppy disks.

This marked a significant upgrade in program entry interfaces compared to other common home computer BASICs at the time, which typically used line editors, invoked by a separate EDIT command, or a "copy cursor" that truncated the line at the cursor's position.

Most systems only supported filenames on diskette, which made saving multiple files on other devices more difficult.

The user of one of these other systems had to note the recorder's counter display at the location of the file, but this was inaccurate and prone to error.

Commodore cassette data was recorded digitally, rather than less expensive (and less reliable) analog methods used by other manufacturers.

If a program was saved on a CBM-II machine, the only way to load it on a PET was by modifying the first two bytes with a disk sector editor as the CBM-II series had their BASIC program area at $0, which would result in a PET attempting to load into the zero page and locking up.

This set the high bit, causing the interpreter to stop reading and parse the statement according to a lookup table.

This meant that the statement up to where the high bit was set was accepted as a substitute for typing the entire command out.

However, since all BASIC keywords were stored in memory as single byte tokens, this was a convenience for statement entry rather than an optimization.

This tokenizing method had a glitch such that if one included a REM (BASIC statement to add a comment to the code) followed by a {Shift-L}, when trying to view the program listing, the BASIC interpreter would immediately abort the listing, display a ?SYNTAX ERROR and return to the READY.

Test results have shown that copying 16 kilobytes from ROM to RAM takes less than a second in machine code, compared to over a minute in BASIC.

This is in comparison to other implementations of BASIC which typically have dedicated commands to clear the screen or move the cursor.

BASIC 7.0 displays a ?STRING TOO LONG error if the user enters a program line over 160 characters in length.

In the early days, when BASIC was used commercially, this was a software protection technique to discourage casual modification of the program.

The accuracy of a floating point number using a three-byte mantissa is only about 6.5 decimal digits, and round-off error is common.

Denoting any variable as integer simply causes BASIC to convert it back to floating point, slowing down program execution and wasting memory as each percent sign takes one additional byte to store (since this also applies to integer arrays, the programmer should avoid using them unless very large arrays are used that would exceed available memory if stored as floating point).

Since Commodore 8-bit machines other than the C128 cannot automatically boot disk software, the usual technique is to include a BASIC stub like 10 SYS 2048 to begin program execution.

It is possible to automatically start software after loading and not require the user to type a RUN statement, this is done by having a piece of code that hooks the BASIC "ready" vector at $0302.

Garbage collection is automatically invoked any time a FRE function is executed and if there are many string variables and arrays that have been manipulated over the course of a program, clearing them can take more than an hour under the worst conditions.

This 1 KB extension to BASIC added a number of disk-related commands, including the ability to read a disk directory without destroying the program in memory.

[10] A disk magazine for the C64, Loadstar, was a venue for hobbyist programmers, who shared collections of proto-commands for BASIC, called with the SYS address + offset command.

If a large section needed to be added, it could just be assigned the next available major line number and inserted to the jump table.

Earlier BASICs from Commodore also lack debugging commands, meaning that bugs and unused variables are hard to trap.

BASIC's file and programming commands could be entered in direct mode to load and execute software.

If program execution was halted using the RUN/STOP key, variable values would be preserved in RAM and could be PRINTed for debugging.

The 128 even dedicated its second 64k bank to variable storage, allowing values to persist until a NEW or RUN command was issued.

[12] This is in contrast to business-oriented operating systems of the time like CP/M or MS-DOS, which typically booted into a command line interface.

While some versions of Commodore BASIC included disk-specific DLOAD and DSAVE commands, the version built into the Commodore 64 lacked these, requiring the user to specify the disk drive's device number (typically 8 or 9) to the standard LOAD command, which otherwise defaulted to tape.

Another omission from the Commodore 64s BASIC 2.0 was a DIRECTORY command to display a disk's contents without clearing main memory.

Addons like the DOS Wedge overcame this by rendering the directory listing direct to screen memory.