Ok, so the title isn’t as catchy as “Back to the Future,” but my guess is a lot of people who are advanced Linux users have — at least — a slight interest in retrocomputing. You’d like an Altair, but not for $10,000. You can build replicas of varying fidelities, of course. You can also just emulate the machine or a similar CP/M machine in software. There are many 8080 or Z80 emulators out there, ranging from SIMH to MAME. Most of these will run on Linux or — at the least — WINE. However, depending on your goals, you should consider RunCPM. Why? It runs on many platforms, including, of course, Linux and other desktop systems. But it also will work with the Arduino, Teensy, ESP32, or STM32 processors. There is also experimental support for SAM4S and Cyclone II FPGAs.

It’s pretty interesting to have one system that will work across PCs and embedded hardware. What’s more is that, at least on Linux, the file system is directly translated (sort of), so you don’t have to use tricks or special software to transfer files to and from CP/M. It is almost like giving Linux the ability to run CP/M software. You still have to have virtual disks, but they are nothing more than directories with normal files in them.

Goals

Of course, if your goal is to simulate a system and you want to have 180 kB floppies or whatever, then the direct file system isn’t a benefit. But if you want to use CP/M software for education, nostalgia, or cross-development, this is the way to go, in my opinion.

It isn’t just the file system, either. If you need a quick utility inside your bogus CP/M environment, you can write it in Lua, at least on desktop systems. On the Arduino, you can access digital and analog I/O. Theoretically, you could deploy an embedded Altair for some real purpose fairly cheaply.

Building and Running

You must build the project, which varies depending on where you want to target. For Linux, it is easy. Change to the RunCPM directory and type:

make posix build

Once you have an executable, it will expect to find subdirectories for each disk drive. In addition, user areas are mandatory, so it isn’t sufficient to have disk A. You need disk A/0, A/1, etc. Drive letters can be from A-P and user numbers are from 0-F.

In other words, if your executable is at ~/runcpm/RunCPM, you should also have ~/runcpm/A/0 so there’s something in the A drive. You might also want other user numbers and drives (e.g., ~/runcpm/B/4).

The GitHub repository has a Zip file with a complete set of programs you can place in the A/0 subdirectory to get started. The author also has a comprehensive set of CP/M programs you can use directly. These are already organized into disks, so just download it to the right place, and you’ve got almost any CP/M application you can imagine.

In any event, when you run the program, you’ll see the subdirectories as disks. It is easy to copy things into the disk directories or your regular file system. Just be careful that everything is in uppercase. The shell will shift your input to uppercase, but it won’t shift file names, so if you can’t find a file you know is there, it may be because the file name is in lowercase. Symbolic links work, too.

If your memory of CP/M is shaky, here’s a very short reference:

• Directory: dir
• Rename file: ren new.txt=old.txt
• Remove file: era file.txt
• Switch to disk F: f:
• Switch to user 4: user 4
• Copy file: pip a:copy.txt=p:orig.txt  (or pip a:=p:orig.txt to keep the name)
• Copy many files: pip a:=p:*.txt
• Copy files from user 4 to current user (spaces matter): pip a:=p:*.com[G4]
• Display file: pip con:=afile.txt
• Exit (specific to RunCPM; needs EXIT.COM): exit

Limitations

Obviously, anything that knows about the CP/M disk structure, like MOVCPM or STAT, won’t work right. Anything that cares about terminal manipulation but doesn’t know how to work with a VT100 terminal won’t look right. You can’t use CP/M file attributes. I/O ports don’t exist as CP/M understands them.

It would be nice if you could somehow associate CP/M file types to simply execute from the Linux shell, but that’s not how it works. Instead, you must start a CP/M command processor and do it from there. On the other hand, with the submit system and some Lua code, you might be able to work something out. Or, of course, the source code is there, so knock yourself out, and let us know when you do it.

You can select several different command processors that allow for different amounts of memory or features. However, many of these present more memory than a real system would probably support. If you were trying to develop for real hardware, this could be a problem.

Why?

If you read Hackaday, you probably don’t need to ask why you would want to run a decades-old operating system. You either want ot or you don’t, and there’s no really good answer. I admit that I sometimes fire up Wordstar either to enjoy writing with it, keep my finger memory for its commands alive, or to read some super old document file I produced a very long time ago.

There were some excellent Forth systems that still work well. The C compilers are historically interesting, but not great. Using Wordstar or another text editor, you can develop 8080 or Z80 code destined for another piece of hardware efficienctly. Since the file system is transparent, you can even use your favorite code editor like Visual Studio, Vi, or Emacs. So while this isn’t something you’ll probably do every day, it is a very handy way to go back in time and compute like it is 1982.

There’s More

We’ve seen plenty of 8080/Z80 simulators, of course. We figure if you are going to emulate, you might as well stick with the Z80. The number of emulators out there is nothing short of staggering. We’ve built one with FABGL on an ESP32. You can even make one in an Arduino shield form factor.