This project looks interesting. I saw you use stty to configure the console, but there is a native "UNIX way" to do this via tcgetattr/tcsetattr, you'll have to figure out how to use these C functions elegantly in Go though / if there is some Go package which wraps them already. On Windows you'll have to configure the console via win32 API calls GetConsoleMode/SetConsoleMode and again you'll have to figure out how to do this from Go ⇒ you'll have to add some compile time switch between "UNIX like" OS and Windows to support both. The "UNIX like" version should work on Linux, macOS, and various other UNIX like systems.
You could also improve the debugging experience with full execution trace recording (record all executed instructions / memory accesses / … to a trace file) which would not only give you detailed information about what exactly went wrong if something goes wrong but also allow you to directly debug your own Z80 code on assembler level.
Thanks for the feedback - there's a disjoined comment in the README on portability that points to the golang package x/term, and a single open bug report that says "fix it".
So I have a plan, but it's a bit more annoying than I'd like to handle. At least the "conditional compilation" via build-tags is nice and straight-forward!
There is a trace of all CP/M syscalls made, available via the "-log-path" command-line option, but so far I've not needed to debug actual Z80 opcodes.
OP is a based madlad for writing a text adventure game -- for ancient retro hardware -- to amuse their kid. If kids are going to be exposed to technology at all, the old 8-bitters are much more effective at stimulating curiosity, imagination, and learning than an iPad with Cocomelon or Skibidi Toilet queued up -- even in emulated form.
I taught him how to divide the range in half to cut down on the number of guesses, and once he got the hang of that he was hooked.
We played a couple of simple text-based games together after that, but most of the classics were too hard, too long, and required too much typing for him. So the game I made was deliberately simple.
Even so the first time he played he had no idea that a rug could cover a trapdoor. That level of hiding things was too much for him to leap to himself, I had to direct him.
These kinda shared activities don't replace his love of Minecraft, or Super Mario Bros (original NES version!), but I'm still glad we can do them together.
I've become familiar with it playing with the Kaypro 1 (the last CP/M model, not the first Kaypro - their model numbers are confusing). I picked it up years ago and just got around to getting disks etc recently.
Interesting to see the influence on DOS, and how people used to deal with ED to write assembly etc.
Really nice machine to play Zork and such on. The monochrome green is so clear and nice, and a really good size. Keyboard feels great.
I've been trying to get serial working with the odd pinout without success yet.
I got to use CP/M briefly on a DEC Rainbow machine in the 80's. It was very similar to DOS but IIRC there were quite a few differences at the detail level. I remember seeing some ads for Kaypro's but I don't think I ever saw one in real life... What sort of issues are you having with the serial port? You might need to jumper the flow control pins if you can't disable flow control. I'm sure the pinout is documented? I had to deal with lots of oddball serial ports way back when, I might even have some breakout/jumper RS232 adapters lying around.
I finally figured it out today, I needed to use the modem port and a another different pinout. I'd been reading about the wrong kaypro before I think. I checked the pins with an oscilloscope and read the manual to figure it out. Pretty satisfying that it's working and it's also nice to finally close up this breakout connector and wire I got a while ago to make the "Kaypro cable".
I worked at a computer store in the mid 80s and we sold the heck out of Kaypros because they were a bargain next to DOS machines. They came bundled with software and often times a promotion with a bundled printer as well.
They tried transitioning to add DOS support with an addin card but it was too late to save them as PC and Apple became the defacto standards.
There was a little-known multiuser CP/M variant called MPM and we managed to sell a few of those, too. It was a cool if plain OS.
MP/M led to Concurrent CP/M-86, which in turn led to three separate families of OSes:
• Multiuser DOS (native 32-bit multiuser multitasking DOS-compatible).
• DR-DOS (DR's comeback, a better DOS than MS-DOS, available at retail, which spurred MS into creating MS-DOS 5, then 6, then Windows 95).
• DR FlexOS: realtime multitasking with a GUI, used widely in the embedded industry for ~40 years and still supported on some IBM point-of-sale terminals in the 4680 and 4690 range.
I ram MP/M 2 on an Altos and it was an excellent system. I think up to about half a dozen users sharing the system, surprisingly good performance for word processing tasks.
MP/M was fairly common in small office environments. I remember one particular accounting firm which had managed to delete all their files on the harddisk.. they had an MP/M system with, IIRC, eight terminals connected.
I managed to restore all their files (not very difficult on CP/M or MP/M, as long as the drive is left in peace after the incident, which is what they did).
You could also improve the debugging experience with full execution trace recording (record all executed instructions / memory accesses / … to a trace file) which would not only give you detailed information about what exactly went wrong if something goes wrong but also allow you to directly debug your own Z80 code on assembler level.