Commodore DOS, also known as CBM DOS, is the disk operating system used with Commodore's 8-bit computers. Unlike most other DOSes, which are loaded from disk into the computer's own RAM and executed there, CBM DOS is executed internally in the drive: the DOS resides in ROM chips inside the drive, and is run there by one or more dedicated MOS 6502 family CPUs. Thus, data transfer between Commodore 8-bit computers and their disk drives more closely resembles a local area network connection than typical disk/host transfers.
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 unique serial IEEE-488 bus (IEC Bus) serial (TALK/LISTEN) protocols; all others use the parallel IEEE-488.
Version 2.6 was by far the most commonly used and widely known DOS version, due to its use in the 1541 as part of C64 systems.
Note: The revised firmware for the 1571 which fixed the relative file bug was also identified as V3.0. Thus it is not possible to differentiate the two versions using the version number alone.
Technical overview
1541 directory and file types
The 1541 Commodore floppy disk can contain up to 144 files in a flat namespace (no subdirectories); the directory is stored on reserved track 18, which is located halfway from the hub to the edge of a 35-track single-sided disk. A file name may be up to 16 bytes in length and is theoretically unique; by using direct access methods on the directory structure, it is possible to rename a file to that of another—although accessing such files may be difficult or impossible. Files with identical names 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.
File names may contain a shifted space character ($A0), and if the directory listing is being viewed from BASIC, the portion of the file name beyond the $A0 character will appear to have been separated from the first part of the file name by a quotation mark, causing BASIC to not consider it to be part of the full file name. This feature can be used to create directory entries such as SAVE "PROGRAM⇧ Shift–spaceCommodore–DUDE",8,1, which will then appear in the directory listing as, for example, 32 "PROGRAM",8,1 PRG.[1] When the user moves the cursor to the beginning of the line, types the word LOAD over the file size, and presses RETURN, BASIC interprets that as LOAD"PROGRAM",8,1..., causing the program to be loaded into memory. Anything after the colon or the secondary address will not be executed, since the computer ignores any command after a LOAD.[2] Alternatively, the user could press ⇧ Shift–RUN/STOP to LOAD and RUN the program automatically.[3]
A null byte embedded in a file name will interrupt the listing after loading by BASIC. If there are three null bytes, that makes it difficult to list through BASIC. Many machine language programmers would experiment with null bytes in an attempt to make it harder for BASIC programmers to access their code and tamper with it.
In BASIC, the directory can be accessed as a non-executable pseudo-BASIC program with LOAD"$0",8 (or LOAD"$1",8 in the case of a dual drive) followed by LIST. The first line has a line number of 0 or 1 (indicating the drive number), showing in reverse video 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, "3D" 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."
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 load 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 (starting with the second character on the first line of the screen).
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 Fast Load, Action Replay, and The Final Cartridge III allow viewing of the disk directory using special commands that load the directory into screen memory without destroying the current BASIC program. Some versions of Commodore BASIC include a DIRECTORY or CATALOG command that performs the same function.
The following file types are supported:
SEQ
A sequential file is a data file that can be linearly read from start to finish. SEQ files are commonly used to store documents or text files created by a word processor or other such editor. A sequential file is analogous to a flat file in Linux or UNIX, in that it has no specialized internal structure. It is not possible to position to any arbitrary location in a sequential file, as there is no analog of the lseek kernel call found in UNIX-like operating systems.
PRG
PRG files normally contain executable program code, although they can also be used for data files. The first two bytes of the PRG are read by the kernal "load file" routine and used to determine the load address (they are stored in a little endian format).
REL
A relative file is a variation of the sequential file type, in which an indexing mechanism referred to as side-sectors is present to permit record-oriented access. Records may be a maximum of 254 bytes in size and are addressed by a one-based cardinal number, permitting true random access to any part of the file.
USR
A user-specified file has an internal structure that is identical to that of a sequential file. Commodore's original purpose for this file type was the facilitation of DOS development, as the file content could be copied into a drive buffer for execution by the drive's microprocessor. Very few programs ever made use of this file type. Some applications that use non-standard low-level disk structures save data in USR format, which came to be considered a sort of "leave me alone, don't try to copy or delete" indication to the user. Most notably, GEOS' "VLIR" files show up as USR files.
DEL
An undocumented internally used file type similar in structure to a sequential file. Creation of this file type must be accomplished by direct manipulation of the disk directory.
The presence of an asterisk (*) prepended to the file type in a directory listing (for example, *SEQ) indicates that the file was not properly closed after writing. When the drive is commanded to close a file that has been opened for writing, the associated buffer is flushed to the disk and the block availability map (BAM) is updated to accurately reflect which blocks have been used. If a program crash or other problem (such as the user removing the disk while a file is open) results in an "orphan file", also referred to as a "poison" or "splat" file, buffers are not flushed and the BAM will not accurately reflect disk usage, putting the disk at risk of corruption. A poison file generally cannot be accessed (but can be opened in "modify" mode), and an attempt to use the DOS scratch command to delete the file may cause filesystem corruption, such as crosslinking. The only practical method of removing one of these files is by opening the file in "modify" mode (and fixing it), or by validating the disk (see the DOS validate command below), the latter which rebuilds the BAM and removes poison file references from the directory. The infamous save-with-replace bug could result in creation of splat files.
*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 that are subsequently created. Some utility programs allow the "un-deletion" of such files if their data blocks and directory entries haven not yet been overwritten by other files. DEL files are commonly used to insert banners or comment sections into a directory listing.
File types with < after them (for example, PRG<) are "locked", and cannot be deleted—they can be opened for reading, however. There is no Commodore DOS command that can explicitly set or clear this status, 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 the changes 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 the BASIC ROM contains a higher level abstraction for file access using BASIC syntax. The components that concern the DOS itself are file name parsing and the secondary address. 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 processing of a number of parameters that are vaguely analogous to file opening procedures in other environments. Since the DOS is actually running in the drive's controller, the file opening sequence must pass enough information to the drive to assure unambiguous interpretation. A typical statement in BASIC to write to a sequential file would be as follows:
OPEN3,8,4,"0:ADDRESSBOOK,S,W"
The parameters following the OPENverb 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-like operating systems. It is never sent to the drive and thus is neither known nor used by the drive's own operating system. The file number may be in the range of 1 to 254 inclusive, is assigned by the programmer and must be unique if more than one file is simultaneously opened. Once the file has been opened all program input and output procedures use the file number. 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. File numbers greater than 127 cause the system to write an extra line feed after each carriage return (useful for double spacing a document, as an example.)
8
This parameter, the device number, identifies a specific peripheral attached to the computer. Devices 0 through 3 address the keyboard, tape cassette, RS-232 interface, and video display, respectively, all of which are directly controlled by the kernal ROM. Device numbers 4 and higher address devices attached to the peripheral bus, such as printers or disk drives. In the case of a disk drive, the device number refers to the unit's controller, not the drive mechanism(s) within the unit. By convention, the first disk drive unit on a system has device number 8, the second drive, if present, 9, etc., up to a maximum number of 15 (when eight disk drives are attached). The device number scheme was derived from the IEEE-488 (or general purpose interface GPIB) 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), again from the mnemonic for the memory location where the device number is stored.
4
This parameter, the secondary address, which may range from 0 to 15 inclusive, refers to a specific communication channel established with the device's controller and is passed to the device when it is commanded to "talk" or "listen" on the peripheral bus. As with the file number, the secondary address is determined by the programmer and must be unique for the device in question. The range 0 to 14 inclusive is used for passing data to or from the device, whereas 15, referred to as the "command channel", is used to issue commands to the device's controller (such as to rename a disk file), if the device is able to support such an operation. In disk drives, secondary addresses 0 to 14 inclusive are mapped to buffers within the controller, hence establishing communication with a specific file on a specific disk; since as mentioned above the drive does not know about the file number, it can only use the secondary address to make a difference between several files that are open at the same time. On the other hand, the host operating system is agnostic about the secondary address; it is transmitted to the drive on every access to the file, but not otherwise used by the host. 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 mechanism 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 mechanism 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 mechanisms (e.g., the OMTISASI controllers that were developed to work with ST-412/ST-506 hard drives in the 1980s). In floppy disk units, the first mechanism is drive 0: and the second 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 a recommended practice (a colon alone is equivalent to 0: and is enough to avoid those bugs). An exception to this convention is with 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 mechanism zero in a dual floppy 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. Load relocation happens in the host, being an exception to what is said above about the secondary address being used only device-internally. Since the PET cannot relocate files, BASIC programs written on later Commodore machines must be modified by using a sector editor to change the header bytes. It is also possible to use the PET's built-in machine language monitor to change the link address for the BASIC program after loading it.
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.)
The directories of disks in two-drive units are accessed as LOAD"$0",8 and LOAD"$1",8. "0:$" and "1:$" do not access the directory but actual files on one drive or the other that just happen to be named "$". 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; all such partial directories still contain the initial disk name line and the final "BLOCKS FREE" line.
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. For years rumors spread, beginning with the 4040 drive, of a bug in the command's implementation. At first, this was denied by some commentators. Prizes were offered to prove the existence of the bug.[4] By early 1985 Compute! magazine advised readers to avoid using the command.[5] That year various authors independently published articles[4][6][7][8] proving that the Save-with-Replace bug was real and including methods by which it could be triggered.
Affected devices included the single-drive 1541 and dual-drive 4040; the 8050 and 8250 did not exhibit the issue.[4] Some commentators suggested the bug could be avoided by always explicitly specifying the 0: drive number when saving,[6] though it was later shown that any disk operations without a drive number were sufficient to lead to the bug.[9] 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 could result in scrambled data being written to the disk.
In September 1986, Philip A. Slaymaker published an article[10] 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 original 1541's ROMs, they did fix the bug in Revision 5 of the 1571 ROMs, and also in the ROMs for the 1541-c and 1541-II drives. Although not supported by Commodore, it is known that the 1541-II firmware (but not that of the 1541-c) can also be used in an original 1541 drive by using EPROMs, which will fix the bug for that drive as well.
Command channel
As previously noted, the Commodore DOS itself is accessed via the "command channel", using syntax like that used to access files. Issuing commands to the DOS and retrieving status and error messages generated in response to commands is accomplished by opening a file to the device using 15 as the secondary address, for example:
OPEN1,8,15
To retrieve and display the device status, one could code:
OPEN1,8,15:INPUT#1,E,E$,T,S:PRINTE,E$,T,S:CLOSE1
In the above example, E will hold the error number (if any; it will be zero if no error exists), E$ will be a terse text description of the error, T will represent the disk track where the error occurred, and S will be the sector on track T to which the error refers. If no error exists, the equivalent of 00,OK,00,00 will be returned in the four variables. Note that INPUT# is a run mode only verb. Also, in programs that issue many disk commands it is customary to open a file to the device's command channel at the start of the program and not close it until the program has finished.
Commodore BASIC versions 4.0 and later provide a pseudo-variable referred to as DS$ that may be used to retrieve drive status in lieu of the above code. This reserved variable is not available on earlier versions of BASIC, so the command channel must be manually read as demonstrated above. Note that immediately after power-on or reset, the DOS revision will be returned. For example, a 1541 will return 73,CBM DOS V2.6 1541,00,00. Error code 73 is common to all drive models and may be used to determine if the drive has been reset to its power-on state.
Format a disk, preparing it for use and deleting any data contained on it. Omitting 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",identifier
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.
OPEN15,8,15,"I0:":CLOSE15
@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.
OPEN15,8,15,"V0:":CLOSE15
@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).
OPEN15,8,15,"D1=0":CLOSE15
@D1=0
BACKUP D0 TO D1
There are also a command for seeking in RELative type files (RECORD#), several block-level direct-access commands (BLOCK-READ, BLOCK-WRITE, BUFFER-POINTER), block management (BLOCK-ALLOCATE, BLOCK-FREE), drive memory manipulation and execution of program code on the drive's processor (MEMORY-WRITE, MEMORY-READ, MEMORY-EXECUTE, BLOCK-EXECUTE) and user-definable functions (USER and & commands). Some of the theoretically user-definable functions were rededicated for accessing new functionality in DOS versions after 1.0.
Related Research Articles
The Commodore 1541 is a floppy disk drive which was made by Commodore International for the Commodore 64 (C64), Commodore's most popular home computer. The best-known floppy disk drive for the C64, the 1541 is a single-sided 170-kilobyte drive for 5¼" disks. The 1541 directly followed the Commodore 1540.
The Commodore 1571 is Commodore's high-end 5¼" floppy disk drive, announced in the summer of 1985. With its double-sided drive mechanism, it has the ability to use double-sided, double-density (DS/DD) floppy disks, storing a total of 360 kB per floppy. It also implemented a "burst mode" that improved transfer speeds, helping address the very slow performance of previous Commodore drives.
A disk operating system (DOS) is a computer operating system that resides on and can use a disk storage device, such as a floppy disk, hard disk drive, or optical disc. A disk operating system provides a file system for organizing, reading, and writing files on the storage disk, and a means for loading and running programs stored on that disk. Strictly speaking, this definition does not include any other functionality, so it does not apply to more complex OSes, such as Microsoft Windows, and is more appropriately used only for older generations of operating systems.
CP/M, originally standing for Control Program/Monitor and later Control Program for Microcomputers, is a mass-market operating system created in 1974 for Intel 8080/85-based microcomputers by Gary Kildall of Digital Research, Inc. CP/M is a disk operating system and its purpose is to organize files on a magnetic storage medium, and to load and run programs stored on a disk. Initially confined to single-tasking on 8-bit processors and no more than 64 kilobytes of memory, later versions of CP/M added multi-user variations and were migrated to 16-bit processors.
In computer data storage, drive letter assignment is the process of assigning alphabetical identifiers to volumes. Unlike the concept of UNIX mount points, where volumes are named and located arbitrarily in a single hierarchical namespace, drive letter assignment allows multiple highest-level namespaces. Drive letter assignment is thus a process of using letters to name the roots of the "forest" representing the file system; each volume holds an independent "tree".
AmigaDOS is the disk operating system of the AmigaOS, which includes file systems, file and directory manipulation, the command-line interface, and file redirection.
ProDOS is the name of two similar operating systems for the Apple II of personal computer. The original ProDOS, renamed ProDOS 8 in version 1.2, is the last official operating system usable by all 8-bit Apple II computers, and was distributed from 1983 to 1993. The other, ProDOS 16, was a stop-gap solution for the 16-bit Apple IIGS that was replaced by GS/OS within two years.
Apple DOS is the disk operating system for the Apple II computers from late 1978 through early 1983. It was superseded by ProDOS in 1983. Apple DOS has three major releases: DOS 3.1, DOS 3.2, and DOS 3.3; each one of these three releases was followed by a second, minor "bug-fix" release, but only in the case of Apple DOS 3.2 did that minor release receive its own version number, Apple DOS 3.2.1. The best-known and most-used version is Apple DOS 3.3 in the 1980 and 1983 releases. Prior to the release of Apple DOS 3.1, Apple users had to rely on audio cassette tapes for data storage and retrieval.
Commodore BASIC, also known as PET BASIC or CBM-BASIC, is the dialect of the BASIC programming language used in Commodore International's 8-bit home computer line, stretching from the PET (1977) to the Commodore 128 (1985).
KERNAL is Commodore's name for the ROM-resident operating system core in its 8-bit home computers; from the original PET of 1977, followed by the extended but related versions used in its successors: the VIC-20, Commodore 64, Plus/4, Commodore 16, and Commodore 128.
TRSDOS is the operating system for the Tandy TRS-80 line of eight-bit Zilog Z80 microcomputers that were sold through Radio Shack from 1977 through 1991. Tandy's manuals recommended that it be pronounced triss-doss. TRSDOS should not be confused with Tandy DOS, a version of MS-DOS licensed from Microsoft for Tandy's x86 line of personal computers (PCs).
The Amiga Fast File System is a file system used on the Amiga personal computer. The previous Amiga filesystem was never given a specific name and known originally simply as "DOS" or AmigaDOS. Upon the release of FFS, the original filesystem became known as Amiga Old File System (OFS). OFS, which was primarily designed for use with floppy disks, had been proving slow to keep up with hard drives of the era. FFS was designed as a full replacement for the original Amiga filesystem. FFS differs from its predecessor mainly in the removal of redundant information. Data blocks contain nothing but data, allowing the filesystem to manage the transfer of large chunks of data directly from the host adapter to the final destination.
The Commodore 64 home computer used various external peripherals. Due to the backwards compatibility of the Commodore 128, most peripherals would also work on that system. There is also some compatibility with the VIC-20 and Commodore PET.
The MSD Super Disk were a series of 5¼-inch floppy disk drives compatible to some degree with the Commodore 1541 disk drive. produced by Micro Systems Development for use with Commodore 8-bit home computers. Two different versions of the MSD Super Disk were available: the single-drive model, SD-1; and the dual-drive model, SD-2.
AmigaOS is a family of proprietary native operating systems of the Amiga and AmigaOne personal computers. It was developed first by Commodore International and introduced with the launch of the first Amiga, the Amiga 1000, in 1985. Early versions of AmigaOS required the Motorola 68000 series of 16-bit and 32-bit microprocessors. Later versions, after Commodore's demise, were developed by Haage & Partner and then Hyperion Entertainment. A PowerPC microprocessor is required for the most recent release, AmigaOS 4.
DOS is a family of disk-based operating systems for IBM PC compatible computers. The DOS family primarily consists of IBM PC DOS and a rebranded version, Microsoft's MS-DOS, both of which were introduced in 1981. Later compatible systems from other manufacturers include DR-DOS (1988), ROM-DOS (1989), PTS-DOS (1993), and FreeDOS (1998). MS-DOS dominated the IBM PC compatible market between 1981 and 1995.
IDEDOS is a ROM-based disk operating system written in 6502/65816 assembly language for the Commodore 64, 128 and SuperCPU. Its main purpose is to control ATA(PI) devices connected to an IDE64 cartridge and present them like normal Commodore drives. Additionally it supports networked drives (PCLink) and has a built-in machine code monitor and file manager.
'Commodore 64 disk/tape emulation and data transfer' comprises hardware and software for Commodore 64 disk & tape emulation and for data transfer between either the C64 computer, the Commodore 1541 disk drive or Commodore 1530 Datasette tape deck, and newer computers.
The Commodore serial bus, is Commodore's interface for primarily magnetic disk data storage and printers for Commodore 8-bit home computers: the VIC-20, Commodore 64, Commodore 128, Plus/4, Commodore 16, and Commodore 65.
References
↑ Sturdivant, Jerry A. (February–March 1985). "Quick Load". Commodore Power/Play. Vol.4, no.1. p.54. Retrieved 2018-10-07.
↑ Grace, Paul (1986). "A bizarre dude". RUN Special Issue 1987. Peterborough, New Hampshire: CW Communications/Peterborough, Inc. Retrieved 2018-10-07.
↑ Philip A. Slaymaker. "Eliminating SAVE@ and Other 1541 Bugs". The Transactor Vol. 7 № O2, September 1986, pp.33–35.
Notes
Immers, Richard; Neufeld, Gerald G. (1984). Inside Commodore DOS. The Complete Guide to the 1541 Disk Operating System. DATAMOST, Inc & Reston Publishing Company, Inc. (Prentice-Hall). ISBN0-8359-3091-2.
Englisch, Lothar; Szczepanowski, Norbert (1984). The Anatomy of the 1541 Disk Drive. Grand Rapids, MI: Abacus Software (translated from the original 1983 German edition, Düsseldorf: Data Becker GmbH). ISBN0-916439-01-1.
(in Finnish) Lundahl, Reijo (1986). 1541-Levyasema. Amersoft. ISBN951-35-3206-2
This page is based on this Wikipedia article Text is available under the CC BY-SA 4.0 license; additional terms may apply. Images, videos and audio are available under their respective licenses.
