CP/Mish: open-source sort-of-CP/M distribution | Hacker News Reader

M distribution

cowlark.com

86 pointsingve32 comments

Hello, author here.

The big missing bit so far is a text editor --- I haven't found an open source one which will work with my tools yet. (I have found te, which is GPLd, but I need to do some C compiler work first. CP/M is hell on stdio.)

I'm also completely willing to add more tools which are cool/interesting/etc if anyone can suggest any --- the only requirements are source and DSFG licensing; although what I'd really love some more BIOSes if anyone has them, so as to support more platforms.

I've done a fair amount of playing around with CP/M, and really enjoy it for providing all of the close-to-the-metal fun of microcontroller programming while being self-hosting with real development tools. Are you familiar with CP/NET at all? It was basically a 'server' that ran on an MPM/II machine (usually) and a number of CP/M or CP/NOS (diskless!) clients that could talk to it and share disk drives and such.

With the availability of large/cheap FPGAs, I've been thinking it would be fun to build a multi-core Z80 system with 1 CPU running a 'kernel' and multi-tasking provided by running CP/NOS clients on the other CPUs - Imagine a multi-tasking OS where each program gets a dedicated CPU instead of having to timeslice!

I've never touched CP/NET or MP/M, but I've read up a bit on them, and on CP/M 3 which shares a number of features --- I have to say that I'm not really a fan of it; there's a lot of extra complexity for a debatable set of improvements, which is why I stuck with CP/M 2.2. (Also I couldn't find a open source CP/M 3 compatible BDOS.)

I do like the FPGA idea --- it feels like a better GA-144. But I'd probably implement it using something based on CP/M 2.2: it would need a BIOS with a remote console and communication channel system, with a switching fabric in the FPGA tying nodes together. I'd also have to rip the filesystem out of the BDOS in favour of something NFS-like over the communication channels, but as that wouldn't really leave anything left, I suspect this would rapidly turn into a combined BIOS/BDOS with most of the actual work done on the file server.

I'm not convinced the end result would be useful... but it'd certainly be cool.

I think CP/NET is actually pretty close to what you're describing - what the 'server' runs on is actually arbitrary (it just needs to implement the protocol and allow file access), and there is an implementation for unix computers floating around somewhere. The clients were running CP/M 2.2 but with a kind of stub BIOS/BDOS (it sounds like it fit in a 4KB ROM of what's basically a thin client) that mostly just had the network interface code.

On an FPGA, just tying together a bunch of cores with 8-bit FIFOs to communicate would be both very cheap and very high performance. I have a simple setup with a Z80 running CP/M at ~80 MHz on a Digilent "Arty" Artix-7 board, and you could probably cram 8 of them on the chip if each core only had a cache backed by DRAM.

Oh, huh. I thought it was more heavyweight than that. I'll go take a look.

Sadly I don't know enough about FPGAs to know whether the Artix-7 is particularly big or not. But you know what would be _really_ cool, though? If your Z80 cores were all implemented using asynchronous logic...

this would be great.. and/or also leverage the modern VM extensions for a cheap 'realish mode' hypervisor system.

Maybe, with a little tweaking, Ant's Editor from IOCCC 1991, the one that says "#define T isspace(*(t=Z(p)))&&". It's a passable vi clone in C using a gap buffer, and it compiles to 7K of amd64 machine code, and somewhere the author has posted the non-obfuscated version. Nominally it depends on curses, but I suspect you could get it to work with implementations of move(), addch(), clrtobot(), clear(), and mvaddstr() that just emit some escape sequences, a getch() that just makes a BIOS call, and null implementations of initscr(), endwin(), raw(), noecho(), and idlok().

IOCCC '91 was before the IOCCC switched to open-source licensing, though, so you might have to somehowe find Anthony Howe and get him to relicense. Or maybe he already did.

I don't know, maybe I should just write one. Is there a reasonable emulator for the Amstrad?

Why are you using ZCPR1 instead of ZCPR2?

I haven't seen ae. I'll take a look. Fuzix has some decent software, too, including a stub curses, which may be useful. Thanks!

Re ZCPR2: licensing. It's got a no-commercial-use license encumbrance which ZCPR1 doesn't have.

Oh thanks! I didn't realize that about ZCPR2 (and, I suppose, ZCPR3). Are all of its authors still alive? Maybe they'd be willing to relicense.

Have you been able to find ae? I can dig around and probably find a non-obfuscated version if the trail is going cold.

Still interested in the Amstrad emulator question. If I'm going to hack together a CP/Mish text editor I'd like to be able to test it on (an emulation of) more than one target platform.

(While we're talking about Z80 stuff: the embedded Z80 microcontrollers I've found on Digi-Key are absurdly power-hungry. Is there a Z80-compatible out there in the ¼-nJ-per-instruction neighborhood of the STM32L0, or at least the 10-nJ-per-instruction neighborhood of the AVR? Because AFAICT there's really no reasonable self-hosted development environment for the AVR, much less for an ARM with tens of kilobytes of RAM, while the Z80 has not ony self-hosted batch-mode toolchains but even IDEs. The first time I saw Turbo Pascal running was on a Kaypro II.)

I found ae; later versions build but they're kinda big (45kB, yikes), and while the unobfuscated early version is amazingly simple it handles redraw by refreshing the entire screen on each keypress. If you've got curses that's easy, and quick, but if you don't have curses, hrm. CP/M terminal emulators are frequently painfully slow and you want to minimise screen refreshes.

Right now I'm wondering about writing my own in another livecoding session; that original ae is a masterpiece of simplicity. The trickiest part would be handling screen updates... https://groups.google.com/forum/#!topic/comp.editors/335qpDF...

Re Amstrad emulators: I haven't played much with these, but I'd probably suggest Joyce: https://www.seasip.info/Unix/Joyce/ That said, I've been running the Kaypro cpmish port using MESS, and it's surprisingly solid. There's even a good debugger. So it might be worth giving that a try.

Re microcontrollers: there are very, very few Von Neumann architecture microcontrollers, and they're mostly just boring low-end ARMs. The one exception is the MSP430, which is nice but still not a Z80. I think the eZ80 is all there is.

Thank you! Yeah, 45K is pretty huge, and redraw logic was pretty commonly the most complex part of editors of that time period. The version you linked compiles for me to 2316 bytes of amd64 machine code (in .text) with cc -Dindex=index_ptr -DBUF=4096 -DMODE=0666 -Os ae.c -o ae -lncurses, but of course then it's linked with ncurses.

Ah, and it looks like Howe did dedicate it to the public domain! That's nice.

I didn't remember that it refreshed the screen on each keypress. The terminals we used on actual CP/M machines were usually pretty snappy, faster than terminal emulators are, at least if you don't count the slow phosphors. But typically they were only 9600 baud, so redrawing the whole screen would take two seconds; escape sequences like the insert-line/delete-line pair supported by the H19 and the VT100 were really important. Contemporary machines like the Apple with its memory-mapped screen buffer avoided the whole terminal catastrophe.

I did see your notes on the site on Kaypro emulation with MESS. Thanks!

I wonder if a text editor for the Atari ST could be ported fairly easily. The 'GEMDOS' on the ST was based originally on CP/M68k -- with some PC-DOSisms added.

Here's a piece of history I didn't know:

https://en.wikipedia.org/wiki/Stevie_(text_editor)

"STEVIE, ST Editor for VI Enthusiasts, [2] was a clone of Bill Joy's vi editor created by Tim Thompson for the Atari ST in 1987. It later became the basis for Vim, released in 1991.[3][4]"

Source code here:

http://nosuch.com/tjt/stevie/

Apparently Stevie can be made to work on CP/M but there's claims it's too slow for real use. See https://groups.google.com/forum/#!topic/comp.os.cpm/lfuEr0hR....

Thanks for the suggestion, though --- keep 'em coming!

What would be needed to support some of the small retro z80 platforms out there?

I can't even begin to list them all - most basically tie the z80 to some static RAM, maybe a pia or similar; I know one out there uses an ATMEGA32 to act as RAM/ROM - plus there's ones that use SD cards for storage.

I'm not really into the retro z80 scene yet, but I'm gathering parts...

CP/M is modular and incredibly low in requirements. You don't even need interrupts. All you need is more than about 16kB of RAM, mapped at 0x0000, and enough hardware for a console and disk. (Obviously the more the better. You won't get much done in 16kB.)

The command shell, the CCP, and the kernel, the BDOS, are completely platform independent. The only actual architecture-specific bit is the BIOS, which the rest of the system talks to via a set of very simple entry points. There's documentation here: http://www.gaby.de/cpm/manuals/archive/cpm22htm/ch6.htm#Sect...

That is, literally, it. There's a little subtlety in the warm boot / cold boot stuff (every time you exit to the shell CP/M literally reboots and loads itself off disk! But it's so quick you don't notice), and the 128-byte CP/M sector size is a total pain which requires buffering for modern hardware with 512-byte sectors, but it's all exceptionally well documented. If your system is simple enough, you can hack up a BIOS in an evening.

If you're not using a serial terminal you need to implement a terminal emulator in the BIOS, and deal with display memory etc. That can rapidly eat away your RAM, so having a banked system helps. The NC200 port divides the 128kB of RAM into two halves, one for userspace, and one for a 'supervisor' which does all the I/O. The BIOS is just a stub which calls the supervisor. There was loads left over in the supervisor address space so I added a massive disk buffer, allowing me to read and write complete tracks in a single disk revolution. It's really quick (for CP/M).

Check out 's', ported and updated by Udo Munk with some help from comp.os.cpm

https://github.com/udo-munk/s

Here's a screenshot of 's' running on my Z80-in-UE4 emulator on the left, with my own embryonic vi clone on the Z80 unit on the right.

https://imgur.com/a/5u5wA

My first computing and programming was on a CP/M machine. It was the 90s, Windows 95 was just coming out and I was just 12, but my family was too poor to afford a contemporary computer. The mother of one of my classmates gave me an old Epson QX-10. Even figuring out how to boot the computer was a learning experience. Among the disks I also found dBASE II, and a book on programming it. I also had a lot of fun duplicating disks and sending files with PIP. Many of the commands and concepts of CP/M were similar to but more orthogonal than MSDOS.

I have an Epson PX-8 (with integrated microcassette drive!). It's terrible, but in a completely awesome way. https://www.youtube.com/watch?v=S3MARL-F8NI

Hurray! CP/M on an Amstrad 464 in the 80s was my first contact with an operating system that back then felt to me professional - like those in the movies. And it brought compilers.

Me too, I used CP/M on an Amstrad CPC 6128.

It was the only environment I could find compilers and an assembler for, along with a book in a local library. It ended up teaching me Z80 assembler, but with Motorola style syntax!

I remember writing an invaders style game and a disk sector editor with it. Fun times and the beginning of a long journey that still continues to this day.

This is pretty neat!

One nerdy question, from someone who actually used to run Z-System (on a TRS-80 Model 4 and an Intertec Superbrain, for the record) -- why ZCPR version 1, instead of a later release? Is version 1 the only one with available source and/or a compatible license?

ZCPR2 has a no-commercial-use license encumbrance, while ZCPR1 is genuinely public domain.

My first job was programming a Sony SMC-70 Z-80 based computer that ran CP/M using the BDS C compiler. (BDS stands for Brain Damaged Software. It was an integer-only version of C.) The SMC-70 was connected to a Sony Laser Videodisc player. It controlled the videodisc over an RS-232 connection and put the video out from the videodisc into an overlay circuit that allowed use to overlay computer graphics onto the video. We used this to create interactive training programs for the US Air Force.

Ha! I'd love to port this to my Z80-emulator-in-Unreal-Engine project:

https://i.imgur.com/Q6307w3.jpg

https://i.imgur.com/OfGXFeO.png

The BIOS is compatible with Z80Pack, so it wouldn't be terribly hard to modify your BIOS to work with that.

If I can this to work, I might get back to work on my project. It stalled due to the complications around the original Digital Research license, among other reasons.

I'm confused -- other sources from DR were GPL'd -- GEM, for example -- was CP/M not included in that dump?

I've definitely seen the CP/M 68k sources floating around, and GPL I believe?

The computer history museum has the sources for early versions (https://www.computerhistory.org/atchm/early-digital-research...).

According to that page “This material is provided for non-commercial use only.”. The source code archive may be more specific.

Yeah, I did see that I'm just confused how a whole bunch of other valuable DR stuff got GPL'd, but not CP/M.

Also, from past perusing, the GEMDOS sources for the Atari ST were basically a fork of CP/M 68k. There's source in there with comments that go back to CP/M. The relocatable binary format loader, for example. I would be surprised if there weren't pieces that that could be scavenged for this project.

Nope. CP/M was _not_ GPLd. Instead it got a custom license from Lineo which explicitly allows for it to be distributed by one site, and one site only: http://www.gaby.de/cpm/license.html

It's a fascinating historical resource, though.

Cool that you are keeping this alive. I had the Zorba, it was very interesting there was a program that would let you swap disk parameters around so it could read a variety of different disk formats. It made program/data sharing with other people simple.

I see you are looking for an editor, have you considered stripping down the Borland Turbo Editor and using that for your baseline?

Was it ever open sourced? I can't find a reference.

I used to run CP/M on an Apple ][e with a Zilog Z80 card.¹

I learned pascal on it (Turbo pascal) and C as well.

https://en.wikipedia.org/wiki/Z-80_SoftCard

This is all well and good, but I can't find the answer to the most important question to me: does it have 'ladders?'

Reply on news.ycombinator.com