Having just completed a CP/M 3.0 BIOS for my homebrew Z80 machine, I am in awe at the amount of planning and foresight that went into it. The fact that you can write a piece of custom code in 2024 (for hardware that didn't even exist back then) and link it with the Digital Research binaries from the 70's to have a fully-functional and compatible O/S that is able to run almost any software written for CP/M in the past 40 years is just crazy.
Unlike CP/M 2.x, CP/M 3 allows for banked memory and disk data/directory buffers, resulting in a lot more usable memory for applications (Transient Program Area) and faster disk access. Although with an SD/CF card, the CPU is more the bottleneck than the disk I/O.
The project was both nostalgic and informative - trying to maintain performance while counting every byte of code has shed some great insights into low-level O/S design.
> Unlike CP/M 2.x, CP/M 3 allows for banked memory and disk data/directory buffers, resulting in a lot more usable memory for applications (Transient Program Area) and faster disk access.
Sounds a lot like what MSX-DOS 2.xx does as compared to its predecessor.
FYI: both versions of MSX-DOS are partially CP/M compatible, such that a # of applications running on it are slightly- or unmodified CP/M programs. Not unimportant given how much quality CP/M software already existed in early '80s.
One oddity resulting from this: some OS calls read or write files in multiples of 128 byte 'records' (regular MSX-DOS calls do handle exact file sizes though). Just guessing: sector size of ancient 8" floppies, or something like that?
Interesting - CP/M has a fixed sector size of 128 bytes. In CP/M 2.x, if your physical sectors were a different size, you'd have to implement deblocking code in your BIOS. CP/M 3.x still used 128 byte sectors, but supported specifying the physical sector size and would do the de-blocking for you.
I'm guessing MSX-DOS uses the 128 byte records/blocks to make it easy to read foreign disks and to be able to create disks readable on other platforms?
> Computer clubs and individuals from all parts of the United States and the world soon created Tiny BASIC interpreters for the Intel 8080, the Motorola 6800 and MOS Technology 6502 processors. The assembly language source code was published or the software was sold for five or ten dollars.
Well played, Mr. Gates.
Of course Microsoft eventually supplied a clone of CP/M-86 to IBM, and the rest is history.
Also interesting in this context is the podcast series "The Advent of Computing" [1] by Sean Haas.
Episode 36 is specifically about CP/M, and there are several episodes that paint the history of the x86 architecture that we're still working on today. A real treat!
There are several biographies on him on Youtube as well.
Included among these is a special episode that Computer Chronicles made about him after his death.
CP/M is the Yahoo of OS's: had a mile-wide opening of opportunity to step into, but blew their chance through greed, short-term thinking, and suits-gone-wrong. CP/M and co. could have been Microsoft, and Yahoo could have been Google.
Bill Gates/Microsoft was also DRI's nemesis, from supplying a CP/M-86 clone to IBM to trying to torpedo DR DOS (which nonetheless lasted into the 2000s.)
If we consider DOS to be a version of CP/M(-86), then it is still in use to this day (and it's probably running on your phone or PC you have any old games that use DOSbox) - a remarkably successful run for any OS.
> Due to a slight problem of undercapitali7ation[sic], I found this incredibly low price still a bit high.
Alas, a situation I am only too familiar with, even though computers and peripherals are so much cheaper these days. Also I love the way he phrased that.
Unlike CP/M 2.x, CP/M 3 allows for banked memory and disk data/directory buffers, resulting in a lot more usable memory for applications (Transient Program Area) and faster disk access. Although with an SD/CF card, the CPU is more the bottleneck than the disk I/O.
The project was both nostalgic and informative - trying to maintain performance while counting every byte of code has shed some great insights into low-level O/S design.