|
|
|
|
Commodore DOS
|
| |
|
| |
Commodore DOS, aka CBM DOS, was the disk operating system used with Commodore's 8-bit computers. Unlike most other DOS systems before or since—which are booted from disk into the main computer's own RAM at startup, and executed there—CBM DOS was executed internally in the drive: the DOS resided in drive-internal ROM chips, and was run by one or more dedicated MOS 6502 family CPUs physically located inside the drive case.
east seven distinctly numbered versions of Commodore DOS are known to exist; the following list gives the version numbers and related disk drives.
Discussion
Ask a question about 'Commodore DOS' Start a new discussion about 'Commodore DOS' Answer questions from other users |
Encyclopedia
Commodore DOS, aka CBM DOS, was the disk operating system used with Commodore's 8-bit computers. Unlike most other DOS systems before or since—which are booted from disk into the main computer's own RAM at startup, and executed there—CBM DOS was executed internally in the drive: the DOS resided in drive-internal ROM chips, and was run by one or more dedicated MOS 6502 family CPUs physically located inside the drive case.
CBM DOS versions
At least seven distinctly numbered versions of Commodore DOS are known to exist; the following list gives the version numbers and related disk drives. Unless otherwise noted, drives are 5¼-inch format. The "lp" code designates "low profile" drives. Drives whose model number starts with 15 connect via Commodore's proprietary serial protocols, all others use IEEE-488.
- 1.0 – found in the 2040 and 3040 floppy drives
- 2.0 – found in the 4040 and 3040 floppy drives
- 2.6 – found in the 1540, 1541, built-in SX-64 drive, 1551, 2031 (+"lp"), and 4031 floppy drives
- 2.7 – found in the 8050, 8250 (+"lp"), and SFD-1001 floppy drives
- 3.0 – found in the 1570, 1571, and 8280 floppy drives (8280: 8-inch), as well as the 9060 and 9090 hard drives
- 3.1 – found in the built-in 1571 drive of C128D/DCR computers
- 10.0 – found in the 1581 (3½-inch)
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.
Technical overview
Directory and file types
The floppies themselves can contain up to 144 files. File names can contain up to 16 characters. There are no subdirectories and file names theoretically need to be unique (that is, if a file with specific name exists, a new file cannot be created with that name or an existing file cannot be renamed to that); however, by writing to disc directory blocks directly, it is possible to make multiple files have the same name, though accessing them may be difficult or impossible. Files with the same name usually serve no purpose except to inform or visually manage files. One popular trick, used, for example, by The Final Cartridge III, was to add files named "----------------" of type 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 SAVE "PROGRAM(shift+space),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 as a non-executable pseudo-BASIC program with LOAD "$",8 followed by LIST. The first line has a meaningless line number of 0, it shows, in reverse type, the name and ID of the disk and a shorthand code for the DOS version with which it was created (codes vary only as far as the DOS versions use incompatible disk formats, "2A" is used by most 5.25 inch DOS versions, "3A" by the 3.5 inch 1581). Lines after this have the size of a file (in disk blocks) as their pseudo "line number", followed by the file name in quotes and the three-letter type code. The last line shows the number of unallocated blocks on the disk (again as a pseudo "line number"), followed by the words BLOCKS FREE).
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 DIRECTORY or CATALOG command (assigned on bootup to the F3 key) that performs the same function.
The following file types are supported:
SEQ
- Sequential files are data files that can be read in a linear fashion. Many word processing and other office suite applications used files of this type for data storage. A sequential file is analogous to a flat file in Linux or UNIX, in that it has no specialized internal structure.
PRG
- Similar to
SEQ files, 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 LOAD command (or KERNAL's LOAD call).
REL
- Relative files are files with fixed-size records. Unlike the other file formats,
REL files support true random access to any portion of the file.
USR
- User-specified files. These are physically similar to
SEQ files. 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 that use non-standard low-level structures on the disks save their data in USR format, which became to be considered somewhat of a "leave me alone, don't try to copy or delete" mark to the user. Most notably GEOS' "VLIR" files show up as USR files.
DEL
- Undocumented internally-used file type. Likewise, similar in structure to
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. *DEL is a special type written into the on-disk directory entry of files that have been deleted; such files are not shown in a normal directory listing and their data blocks and directory entries will be reused by files stored later. Some utility programs allow the "un-deletion" of such files if their data blocks and directory entries haven not yet been verwritten by other files.
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).
Files with < 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.
File access
Accessing files is primarily an issue for the host computer. The KERNAL ROM in the computer contains the necessary primitive routines needed to access files, and BASIC ROM contains a higher level type of support for file access using BASIC syntax. The only component that really concerns the DOS is the file name parsing with the OPEN and LOAD/SAVE commands. 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:
OPEN 3,8,4,"0:ADDRESSBOOK,S,W"
The parameters following the OPEN verb are as follows:
3
- This parameter, the file number, logically identifies the opened file within the computer's operating system and is analogous to a file descriptor in UNIX or Linux. The file number may be in the range of 1 to 127 inclusive, it is determined by the programmer. In assembly language programs, this value is often referred to as LA (logical address), the abbreviation coming from the mnemonic that refers to the memory location where the file number is stored. This number is entirely host-internal, it is never communicated to the drive. If more than one file is opened on the host at one time (no matter whether on one or more peripheral devices), each must have its own file number.
8
- This parameter, the device number, identifies the hardware attached to the computer, such as a disk unit or a printer. Numbers 0 through 3 correspond to four "unintelligent" devices controlled by the host ROM (keyboard, audio cassette unit, RS-232 interface, screen); all higher numbers are simply transmitted over the peripheral bus and expected to be handled by an "intelligent" device, such as a printer or a disk drive, connected to that bus. In the case of a disk drive, the device number refers to the unit's controller, not the drive(s) within the unit. By convention, the first disk drive unit on a system has device number 8, and the second drive, if present, is typically 9. Higher numbers are possible up to a maximum of 15. The device number scheme comes from the IEEE-488 interface bus that was used with the Commodore PET/CBM models. In assembly language programs, this value is often referred to as FA or PA (physical address).
4
- This parameter, the secondary address, refers to a specific communication channel established with the device's controller. This number is used only device-internally, the host merely transmits it over the bus and leaves its interpretation to the device. In disk drives, channel numbers from 0 to 14 inclusive are used to communicate with buffers within the controller, hence establishing communications with a particular file in a disk unit. Channel 15 is reserved for communicating with the controller itself, and thus is known as the command channel. For example, a command to "scratch" (delete) a file would be issued through channel 15. The secondary address is selected by the programmer; if more than one file at a time is opened on one disk drive unit, each must have its own secondary address, so that the drive (which does not know about the file number parameter described above) can distinguish between them. In assembly language programs, this value is often referred to as SA (secondary address).
COMMAND STRING
- The
"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.
- The drive number identifies a drive attached to a disk unit's controller and is analogous to a logical unit number in a SCSI controller that is capable of controlling multiple drives (e.g., the OMTI SASI controllers that were developed to work with ST-412/ST-506 hard drives). In floppy disk units, the first drive is drive 0: and the second drive is 1:. It is fairly common practice to omit the drive number when communicating with a single drive floppy unit, as 0: is the default in such units, but since omitting the number can trigger a few obscure bugs in the DOS it is not recommended (a bare colon : is equivalent to 0: and is enough to avoid those bugs). An exception to this convention is the Lt. Kernal hard disk subsystem, in which the drive number refers to "logical units" (virtual drives created on a single physical drive), which made syntax such as 4: or 10: necessary if a file to be opened was not on logical unit zero (equivalent to drive zero in a dual floppy drive unit).
Files can also be loaded and saved to with LOAD and 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 or is specified as 0 (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 as a non-zero value (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.
The command 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 when no other file on that disk has been accessed before; the name of the last-used file is kept in memory, and subsequent LOAD "*",8,1 commands will load that file rather than the first. (However, LOAD "0:*",8,1 or LOAD ":*",8,1 will always load the first file on the disk.)
It should be noted that the directories of disks in two-drive units are accessed as LOAD "$0", 8 and LOAD "$1", 8, not as "0:$" and "1:$". Partial directories can be loaded by adding a colon and a template, for example LOAD "$0:K*=P",8 would load a partial directory that shows only the files whose name starts with the letter K and which are of type PRG.
The save-with-replace bug
Commodore DOS also offers a "Save-with-Replace" command, which allows a file to be saved over an existing file without the need to first SCRATCH the existing file. This was done by prepending an @ symbol to the file name during the OPEN or SAVE operation - 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.
Command channel
The DOS itself is accessed through command channel. This is accessed like all other files, but using the secondary address 15.
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 by RUNning a short program:
10 OPEN 15,8,15:INPUT#15,E,E$,T,S:CLOSE 15:PRINT E,E$,T,S
(The INPUT# statement cannot be used in direct mode.) Here, E is the error code, E$ is a textual error message, and T 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 |
|---|
New
Format a disk, preparing it for use and deleting any data contained on it. Leaving out the two-character identifier parameter will perform a quick deletion of all files on an already-formatted disk. |
OPEN 15,8,15,"N0:disk name,identifier":CLOSE 15 |
@N0:disk name,identifier |
HEADER "disk name",Iidentifier |
Scratch
Delete a file from the disk (or multiple files, using wild card matching) |
OPEN 15,8,15,"S0:file name":CLOSE 15 |
@S0:file name |
SCRATCH "file name" |
Rename
Rename a file on the disk. Note that the new name comes first (except in the BASIC 3.0+ code)! |
OPEN 15,8,15,"R0:new name=old name":CLOSE 15 |
@R0:new name=old name |
RENAME "old name" TO "new name" |
Initialize
Reset the drive and read the disk BAM into its internal memory. Rarely needed as the drive usually does this on its own, except if a disk is exchanged for another one with the same ID. |
OPEN 15,8,15,"I0:":CLOSE 15 |
@I0: |
DCLEAR (BASIC 7.0+ only) |
Validate
Reconcile the BAM with the disk directory, allocate all used blocks and free all blocks not being used by files, and delete all unclosed files from the directory. Comparable to CHKDSK/ScanDisk tools of Microsoft operating systems. |
OPEN 15,8,15,"V0:":CLOSE 15 |
@V0: |
COLLECT |
Copy
Duplicate a file on the same disk (or another disk in the same two-drive unit) under a different file name. Note that the new name comes first (except in the BASIC 3.0+ code)! Duplicating to another disk without a two-drive unit requires using a utility program. |
OPEN 15,8,15,"C0:new name=0:existing name":CLOSE 15 |
@C0:new name=0:existing name |
COPY"existing name"TO"new name" |
Duplicate
Duplicate an entire disk. Only available in two-drive units, otherwise a utility program needs to be used instead. The target(!) drive number comes first, then the source drive number (except in the BASIC 3.0+ code). |
OPEN 15,8,15,"D1=0":CLOSE 15 |
@D1=0 |
BACKUP U0 TO U1 |
There are also several random-access commands (BLOCK-READ, BLOCK-WRITE), block management (BLOCK-ALLOCATE, BLOCK-FREE), 1541 memory manipulation and execution of program code in 1541's processor (MEMORY-WRITE, MEMORY-READ, MEMORY-EXECUTE, BLOCK-EXECUTE, BUFFER-POINTER) and user-defined functions (USER and & commands).
|
| |
|
|
