I'd intended this to be complete before the July 24..26, 2026 TEARDOWN '26 event, where I will be presenting a slide show about fZ80, but I ran out of time. So this is now "part one". But what's written so far is complete or close enough.
When I return I'll put the slideshow itself up here, hopefully a video of the hour-long talk. So for the short term:
Oh great, I need to have a policy on so-called AI.
An experimental archaeological look at an abandoned 8-bit operating system: Digital Research’s MP/M, for the Intel 8080 8-bit microcontroller (1978..1982).
Digital Research Inc, creators of the wildly successful CP/M operating system for the 8-bit Intel 8080, released their new real-time operating system, MP/M in 1978. (For contrast: the first C language port of unix was in 1978(1) MP/M provided preemptive multitasking, multiple consoles, daemons, inter-process messaging, and file sharing, field proven after its third release in 1982, 13 years before these features were available on Windows 95.
CP/M was popular and successful, but MP/M never got off the ground. By 1980 it was obvious to all that the 8086 was imminent, why did Digital Research waste time on advanced code for a dead-end CPU?
Two things are in tension:
I have brought up MP/M II 2.1 system using Digital Research's contemorary tools, MAC, RMAC, etc, running on my Friendly fZ80 computer, and have put in some modest effort tuning MP/M features, writing missing tools, developing workflows, sufficient to demonstrate at least some of the promise of MP/M, so all statements about MP/M function- and code-wise are from current experience.
This lets us ask, in an experimental archaeological way: What were contemporary expectations of MP/M? What did Digital Research’s intend for MP/M? How might one have used a multi-programming system in 1982? Who used it, and for what purposes? Businesses? Amateurs? Multiple terminals and users? One "power user"? What problems does it solve, and which new issues does it raise? What’s good about it? What sucks (beyond the obvious)? Are any of its ideas present, or meaningful, in current computing?
Friendly fZ80 Computer project started in January 2025 was to build a CP/M machine. I had been putting the idea off for a long time. Certainly some nostalgia was involved, and distraction from the terrible year (one in a series) but having worked with this stuff in its time, my nostalgia is offset by personal memory of the frustrations of inadequate software and primitive hardware of the time.
I wanted new hardware. 1980 hardware is unreliable, worse today: chips in dissimilar-metal sockets, card-edge connectors, the far end of the bathtub curve for everything, power hungry, bulky, heavy, hot, slow. Storage media such as floppy disks are scarce, even more unreliable, inadequate when new. Cathode ray tubes are eye-straining.
Good antique computers are expensive. I remember the fun of them but also the unreliability, bulk and overall difficulty. “Simple” things like good keyboards were exotic. I do understand that many people love the challenge of all that, as I have myself in the past; more power to them. But this project is not about that.
So in January 2025 I started on Friendly fZ80 as a CP/M machine. A physical thing, distinct and idiosyncratic and to the point, not software emulation in a window on a display; a toe-stubbable physical machine that retained the era's user experience, minus avoidable annoyances, as we might have wanted in 1980.
CP/M's workflow is designed around removable media. Even with large media the lack of usable file-organizing paradigms (directories/subdirectories etc) pretty much demands multiple and removable disks.
To summarize the technical research part, these things came together: the 600 MHz ARM CPU in Teensy 4.1 was in hand. I'd already decided that full-size SD cards were the trashy low-class inheritors of floppies. I came across VGA4BIT (2), on the PJRC forum. Web search turns up many Z80 emulators. I tested three(3), settled on David Lee's due to it being 20% faster than the others. Mockups proved these major components to be a workable combination.
fZ80 pushes hardware issues to the background, allows concentrating on the operating system and tools, making inherent limitations starkly visible.
The original fZ80 target was CP/M 2.2, not particularly difficult to implement. Initial bring-up was done on David Lee's NTVCM linux CP/M emulator(4) to write the ROM Monitor and initial CP/M BIOS, and code was brought into Z80 RAM via magic (firmware-side hex loader). CP/M was booting from the CP/M A: drive SD card by February and at that point NTVM was set aside. May to June was breadth: firmware changes for devices, bug fixes and features -- apparently no one but me uses multiple SD cards as removable storage -- and writing of many tools.
In July 2025 I brought fZ80 to TearDown '25, running CP/M.
Having this basis freed me to think: with hardware problems essentially gone, how good could CP/M be if it had better tools? Software from the entire CP/M era is now available for download, for free, much of it good. How nice could CP/M system software be if it got some modern attention?
Somewhere in here I came up with the following constraint:
Tool and work flow problems require close attention to nagging detail, in my experience the only way to address these issues is to iteratively use them and fix them.
Most of the big shops like Digital Research did their dev work on larger machines. Clearly this was the sensible path then.
But all of the shops I worked at in the 1970's and 1980's did all development work on "large" CP/M machines (heavy duty chassis, 64K+banked memory, hard disks, good software tools, etc). Who could afford a complete minicomputer setup? And we already knew we could do it on a micro; we had CP/M to point to. I know this was very common.
But today the few people I know of writing code for small systems like these tend to use their familiar modern machines and cross compilers. If using an ancient computer is fun, why not use it to write your code? A secondary effect of cross-compilation is that the resulting code tends towards bloat and lack the succinctness and frugality that make 1980 machines what they are.
Along the way the work itself spawned another constraint:
It is at this point the Friendly fZ80 became an experimental archaeological project. With our half century of collective experience of millions of programmers, we know so much more today. Event loops, state machines, message passing, algorithms like regular expressions and data compression, huge improvements in development methods have honed by practice and are now well-known; these ideas backported to the 8080 world are fairly revolutionary in effect.
What could have been?
During these months of CP/M work I kept stumbling across MP/M. I remembered it from the 1970s; one shop I worked in brought up an early version, no one was impressed, and it was abandoned. I suspect this experience was not rare. We were too busy with projects and customer work to look any further. It didn't get much attention in the magazines I read, as I recall; in hindsight, this may have been partially the relative complexity and high expense of the hardware required, and the persistent attention to detail required, especially for amateurs and hobbyists, who at the time were the core of attention and contributions.
The vintage computing community has done a remarkable job of preserving software; vast amounts of software from the 8-bit era and nearly all of Digital Research's products are available for download, often including Digital Research source files and documentation. A look at MP/M, source and document, revealed really nice work; the final MP/M 8080 version was complete in 1982, years after my initial dubious contact with a preliminary product.
CP/M can run one program at a time on a single screen; the common edit-compile-debug iteration workflow requires printouts and paper notes to maintain train-of-thought continuity; running a program erases the previous screen. Tediousness is the rule.
So a question arose in my head, how nice could CP/M system software be if it got some modern attention? Turns out not a lot better, due to this single-context issue. MP/M appeared to solve this.
Why wasn't MP/M better known?
By August 2025, with the benefit of all of MP/M's development present in one disk folder, I started work on bringing up MP/M II version 2.1, using what was apparently a then-unanticipated-by-Digital-Research mode of use of MP/M: the "power user", a single person with two or more terminals. fZ80 follows this model, a somewhat ahistorical backport of today's computer usage into this past, but replacing four large and expensive data terminals with a four-window, split VGA screen and single keyboard, immediately solves the primitive workflow problem.
Mostly...
[SUMMARIZE MP/M FEATURES]
realtime, daemons, scheduler, spooler.
CP/Net.
And now for a bit of a jump to MP/M's historical context.
By 1976 it was clear to all that the 8-bit CPU world would soon end. The next two years were to be a whirlwind of change, even if many hobbiests weren't fully paying attention, and would soon direct the fledgling industry away from amateurs.
Intel began development of the 16-bit 8086, delivering early chips in 1979.
Digital Research began work on MP/M in 1979, both 8- and 16-bit versions almost simultaneously, wisely writing code in PL/M, their device-independent programming language(5), testing and deploying the 8-bit version then applying results to the 8086 version. (The 8-bit version of MP/M was retconned "MP/M-80") such that the 16-bit version lagged by only a few months. By 1982 CP/M-81 had gone through three major releases, including real customer field experience, and now included file-sharing and a file server application (CP/Net), in MP/M II version 2.1, the final version, and the one chosen for fZ80.
However it appears that DR made a strategic mistake in delaying release of a plain old CP/M-86 until November 1981. 8086 machines would appear; Seattle Computer Products (SCP) new SCB-200B 8086 CPU card was demonstrated in June 1979, and offered for sale in November, and Digital Research had not even announced a CP/M-86 product.
The only software available in 1980 that ran on the new 8086 processor was Microsoft's standalone BASIC(6); With no 8086 operating system available from Digital Research Tim Paterson of SCP wrote QDOS by closely copying the 8-bit CP/M's structure, API system calls, BIOS/BDOS division, right down to the BIOS jump table. I do not disparage Tim or SCP in any way; CP/M had done a lot of things right, it was the dominant paradigm, and easing translation of 8-bit programs to the 8086 seems obvious at the time. I would have done the same thing.
What SCP did not copy from CP/M was the disk directory and block allocation schemes, instead borrowing the File Allocation Table (FAT) method that Microsoft had developed for standalone 8086 BASIC. This implies an early and close relationship between Tim Paterson and Microsoft; that Microsoft later purchased QDOS/86DOS from him is now well known, undermining would-be competitor DR as Microsoft negotiated with IBM to license an operating system to IBM.
Tim Paterson wrote in his blog that if a CP/M-86 had existed that he probably would not have written QDOS/86DOS. This seems reasonable; Seattle Computer Products was a maker of hardware, not software, likely just wanted to sell their new 8086 board and machines. Tim also wrote that SCP had been working with Microsoft in 1978, so this preexisting relationship may have undermined DR regardless. We'll never know.
DR pitched MP/M-86 to Don Estridge of IBM, in Boca Raton. IBM turned them down; IBM said that it did not want to offer such sophisticated system software to end users (7), believing the less-complex (probably meaning easier to support) 86DOS-turned-PCDOS to be adequate. Marketing overrode ability and user's needs.
Digital Research were technologists, with ideals I appreciate, not ruthless business folk that have since taken over the industry.
Digital Research remains a beloved underdog, delivering solid, usable, user-oriented code.
The fact remains that Digital Research's MP/M provided preemptive multitasking 14 years earlier than any Microsoft offering (Windows NT 3.1, July 1993). And on the 8080/Z80 (demonstrated on fZ80) and the 8086, in 1982.
The microcomputer industry rose from literally nothing in the middle 1970s, with no discernable code from prior existing computer practice, and culturally similar to amateur radio, regarding class and education and access. Almost all code was written by amateurs and moonlighting professionals; there was no microcomputer market beyond hobbiests in 1976. By 1980, most 8-bit CP/M software had been written from scratch in the two to four years prior, with nearly zero of it imported from minicomputer or other computing practices. Coding, development, ideas, uses and applications, largely occurred within amateur communities, and the businesses that arose were populated with enthusiasts.
By 1982 Digital Research had sold 250,000 licenses to CP/M(8); an estimated 3000 computer brands and makes
ran the CP/M operating system.
Note #1 Annals of the History of Computing, Volume 11, Number 3, 1989, https://ia801400.us.archive.org/14/items/first-unix-port/Image092317133353%20copy_text.pdf.)
Note #2 Users @jmarsh and @wwatson (Warren Watson, author) on PJRC Forum forum.pjrc.com wrote the VGA4BIT DMA drive VGA driver code.
Note #3 Z80 emulators used: ultimately the Z80 code from David Lee's NTVCM (20 &percent; faster than the others, though missing IO instructions and interrupts. Lin Ke-Fong, https://github.com/anotherlin/z80emu, very nice code, and the well-known RedCode emulator, https://github.com/redcode/Z80, worked fine but had too many very short global symbol names to be easily incorporated.
Note #4 David Lee's NTVCM: https://github.com/davidly/ntvcm
Note #5 In a looser and older sense than anything today; but in any case PL/M described the similar x80 and x86 machines closely enough.
Note #6 Microsoft's MBASIC ran directly on the machine, no OS, and had it's own filesystem based on the RAM-resident File Allocated Table (FAT).
Note #7 Personal conversation with Tom Rolander.