Around 1984, I worked for a Unix workstation manufacturer named Callan Data Systems [1]. Our workstations were 68k based and ran System V.
Except for one that was sitting in a corner of the main office, which I noticed was running CP/M-68K.
I asked around and found out that this was for the accounting people. It wasn't because they needed some accounting software that wasn't available for Unix. Everything they were interested in could easily be done on Unix.
So why did accounting choose CP/M-68K?
Because they assumed (correctly, it turned out) that in a company where all the engineers were Unix kernel hackers, running CP/M would keep all the engineers from messing with accounting's computer.
[1] https://en.wikipedia.org/wiki/Callan_Data_Systems (BTW, Wikipedia says Callan was founded by Dave Callan. That's only partially correct. There were actually three equal founders. They could not agree on a name for the company, and it got to the point where the only thing stopping them from starting was having a name to put on the paperwork. One weekend the other two founders went away on a hunting trip, and when they came back Callan told them he'd picked a temporary name and filed the paperwork, and they could change it to the real name later when they came up with one. They never did agree on a "real" name, and so the company retained Callan's "temporary" name, Callan Data Systems).
Wow - I did a lot of work with CP/M in the early 80s, but I'd never even heard of that variant. Yours may have been the only copy ever purchased :)
> It wasn't because they needed some accounting software that wasn't available for Unix.
Well, actually, it may well have been - there was a lot of accounting software (and other end user stuff such as word processors, databases and spreadsheets) written for CP/M, and back then not so much for Unix (which I was also working on at the time).
Yours may have been the only copy ever purchased :)
Hardly. It wasn't wildly popular, but it was widely available on early 68000 machines. It was easy to port, and you got a little bit of useful software along for the ride. In addition to various Motorola (VERSAbus) machines and the small guys like Sage and Stride, HP sold it for early HP 9000s. And it was available on the Tandy model 16.
You want really rare...there was a Zilog Z8000 version of CP/M. I think there was only 1 production machine it was released on (Olivetti M20).
Thinking more about it, I'm not actually sure it was CP/M-68K. I remember hearing something about before building the 68k workstations they built a couple test units with x86 motherboards to test out the proposed workstation form factor.
Accounting may have ended up with one of those, in which case it would have been plain old CP/M-86.
How much accounting software was there for CP/M-86 or CP/M-68K?
CP/M-80 was a popular platform for business software in the late 1970s and early 1980s, but CP/M-80 software wouldn't run on CP/M-86 or CP/M-68K due to the different CPU architecture. A lot of this software was written in assembler (for performance), which meant that porting to another CPU architecture was closer to a rewrite than just a recompile. (There were tools to convert 8080 assembly source to 8086, although I don't how well they worked.)
I was under the impression that most CP/M-80 business software vendors moved to the IBM PC and PC-DOS/MS-DOS as their target platform, and not very many of them ported their software to CP/M-86 or CP/M-86K. (I could be wrong about that–this was all happening when I was a baby.)
IIRC, its propietary OS, SIM/M, was apparently a CP/M clone, later retronamed CP/M-80. Both dBase ii and iii ran on this fantastic small business machine.
My first ever computer was a hand-me-down Osborne. I vividly remember needing a special hardware keyboard combination to be able to display all the contents of the “window” in the frame buffer.
I’ll definitely need to check this out for the nostalgia.
A lot of the CP/M computers I used had serial terminals connected to them and no way to directly attach a monitor and keyboard. It feels like it's easier to emulate that way. Also, Apple's Terminal.app does an outstanding job of pretending to be a VT-200 terminal.
OTOH, this one is self contained. Still pretends the terminal is attached through a serial port, but it's emulated in the app.
It's a shame Apple doesn't make the Terminal.app engine available to developers.
>It's a shame Apple doesn't make the Terminal.app engine available to developers.
Sigh. Add it to the pile of "things Apple really ought to open source just to give back to the community that they used to build the worlds most successful business from"
You are right that making Terminal.app open source would be a net win for everyone, but it's not going to happen. Not because Apple doesn't want to, but because there's no spare bandwidth for anyone to push for it internally.
I think one of the biggest misunderstandings about Apple is the assumption that they have massive resources available to them, therefore they must have a wide bandwidth for competent development—be that in terms of vision, design, or code. The way I see it, Apple seems rarely able to focus on more than a few things at once. They have never been able to maintain high standards across the full breadth of their product stack.
MacOS tends to get jankier and cruftier with every release. At this point it's akin to a very pretty rug that has had so much mess swept under it that it's impossible for it to lie flat.
If you've ever dealt with the back end of Apple Music (née iTunes Music Store) you'd know that it's held together with a lot of crummy, barely-maintained software that falls apart under the most trivial of circumstances. For example, their iTunes Music Producer software can't even rip two-CD sets without causing file name conflicts in the XML. This bug has not been fixed for over a decade.
Apple does have massive resources. They're one of the highest revenue companies in the world, and have way better margins than most of the higher companies in the list.
At least in the Steve Job days, they'd spin up three teams to make a 1.0 product, unbeknownst to the teams, and only ship from and keep the team that did the best.
These examples like the iTunes thing you list are them not caring, rather them not having the resources to get to it.
More precisely, I'm saying that Apple appears to suck at massively parallel use of their resources. For a company as big as they are, their cumulative output of high quality product isn't all that much. It seems they can barely keep macOS cobbled together now, let alone spin up groups tasked with shepherding individual components towards open source.
Yeah. I can understand Apple not wanting to open source everything, but open sourcing Terminal.app is scarcely going to give any advantage to competitors (or jailbreakers, or Hackintoshers, or malware authors, or whoever else the folks at Apple who make these kinds of decisions worry about).
I wish Microsoft would open source some more stuff too – although they are much more open source friendly than Apple, especially in recent times. How about open sourcing cmd.exe? Likewise can't see how that could cause any harm. If they did that I'd be eager to send them some PRs (e.g. add a configuration option to suppress the "Terminate batch job (Y/N)?" prompt.)
The GPL can restrict your freedom. All licenses which contain restrictions "restrict freedom" by definition. The actual question is whether the GPL license restrictions come into conflict with any freedoms YOU wish to exercise, such as the freedom to distribute modified binaries without releasing source code.
Alternatively you could argue that the mere existence of any software—regardless of its license—can only be additive to freedom and can never be subtractive of it. Under this view it is impossible to have "less freedom" because Terminal.app exists; you've merely identified a scenario where you could have more freedom than you do right now.
It's open source, so that limitation isn't a permanent state of affairs. I dare say the active maintainers might be interested in any features which are currently supported by Terminal.app.
Is anyone using this, a quick howto would be most appreciated. I went to CP/M sites and mainly found ARK files for the main software. Do I need to uncompress this into a directory and pretend it's a floppy drive? The github just talks about dragging and dropping of individual files.
I stumbled across his YouTube channel a few days back where he demonstrates this and lots of other retrocomputing gubbins. Worth a watch: https://www.youtube.com/user/80Thom80
Anyone know how to run this on Big Sur? I've built the project and it runs but there's no terminal window and the New menu item is dim. I looked at all the forks but most are very old. I guess I need a CP/M disk image?
Did a little searching but did not see a specific version of the old ASCII Star Trek game for CP/M. I see BASIC for CP/M so I presume you could enter Star Trek that way....
Except for one that was sitting in a corner of the main office, which I noticed was running CP/M-68K.
I asked around and found out that this was for the accounting people. It wasn't because they needed some accounting software that wasn't available for Unix. Everything they were interested in could easily be done on Unix.
So why did accounting choose CP/M-68K?
Because they assumed (correctly, it turned out) that in a company where all the engineers were Unix kernel hackers, running CP/M would keep all the engineers from messing with accounting's computer.
[1] https://en.wikipedia.org/wiki/Callan_Data_Systems (BTW, Wikipedia says Callan was founded by Dave Callan. That's only partially correct. There were actually three equal founders. They could not agree on a name for the company, and it got to the point where the only thing stopping them from starting was having a name to put on the paperwork. One weekend the other two founders went away on a hunting trip, and when they came back Callan told them he'd picked a temporary name and filed the paperwork, and they could change it to the real name later when they came up with one. They never did agree on a "real" name, and so the company retained Callan's "temporary" name, Callan Data Systems).