[somat]

As someone who missed that era, a question about cp/m.

Most machines had some sort of basic rom, why was that not the preferred command processor, basic is not that great, but it provides for a much richer command environment than cp/m or dos. What was the advantage of cp/m?

I am approaching from the context of the unix shell, an operating environment rich enough to program in. I don't know what scripting was available on cp/m but dos scripting with batch files was a miserly unpleasant thing in comparison. But then I think about how all those early home computers had a BASIC rom, why did that not evolve into a BASIC shell? it would have been a much nicer environment than cp/m.

[retrac]

CP/M software was (somewhat) portable. That was its killer feature. A program coded in 8080 assembly that closely adhered to the CP/M API, would run on any 8080 machine that could run CP/M. Anyone with the hardware skill could build a CP/M compatible computer, no coding required beyond a bootloader and tweaking the CP/M BIOS (low level driver code). There were dozens of manufacturers of CP/M machines. On the other hand, there was no standard BASIC common across all those machines, besides MS BASIC, sort of.

On proprietary systems, BASIC shells were a thing. Both DOS and ProDOS on the Apple II hooked into the ROM BASIC interpreter.

[donatj]

Just to add a little detail, MS BASIC’s capabilities varied pretty widely across versions and machines, and it wasn’t helped that Commodore had gotten a sweet heart deal on MS BASIC in 1977 that included no royalties and as such they never upgraded the version of MS BASIC - as that would involve giving the now much bigger and more apt Microsoft another whack at the terms.

[InterNautic]

Yes, this is why "it can run CP/M" is popular "form of bragging" among modern homebrew computers builders.

[fsckboy]

cp/m had tools for using floppy disks (and so did ms-dos) being able to save your work to a floppy is basically a necessity. There were "encode your data/programs onto a cassette" and some paper tape, but those were incredibly inconvenient. . To use floppy disks you needed to format them, have some notion of a filesystem, be able to DIR and COPY files, and programs like word processors needed a way (a standard way, a single way, etc.) to talk to the disk to open and save files. That's what cp/m did.

cp/m from the user perspective (command line) was something of a knockoff of Digital/DEC command lines similar to RSTS or RSX-11 (probably RT-11 too? never used it)--PIP ftw! These are somewhat similar to MSDOS command lines. Unlike unix "everything is a file", these operating systems had the notion that "everything's a device" (like MSDOS things with colons, CON: AUX: LPT(?): etc., and sometimes "we'll provide the baling wire so different devices can talk to each other but it's not guaranteed", COPY A:FILE LPR:

PIP (peripheral interchange program) was the workhorse that actually did it all underneath, PIP A:FILE.DOC LPR:/COPY to extend the example above. I think that they actually may have put DEST: before SOURCE: and maybe DEST:=SRC:, and maybe the /COPY had to be on the dest, i don't remember, but for this purpose it's "eh"

basic does not offer anything like that. It could have, but for whatever reason, nobody thought to add those features, they were probably thinking more along the lines of "we're in ROM, why would we need a floppy? feature!"

[hulitu]

> cp/m had tools for using floppy disks

Floppy disks were very expensive. And needed an additional expansion board which was also expensive. Cassettes : everybody had one.

> basic does not offer anything like that

It had LOAD and SAVE as far as i remember.

TBH i think the speed of loading programs (from floppy) made a bigger difference than a "command interpreter".

[karmakaze]

The CP/M machines I've used (z80) weren't so personal. They typically ran off the shelf software. I recall using dBase II on a Xerox machine.

The machines that came with BASIC could be personal (Atari) or business focused (TRS-80) and did make for a good default prompt. Often the storage subsystem needed a DOS-like part not included with Basic which may only have supported cassette data storage out of the box.

[TedDoesntTalk]

It seemed all of the I/O access on 80s BASIC machines was proprietary or at least not standardized.

[monocasa]

A surprising number of these BASIC interpreters were ports of Microsoft BASIC so there was more consistency than you might think. That's how they made most of their money prior to buying the Quick and Dirty Operating System (QDOS) and turning around to sell it as PC-DOS 1.0.

https://en.wikipedia.org/wiki/Microsoft_BASIC

[karmakaze]

Even the Atari BASIC cartridge/ROM was supposed to be MS BASIC[0] but it didn't fit in the 8K ROM leaving any room for additional interfacing with the machine. MS BASIC was still offered separately.

I'm glad for the Atari version. Although it was less powerful, it was enough taking less space and running faster. An Integer Basic like on the Apple would have been great to have too.

https://en.wikipedia.org/wiki/Atari_Microsoft_BASIC

[flohofwoe]

CP/M was essentially THE compatibility standard for business software before DOS. If you wanted to run a professional text editor or database before the PC and MS-DOS era, it pretty much had to be CP/M.

UNIX was of course much more powerful, but didn't run on cheap 8-bit computers. And some home computers also offered CP/M compatibility as an add-on (for instance here: the Amstrad CPC booting into CP/M: https://floooh.github.io/tiny8bit/cpc.html?file=cpc/6128sp_4...)

And the whole reason why Commodore added a second CPU to the Commodore 128 was CP/M compatibility, that's how powerful the "lure of CP/M" was at the time.

[rwmj]

CP/M is essentially a small command processor ("CCP") which loads whatever command you type, and even the simplest CP/M 2.2 had a lot of useful commands. PIP, directory listings, editor, assembler and debugger.

So CP/M was a lot nicer than BASIC, and if you didn't like it you could just ... run MBASIC.COM and get BASIC.

[guessbest]

Most BASIC distributions did't save state and it didn't have an online help, meaning it wasn't on the system. So, if a user was going to have to look up commands then they were more likely do so through another program, necessitating have BASIC not in the ROM but on the filesystem. This way a user could still use BASIC and load/edit the program from a file on a floppy.

[Gordonjcp]

You're not comparing like with like.

BASIC was a very slow and limited programming language.

CP/M was a disk operating system.

If you wrote programs in BASIC you could only save them painfully slowly on cassette tape, and maybe if you were lucky you could get them to load back in again. You couldn't really write useful programs in it because it had no concept of functions and a very vague idea of subroutines, and there wasn't really an editor or debugger. You couldn't load or save data files except as raw binary copies of what was in memory. Latterly some home computers like the Commodore 64 got crude disk drives, which were only a little faster and about as reliable as tape, and still couldn't really work the way we use files now.

By comparison, CP/M was more like MS-DOS in that it was a thin command interpreter that would load and run programs in memory, which could then be used to do useful stuff. In the Olden Days I used a CP/M machine to write firmware for Z80-based machine controller boards. On one floppy I had the editor, assembler, debugger, and a few other tools, and on the other floppy I had the assembly source code and object code output. Although the computer with its whopping 64kB of RAM and 256kB per floppy disk could only run one program at a time, it only took a few seconds to load the editor and the working file, and run a SUBMIT job (similar to an MS-DOS batch file) to assemble and link the code.

Pretty much all serious development was done in assembler then although there were some daft old gits who still held onto PL/I, and you could get Turbo Pascal for CP/M. There was even talk of buying a C compiler, like that C stuff they use on big Unix systems, and using a thumping great Tandon 386 with Xenix on it as a shared development machine, with 2MB of RAM and a 40MB hard disk! I left the company before they brought this in though.

BASIC is an interesting enough language, but it was inherently too limited to evolve into much without an underlying OS. CP/M required the machine running it to have a BIOS ROM with a boot loader and the machine-specific code in it to handle the hardware, which would be about half the work of the BASIC ROM.

If you want to see an interesting contrast in 80s home computers see what you can find about the Jupiter Ace, which was a Z80-based computer that ran Forth instead of BASIC. Forth would have been a far better starting point for a general-purpose OS, being essentially compiled into bytecode (really just a list of addresses of words) and run by a very simple "interpreter" that loops over the bytecode. Later on Sun would use Forth as part of OpenBoot, where it made its way into PowerPC-based Apple machines.