4 ms·

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

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.

musicale 2y ago
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.
RetroTechie 2y ago
> 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?
- schlopper 2y ago
  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?

musicale 2y ago

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.

RetroTechie 2y ago

> 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?

schlopper 2y ago
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?