Comment by schlopper | Hacker News Reader

Comment by schlopper | Hacker News Reader

Having just completed a CP/M 3.0 BIOS for my homebrew Z80 machine, I am in awe at the amount of planning and foresight that went into it. The fact that you can write a piece of custom code in 2024 (for hardware that didn't even exist back then) and link it with the Digital Research binaries from the 70's to have a fully-functional and compatible O/S that is able to run almost any software written for CP/M in the past 40 years is just crazy.

Unlike CP/M 2.x, CP/M 3 allows for banked memory and disk data/directory buffers, resulting in a lot more usable memory for applications (Transient Program Area) and faster disk access. Although with an SD/CF card, the CPU is more the bottleneck than the disk I/O.

The project was both nostalgic and informative - trying to maintain performance while counting every byte of code has shed some great insights into low-level O/S design.

> Unlike CP/M 2.x, CP/M 3 allows for banked memory and disk data/directory buffers, resulting in a lot more usable memory for applications (Transient Program Area) and faster disk access.

Sounds a lot like what MSX-DOS 2.xx does as compared to its predecessor.

FYI: both versions of MSX-DOS are partially CP/M compatible, such that a # of applications running on it are slightly- or unmodified CP/M programs. Not unimportant given how much quality CP/M software already existed in early '80s.

One oddity resulting from this: some OS calls read or write files in multiples of 128 byte 'records' (regular MSX-DOS calls do handle exact file sizes though). Just guessing: sector size of ancient 8" floppies, or something like that?

Interesting - CP/M has a fixed sector size of 128 bytes. In CP/M 2.x, if your physical sectors were a different size, you'd have to implement deblocking code in your BIOS. CP/M 3.x still used 128 byte sectors, but supported specifying the physical sector size and would do the de-blocking for you.

I'm guessing MSX-DOS uses the 128 byte records/blocks to make it easy to read foreign disks and to be able to create disks readable on other platforms?

Sounds like a really fun project.

At least on HN, CP/M (and Gary Kildall) seem to be getting their due.

I think it may be time to try out RunCPM.

Reply on news.ycombinator.com