Things to know about CP/M

While CP/M itself is standardized and the same on every CP/M machine, you may be surprised at poor interchangeability of files and sometimes programs between different manufactured CP/M machines.

CP/M disk storage is well defined, but with the exception of IBM type 3740 8" diskettes, almost no media was interchangeable. Every maker of machine used their own disk logical layout, number of directory entries, reserved tracks and sectors, the number of sides, and encoding density. SSSD, SSDD, DSDD were common acronyms: Single Sided Single Density (that 3740 format), to later DOS diskettes which were mostly DSDD, Double Sided Double Density (360K). See the Wikipedia article in the next section.

CP/M disks themselves do not store the necessary information from which to derive geometries. That information is external.

For anything graphical each maker had their own graphics hardware. Memory was expensive. Graphics, such as games, are tightly coupled to the machines they were designed for. CP/M generally wasn't a gaming platform.

The vast majority of CP/M software what character based, with cursor-addressable screens. Many or most CP/M machines were serial console machines requiring an external terminal; built-in displays were less common. This has the positive side effect that character-graphical software was usually configurable for one of the popular terminals; fZ80 emulates the Heath/Zenith H19, a popular and affordable terminal.

DISK STORAGE, SECTORS AND FILES

The "sector" is a basic unit of "size" in CP/M, used as if it were some understood Imperial unit. I suppose it is.

A sector is 128 bytes, the basic storage unit in the magnetic surface on a circular track of a spinning floppy disk, specifically the original IBM 3740-type (eight inch diameter) floppy disk of that 1970's revolution. That floppy disk contained 26 sectors in a track, and 77 tracks on one side of the disk. Within the next decade floppy disk sizes, magnetic density, and formats exploded in diversity, and a megabyte or more eventually became common, but mostly well after CP/M's time.

The CP/M file system stores everything in terms of sectors. There is no smaller unit. Files rounded up to the nearest 128 bytes. (The MAC.COM macroassembler file is 92 sectors.) What happens with the extra, unused bytes of a one-sentence text file? Read about this in TEXT FILES below.

If you are not a programmer and will never write a line of code that's about all you need to know about sectors: 128 bytes.

ENTERING COMMANDS, RUNNING PROGRAMS

The CP/M command line processor ("CCP") is superficially similar to a modern linux' BASH shell, barbarically primitive maybe but conceptually close. A DOS shell ("COMMAND.EXE") is much closer.

Web search for "how to use CP/M" and you will still find many! Alas, most of them have that dorky "seriously utilize your computer" manly man approach but at least there's a lot to choose from. Here's a book saved on the Internet Archive: "USING CP/M" by Judi N. Fernandez and Ruth Ashley.

RAM MEMORY

The fZ80 Operator's Manual contains a detailed "memory map" should you care. Low memory is small enough to be knowable. Memory addresses run from 0 to the maximum, 65535 decimal. The first block of memory (two sectors' worth), called "low memory", is reserved for CP/M and contains most of the interesting locations to know about.

When you type the name of a program on the command line ("WS" for WordStar) CP/M opens a disk file named WS.COM and reads the contents of that file into RAM starting at byte address 256 (100h) then executes it. WS.COM is about 7100 bytes and loads quickly; much of WordStar's code is contained in overlay files and is loaded in as the WordStar base code needs it.

(The CCP is very simple, and the number of 8080 machine instructions between you typing W, S, the ENTER key, and the binary program loaded into memory and arraanged properly is like 100 instructions; you can follow through them with the DDT debugger.)

Good CP/M programs work fine with files larger than available memory; they buffer and scroll, transparently and automatically, up to the maximum file size of 8 megabytes.

CP/M is succinct and it is quite reliable even by modern standards.

DISK STORAGE

50 years later, surprise, storage is infinite and nearly free. The "floppy" of fZ80 is the full-size SD card. The largest possible disk for CP/M 2.2 is a theoretical 80 megabytes; fZ80's are 32 megabytes. This is discussed in detail in the fZ80 Operating Manual.

"Logged in" removable media

CP/M contains the concept of a disk drive being "logged in". This is loosely analogous to a linux "mount"; it means that once a disk is accessed, via DIR or executing a program or opening a file on it, that disk is "logged in".

If you have "logged in" a disk, remove the disk from the drive and insert another, and then attempt to write to that disk, you will get the dreaded BDOS ERR: R/O error; the BDOS (Basic Disk Operating System) sees that the disk changed and has marked the drive as R/O, terse shorthand for READ-ONLY. Hopefully you are not discovering this after typing for an hour at a keyboard, as often this isn't easily recoverable. Reading a changed disk without logging-in is OK.

The solution to this is an easy habit to form: Whenever you change disk media, "warm boot" the system by typing Control-C on a command line, as the first character in the line. This "logs in" disk drives and now writing is safely done. Warm boot is evident by CCP displaying ^C, a brief delay and flickering of the access LED.

The "default drive"

The "logged in" disk is also the default disk for things like running programs and saving/loading files. Default drive is displayed in the command prompt. After initial system boot, this will be A>

Indicating that drive A is the default drive. Any command entered ("DIR") will apply to that drive. The default drive is also logged in, as described above, since after booting the first thing the command interpreter and BDOS does is scan the directory of files.

To change default drive, one simply enters the new drive letter and colon: A> B:

And after the directory on the new (B:) disk is read B: becomes your default drive, and all future commands default to that drive. This of course assumes that the media is free of errors. If an error is encountered, of the "bad sector" physical error variety you will get an error message and a prompt to retry. The problem is that, if retry does not solve it, there is no way to "back up" to a logged-in drive you know to be good, eg A: in this example. Pressing RESET becomes the only option.

Default drive is analogous to default directory in linux, if that helps.

But you are not limited to working on the default drive, only. You can specify the drive letter of any program you run or file you use. A not completely silly example is A> C:SYSBOOT B: A:CBIOS.HEX

Meaning, load the SYSBOOT.COM program (which writes CP/M bootable system components to disk system tracks) from drive C:, write to drive B:, the contents of the CBIOS.HEX file stored on drive A:.

Anything that you do not specify a drive for, will assume the current drive.

A suggested practice, when inserting a card to copy files to or from, is to reference the new drive in some way that does not commit you to yet making it default, such as: A> DIR B:

Drive A remains your default, logged in drive, while you list the contents of the directory on B:. The difference is that should there be irrecoverable errors, typing Control-C will abort the DIR command and leave you in your good default drive.

Text files

CP/M files have two odd features, that matter not at all when text stays within the CP/M world, but are alarming when ported outside to linux/unix, Macintosh, Windows.

Characters are 7 bits

CP/M text files are declared, in multiple places in the documentation, to use 7-bit characters, eg. ASCII-1967. The console device specifically states that the 8th bit should be stripped off... this is because, in a system as frugal as CP/M, every possible storage location is used, including that extra 8th bit in what you'd think are characters in text files.

WordStar notoriously sets the 8th bit (bit 7, 0x80, 128 decimal) in various places as file meta data. Most of the critical tools strip this 8th bit off and don't care. However exporting CP/M text files to outside-CP/M frequently makes them look like damaged binary, and unix/linux cat, less, more, etc, warn of binary files. (fZ80 provides the linux script cpm2unix to fix these.)

CP/M is notoriously provincial, as is most computer-anything from this era; U.S. ASCII text, no room for accented characters nor code pages or other character sets. You could store UNICODE in a CP/M file, but there is no way to graphically render it for display within CP/M.

Text terminator character(s) -- Control-Z

Another feature of CP/M is that it does not record exact file size; files are multiples of sectors (128 bytes). Of course rarely will a file's length line up on sector boundaries. End-of-text is flagged by a special character, Control-Z, aka ASCII sub, 18 decimal. Or more than one.

The linux tool dos2unix unfortunately does not know how to deal with these directly. fZ80 cpm2unix does.