SoylentNews is people
SoylentNews
from the where-are-the-redacted-chapters-of-Gary's-posthumous-memoir-at dept.
The Eerie Linux blog (also in Gemini) has a longer post about how to actually get started using CP/M, the Control Program for Microcomputers.
This article is just what the headline promises: an introduction to the CP/M operating system. No previous knowledge of 1970s and early ’80s operating systems is required. However, some familiarity with Linux or a BSD-style operating system is assumed, as the setup process suggested here involves using a package manager and command-line tools. But why explore CP/M in the 2020s? There are (at least) two good reasons: 1) historical education 2) gaining a better understanding of how computers actually work.
Last year I wrote two articles about CP/M after having taken a first look at it:
A journey into the 8-Bit microcomputing past: Exploring the CP/M operating system – part 1
A journey into the 8-Bit microcomputing past: Exploring the CP/M operating system – part 2These were written with a focus on the first reason; I had (partially) read the manuals and tried out a few commands in an emulator (as well as done a little bit of research). I wrote an outsider’s look at CP/M and covered the various versions that were released and some of their notable features.
This article is different. It’s for readers who want to get started with CP/M themselves. Expect a practical introduction to get familiar enough with the platform to be able to explore a wealth of historic software, often enough ground-breaking and influential.
CP/M was of great importance back during the 8-bit microcomputer era. It was ubiquitous in small businesses and government offices for a while. It ran on the Zilog Z80 and Intel 8080 hardware architectures. MicroPro International's WordStar and Ashton Tate's dBase II were among the killer apps of the era. Networking was by sneakernet or, maybe, if your cable smithing skills were up to it, by null modem.
Previously:
(2024) Complete WordStar 7.0 Archive
(2024) End of an Era: End-Of-Life for the Venerable Zilog Z80
(2024) Intel 8080 Emulator. 19th IOCCC. Best of Show.
(2022) Z80—The 1970s Microprocessor Still Alive
(2016) Portion of Gary Kildall's Memoir Made Public
(Score: 1, Funny) by Anonymous Coward on Saturday August 30, @04:45AM (2 children)
... and why does he have memories after his death?
(Score: 3, Insightful) by Anonymous Coward on Saturday August 30, @05:57AM
The story of his unpublished memoir was old news before your teacher was born.
(Score: 0) by Anonymous Coward on Tuesday September 02, @02:37PM
See:
(Score: 5, Funny) by stormreaver on Saturday August 30, @11:29AM (7 children)
I remember building my null modem cables for my CoCo 3's serial port. I forgot how much it boosted my speed, but it was substantial. Then I graduated to building a null modem cable for the printer port. The speed boost was supposed to be gigantic (115Kb/s). I was so excited by this prospect that I rushed home from the local Radio Shack after buying the parts. I rushed so much that I got pulled over for speeding. The cop wasn't nearly as excited about my project as I was, and I got my first speeding ticket (the bastard!).
To make matters worse, I don't think I ever got that cable working. Fines and points on my license for nothing!
(Score: 2, Funny) by Anonymous Coward on Saturday August 30, @12:42PM (1 child)
Ahh no CoCo glasshopper, you rearn many valuable ressons that day.
no ethnic disparagement intended, rather just poking fun at various actors who (fairly badly) played "Oritental" parts, such as "Kwai-Chang Caine" on TV show "Kung Fu".
(Score: 0) by Anonymous Coward on Saturday August 30, @02:43PM
Is that you Master Po? I see, no offense, your speech to text works great!
(Score: 3, Informative) by VLM on Saturday August 30, @03:14PM (3 children)
For the folks who aren't in on the joke, the coco series shipped with a bit-bang serial port (win-rs232 LOL) where the CPU had to toggle the rs-232 port lines. Good enough for slow serial printers that took a couple of seconds to print a line anyway, slow for everything else. Good luck pushing more than 1200 baud or so with that thing LOL, especially if you were using multitasking OS-9 as your operating system or trying to do anything else other than run xmodem, I guess.
RS (and many others) sold a hardware RS-232 plug in expansion pack that had hardware RS-232 and IIRC working flow control. That thing could fly.
The pinout of course was different LOL. So you'd get a hardware RS-232 pack, solder new cable ends on, and reconfigure OS-9 to print to the serial printer on the expansion pack not the built-in pit bang port.
I suppose you'd explain a bit-banged RS-232 port as being something like doing I2C by writing your own software to toggle GPIO ports complete with timing loops whereas having a hardware UART chip would be similar to having a microcontroller with a built in hardware I2C bus where you just "Send it".
(Score: 2) by sgleysti on Saturday August 30, @04:08PM (2 children)
It's the exact same thing, just for UART instead of I2C. I've bit banged I2C before; it's pretty easy due to the separate clock and data lines. Bit banging UART would be complicated. You'd need really good timing. I'd be worried about interrupts ruining it.
(Score: 2) by VLM on Saturday August 30, @04:43PM
Oh I assure you having been there, the bit banged RS-232 on the coco barely worked as a single tasking slow speed serial printer output.
The CPU ran around 1 MIP but the interrupt latency could be brutal, yup. Could easily mess up and only ran at relatively low speeds.
When disk access or just being slow stopped feeding data to the hardware UART in the RS-232 expansion pack, thats OK, there's just a gap between characters, but on the coco you "really couldn't" print in the background to the bit bang port while continuing to edit in a word processor or otherwise mess around on the machine because odds are the interrupt would be during a bit-time gap not between bytes.
The coco really was an example of a system where the software was WAY ahead of what the hardware could support. From the mid-80s until early 90s linux era going from OS-9 on a coco to late-80s IBM PCs was a pretty severe downgrade at least on the software side even if the hardware was 10 to 100 times "better" in theory.
(Score: 2) by ncc74656 on Tuesday September 02, @08:01PM
I've bit-banged 1-Wire [analog.com] on the Apple II [alfter.us]. Depending on the application, bit-banging a serial port should be about the same level of complexity.
(Score: 1, Interesting) by Anonymous Coward on Saturday August 30, @03:16PM
We had a CP/M S-100 bus machine in the early 1980s and a 1200 baud modem. While the Z-80 wasn't very good for number crunching, we had an account on a VAX that was. Simulation/optimization code written locally was uploaded to the VAX (about 400 miles away) to compile & run, then the results files came back by modem. Results plots were slow to come out of the dot matrix printer!
Our choice of text editor? Mince, by Mark of the Unicorn (Mince Is Not Complete Emacs).
(Score: 5, Interesting) by SemperOSS on Saturday August 30, @01:04PM
One of my earliest consulting jobs was writing a CP/M BIOS for a small company making Z80-based computers. It went well and soon we created a new version with an intelligent video card based on the same Eurobus motherboard as the computer itself. I had built in a status line at the bottom of the video output with a clock showing the time of day. You had to set the clock every time you turned on the computer as there was no hardware time-keeping circuitry. The clock used the sync timing of the video as time reference. Definitely not precise as the clock drifted a lot with even small temperature changes, but better than the competition that had no status line and definitely no clock.
Open Source Solutions and Digital Sovereignty is the new black
(Score: 3, Insightful) by VLM on Saturday August 30, @02:48PM
For the "historical education" I'd make an analogy with archeology that you can learn a lot from old tech if you'll bother to put in the time. Old lessons learned can sometimes be figured out a lot faster than re-learning from the start in the present day.
Education in general, not historical education. Its small enough an individual can realistically understand how all the parts work together and this is of educational value. Its easier or more realistic to teach someone everything about a small system rather than a huge system like "all of linux" or "all of windows" or "all of osx".
Its a fun puzzle. If you want a picture of dogs playing poker, its a hell of a lot easier to find one and download it from the internet or order a beautiful high res poster online, than to put together a 1000 piece puzzle. Making an old system do something interesting is likewise a puzzle with a lot of small, satisfying parts.
There are different ways to "retrocompute". This article is about being a tourist with an experienced tour guide. This leads to
Another way to retrocompute is to "do something" with it. Go solve fizzbuzz in Turbo Pascal for CP/M or go solve some Project Euler challenges using MS FORTRAN-80 (which was a thing, and the 80 IIRC was the copyright date, it was NOT a F77 god help you IIRC it was a FORTRAN-IV like using a PDP-8 in the mid 60s two decades earlier) IIRC F-80 was only restored and make operational again around 2020 so this is semi-cutting-edge in 2025. For a few decades if I felt like running F-IV I "had to" use a PDP-8 emulator. Write software using overlays (a lost art since at least Y2K... I'd explain it to noobs by saying something like what if you had a system without VM but VERY manually implemented virtual memory in your own program, kind of...)
There are also people who get into end-user software instead of small time sysadmin stuff. Some "applications" were pretty interesting. Editor/word processors, spell checkers operating in ridiculously limited memory, very early database stuff was cool. Early BBSes and related terminal programs (I didn't get into this until 1984 or so, which is a bit after the CP/M in the article).
Another fertile field of experiment is retrocomputing people like small time first time user sysadmin stuff. Now try something exotic like setting up an in-memory print buffer or using multi-user CP/M 3 or that mystifying network/LAN/server system for CP/M that I never really got into but knew about. Go a little further than typing "DIR", interesting as that might be for total noobs, were not all total noobs forever and there's a lack of "advanced" content.
(Score: 5, Insightful) by VLM on Saturday August 30, @03:03PM
Based on some distant memories and recent gossip, I was motivated enough to find CP/NET from 1980 with is an official DRI product and it was kernel native networking with drivers that could use anything not just null modems. Now a days people like using microcontroller hardware as a protocol converter (toss a packet at a ESP32 or wiznet module and it chucks it on the ethernet for you)
http://sebhc.durgadas.com/CPNET-docs/cpnet.html [durgadas.com]
If you remember how TCP/IP worked, or maybe more like how Novell worked, on earlier MSDOS this will all seem EXTREMELY familiar because a decade or two later the dos people were basically copying DRI's architecture and ideas from 1980. I messed around with novell (without a "real" license LOL) back when it was a new thing or at least a commercial thing (there were people running Novell networks up until 1990, surely, and probably past that) and CP/NET on CP/M feels very familiar to running Novell on dos other than add about three zeros to disk capacity etc.
DRI or Digital Research Inc should sound familiar, thats the CP/M dudes. Yup, toward the end of CP/M dominance in the early 80s they sold what amounted to CP/M 2.2 plus plus plus that had kernel-level networking.
And this stuff works in 2025 if you google for it. Mostly people are simulating but there are hardware implementations as I understand.
In my infinite spare time I should set up a CP/NET server in a docker container to serve files to my machines, that would be hilarious.
(Score: 3, Interesting) by Rich on Monday September 01, @10:29PM
A bit late to the party for this article now, as well as when I got a cheapo Z-80 softcard clone for my Apple II to run dBase II after I saw that on a Kaypro in late '84. Aside from dBase and WordStar, there was TurboPascal, which was the only practical high-level language option for the base kit (In my view, UCSD failed with its ultra crude file-system and had to use slow p-code vs. the native Z80 executable because the 6502 absolutely objects to compilers generating code for it). I wrote a little BBS that I ran on my telephone line in Turbo Pascal in '85. But beyond being a launcher for these killer apps, CP/M was crap. It couldn't even shrink files (and iirc only CP/M 3, which no one had, allowed to manually set a "file length" attibute). OS/9 (or even just the ProDOS/SOS file system) was light years ahead.
But following the links and looking at how crude the crap back then was and what prices they demanded (like CP/M 86 for the 5150... $240 or something), I wonder if I could just have done something utterly boring and hit it big. Like doing a WordStar clone for the 6502, or doing some nice little language that'd appeal to both hackers and educators. It looks easy from today's perspective, but apparently was near impossible with my knowledge back then. And for everyone else, too, or we would have seen examples. For example floating point was black magic (I assert that Gates had never made it anywhere if Monte Davidoff hadn't written the FP logic for him). On the other hand, on some family visit, I got bored and in one evening hacked together a trivial text editor on a Dragon 32 that I encountered. The guy who owned the machine apparently added a few touches and turned it into a small scale product.