Monday, 30. December 2024
[This article has been bi-posted to Gemini and the Web]
The first part of this article series covered CP/M 1.3 to CP/M 2.2 and took a look at the editor ED:
A journey into the 8-Bit microcomputing past: Exploring the CP/M operating system - part 1
This article relies even stronger on the manuals that I read (and a bit of information collected from the net), since CP/M 3 is the only one that I could run in the simulator. All the other variants I had no way to actually try them out, so I only have this indirect means of exploring them. (Well, MP/M-II is part of the z80pack emulator, but I did not have the time on my hand to figure out how to do the system customization necessary to load RSP programs and make it useful or how to simulate different consoles!)
After their very successful CP/M version 2.2, Digital Research also created several other specialized systems that belong to the larger CP/M family of operating systems. Some of these are really interesting from a technical perspective as they kept pushing boundaries of what was possible using microcomputers. One such bold move was the creation of MP/M.
In 1979, DR released MP/M, the "Multi-Programming Monitor Control Program". Based on CP/M 2.0, it adds an "extended I/O system" and an "extended disk operating system", referred to as XIOS (which includes the standard BIOS portion) and XDOS (which is separate from the also still needed BDOS).
The manual describes is as the following:
The purpose of the MP/M multi-programming monitor control program is to provide a
microcomputer operating system which supports multi-terminal access with multi-programming
at each terminal.
It mentions these as its core features:
As well as the following optional facilities:
While there really isn't much to envy today, considering the time I'd say this is pretty much amazing! Especially when you take into account that this is happens on an 8-bit microcomputer with possibly as little as 32 KB of RAM! When only one console is used and a single program executed, according to the manual the speed is approximately the same as with regular CP/M. It sounds like I/O could generally be distributed pretty well but compute-intense tasks were causing significant speed degradation - which is perfectly expected on a slow microcomputer.
Here's another paragraph from the manual that I found really interesting:
The MP/M Operating System is based on a real-time multi-tasking nucleus.
This nucleus provides process dispatching, queue management, flag management,
memory management and system timing functions.
Even if that probably does not live up to what we understand from these terms today (for example the "nucleus" is what we call a kernel now and multi-programming mentioned above essentially is the same as multi-tasking as it means that multiple programs can run at the same time), it's still a fascinating accomplishment. Keep in mind that we're talking running real-mode programs with direct hardware access - protected mode only became a possibility with the introduction of Intel's 80286/80386 processor half a decade later!
M/PM does not come with the CCP and thus cannot offer any built-in commands. It does not come with a standard set of transient programs, either! It was in fact built to be customized for its respective purpose on site. The program that is loaded for every attached console is the CLI (Command Line Interpreter) which can execute programs from a disk (this could for example be DIR) and pass a command tail to it. There can be a total of 16 consoles attached, some of which can be master and some slave consoles. After cold boot, each console is automatically logged-in to the user area which corresponds to the console number. Users can be switched later, though.
Running programs can be aborted with CTRL-C if they are attached to the console or by running the ABORT command. It's possible to execute Resident System Processes which don't need to be loaded from disk because the operating system loaded them into memory during booting and they remain there. It's possible for the user to detach a program from the console without aborting it by pressing CTRL-D or programmatically by making an XDOS detach call. The ATTACH command can be used to attach the console to a detached program (the limitation is that that is only possible from the console it was detached earlier).
M/PM can run two types of programs: Regular CP/M COM commands which require an absolute TPA or PRL commands which are relocatable programs and can be executed in a relocatable memory segment. The typical commands are called CUSPs ("Commonly Used System Programs"). Many of these are the same as with regular CP/M, but there's also some which are unique to MP/M:
MP/M also features a facility known as RSPs (standard resident system processes). They can be files on disk or resident system processes. RSPs available must be selected at system generation time:
Here is an example output for MPSTAT from the manual:
****** MP/M Status Display ******
Top of memory = FFFFH
Number of consoles = 02
Debugger breakpoint restart # = 06
Stack is swapped on BDOS calls
Z80 complementary registers managed by dispatcher
Ready Process(es)
MPMSTAT Idle
Process(es) DQing:
[Sched ] Sched
[ATTACH ] ATTACH
[CliQ ] cli
Process(es) NQing:
Delayed Process(es):
Polling Process (es)
PIP
Process(es) Flag Waiting:
01 - Tick
02 - Clock
Flag(s) Set:
03
Queue(s): MPMSTAT Sched CliQ ATTACH MXParse
MXList [TmpO ]MXDisk
Process(es) Attached to Consoles:
[0] - MPMSTAT
[1] - PIP
Process(es) Waiting for Consoles:
[0] - TMPO DIR
[1] - TMPl
Memory Allocation:
Base = OOOOH Size = 4000H Allocated to PIP [1]
Base = 4000H Size = 2000H * Free *
Base = 6000H Size = 1100H Allocated to DIR [0]
The whole idea of the microcomputer revolution was to build machines that were cheap enough to allow wasting processor time serving a single user. DR created their CP/M operating system to fulfill exactly that goal - and then attempted to turn the "micro" into a little "mini" with MP/M! And here's the weird outcome: It turned out to be feasible to create a multi-user system on a microcomputer!
While such a system certainly was a lot slower and could not handle as many users as the common minicomputers could, MP/M was impressive work. It also lead to various innovations that standard CP/M would later benefit from.
CP/M-86 is DR's port of CP/M-80 (as it was now called in retrospect) version 2.2 to the 16-bit Intel 8086/8088 platform. The OS can run on systems with as little as 32 KB of RAM but for the assembler and many other programs at least 64 KB are required. It can address up to 1 MB of RAM (which is the limit of the CPU) and allows for up to 16 disk devices of 8 MB each for 128 MB of disk storage in total (hard disks of 5 MB in size were available at that time but not common, yet). The directory for any drive allows to store up to 64 files.
The 86 version of CP/M uses the file type of CMD for transient utilities and A86 for assembler source files. Program files in hexadecimal format have the type H86. There's a couple of new transient commands available:
CP/M-86 mostly brought over Digital Research's operating system to the new platform. A few commands like COPYDISK were taking advantage of the memory-wise much more capable machines, but to me it looks like the system was not meant to innovate too much.
Speaking of innovations: These clearly were what the second release of the multi-user OS was about. Released in 1981 as well, MP/M-II is an improved version of M/PM. It requires at least 43 KB of RAM instead of 32 KB. Like the previous version, it can support up to 16 physical or logical drives. However each of them may now be up to 512 MB in size instead of just 8 MB! It also supports up to 16 printers.
Using banked memory, the system can address up to 400 KB of RAM. This means that while the processor has a limited address space of 64 KB, the OS could choose _which_ 64 KB would be visible if there were multiple 64 KB banks. In each of the banks the OS would use a tiny bit for itself, storing enough logic in there to execute programs and be able to switch back to other banks. So while on the main bank MP/M-II used 43 of the 64 KB for itself, leaving only 21 KB for the programs, in each bank the OS would use only about 4 KB or so, leaving roughly 60 KB for the programs!
MP/M-II ships with over 30 utilities, some of which can be incorporated into the OS at system generation time, others executed from disk. At system generation, a number of characteristics are decided upon. For example it's possible to define a 'system disk' on which the OS will look for programs if they cannot be found on the current default drive. It's also possible to define a drive for temporary files.
There's a couple of new commands:
MP/M-II introduces a password feature: Files can be protected with passwords to avoid them being deleted, modified or viewed without being authorized to do so. It's possible to protect 'read', 'write' and 'delete' operations (or any combination). Passwords are part of the filespecs, they are appended after a semicolon. It's also possible to protect an entire drive with a password.
In addition to the 'dir' or 'sys' attribute flag and the 'RW' or 'RO' attribute flag, MP/M-II introduced the 'archive' attribute that is set for files that a backup is made for using the [A] option to PIP, so it's skipped for the next backup (the is flag automatically cleared by the OS if the file is modified). There are also four user-defined attributes, F1 to F4 that can be used as the operators see fit. Programs with the 'sys' flag can be executed from any user area if they are in user area 0, which is very useful.
Another innovation was the XFCB or "eXtended File Control Block". They are used to record a password for a file and can also contain two stamps for files: One for when it was last updated and the other to either record the file creation date or the date when it was last accessed.
Even though MP/M-II again needs more valuable RAM for itself, DR has packed so much new functionality into it that it's hard to believe. It's not hard to see that it all makes perfect sense on a multi-user operating system, though, and I would say that MP/M was approaching to become "the Unix of microcomputers" (early Unix was quite primitive, too, after all - which I appreciate as I hold the theory that many of the Unix principles that we've come to love owe their existence to programmers that were forced to work in frugal environments)!
Obviously 1981 was a busy year for Digital Research as they not only released CP/M-86 and MP/M-II but also MP/M-86, the Intel 8086/8088 port of their multi-user offering. The OS needs at least 64 KB of RAM but can make use of up to 1 MB which is the maximum for this platform. It can manage up to 16 logical or physical drives which each up to 512 MB in size like MP/M-II. Unlike MP/M-II it also supports up to 254 I/O devices including system consoles, terminals and printers.
I only skimmed the manual, but it looks that DR mostly used the advanced capabilities of the x86 platform to push the general limits. Otherwise MP/M-86 is probably a pretty straight-forward port of MP/M-II. They were released in the same year, so there probably weren't any major new developments in between.
Porting the new MP/M to the 16-bit Intel platform seems like a pretty obvious thing to do. Not only were these new processors clearly the future of microcomputing, but it would also free the OS from the shackles of having to use tricks to address more then 64 KB of RAM. Not having to do bank switching was a major benefit - and being able to run on faster processors certainly did not hurt, either, especially for a multi-user OS! Interestingly I've read somewhere that it never ran on IBM XT compatible machines and only targeted Intel development systems. One can only guess why it never turned into a proper product. Probably because MP/M in general was not that successful?
After finishing the first version of MP/M, Digital Research started another amazing project: CP/NET. While MP/M was able to serve several consoles from one computer, CP/NET expanded this to a real client-server model! Like with the kernel, standard terminology did not exist at that time and so while MP/M was indeed called the server, the clients were known as "requesters".
CP/NET is described as a "network operating system" consisting of two or more microcomputers, one of which is an MP/M-II server, and at least one CP/M requester that can talk to the server. The requesters don't require a console but having one is strongly recommended. Interestingly, while the server could have between 1 to 16 logical or physical disks of up to 8 MB each, the requesters could have 0 to 16. Yes, that's right: They could use disk storage of their own or work _diskless_.
This was possible because the operating system was ROMable: It could be shipped in a ROM chip from which it was booted and then worked entirely over the network! Yes, the idea of what would become "thin clients" much, much later, was already there - and working in the early 1980s! However in terms of sales, CP/NET was a massive failure. DR were _too far_ ahead of their time and people who wanted networking did so using minicomputers and not yet with microcomputers. But let's take a closer look.
DR was clear-sighted enough to transfer the approach that had made their OS so successful to the network and created it in a 'network independent' fashion (today we'd say that it's network-agnostic). The SNIOS (Slave Network I/O System) and the NETWRKIF (Network Interface Process) were the hardware-dependent parts of the requester and the server respectively. They had to be modified depending on which networking hardware and protocol to use and then for the actual programs networking would just work. (Compare this to networking later on DOS where the OS had no idea of it and every application had to implement it itself!)
So CP/NET is the middle layer or interface between either MP/M and CP/M or CP/NOS (CP/Network Operating System, the ROM variant). On the requester side, the special variant of CP/M works with SNIOS instead of the standard BIOS and NDOS (Network Disk Operating System) instead of standard BDOS. Like on the mini, the system allowed for electronic mail, too. It is also not limited to one server and multiple requesters, but requesters can access resources from multiple servers as well. CP/NET allows for sharing and transferring disk files as well as printers, consoles and even programs or databases.
The following paragraph in the manual is a testament to how visionary their approach was:
CP/NET operates in multiple-processor environments ranging from tightly to loosely
coupled to networked processors. In this manual, tightly coupled processors are those
sharing at least a portion of common memory. Interprocessor messages communicate at
memory speed. Loosely coupled processors do not have access to memory that is common
or accessible by both processors; they communicate via a short, high-speed bus.
Loosely coupled processors usually reside in the same physical box. Networked
processors are usually physically separated and communicate over a serial link.
The manual describes multiple possible network topologies: A single requester networked to a single server, a hub-star where multiple requesters are connected to a single server, a bus configuration where multiple requesters are networked to multiple servers and a hybrid one which includes bus, star and loop topologies.
CP/NET works on unmodified MP/M-II and CP/M 2.2 systems. To make an MP/M system capable of networking, the SERVER resident system process has to be added an SYSGEN time and the customized NETWRKIF tailored to the respective networking gear has to be available as well. On the requester, the NDOS.SPR, SNIOS.SPR and CCP.SPR objects are used and loaded into memory to provide the required functionality. The CPNETLDR program takes care of this. NDOS for example decides if a requested files is local and can be directly accessed or if it's remote and a message must be sent over the network (and its transmission controlled).
The manual describes the SERVER process as providing the following functionality:
The latter are possible user-defined functions which means that the system is actually extensible!
CP/NET ships several new commands for the requester:
It's not easy to trace the history of CP/NET. A manual from 1982 survived and is probably for CP/NET 1.2, the last release. This version requires MP/M-II to act as the server. The Vintage Computing Lab (homepage is available in German only) owns copies of source code printouts for CP/M 2.2 and CP/NET 1.0.
Vintage Computing Lab: History of CP/M (in German)
These are extremely rare objects, as there were only two copies sold to companies in Europe (one being Siemens, the other one either Sinclair or Apricot in England). The notable thing here is that both printouts date 1980, so the first version of CP/NET was released before MP/M-II.
Since I like the introduction in the foreword quite a bit, here it is:
Welcome to the world of microcomputers opened to you by your eight-bit microprocessor.
Welcome also to the world of application software accessible with your Digital Research CP/M
Plus" operating system, also called CP/M(r) 3. Digital Research designed CP/M(r) 3 especially for
the 8080, 8085, Z80(r) or equivalent microprocessor that is the heart of your computer.
What CP/M 3 Does For You
CP/M 3 manages and supervises your computer's resources, including memory and disk storage,
the console (screen and keyboard), printer, and communications devices. It also manages
information stored magnetically on disks by grouping this information into files of programs or
data. CP/M 3 can copy files from a disk to your computer's memory, or to a peripheral device
such as a printer. To do this, CP/M 3 places various programs in memory and executes them in
response to commands you enter at your console.
Once in memory, a program executes through a set of steps that instruct your computer to
perform a certain task. You can use CP/M 3 to create your own programs, or you can choose
from the wide variety of CP/M 3 application programs that entertain you, educate you, and help
you solve commercial and scientific problems.
Version 3 of the OS comes in two variants: banked and nonbanked, depending on the machine it is meant to run on. The smaller nonbanked version requires at least 32K of RAM to operate, the banked version requires 96K (but can use up to 16 banks of memory to make even more memory available to the system). CP/M 3 was distributed on two floppies: A system disk and a utilities disk. While it could still run with only one drive, two were recommended.
The manual starts with 4 sections for the complete newcomer to CP/M. The first one provides a general introduction (with examples that show how to create a backup of the distribution disks), the second one explains files, disks and drives.
Interestingly, the list for reserved characters not usable in file names has not only grown again, but it seems that the % sign is no longer reserved? Here's the new list with 5 new characters on it: < > . , ; : = ? * [ ] | ( ) / \ ! & $ + -
The banked version of CPM/3 can protect files with passwords, which are handled on the command line by appending them directly after a file name, separated by a semicolon. Another new feature are so-called user areas which can be used to group files together. User area 0 is the default which is compatible with previous versions of CP/M, but areas 1 to 15 can be used for files which will not be visible on the disk unless the user is changed to the respective number. files in user area 0 that have the system attribute can be executed (programs) or read (data files) from other user areas to avoid having to duplicate them. Unless the user area is 0, the number is displayed before the drive name in the prompt - for example 2A>.
Files can now have date and time stamps if the feature is enabled for the disk. At the user's discretion, CP/M can record _either_ the creation date or the last access date for each file, but not both.
Chapter 3 of the manual is about the console and printer. A very useful feature is that DIR, TYPE and other commands now support _paging_. When data is longer than what would fit on the screen, the output stops, printing "Press RETURN to Continue" on the last line. This means you no longer have to stop and resume the output manually using a control sequence!
CTRL-P toggles printer echoing. When printing is on, any characters appearing on the screen are also printed. Together with stopping and resuming the console this can be used to print out parts of a file. To do so you'd TYPE the file, stop the output right before the part you want to print, enable printing, continue the output, stop again at the position after which you don't want it printed, turn printing off and resuming output once more. Sounds rather inconvenient? Probably, but it obviously worked that way!
Banked CP/M even supports line editing, which means that you can fix misspelled command lines rather than typing everything again! You have to memorize control characters for this (like CTRL-W for bringing back the previous command line, CTRL-B for bringing the cursor to the beginning of the line, CTRL-F for moving forward and CTRL-G for deleting characters), but it's a huge step forward. There's 14 such control characters that actually allow for relatively comfortable command line editing.
Chapter 4 is about "command concepts". It looks like CP/M 3 now has 6 built-in programs: DIR, DIRSYS (which displays files with the system attribute), ERASE, RENAME, TYPE, USER (switch user area). It's interesting to see that some of these also exist as transient utility programs - for example there's DIR.COM, even though DIR is a built-in. The reason for this is that version built into the CCP (certainly for size reasons) provides only the bare minimum of functionality while the transient program accepts various parameters that modify its behavior.
While CP/M still searches in the active user area (if applicable) of the current device and then in user area 0 for a file when told to, it is now also possible to define a "drive chain" and possibly look for files in up to 16 locations!
It is now possible to issue multiple commands in one command line by separating them with an exclamation mark. The following command line lists all files and all system files present in the active user area of the current drive:
DIR!DIRSYS
Creating .SUB file with several commands and running them with SUBMIT of course still works. The OS now looks for the special file PROFILE.SUB during cold start and automatically executes it (this is where DOS' AUTOEXEC.BAT originates from!). This is useful for bringing a system into the desired normal state after booting it: Maybe you want to set a drive R/O or you want to define the drive chain.
Another new feature of CP/M 3 is the HELP utility which provides online help for the commands that come with the OS!
Chapter 5 is the Command Summary. There's a lot of interesting things in here. A couple of programs that were part of previous CP/M versions are gone: The functionality of STAT is now covered by DIR and SHOW, ASM has been replaced by MAC and DDT is superseded by SID.
A new command is DATE which is used to display date and time information (or set it). CP/M defaults to the creation date of the system unless manually set to the correct date.
The logical devices that CP/M uses have been reduced to 5 (probably because the original names have long since become arbitrary names without meaning in most cases): CONIN, CONOUT, AUXIN, AUXOUT and LST. There's other names that refer to the same devices as well: CON and CONSOLE (both CONIN and CONOUT), KEYBOARD (CONIN), AUX and AUXILIARY (both AUXIN and AUXOUT) and PRINTER (LST). The new DEVICE command can be used to view what physical devices these are mapped to or change the mapping.
In addition to the DIR command (which will no longer display files with the system attribute but notify the user if there's any in the respective user area of the drive directory!) there's now the DIRSYS (may be abbreviated to DIRS) command for displaying system files. The transient version of DIR accepts several options that make it much more powerful: For example it can list files that have a specific attribute, it can display the date stamp (if active for the drive), it can list files from some (or all) user areas and it can even list files on multiple drives in a sorted output! Here's what standard DIR's output looks like on the system disk:
A>DIR
A: CPM3 SYS : VT100DYN COM : TRACE UTL : HIST UTL : PROFILE SUB
SYSTEM FILE(S) EXIST
Whereas requesting DIR to list files with their attributes results in this nice list:
A>dir [att]
Scanning Directory...
Sorting Directory...
Directory For Drive A: User 0
Name Bytes Recs Attributes Name Bytes Recs Attributes
------------ ------ ------ ------------ ------------ ------ ------ ------------
BYE COM 1k 1 Sys RW CLS COM 1k 1 Sys RW
CPM3 SYS 29k 230 Dir RW DATE COM 4k 26 Sys RW
DEVICE COM 8k 57 Sys RW DIR COM 15k 114 Sys RW
DUMP COM 1k 8 Sys RW ED COM 10k 73 Sys RW
ERASE COM 4k 30 Sys RW GENCOM COM 15k 115 Sys RW
GET COM 7k 52 Sys RW HELP COM 7k 55 Sys RW
HELP HLP 62k 496 Sys RW HEXCOM COM 2k 9 Sys RW
HIST COM 2k 14 Sys RW HIST UTL 2k 10 Dir RW
HISTCL COM 1k 1 Sys RW PIP COM 9k 68 Sys RW
PROFILE SUB 1k 1 Dir RW PUT COM 7k 55 Sys RW
RENAME COM 3k 23 Sys RW RESET COM 1k 2 Sys RW
SAVE COM 2k 14 Sys RW SET COM 11k 81 Sys RW
SETDEF COM 5k 34 Sys RW SHOW COM 9k 66 Sys RW
SID COM 8k 62 Sys RW SUBMIT COM 6k 42 Sys RW
TRACE UTL 2k 9 Dir RW TYPE COM 3k 24 Sys RW
VT100DYN COM 1k 8 Dir RW
Total Bytes = 239k Total Records = 1781 Files Found = 31
Total 1k Blocks = 239 Used/Max Dir Entries For Drive A: 35/ 64
CP/M 3 supports "Resident System eXtensions" (RSXs) which are discussed in the System Programmer's Guide which I did not read. There's quite some new commands as well:
CP/M Plus clearly was a major revision of the operating system. DR incorporated a large amount of features from the MP/M into it, most notably banked memory, password protection of files and the online HELP system.
It came with several innovations of its own, though, showing that the single-user line of the OS family had evolved on its own over time, too. Modularization of assembler code with relocatable objects and libraries of those allow for larger, more complex programs. This version of the OS also did away with some intermediary steps like a separate ERAQ command or SDIR, adding their functionality into ERASE and DIR respectively using parameters.
Also various parts of the BIOS were moved to the BDOS, shrinking the portion of the operating system that had to be adapted to the respective hardware it was meant to run on. Despite being somewhat slower than CP/M 2.2 which a lot of users that didn't need the new facilities decided to stay with, it was commercially successful because vendors licensed it for various machines.
There's a manual available, however it's in DR's TEX file format. It is ASCII and the control characters are relatively few but I just skimmed it quickly. It looks like this is basically CP/M Plus ported to the Intel 8086/8088 platform.
Proof of CP/M's portability is that the operating system was not just modified to run on a multitude of microcopmuter systems with Intel 8080 or Z80 CPUs but also on other architectures. In 1983, DR released CP/M-68K for machines with the Motorola 68k CPU. Interestingly, the CCP on this platform has SUBMIT as a built-in command rather than a transient! Executables use the 68K filetype rather than COM. Assembler source files are expected to have the file type S.
The system seems to be based on CP/M 2.2 but shipped a couple of different utilities (on 5 disks rather than 2!). Obviously it was meant as a sophisticated programming environment featuring the C programming language:
A year later, in 1984, CP/M-8000 was released for the Zilog Z8000 architecture. At this point the OS was provided on 5 1/4 inch diskettes. The file type for command files is Z8K, assembler files are named Z8N and segmented assembly source uses the type Z8S.
Again the port looks like it was based on CP/M 2.2 with SUBMIT contained in the CCP. It also came with some special commands:
Concurrent CP/M, sometimes abbreviated CCP/M, is the result from merging CP/M-86 and M/PM-86. It's probably also the result from DR realizing that MP/M was often used by power users who loved the ability to detach processes from the console but keeping them running. So they often used it as a single-user system rather than with multiple consolet attached or as a server for CP/NET. Concurrent CP/M is therefore described as "a multi- or single-user, multitasking operating system that allows you to do two or more jobs at the same time on one or more terminals." So it's designed to be used in either role as desired by the operator(s).
It's closer in functionality to MP/M-86 than plain CP/M-86, but adds a major new feature of its own: _Virtual consoles_ with the ability to switch between these! You no longer need to detach a program from the console but simply switch to another virtual console. The program running on the current console is said to be running in the foreground while other programs are running in the background. The presence of the ERAQ command gives away that the OS is derived from MP/M-86 and not CP/M-86-plus. To me it sounds a little weird that - despite bearing the version 3.1! - it was **not** the new "latest and greatest" version of CP/M for the 8086, but depending on what you wanted to do, either CP/M-86-plus or Concurrent CP/M would have been the right choice.
The manual has an additional section "What Is An Operating System?" which I think was a good idea to make the OS easier to get started with for people new to computers. Multi-tasking and virtual consoles are explained in simple terms - the latter being compared to a TV where you can switch between stations. There's two types of virtual consoles: _dynamic_ and _buffered_, where the former works like a TV: The program goes on while you switched away, and you have missed the output. In buffered mode, program output is saved to a file and you can later view what happened while you switched away from that virtual console. This is compared to using a video recorder.
Concurrent CP/M can display a status line which holds information like which virtual console is current, its operating mode, which printer is assigned to it as well as the name of the program running. It can also show on which drives there are open files so you don't accidentally remove the disk.
This is the first manual that mentions that some systems with hard disks may not require CP/M floppies to boot, so it looks like it's definitely possible to boot from hard disk now (I have no idea if it was before). Concurrent CP/M introduced a facility called startup files. These are simple files that can contain _one_ command line (which may be a SUBMIT command to run batch process a list of commands if needed). When the system has booted up, STARTUP.0 is executed for virtual console 0 (if it exists), STARTUP.1 for virtual console 1 and so on.
There are a couple of new commands available as well:
There's two versions of what happened between IBM, Microsoft and Digital Research. Let's stick to the fact that a contract between DR and IBM about licensing CP/M-86 for the PC was not made. Unfortunately for Kildal, who had thought that the PC would likely be one of the many microcomputers, the platform's open nature (and the big name behind it) made it become the standard. While initially CP/M was the superior system compared to the first versions of PC DOS, Microsoft had one killer feature going for them: Their FAT filesystem which soon supported subdirectories. DR had to witness the offshoot taking over and was ultimately forced to adopt to stay competitive.
After Concurrent CP/M, the system evolved into Concurrent DOS, then Multiuser DOS. CP/M-86-plus evolved into DOS Plus. Eventually Digital Research started over with a new operating system which gave up on CP/M compatibility: DR-DOS. We all know how Microsoft played down-and-dirty a couple of times, but that won them the day.
I will admit that when I wrote the first article, I left CP/M Plus over for this one because I wasn't sure how much I'd be able to write about the other versions. My guess was that "the rest" was slight variations (as seems to be the case with the ports to other architectures), but I was very much mistaken when it comes to MP/M and CP/NET! I did quite a bit of reading and could easily have written much more on any of the systems covered here. However my goal was to read some old manuals and get a first impression of what the systems that they covered were like, not to take a deep dive.
After doing so, I cannot confirm the statement in Wikipedia about DR having been known for their bad documentation. I have no idea if the one source they cite is the exception or if this was actually true. Whatever; I have read my fair share of bad documentation (and pulled out some hair over it), and I cannot say that DR's manuals felt lousy to me. I haven't tried to really use any OS from the CP/M family for real work and my background of knowing DOS from my childhood may also help in making heads and tails of things. But after reading the user part of all those manuals I have never felt that I'd be lost if I had to use the system. Maybe the programmer's part is terrible, I don't know, but I somehow doubt it.
For me this was a fascinating journey with quite a few surprises - and it once again made me realize that I would like to know more about early microcomputers. This article was not written using ED, but I created a quick port for FreeDOS' _edlin_. It's one of the DOS tools that I failed to understand when I was a child and lost without EDIT.COM. It's derived from CP/M's ED, which means after reading about that, I should in theory be able to use it, right? So chances are that if I ever write a retro-computing article again, I might leave my trusty nvi behind for once.