Jump to content

Commodore BASIC

From C64 Wiki

Commodore BASIC is the resident BASIC language environment relevant to the Commodore 64 (C64) and Commodore 128 (C128). On a standard C64, the built-in language is Commodore BASIC 2.0; the C128 supplies BASIC 7.0 in its native mode and also provides a C64 mode built around BASIC 2.0.[1][2] It is both a programming language and a user-facing ROM environment: it accepts immediate commands, retains numbered program lines, and calls operating-system services and machine code when a program needs facilities outside its language vocabulary.[3][4]

Versions and operating modes

[edit | edit source]

The C64 language is commonly identified as BASIC V2. Its firmware image identifies it as the C64 BASIC interpreter, version 2, and places it in the eight-kilobyte region from $A000 through $BFFF.[2][5] The C64 BASIC source record contains a token table and dispatch entries for program control, data, I/O, memory access, and machine-language transfer; this structure explains why a typed keyword is stored and later interpreted rather than compiled into a standalone native program.[6][4]

In native C128 mode, BASIC 7.0 retains the BASIC 2.0 language elements and adds its own commands, statements, functions, and operators.[7][1] The C128 firmware archive documents 32-kilobyte BASIC V7 ROM sets and separately records the C64 BASIC and KERNAL components included in a C128 system-ROM layout.[8][9] In C64 mode, the C128 documentation specifies BASIC 2.0 and says that BASIC 2.0 commands are usable in both C64 and C128 modes.[10][1] A program that uses a BASIC 7.0-only word therefore belongs to the native C128 environment unless it is rewritten for the BASIC 2.0 vocabulary.[7][6]

ROM environment and memory visibility

[edit | edit source]

On the C64, BASIC shares the 6510 processor's address space with RAM, the KERNAL ROM, character ROM, and memory-mapped I/O. The processor port at address $0001 selects whether the BASIC ROM at $A000, the KERNAL ROM at $E000, and I/O or character ROM are visible to the CPU.[5][11] RAM still exists beneath mapped ROM, so a write to a ROM-covered address can alter the underlying RAM even while a read returns the visible ROM byte.[5][11] This mapping is central to advanced C64 work, but removing the KERNAL mapping also removes services on which the normal BASIC environment depends.[5][11]

The C128 exposes a more explicit language-level memory selection mechanism. BASIC 7.0's BANK chooses one of sixteen documented configurations before subsequent PEEK, POKE, or SYS activity, while its binary-load and binary-save facilities can name a bank as well as an address range.[12][13] The source comment and the system guide agree that banks 14 and 15 select configurations involving system ROM, with the distinction affecting character-ROM versus I/O visibility.[12][13]

This distinction is important because the ordinary BASIC view is not the whole physical memory map. In the C64 configuration, an address can name RAM, a ROM byte, or a device register according to the active mapping, so an address-based program needs to distinguish the intended CPU-visible resource from an abstract notion of “memory.”[5][11] The C128's BANK statement does not eliminate that concern; instead, it makes selection of a documented context part of the BASIC program before its machine-facing operations run.[12][13]

Language facilities and devices

[edit | edit source]

BASIC 2.0 provides the general language apparatus expected for small programs: variables and arrays, expressions, branches and subroutines, loops, data statements, string and numeric functions, and direct-mode commands.[3][6] Its machine-facing vocabulary includes PEEK for reading an address, POKE for writing one, SYS for transferring control to machine code, and USR as a function-level entry point.[14][6] A SYS target must return with the processor's subroutine-return instruction if BASIC execution is to continue after the call.[14][11]

Device handling in BASIC 2.0 is organised around logical files. OPEN creates a channel, PRINT# sends formatted output to an open channel, INPUT# and GET# read from one, CLOSE finishes it, and CMD can redirect normal output to an already open channel.[15][14] At the KERNAL level, logical-file, device, and secondary-address parameters are prepared before opening, loading, or saving; the documented device assignments include keyboard, cassette, RS-232, screen, printer, and serial-bus storage devices.[16][15] BASIC's file statements are consequently a high-level route to the machine's documented I/O conventions rather than a separate peripheral system.[16][15]

BASIC 7.0 extends this model in several directions. It adds editing and control facilities such as automatic line numbering and multi-line conditional blocks; it also includes disk-oriented commands, binary file operations, bank selection, graphics primitives, sprite and collision facilities, and sound-oriented commands.[12][9] For example, the guide documents commands for boxes, circles, character placement, binary loading, binary saving, catalogue display, and file appending, while the source tree contains corresponding implementation modules for graphics, sound, sprites, disk operations, and banks.[12][9] These facilities make native C128 BASIC more direct for many display, sound, disk, and memory tasks, but they are not part of the C64 BASIC 2.0 token table.[12][6]

The difference is especially visible in graphics work. The C64 reference guide treats graphics, sound, and BASIC-to-machine-language programming as separate subjects, and BASIC 2.0's token list does not contain dedicated bitmap, drawing, sprite, or sound statements.[3][6] As a result, a BASIC 2.0 program can still control the machine's graphics or sound hardware, but it does so through memory access, a machine-language extension, or both.[11][14] Native C128 BASIC 7.0, by contrast, documents graphics statements that establish display modes and place or draw objects, as well as source modules named for these features.[12][9] The two approaches are therefore different language interfaces to related kinds of hardware rather than evidence that the C64 lacks the underlying video or sound capabilities.[3][1]

The same pattern applies to persistent data and executable bytes. BASIC 2.0 can use its channel model with cassette or serial storage, and its LOAD and SAVE vocabulary works with the system's device conventions.[15][16] BASIC 7.0 adds named facilities for binary files and disk operations; BLOAD and BSAVE can identify a bank and memory range, while commands such as DIRECTORY/CATALOG and APPEND expose commonly used disk operations within the language.[12][1] This is an expansion of convenience and scope, not a replacement for the underlying KERNAL and device protocols.[16][12]

Machine interaction and compatibility

[edit | edit source]

On a C64, BASIC programs commonly cross the language boundary by reading or changing mapped memory, invoking a machine-language routine, or using a KERNAL I/O service indirectly through BASIC's file commands.[11][16] The relevant address, ROM mapping, and I/O configuration are part of the program's effective environment; a routine written for one machine mode should therefore identify its required memory configuration and return path rather than treating BASIC syntax alone as a portability guarantee.[5][13] On a C128, BANK makes that dependency visible within BASIC before PEEK, POKE, and SYS operations.[12][13]

KERNAL calls are a complementary boundary. Their documented interface works in terms of logical files, device numbers, names, channels, and status rather than BASIC source syntax alone.[16][15] A programmer may remain entirely in BASIC when the language's OPEN, PRINT#, INPUT#, GET#, LOAD, and SAVE operations fit the task, or move to KERNAL routines and machine code when register-level control, custom I/O flow, or an unavailable language feature is required.[15][11] Both cases depend on the same ROM-based environment, so they should not be represented as unrelated systems.[11][16]

Compatibility should be described by mode as well as by computer name. The C128 preserves the BASIC 2.0 language in C64 mode, whereas its native BASIC 7.0 environment supplies a substantially larger command set and different bank-aware facilities.[10][8] C64 BASIC itself had one essential BASIC V2 revision in the firmware archive, while the C64 KERNAL and C128 BASIC V7 records show multiple ROM revisions; software that depends on ROM internals should consequently record the target machine, mode, and ROM assumptions.[2][8]

This mode-based description also prevents a misleading comparison between source text and executable environment. A program using only the shared BASIC 2.0 vocabulary may be suitable for either relevant BASIC context, subject to its device and memory assumptions.[10][7] A program using native BASIC 7.0 commands, explicit bank contexts, or C128-specific graphics and disk features requires C128 mode because those words and facilities are not present in the C64 token table.[12][6] Conversely, code that relies on a particular KERNAL entry, mapped address, or ROM revision should state that low-level dependency even when its visible source is ordinary BASIC.[2][5]

See also

[edit | edit source]

References

[edit | edit source]
  1. ↑ 1.0 1.1 1.2 1.3 1.4 “Commodore 128 Programmer's Reference Guide”. Commodore Business Machines, via jbrain.com. Accessed 2026-09-21.
  2. ↑ 2.0 2.1 2.2 2.3 “Firmware for all variations on the Commodore 64k computer”. Zimmers.net. Accessed 2026-09-21.
  3. ↑ 3.0 3.1 3.2 3.3 “Commodore 64 Programmer's Reference Guide: contents and introduction”. Commodore Business Machines, via Commodore.ca. Accessed 2026-09-21.
  4. ↑ 4.0 4.1 “C64 BASIC & KERNAL ROM Disassembly”. Pagetable.com. Accessed 2026-09-21.
  5. ↑ 5.0 5.1 5.2 5.3 5.4 5.5 5.6 “C64 Memory Map”. Pagetable.com. Accessed 2026-09-21.
  6. ↑ 6.0 6.1 6.2 6.3 6.4 6.5 6.6 “BASIC_C64/tokens”. mist64 cbmsrc source collection, GitHub. Accessed 2026-09-21.
  7. ↑ 7.0 7.1 7.2 “Commodore 128 System Guide, section 16: Introduction”. Commodore Business Machines, via Commodore.ca. Accessed 2026-09-21.
  8. ↑ 8.0 8.1 8.2 “Firmware for Commodore 128 computers”. Zimmers.net. Accessed 2026-09-21.
  9. ↑ 9.0 9.1 9.2 9.3 “BASIC_C128_04 source directory”. mist64 cbmsrc source collection, GitHub. Accessed 2026-09-21.
  10. ↑ 10.0 10.1 10.2 “Commodore 128 System Guide, section 9: Using BASIC 2.0”. Commodore Business Machines, via Commodore.ca. Accessed 2026-09-21.
  11. ↑ 11.0 11.1 11.2 11.3 11.4 11.5 11.6 11.7 11.8 “Commodore 64 Programmer's Reference Guide, chapter 5: BASIC to Machine Language”. Commodore Business Machines, via Commodore.ca. Accessed 2026-09-21.
  12. ↑ 12.00 12.01 12.02 12.03 12.04 12.05 12.06 12.07 12.08 12.09 12.10 “Commodore 128 System Guide, section 17: BASIC Commands and Statements”. Commodore Business Machines, via Commodore.ca. Accessed 2026-09-21.
  13. ↑ 13.0 13.1 13.2 13.3 13.4 “BASIC_C128_04/bank.src”. mist64 cbmsrc source collection, GitHub. Accessed 2026-09-21.
  14. ↑ 14.0 14.1 14.2 14.3 “Commodore 64 Programmer's Reference Guide, chapter 2: BASIC Language Vocabulary”. Commodore Business Machines, via Commodore.ca. Accessed 2026-09-21.
  15. ↑ 15.0 15.1 15.2 15.3 15.4 15.5 “Commodore 64 Programmer's Reference Guide, chapter 6: Input/Output Guide”. Commodore Business Machines, via Commodore.ca. Accessed 2026-09-21.
  16. ↑ 16.0 16.1 16.2 16.3 16.4 16.5 16.6 “C64 KERNAL API”. Pagetable.com. Accessed 2026-09-21.

Automation and sourcing note

[edit | edit source]

This article was independently synthesized from the cited sources under c64.wiki publication policy. It uses the cited historical manuals and source materials for factual verification only; no manual prose, program listing, scan, or image has been reproduced.

Retrieved from "https://c64.wiki/index.php?title=Commodore_BASIC&oldid=35"