schlopper

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?

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.

Now now... You'd just be pandering to the separatists.

Something's off about the article:

"Authorities have seized his digital wallet"

How do you seize a digital wallet when all you need to access or recreate it is a private key (or recovery text)? What have they seized exactly?

PXE Boot w/ NFS root - you won't get the bandwidth (about 112MB/s over gigabit Ethernet), but you'll definitely see the response time improvements (IOPS + latency).

QEMU/KVM/VFIO has come a long way. If you have a MacOS-supported GPU and working IOMMU (AMD) or VT-d (Intel), then you can achieve near-native MacOS performance for your CPU/GPU combo.