Editing Commodore BASIC (section)

===Program editing===
A convenient feature of Commodore's [[read-only memory|ROM]]-resident [[BASIC interpreter]] and [[KERNAL]] was the [[visual editor|full-screen editor]].<ref>{{cite web|url=https://archive.org/stream/Commodore_Microcomputers_Volume_6_Number_4_Issue_36_1985-07_Commodore_US#page/n41/mode/2up|title=Keyboarding and the Screen Editor|date=July 1985}}</ref><ref>{{cite web|url=http://www.classiccmp.org/dunfield/c64/bytejl83.pdf|title=Byte July 1983|access-date=2015-05-01|archive-date=2017-08-24|archive-url=https://web.archive.org/web/20170824214757/http://www.classiccmp.org/dunfield/c64/bytejl83.pdf|url-status=dead}}</ref> Although Commodore keyboards only have two [[cursor keys]] which reversed direction when the shift key was held, the screen editor allowed users to enter [[Direct mode|direct commands]] or to input and edit program lines from anywhere on the screen. If a line was prefixed with a line number, it was [[tokenized]] and stored in program memory. Lines not beginning with a number were executed by pressing the {{keypress|RETURN}} key whenever the [[cursor (computers)|cursor]] happened to be on the line. This marked a significant upgrade in program entry interfaces compared to other common home computer BASICs at the time, which typically used [[line editor]]s, invoked by a separate <code>EDIT</code> command, or a "copy cursor" that truncated the line at the cursor's position.

It also had the capability of saving named files to any device, including the [[Compact Cassette|cassette]] – a popular storage device in the days of the PET, and one that remained in use throughout the lifespan of the 8-bit Commodores as an inexpensive form of mass storage. 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. With the PET (and BASIC 2.0), files from cassettes could be requested by name. The device would search for the filename by reading data sequentially, ignoring any non-matching filenames. The file system was also supported by a powerful [[storage record|record structure]] that could be loaded or saved to files. Commodore cassette data was recorded digitally, rather than less expensive (and less reliable) analog methods used by other manufacturers. Therefore, the specialized [[Datasette]] was required rather than a standard tape recorder. Adapters were available that used an [[analog-to-digital converter]] to allow use of a standard recorder, but these cost only a little less than the Datasette.

The {{mono|LOAD}} command may be used with the optional parameter {{mono|,1}} which will load a program into the memory address contained in the first two bytes of the file (these bytes are discarded and not retained in memory). If the {{mono|,1}} parameter is not used, the program will load into the start of the BASIC program area, which widely differs between machines. Some Commodore BASIC variants supplied <code>BLOAD</code> and <code>[[BSAVE]]</code> commands that worked like their counterparts in [[Applesoft BASIC]], loading or saving [[bitmap]]s from specified memory locations.

The PET does not support relocatable programs and the {{mono|LOAD}} command will always load at the first two bytes contained in the program file. This created a problem when trying to load BASIC programs saved on other Commodore machines as they would load at a higher address than where the PET's BASIC expected the program to be, there were workarounds to "move" programs to the proper location. 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.

Commodore BASIC [[keyword (computer programming)|keyword]]s could be abbreviated by entering first an unshifted keypress, and then a shifted keypress of the next letter.  This set the [[most significant bit|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.

In the default uppercase-only character set, shifted characters appear as a graphics symbol; e.g. the command, <code>GOTO</code>, could be abbreviated <code>G{Shift-O}</code> (which resembled <code>G'''Γ'''</code> onscreen). Most such commands were two letters long, but in some cases they were longer. In cases like this, there was an ambiguity, so more unshifted letters of the command were needed, such as <code>GO{Shift-S}</code> (<code>GO♥</code>) being required for <code>[[GOSUB]]</code>. Some commands had no abbreviated form, either due to brevity or ambiguity with other commands. For example, the command, <code>INPUT</code> had no abbreviation because its spelling collided with the separate <code>INPUT#</code> keyword, which was located nearer to the beginning of the keyword [[lookup table]]. The heavily used <code>PRINT</code> command had a single <code>?</code> shortcut, as was common in most Microsoft BASIC dialects. Abbreviating commands with shifted letters is unique to Commodore BASIC.

This tokenizing method had a glitch such that if one included a <code>REM</code> (BASIC statement to add a comment to the code) followed by a <code>{Shift-L}</code>, when trying to view the program listing, the BASIC interpreter would immediately abort the listing, display a <code>?SYNTAX  ERROR</code> and return to the <code>READY.</code> prompt. This glitch was used to some effect by programmers who wanted to try and protect their work, although it was fairly easy to circumvent.

By abbreviating keywords, it was possible to fit more code on a single program line (which could take up two screen lines on 40-column displays - i.e., C64 or PET, or four lines on the VIC-20's 22-column display). This allowed for a slight saving on the overhead to store otherwise necessary extra program lines, but nothing more. All BASIC commands were tokenized and took up 1 byte (or two, in the case of several commands of BASIC 7 or BASIC 10) in memory no matter which way they were entered. Such long lines were a nuisance to edit. The <code>LIST</code> command displayed the entire command keyword - extending the program line beyond the 2 or 4 screen lines which could be entered into program memory.