[musicale]

> There's no reason to repeat the mistakes Intel made in the 01970s today. We know how to do better!

CP/M, WordStar, and Turbo Pascal were/are pretty good though!

As you suggest, someone really should port an open source FPGA toolchain to Oberon to honor Prof. Wirth's great work.

[kragen]

I agree about WordStar and TP. You can kind of justify all of CP/M's problems by reference to the limits of the machines it had to run on (for example, they often had no real-time clocks), but I still think you could do better in many ways. For example:

- The command processor didn't have to be so limited, as amply demonstrated by ZCPR, or so hard to use, as demonstrated by the p-System.

- Record-oriented file access was probably a mistake. The 128-byte record size meant that you still had to use 2-byte record numbers to get files of over 32K, and that writing a single record required wastefully reading a whole 512-byte sector in order to not lose the other three records in the sector. Byte-based file access would have been far better for the usual case, even at the expense of needing 24-bit seek offsets for very large files (over 64K). This would have to be built on sector-based access, but the intermediate layer of record-based access is purely dead weight for most applications. Sector-based access (or access in larger blocks as in Forth) would allow you to use 1-byte sector numbers until the advent of double-density disks.

- Using different BIOS calls to write to the terminal, the printer, and the paper tape punch was obviously a mistake, and one that made it very difficult to extend the set of available devices. I believe HDOS did a better job here. Moreover, if you adopted byte-based file access, you could use a single BDOS call to write to a file, the terminal, the printer, or the punch, and analogously for reading. This also would have made it easier to support multiple terminals.

- The user interface of ED was stuck in the teletype era. But almost nobody ran CP/M on a teletype, because teletypes cost more than CP/M crates. Before long most CP/M machines had a monitor built in, like the Kaypro, Osborne, and H-89. Even BASIC-80's unusably bad line editor gave you a live display of the line you were editing, and WordStar demonstrated that it was possible to do much better on the same hardware.

- The "user" facility in its filesystem was useless.

So, I'm not a huge fan of CP/M. I think virtually all of its major design decisions were mistakes, except for the BIOS/BDOS split, though not such serious mistakes as to make it completely unusable. I'm interested to hear why you disagree so strongly.

[stevekemp]

Interesting that you picked out the use of different API calls for writing to terminal, printer, and the tape. There was at least an attempt at unifying that with the "IOByte" configuration.

The idea was that depending on the state of the IOByte the actual destination of "stuff" could vary.

Of course in the CP/M emulator I wrote/maintain I ignore that byte, because it turns out everybody else did too. (Kinda like user-numbers/areas, most people ignored them.)

[kragen]

Aha, thanks! I didn't know about that!

[musicale]

> I think virtually all of its major design decisions were mistakes, except for the BIOS/BDOS split, though not such serious mistakes as to make it completely unusable. I'm interested to hear why you disagree so strongly.

"Pretty good" isn't the same as "perfect". All of your comments seem completely reasonable. But that BIOS/BDOS design made CP/M a minimum viable portable OS that enabled binary software portability and created an ecosystem across 8-bit hardware from many vendors (not to mention homebrew), starting in 1974. The closest things to it in that space were Microsoft BASIC (with many incompatible versions) and the UCSD p-System, as you note. So I rate CP/M "great" in terms of its industry innovation – specifically how it applied technology to develop a successful 8-bit PC compatibility standard, providing a model for the 16-bit era of DOS and IBM PC compatibles.

Years later, Linux seems to be stuck with multiple, incompatible formats for binary software packaging (snap, flatpak, appimage, docker, win32...) Though I guess you don't have to worry about different sizes of floppy disks.

[kragen]

I just found Tim Paterson's article at http://dosmandrivel.blogspot.com/2007/09/design-of-dos.html?... which says my comment above got an important thing wrong: the sector size on 8" disks was typically 128 bytes, so CP/M was reading per sector. He mentions that North Star DOS used 256-byte sectors. I'm pretty sure the logical HDOS sectors on my H-89 5¼" single-density floppies were 512 bytes, but I've never interacted with the low-level format of the disks. They were 100K per side, 10 sectors per track (with 11 holes punched in the disk to indicate their positions), which I guess would imply 20 tracks, which sounds too low! Maybe the physical sectors were 256 bytes.

https://heathkit.garlanger.com/diskformats/HDOS_Disk.pdf confirms: 256 bytes, 10 sectors, 40 tracks.

Paterson's article explains why he copied the FAT filesystem from Microsoft BASIC but extended the cluster numbers to 12 bits. He also has some pretty damning criticisms of both the CP/M filesystem design and its BIOS interface.

[musicale]

Great reference. I didn't realize the FAT filesystem was from Microsoft Disk BASIC (though I knew it was different from CP/M's) so I guess it came back full-circle with DOS. (Though perhaps not directly compatible with Disk BASIC's FAT8 filesystems.)