Version 2.6 was by far the most commonly used, and known, DOS version, due to its use in the 1541 (which sold in large numbers to users of C64s), and its emulation in the numerous third-party clones of that drive.
DEL<to the directory, and files could then be rearranged around those lines to form groups. Many game developers, warez group members and demoscene hackers used some more clever custom directory entries as well.
There's also one curious quirk in file names: File names may contain shift+space character, and the remainder of the name will appear after file name in the directory and is not really considered to be part of the file name. This is frequently used to create things like
,8,1:",8,1 which will then appear in directory as, for example,
32 "PROGRAM",8,1: PRG. When the user then moves the cursor to the beginning of the line and types
LOAD, overwriting the file size on that line, and presses enter, the Commodore BASIC interprets that as
LOAD "PROGRAM",8,1: ..., ignoring any commands after colon.
In BASIC, the directory can be accessed with
LOAD "$",8 followed by
LIST. Interestingly, on the Commodore 64, entering
LOAD "$",8,1 will flood the screen with garbage instead of loading the directory into BASIC RAM. This is because the drive assigns the directory a starting address of $0401 (1025), which is equivalent to the start of BASIC for the Commodore PET, but corresponds to the default screen memory in the C64.
Viewing the directory with a
LOAD "$",8 command overwrites the BASIC program in memory. The DOS Wedge and various third-party cartridges and extenders such as Epyx FastLoad, Action Replay and The Final Cartridge III allow viewing of the disk directory using special commands without destroying the current BASIC program. The Commodore 128's BASIC 7.0 includes a
CATALOG command (assigned on bootup to the F3 key) that performs the same function.
The following file types are supported:
SEQfiles, but they have program location header as the two first bytes. All machine language and BASIC programs are saved as
PRG, and can be loaded to memory with the BASIC's
LOADcommand (or KERNAL's
RELfiles support true random access to any portion of the file.
SEQfiles. They were intended to hold executable code for execution with the disc drive's own processor. It is unknown if anyone found a use for the facility. Some applications save their data in this format. Most notably GEOS' "VLIR" files show up as
SEQ. The DOS commands cannot create this file type, it can only be created by manipulating directory directly.
Also, the presence of an asterisk (
*) prepended to the file type in a directory listing (for example,
*SEQ) indicates that the file was not closed after writing. Most often, this will happen when a program crashes and leaves one or more files open on the disk. If a manual
CLOSE is not immediately executed on any file that was opened for writing, the disk's block allocation map (BAM) will not be updated, leaving the filesystem structure in an inconsistent state.
An asterisked file is often referred to as a "poison" or "splat" file, and generally cannot be accessed. Attempting to use the DOS
scratch command to delete such a file may damage other data on the disk due to crosslinking caused by an inaccurate BAM. The only practical method of removing a poison file is by validating the disk (see the DOS
validate command below).
< after them (for example,
PRG<) are locked, and cannot be deleted. There is no Commodore DOS command that sets or resets this bit, but many third-party utilities were written to allow this to be done. These utilities generally read the directory using direct-access commands, perform the necessary modifications to the raw data, and then write it back to the disk.
LOAD/SAVEcommands. This section will give an overview of the necessary BASIC commands for the sake of completeness.
Opening a file on a Commodore disk unit entails the passing of a number of parameters that are vaguely analogous to file opening procedures in other environments. Since the DOS is actually running on the drive and not the computer, the file opening sequence must pass enough information to assure unambiguous interpretation. A typical file opening sequence in BASIC would be as follows:
The parameters following the OPEN verb are as follows:3
"0:ADDRESSBOOK,S,W"parameter is officially referred to in Commodore documentation as the command string and is interpreted by the controller of the device being accessed. In the case of a disk drive unit, the formal command string structure consists of the drive number (
0:, not to be confused with the device number), filename (
ADDRESSBOOK), file type (
S, sequential in this example) and access mode (
W, opened for writing in this example). In practice, some of these parameters may be omitted. Minimally, only the filename is required if the file is to be opened for reading.
Files can also be loaded and saved to with
SAVE commands. File name specifiers can also be used here, for example,
SAVE "FILE",8 saves the BASIC program to a
PRG (program) file and
SAVE "0:FILE,SEQ,WRITE",8,1 saves the BASIC program to a sequential file. If the secondary address isn't specified (e.g.
LOAD "FILE",8), the file is saved/loaded from the BASIC memory area (which, on the C64, starts by default at $0801). If the secondary address is specified (e.g.
LOAD "FILE",8,1), the program is loaded starting from the address specified by the file itself (the PRG header, which is the first two bytes of the file)—this form of command is more common when loading machine code programs.
Load relocation was first introduced on the VIC-20 because this machine could start BASIC RAM in several different locations, depending on the memory expansion that was installed. The older Commodore PET series did not support relocation, so
LOAD "FILE",8 and
LOAD "FILE",8,1 would have the same effect: the file would be loaded into the same memory region from which it was saved.
LOAD "*",8,1 will load the first program on the disk starting from the file-specified memory location. This is one of the most popular load commands of the platforms, the method to start majority of commercial software, for example. Of note is the fact that the wildcard expansion will only pick the first catalog name on the first invocation; the name of the file is kept in memory, and subsequent
LOAD "*",8,1 commands will load the file with same name as the previous file to memory. (However,
LOAD "0:*",8,1 will always load the first file on the disk.)
SCRATCHthe existing file. This was done by appending an
@symbol to the file name during the
SAVEoperation - for instance,
SAVE "@MY PROGRAM",8. During the Commodore 64 era, this was the subject of a great deal of controversy, due to alleged bugs in the command's implementation on the 154x and 157x series drives. At first, this was denied by some commentators (and Commodore), but in 1985, various authors independently published articles proving that the Save-with-Replace bug was real and including methods by which it could be triggered. The bug stemmed from the fact that the affected DOS implementations were modified versions of the DOS contained in earlier Commodore PET dual drives such as the 8050. This created a "phantom drive
1:" on single-drive systems, resulting in the allocation of an unnecessary buffer under some conditions. Since the Save-with-Replace command used all five drive buffers, and because the method by which the "phantom" buffer was allocated did not meet specifications, this resulted in scrambled data being written to the disk under some conditions. Some commentators suggested the bug could be avoided by always explicitly specifying the
0:drive identifier, though this was later shown to be ineffective. In September 1986, Philip A. Slaymaker published an article describing in great detail the cause of the bug and providing patches to the 1541 drive ROMs; readers with an EPROM burner could produce their own patched ROMs which could be swapped into the drive. Commodore was made aware of Slaymaker's findings, and while they never issued an official update for the 1541 ROMs, they did fix the bug in Revision 4 of the 1571 ROMs.
The command channel is used both to send commands to the disk drive and to read the drive status. On Commodore BASIC 4.0 and above, the channel can be read by entering the command
PRINT DS$. This reserved word is not available on earlier versions of BASIC, so the command channel must be manually read with a short program:
10 OPEN 15,8,15:INPUT#15,E,E$,T,S:CLOSE 15:PRINT E,E$,T,S
INPUT# statement cannot be used in direct mode.) Here,
E is the error code,
E$ is a textual error message, and
S represent the track and sector where the error (if any) occurred.
If no error has taken place, the command channel will usually return "
00,OK,00,00". Immediately after power-on or reset, the DOS revision will be returned; on a 1541, for instance, the user would see
73,CBM DOS V2.6 1541,00,00.
|Commodore DOS Commands|
|DOS Command||BASIC 1.x and 2.x Implementation||DOS Wedge Implementation||BASIC 3.0+ Implementation|
Format a disk, preparing it for use and deleting any data contained on it
Delete a file from the disk (or multiple files, using wild card matching)
Rename a file on the disk
Reset the drive and read the disk BAM into its internal memory
Reconcile the BAM with the disk directory, free all blocks not being used by files, and delete all unclosed files from the directory
Duplicate a file on the same disk under a different file name
There are also several random-access commands (
BLOCK-WRITE), block management (
BLOCK-FREE), 1541 memory manipulation and execution of program code in 1541's processor (
BUFFER-POINTER) and user-defined functions (