CP/M Days 06/12/24 ---------------------------------------------------------------------- Ok, I've had a CP/M machine operational for a little bit now, so it's time for more details. Information about the system can be had in a previous post[1]. # Serial Comms In case you're not aware, CP/M has an available BIOS I/O concept called IOBYTE. It "creates a mapping of logical-to-physical devices that can be altered during CP/M processing"[2]. In several places this IOBYTE concept is said to be based on an "Intel standard", but I've been unable to locate documentation about any standard. I think, rather, that the so-called standard was simply to mimic the bottom-of-address-space behavior of the Intel 8080. To make a long story short, CP/M is able, through optionally included BIOS calls, to use the IOBYTE function call to map serial ports. Modern software would handle port assignments in easily configurable ways, but CP/M software wasn't quite there. Most software requires patching, and that requires understanding of the IOBYTE setup. Of course, I didn't know all this for a long time. I had been fiddling with various serial comm programs, including the very simple RC2014 terminal program whose ASM source is readily available[3]. All of the pieces finally came together when I pulled the computer out this time, and I was able to realize that my TERM programs weren't getting the switching done properly when I was using the SERIAL port as a terminal, but they were working when using the TTL port (speaking now in Grant Searle's terms for his board's ports, one of which has an RS232, the other of which does not). What I also realized was that Kermit, which uses the BIOS call for switching the IOBYTE, was able to be made serviceable if I set the secondary port to CRT with the "set port CRT" command. In Grant's BIOS, the CRT port is the TTL (I primarily use the SERIAL for my VT100 pocketerm). With this setting, Kermit file transfers work flawlessly. (I should probably take a moment here to recognize how amazing it is that Kermit still works so well, and is still so widely available, after all these years. It's still maintained, even for ancient systems. Thank you Kermit team!) TLDR here is, I have realiable file transfers without pulling the CF card out and using odd tools. I can send and receive to an external system, which is a fundamental thing for me. All that lacks presently is a reliable setup for connecting to agetty for a remote login prompt on my Linux system. It works in kermit, but I have terminal emulation issues no matter what I do, and even with a dumb terminal setup there seems to be some kind of buffering issue. One day, it'll get there. # Shell You can customize things about the CP/M console command processor (shell, as call it these days), with GETSYS, PUTSYS, and SYSG... I think. It seems to be what I'm reading. However, all of that is hardware dependent, and I haven't taken the time to connect the dots between what I read and what Grant has setup with his BIOS (though, he makes his source available, so I'm sure customizations could be done). One thing that drives me a little bit bonkers is the lack of a PATH environment in the default shell. It's not that big of a deal to specify a drive letter all the time (there are not directories to worry about), but it's a slight annoyance. Enter MicroShell v2.0, (c)1982 New Generation Systems. MicroShell is a fancy little shell that strives to make CP/M more unix-like (an effort I can get behind!). It adds input and output redirection, pipes, batch processing, command chains, custom prompt strings, PATH, and more. Those items alone make it entirely worthwhile. The default prompt suits me just fine. The A: drive is in my path now, so I keep my most useful programs there and can run them without specifying the drive. Now, MicroShell can actually be setup as the main command interpreter, but that requires SYSGEN stuff, and I'm not there yet with Grant's setup. Perhaps someone has already done it, I don't know. Maybe it's time to email Grant and see. But for now, it's easy enough to start the shell on boot by typing "sh" in the A: drive. I can't give MicroShell enough praise. Go out and buy a copy, available now wherever CP/M software is sold! Drive in to town and support your favorite software retailer! Or, just download it, you dirty pirate[4]. # Software During this last run, I added a few little bits of software: * Microshell (already mentioned) * D (part of Microshell, alternative DIR command) * ERAQ (erase files with confirmation) * ORB (game) * ROGUE (game, the famous one) * CHICKEN (game) * SARGON (game) * MAZE (game) * BBCBasic * IOB (a little BASIC program, compiled, to change the IOBYTE) * MONOPOLY.BAS, BANNER.BAS, POSTER.BAS * UNZIP157, PMARC, NULU152 (for managing archives) I also added some readme files in the A: drive, and updated some information in the I: drive (I use the I: drive for my manual pages; there is a text reader in there that I've named MAN.COM so I can type "I:man " and get a manpage looking thing. Very useful since I don't use this system often enough to recall everything.) # Issues Of course, my experience recently hasn't been without issues. There are always terminal emulation issues and one-off little program quirks, but honestly only one issue matters to me: file corruption. For some reason, from time to time, I end up with file corruption either during program execution involving filesystem calls, or during serial data transfer. I haven't really narrowed down the cause. Part of me wonders if my power supply is inadequate (especially since I've connected a second RS232 to the TTL). Another part of me wonders if CP/M just stinks at avoiding problems. Yet another part of me wonders if it's due to having a Frankenstein system full of randomly collected software built for different CP/M computers. My solution has been to keep an image backup of the compact flash card, so I can restore the whole blasted thing when something goes wrong. It's a little overkill, but on my modern system I can keep an obscene number of 128MB backup images without breaking a sweat, so there is that. And it only takes a few seconds to backup/restore, so there is that too. At some point I'll try a different power supply, to see if that helps. # Conclusion I enjoy almost everything about this little computer. It's small enough to keep around all the time, and about the only thing stopping me from doing that is the file corruption issue. Perhaps it's time to build a case and buy a real power supply for it, and see what it can do with that. But, I do miss DOS, which is what I was raised on. In any case, it has been fun to have out, and I suppose that was the point all along. [1] gopher://zaibatsu.circumlunar.space:70/0/~tfurrows/phlog/2024-05-18_cpmBackOn.txt [2] http://www.gaby.de/cpm/manuals/archive/cpm22htm/ch6.htm#Figure_6-1 [3] https://github.com/maccasoft/z80-apps/blob/master/TERM.ASM [4] http://www.z80.eu/microshell.html