Soldering Complete! AND What is the draw to CP/M?

A project log for Vintage Z80 palmtop compy hackery

It even has a keyboard!

esot.ericesot.eric 07/23/2021 at 05:315 Comments

MANY DAYS (Weeks?) as The One Big Plan for the day, upon waking each morning... and still left with it on my mind upon going to bed. Heh! What was it... eight solder joints?

I now FINALLY have a means to power the thing while it's open, as well as not wipe its memory by opening it. I scaled-back the plan quite a bit. I have test-clips, but installing them without shorting pins is /very/ unlikely... so, I'd planned to solder leads to the pins I plan to test. Instead, on a whim as the sun began setting, I wired the cable to the external battery-pack through the switch that was already in it... (Why would I want a switch on the main power supply of a system which sleeps when "off"?!) Only after that split-second last-minute decision was implemented did it occur to me... hey, if I cut the power, I can install the test-clips [almost] wherever I want and not have to worry about shorting nearby pins in the act! Nor do I need to be limited to only the pins I pre-soldered leads to! Holy schmoly, brilliant!


WEEKS, maybe, to solder in an internal backup battery, a header for a power supply, and some leads to a battery pack. Hah!

I think, maybe, now I can finally code-up somethings to/and test those pins.


In other news, I just scrolled on a Z80-based CP/M machine designed recently which has just a handful of period ICs aside from a Compact Flash card... and it got me to thinking...

What Exactly Is (or was) The Draw To CP/M? It's a sincere question, being that the past several weeks of non-progress on the front I'd been planning have instead resulted in my gathering all sorts of ideas how to design my own stock-z80-based computer... I WOULD'VE thought (rather, /did/) that the crazy sorts of implementations I've come up with would be far too architecturally different to enable running most z80-based era-computer-programs... E.G. my vidcard idea of a recent log, surely loadrunner wouldn't run on that...? But Then... I start seeing these CP/M compatible designs that folk've come up with that are nowhere near architecturally similar to, say, my Kaypro... and... well... then I start thinking, well heck, there were /numerous/ z80-based computer systems in the CP/M era, and they varied dramatically, yet they mostly ran CP/M, right? Yet, they couldn't run each others' programs, no? So... then... what /IS/ CP/M...? What does it provide, besides a common look in directory-listings? Can /some/ CP/M executables run on /any/ machine running CP/M? While still others can't because, say, they might try to directly access hardware that isn't there? I just don't get it. And, if the former... what types of programs would be universal like that that folk would want to run on their otherwise custom machines? So far, I see Fortran, Assemblers, and C as possibilities, maybe some serial-communication programs... Text adventures? Surely even most text editors would require finer/lower-level interaction with a screen than stdio provides. I'm not trying to discredit the idea, I'm just trying to understand, maybe even consider trying to implement it on my design, if I can figure out why... what's the draw to running CP/M? What all does doing-so offer?


In a similar realm, I recently saw DOS running on an 8086 in... well, heck, I forget the name... but, basically the 8086 has two modes, an easy mode and a hard mode... one requires a LOT of external circuitry, which is the one PCs is based on. The other is far simpler, but removes options like DMA and such that... I thought... DOS relies on. So, again we're back to the same question as for CP/M... what on earth would be the draw to running DOS on a system so architecturally different that the vast majority of software written for DOS can't run on such a different system? At that point, isn't it basically just a slightly more sophisticated BIOS that basically implements disk-access and little else? Heh, and DOS gets all the credit, when, frankly, most applications of the era had to be so deeply-coded to the hardware that, essentially, every program could've been run "bare metal," bypassing an OS completely, with only a tiny bit more effort, if any. So, basically, initially, the draw to DOS was the ability to have many different programs on the same disk... right? And then later it started providing essentially hardware-drivers that were basically glorified BIOS routines...?


And, rereading just now, it occurs to me how strange it is that test-clips don't simply have epoxy or acrylic or some sort of insulation on the backside. Could preventing shorting really be as simple as brushing on some nail polish?! Why haven't I heard of this?!


ziggurat29 wrote 07/23/2021 at 18:50 point

re: CP/M -- nostalgia, to wit.  I very much wanted to run CP/M back in the day (1980), but I couldn't afford it.   It was /the/ OS to have if you were running a micro in the 70's and even early 80's to an extent.
CP/M was the front runner for the nascent IBM-PC. -- IBM didn't really believe in micros and decided to enter the market begrudingly and was shopping for an OS produced by a 3rd party.  This history abounds on the Internet, so I won't repeat it here (and some is fable), but the short story is that IBM didn't come to an arrangement with Digital Research, and went back to Microsoft, who lied and said they had an OS, and then they bought a local company Seattle Computer Products, which had a CP/M knock-off called QDOS, which was quickly rebranded as MS-DOS.  Gary Kildall was unsurprisingly irritated, and all the more so with MS-DOS' eventual dominance at the expense of his CP/M.  There was a CP/M for the PC, but it was like $300, and few people bought that since MS-DOS shipped out-of-box.  Such was Gates' business savvy.
Digital Research's and Gary Kildall's history is interesting in its own right.  Check it out if you're bored.  If you want to see Kildall in life, he co-hosted "The Computer Chronicles" in the 1980's, so you can check out those ancient episodes on YouTube.

Now, as far as putting CP/M on this calculator, hmm.  I don't know if I'd bother.  I had thought about putting CP/M on my TRS-80 emulator project (it would not be a TRS-80 anymore, but not the point), but decided against it for several reasons.  First, there's a zillion CP/M emulators out there, so what would I be contributing?  Second, using CP/M is just not much fun now that we are 45 years hence and used to many more creature comforts.

Your case is different, since you are not emulating, but doing hardware.  However, I think you're going to have some challenges with CP/M.  First, CP/M had a weird design that /required/ that RAM be at address 0-256 (or maybe more -- I can't recall).  You have ROM there.  You can hack the source, but then that gets into the next problem:  applications had a somewhat tight binding to that design.  So you are not going to be able to run existing built binaries and so you won't be able to take advantage of the existing software base.  And not being able to do that does somewhat take away from the charm.

Why not just make your own 8-bit OS?  Borrow concepts freely.  You'll have to decide whether you want to reuse the existing ROM routines or replace that with your own device (and then you have to figure out how to burn it!).

  Are you sure? yes | no

esot.eric wrote 07/23/2021 at 22:38 point

ah hah, so that does kinda answer my questions with a question I'd kinda hesitated to ask, myself... "Why don't they make their own OS?" Mostly, in consideration of: surely creating all the ROM routines and architecture compatible with CP/M would be almost as much work, and apparently with little benefit since, it seems, most pre-existing applications wouldn't run on it, anyhow. 

But: I think I'm kinda getting it: nostalgia aside, having a C compiler, for instance, at your ready would be a heck of a lot easier than trying to make/port one. And, being that really all it needs is stdio which is taken care of via CP/M (and necessary BIOS calls), it doesn't really depend on a certain computer's I/O, keyboard, display, or even serial-port and an external dumb terminal.

So, from the sounds of it, CP/M, and DOS, basically just made for the ability to share /some/ applications, but not all, between machines... and, at the time, being soon after paper-tape programs, most users of CPM/DOS were pretty well aware they'd mostly be writing their own software... BASIC, or Fortran, even ASM... and fancy stuff like graphics or sound, then, were very much hardware-specific... basically just peripherals that one would program for if they need it... 

Which... goes along with my understanding of say HP-IB, as well... Nowadays Labview, say, has drivers for such devices, but my HP-IB card came with a programming manual. And, I'm guessing, so would have the HP-IB 8inch floppy drives, and so did the HP-IB plotter... it wasn't "click File->Plot" it was: use BASIC (Or C) to send hp-gl commands for the lines you want to draw, send them to port x (HPIB card), but only after telling port x that you want to talk to device 8 (plotter). Heh! And, similarly for the hpib floppy drives, I guess! I'm betting DOS didn't know how to talk to them! Nevermind, say, that programmable power-supply or multimeter. Or the awesome digital/analog-switchable oscilloscope which has BASIC code in the manual. Sound, or even graphics must've been similar at the time... So, even if pacman was written for z80 and CP/M, and your machine had both, it still had to have the same graphics card addressed in the same way with the same configuration registers as the programmer's setup.  

Now, atop that, you mention that the memory may've been mapped differently between machines, and since the applications worked with the hardware at such low levels, even that could be the deciding factor  of whether a program would run on a different machine! 

Hah! No Wonder the PC was revolutionary... not because its hardware was particularly profound, but because it was cloned, folk could finally share their programs!

So, hmm, writing my own OS...

First-off, I was thinking more along the lines of, if I built my own z80 machine, rather than, say, trying to replace (or extend?) the calculator's OS. (But, why not? Hmmm). 

Well... somehow I see developing an "OS" of sorts as a bit of the sort of thing that would evolve (slowly) on its own... Just having the hardware, then writing a (bootable) program to, say, take keyboard input and spit it out to a screen... step back, make that a bios routine. Then reading/writing a serial port, then later a disk/CompactFlash so-forth. Before CF, manual selecting/booting of an application (e.g. stored in some dip-switchable ROM location). Then maybe a BIOS menu and addressing circuitry scheme to select those programs, then another "upgrade" to load them from that ROM into RAM to be executed, then a slight modification to do the same thing from "disk", and so-forth...

Who knows, maybe on to drivers and multitasking... but, really, from the sounds of it, those things don't really define an OS in that classic sense... A homebrew OS, it seems, could be quite simplistic, and evolve over time...


  Are you sure? yes | no

ziggurat29 wrote 07/24/2021 at 07:36 point

Yes, you have to figure out for yourself whether you're interested in making an OS, or whether you want to port an existing OS to the hardware.  CP/M might be too old school for your tastes. You could test-drive one of the many emulators to see if you want to bother, but then again you've probably already got hands-on experience from the Omni 4.
I believe NuttX can be made to run on a Z-80, which would give you a Unix-esque experience that might be more comfortable.  The challenge will be in producing drivers for your hardware.  Then you have to decide if you want that hardware to be this calculator, or something else.  The calculator is attractive because you already have it built and there's charm in repurposing it.  But maybe that the ROM/RAM design is too constraining.  It all just depends on your interests.

  Are you sure? yes | no

esot.eric wrote 07/25/2021 at 22:23 point

gah! Wouldn't you know, no notification for the last one. Lucky I still had the tab open!

Indeed, re: OS path/choice. I totally agree that there's some draw to working with this system's hardware in such ways... Especially now knowing a bit about the hardware; could it be I now know enough to actually implement "drivers" for all its hardware? Or at least that necessary to get it running from my own bare-metal bootable code?

And, interesting point, there... having just soldered in the FLASH addition, it might only be a matter of a toggle-switch (and a pin-pop) to choose whether to boot from TI's ROM or my own code/OS... HMMM... (in fact, both /CE0 and /CE3 are at the PCB pads for the unpopulated U10... a small bit of rewire could place the toggle right there)

I really hadn't thought of doing it that way, swapping the boot-ROM. Kinda felt like I was stuck working within TI-OS, e.g. running a custom OS would've meant essentially having used TI-OS as a bootloader, and the ASM program would take over completely from there. But, doing-so would mean some things would be unchangeable... page zero would always be mapped to the now mostly unused TI-OS ROM... Res commands (and interrupt routines? More?) would be unchangeable... so-forth. Oh, also... can't just overwrite the system RAM, etc. even if you had no intention of returning to TI-OS... because it /will/ return after power loss, maybe even power-down. 

Again, nothing wrong with TI-OS, per se, but I'm more a hardware archeologist than a software one...

So, duh... just /don't use/ TI-OS in some of these coding endeavors! Hmmm!

Now... other choices... well... again, I'm not likely to code-up my own assembler, certainly not C. So I need /some/ OS to provide those... Therein CP/M might be a decent option... and a bigger/additional FLASH could offer triple-booting. 

Seems there are many path choices!

First, however, just trying out that flash chip... I'll use TI-OS, ASMIDE86 , and ZAC for that. We'll see where things go after that.

  Are you sure? yes | no

ziggurat29 wrote 07/31/2021 at 15:06 point

You're getting really close to being able to implement your device drivers.  The hardware is limited:  keyboard, display, serial port thingy, and fiddly bits like power and the periodic ISR.  You can use the TI-86 code to guide you on those things.
As for Assembler, you have one already, no?  As as for C compiler, I have used SDCC successfully.  No need to live in assembler hell if you can avoid it.
Realizing an OS on this paged device will be a little challenging in itself, but you should be able to create a 'kernel' on ROM Page 0, and core OS structures on RAM Page 0, and then use the other RAM pages for multiple 'tasks' or maybe extended heaps.
If it were me I'd skip CP/M for this project unless you /really/ want to.  You'll have to do major surgery to the design, which I think for me at least would be more work than starting from scratch and working with the hardware.  But this is your project, so do whatever strikes your fancy!

  Are you sure? yes | no