C64 OS USER'S GUIDE
Appendices
The appendices contain useful summaries, for easy reference, of informataion that is elsewhere found throughout the User's Guide. It also contains some supplementary information about that would have bogged down the main User's Guide and so can be considered as footnotes.
Frequently Asked Questions
How do I purchase a copy of C64 OS?
You can purchase a copy of C64 OS right here on C64OS.com. Choose whether you want the Starter Bundle (16 MB System Card) or the Standard Bundle (64 MB System Card), click the buy now button and you can pay using PayPal secure online payments.
No PayPal account required
You do not need a PayPal account to pay with PayPal, you can pay using a credit card. The beauty of PayPal is that C64OS.com never gets access to your credit card information. We don't store any sensitive information, because we don't collect any sensitive information.
What do I get when I buy a copy of C64 OS?
A licensed copy of C64 OS v1.0 includes:
- Access to the 3,500 word online Getting Started Guide
- Access to the complete 75,000 word online User's Guide
- A 42-page full-color professionally printed User's Guide Supplement
- A pre-installed copy of C64 OS v1.0 on a System Card (16 MB or 64 MB SD Card)
- An installation archive and install tools for C64 OS v1.0 for other storage media
- App Launcher, File Manager, C64 Archiver, 3 additional Applications and over 25 Utilities, plus 10 KERNAL modules, 12 Drivers, 18 Libraries, 24 Toolkit classes, and 8 additional Tools
- A high-quality promotional C64 OS vinyl sticker
- Access to ongoing patches, bug fixes and feature updates to C64 OS v1.0
- Access to new non-commercial Applications and Utilities for C64 OS
- Access to a C64 OS Discord server for support, help, bug reporting, news and community
The 64 MB System Card also comes with these bonuses:
- A pre-installed CMD HD hard drive image of C64 OS v1.0 for use in VICE
- A collection of C64 graphics files that can be viewed with Image Viewer
- A collection of popular HVSC SID tunes that have been relocated for use in C64 OS
The C64 OS bundles do not come in a product box. The labeled System Card is elegantly mounted on the inside cover of the User's Guide, and this is contained in a clear cellophane self-sealing product bag.
For a detailed overview of the contents of the C64 OS system and accompanying software, you can peruse this online User's Guide.
By purchasing a copy of C64 OS you acquire a license to use C64 OS on any number of C64 computers, and emulators for your personal use. You review the software license agreement and other legal documents here. With the ability to run C64 OS you gain access to the future Applications, Utilities, drivers, libraries and other C64-OS-specific technologies that are planned and under development.
There are point upgrades with new features and bug fixes that are free to download from the Software Updates page. These add new libraries, drivers, Toolkit classes, Applications and Utilities.
What does C64 OS cost?
The C64 OS software package costs $59 (Canadian dollars) for the Starter Bundle (16 MB System Card), or $64 (Canadian dollars) for the Standard Bundle (64 MB System Card), plus shipping and any applicable sales tax.
Both versions contain the same base content. The main difference is the available capacity of the original System Card. The larger capacity card allows you to use the official C64 OS System Card as a primary mass-storage device, and provides plenty of free space for future content. The larger System Card also comes with some bonus content, including a pre-installed CMD HD hard drive image to make it easy to get started with C64 OS on VICE.
Is C64 OS compatible with VICE?
Yes. C64 OS is compatible with the latest versions of VICE with support for the CMD HD. You can find installation instructions for VICE in Chapter 2: Installation → Installation on VICE.
It should also be possible to install C64 OS on a physical CMD HD or SD2IEC that is connected to a PC running VICE. However, this configuration and details on how to configure VICE in this manner are not outlined by this User's Guide.
Is C64 OS compatible with theC64, mini or Maxi?
Yes. When C64 OS v1.0 was first released, it was thought that it would not be compatible with TheC64 mini or Maxi due to lack of support for virtual CMD HD and also the lack of a physical IEC port. However, an industrious early C64 OS user has come up with a way to activate a virtual IDE64 on TheC64. With C64 OS pre-installed in an IDE64 disk image via VICE, it can be added to TheC64 allowing C64 OS to boot and run.
Thanks Andrew Gillham!
Is C64 OS compatible with BMC64?
No. Unfortunately, BMC64 does not support the one minimum requirement to run C64 OS. Although BMC64 runs a custom version of VICE, that version does not have support for a virtual CMD HD.
Additionally, BMC64 does not have support for physical IEC ports, and therefore it cannot be connected to a real SD2IEC or CMD HD.
Can C64 OS be run from a 1541 or 1571?
No. A 1541 and 1571 are legacy, low-capacity storage devices. C64 OS can access 1541 and 1571 drives and compatible recreations of these devices, such as Pi1541, to manage data, (rename files, copy files to and from, scratch files, etc.), but they cannot be used as the C64 OS system drive.
There are three reasons for this:
-
The storage capacity is much too low. A base C64 OS installation is greater than 1 megabyte.
That's over 6 times the capacity of a 1541 disk side and over 3 times the capacity of a
1571 disk.
-
The native file system on 1541 and 1571 disks does not support subdirectories. C64 OS's
system directory depends on the logical layout of files into over 50 nested subdirectories.
See Chapter 8: File System → System Directory.
- The single root directory of a 1541 or 1571 disk can hold only a maximum of 144 files. But, a working installation of C64 OS comprises upwards of a 1000 files.
Can C64 OS be run from a 1581?
No. A 1581 is a legacy, medium-low-capacity storage device. C64 OS can access 1581 drives to manage data, (rename files, copy files to and from, scratch files, etc.), but they cannot be used as the C64 OS system drive.
There are three reasons for this:
-
The storage capacity is too low. A base C64 OS installation is greater than 1 megabyte,
which is more than the capacity of a 1581 disk.
-
The native file system on 1581 disks does not support subdirectories. 1581 disks support
something called sub-partitions, but they do not work the same as subdirectories. For
example, they can't be nested and are not easily created or removed the way subdirectories
can be. C64 OS's system directory depends on the logical layout of files into over 50 nested
subdirectories. See Chapter 8: File System → System
Directory.
- The single root directory of a 1581 disk can hold only a maximum of 296 files. But, a working installation of C64 OS comprises upwards of a 1000 files.
Can C64 OS be run from a CMD FD 2000 or 4000?
Yes. A CMD FD Series floppy disk drive is the lowest capacity drive that is classified as a modern device. See Chapter 8: File System → Drives and Devices for a table of supported legacy and modern devices.
A CMD FD 2000 disk has a storage capacity of 1.6MB, and an FD 4000 disk has a capacity of 3.2MB. Both of these capacities are enough to hold a base installation of C64 OS. Additionally, CMD FD disks support CMD native-mode partitions, which support subdirectories just like the CMD HD and RAMLink, which is a requirement for the C64 OS system drive.
Due to the low capacity of a CMD FD Series (especially an FD 2000), very little room is left on the system disk for Applications, documents, music, pictures, etc. It is therefore recommended that a custom installation for a CMD FD disk exclude all non-essential resources. For example, if the build will be used with a mouse, other input drivers can be removed. If an Application is not required, omit it. Further customization possibilities are left to the imagination of the courageous C64 OS explorer.
Can C64 OS be run from Kung Fu Flash?
No. A Kung Fu Flash is primarily a multi-cartridge emulator. It can mount .D64, .D71 and .D81 disk images, and behave, respectively, like a 1541, 1571 or 1581 drive. However because it is not connected via the physical IEC bus it is compatible with these drive types only when the software limits itself to standard KERNAL calls.
C64 OS in fact limits itself only to KERNAL calls. However, in this case, a Kung Fu Flash now has all of the limitations discussed above about running C64 OS from a 1541, 1571 or 1581.
Can C64 OS be run from EasyFlash3?
No. An EasyFlash3 is primarily a multi-cartridge emulator. D64 images can be converted to .CRT images and loaded onto EasyFlash3. However because it is not connected via the physical IEC bus it is only compatible with software that limits itself to standard KERNAL calls. C64 OS in fact limits itself only to KERNAL calls. However, in this case, EasyFlash3 still has all of the limitations discussed above about running C64 OS from a 1541.
Although C64 OS cannot be run from EasyFlash3, that doesn't mean that C64 OS cannot benefit from having one. For example, EasyFlash3 can be used to replace the C64's KERNAL ROM without having to physically replace the ROM. Thus, it can be used to provide a C64c with the JiffyDOS KERNAL, without having to desolder its non-socketed KERNAL ROM.
Can C64 OS be run from a 1541 Ultimate II+
No. A 1541 Ultimate II+ is, first and foremost, a very faithful reproduction of a 1541 disk drive. It connects both via the expansion port and via the IEC port and provides up to two highly compatible virtual 1541s. It uses a mass storage device which it accesses via its own backend menu system to pick and mount a disk image into one of the virtual disk drives.
With recent firmware updates 1541 Ultimate II+ can also behave like a virtual 1571 or 1581. However, in this case, it now has all of the limitations discussed above about running C64 OS from a 1541, 1571 or 1581.
The 1541 Ultimate II+ is much more than just a virtual disk drive. It can be used as a 17xx REU up to 16MB or a GEORAM up to 4MB. It has simulated additional SID chips; it has an RTC that C64 OS has a driver for; it can be used to provide a replacement KERNAL ROM, among many other useful features. Therefore, although a 1541 Ultimate II+ cannot be used as the C64 OS system drive, it can be used in powerful combination with an SD2IEC or CMD HD.
Can C64 OS be run from an Ultimate64?
Yes and No. An Ultimate64 is a complete modern C64 reproduction in FPGA with all of the functionality of a 1541 Ultimate II+ built-in. Can an Ultimate64 be used as the Commodore 64 computer that runs C64 OS? YES, definitely. But is the 1541 Ultimate II+ functionality built into the Ultimate64 able to be used as the system drive onto which C64 OS is installed? No. For the reasons discussed above about 1541 Ultimate II+.
An Ultimate64 is a C64, plus it has highly compatible virtual floppy disk drives. But it also has a built-in 17xx REU up to 16MB or a GEORAM up to 4MB. It has simulated additional SID chips; it has an RTC that C64 OS has a driver for; it can have any KERNAL ROM installed; its clock rate can even be sped up, among many other useful features. Therefore, although C64 OS cannot use one of the virtual 1541, 1571 or 1581 drives as its system drive, an Ultimate64 has a full expansion port and standard IEC serial ports and can be used in conjunction with an SD2IEC, CMD HD or IDE64 for a very powerful combination.
Can C64 OS play SID music?
Yes. C64 OS version 1.0 includes a library that is capable of loading and playing SID music in PSID format. However, the memory address range used by the main music data, and the zero page memory used by the SID music as it runs, is not standard. When you try to load a PSID, it first checks to see if the range of required main memory is available. If it's unavailable the file will fail to load. If it is available it gets loaded in and that area of memory is marked in the allocator as taken so that other processes won't use that memory.
However, most of zero page is already spoken for by C64 OS, its libraries, drivers, Applications and Utilities. Therefore, if you simply load any random PSID, when it runs it will most likely overwrite unavailable zero page and the system will crash. C64 OS reserves 4 consecutive zero page addresses just for SID music. Many but not all PSIDs can be relocated using the sidreloc tool to be safe to use within C64 OS.
See: Appendix IX. SID Music for more information about SID music support in C64 OS and tips about relocation.
Can the File Manager copy files to, from or between 1541, 1571 and 1581 disk drives?
Yes. The C64 OS File Manager has 4 tabs, and each tab can be in any place. Any device, any partition, any path on that partition. You can then recursively copy or move files and directories between any two tabs.
Supported devices include: 1541, 1571, 1581, CMD FD, CMD HD, RamLink, IDE64 and SD2IEC. Plus their equivalent clones, like Pi1541, 1541UII+, etc.
Can the File Manager copy files to and from D64, D71, D81 or DNP disk images?
Yes. C64 OS's File Manager does not directly read/write disk images. However, SD2IEC has the ability to mount disk images into a partition. The C64 OS System Card comes with two partitions already setup. Partition 1 is the C64 OS system partition. Partition 2 is called Disk Images. Put your disk images into that second partition. You can then mount the image into partition 2, you can then use the File Manager to copy files into and out of that image by just opening partition 2 in a tab, and using File Manager as normal.
C64 OS v1.03 added the Mount Utility and the unmount command to File Manager. All standard disk images are assigned to Mount Utility by default. Double-click a disk image in File Manager, and it opens the Mount Utility. The image can be mounted if it is in a non-system-partition of an SD2IEC.
Can C64 OS be used without a 1351 mouse?
Yes. If you are not lucky enough to have a real 1351 mouse, there are numerous commercially available 1351-compatible mouse adapters. There are adapters for both PS/2 and USB mice. Two popular adapters are the MicroMys v5 (PS/2) and the MouSTer (USB). There are numerous other less well known options, many are listed in the Commodore 8-bit Buyer's Guide.
Can C64 OS be used without a mouse?
Yes. If you don't have a 1351 mouse or adapter, and you don't want to spring for buying one of the many available adapters, you can still use C64 OS. There are input drivers for regular joysticks, light pen, Koala Pad, and—if you're running C64 OS on a C128—there is a driver to use the C128's numeric keypad for pointer input. A mouse is still recommended, however, for its speed and precision.
C64 OS Software License Agreement
The C64 OS End-User License Agreement (EULA) can be found in the legal subsection of C64OS.com. These other important resources can be found there as well, all of these links can also be found in the footer of every C64OS.com page:
- Terms & Conditions (for C64OS.com)
- Privacy Policy (for C64OS.com)
- Cookies Policy (for C64OS.com)
- C64 OS License Agreement (for C64 OS)
- Thanks and Credits (for C64 OS and C64OS.com)
I. C64 Tools
C64 Tools are a set of programs from various sources that are included alongside C64 OS, but they are not part of C64 OS proper. They are just regular C64 programs that load and run from the READY prompt. This collection of tools serves a wide variety of purposes. Some of the tools are only for programming and are covered in more detail in the C64 OS Programmer's Guide. C64 Tools can be found in the directory:
//os/c64tools/
Alias Creator
//os/c64tools/:alias creator
This is a BASIC program that can create alias files on any App Launcher desktop. The program must be run while the default directory is the desktop directory. Switch to the desktop directory, then load and run the program by specifying the path to the c64tools directory in the load command.
Without JiffyDOS (assuming device 8):
open15,8,15,"cd//os/c64tools/":close15 load"//os/c64tools/:alias creator",8 run
With JiffyDOS:
@cd//os/desktop ↑//os/c64tools/:alias creator
The program is a simple wizard that asks questions for which you supply answers. New aliases are created and placed on the specified desktop. The aliases take a default color and position but can be later repositioned and colored using App Launcher.
Backup
//os/c64tools/:backup Requires: JiffyDOS
This is a BASIC program to recursively backup any directory from one device to a different device. The directory processing is done in standard BASIC but requires features of JiffyDOS to perform the actual file copying.
To use this program, change into the starting directory on the source device where the backup should begin. Load and run backup, specifying the c64tools path in the load command. The following example could be used to backup the entire C64 OS system directory.
With JiffyDOS: (JiffyDOS is required anyway)
@cd//os/ ↑//os/c64tools/:backup
When backup runs, it asks for the source and destination device numbers. These must be different, as that is a requirement of the JiffyDOS two-drive copier. In order to work as expected, the destination device must be a modern storage device.
Backup asks for the name of the destination directory. This is used to collect together repeated backups of similar types. For example, if you were backing up the C64 OS system directory, you might call the destination directory "c64 os backups". But if you were backing up your documents directory you might call the destination directory "document backups". If a directory with this name does not already exist (in the root directory of the destination device) it will be created.
Next it asks for today's date in YYYY-MM-DD format. All of the files and subdirectories found in the current directory of the source device will be copied into a subdirectory with this date as the name. Naming the directory in this format is not strictly required, but is recommended. It guarantees that backups taken on different days will be kept separate; it helps you find your backups in the future; and the order (year, month, day) lets them sort chronologically in the C64 OS File Manager and other programs that sort directories alphabetically.
Lastly, backup asks if you want to perform a full or an incremental backup. You should perform full backups of important directories, periodically, but you can run incremental backups between full backups. Incremental backups complete faster by only backing up files which have changed since the last backup. Incremental backups are only possible from a source device with a functioning and well adjusted RTC. Each time backup is run, it creates and/or updates a file, "backup.ts.t", in the source directory. This file records the date and time of the previous backup. It is used by the incremental backup to omit files that were modified prior to this date. If "backup.ts.t" is deleted or cannot be found, an incremental backup will be automatically converted into a full backup.
C64 OS Setup
//os/c64tools/:c64os setup
This file is one of the required BASIC programs for an initial C64 OS installation. It is found in the root directory of a new C64 OS version 1.0 System Card. A copy of this file is also found in the C64 Tools directory. In fact, when a C64 OS installation is unarchived from a restore.car file, that installs an //os/c64tools/ directory that contains this setup program.
After the initial setup is complete, this program can be scratched from the root directory, in order to clean up the root directory. It can be loaded and run directly from the C64 Tools directory at a later time, in order to change the installation location of a C64 OS system directory. See Chapter 2: Installation → About Installation Location for more information about how to use C64 OS Setup.
C64 OS Booter
//os/c64tools/:c64os
The program called "c64os" is the C64 OS booter. The booter has to be in the root directory alongside the system directory. However, a fresh backup copy of the booter is also found in the C64 Tools directory. This can be copied back to the root directory if your original booter is scratched or damaged. The booter is also a self-modifying BASIC program. So if it somehow ends up self-modified in an inappropriate way, it's convenient to have a clean backup readily available.
This copy of the booter can also be used in the advanced process of creating multiple C64 OS installations in the same partition. See Chapter 8: File System → Multiple Installations for more information.
C64restore
//os/c64tools/:c64restore
This file is one of the required programs for an initial C64 OS installation. It is found in the root directory of a new C64 OS version 1.0 System Card. A copy of this file is also found in the C64 Tools directory. In fact, when a C64 OS installation is unarchived from a restore.car file, that installs an //os/c64tools/ directory that contains a copy of this program.
After installation is complete, this program can be scratched from the root directory, in order to clean up the root directory. It is convenient to have a backup copy here. This program is not intended to be loaded and run independently. It is a component that gets loaded and run automatically as part of the installation process.
CAR Search
//os/c64tools/:carsearch Requires: an SD2IEC
CAR stands for C64 Archive and is a file format produced by the C64 OS Application, C64 Archiver. The format supports 16-character PETSCII filenames, the CBM filetypes (PRG and SEQ), the file lock status, file size with byte precision, and nested subdirectories. The archive header contains an archive version number, an archive type code, date/time stamp of when the archive was created, and a short fixed-length note.
CAR Search is a BASIC program for previewing the contents of a CAR file. CAR files are used to distribute complete C64 OS installation archives, installation overlay archives, as well as general purpose archives. CAR Search can only be run from an SD2IEC. It depends on the ability to scan files, which means to efficiently skip an arbitrary number bytes forwards or backwards within a file.
Load the carsearch program, then make the SD2IEC the default device and change into the directory where the CAR file is located. Run the program. It reminds you that it can only be used on an SD2IEC and asks for the name of the CAR file. Enter the name, and press return. It then proceeds to output the header information, followed by a recursive directory listing of everything contained within the archive. CAR Search supports multiple CAR format versions.
Example, with JiffyDOS:)
///os/c64tools/:carsearch @#10 @cd//somedirectory/ run
Enter the name of a .car file in //somedirectory/ on device 10.
Configure
//os/settings/:configure
Note that the configure tool does not reside in the standard c64tools directory. The configure tool modifies settings files, and therefore it's kept in //os/settings/ instead, so it can relatively reference files in that directory.
Configure should be run once after a fresh install, or at least once before you start using the copy of C64 OS that comes pre-installed on the System Card (SD Card.) See Chapter 3: Configuration and Settings for more information about how to use the configure tool.
Novatext 1.2.2
//os/c64tools/:novatext 1.2 //os/c64tools/:novatext 1.2.2
Novatext version 1.2 is an easy-to-use PETSCII text editor written by Nick Rossi. It came bundled with Novaterm 9.6 and was included for being able to edit script files and other texts. Earlier versions were available in earlier versions of Novaterm. The complete source code of Novaterm 9.6 was later released.
Novatext 1.2 is not compatible with SD2IEC. However, Novatext 1.2.2 is a patched version that has been fixed to support reading and writing files with SD2IEC. Both the original and the patched version are included in the c64tools directory. The program has built-in help, which can be accessed with CONTROL+H. Novatext is very useful for editing any of the C64 OS text-based resources, such as settings files, menu definitions, and Application about files. It can also be used for editing SD2IEC swaplist files.
NOTE: Novatext is not compatible with IDE64.
PRGAlias Creator
//os/c64tools/:prgalias creator
PRG aliases are files which hold metadata about how a regular C64 PRG file is to be loaded and run. PRG alias files are stored in "//os/prg aliases". The PRG Runner Utility opens PRG aliases and uses them to launch into that program from within C64 OS.
PRGAlias Creator is a tool for creating and configuring PRG aliases. To use the tool, first change into the prg aliases directory. Then load and run PRGAlias Creator. It asks a series of questions about the program. You have to know ahead of time the answers to all of these questions. For example, if the program is found on a device that is not #8, is it capable of running from that device number, or should the source device be swapped to device #8 first? Does the program have a BASIC loader, or does it require jumping to the start address where the program is loaded to?
PRG Runner is also capable of mounting disk images and swaplists. These options can be specified with PRGAlias Creator, but the swaplist file has to be created by some other means.
Without JiffyDOS:
open15,8,15,"cd//os/prg aliases":close15 load"//os/c64tools/:prgalias creator",8 run
With JiffyDOS:
@cd//os/prg aliases ↑//os/c64tools/:prgalias creator
Turbo Macro Pro
//os/c64tools/:tmp
Turbo Macro Pro is a 6502 macro assembler for the Commodore 64. It was originally released in 1985 as Turbo Assembler by the German company, Omikron. It is now maintained by Style. There has not been a new release of the C64-native version of Turbo Macro Pro since v1.2 in 2006. It is available in numerous pre-assembled binaries. They are all considered version 1.2, but each has different assemble-time options enabled with support for various hardware configurations.
The version found in the c64tools directory is TMP+REU. Turbo Macro Pro v1.2 with support for 17xx REUs. This is the version of Turbo Macro Pro that was used to program and assemble all of C64 OS; its KERNAL, Libraries, Drivers, Toolkit Classes, Applications, Utilities and more. With this assembler and the headers, constants and macros files that are included with C64 OS, it is possible to use a Commodore 64 itself to create new C64 OS drivers, new libraries, toolkit classes, Applications and Utilities.
More information about how to use Turbo Macro Pro, how to use the C64 OS APIs, and to find source code samples and tutorials, see the C64 OS Programmer's Guide.
The STA 1272 Bug
According to this excellent video by 8-bit Show and Tell, there is a rare bug in TurboMacroPro. The version of TMP that is included on the C64 OS version 1.0 System Card has this bug. Although it is unlikely that you'll encounter this bug, a fixed version of TMP is available here:
II. Character Sets
C64 OS loads a new character set into memory. The character set resides in RAM under I/O, from $D000-$D7FF. The character set consists of uppercase and lowercase letters, numbers and standard symbols. Several symbols on a standard C64 have been replaced by their more standard equivalents from ASCII.
The upper half of the character set is mostly the reverse of the lower half, with a few exceptions. The final block of 32 characters in each half are reserved from graphical user interface elements. 9 of those, from each half, 18 characters total, are reserved from the Application or Utility to redefine.
Keyboard Mapping for Special Characters
| Key/Combination | Symbol | Description |
|---|---|---|
| pound (£) | \ | backslash |
| Up Arrow (↑) | ^ | circumflex |
| Left Arrow (←) | _ | underscore |
| SHIFT+asterisk (*) | ` | backtick |
| SHIFT+plus (+) | { | left brace |
| SHIFT+pound (£) | | | pipe |
| SHIFT+minus (-) | } | right brace |
| SHIFT+Up Arrow (↑) | ~ | tilde |
Lowercase (Block 1 and Block 5)
| ScreenCode | Symbol | Description | ScreenCode | Symbol | Description |
|---|---|---|---|---|---|
| 0 | @ | at-symbol | 128 | @ | at-symbol reversed |
| 1 | a | lowercase a | 129 | a | lowercase a reversed |
| 2 | b | lowercase b | 130 | b | lowercase b reversed |
| 3 | c | lowercase c | 131 | c | lowercase c reversed |
| 4 | d | lowercase d | 132 | d | lowercase d reversed |
| 5 | e | lowercase e | 133 | e | lowercase e reversed |
| 6 | f | lowercase f | 134 | f | lowercase f reversed |
| 7 | g | lowercase g | 135 | g | lowercase g reversed |
| 8 | h | lowercase h | 136 | h | lowercase h reversed |
| 9 | i | lowercase i | 137 | i | lowercase i reversed |
| 10 | j | lowercase j | 138 | j | lowercase j reversed |
| 11 | k | lowercase k | 139 | k | lowercase k reversed |
| 12 | l | lowercase l | 140 | l | lowercase l reversed |
| 13 | m | lowercase m | 141 | m | lowercase m reversed |
| 14 | n | lowercase n | 142 | n | lowercase n reversed |
| 15 | o | lowercase o | 143 | o | lowercase o reversed |
| 16 | p | lowercase p | 144 | p | lowercase p reversed |
| 17 | q | lowercase q | 145 | q | lowercase q reversed |
| 18 | r | lowercase r | 146 | r | lowercase r reversed |
| 19 | s | lowercase s | 147 | s | lowercase s reversed |
| 20 | t | lowercase t | 148 | t | lowercase t reversed |
| 21 | u | lowercase u | 149 | u | lowercase u reversed |
| 22 | v | lowercase v | 150 | v | lowercase v reversed |
| 23 | w | lowercase w | 151 | w | lowercase w reversed |
| 24 | x | lowercase x | 152 | x | lowercase x reversed |
| 25 | y | lowercase y | 153 | y | lowercase y reversed |
| 26 | z | lowercase z | 154 | z | lowercase z reversed |
| 27 | [ | left bracket | 155 | [ | left bracket reversed |
| 28 | \ | backslash | 156 | \ | backslash reversed |
| 29 | ] | right bracket | 157 | ] | right bracket reversed |
| 30 | ^ | circumflex | 158 | ^ | circumflex reversed |
| 31 | _ | underscore | 159 | _ | underscore reversed |
Numbers and Symbols (Block 2 and Block 6)
| ScreenCode | Symbol | Description | ScreenCode | Symbol | Description |
|---|---|---|---|---|---|
| 32 | space | 160 | space reversed | ||
| 33 | ! | exclamation point | 161 | ! | exclamation point reversed |
| 34 | " | double quote | 162 | " | double quote reversed |
| 35 | # | hash/pound | 163 | # | hash/pound reversed |
| 36 | $ | dollar-sign | 164 | $ | dollar-sign reversed |
| 37 | % | percent-sign | 165 | % | percent-sign reversed |
| 38 | & | ampersand | 166 | & | ampersand reversed |
| 39 | ' | apostrophe | 167 | ' | apostrophe reversed |
| 40 | ( | left parenthesis | 168 | ( | left parenthesis reversed |
| 41 | ) | right parenthesis | 169 | ) | right parenthesis reversed |
| 42 | * | asterisk | 170 | * | asterisk reversed |
| 43 | + | plus-sign | 171 | + | plus-sign reversed |
| 44 | , | comma | 172 | , | comma reversed |
| 45 | - | hyphen-minus | 173 | - | hyphen-minus reversed |
| 46 | . | period | 174 | . | period reversed |
| 47 | / | forward slash | 175 | / | forward slash |
| 48 | 0 | zero | 176 | 0 | zero reversed |
| 49 | 1 | one | 177 | 1 | one reversed |
| 50 | 2 | two | 178 | 2 | two reversed |
| 51 | 3 | three | 179 | 3 | three reversed |
| 52 | 4 | four | 180 | 4 | four reversed |
| 53 | 5 | five | 181 | 5 | five reversed |
| 54 | 6 | six | 182 | 6 | six reversed |
| 55 | 7 | seven | 183 | 7 | seven reversed |
| 56 | 8 | eight | 184 | 8 | eight reversed |
| 57 | 9 | nine | 185 | 9 | nine reversed |
| 58 | : | colon | 186 | : | colon reversed |
| 59 | ; | semi-colon | 187 | ; | semi-colon reversed |
| 60 | < | less-than-symbol | 188 | < | less-than-symbol reversed |
| 61 | = | equals-sign | 189 | = | equals-sign reversed |
| 62 | > | greater-than-symbol | 190 | > | greater-than-symbol reversed |
| 63 | ? | question-mark | 191 | ? | question-mark reversed |
Uppercase (Block 3 and Block 7)
| ScreenCode | Symbol | Description | ScreenCode | Symbol | Description |
|---|---|---|---|---|---|
| 64 | ` | backtick | 192 | ` | backtick reversed |
| 65 | A | uppercase a | 193 | A | uppercase a reversed |
| 66 | B | uppercase b | 194 | B | uppercase b reversed |
| 67 | C | uppercase c | 195 | C | uppercase c reversed |
| 68 | D | uppercase d | 196 | D | uppercase d reversed |
| 69 | E | uppercase e | 197 | E | uppercase e reversed |
| 70 | F | uppercase f | 198 | F | uppercase f reversed |
| 71 | G | uppercase g | 199 | G | uppercase g reversed |
| 72 | H | uppercase h | 200 | H | uppercase h reversed |
| 73 | I | uppercase i | 201 | I | uppercase i reversed |
| 74 | J | uppercase j | 202 | J | uppercase j reversed |
| 75 | K | uppercase k | 203 | K | uppercase k reversed |
| 76 | L | uppercase l | 204 | L | uppercase l reversed |
| 77 | M | uppercase m | 205 | M | uppercase m reversed |
| 78 | N | uppercase n | 206 | N | uppercase n reversed |
| 79 | O | uppercase o | 207 | O | uppercase o reversed |
| 80 | P | uppercase p | 208 | P | uppercase p reversed |
| 81 | Q | uppercase q | 209 | Q | uppercase q reversed |
| 82 | R | uppercase r | 210 | R | uppercase r reversed |
| 83 | S | uppercase s | 211 | S | uppercase s reversed |
| 84 | T | uppercase t | 212 | T | uppercase t reversed |
| 85 | U | uppercase u | 213 | U | uppercase u reversed |
| 86 | V | uppercase v | 214 | V | uppercase v reversed |
| 87 | W | uppercase w | 215 | W | uppercase w reversed |
| 88 | X | uppercase x | 216 | X | uppercase x reversed |
| 89 | Y | uppercase y | 217 | Y | uppercase y reversed |
| 90 | Z | uppercase z | 218 | Z | uppercase z reversed |
| 91 | { | left brace | 219 | { | left brace reversed |
| 92 | | | pipe | 220 | | | pipe reversed |
| 93 | } | right brace | 221 | } | right brace reversed |
| 94 | ~ | tilde | 222 | ~ | tilde reversed |
| 95 | reserved | 223 | reserved |
UI Characters (Block 4 and Block 8)
| ScreenCode | Symbol | Description | ScreenCode | Symbol | Description |
|---|---|---|---|---|---|
| 96 | Transparent | 224 | reserved | ||
| 97 | Commodore symbol | 225 | Commodore symbol reversed | ||
| 98 | up arrow | 226 | up arrow reversed | ||
| 99 | down arrow | 227 | down arrow reversed | ||
| 100 | left arrow | 228 | left arrow reversed | ||
| 101 | right arrow | 229 | right arrows reversed | ||
| 102 | analog clockface | 230 | analog clockface reversed | ||
| 103 | cycle arrows | 231 | cycle arrows reversed | ||
| 104 | … | ellipsis | 232 | … | ellipsis reversed |
| 105 | diagonal stripes | 233 | diagonal stripes reversed | ||
| 106 | checkbox unchecked | 234 | checkbox unchecked reversed | ||
| 107 | checkbox checked | 235 | checkbox checked reversed | ||
| 108 | radio button unselected | 236 | radio button unselected reversed | ||
| 109 | radio button selected | 237 | radio button selected reversed | ||
| 110 | Utility close button | 238 | Memory chip icon | ||
| 111 | Utility title bar | 239 | Shift symbol | ||
| 112 | © | copyright symbol | 240 | © | copyright symbol reversed |
| 113 | checkmark | 241 | checkmark reversed | ||
| 114 | 3 horizontal stripes | 242 | 3 horizontal stripes reversed | ||
| 115 | tick track | 243 | tick track reversed | ||
| 116 | tick track nub | 244 | tick track nub reversed | ||
| 117 | tab corner | 245 | tab corner reversed | ||
| 118 | 3 vertical stripes | 246 | 3 vertical stripes reversed | ||
| 119 | Custom 1 | 247 | Custom 10 | ||
| 120 | Custom 2 | 248 | Custom 11 | ||
| 121 | Custom 3 | 249 | Custom 12 | ||
| 122 | Custom 4 | 250 | Custom 13 | ||
| 123 | Custom 5 | 251 | Custom 14 | ||
| 124 | Custom 6 | 252 | Custom 15 | ||
| 125 | Custom 7 | 253 | Custom 16 | ||
| 126 | Custom 8 | 254 | Custom 17 | ||
| 127 | Custom 9 | 255 | Custom 18 |
III. Data Types
//os/s/:type.s
C64 OS data types are like simplified MIME types. A C64 OS data type consists of a 1-byte type code, and a 1-byte subtype code. Subtype codes are reused for each type code. There are thus 256 possible types and each type has 256 possible subtypes. Providing for a maximum of 65536 possible C64 OS data types.
New C64 OS data types are created by discussion and concensus in the community of developers. C64 OS data types are not valid, and should not be used, unless they are documented and listed on C64OS.com.
C64 OS Data Types (Type Codes)
| Constant | Value | Description |
|---|---|---|
| ct_text | 0 | Human readable text. |
| ct_appl | 1 | Application data, binary data. |
| ct_audio | 2 | Audio data, sound, music. |
| ct_image | 3 | Image data, pictures, graphics. |
| ct_video | 4 | Video data, animations, movies. |
C64 OS Data Subtypes (CT_TEXT: Subtype Codes)
| Constant | Value | Description |
|---|---|---|
| ct_pettxt | 0 | PETSCII encoded plain text. |
| ct_asctxt | 1 | ASCII encoded plain text. |
| ct_mtext | 2 | MText encoded markup text. |
| ct_email | 3 | Valid email address formatted text. |
| ct_weburl | 4 | Valid web URL formatted text. |
| ct_date | 5 | Date text in format YYYY-MM-DD. |
| ct_dattim | 6 | Date/time text in format YYYY-MM-DD HH:mm:ss |
| ct_fref | 7 | C64 OS serialized file reference formatted text. |
| ct_hexdec | 8 | Hexadecimal number formatted text. |
| ct_number | 9 | Valid number formatted text. |
| ct_tel | 10 | Valid telephone number formatted text. |
| ct_cal | 11 | C64 OS calendar event formatted text. |
| ct_html | 12 | HTML formatted text. |
| ct_xml | 13 | XML formatted text. |
C64 OS Data Subtypes (CT_APPL: Subtype Codes)
| Constant | Value | Description |
|---|---|---|
| ct_zip | 0 | PKZip formatted binary data. |
| ct_float | 1 | BASIC 5-byte floating point integer format. |
| ct_base64 | 2 | base64 encoded data. |
| ct_gzip | 3 | GZip formatted binary data. |
| ct_uuenc | 4 | Unix-to-Unix encoded data. |
C64 OS Data Subtypes (CT_AUDIO: Subtype Codes)
| Constant | Value | Description |
|---|---|---|
| ct_raw | 0 | Raw PCM formatted audio data. |
| ct_aiff | 1 | Audio interchange file format data. |
| ct_wave | 2 | RIFF/Wave audio encoded data. |
| ct_sid | 3 | PSID-wrapped SID audio data. |
| ct_mod | 4 | Amiga module music encoded data. |
| ct_mp3 | 5 | MP3 encoded audio data. |
| ct_midi | 6 | MIDI encoded music data. |
| ct_snd | 7 | SouND digital audio formatted data. |
C64 OS Data Subtypes (CT_IMAGE: Subtype Codes)
| Constant | Value | Description |
|---|---|---|
| ct_multc | 0 | C64 OS Multi-Color raw image data format. |
| ct_hires | 1 | C64 OS HiRes raw image data format. |
| ct_koala | 2 | Koala formatted image data. |
| ct_arts | 3 | Art Studio formatted image data. |
| ct_jpeg | 4 | JPEG formatted image data. |
| ct_gif | 5 | GIF formatted image data. |
| ct_4bit | 6 | GoDot 4-bit image formatted data. |
| ct_3icon | 7 | C64 OS 3x3 icon format. |
C64 OS Data Subtypes (CT_VIDEO: Subtype Codes)
| Constant | Value | Description |
|---|---|---|
| ct_hdx | 0 | C64 HiRes encoded video data. |
See Chapter 4: User Interface → Clipboard for an example of the internal use C64 OS data types.
IV. Drivers
//os/drivers/ //os/settings/:drivers.t
In order for a driver to be available for C64 OS to use, it must be put in the //os/drivers/ directory. There are several driver types, each type may be occupied by a single driver at a time. Drivers and optional data are specified in the //os/settings/:drivers.t file.
Pointer Drivers
| Type | Filename | Description | Available |
|---|---|---|---|
| pointer | ptr.1351 mouse | Driver for 1351 and compatible mice in port 1. | v1.0 |
| pointer | ptr.1351 port2 | Driver for 1351 and compatible mice in port 2. | v1.01 |
| pointer | ptr.c128 keypad | Driver for using C128 numeric keypad as mouse pointer input. | v1.0 |
| pointer | ptr.joystick 1 | Driver for using a standard joystick in port 1 for mouse input. | v1.0 |
| pointer | ptr.joystick 2 | Driver for using a standard joystick in port 2 for mouse input. | v1.0 |
| pointer | ptr.koala pad | Driver for using a Koala Pad for proportional mouse pointer input. | v1.0 |
| pointer | ptr.light pen | Driver for using a light pen for mouse pointer input. | v1.0 |
| pointer | ptr.micromys 1 | Driver for micromys mouse adapter in port 1. | v1.02 |
Joystick (Game) Drivers
| Type | Filename | Description |
|---|---|---|
| joystick | joy.nes 2 player | Driver for 2 joysticks, with extensions for NES Controller Select/Start mod. |
| joystick | joy.nes 4 player * | Driver for 4 joysticks, with extensions for NES Controller Select/Start mod. |
Realtime Clock Drivers
| Type | Filename | Description |
|---|---|---|
| realtime clock | rtc.ds3231 i2c |
Driver for reading date/time from DS3231 Arduino module over User Port i2c bus. |
| realtime clock | rtc.iec device |
Driver for reading date/time from CMD HD, CMD FD, RAMLink, IDE64 and SD2IEC. |
| realtime clock | rtc.manual |
Driver that reads manually configured date/time from //os/settings/:time.manual.t |
| realtime clock | rtc.ultimate |
Driver for reading date/time from 1541 Ultimate II+ and Ultimate 64 over Ultimate Command Interface. |
See Chapter 8: File System → Drivers for more information about drivers.
V. File References
C64 OS uses a unified file reference format. It consists of 4 parts separated with colons.
device#:partition#:filename:path
On modern devices, which support partitions, specifying 0 for the partition is a reference to the partition directory.
device#:0::
A filename can be omitted for a file reference to be a reference to a path only.
device#:partition#::path
Paths use the standard path structure of CMD devices, SD2IEC and IDE64. Two leading slashes for the root directory, one leading slash for the current directory. Followed by a subdirectory name and a trailing slash. Multiple subdirectories can be appended, but each one, including the last needs its trailing slash.
Slashes in the name of a subdirectory are not permitted.
See Chapter 8: File System → File References for more information about file references, their component parts and directory path structure.
VI. KERNAL
//os/kernal/ //os/settings/:modules.t
The C64 OS KERNAL is divided into 10 modules. There can be different versions of modules, which are selected and loaded by the booter by reference to the modules.t file in the settings directory.
A KERNAL module lookup table is installed to the end of $CFFF and down, by the C64 OS booter. The KERNAL plus lookup table from $CFFF down to around $8200. The final page of available heap memory is configured by the booter based on hardware configuration.
C64 OS KERNAL Modules
| Module | Description |
|---|---|
| file | File reading/writing. Clipboard. File reference conversion. |
| input | Produces and queues keyboard, mouse, and game controller input events. |
| math | 16-bit multiplication and division routines. |
| memory | Paged memory allocator. Malloc and Free. REU support routines. |
| menu | Implements the C64 OS menu and status bars and all their functionality. |
| screen.cpu | Screen compositing routines. Low-level contextual drawing system. |
| screen.reu | REU-assisted screen compositing routines. Low-level contextual drawing system. |
| service | Application, Utility and shared library loading. IRQ service routine. |
| string | String manipulation routines. Base conversion routines. |
| timers | Enqueues timer structures. Processes timers. Asynchronous message passing. |
| toolkit | Support routines for toolkit environment, event passing and hitting detection. |
NOTE: The booter chooses to load either screen.cpu or screen.reu depending on whether an REU was detected earlier in the boot process.
VII. Libraries
//os/library/
In order for a library to be available for C64 OS to use, it must be put in the //os/library/ directory. Libraries are relocatable and single instances loaded into memory can be shared by multiple processes to conserve memory.
Shared libraries can also be sourced out of an Application's bundle. This allows Applications to parcel their functionality into libraries, without needing to install the library in the system-wide library directory. Libraries are managed by the services KERNAL module.
Libraries included with C64 OS
| Library | Description | Available |
|---|---|---|
| calendar.lib | Standard calendar routines, such as leap year and day of week. | v1.0 |
| checksum.lib | Provides standard checksum routines; CRC8, CRC16, CRC32. | v1.02 |
| cmp.lib | Comparison routines for directory and other sorting. | v1.0 |
| crash.lib | Crash handler that loads the crashscreen when an exception is unhandled. | v1.0 |
| datetime.lib | String to integer and vice versa date/time conversion routines. | v1.0 |
| dir.lib | Directory loading and parsing. Supports all C64 OS supported devices. | v1.0 |
| fcopy.lib | File copy for a single file between any two file references. Supports REU. | v1.0 |
| flock.lib | File lock routines for 1541, 1571, 1581, CMD HD, FD, RAMLink and IDE64. | v1.0 |
| gfx.lib | Routines for supporting status bar raster split when graphics data is available. | v1.0 |
| grab.lib | Library for grabbing and saving a screenshot of the standard UI. | v1.0 |
| i2c.lib | Library that implements the I2C bus over the User Port. Two versions exist. | v1.0 |
| iec.lib | Library that scans the IEC bus and builds the detected devices table. | v1.0 |
| path.lib | Library with routines for standard path and file reference manipulation. | v1.0 |
| places.lib | Library of routines to load, read and manage recents and favorites. | v1.0 |
| qsort.lib | Quick Sort routines paired with cmp.lib. Used by dir.lib to sort directories. | v1.0 |
| rec.lib | Routines for detecting presence and capacity of 17xx REU. Used by memory KERNAL module. | v1.0 |
| sidplay.lib | Library for loading PSID format SID music. Fetches metadata and controls playback. | v1.0 |
| utils.lib | Builds and links the Utilities menu from //os/settings/:utilities.m definitions file. | v1.0 |
| wrap.lib | Softwraps text. Builds a linked-line table used by the TKText Toolkit class. | v1.0 |
See Chapter 8: File System → Libraries for more information about shared libraries.
Configuring the I2C Bus
I2C is a simple serial bus for communication between a computer or microcontroller and low-speed peripheral ICs. The I2C library provides an implementation of the I2C bus that allows C64 OS to communicate with I2C peripherals connected to the User Port.
An I2C bus only requires two communications lines. The Commodore 64's KERNAL ROM also provides built-in support for RS-232 over the User Port. Both communications protocols use only a subset of the User Port's available communications lines. The lines used for RS-232 cannot be changed, however, and there are many WiFi and traditional modems and other RS-232 devices fixed to the lines used by the KERNAL ROM.
It is possible to drive the I2C bus via lines not used by RS-232. This allows the use of I2C and RS-232 devices on the User Port at the same time without interference. However, GEOS also has some software that can use the I2C bus, but it uses lines which overlap with RS-232. For this reason, C64 OS provides two versions of the I2C library. One which is compatible with RS-232 devices but not compatible with GEOS. The other with the compatibility priorities reversed. You should choose which one to use based on your needs. If you want to use I2C in both C64 OS and in GEOS, select the GEOS compatible I2C library. Otherwise, go with the version that is compatible with RS-232.
There are two versioned library files:
| File | Data Lines | CIA Port B | Compatibility |
|---|---|---|---|
| i2c.lib.ver_cd.r | C and D | bits 0 and 1 | GEOS, but not RS-232 |
| i2c.lib.ver_ef.r | E and F | bits 2 and 3 | RS-232, but not GEOS |
C64 OS loads the library called i2c.lib.r. To change the version you're using, start by scratching the file i2c.lib.r, then, depending on which User Port lines your I2C bus is connected to, copy the corresponding i2c.lib.ver_XX.r back to i2c.lib.r. For example:
With JiffyDOS:
@cd//os/drivers/ @s:i2c.lib.r @c:i2c.lib.r=i2c.lib.ver_ef.r
This can also be done with the C64 OS File Manager, but a reboot may be required for the change to take place.
See the weblog post I2C Serial Bus in 6502 for a technical deep dive on how to use I2C on your Commodore 64.
VIII. Settings
//os/settings/
C64 OS settings are stored in human-readable settings files in the //os/settings/ directory. Many of these files are configurable with C64 Utilties or Tools, others can be manually customized using a text editor, such a Novatext.
It is highly recommended that you backup any settings file before manually editing it. They are sensitive to extra spaces and carriage returns that you can't see. Use the C64 tool //os/c64tools/:datacheck to list a settings file's data one byte at a time. If a manual change doesn't work, compare it against the backup for trailing carriage returns or lack thereof.
Standard Settings Files
| File | Description |
|---|---|
| components.t | Lists the components that are loaded by the booter before everything else. |
| config.t | CPU busy indicator status, global keyboard shortcuts, and default status bar mode. |
| drivers.t | Lists the drivers and their arguments for each of the supported driver types. |
| docs.path.t | File reference to "Documents" standard place. |
| games.path.t | File reference to "Games" standard place. |
| homebase.t | Stores the last accessed Homebase Application: App Launcher or File Manager. |
| memory.t | Specifies memory Utility. REU banks for fast app switching. Memory display format. |
| modules.t | Specifies the KERNAL modules to be loaded by the booter. |
| mouse.t | Stores the mouse pointer, color, handedness, acceleration and double click speed. |
| music.path.t | File reference to "Music" standard place. |
| pictures.path.t | File reference to "Pictures" standard place. |
| system.t | Specifies the name of the system directory for this installation of C64 OS. |
| theme.cus.t | Defines the customized theme colors selected in the Themes Utility. |
| theme.day.t | Specifies the colors for the Daylight color theme. |
| theme.mid.t | Specifies the colors for the Midnight color theme. |
| theme.t | Specifies the currently active theme colors. |
| time.manual.t | Holds a static date/time string that is read and written by the rtc.manual driver. |
| time.t | Specifies the time Utility. 12/24H format, and menu bar clock settings. |
| tkclasses.t | Lists the non-relocating Toolkit classes loaded by the booter. |
| utilities.m | Menu definitions file read by utils.lib to build the Utilities menu. |
| version.t | Lists the C64 OS version number. Displayed in About C64 OS Utiliity. |
See Chapter 3: Configuration and Settings for more information about customizing settings.
See Chapter 8: File System → Settings for more information about settings and the settings directory.
IX. SID Music
//os/library/:sidplay.lib.r
C64 OS includes a shared library, sidplay.lib.r, which can be loaded and used by Applications and Utilities to load and play SID music in PSID format. There are, however, numerous restrictions and caveats.
Unlike text data, or digital audio, or graphics data, SID music is effectively 6502 executable code. The data for the music is incorporated into custom player code, used to achieve unique and advanced sound effects. Typically a piece of SID music is composed and assembled in cooperation with a game or demo developer. The developer and the musician negotiate on things like heap memory amount and location, available zero page addresses, acceptable CPU utilization, and other special hardware requirements for things like embedded digital samples.
It is problematic to combine arbitrary SID music with an operating system, such as C64 OS, because the two were not originally designed to work together. Memory in C64 OS is dynamically allocated. There is no way to guarantee that a given fixed address range will always be available. Sidplay lib checks the PSID headers and the file's overall size to determine the start address and length of memory required. It then checks the memory allocation table to see if that memory is available. If it is available, sidplay.lib manually marks that memory as allocated and loads the SID data into that block. However, if it is not available, in whole or in part, you are simply out of luck and the library reports back to the Application that it is unable to load that SID.
An additional problem is zero page memory usage. Neither the SID music itself, nor the PSID headers, explicitly indicate which zero page addresses the music will modify while playing. In C64 OS, most of zero page is already manually/statically allocated to various system-level processes. Most SID music, which makes arbitrary use of zero page, will almost certainly cause C64 OS to crash. C64 OS reserves 4 consecutive zero page addresses (enough for 2 pointers) just for SID music use. Many SIDs, although not all, can be relocated using a cross-platform tool such as Sidreloc by Linus Åkesson (aka LFT) to use the zero page memory address that are explicitly reserved for SID music.
Notes for SID Relocation
Available Zero Page for SIDs in C64 OS: $B0, $B1, $B2, and $B3
Recommended Relocation Start Address: $2000
sidplay.lib.r does not support NMI-driven digis in SID music.
X. System Directory
Below is an outline of the main structure of the C64 OS system directory. Some of these system subdirectories are broken down into further detail in the sections that follow.
| Directory/File | — | Description |
|---|---|---|
| c64os | The main C64 OS booter. | |
| //os/ | The C64 OS system directory. | |
| applications/ | Installed Applications. | |
| Hello World | Bundle for Application "Hello World". | |
| booter | KERNAL booter. | |
| c64tools/ | Useful non-C64-OS-native programs | |
| calendar/ | System wide calendar events. | |
| 2019-07/ | Calendar events for July 2019. | |
| 4 | Calendar events data file for July 4th 2019. | |
| charsets/ | Character sets. | |
| boot.charset | Boot screen's logo character set | |
| main.charset | Main character set; letters, numbers, symbols. | |
| ui.charset | User interface character set | |
| clipboard/ | Current clipboard and additional clippings. | |
| 0.t | Current clipboard data type and size. | |
| 0.d | Current clipboard data content. | |
| desktop/ | App Launcher's multiple desktops. | |
| 1/ | Aliases on desktop 1. | |
| Hello World | Alias to application "Hello World". | |
| 1.p | Background PETSCII art desktop 1. | |
| 2/ | Aliases on desktop 2. | |
| 2.p | Background PETSCII art desktop 2. | |
| docs/ | Documentation | |
| drivers/ | Hardware drivers | |
| h/ | Programming headers | |
| icons/ | Library of standard icons. | |
| kernal/ | C64 OS KERNAL modules. | |
| library/ | Components and libraries. | |
| pointers/ | Mouse pointers | |
| prg aliases/ | Aliases to traditional C64 software. | |
| s/ | Programming macros and constants. | |
| screengrabs/ | Screengrab saves screenshots to here. | |
| services/ | Special service applications. | |
| App Launcher | An application launching, desktop-like environment. | |
| File Manager | A file management application. | |
| settings/ | System settings. Globally saved Utility state files. | |
| temporary/ | Temporary files are scratched during boot up. | |
| tk/ | Toolkit class files and headers. | |
| utilities/ | Installed Utilities. | |
| Calculator | Executable file for Utility "Calculator". | |
| Today | Executable file for Utility "Today". |
XI. Toolkit Classes
Below is the list of Toolkit classes and the C64 OS version number in which they first became available. There are two types of classes. The core set is built-in and always memory resident. Relocatable classes are loaded and linked by an Application or Utility when they are needed.
The classes are listed in alphabetical order, but grouped and indented according to their inheritence.
| Class | Type | Description | Available |
|---|---|---|---|
| TKObj | Core | The root class from which all others descend. | v1.0 |
| TKView | Core | The root view from which all class that handle events descend. | v1.0 |
| TKCtrl | Core | The abstract class from which all interactive controls descend. | v1.0 |
| TKButton | Core | Serves as a push button, cycle button, checkbox or radio button. | v1.0 |
| TKDatePick | Relocatable | A date picking class. Embeds three managed cycle buttons for date parts. | v1.0 |
| TKInput | Relocatable | A single line text input class, with selections, cut, copy and paste. | v1.0 |
| TKRating | Relocatable | A 5-star rating control. Takes customizable on and off characters. | v1.0 |
| TKSBar | Core | A horizontal or vertical scroll bar with arrow buttons and a draggable nub. | v1.0 |
| TKTimePick | Relocatable | A time picking class. Embeds cycle buttons for time parts. 12H and 24H mode. | v1.0 |
| TKTimer | Relocatable | Shows 3 double-high time segments. Has timer and stopwatch mode. | v1.0 |
| TKDirInfo | Relocatable | Shows a directory info bar, number of items and available capacity. | v1.0 |
| TKFileMeta | Relocatable | Shows multi-line file metadata: file size, date modified, and CBM file type. | v1.0 |
| TKIcon | Relocatable | Renders an icon of custom chars, 1x1, 2x2, 3x3, etc. with click event. | v1.0 |
| TKLabel | Core | A single line text label with left, right, and center justification. | v1.0 |
| TKLabelBox | Relocatable | Adds a label and containing box around its content views. | v1.0 |
| TKList | Relocatable | A list with delegate methods for retrieving row count and content. | v1.0 |
| TKTable | Relocatable | A multi-column list with delegate methods for retrieving cell count and content. | v1.0 |
| TKPBar | Relocatable | Shows an interactive path reflecting the path of the open file reference. | v1.0 |
| TKPlaces | Relocatable | Shows a list of devices and embeds a TKList for recents and favorites. | v1.0 |
| TKScroll | Core | An class that manages two TKSBars plus one content child that scrolls. | v1.0 |
| TKTCols | Relocatable | Adds resizable column headers and coordinates with a TKTable content view. | v1.0 |
| TKText | Relocatable | A multi-line text display class. Supports soft wrapping and MText rendering. | v1.0 |
| TKSplit | Core | An organization class that divides an area horizontally or vertically. | v1.0 |
| TKTabs | Core | An organization class that presents a set of tabs. | v1.0 |
XII. Glossary of C64 OS Terminology
Below is a list terms used in C64 OS with a brief explanation of its meaning.
0...9
1351 mouse - A 2-button proportional mouse for the C64 and C128, released by Commodore in 1987. Supported by C64 OS with the correct pointer driver. (See also, driver, pointer.)
1541 Ultimate II+ - A multi-purpose oversized cartridge produced by Gideon's Logic. Provides many features, such as a 17xx REU (upto 16MB), GEORAM, Alternative KERNALs, and up to 2 highly compatible disk drives (1541, 1571, 1581) which backend on disk images stored on modern media. (See also, disk image, 1541/1571/1581, RAM, GEORAM, KERNAL, REU (17xx).)
1541/1571/1581 - Legacy floppy disk drives produced by Commodore. The 1541 uses single-sided 5.25" disks with a storage capacity of 664 blocks. The 1571 is 1541 compatible but can write double-sided 5.25" disks with a storage capacity of 1328 blocks. The 1581 uses double density 3.5" disks with a storage capacity of 3160 blocks. These drives do not support subdirectories. (See also, block, legacy device, subdirectory.)
17xx REU - RAM Expansion Unit. (See, REU (17xx).)
6502/6510 - The 6502 is a classic 8-bit CPU designed in the 1970s that powers many home computers and game consoles from the late '70s and early '80s. The 6510 is an instruction-set compatible variant of the 6502 used in the Commodore 64. In the C64 it is clocked at approximately 1 MHz.
A...
alias - An alias is a file that appears on the desktop in App Launcher, which can be used to open its corresponding C64 OS Application or Utility, or regular C64 software by means of a PRG alias and the PRG Runner Utility. (See also, App Launcher, PRG alias, Utility.)
anchor - A term used with selections. When a selected item is the anchor, the selection range can be extended above or below that anchor, but the anchor remains the fixed point. With discontiguous range selections, the anchor point can be moved to the edge of a new range. There can only ever be one anchor. (See also, selection.)
API - Application Programming Interface. An API is a published set of functions, routines, data structures, methods and/or properties that an Application (or other software) makes use of to acquire functionality provided by an operating system or one of its components.
App Launcher - One of two Homebase Applications in C64 OS. App Launcher has 5 configurable desktops, upon which aliases to other software can be added and arranged. (See also, alias, desktop, File Manager, home (Homebase).)
Application - An Application (with a capital A) is a special kind of C64 OS program. It has a bundle for resources that is stored in //os/applications/. One Application runs at a time. It defines the set of menus in the menu bar and sets the custom message in the status bar. (See also, bundle, menu bar, status bar.)
ASCII - American Standard Code for Information Interchange. A 7-bit character encoding standard first published in 1963. Commonly used on older PCs. Commodore 8-bit computers using PETSCII, an alternative character encoding requiring conversion to and from ASCII. (See also, PETSCII, text.)
assembly language - A programming language that uses easy-to-remember mnemonics for a CPU's instructions and standardized syntax to represent their various addressing modes. C64 OS was written entirely in 6502 assembly language. Assembly language provides the greatest flexibility in code optimization and behavior.
assign - An assign is an assignment of an Application or a Utility to a file type and extension. The Opener Utility is used to create and update assigns. The list of current assigns can be found in //os/settings/assigns/. (See also, Application, extension, file type, Opener, Utility.)
B...
backdrop - These are low-resolution images that can be selected to appear behind the aliases on a desktop in App Launcher. A backdrop is a SEQ file containing 1000 bytes of screencodes, no more no less. Backdrops can be created with the screenedit tool. (See also, alias, App Launcher, desktop, screencodes, SEQ, tool.)
bank - A bank is a unit of memory that can be seen at a time by a chip. Usually a bank can be switched or swapped in some convenient way. The VIC-II can see 16KB at a time, and the C64's main memory can be considered to have 4 VIC-II banks. The 6510 CPU can see 64KB at a time, and a 17xx REU can be divided up and contain from 2 to 256 banks of 64KB. (See also, 6502/6510, CPU, REU (17xx), VIC-II.)
block - A block is a standard unit of storage on a C64 storage device. A block on disk is 256 bytes, however, due to the way the file system works, only 254 bytes per block can be used for data storage. (See also, cluster, file system.)
boot - This term comes from the word bootstrap and the idiom, to pick oneself up by one's bootstraps. A bootstrap loader is a small amount of code that starts off from nothing and gets everything else necessary loaded in. The verb to boot means to start up. (See also, booter.)
boot drive - The boot drive is the storage device upon which C64 OS's system files and booter are installed. (See also, boot, system device (system drive).)
booter - The program that boots C64 OS is called the booter. C64 OS has two booters, c64os is a BASIC program which must be in the root directory, and //os/:booter which is written in assembly and is also known as the KERNAL booter. (See also, boot, KERNAL, root directory.)
build The build number is a technical version number. It is stored in //os/settings/:build.t. It can be viewed using the About C64 OS Utility. Click the version number to toggle to the build number (available in v1.04.) The build number is in the format {primary_version}.{secondary_version}.{YYMMDD} where YYMMDD is a 2-digit year, month and day when the current build of C64 OS was packaged up. E.g., 1.02.230105 means version 1.02, built on January 5, 2023. (See also, version.)
bundle - A bundle is a subdirectory that contains a specific set of structured files. A C64 OS Application consists of a bundle; a subdirectory that contains main.o, menu.m, about.t, icon.charset, etc. Bundles are useful for containing and organizing multiple resources that are stored as separate files. (See also, icon, subdirectory.)
C...
CAR - A CAR file is a C64 Archive file. These files contain files and nested subdirectories. They store filenames in PETSCII, along with other CBM FS metadata. CAR files are created with the C64 Archiver Application, and can be extracted with the Installer Utility or the c64restore tool during a complete C64 OS installation. (See also, Application, install, metadata, PETSCII, subdirectory, tool, Utility.)
case sensitive/insensitive - Case refers to upper and lower case letters. Case sensitivity means the case matters, and upper and lower case letters cannot be interchanged. Commodore file systems are case sensitive. Two files may exist which differ only by case. And if a process searches for a file using case that isn't a perfect match the file will not be found. The FAT file system used on SD2IEC (for directories and files not .p00/.s00 wrapped) are case insensitive. Two files cannot co-exist in the same directory, with the same name, that differs only by case. (See also, directory, FAT (32/16), file system, p00, s00, SD2IEC.)
channel - A channel is a communications pathway, typically associated with a number to keep multiple channels identified. C64 storage devices support 16 channels. 0 is dedicated to loading directories and program data, 1 is for saving program data. 15 is a special channel reserved for sending commands and retrieving command results and status information. Channels 2 to 14 are generic read/write channels. Commodore's documentation also sometimes refers to the C64 as having an input and an output channel. These channels are always assigned to a device. The keyboard device is assigned by default to the input channel, and the screen device is assigned by default to the output channel. (See also, command channel, device.)
character mode - The VIC-II chip has several native display modes. Two bitmap modes which require 8KB of memory to store bitmap data, plus 1KB to 2KB of memory to store color data. Manipulating bitmap mode is slow due to the large size of the bitmap data. The VIC-II also offers a character mode. Character mode requires a 2KB character set bitmap, 1KB of color data, and 1KB of character indexes called screencodes, for a total of just 4KB. Manipulating what is shown on screen is very fast because changing a single screencode changes what is displayed in an entire 8x8 pixel region of the screen. (See also, character set, native, screencodes, VIC-II.)
character set - A character set is a 2KB bitmap. Every 8 sequential bytes represent the bitmap data of an 8x8 pixel character. The C64 comes with two character sets in a 4KB ROM chip, sometimes called the character generator. C64 OS uses a custom character set stored in RAM from $D000 to $D7FF. A character set is sometimes called a charset. (See also, character mode, RAM, ROM.)
checksum - A checksum is a mathematical technique used to produce a maximally unique output number given an arbitrary quantity of input data. C64 OS (available in v1.02) includes a checksum library, which provides CRC8, CRC16 and CRC32 routines. These produce a 1 byte, 2 byte and 4 byte output number respectively. When the contents of a file are passed through a checksum routine a number is produced for that file. The algorithm is designed such that if any single byte of input is changed the output will be radically different. Although there are an infinite number of input streams that can produce any given checksum, it is highly unlikely that any accidental data corruption will result in the same checksum value. Thus, checksums can be used to reliably test for data integrity. (See also, library.)
class (Toolkit) - C64 OS includes an object-oriented user interface Toolkit. Object-oriented environments consist of a hierarchy of classes. A subclass descends from another and inherits the properties and behaviors of its parent class or superclass. The subclass has the ability to add new properties and new behaviors and to customize the behaviors of its parent. C64 OS includes 9 classes that are permanently memory resident, plus many more useful classes (a continually expanding set) that can be loaded at runtime by Applications and Utilities to build rich, powerful and consistent user interfaces with minimal coding effort. (See also, Toolkit.)
clipboard - The clipboard is a temporary holding place for a piece of data with an associated data type. C64 OS's clipboard data is stored in //os/clipboard/. The KERNAL has calls to allow an Application, Utility or something else, like a library, driver or Toolkit class, to write data to the clipboard. The KERNAL has other calls for reading the clipboard data in. By making use of the common clipboard API, different Applications and Utilities can exchange data even though they were never written with each other in mind. The clipboard provides a very powerful advantage to using and developing software for C64 OS. (See also, API, data type, KERNAL, library, place.)
close (file) - In order to read data from a file, or write data to a file, the file must first be opened. An opened file must later be closed. Since C64 OS can only open a limited number of files at the same time, it is very important that files be closed when they are no longer required to be open. Closing files also frees up resources in the device on which the file is stored. (See also, open.)
cluster - On CMD and CBM file systems data is stored in 256-byte blocks. On IDE64 data is stored in 512-byte blocks. On FAT16 and FAT32 file systems, which is the native file system used by SD2IEC, the equivalent of a block is called a cluster. The cluster size used by a partition is set when it is formatted, and the cluster size can vary from partition to partition. The minimum cluster size is 512-bytes. The blocks free count reported in an SD2IEC directory is a count of free clusters. Two different files cannot share a cluster. Therefore every file must use a minimum of one cluster. Large cluster sizes allow the FAT file system to access greater total storage, but at the expense of wasting more space when storing small files. (See also, block, directory, FAT (32/16), file system, IDE64, native, partition, SD2IEC.)
CMD FD - The CMD FD is a 3.5" floppy disk drive produced by Creative Micro Designs during the 1990s. It has two models, the FD-2000 and the FD-4000. The 2000 reads and writes high density 2MB floppies, while the 4000 reads and writes even higher capacity 4MB floppy disks. Both drives are backwards compatible with Commodore's 1581 disk drive. CMD FD disks can be partitioned just like a CMD HD, and native mode partitions support nested subdirectories. (See also, 1541/1571/1581, CMD HD, native, partition, subdirectory.)
CMD HD - The CMD HD is a series of harddisk drives produced by Creative Micro Designs during the 1990s. It came in several models, 20, 40, 100, 200, etc. based on the size of the SCSI harddrive mechanism inside. The internal mechanism can be upgraded later, and other than that all models are the same. The CMD HD supports up to 255 partitions, and native mode partitions may be up to a maximum of 16MB, allowing the CMD HD to access up to 4GB of storage. Native mode partitions supported nested subdirectories. The CMD HD supports much faster access times when connected via a parallel cable to a CMD RAMLink. (See also, CMD FD, native, partition, RAMLink, SCSI, subdirectory.)
command channel - C64 storage devices support 16 channels, numbered 0 to 15. 15 is special; It is called the command channel. Commands sent to the drive's DOS are sent over the command channel, and the results are read back from the command channel. For example, to read a CMD HD, FD, RAMLink, IDE64 or SD2IEC's realtime clock (RTC), a command (e.g., "t-ra") can be sent over channel 15. The result read back is the date and time. The commands that can be sent over the command channel depend on the features supported by the DOS that is on that device. (See also, channel, RTC.)
COMMODORE (key) - The COMMODORE key is found at the lower left corner of the C64's keyboard. It has numerous purposes from the READY prompt. In C64 OS it is used as a general purpose modifier key. It can be combined with other keys to trigger menu options, or with mouse clicks to modify the result of the click. For example, COMMODORE-clicking a scroll bar's up or down button causes the content to scroll all the way to the top or bottom, respectively. (See also, modifier keys.)
component - A C64 OS component is a small program that is loaded and run during boot up. The booter references //os/settings/:components.t for a list of components to be loaded and the order to load them. Each line also includes a code allowing for components to specify if they are to be left in memory, run immediately and then purged from memory, or loaded temporarily but deferred from running until all other components have been loaded. The list of components allows the C64 OS boot up process to be customized. Some components are only necessary if certain hardware is being used. (See also, boot, booter, load (file/directory), settings file.)
CONTROL (key) - The CONTROL key is found on the left side second row down of the C64's keyboard. It has numerous purposes from the READY prompt. In C64 OS it is used as a general purpose modifier key. It can be combined with other keys to trigger menu options, or with mouse clicks to modify the result of the click. For example, CONTROL-clicking the title bar of a Utility toggle's that Utility in and out of window shade. (See also, modifier keys, Utility, window shade.)
control (Toolkit) - A Toolkit control is any instance of a class that descends from the TKCtrl class. This includes, push buttons, cycle buttons, radio buttons, checkboxes, rating control, scroll bars, text input fields, etc. All controls support mouse and keyboard events, hold a piece of data (number or string,) and store information about what to call when the control is triggered. Controls also maintain state, active/inactive, enabled/disabled, first key, etc. (See also, class (Toolkit), event, Toolkit.)
copy job - A copy job is a special job data structure that is provided by an Application to the Copy Utility. It provides the Utility with a set of instructions for source and destination information, validation callback and other settings used for performing a multi-file and recursive copy operation. (See also, job, Utility.)
CPU - The Central Processing Unit. The CPU is the microprocessor that interprets and executes program code. The C64's CPU is the 6510, a variant of the 6502. (See also, 6502/6510.)
CPU busy indicator - If a process (an Application, a Utility, a library or any other code) causes the CPU to be occupied, preventing it from passing through the operating system's main event loop, the CPU busy indicator becomes active and starts animating. The CPU busy indicator is displayed as a small ticking clockface in the upper left corner of the screen, overtop of the Utilities menu icon. The CPU busy indicator can be disabled using the Configure Tool. (See also, CPU, icon, library, tool, Utilities menu.)
D...
datacheck - datacheck is a tool found in //os/c64tools/. It is written in BASIC and can be used to view the binary contents of a file from the READY prompt. It is useful for seeing hidden characters such as line endings and spaces in settings and other files. (See also, settings file, state file, tool.)
data type - A C64 OS data type is a two-level (generic/specific) description of how some data is formatted. There is a very limited set of generic types, text, audio, image, video, etc. Each generic type can have up to 256 subtypes. For example, text/plain, text/mtext, text/xml, etc. File's often hold data that has a data type. The data type of a file is identified by its filename extension. Extensions are mapped to data types. Data types should not be confused with file types. (See also, extension, file type, text.)
data type loader - A data type loader is a special purpose program designed to open a file of a certain file type and filename extension, by which the file's data type is identified. The data type loader then allocates memory and loads, and optionally decodes, the contents of the file into the allocated memory. C64 OS ships with a number of data type loaders for common graphics file formats. (See also, data type, extension, file type, load (file/directory).)
desktop - The desktop in C64 OS is provided by App Launcher. Unlike on a Mac or Windows PC, the desktop is not used for storing arbitrary files. The C64 OS desktop is more like the springboard of a smartphone. You can customize its backdrop and hint color, and you can add aliases to Applications, Utilities and PRG Aliases to regular C64 Software. The desktop is a colorful and customizable place from which you launch into other software. (See also, alias, App Launcher, Application, hint color, place.)
detected devices table - C64 OS detects supported (and unsupported) storage devices during boot up. A table is constructed for every device number, indicating if the device number is occupied and by what device type. C64 OS software should consult this table for device presence and type identification. C64 OS software should not attempt to detect devices manually. The Drives Utility can be used at anytime to rescan the bus and update the detected devices table, allowing drives to be turned on or off without rebooting. (See also, boot, device, Utility.)
device - Both C64 OS and the C64's KERNAL represent I/O hardware using a set of device numbers. The keyboard is 0, the datasette is 1, RS-232 over the User Port is 2, and the screen is 3. Devices 4 and 5 are for printers on the IEC serial bus. Devices 6 and 7 are for plotters on the IEC serial bus. Devices 8 through 30 are for disk drives, hard drives, SD Card drives, and other storage devices. Storage devices are typically on the IEC serial bus, but some special high speed drives are connected to the expansion port. Other input devices such as mouse, joystick, light pen, or KoalaPad, and other output devices such as the SID or digital audio devices are not represented in the C64's official devices scheme. (See also, IEC (serial bus, IEEE-488), joystick, KERNAL, KoalaPad, light pen, RS-232, SID.)
device status - After a request is made to a storage device, the result of the request is returned over the device's command channel. This result is called the device status. Each status consists of a status code, followed by an english language description of the code, followed by one, two or sometimes more additional numbers. The default operating status of a storage device is 00, OK. There is a standard set of status numbers used by all devices, and there are some custom numbers used by different devices. By convention, any status number less than 20 is not an error. All status numbers 20 or greater represent some kind of error. (See also, channel, command channel, device, status bar.)
DIR - (See, subdirectory.)
directory - A directory is a list of files that exist in one conceptual place. The directory includes several important pieces of information: the partition number, the directory title, the files in the directory, and the blocks free count for this partition. Each file is shown with several pieces of information: the file's size in blocks, the filename, the file type, the lock status, and optionally a date/time stamp, hidden flag, etc. (See also, block, file type, partition, place.)
disk image - A disk image is a file that contains a byte-for-byte copy of each block of all the tracks and sectors of a disk. A disk image can be written back out to an original disk, or it can be used to backend modern disk drive recreations, such as a 1541 Ultimate II+, a pi1541, or with VICE. Disk images can also be written to emulation partitions on CMD devices, or mounted by SD2IEC to create a kind of temporary emulation partition. Popular disk images are known by their file extension, D64 for 1541, D71 for 1571, D81 for 1581 or DNP for CMD Native partitions. (See also, 1541/1571/1581, 1541 Ultimate II+, block,extension, native, partition, pi1541, SD2IEC, VICE.)
DMA - DMA stands for direct memory access. It is a process whereby a device connected to the C64's expansion port asserts the bus access line, which temporarily halts the CPU, and then takes over the data and address bus to gain direct access to the C64's RAM. (See also, CPU, memory (main), RAM, REC, REU (17xx).)
document - A document is a kind of file. Not every file is a document, some files contain program code or other program resources. A file is considered a document if it contains information that was created by user input using an Application, such as a text editor, a word processor, spreadsheet, presentation software, etc. (See also, Application, text.)
driver - A driver is a special purpose program designed to access information from a hardware device and convert it to and from a generic internal representation. A classic example of a driver is for reading from an input devices, such as a mouse, joystick, light pen, etc. Although different hardware devices, they all perform the same internal function, moving the pointer. (See also, device, joystick, light pen, pointer.)
E...
event - C64 OS is an event-driven operating system. There are several types of events which trigger program behaviors. Pointer events, such as button down, button up, button click, button double-click, mouse wheel movements, mouse dragging, etc. Keyboard events, such as a regular key being pressed (creates a low-level printable key event), or a key being pressed in combination with modifier keys (creates a low-level key command event). Events can be also generated internally, such as a timer that expires or data arriving from a network. (See also, modifier keys, timer.)
exception - An exception is an unexpected condition deep inside a C64 OS process. The exception changes the flow of a computer program. If the program handles the exception, it can gracefully recover and deal with the problem. But if an exception is not handled, it rises up to the level of the operating system which terminates the program by presenting the red "Splat!" dialog box with a frowning face.
extension - An extension is a short code, from 1 to 6 characters appended (postfix) or prepended (prefix) to a filename using a dot. For example, tree house.koa has the name tree house with a koa extension. A prefixed extension example is ptr.1351 port2, the name is 1351 port2 the extension is ptr. A filename extension is used to indicate the file's data type. By C64 OS convention, a runnable program has a PRG file type with no extension. A PRG file type with an extension is some kind of data file. (See also, data type, file type, PRG.)
F...
Fastload - EPYX Fastload is a popular speedloader cartridge from 1984. Since C64 OS uses the KERNAL ROM for all disk accesses, without a speedloader of some kind its loads, reads and writes are going to be stock-speed (i.e., slow.) The original EPYX Fastload cartridge does not support SD2IEC. However, the Fastload Reloaded cartridge does. The reloaded firmware is a modified version of the original. Original Fastload cartridges can be updated by replacing the ROM chip with the newer version. (See also, JiffyDOS, KERNAL, load (file/directory), ROM, SD2IEC.)
FAT (32/16) - FAT stands for File Allocation Table and is the file system used on MS-DOS and older versions of Windows. It is no longer the standard file system used by Windows, but because of its age and wide support it is used as the default file system on commercial SD Cards. SD2IEC reads and writes FAT file systems natively. FAT32 and FAT16 are 32-bit and 16-bit versions of the file system. Both are supported by SD2IEC. (See also, file system, native, SD2IEC.)
favorites - A favorite is a place you frequently want to access. From File Manager any directory in any partition of any device can be added to the list of favorites. Favorites are displayed in the lower section of the left sidebar of File Manager. Favorites created using File Manager are also available from within any Application via the left sidebar of the Open and Save Utilities. The sidebar supports up to 15 favorites. (See also, device, directory, File Manager, partition, place.)
file lock - On CBM file systems (1541, 1571, and 1581) there is a special lock bit on a file's entry in the directory. A locked file cannot be scratched. However, it can be overwritten using the @-overwrite DOS command, or by selecting the Allow Overwrite option in the Save Utility. CMD file systems (CMD HD, FD and RAMLink) and IDE64 support file lock. SD2IEC supports file locking inside mounted disk images. SD2IEC also supports file locking of regular files if you have installed firmware version 63+. A locked file shows with a lock icon after its file size in File Manager. The locked status of a file can be toggled with the File Info Utility. (See also, 1541/1571/1581, CMD FD, CMD HD, disk image, icon, RAMLink, FAT (32/16), File Manager, file system, IDE64, mount, SD2IEC, scratch, Utility.)
File Manager - One of two Homebase Applications in C64 OS. File Manager has 4 tabs allowing you to be in up to 4 places at once. Files and subdirectories can be recursively scratched, or recursively copied and/or moved between any two directories, and partitions of any two devices. File Manager can also be used to open documents in assigned Applications and Utilities. (See also, App Launcher, assign, document, home (Homebase), partition, place, scratch, subdirectory.)
file reference - A file reference is a C64 OS structure that contains all the
necessary information to locate a file: its device number, partition number, path within that
partition, and filename. The in-memory file reference can also be used to fetch and store the
file's size in blocks. Additionally, the in-memory structure can be converted to a serialized
format for displaying on screen or saving to a file. The serialized format
(dev#:part#:filename:path) can be unserialized back into the in-memory structure. Serialized
example:
10:2:Hi there.txt://documents/examples/
(See also, device, partition, path.)
file system - A file system (FS) is a means of organizing data on a storage device. Different file systems have different features, such as support for subdirectories, different maximum numbers of files in a directory, case sensitivity, ability to scan efficiently through a large file, date and time stamping, etc.
The Commodore File System (CBM FS) used on 1541, 1571 and 1581 do not support subdirectories, do not support date/time stamping, have fairly low limits on the number of files that can be in the main directory, and scanning through files is slow and inefficient.
The file system used on CMD devices (CMD FS) is based upon CBM FS, but extends it with date and time stamping, multiple partitions, subdirectories, and larger limits on the number of files per directory.
IDE64's FS is based loosely on CMD FS, but increases the maximum storage capacity of a partition, adds support for links, hiding files, efficient scanning through large files, and fast file moving within a partition.
SD2IEC uses a FAT FS, this is a PC-based file system with special features added for backwards
compatibility with C64-specific needs. It adds case-insensitivity, the ability to mount disk
images, large partition sizes, the ability to efficiently scan files, and other features.
(See also, block, cluster, directory, disk image, FAT (32/16), file lock, mount, partition.)
file type - A file type should not be confused with a data type. A file type is special to CBM file systems and their descendants. There are a limited number of file types, PRG, REL, SEQ and USR. These file type codes are listed in a standard directory and are identified by the left-most column of a file list in the C64 OS File Manager and Open and Save Utilities. These indicate how the file's data is stored, not what the file's data contents are. (See also, data type, file system, PRG, REL, SEQ, USR.)
float - A floating point number in C64 OS is stored and represented in the same format as C64 BASIC, and the BASIC ROM's routines are used to perform mathematical operations on them. A float is 5 bytes. 4 bytes (32 bits) are used for precision, and a 5th is used for sign and the position of the decimal point. A C64 OS floating point number can range from -1.70141183e+38 to 1.70141183e+38. The smallest number between 0 and 1 is 2.93873588E-39.
focus - Focus is used to describe which elements of a user interface keyboard events will be directed to. Because user interface elements are nested, focus can exist simultaneously at multiple levels, and is usually indicated by a difference of color. Out of focus elements have a low-contrast color, while focused elements have a more vibrant or higher contrast color. For example, when a Utility is in focus its title bar is a different color than its panel body, but when it's out of focus the title bar is the same color as the panel body. A set of tabs shows which tab is selected using color. A list with a selected item shows the item in the selected color when in focus, or in a muted color when the list is not in focus. A text field changes color and has a visible text input cursor when it is in focus. (See also, event, theme.)
fullscreen (gfx) - The primary C64 OS UI is in character mode for speed and memory efficiency. However, C64 OS also supports bitmap mode at the KERNAL and library level. Whenever bitmap graphics data is available a small up arrow appears beside the free memory indicator in the status bar. A global keyboard shortcut, COMMODORE+← (this can be customized,) toggles into and out of fullscreen graphics mode. Keyboard shortcuts to menu options continue to work even while in fullscreen graphics mode. (See also, character mode, COMMODORE (key), splitscreen (gfx), KERNAL, library, shortcut, status bar.)
G...
game controller - In C64 OS, a game controller is distinct from the pointer input device. There can simultaneously be a pointer input driver and a game controller driver enabled at the same time. The game controller driver can read in data from 2 or 4 game ports and updates the state information 50 (PAL) or 60 (NTSC) times a second for 8 digital buttons per controller. Up, down, left, right, fire 1, fire 2, select and start. A game should only read from the operating system's game controller status values. The user chooses the driver that suits the 4-player adapter and/or controller interfaces physically connected to the computer. (See also, driver, pointer.)
GEORAM - A GEORAM is a simple 256-byte window-paged expansion memory device. It is not compatible with a 17xx REU, however with an appropriate port expander a 17xx REU and a GEORAM can be used at the same time. An original GEORAM has 512KB of memory, clones are available with 1MB, 2MB, or up to a maximum of 4MB. GEORAM has some advantages and some disadvantages when compared with a 17xx REU. (See also, RAM, REC, REU (17xx).)
go menu - A go menu lets you quickly jump to some other convenient place. The App Launcher's go menu lets you change to another desktop or to switch to File Manager. The File Manager's go menu lets you navigate up the current directory path, jump directly to the system directory, Applications directory or Utilities directory, or switch to App Launcher. Additionally, File Manager's go menu lets you quickly jump to one of four user-defined places: Documents, Games, Music, or Pictures. (See also, App Launcher, desktop, directory, File Manager, path, place, system card.)
GUI - A GUI is a graphical user interface, in contradistinction to a CLI or command-line interface. Although C64 OS's primary user interface uses the VIC-II's character mode for speed and memory efficiency, it is conceptually a GUI. Commands are issued by using a mouse to choose menu options, click buttons, drag scroll bars, move floating panels by dragging them, etc., rather than typing commands into an endlessly scrolling terminal-like interface. (See also, character mode, VIC-II.)
H...
hint color - App Launcher provides 5 configurable desktops. Each desktop can have a custom backdrop and a single hint color. The hint color is applied to the foreground color of the backdrop and to the screen's border (overriding the border color defined by the theme.) The backdrop's background color is global, and determined by the current theme. (See also, App Launcher, backdrop, desktop, theme.)
HiRes - HiRes, or High Resolution, is a native graphics mode supported by the VIC-II. It has 320x200 pixels of resolution, arranged in 8x8 pixel cells. Each cell can have two colors from the VIC-II's fixed palette of 16 colors. Each pixel in the cell can take either of those two colors. A fullscreen HiRes image takes 9KB of data; 8KB of bitmap data, plus 1KB of color data. (See also, MultiColor, native, VIC-II.)
home (Homebase) - The model of C64 OS is as follows: Upon booting you are taken first to the Homebase Application. From Homebase you launch into another Application. From that Application you choose Go Home from the menu options, which returns you to Homebase. C64 OS has two different homebase Applications: App Launcher and File Manager. These are conceptually two modes of Homebase. From either you can switch to the other using its go menu. (See also, App Launcher, Application, boot, File Manager, go menu.)
I...
I2C (serial bus) - I2C is an acronym for Inter-Integrated Circuit, a serial bus protocol for communication between low-speed peripheral ICs and a microprocessor or microcontroller. The protocol was invented in 1982 by Philips, but is now widely used with Arduino and its many peripheral devices. C64 OS has an I2C library that implements the I2C protocol over 2 lines of the User Port. There are different versions of this library, one that uses lines compatible with a GEOS I2C implementation and another preferred for use with C64 OS that can be used simultaneously with RS-232 over the User Port. Additional versions of this library may be offered in the future using different lines, such as over the cassette port for compatibility with Mister64. Some drivers, such as the I2C RTC driver, communicate over I2C abstractly by relying on the library to provide the bus communications. (See also, library, RS-232, RTC, version.)
icon - An icon is a small graphical picture used to represent something else. C64 OS's main character set reserves 18 characters to be custom defined. C64 OS provides a standard icon library, a collection of 1x1 character icons (8x8 pixels) offering a variety of useful symbols for Applications and Utilities. Such as, a trash bin, a wifi symbol, a floppy disk, a joystick, and many others. Applications also define an icon, but their icons are 3x3 characters (24x24 pixels.) An Application's icon is shown when the App is launching and can be viewed later with About This App. (See also, Application, bundle, character set, joystick.)
IDE - IDE stands for Integrated Drive Electronics and was developed in the 1980s by Western Digital and Compaq. It combines a hard drive storage mechanism with a control board in the same compact unit. IDE was later called ATA (Advanced Technology Attachment) and later called PATA or Parallel ATA to distinguish it from SATA or Serial ATA. IDE storage devices can be used on a Commodore 64 by means of the IDE64 cartridge. (See also, IDE64.)
IDE64 - IDE64 is a family of mass storage devices for the C64. It connects to the C64 via the cartridge port. Early versions provide a 40-pin IDE terminal connector, to which up to 2 IDE devices (hard drives, CD-ROMs, Zip Drives, etc.) can be connected. IDE64 uses IDEDOS which requires the hard drive to be partitioned and formatted with a custom file system. Later versions include a compact flash card socket which allows use of a CF Card in place of an IDE hard drive. (See also, file system, IDE, modern device, partition.)
IEC (serial bus, IEEE-488) - The Commodore PET uses a parallel IEEE-488 bus for communications with storage devices. The Commodore VIC-20, C64, C128 and others use a serial version of IEEE-488 known more commonly as the IEC bus. This bus is used for storage devices, such as 15xx disk drives, CMD HD, CMD FD, and SD2IEC. It is also used for printers and printer adapters. IEC bus communications on a stock C64 are notoriously slow. Using a custom protocol, such as the one provided by JiffyDOS, dramatically increases IEC serial bus transfer speeds. (See also, 1541/1571/1581, CMD FD, CMD HD, JiffyDOS, SD2IEC.)
image - Although graphics files are sometimes referred to as images, image is often used to mean disk image. (See also, disk image.)
install - Software is installed when it is copied from a small temporary device such as floppy disk to a larger more permanent device such as a hard drive. An installation can also be from a compact format such as an archive or image file into an assortment of files ready to be used. C64 OS software and updates are distributed in C64 Archiver (.CAR) format and are installed using the Installer Utility. (See also, CAR, device, disk image, image, Utility.)
J...
JiffyDOS - JiffyDOS is a replacement ROM set for the KERNAL ROM in the C64 and the DOS ROM in 1541, 1571 and 1581 disk drives. JiffyDOS is a highly compatible speedloader that accelerates disk access to drives that have had their DOS updated to JiffyDOS. The JiffyDOS protocol comes built-in with SD2IEC, CMD HD and FD. JiffyDOS also adds numerous productivity boosting features to BASIC, such as a two-drive file copier, text and BASIC program listings, DOS wedge, and more. JiffyDOS is still commercially available today. Although not a requirement, JiffyDOS is strongly recommended for use with C64 OS. (See also, 1541/1571/1581, CMD FD, CMD HD, KERNAL, load (file/directory), ROM, SD2IEC, text.)
job - A job is a special structure that an Application provides to a Utility to instruct the Utility what to do. The Utility then carries out the job and reports completion back to the Application with a job complete message. Jobs include, copying, moving or scratching a set of files and/or subdirectories. Open and save jobs are used for coordinating an Application with the Open and Save Utilities. (See also, Application, message, Utility, save job, scratch, subdirectory.)
joystick - A joystick is a digital input device. It is often used as a game controller, with up, down, left, right and fire buttons. C64 OS supports up to 4 joysticks for game controllers with up to 8 buttons each (up, down, left, right, select, start, fire 1, fire 2.) A joystick can also be used as a pointer input device, to control the mouse pointer. However, using a real mouse for this provides a faster and more satisfying experience. (See also, 1351 mouse, driver, game controller, pointer.)
K...
KERNAL - KERNAL is Commodore's spelling of kernel. The C64's KERNAL is on an 8KB ROM chip. JiffyDOS is a replacement for the C64's original KERNAL ROM. C64 OS extends the C64's KERNAL, by loading files from the system directory during boot up. A KERNAL is the lowest-level component of an operating system and helps manage memory and other system resources. The C64 OS KERNAL is divided into 10 modules. (See also, boot, JiffyDOS, load (file/directory), module, ROM, system card.)
KoalaPad - The KoalaPad is an drawing tablet device first introduced for the Commodore 64 in 1983. C64 OS includes a KoalaPad pointer driver, which allows the use of a KoalaPad in place of a mouse. The KoalaPad driver in C64 OS is unlike how most other C64 software uses it. In C64 OS the KoalaPad behaves more like the trackpad of a modern laptop. Movement of the pointer is relative, proportional and accelerated, rather than coordinate mapped. (See also, 1351 mouse, driver, pointer.)
L...
legacy device - A legacy device is a storage device for the C64 that does not have support for subdirectories or multiple partitions. All the Commodore-brand disk drives, 1541, 1571, and 1581 are classified as legacy devices. The C64 OS system directory cannot be installed on a legacy device, for two reasons; The storage capacity is too low and they do not support subdirectories. (See also, 1541/1571/1581, install, modern device, partition, subdirectory, system card.)
library - A library is a collection of useful and related routines. A library is not a program in and of itself, but provides common functionality to many different programs. In C64 OS, libraries are shared; If multiple processes need to use the same library at the same time, only one copy of the library is loaded into memory. Libraries are installed in //os/library/. (See also, install.)
light pen - A light pen is a special kind of input device that can be touched to the screen to keep the pointer directly beneath the pen tip. C64 OS includes a driver for using a light pen as a pointer input device. Light pens only work on CRT monitors that draw the image using a real raster beam. (See also, device, driver, pointer.)
load (file/directory) - Loading is the process of reading data into memory from a storage device. The C64 KERNAL has special load routines which communicate with storage devices on channel 0. Channel 0 is dedicated for loading PRG files, which begin with a 2-byte load address header, or for loading a directory listing. (See also, channel, device, directory, KERNAL, PRG.)
loader - The loader is a C64 OS component, found in //os/library/. It is responsible for loading a new Application into memory. It performs some cleanup on behalf of the previous Application and some setup on behalf of the loading Application. (See also, Application, component, library.)
lock - (See, file lock.)
logical file - A logical file is a numbered communications channel between the C64 and a device. Each open logical file number is associated with a device number and a secondary address. The meaning of the secondary address varies depending on the device. C64 OS uses the C64 KERNAL for communication with devices, and therefore supports 10 logical files open at the same time. (See also, channel, device, KERNAL.)
M...
mass-storage device - (See, modern device.)
memory (main) - Main memory refers to the 64KB of RAM that is directly addressable by the 6510 CPU. In C64 OS main memory is divided into several regions: workspace, Application, free/heap, KERNAL, buffers, high memory. High memory is beneath the KERNAL ROM and is used for graphics data or for a Utility. Currently available free memory can be seen in two of three mods of the status bar. (See also, 6502/6510, CPU, KERNAL, RAM, ROM, status bar, Utility, workspace memory.)
menu bar - The menu bar is a strip that runs along the top of the screen. It provides a set of top-level menus, with menu options for sending commands to the Application. The first menu on the left end of the menu bar is the Utilities menu. On the right end of the menu bar a clock is optionally displayed. The menu bar and menu system is a feature of the C64 OS KERNAL. (See also, KERNAL, Utilities menu.)
menu definitions file - The menus of an Application are constructed by the loader when the Application is opened. A menu definitions file (menus.m) is stored in the Application bundle. The menu definitions file is designed to be human readable and editable in a text editor. It is also designed to be transformed in memory where the text was loaded, into a linked structure ready to be rendered by the menu system. (See also, Application, bundle, load (file/directory), loader, text, Utilities menu.)
message - A message is a standardized data structure that is sent between an Application and a Utility, or the system and an Application or Utility. Messages are loosely coupled, allowing unsupported message types to be handled gracefully. Supported message types have only a conceptual result, rather than a hard-coded and fixed effect. (See also, Application, Utility.)
metadata - Metadata is data about data. For example, a file contains data. But a file's name, its extension, its file type, date/time stamp, lock status, etc. are each pieces of data that are secondary and used to describe something about the file's data. (See also, extension, file lock.)
MicroMys - MicroMys is a mouse adapter for connecting PS/2 mice to your C64. MicroMys primarily behaves like a 1351 mouse and is therefore compatible with software that can use a 1351, but it also provides support for middle button clicks and mouse scroll wheel information. C64 OS includes a MicroMys mouse driver (available in v1.03) with support for the scroll wheel in Toolkit. (See also, 1351 mouse, driver, MouSTer, Toolkit.)
modal - Modal refers to a user interface that uses different modes which can be switched on or off, where each mode changes the way the system responds to the same input. Modal user interfaces are generally frowned upon and many modern designers think they should be avoided. C64 OS strives to not use modes. Typically you can take any action, at any time, and in any order to work towards solving a problem. There are some instances, however, where modes are enforced. During a recursive or multi-file copy, move or scratch operation, the corresponding Copy, Move and Scratch Utilities turn on a "modal" flag. Menus become disabled, clicks to areas of the screen outside the Utility are ignored, keyboard shortcuts are ignored, etc. until the long-running file job completes. (See also, job, recursion, scratch, shortcut, Utility.)
modern device - A modern device is a storage device for the C64 that has support for multiple partitions and subdirectories. CMD HD, FD and RAMLink, IDE64 and SD2IEC are all modern storage devices. C64 OS requires a modern storage device for its system directory because the system directory is divided into numerous nested subdirectories. (See also, CMD FD, CMD HD, IDE64, legacy device, partition, SD2IEC, subdirectory, system card.)
modifier keys - Modifier keys are special keys on the keyboard that when used in conjuction with non-modifier keys produce alternative results. The C64's modifier keys are the COMMODORE key, the CONTROL key, and the left and right SHIFT keys. When the COMMODORE or CONTROL key or both are used with some other non-modifier key, a low-level key command event is generated. The SHIFT keys can be used in conjunction with COMMODORE or CONTROL or both as a modifier for key command events, however, if SHIFT is the only modifier key used with a non-modifier key, a low-level printable key event is produced with an uppercase or similar value. (See also, COMMODORE (key), CONTROL (key), event, SHIFT (key).)
module - A module is a subunit of a more complex computer program. The module sets boundaries on the code such that calls between modules are limited to being made via an explicit programming interface. This allows you to make changes within a module without fear of breaking unexpected dependencies from outside the module. The C64 OS KERNAL is implemented as a set of 10 modules. Individual modules can be swapped with alternative versions at boot time depending on configurable settings and detected hardware. (See also, API, boot, KERNAL.)
mount - To mount means to attach a device or disk image with an alternative file system into a specific place in the existing file system. The Commodore 64 itself does not have a concept of a file system, however its storage peripheral devices do. Not every storage device supports mounting, however SD2IEC devices do. Disk image files on an SD2IEC can be mounted to the partition in which the file is stored. The disk image's file system completely takes over that partition. While the image is mounted, no other files in the partition outside the disk image can be accessed. For this reason, C64 OS only allows mounting disk images to partitions that are not the C64 OS system or boot partition. (See also, boot, disk image, file system, image, partition, place, SD2IEC, unmount.)
MouSTer - MouSTer is a mouse adapter for connecting USB mice to your C64. MouSTer primarily behaves like a 1351 mouse and is therefore compatible with software that can use a 1351, but it also provides support for additional configurable settings. Although MouSTer is mostly used for mice, it can also be used with USB-based game controllers and has options for mapping their buttons to the buttons of standard C64 joysticks. It includes support for other features such as rapid fire. (See also, 1351 mouse, driver, game controller, joystick, MicroMys.)
move job - A move job is a special job data structure that is provided by an Application to the Move Utility. It provides the Utility with a set of instructions for source and destination information, validation callback and other settings used for performing a multi-file and recursive move operation. (See also, job, recursion, Utility.)
MText - MText stands for marked text. It is a light-weight alternative to a markup language like HTML. MText is based on PETSCII but defines additional codes, undefined by PETSCII, for paragraph justification, themed text styles (normal, strong, and emphatic text), inline absolute text colors, dynamic horizontal rules and linked text (i.e., hyperlinks.) MText is interpreted natively but the TKText Toolkit class, and subsequently by any C64 OS software that uses that class. (See also, class (Toolkit), native, PETSCII, text, TextView, theme, Toolkit.)
MultiColor - MultiColor is a native graphics mode supported by the VIC-II. It has 160x200 pixels of resolution, arranged in 4x8 pixel cells, wherein each pixel is double the width of a HiRes pixel. Each cell can have any three colors from the VIC-II's fixed palette of 16 colors, or one background color defined globally for the entire screen. A fullscreen MultiColor image takes 10KB of data; 8KB of bitmap data, plus 1KB of screen matrix memory used for color data, plus 1KB of color ram data. (See also, fullscreen (gfx), HiRes, native, VIC-II.)
N...
native - In a computer context, native means original or inherent to a system. For example, PETSCII is native to the C64, whereas ASCII is foreign. PETSCII does not require conversion to be displayed as intended, but ASCII does require conversion. The CMD storage devices have native partitions, which are the most natural and original to the CMD devices. They also support emulation partitions which layout the data as it is on various kinds of floppy disk. 6502/6510 assembly language is native to the C64 and runs extraordinarily fast. The C language is not native to the C64; It was designed with features in mind available on other CPUs that are not available to the 6510. IEC serial devices are native C64 peripherals which can be connected directly. Non-native devices require a hardware adapter of some sort. PS/2 and USB mice are not native to the C64, requiring MicroMys, MouSTer or similar adapters. (See also, 6502/6510, ASCII, assembly language, CMD HD, CPU, IEC (serial bus, IEEE-488), MicroMys, MouSTer, partition, PETSCII.)
natural sort - A sort algorithm puts items in either numeric or alphabetic order. The letters of the alphabet have numerically ordered byte values, therefore alphabetical order is a form of numerical order. However, when multi-digit numbers in a string are being sorted alphabetically, a primitive sort algorithm sorts them one digit at a time, resulting in: 1, 101, 11, 2000, 21, etc. A natural sort algorithm groups sequences of digits together and orders them by their full numeric value, resulting in: 1, 11, 21, 101, 2000, etc. C64 OS includes a sort library which implements a fast natural sorting algorithm, which is used in File Manager and elsewhere. (See also, File Manager, library.)
O...
open job - An open job is a special job data structure that is provided by an Application to the Open Utility. It provides the Utility with a set of instructions for how to present the controls, what to do when a file is opened, and a validation callback for validating files as openable as they are selected. (See also, job, Utility.)
Opener - The Opener Utility is used whenever a file is opened using File Manager. Opener manages the assignment of file and data types to Applications and Utilities that are capable of opening those files. If no Application or Utility is assigned, it lets you choose one, optionally assign it to this file type and data type for the future, or open the file in a specific Application or Utility just this one time. (See also, Application, assign, data type, File Manager, file type, Utility.)
P...
p00 - A file with the extension .p00 (or .pXX with any number from 00 to 99) is a file wrapped with a special header that carries CBM FS specific metadata. This format was first created for the PC64 emulator to allow files stored on a FAT file system to retain their CBM FS metadata. The "p" in "p00" represents the CBM File Type PRG. SD2IEC uses .p00 files and implicitly unwraps them. (See also, extension, file system, file type, metadata, PRG, s00, SD2IEC.)
page (memory) - The C64's main memory is 64KB, which can be addressed using two bytes, a high byte and a low byte. This field of memory can be conceived of as 256 pages of memory, where each page consists of 256 bytes of memory. In this model, the high address byte holds the page number and the low byte is an index into the page. The 6502/6510 CPU is more efficient when an index does not cross a page boundary. C64 OS provides a paged memory allocator which allocates memory in page-sized increments that are always page-aligned. A 256-byte page of memory is roughly analogous to a 256-byte block of disk storage. The paged memory allocator is roughly analogous to a disk's block allocation map or BAM. (See also, 6502/6510, block, CPU, memory (main).)
partition - A storage device has a medium upon which data is stored. The medium must be formatted and organized with a file system in order to be used. Some storage devices, especially those with a large storage medium, are able to segment the medium into numbered units called partitions. Each partition is then independently formatted. Different partitions can be formatted with different file systems. All the files in the same partition share a single volume of shared storage space, regardless of how those files are divided into subdirectories. The legacy storage devices do not support multiple partitions. (See also, device, file system, legacy device, modern device, partition, subdirectory.)
path - On a modern storage device the path is a way to specify the order of
nested subdirectories leading to a place. An absolute path starts with two slashes (//) to
indicate the root directory. A relative path starts with one slash (/) to indicate that the
path begins in the current directory. Path components are appended by specifying the
subdirectory name followed by a single slash. A path always ends with a slash.
Example absolute path:
//os/settings/assigns/
Example relative path (if the current path were already //os/):
/settings/assigns/
(See also, directory, modern device, place, root directory, subdirectory.)
Peek - Peek is originally a BASIC command that can be used to read the value from a memory address. Peek is also a C64 OS Utility which can be used to view the contents of memory, one page at a time. (See also, memory (main), page (memory), Utility.)
PETSCII - PET Standard Code for Information Interchange. PETSCII is an alternative to ASCII, which was developed by Commodore for the PET computer in 1977. Unlike ASCII, PETSCII is an 8-bit character encoding which has some advantages when used on a computer with limited resources. In addition to the character encoding, PETSCII is also closely associated with the default character set that shipped in a ROM on the PET. Variants of the PET's character set are used on all Commodore 8-bit computers. (See also, ASCII, character set, MText, ROM, text.)
pi1541 - Pi1541 is an adapter board which can be connected to a Raspberry Pi to create a cycle-exact 1541 disk drive implementation, which backends on disk image files rather than physical disk media. In addition to being a faithful 1541 implementation it also supports some SD2IEC functionality. (See also, disk image, SD2IEC.)
place - A place in storage means the combination of a device number, a partition number and a directory path in that partition. The Places Utility lets you define the four customizable places in File Manager's go menu: Documents, Games, Music, and Pictures. You can also use File Manager to save the place of the current tab to the list of favorite places. Favorite places show up in the left sidebar of the Open and Save Utilities even when these Utilities are opened within other Applications. (See also, device, directory, favorites, File Manager, go menu, path, partition.)
pointer - A graphical user interface makes use of an on-screen pointer. The pointer is moved by means of a hardware device, usually a mouse, which is interfaced to the operating system via a pointer driver. C64 OS comes bundled with numerous pointer drivers for 1351 mouse, joystick, light pen, KoalaPad and more. The appearence of the pointer can be changed using the Mouse Utility. Each pointer selected with the Mouse Utility comes from a file found in //os/pointers/. These files can be modified to provide an alternative to the set that comes bundled. (See also, 1351 mouse, driver, GUI, joystick, KoalaPad, light pen, pointer.)
PRG - PRG is a CBM FS file type. It consists of a sequential stream of binary data that is prepended with a 2-byte header. The header indicates where in memory the data was saved from and to where it should be put back into memory when loaded. PRG files usually store program data, hence the name, but can also be used for certain kinds of data that need to be in a very specific place in memory, such as graphics data files and SID music. (See also, file system, file type, load (file/directory), memory (main), SID.)
PRG alias - There are a number of ways that a regular C64 program can be loaded and run, and several hardware configuration issues that can prevent a program from loading or running correctly. A PRG alias is a small file containing metadata about a C64 program. PRG alias files can be opened with the PRG Runner Utility, which uses the metadata to test that the PRG can be loaded and run under the current hardware conditions. It can also make some hardware changes, such as swapping device numbers or mounting disk images or swaplists. Then it loads the PRG file, does a controlled reboot and runs the program. (See also, device, disk image, load (file/directory), metadata, mount, PRG, swap.)
Q...
Quantum Link (Q-Link) - Quantum Link was a North American online service specifically for the Commodore 64 and 128. The service was accessed with dial-up modems from 300 to 2400 baud. It provided mail, chat, news and file sharing, along with some other services. Q-Link became America Online in 1989 and access to the original Q-Link ended in 1995. Q-Link was revived and rebuilt as Q-Link Reloaded in the 2000s, and can be accessed via the internet with a modern WiFi modem. (See also, WiFi modem.)
R...
RAM - Random Access Memory. (See, memory (main).)
RAMLink - The RAMLink is a high-speed storage device that was produced by CMD from 1990 to 2001. Its storage medium is power- (and battery-) backed 30-pin RAM simms with a maximum storage capacity of 16MB. The RAMLink has a parallel port which can be connected to the parallel port on a CMD HD to greatly accelerate transfer rates to and from the CMD HD. C64 OS can be installed and booted from a RAMLink. (See also, boot, CMD HD, device, install, modern device, RAM.)
REC - REC stands for RAM Expansion Controller and is a chip produced by Commodore that lies at the heart of the 17xx RAM Expansion Units. The REC chip can be instructed to move data very quickly between main memory and external memory using DMA. (See also, DMA, memory (main), RAM, REU (17xx).)
recents - Recents are files which have recently been opened. The TKPlaces class, which appears in the left sidebar of the File Manager and Open and Save Utilities, automatically manages recent files. A separate list of recently opened files is maintained per Application. The list of recents and favorites can be toggled by clicking the Recents/Favorites header. The list of recents can hold up to 15 recently accessed files. (See also, class (Toolkit), favorites, File Manager, Toolkit.)
recursion - Recursion is the ability of computer software to repeat a pattern of functionality in a nested context. For example, to scratch a directory containing files and subdirectories, the software can first scratch the files, then move into the first subdirectory and repeat an identical pattern within that subdirectory. When the pattern finds the deepest nested subdirectory, which itself has no more subdirectories, it returns to the parent directory and finally removes the now-empty subdirectory from which it just returned. The result is the ability to scratch an entire directory tree with a single command. C64 OS provides both low-level support and usable features for recursively copying, moving and scratching directory trees. (See also, directory, File Manager, scratch, subdirectory.)
REL - REL is a CBM FS file type. It stores data on the disk in a non-linear record-based fashion. It is useful for creating certain kinds of databases or index card systems. REL files are an uncommon file format, but they are supported by legacy devices, CMD HD, FD and RAMLink, as well as IDE64. REL support is incomplete on SD2IEC. The C64 OS File Manager does not support copying REL files between devices. (See also, file type, IDE64, legacy device.)
restore archive - C64 Archiver is an Application for C64 OS that can be used to create C64 Archive (CAR) files. Archive files come in more than one type: general, install and restore. A restore archive contains a complete copy of a C64 OS system directory. A restore archive cannot be extracted using the Installer Utility, but is instead extracted using the c64restore tool which is loaded and run automatically by the C64 OS Setup Tool during a fresh installation of C64 OS. (See also, CAR, install, load (file/directory), system card, tool.)
RESTORE (key) - The Commodore 64 has a special key, above the RETURN key, called RESTORE. Pushing this key triggers a low-level non-maskable interrupt (NMI) in the 6510 CPU. This causes the CPU to interrupt its current process and execute an interrupt service routine configured for the NMI. This can be used to do a variety of things. In C64 OS, when STOP+RESTORE are used together, the current Application is quit and the user is returned to Homebase. If the user is already at Homebase, the current Homebase Application is reloaded. (See also, 6502/6510, Application, CPU, home (Homebase).)
REU (17xx) - REU stands for RAM Expansion Unit. Commodore made several versions of REU 1700, 1750 and 1764, with 128KB, 512KB and 256KB of expansion RAM respectively. The 17xx REU makes use of the REC chip to perform DMA transfers for moving data very quickly between main memory and expanded memory. C64 OS has KERNAL level support for REUs, and can take advantage of REUs for accelerating file transfers and screen redrawing. C64 OS will continue to take advantage of REUs in new ways in subsequent versions. Although a GEORAM is a form of RAM expansion unit, it is not compatible with 17xx REUs, and uses a different technique for accessing extra memory. (See also, DMA, GEORAM, KERNAL, RAM, REC, memory (main), version.)
ROM - ROM stands for Read Only Memory. A ROM chip is a kind of memory chip that stores data which cannot be changed. Unlike a RAM chip which loses its memory contents when power is removed, a ROM chip retains its contents even without power. When the C64 is turned on, its ROM chips, (BASIC, KERNAL and character set ROMs,) are responsible for providing the familiar blue READY prompt. (See also, character set, KERNAL, RAM.)
root directory - A subdirectory is a directory that is nested within a parent directory. The root directory is the one directory on a partition that is not nested within a parent directory. Legacy devices support only a root directory; they do not support subdirectories. (See also, directory, legacy device, partition, subdirectory.)
RS-232 - RS-232 is an asynchronous bi-directional serial communications standard. It is used for connecting the Commodore 64 to other RS-232 peripherals. The C64's KERNAL supports RS-232 communications as a first class device, with speeds from 300 to 2400 baud over the User Port. The User Port's RS-232 implementation uses a non-standard 0V to 5V, rather than the standard -12V to 12V, but can be fitted with an adapter. Higher speed RS-232 communications are possible over the User Port with more efficient custom routines. The highest RS-232 communication speeds are possible with a cartridge, such as SwiftLink, Link232, Turbo232 and others. These cartridges add a dedicated UART chip for handling the sensitive communications timing. (See also, device, KERNAL, WiFi modem.)
RTC - RTC stands for realtime clock. The C64 does not include a built-in realtime clock, but can retrieve the current date and time from any of a number of external RTC chips. The CMD HD, FD and RAMLink all include an RTC chip, as does the IDE64, 1541 Ultimate II+ and the Ultimate64. Some SD2IEC devices include an RTC but most do not. It is also possible to connect an arduino based RTC module to the C64 using the I2C bus protocol. (See also, 1541 Ulimate, CMD FD, CMD HD, I2C (serial bus), IDE64, RAMLink, SD2IEC, Ultimate64.)
S...
s00 - A file with the extension .s00 (or .sXX with any number from 00 to 99) is a file wrapped with a special header that carries CBM FS specific metadata. This format was first created for the PC64 emulator to allow files stored on a FAT file system to retain their CBM FS metadata. The "s" in "s00" represents the CBM file type SEQ. SD2IEC uses .s00 files and implicitly unwraps them. (See also, extension, FAT (32/16), file system, file type, metadata, p00, SD2IEC, SEQ.)
save job - A save job is a special job data structure that is provided by an Application to the Save Utility. It provides the Utility with a set of instructions for how to present the controls, what to do when a file is saved, and a validation callback for validating filenames as saveable, and what to do with overwriting an existing file. (See also, job, Utility.)
scratch - Scratch is the original CBM FS terminology used to mean removing or deleting a file from a disk. When CMD HD DOS extended the file system with support for subdirectories they used the term remove for directories, but retained scratch for files. C64 OS uses the term scratch to apply to both files and subdirectories. (See also, CMD HD, file system, subdirectory.)
scratch job - A scratch job is a special job data structure that is provided by an Application to the Scratch Utility. It provides the Utility with a set of instructions for what to scratch and a validation callback for validating filenames as scratchable. (See also, job, scratch, Utility.)
screencodes - Screencodes are byte values stored in screen matrix memory, which are used directly by the VIC-II chip as numeric indexes into the character set bitmap. They are not PETSCII codes even though they result in PETSCII characters appearing on the screen. (See also, backdrop, character set, PETSCII, VIC-II.)
screengrab - C64 OS has a configurable global keyboard shortcut for saving the contents of the screen to a timestamped file in //os/screengrabs/. The screengrab only captures the contents of the character-mode UI. It does not include graphics data or splitscreen. Screengrabs can be viewed with the tool petsciiview found in //os/c64tools/. (See also, character mode, shortcut, splitscreen (gfx), tool.)
SCSI - SCSI stands for Small Computer Systems Interface and is used for interfacing peripheral devices to computers. Typically hard drives, CD-ROM drives or scanners. The CMD HD communicates with SCSI devices and bridges them to the C64 via the IEC serial port and CMD HD DOS commands. The CMD HD typically works with a SCSI hard drive mechanism as its storage medium, although this can be replaced by a modern SD2SCSI interface card. The CMD HD also has a DB25 connector for external SCSI devices. C64 software exists to use a SCSI CD-ROM drive connected to this port, for transferring data and playing audio CDs. (See also, CMD HD, IEC (serial bus, IEEE-488), modern device.)
SD2IEC - SD2IEC is a modern storage device with support for partitions and subdirectories. It backends on SD Card storage media. SD Cards are formatted with the FAT 16 or FAT 32 file system. Various compatibility modes are available for handling the differences between FAT FS and CBM FS, such as the ability to automatically wrap and unwrap files with .p00 and .s00 wrappers. C64 OS can be installed on and boot from an SD2IEC. (See also, FAT (32/16), file system, install, modern device, p00, partition, s00.)
selection - C64 OS has many different user interface elements that in some way support selection. The Themes Utility has a common theme-able element for selections and this color is applied to all of these different contexts. For example, dragging a selection box around aliases in App Launcher, selecting multiple files in a table in the File Manager, selecting an item in the Utilities Utility list, selecting text in a text input field, pressing down on a scroll bar's nub to drag it, mousing down on a tab to change to that tab, these all share the same selection themed color. (See also, theme, Toolkit, UI.)
SEQ - SEQ is a CBM FS file type. It consists of a sequential stream of data. The data does not have to be text or human readable, it can be binary data. SEQ files are like PRG files but without the 2-byte load address header. You can't load a SEQ type file. (See also, file type, load (file/directory), PRG.)
services - Applications are found in //os/applications/. Applications can be installed and uninstalled by copying them into and out of the applications directory. However, some Applications are critically important to making C64 OS work and should never be uninstalled. These are called services, or service Applications, and are found instead in //os/services/. (See also, App Launcher, File Manager, install.)
settings file - Settings files end with the extension ".t", they are always in a human readable/editable text format. These files are found in //os/settings/. Settings files are not created automatically and must not be scratched. If you are going to manually edit a settings file, make a backup copy of it first. If the edited version leads to problems, restore the file from its backup or compare the file to its backup to see what might be wrong. (See also, datacheck, extension, scratch, state file, text.)
SHIFT (key) - There are two SHIFT keys found near both ends of the row of the C64's keyboard above the space bar. The LEFT-SHIFT and RIGHT-SHIFT keys are independent. For normal capitalization or punctuation, either SHIFT key may be used. When used with the the cursor keys, LEFT-SHIFT and RIGHT-SHIFT behave differently. Only RIGHT-SHIFT can be used to invert the directions of the cursor keys, allowing you to produce four directions, UP, DOWN, LEFT and RIGHT. The LEFT-SHIFT key can be used in conjunction with these four directions to create and extend selections. When either the COMMODORE or CONTROL keys are used, only the LEFT-SHIFT key can be used as an additional modifier for that key command event. LEFT-SHIFT (but not RIGHT-SHIFT) can also be used to modify mouse clicks. (See also, COMMODORE (key), CONTROL (key), modifier keys, selection.)
shortcut - A shortcut is a key command event used to activate either a menu option or some other element of the UI. A shortcut should not be confused with an alias. (See also, alias, event, menu bar, modifier keys, UI.)
SID - The SID chip is responsible for producing sound and music on the C64. SID stands for Sound Interface Device. Adding a second SID chip for stereo sound and more voices is a common C64 upgrade. Music files that control the SID chip are also referred to as SIDs. (See also, VIC-II.)
splitscreen (gfx) - The primary C64 OS UI is in character mode for speed and memory efficiency. However, C64 OS also supports bitmap mode at the KERNAL and library level. Whenever bitmap graphics data is available a small up arrow icon appears beside the free memory indicator in the status bar. The status bar can be dragged up and positioned on any screen row to split the screen. The character mode UI is active in the upper half and the bitmap graphics UI is available below the split. (See also, character mode, fullscreen (gfx), icon, KERNAL, library, status bar, UI.)
splitter (Toolkit) - Splitter is a common name for the TKSplit Toolkit class. It provides a bar, either horizontal or vertical, that splits the screen with other Toolkit objects on either side of the split. The splitter bar can be dragged to give more space for one side and less to the other. Splitters should not be confused with the graphics splitscreen. (See also, class (Toolkit), splitscreen (gfx), Toolkit.)
state file - State files end with the extension ".i", they are in a binary format not suitable for being manually edited or opened in a text editor. Global state files are stored in //os/settings/, and local state files are stored inside Application bundles. All state files are auto-generating, and can therefore safely be scratched. (See also, Application, bundle, extension, scratch, settings file.)
status bar - The status bar is a strip that runs along the bottom of the screen. It provides three modes which can be cycled by clicking the bar. Drive status mode shows the most recent status message from the last accessed drive. Open/selected file mode shows the file reference to the currently open or selected file. In both of these modes the right end of the status bar shows the currently available memory, which can be double clicked to open a memory-related Utility. The third status bar mode is the Application custom message. This mode uses the full width of the bar to show whatever the current Application wants to show. When bitmap graphics are available a small up arrow appears beside the available memory indicator. The status bar can be dragged up to reveal the graphics in splitscreen. (See also, file reference, selection, splitscreen (gfx).)
subdirectory - A subdirectory is a directory that exists nested within a parent directory. Legacy devices do not support subdirectories, modern devices do. A subdirectory appears as an item within its parent directory with the file type DIR. (See also, directory, file type, legacy device, modern device.)
swap - Storage devices can be assigned device numbers from 8 to 30. Some C64 software, particularly older software, is hardcoded to only access a specific device number, usually 8. To accommodate this software, devices can have their numbers swapped. Although devices have an internally configured device number, they can be assigned a different device number through software. For example, device 9 could be changed to device 8. But if there is already a device on 8, it can be changed to device 9. The two devices have then swapped device numbers. (See also, device, PRG alias.)
System Card - C64 OS ships on an SD Card. A Commodore 64 can have more than one SD2IEC device connected at the same time, but C64 OS is booted from only one of those devices. The card from which C64 OS is booted is called the System Card. It is imperative that you not remove the System Card, as C64 OS expects to always have access to the system directory. (See also, boot, SD2IEC, system card.)
system directory - C64 OS v1.0 consists of nearly 1000 files distributed across a tree of around 50 nested subdirectories. All of these files and subdirectories are organized within a single directory called the system directory. The system directory must be located in the root directory of a partition. The default name of the system directory is "os", but this name can be changed. This makes it possible to have more than one system directory installed in the same partition. (See also, directory, install, partition, root directory, subdirectory, system card.)
system device (system drive) - The system device, sometimes called the system drive, is the device upon which the system directory is found. Using the Drives Utility it is possible to turn other devices on and off without needing to reboot C64 OS. It is not possible to turn off the system drive, because C64 OS requires access to the system directory at all times. (See also, system directory.)
system partition - C64 OS can only be installed on a modern storage device, because these have support for subdirectories. All modern devices also support partitions. The system partition is the one in which the system directory is found. Disk images can be mounted to SD2IEC partitions. However, an image cannot be mounted in the system partition because that would prevent C64 OS from having access to the system directory. A commercial C64 OS System Card comes with two partitions: Partion 1 "C64 OS" and Partition 2 "IMAGES". Storing disk images in the IMAGES partition is recommended. It allows them to be mounted without disturbing the system partition. (See also, disk image, image, modern device, mount, partition, SD2IEC, subdirectory, System Card, system card.)
T...
text - Text is a kind of data that is meant to be read by a human. Text can be encoded in more than one way. PCs traditionally use ASCII, while Commodore 8-bit computers use an ASCII-variant called PETSCII (or sometimes PET-ASCII.) C64 OS has KERNAL-level support for ASCII-PETSCII conversion which is used by the TextView Utility for viewing either PETSCII or ASCII texts. (See also, ASCII, KERNAL, PETSCII, MText, TextView.)
text wrap (soft wrapping, hard wrapping) - Text wrapping is how a long text file is split into multiple lines. Hard wrapped text has special codes at fixed positions within the text to indicate where one line should end and the next begin. Hard wrapped text is pre-formatted for a specific screen width and can be problematic for the C64 if that width exceeds ~39 characters. Soft wrapped text only indicates with codes where one paragraph ends and the next begins. Software is then used to wrap the text to best fit the width of the display. Soft wrapping is much more computationally expensive than hard wrapping but provides a better and more customized reading experience. C64 OS includes library and Toolkit support for soft wrapping. (See also, library, MText, text, TextView, Toolkit.)
TextView - TextView is a Utility for viewing text files. File Manager has a menu option with keyboard shortcut for opening the selected file in TextView. TextView can do on-the-fly conversion from ASCII to PETSCII and supports soft and hard wrapped text. (See also, ASCII, PETSCII, shortcut, text, text wrap, Utility.)
theme - A theme is a set of colors for all of the different customizable user interface elements, which are designed to have a pleasing appearence when used together. C64 OS comes with two built-in themes, Daylight and Midnight (light and dark themes), plus the ability to create a custom theme using the Themes Utility. The built-in and custom themes are specified by files in //os/settings/ which allows you to modify even the built-in themes. (See also, Toolkit, UI, Utility.)
timer - Timers are a low-level feature of C64 OS that Applications and Utilities use for setting up timed events. C64 OS is a single-tasking, event-driven OS, but timers can be used to allow different processes to interleave their events giving a form of multitasking. For example, the Memory Utility can be left open. It scans the memory page allocation table and updates its display of memory usage with a timer. As you use the Application below, you see changes to memory usage reflected in the Utility. (See also, event, page (memory), Utility.)
TMP - TMP is acronym for Turbo Macro Pro. (See, Turbo Macro Pro.)
tool - In C64 OS parlance, a tool is a program that is designed to be run from the C64's READY prompt. A tool is, therefore, not a C64 OS program. The tools directory (//os/c64tools/) contains many small useful programs to help with programming, data and device management. (See also, subdirectory, system card.)
Toolkit - Toolkit is part of the C64 OS KERNAL. Toolkit is an object-oriented user interface framework. It includes several built-in user interface classes, and many more classes that can be loaded by an Application or Utility that needs them. Classes snap together like lego pieces providing sophisticated and consistent behavior across the system. Toolkit gives Applications a powerful user interface with minimal coding effort. (See also, class (Toolkit), GUI, KERNAL, UI.)
tracking - Tracking refers to the speed and acceleration of the mouse pointer. Mouse tracking in C64 OS always makes use of acceleration to make it easier to move the pointer over large distances. The tracking speed can be set with the Configuration Tool (//os/settings/:configure) or with the Mouse Utility. (See also, 1351 mouse, pointer, tool, Utility.)
Turbo Macro Pro - Turbo Macro Pro is a popular 6502 assembler which runs directly on the C64. C64 OS was developed using Turbo Macro Pro on a Commodore 128. A version of Turbo Macro Pro, with REU support, is included in the c64tools directory making it possible to create new C64 OS software right from your C64. The C64 OS Programmer's Guide treats Turbo Macro Pro as a first class citizen for software development. (See also, 6502/6510, assembly language, pointer, REU (17xx), tool.)
U...
UCI - UCI is an acronym for Ultimate Command Interface. It is an optional register-based API for communicating with the advanced hardware features of a 1541 Ultimate II+ or Ultimate64. C64 OS includes an RTC driver that communicates over UCI to read and write the realtime clock of 1541 Ulimate II+ and Ultimate64. (See also, 1541 Ultimate II+, API, driver, RTC, Ultimate64.)
UI - UI is an acronym for User Interface. Popular user interfaces include the command line interface (CLI) or graphical user interface (GUI). A user interface defines the means and metaphors by which a user interacts with the computer, starting and stopping programs, giving the computer input and receiving output. C64 OS uses a graphical user interface, implemented priimarily, though not exclusively, using the VIC-II's character mode with a custom character set. (See also, character mode, character set, GUI, VIC-II.)
Ultimate64 - The Ultimate64 is a new FPGA implementation of a Commodore 64. It fits into a standard C64 or C64c case and uses a real C64 keyboard and peripherals. It has the functionality of a 1541 Ultimate II+ built in, plus other features such as CPU acceleration, video and audio streaming, etc. It puts 2 USB ports, an ethernet port and an HDMI port in the place of the standard User Port. The original User Port can be added via an adapter board attached to a terminal header with a ribbon cable. C64 OS is fully compatible with Ultimate64 and can take advantage of many of its features. (See also, 1541 Ultimate II+, CPU.)
unmount - Unmounting is the opposite of mounting. After a disk image has been mounted it can later be unmounted. (See also, disk image, mount.)
USR - USR is a file type in CBM and compatible file systems. It stands for user defined. Files of USR type may be structured in any way, including in non-linear ways that are not understood by the drive's built-in DOS. For example, GEOS VLIR files have a tree-like structure of linked blocks on disk, and are accordingly marked with the USR file type. For this reason, the C64 OS Copy Utility cannot copy USR files. It skips over them instead. (See also, file type, PRG, REL, SEQ.)
Utilities menu - The Utilities menu is found in the top-left corner of the screen. It is always the left-most option in the menu bar. It looks like three horizontal bars. The contents of the Utilities menu is populated during boot up from the file //os/settings/:utilities.m which is structured as a menu definitions file. The Utilities menu allows you to open any Utility from within any Application. (See also, boot, menu bar, menu definitions file, Utility.)
Utility - A Utility is a small C64 OS program which display itself in a floating panel and can be opened simultaneously with any C64 OS Application. Utilities are sometimes stand-alone programs providing their own useful function, and they are sometimes designed to provide auxiliary functionality to an Application. Utilities allow different Applications to share functionality, without it having to be rewritten within each Application. (See also, Application, Utilities menu.)
V...
version - C64 OS as a whole has a version number which is shown on the boot screen and can be viewed later using the About C64 OS Utility. The version number is stored in //os/settings/:version.t. The version consists of a primary version number and a secondary version number separated by a dot. Primary version numbers represent major changes. The secondary version number runs from 00 to 99, with small changes incrementing the number by 1, and larger changes raising the number to the next 10. Some incremements from .00 to .99 may be skipped. (See also, build.)
VIC-II - The VIC-II is the video chip used in the Commodore 64. It was produced in a PAL version and a couple of NTSC versions. VIC stands for Video Interface Controller. It is responsible for the amazing effects seen in C64 demos, but also for the limitations imposed on the C64 OS user interface, such as a single background color common to the whole screen. (See also, SID.)
VICE - VICE is the Versatile Commodore Emulator. It is a featureful multi-Commodore 8-bit emulator that runs on many different computer platforms. C64 OS can be installed and run within recent versions of VICE, by installing to a virtual CMD HD or IDE64 storage device. (See also, CMD HD, IDE64, install.)
W...
WiFi modem - A WiFi modem is a networking device which presents itself to the Commodore 64 as a traditional dial-up modem. It is connected to the computer by RS-232, either over the User Port or in the form of a SwiftLink or Turbo232 cartridge. The modem connects to a WiFi router and performs TCP/IP packet handling internally. Hayes commands can be used to open a network socket connection, which then behaves like a direct modem-to-modem connection. WiFi modems can be used to connect to internet-based BBSes, Q-Link Reloaded, or also to implement modern networking services. (See also, Q-Link, RS-232.)
window shade - A real window shade is affixed at the top of a window and can be pulled down or drawn up. A Utility panel (a kind of window) can be rolled up into its title bar, just like a window shade. Hold CONTROL and click the title bar, or right-click the title bar (available in v1.03) to toggle window shade on or off. (See also, CONTROL (key), Utility.)
workspace memory - The C64's main memory is divided into several regions. The first 2.25KB of memory ($0000 to $08FF) are reserved as a special workspace for the KERNAL ROM, the BASIC ROM, the C64 OS KERNAL, libraries, drivers and toolkit classes. This area is statically allocated, and its use is documented in //os/docs/:memory.t (See also, class (Toolkit), driver, KERNAL, library, memory (main), ROM.)
X...
XMODEM - XMODEM is a simple file transfer protocol developed by Ward Christensen. It allows files to be transmitted between two computers connected directly to one another using modems. (See also, YMODEM, ZMODEM)
Y...
YMODEM - YMODEM is a simple file transfer protocol developed by Chuck Forsberg, as an extension of XMODEM. It allows files to be transmitted between two computers connected directly to one another using modems. (See also, XMODEM, ZMODEM)
Z...
ZMODEM - ZMODEM is an inline file transfer protocol developed by Chuck Forsberg in 1986. It dramatically improves on the efficiency of XMODEM and YMODEM. It allows files to be transmitted between two computers connected directly to one another using modems. (See also, XMODEM, YMODEM)
Table of Contents
This document is subject to revision updates.
Last modified: Feb 03, 2023