I find this project very intriguing (besides the fact that, despite being, or at least having been, a big Sir Clive fan, I had never heard of "project Loki").
However, it's disappointing that the author didn't publish its source code.
Really?! Wow. It was very famous in the Sinclair community of the time. The last new computers from Sinclair Research were the QL (a 680xx home computer launched two weeks before the Mac) and the Spectrum 128, which used a design partly from Investronica in Spain, which tragically didn't incorporate the improvements from Timex in the USA -- it didn't have the extra graphics modes, which the Spectrum desperately needed, and it didn't have joystick ports or a cartridge slot. (Those appeared in the ZX Interface 2, of course.)
The two planned machines that Sinclair was talking about were the Pandora and Loki.
Pandora was to be a Z80-based laptop -- and bear in mind, at this time, laptops did not really exist yet. Sir Clive's second computer company did launch a derivative of this idea: the Cambridge Computers Z88. I have one. It's a lovely machine, hindered by nonstandard storage slots (because the standards didn't exist yet), and an awkward way of getting documents off the machine: RS-232 serial.
(The better way, IMHO, is what Alphasmart did later: make the portable appear as a keyboard, so it can just type your documents into any computer with the right keyboard port, whatever OS or apps you are running.)
The Z88 does show that Sinclair learned from his mistakes: it has its own proprietary OS, OZ, which is still in development -- a new version, 5.0, is in beta.
https://cambridgez88.jira.com/wiki/spaces/OZ/overview
But on top of OZ it runs the standard Z80 edition of BBC BASIC.
As an aside, I gather than CP/M+ (aka CP/M 3.0) runs quite well on the Spectrum Next and is due to be available on the Spectrum Next Issue 2 (whenever they get hold of the FPGAs the project is hung up on). And the Next looks a whole lot like Loki, except with a gonzo modern FPGA pretending to be a really fast Z80, SD card support, and a Raspberry Pi Zero as a GPU(!). It even costs about the same as an original Spectrum 16K did in 1982, adjusted for 40 years of inflation.
the QL (a 680xx home computer launched two weeks before the Mac)
This implies that the QL was a competitor to the Mac. My sincere apologies if that wasn't your intention, but anyone who has used a QL and a Mac would have a hearty chuckle at the thought.
Sinclair guessed and gambled on the next big thing in small business micros being multitasking. It wasn't. That came more than a decade later. The next big thing, we know now, was the GUI.
Also, the QL was far too savagely cost-cut, as was Sinclair's wont.
But what is rarely considered is that the QL inspired more derivative designs than almost any other micro except the IBM PC... if you exclude the dozens of illegal Sinclair Spectrum clones in the Soviet Bloc.
The Thor, Thor II, Thor III. The Aurora. The QXL card. The Q40 and Q60, and later, and still around now, the Q68.
The OS was rewritten as SMSQ/E and was sold in a form that ran on Atari ST hardware, too.
And the many that didn't run QDOS: the Merlin Tonto, ICL OnePerDesk, Telecom Australia Computerphone.
About a dozen different computers from half a dozen companies, all QL compatible to some degree, developed and sold over some 35 years, is pretty impressive, IMHO, for a machine widely seen as a flop and a failure.
I had a Z88 back in the early 90s. A great little machine. I still think Pipedream is one of the ideal pieces of productivity software. The Alphasmart was a gem as well.
It's like a windowed, multi-tasking environment where each process actually gets its own dedicated CPU/memory/display hardware and can run fully independent of the others.
I think it was Cromenco that had a setup where you had a 'master' S-100 CP/M CPU board that managed mass storage, printers and other things, and 'subordinate' S-100 cards that had CPU, memory and SIO. Each user would be dedicated a sub card and terminal, running their own full version of CP/M, and the master mediated access to shared resources. Very popular in small office settings for a while.
I'd say more like a VM system where there's a (mostly) 1-to-1 mapping between hardware and user, supported by a really simpleminded hypervisor. But I definitely see where you're thinking.
> I built a 16-core Z80 laptop running CP/NOS (the networked version of CP/M 2.2)
I remember that laptop! I wonder if it can be emulated in MAME easily.
That, and beefier nodes running something like MP/M (or different architectures, such as CP/M 68K, alongside the more usual CP/M 80) would also be fun.
Is CP/NET reliable on your cluster? Way back in the day, when I worked at an outfit named ACE on the then-dominant solution for multiprocessor CP/M dpc/os, we evaluated CP/NET and found it unsuitable as a daily driver due to a lot of crashing.
Neat - I had never heard of ACE. In my (fairly limited) experience it works fine, although running the cores at 140 MHz (and the network) forgives a lot of sins. I actually wrote my CP/NET server as a regular CP/M application in Turbo Pascal, so I can't speak to other server solutions. The idea behind my ZedRipper was to basically turn a 'multi-user' CP/M system into a single-user/multi-tasking system, and it worked better than expected.
CP/M is a bit before my time, but why was it so wildly popular compared to its contemporaries? Was there any technical reason or was it just available and easy to license for the different microcomputers that came to market at the time?
It’s interesting that some of CP/M’s underlying ideas are part of Windows 11 today, such as drive letters.
CP/M is popular because its requirements are dirt simple, and it has a lot of software that still runs. It's popular because, unlike IBM PCs, the hardware was diverse, and the software has to cope with that. Now, while MS-DOS is very CP/M-esque in its design, the truth is that most MS-DOS software is actually PC software. It assumes the PC hardware. Most major MS-DOS applications skipped the MS-DOS driver part and just went straight into the hardware. Today that means if you want an "MS-DOS" machine, you really need a PC with all of its hardware, its graphics, its ports in the right place, etc.
In contrast to CP/M. It requires a block device of some kind (i.e. a disk drive), and a console of some kind (typically, but not necessarily, a serial terminal).
While some applications did route around the BIOS and BDOS in CP/M, most did not. CP/M was quite portable across a crazy range of hardware. Porting a CP/M BIOS is a nice engineering and assembly language challenge for anyone willing to take it on, depending on their hardware environment.
Today, anyone with a Z80 chip, a RAM chip, and some paperclips to wire it all together can get a device that will run Wordstar. That flexibility makes CP/M very popular with retro enthusiasts today. It's easy to find dongle sized computers for $50 running CP/M on eBay. It's also easy to find full through hole kits of parts and PC boards to make your own. Or, grab a Z80 CPU and Peripheral manual, a copy of KiCad, some parts and breadboards and go to town. Having your creating run Wordstar beats blinking LEDs any day of the week.
It's crazy easy to get CP/M running on just about anything with Z80 CPU emulation, and some glue logic to handle reading bytes from a keyboard I/O port, and sending them to a terminal, and reading/writing sectors from a block device. I had to write a VT100 emulator for UE4 but that doesn't take too much work.
Extremely cool. It'd be fun to play with machines from this era in VR and have them exist with huge glass terminals like this. It makes them feel so immense compared to what they actually were (small tabletop computers).
I'd love to go back and work on it more, I wanted to have both Z80/6502 based systems, just like the 8-bit wars of the 80's, but with networking. I couldn't decide between "1980's in space" or a post apocalyptic world where only 8-bit computers were robust enough to function. Maybe one day.
I still play around with Turbo Pascal on CP/M a lot for fun - it is a shockingly good development environment (even on a 4 MHz CPU my edit/compile/debug loop is usually <10 seconds, which is pretty fast even by modern standards). And it could all trivially fit in the L1 cache of a modern CPU.
I haven't tested Turbo Pascal on it, since i'm not a Pascal programmer, but the HiTech-C compiler runs and creates working executables, its not a stretch that Turbo Pascal would either.
Why would there be an assumption I have implemented all the emulation completely and correctly enough for it to run?
If it doesn't, there's a bug in my emulator, end of story. I have had to implement all kinds of things to make various software work correctly, and there's probably still more to do.
In contrast to CP/M. It requires a block device of some kind (i.e. a disk drive), and a console of some kind (typically, but not necessarily, a serial terminal).
In other words, it was like the UNIX of the microcomputer world.
It had terminal capabilities (not to the level of termcap in Unix, but good) which meant that shrinkwrapped software like Wordstar would run on anything with an 8080, Z80, or NEC V20/V30 and CP/M. The Osborne 1's tiny screen was only 50 characters wide instead of 80, but software still ran on it.
It hit the sweet spot of abstraction for its time, and made it easy to write drivers for custom hardware that a new manufacturer might decide to make.
I dunno what CP/M you were using, but all the rest of us had application specific patches for Wordstar for whatever we were running, and pretty much everything else. The Wordstar branded for Osborne did not work right on a Cromenco+VT100 and definitely went weird on a TRS-80 4P without directly patching it. Don't even get me started on the cornucopia of floppy disk formats one had to deal with.
Not sure what the VT100 link was supposed to prove other than yeah terminals back then were hard to support generically. And you had to hack around the issues. Which was my point.
The "Osborne-specific version" was the retail version...for the Osborne. Yeah, there was a 'generic' retail Wordstar...that you had to patch for your specific hardware if your combo wasn't supported out of the box. I had friends who's whole business back then was hacking popular CP/M apps to support less popular hardware.
There wasn't some compatibility nirvana. It was just easy to hack up a fix because apps were on the order of 10's or 100's of kilobytes, not hundreds of megabytes.
One reason is that unlike MS-DOS, the OS is hardware independent, except that an 8080-compatible CPU was needed (8080, z80, some NEC chips etc). Other than that you could use just about anything. It wasn't hard to port (more like transport than port) CP/M to a new system which met the minimum requirements (cpu, some minimum amount of RAM, floppy disks at least, and a TTY or terminal). Very different from MS-DOS, which required a mostly exact PC clone, and it had no provision for moving to another architecture. CP/M came with, among other tools, "MOVECPM", a program to relocate the operating system to a different place in the memory map (and write the result to a new boot floppy or whatever), an Alteration Guide document, and there were various books detailing the process.
CP/M didn't require a floppy. You could boot it off ROMs, tape or even paper tape (ASR-33s were fun). There's even a RDR: device that was supposed to be used to load from a card reader, tho I confess I never saw that in the wild.
MS-DOS was structured the same as CP/M: there was a small-ish machine dependent part you ported (called an 'OEM Adaption Kit' at one time), and a hardware independent kernel. At least through 3.0 and probably later, it did not require a PC clone. It ran on all sorts of non-PC 8088/8086 machines. Ever run MS-DOS on an 80186 with 8" floppies? I have. Now, your apps might not run because of machine level assumptions (video, usually), but MS-DOS did.
I still have a British-made 8086 almost-PC in the attic. It ran MS-DOS - but harddisks didn't work because the interrupt vector was different. That could be fixed - I burned a new EPROM and got it working. The company which imported the machine told me how - I called them and the guy who took the call explained in detail about interrupts and addresses and whatnot, and the next day I removed the PROM, brought it to work, copied it, patched it up, and burned a new EPROM. I'm still shaking my head at that memory. Try calling a company today and ask a technical question.
But the real problem with almost-clones was (as you said) that in practice applications more often than not bypassed the "ABI" and went directly to the hardware, and admittedly that's not MS-DOS fault per se. The result was anyway that lots of software wouldn't run on almost-clones, especially if they moved around too many of the assumed interrupts (e.g. 80186-based PCs - they had some of the peripherals of the 8088/8086 integrated, just not exactly in an IBM PC layout). One system I ran across was an "enhanced" PC-like semi-clone, probably using an 8086 or something better - the local health services had just started a huge campaign where they tried to get everyone to volunteer for a health checkup, and they were followed up with a new one some years later, and on and on (it still goes on, to this day). Anyway, for that early start, they used this MS-DOS computer to collect and print information. But the printer didn't work - the PC was nonstandard. I went to the hospital and figured out why, and patched things and got it working (I don't recall anything today about what or how or even why I could).
CP/M applications though - they didn't, for the most part, bypass anything - maybe that's because people writing the software knew that the hardware could vary wildly. Screen-oriented apps like WordStar usually needed a machine-specific patch for that, but otherwise CP/M software was way more portable than MS-DOS software. PC software though - vendors just thought "IBM PC hardware" and that was it, for the most part.
That's easy: because the calls to the screen went through the terminal handling code; on MSDOS, for speed, many applications bypassed the MSDOS I/O and called the video hardware directly; this made things much less portable.
There were many MSDOS but not 100% IBM PC compatible machines made that got hit in the market because of this, such as the Zenith Z-100/Z-120 , TI PC, etc. If the memory map and everything else didn't exactly match the IBM BIOS setup the application would fail.
Most of the early CP/M systems I encountered were running on Zilog Z80 CPUs. There were other OSes as well but CP/M was very popular. I used dBase II on a Xerox 820 which was pretty nice with soft white monochrome text.
CP/M was also very portable and eventually ended up on Atari ST 68000 machines which I also used with the GEM desktop/graphics environment. There was even a CP/M card for the Apple II that had a Z80 on it.
GEMDOS on the ST isn't really CP/M. It was a DR product, yes, and the API was somewhat based on CP/M, but it was also a new thing not ABI compatible with CP/M and also pulled in a lot from MS-DOS. It was built specifically to run GEM on systems where MS-DOS was not present (because GEM was written for MS-DOS originally). So the 68k, and was prototyped on the Apple Lisa and some Motorola VME machines before porting to the Atari ST.
The source code for both CP/M 68k and GEMDOS are available these days and one can see that while some small bits are borrowed between them (the program loader, for example), on the whole it's a whole new source tree.
I believe parts of the GEMDOS sources did become the basis of what eventually became DR-DOS on the x86.
Oh yes, you're right! I'd forgotten some of how things got finalized. I started using the Atari 520ST with pre-release CP/M-68K docs and software before settling on GEMDOS/TOS. It was all in a bad state with a literal stack of paper given to me (rather than electronic docs) that only roughly corresponded to the state of the software so must have been in flux. Even the GEM parts were still being worked out. I recall using just the "Line-A"[0] graphics calls which were I believe 000a traps that were ROM calls to routines before getting access to higher level GEM graphics support.
There's mention of CP/M-68K and TOS with info on the Atari 130ST/260ST[1] (which also happened to have 512KB). I do recall later getting the OS in ROM of later hardware so boots were quicker.
GEM Desktop, now that's some nostalgia. First GUI I ever used, on an Amstrad PC-1512. Can barely remember it now other than a feeling of "wow", swiftly followed by "but none of my DOS games run on it, meh" :)
It didn't have any. That's why it thrived. It was the first cross-platform OS for microcomputers. There were other microcomputers, but they didn't have OSes as such: they mostly had a BASIC interpreter in ROM and that was all.
And most machines had their own unique implementations of BASIC, all subtly different. In the American market (and only there), Microsoft BASIC was a lowest-common-denominator industry standard, because it was very small and MS made it cheap. It was rubbish, though: no graphics, no sound, no structure, not even IF...THEN...ELSE.
In the rest of the world, vendors competed for who could offer the best BASIC... and in the end, Acorn won, with BBC BASIC, which was the best by far of any early 1980s micro. Acorn went on to invent the ARM processor.
However, all the different BASICs made all the machines software incompatible.
CP/M was a DOS: a disk operating system. You needed a disk drive, and ideally 2. That was expensive, so CP/M ran on expensive micros in the small-business market: often they cost thousands of £/$ while home computers sold for hundreds of £/$.
In that space, CP/M had no competition until MS-DOS came along, for the newer and more powerful 16-bit Intel 8088 and 8086 chips.
If the UK is "the rest of the world" sure. Microsoft BASICs served as the foundation for a lot of home computer BASICs, Commodore's, Apple's, MSX, PC-8800's. C64's were very popular in parts of Europe too like Germany, not just the US.
France had some interesting home micros, and of course Minitel.
Japan had some amazing machines, and MSX did some stuff that no other 8-bits ever did.
Behind the iron curtain there was a ton of R&D, including legions of clones, but also PDP-11 home computers, machines that used trinary instead of binary and all sorts of exotica.
In the Southern hemisphere, Australia and several big Latin American countries had their own industries, due to the costs of imports.
MSX wasn't? No, indeed not, and AFAICR MSX BASIC wasn't anything very special. (MSX-DOS actually was, and is CP/M compatible and can run CP/M programs, which is rarely even mentioned.)
But MSX was aimed squarely at gaming with a sideline in music making and things. I feel it deserves more respect, as one of the longest-surviving 8-bit architectures, one that was the most extended of all of them, and even transitioned with some degree of success to 16-bit, with the Z800-compatible R800 chip:
https://www.msx.org/wiki/ASCII_DAR800-X0G
It's just what ran on the various 8080/Z80 machines that flooded the market in the late 70s. There weren't really any alternatives.
As for the prevalence of its concepts, Gary Kildall borrowed a lot from minicomputer OSes that he was exposed to early in his career. CP/M brought a lot of the capabilities and styles of those $$$ systems to machines that people could use at home. So I think if you want to see where this style of CLI came from and why those things were popular you might look at DEC TOPS-10... or other "real" minicomputer operating systems that hobbyists coveted but could not afford for themselves.
Before standardization around the IBM PC, CP/M was the only way to get that, really. And there were boatloads of these 8080/Z80 systems out there, all sharing some common attributes but not being 100% compatible with each other, so CP/M is what glued them all together until the great wave of the IBM PC overtook them all.
Portability before Windows or any other system became mainstream. For example, Hitchhiker's Guide to the Galaxy (the original text adventure) was available on it (and so did early text processors though I personally can't speak with hands-on experience here). Technically, CP/M isn't even an O/S in the "modern" sense taking Unix as a point of reference - Z80 and 8086 didn't even have an MMU so no kernel/userspace memory protection or process isolation. CP/M, like DOS, is rather an extended BIOS with a file system (as it says on the tin: control program for microcomputers) acting as portability lib once a program is loaded, plus a couple of interrupt handlers for screen refresh etc. I guess.
It was an operating system in the sense it abstracted much of the hardware into portable syscalls and came with a set of practical utility programs. Really the only assumption hardware had to conform was a certain memory map layout. Process isolation does not make much sense on a 2mhz 8 bit CPU with 64Kb address space anyway. MS DOS didn't do that either, and there are still modern embedded OSes that don't do process isolation.
8 bit CPUs are seriously limited and the OS on them needed to be user friendly and lean. CP/M mostly covered that. The other thing is, many early computer users also had used mainframes, with DEC being exceedingly popular in colleges and universities. Among the operating systems for DEC’s machines was TOPS-10, from which CP/M drew a ton of inspiration. CP/M being similar to TOPS in many ways made it easy for people to pick up. There’s also timing. CP/M had serious first mover advantage.
For one thing, there weren't many contemporaries. Its biggest advantage was its ubiquity. It came out years before MS-DOS. Some microcomputer manufacturers had their own DOSs, but CP/M needed relatively little customization to run on any machine that had an 8080 or Z80-compatible processor, and in most cases it ran better and faster than the hardware manufacturer's DOS.
Microsoft's first hardware product, the Z80 Softcard for the Apple II, was a bestselling product because it gave the Apple an 80 column display and CP/M 2.2 all in one package.
Mostly because there were no contemporaries. HDOS (Heathkit DOS) was an alternative for a while (only on Heath/Zenith) but almost all third party packages were for CP/M. It is hard to explain the hardware diversity, even in the 8080/Z80 universe, but relative lack of software diversity (there was no IBM PC standard). But if you wanted to run WordStar, CP/M was the only option.
It was definitely popular in Europe, you just had to look at the right places. Both CP/M and the multi-user variant MP/M were used in e.g. accountant offices, and the reason is exactly as an earlier comment said - CP/M and MP/M could run on tons of different hardware, so you could start with choosing which hardware worked best for your use case / office, and then just run CP/M or MP/M with the software you needed. Accounting, for example. I remember visiting an office with 8 terminals connected to an MP/M box - I can't recall at all what that hardware was, except that it was probably built in northern Europe somewhere. I went there because they had accidentally deleted all the files on their harddisk, and needed a rescue.. which wasn't difficult to fix.
I was. When, as a kid, I went to computer trade shows in the early 80s, 1/2 of the "business" computers were running CP/M (then switched, almost overnight, to MS-DOS around 1983, IIRC).
the collection of hardware parts in those days was really different. I imagine that simply disposing of the dependencies on a hundred "standard" parts of a modern PC motherboard in the source code, is a win. So it is not better to go back to CP/M for some architectural reason, it is a win to get-rid-of the intrusive and bulky, and patented, parts in modern OS.
This sucks. Everybody knows that CP/M was written in PL/M, which was its one and only good feature. It was reasonably easy to extend to various projects.
Creepiest thing was that Nokia's massive multiprocessor telephone exchange from 1980 was written in PL/M. And CP/M also visible at operators console with floppy disk and other shit.
However, it's disappointing that the author didn't publish its source code.