CP/M for Single-Drive Systems

---

The CP/M operating System was not intended for use on computers with only one disk drive. The Filecopy program makes it easier.

---

Ken Barbier Borrego Engineering PO Box 1253 Borrego Springs, CA 92004

Since the CP/M operating System from Digital Research was intended for an expensive microprocessor development system, its creator didn't anticipate the problems that some of us low-budget users encounter. Digital Research doesn't even seem to want to recognize the existence of mini-floppy disk drives and obviously never intended the system to be used in single-drive environments.

But CP/M is available for such mini-based systems as North Star, Micropolis and TRS-80, since it has been adapted to these formats by vendors who are licensed by Digital Research to make such adaptations. And some of these personal computer systems run CP/M on a single disk drive.

This can lead to complications and inconveniences. But mini-floppies themselves are convenient, and the price is certainly right. The major problem is in transferring your programs from one disk to another to provide the safety of a backup copy.

I wrote Filecopy to overcome this problem. Since it takes up only 1K of disk space, the cost is low.

This program will let you copy any type of CP/M file from one disk (the read disk) to another (the write disk) in a few seconds with little fuss. It can even help recover files with read checksum errors, which most systems software will not accept.

Of course, Filecopy can't correct data errors, but you can tell the program to ignore read checksum errors, and the output file will have the checksum correct, permitting later manual patching of the data errors.

Filecopy's console messages have no mysterious codes. Any errors encountered are spelled out clearly, as shown in the sample console messages in Example 1.

A>FILECOPY STUFF.BAS SINGLE DRIVE FILECOPY V80.1 11 FEB 80 READ DISC IN DRIVE. THEN CR FILE DOES NOT EXIST! BACK TO CP/M? A>FILECOPY DUMP.COM SINGLE DRIVE FILECOPY V80.1 11 FEB 80 READ DISC IN DRIVE. THEN CR WRITE DISC IN DRIVE. THEN CR FILE ALREADY EXISTS. ENTER: X TO ABORT CR TO ERASE IT ALL DONE! BACK TO CP/M? A> Example 1. Console messages displayed during a typical Filecopy operation. The first file named did not exist on the input disk, so the operator was given a chance to swap disks before the program reloaded the CP/M operating system. The second file requested for copying, DUMP.COM, was found on the input disk and loaded into memory. When the output disk directory was checked, it was found to contain a file with the same name. The operator is given the option of updating this existing DUMP.COM file or returning to CP/M.

The program listing includes pauses at strategic points to let you change disks at leisure and correct read, write or operator errors in simple fashion. For example, you can load Filecopy from one disk, and it will prompt you for the disk from which you want to read a file. If the read file is on a different disk, you place it in the drive and hit the carriage-return key (CR). When the read file has been loaded into memory, the program prompts for the write disk and waits for another CR.

At any of these pauses, you can abort the entire operation and reload CP/M by typing X instead of CR. The same is true following error messages. Recoverable errors are displayed, and you can choose to correct the error, ignore it or reload the system. In the case of nonrecoverable errors, either the CR or X will reload CP/M, since there is no valid option in this case.

Since the purpose of the program is to opy one file from a read disk to a write disk, there are few options available and virtually nothing to learn. As in Example 1, you call for the program by name and include the file name and file type that you want to copy.

In the first example, I want to make a backup copy of the BASIC language file named STUFF. Filecopy is loaded, displays the sign-on message and asks me to place the disk with the source file on it into the drive. Usually this is the disk already in the drive, so I type a carriage return on the console (this action is obviously invisible on the printout).

The program searches the disk file directory for STUFF.BAS, and in this example cannot find it. A pause following "BACK TO CP/M?" allows me to change the disk in the drive if I want, before going through the CP/M reload.

Now I remember that it was DUMP.COM that I wanted to copy, so I once again call for the copy program, giving the file name on the same line. This time, Filecopy finds the file and loads it into memory and then pauses after asking for the output disk to be placed in the drive. Following the CR, the program searches this disk directory and discovers that it already has a file by that name.

If I'm totally confused by this, I can type X to reload the system and then display the directory to get things sorted out. But in this example I know that I want to replace an old version of DUMP with a new update, so I type CR. Filecopy will now erase the old file and write the new file on the disk. Following this is another pause to let me insert my original disk, or any other, before the exit back to CP/M.

That's all there is to using the program, I made no attempt to incorporate exotic features such as changing the file name between read and write or making multiple copies. I kept it simple and small, so that it only takes up 1K of disk space, the minimum possible under CP/M.

The program will most often be used to make a quick backup of a file following a long edit session. And when your program has been fully debugged, Filecopy is the quickest way to move the resulting .COM file to other disks.

The first thing you will probably want to do with Filecopy is use it to place a copy of Filecopy.COM on each of your disks.

I won't try a detailed discussion of the program here, since the listing is heavily annotated, and assembly-language programmers will find it completely straightforward. I assume you have some familiarity with the internal workings of CP/M for the following optional discussion. Readers only interested in using the program can skip the rest of the text and start typing.

All console and disk I/O is passed through the single BDOS entry point accessed through the jump instruction at location 5. Filecopy exits through the reload vector placed in location 0 by CP/M. The program uses the standard file control block and sector buffer defined by CP/M. It is otherwise totally self-contained and requires that no changes be used with any version of CP/M.

Since the copy operation is done in one pass, there is a size limitation on the files that can be copied. Data will be loaded into memory from the BUFFR starting at 0487H up to just below CP/M's BDOS, overlaying the CCP, as does PIP.

In a minimum 16K byte version of CP/M, the file size is limited to over 11K bytes. This should prove no inconvenience to the user of a 16K system, since the only file that big you will probably ever generate is a print file, which is not normally ever copied or backed up.