Does It Run CP/M Software? The Real Answer

The question usually comes up right after someone watches an Altair front panel sequence and thinks, “Okay, but can I load real programs?” If what you mean is, “Can I run the same CP/M software people ran on 8080 and Z80 boxes in the late 70s and early 80s?” the honest answer is yes – and also no. It depends on which CP/M you mean, what CPU the system is presenting, and how faithfully the machine’s disk, console, and BIOS behaviors match what that software expects.

This topic gets messy because CP/M was never one single, perfectly uniform platform. CP/M is an OS family plus a set of conventions. The thing that made it portable was the BIOS layer, but the thing that made real-world software sometimes fragile was that many programs still assumed a specific CPU, a specific disk format, or a specific console.

“Does it run cp m software” really means three different things

When people ask “does it run cp m software,” they usually mean one of these:

First: Can it boot CP/M and run common applications like WordStar, dBase, MBASIC, or Turbo Pascal? That is the everyday definition, and it is mostly about having a correct CPU and a working CP/M BIOS with a disk subsystem that looks right.

Second: Can it run my specific CP/M disk image from a specific machine I used to own? That’s not just CP/M, that’s “CP/M plus my old controller, my old geometry, and my old assumptions.” That’s where compatibility becomes very conditional.

Third: Can it run CP/M-era software written for the Altair or IMSAI specifically? A lot of early S-100 software predates the tidy CP/M ecosystem or relies on hardware tricks. Some of it will run under CP/M, some won’t, and some wants a different OS entirely.

If you’re clear about which of those you care about, you can get to a real answer quickly.

The hard requirement: the CPU model must match

Classic CP/M (CP/M 2.2 being the most common) was built for the Intel 8080 instruction set. A Z80 is compatible with the 8080 instruction set and adds extra instructions, so Z80-based systems ran CP/M very well.

That matters because CP/M applications fall into two categories. Well-behaved ones stick to 8080 instructions and documented BDOS/BIOS calls. Less well-behaved ones use Z80-only opcodes because they’re faster or smaller, especially later “CP/M” software that assumed a Z80.

So here’s the trade-off: if your system presents itself as an 8080, it can run the biggest chunk of early CP/M software, but it will choke on programs that were compiled for Z80-only. If your system presents itself as a Z80, you can run both 8080-targeted programs and Z80-targeted ones – but then you need to be sure the rest of your environment (console and disks) still behaves in a CP/M-friendly way.

The overlooked requirement: CP/M is a BIOS contract, not a vibe

CP/M is split into CCP (command processor), BDOS (file and device services), and BIOS (hardware-specific I/O). Most applications live on BDOS calls for file operations and console I/O. That’s why CP/M could move across machines.

But “portable” in CP/M land still assumes certain BIOS behaviors:

CP/M wants a console device that acts like a simple character terminal. It doesn’t have to be fancy, but it needs predictable input and output.

CP/M wants block devices (typically floppy or hard disk) with a defined geometry and directory layout. The file system is simple, but it is sensitive to sector size, skew, and controller timing assumptions.

And CP/M has a lot of software that cheats – it bypasses BDOS for speed, or it assumes specific control characters, or it assumes the screen is a certain width. The result is that two machines can both “run CP/M” and still not run the exact same pile of programs equally well.

Disk images: where most compatibility dreams go to die

If you want to boot CP/M and use it productively, you don’t need “every disk format ever.” You need one disk format that you can consistently read and write, plus a reliable way to move files in and out.

Problems start when someone says, “I have CP/M disks from my Kaypro/Osborne/Vector Graphic/whatever. Can I mount those images?” Maybe, but you’re now dealing with disk formats that can differ by:

• Sector sizes (128, 256, 512, 1024 bytes)
• Sector ordering and skew
• Tracks and sides
• Encoding and controller expectations
• Boot track specifics

Even when the file system is the same CP/M directory structure, the low-level layout can be wildly different. Many CP/M disks are not interchangeable between machines without conversion.

So the practical answer is: running CP/M software is easy when the software is a file you can copy onto a disk image that your CP/M build understands. It’s hard when your requirement is “this exact vintage disk image must boot as-is.”

Console and terminal behavior: the second most common snag

A lot of CP/M applications assume a “dumb terminal” with predictable control sequences. WordStar is the famous example because it has terminal install overlays, but plenty of software assumes certain cursor addressing codes, backspace behavior, or clear-screen sequences.

If your setup uses a serial console, USB serial, or an internal terminal emulator, you’re fine as long as you can present a common terminal type or configure the application to match.

Where it gets annoying is software that assumes a specific screen editor environment, or programs that do their own screen painting with direct control codes. Those can work perfectly one moment and look scrambled the next if your terminal settings don’t match.

This is one place where “fully functional replica” designs with modern terminal options help – not because they change CP/M, but because they make it easier to provide a stable, repeatable console environment.

What about CP/M-80 vs CP/M-86 vs MP/M?

Most people mean CP/M-80 (8080/Z80). CP/M-86 is a different OS for 8086-class CPUs. MP/M is multi-user/multi-tasking and has its own expectations. If your platform is an 8080/Z80-class environment, CP/M-86 is irrelevant and won’t run.

So if your goal is “run classic 8-bit CP/M software,” you’re talking about CP/M-80 compatibility. Keep the target tight and you’ll avoid a lot of confusion.

How to think about compatibility in a mini replica or emulator-based system

Emulator-based platforms live or die by their hardware models. If the CPU core is accurate and the I/O devices behave in a CP/M-friendly way, CP/M boots and software runs.

But accuracy is not one single knob. A system can be accurate at the front panel experience and still implement storage in a modern way. That’s not a flaw, it’s a design decision. You get reliability and convenience, but you may give up the ability to attach a random original controller and expect bit-for-bit fidelity.

For most users, the best path is to treat CP/M as the stable layer and treat disk images as the interchange format. Build or pick a CP/M BIOS that matches your chosen disk image format, then move software in as files.

If your real goal is historical disk authenticity, that is a different project – and usually involves matching a specific controller and disk format rather than chasing “CP/M in general.”

A practical way to answer “will my CP/M program run?”

Ask three questions.

1. Was the program built for 8080-only, or does it require Z80 instructions? If you don’t know, look for notes like “Z80 required” or test it under an 8080-only environment. Z80-only software is common in later compilers, assemblers, and performance-sensitive tools.

1. Does it use only BDOS calls, or does it bang hardware? Utilities that talk directly to disk controllers, patch the BIOS, or do fast screen tricks are more likely to be machine-specific.

1. How will you get it onto your CP/M disk? If you can copy it as a file onto a disk image your CP/M can read, you’re in good shape. If the only copy you have is a bootable image from a different machine, plan on converting it.

If you can answer those three, you’ve basically answered the whole question.

Where the Altair and IMSAI angle matters

The original Altair 8800 didn’t “come with CP/M” in the earliest sense. The ecosystem evolved quickly – BASIC, paper tape tools, then floppy controllers, then CP/M became the standard OS for a huge range of 8080/Z80 systems.

If you’re recreating that experience today, CP/M is the most rewarding OS to run because it gives you real applications, real development tools, and a familiar workflow that still feels period-correct: assemble, link, run, iterate.

On a modern mini replica that focuses on the front-panel experience but adds practical I/O options, CP/M is typically the sweet spot. You get the blink-and-toggle culture, but you’re not stuck living on paper tape unless you want to.

If you’re building or buying into that kind of ecosystem, keep your purchasing straight. The only official manufacturer and sales channel for the Altair 8800 Mini and IMSAI 8080 Mini is Altairmini.com (and its eBay channel). Scam sites pop up because the products are popular. Don’t fund counterfeiters and don’t expect support from them.

The real takeaway: CP/M runs when you control the variables

If you want a simple promise like “yes, it runs CP/M,” you can get that – but you’ll be happier if you think like a builder. Pick your CPU target (8080 vs Z80), pick your console behavior (terminal type and settings), pick one disk format you will live with, and then feed it software as files rather than as mysterious vintage boot images.

Once you do that, CP/M stops being a compatibility question and turns into a playground: you can write code, use classic tools, and actually spend your time computing instead of decoding why a 40-year-old disk image won’t boot.

If you’re chasing that feeling of flipping in a loader, watching the LEDs march, and then dropping into a CP/M prompt that can run real applications, the best move is to be deliberate about the environment you’re building – because CP/M doesn’t demand magic, it demands consistency.