Honestly, any deep dive into the CP/M BIOS/BDOS architecture should suit you.
It's really quite basic.
The BDOS was common across platforms, with the machine specific BIOS acting as the interface layer between the BDOS and the raw hardware. The BIOS deals with all of the interrupts and shoving values in and out of I/O ports (or addresses) hoping the hardware behaves.
A better approach would be to compare things like CP/M, FLEX for the 6800, and even TRSDOS for the TRS-80. CP/M and FLEX are similar in that they're "generic" OSes for different hardware. TRSDOS is interesting because the DOS offered actual system services.
These are more interesting than the ROM based "OS" of things like the C64 and Atari. For example, the C64 doesn't really have a "DOS", it has a smart peripheral that you connect to over a serial interface and send commands. The "DOS" is actually implemented on the disk drive, not the host machine. Similarly with the Atari, it had a very nice device driver level abstraction, but that was as far as it went.
The novelty of this project is the relocatable binary loader. CP/M didn't have one of these (it didn't need one). The memory maps of the various 6502 machines are quite varied. Having large chunks of the RAM mapped to video displays didn't help matters much. And all of the systems were pretty fast and loose with low memory.
CP/M needs, like, 16 bytes of low memory "committed" for the OS, then everything else is shoved to the end in high memory. The 8080/Z80 used I/O ports compared to the 6502s memory mapped I/O (yet more holes in the 6502 memory map).
To be fair, the TRS-80 has a much different memory structure than a random CP/M machine. CP/M machines were designed FOR CP/M, but the BIOS let them have all sorts of flexibility for disk drives, I/O and other hardware. Out of the box, raw CP/M can not run on the early TRS-80s, lower memory simply isn't available.
It's really quite basic.
The BDOS was common across platforms, with the machine specific BIOS acting as the interface layer between the BDOS and the raw hardware. The BIOS deals with all of the interrupts and shoving values in and out of I/O ports (or addresses) hoping the hardware behaves.
A better approach would be to compare things like CP/M, FLEX for the 6800, and even TRSDOS for the TRS-80. CP/M and FLEX are similar in that they're "generic" OSes for different hardware. TRSDOS is interesting because the DOS offered actual system services.
These are more interesting than the ROM based "OS" of things like the C64 and Atari. For example, the C64 doesn't really have a "DOS", it has a smart peripheral that you connect to over a serial interface and send commands. The "DOS" is actually implemented on the disk drive, not the host machine. Similarly with the Atari, it had a very nice device driver level abstraction, but that was as far as it went.
The novelty of this project is the relocatable binary loader. CP/M didn't have one of these (it didn't need one). The memory maps of the various 6502 machines are quite varied. Having large chunks of the RAM mapped to video displays didn't help matters much. And all of the systems were pretty fast and loose with low memory.
CP/M needs, like, 16 bytes of low memory "committed" for the OS, then everything else is shoved to the end in high memory. The 8080/Z80 used I/O ports compared to the 6502s memory mapped I/O (yet more holes in the 6502 memory map).
To be fair, the TRS-80 has a much different memory structure than a random CP/M machine. CP/M machines were designed FOR CP/M, but the BIOS let them have all sorts of flexibility for disk drives, I/O and other hardware. Out of the box, raw CP/M can not run on the early TRS-80s, lower memory simply isn't available.