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.
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?
Re ZCPR2: licensing. It's got a no-commercial-use license encumbrance which ZCPR1 doesn't have.
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.)
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.
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!
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 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.
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.
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...
Here's a piece of history I didn't know:
"STEVIE, ST Editor for VI Enthusiasts,  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."
Source code here:
Thanks for the suggestion, though --- keep 'em coming!
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.
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...
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).
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.
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?
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've definitely seen the CP/M 68k sources floating around, and GPL I believe?
It's a fascinating historical resource, though.
According to that page “This material is provided for non-commercial use only.”. The source code archive may be more specific.
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.
I see you are looking for an editor, have you considered stripping down the Borland Turbo Editor and using that for your baseline?
I learned pascal on it (Turbo pascal) and C as well.