CP/M was an operating system originally created for Intel 8080/85 based
microcomputers by Gary Kildall of Digital Research, Inc. 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
CP/M stood for either Control Program/Monitor or Control Program
for Microcomputers (the latter being a backronym). The name shows a
prevailing naming scheme of the time, as in Kildall's/Intel's PL/M (Programming
Language for Microcomputers) and Prime Computer's PL/P (Programming Language for
Prime), both suggesting IBM's PL/I; and IBM's CP/CMS operating system, which
Kildall used when working at the Naval Postgraduate School, and which, like
clear similarities to the CP/M user interface and file system.
Gary Kildall himself renamed CP/M in word form as part of the maturation of CP/M
from personal project in 1974 to commercial enterprise in 1976.
The combination of CP/M and S-100 bus computers patterned on the MITS Altair was an early "industry standard" for microcomputers, and was widely
used through the late 1970s and into the mid-'80s. By greatly reducing the
amount of programming required to install an application on a new manufacturer's
computer, CP/M increased the market size for both hardware and software.
A minimal 8-bit CP/M system would contain the following components:
The only hardware system that CP/M, as sold by Digital Research, would
support was the Intel 8080 Development System. Every manufacturer of CP/M
compatible systems would customize portions of the operating system for its
combination of installed memory, disk drives, and console devices.
CP/M would also run on systems based on the
processor since the Z80 was able to execute 8080 code. CP/M did not use any of
the Z80 specific instructions.
Components of the operating system
In the 8-bit versions, CP/M's software was separated into three components
console command processor or CCP,
basic disk operating system or BDOS, and
basic input/output system or
The CCP and BDOS were the same in all installations of a particular revision
of CP/M, but the BIOS portion was always adapted to the particular hardware.
Adding memory to a computer, for example, meant that the CP/M system had to be
reinstalled. Once installed, the operating system was stored in reserved areas
at the beginning of each floppy disk. On power-up, the ROM-resident bootloader
would look for a floppy disk in drive A: and load from it the
By modern standards CP/M was primitive owing to the extreme constraints on
program size. With version 1.0 there was no provision for detecting a changed
disk. If a user changed disks without manually rereading the disk directory the
system would write on the new disk using the old disk's data, ruining the data
stored on the disk. Starting with 1.1 or 1.2 this danger was reduced: if one
changed disks without reading the new disk's directory, and tried to write to
it, the operating system would signal a fatal error, avoiding overwriting but
requiring a reboot (which took no more than a few seconds).
The majority of the complexity in CP/M was isolated in the BDOS, and to a
lesser extent, the CCP. This meant that by porting the limited number of simple
commands in the BIOS to a particular hardware platform, the entire OS would
work. This significantly reduced the development time needed to support new
machines, and was one of the main reasons for CP/M's widespread use. Today this
sort of abstraction is common to most OSs, but at the time of CP/M's birth, OSs
were typically intended to run on only one machine platform, and multilayer
designs were considered unnecessary.
The command processor or CCP accepted input from the keyboard. All CP/M
commands had to be typed in on the "command line" — the screen would show most
often A> and would await input from the user.
command line interface was patterned after the operating systems from Digital
Equipment, such as RSTS/E for the PDP-11.
Commands generally took the form of a keyword followed by a list of
parameters separated by spaces or special characters. If an internal command was
recognized, it was carried out by the CCP itself. Otherwise it would attempt to
find an executable file on the currently logged disk drive and user area, load
it, and pass it any additional parameters from the command line. On completion
of a transient program, CP/M would reload the part of the CCP that had been
overwritten by application programs — this allowed transient programs a larger
The commands themselves could sometimes be obscure. For instance, the command
to duplicate fileswas named PIP (Peripheral-Interchange-Program), the name of
the old DEC utility used for that purpose. The format of parameters given to a
program was not yet standardized, so that there was no single "option character"
that differentiated options from file names (only the last version of CP/M
included options in square brackets fairly consistently).
Basic disk operating system
The basic disk operating system (BDOS) provided access to such operations as
opening a file, output to the console, or printing. Application programs would
load processor registers with a function code for the operation, and addresses
for parameters or memory buffers, and call a fixed address in memory. Since the
address was the same independent of the amount of memory in the system,
application programs would run the same way for any type or configuration of
Basic input output system
The basic input output system or BIOS provided the lowest level functions
required by the operating system. These included reading or writing single
characters to the system consoles and reading or writing a sector of data from
the disk. The BDOS handled some of the buffering of data from the diskette, but
before CP/M 3.0 it assumed a fixed disk sector size of 128 Bytes, as used on
single-density 8-inch floppy disks. Since most 5.25-inch disk formats used
larger sectors, the blocking and deblocking and the management of a disk buffer
area was handled by model-specific code in the BIOS.
File names consisted of up to 8 characters, a period, then up to three
characters as a file name extension. The extension usually identified the type
of the file. For example, .COM indicated a binary executable
program file, and .TXT indicated a file containing
File size was specified as the number of 128-byte records (directly
corresponding to disk sectors on 8-inch drives) occupied by a file on the
disk.There was no generally supported way of specifying byte-exact file sizes.
The current size of a file was maintained in the file's file control block (FCB)
by the operating system. Since many application programs (such as text editors)
prefer to deal with files as sequences of characters rather than as sequences of
records, by convention text files were terminated with a control-Z character
(ASCII SUB, hexadecimal 1A). Determining the end of a text file therefore involved examing the last record of the file to locate the
terminating control-Z. This also meant that inserting a control-Z character into
the middle of a file usually had the effect of truncating the text contents of
(timestamps) were not supported, although some later variants of CP/M added this
feature as an extension.
CP/M 2.2 had no sub-directories in the file structure but provided 16 "user
areas" to organize files on a disk. The user area concept was to make the
single-user version of CP/M somewhat compatible with multi-user MP/M systems. A
common patch for the CP/M and derivative operating systems was to make one user
area accessible to the user independent of the currently set user area. A
supported command was "USER x" where x is a value from 0 to 15. User 0 was the
default. If one changed to another user, such as USER 1, the material saved on
the disk for this user would only be available to USER 1; USER 2 would not be
able to see it or access it. Since CP/M was a single-user operating system, no
security was provided for the user command; nothing would prevent any user from
logging in successively as any of the 16 users. The user area feature arguably
had little utility on small floppy disks, though it was more useful for
organizing files on machines equipped with large
When Tim Paterson became the "father
of DOS" at the age of 24 it should not have come as a great shock to anyone
who knew him well. Growing up with a father who was an electrical engineer says
Paterson, "I got a lot of exposure to electronics stuff at home." He also says
that he learned a lot by reading and simply by experimenting on his own. It was
not until he went off to the University of Washington, however, that he first
came into contact with PC's. His roommate bought one and let him play around
with it. At the same time, Paterson was working as a technician at a retail
computer store in the Seattle area. This position allowed him to begin trying
to design his own computer boards. more...