CPM BIOS, BDOS, CCP layout on Disk vs RAM

Can someone smarter than I, please clarify the CCP, BDOS, BIOS disk vs RAM layout, for both CP/M 2.2 and 3.0? So here is what I always understood (CP/M 2.2 Manual section 6, CP/M Alterations):

CP/M 2.2
CPM.SYS contains CCP+BDOS+BIOS
DISK drive 0, side 0, track 0, sector 1: bootloader
drive 0, side 0, track 0, sector 2: start CCP+BDOS+BIOS end
RAM (booted): lower-end CCP, BDOS+BIOS higher-end

CP/M 3.0
CPM3.SYS contains BDOS+BIOS
CCP.COM separate file
DISK drive 0, side 0, track 0, sector 1: bootloader
drive 0, side 0, track 0, sector 2: start BDOS+BIOS end, next file CCP.COM
RAM (booted): lower-end CCP, BDOS+BIOS higher-end

CP/M 2.2 boots by loading:
CCP follows from disk to RAM starting at CBASE to FBASE-1
BDOS follows from disk to RAM starting at FBASE to FBASE+3.5K
BIOS from the start of the disk to RAM starting at FBASE+3.5K+1 to HIGH

CP/M 3.0 unbanked
it is similar to CP/M 2.2 but with different locations/size limits.

CP/M 3.0 banked
BNK0 is loaded with resident CCP, BDOS+BIOS
BNK2 is loaded with banked portion of CCP, BDOS+BIOS

Clarification Questions:
1) CP/M boot process reads the sequential disk layout of CCP+BDOS+BIOS and reorders them to (CCP, BDOS, BIOS) in high memory, right?
2) The bootstrap, usually in ROM that loads bootloader d0, h0, t0, sector1
3) bootloader loads CCP+BDOS+BIOS from disk, right?

CP/M eligant memory layout easily allows the TPA to overlay CCP and then reload CCP later.

I have recently read that the disk layout of the boot track is BIOS+BDOS+CCP which I'm doubting its correctness, hence this discussion. Thanks.

It’s been a while but IIRC BNK1 is loaded with banked portion of CCP, BDOS & BIOS.
Plus the disk images are sysgen’d backwards (last sector first) onto disk so the bootloader loads to high memory down to the bottom of the BDOS (or CCP).

geowar1 said:

It’s been a while but IIRC BNK1 is loaded with banked portion of CCP, BDOS & BIOS.
Plus the disk images are sysgen’d backwards (last sector first) onto disk so the bootloader loads to high memory down to the bottom of the BDOS (or CCP).

Click to expand...

Hence my confusion when I recently read the sysgen "inverted" image on disk, yielding a boot track effectively BIOS+BDOS+CCP.

Yes, it has been a while and as more 8bit newcomers discover the joys of CP/M, this might help them as well.

For CP/M 3, typical memory layout is that banked and resident BDOS and BIOS are in "bank 0" (bank 0 + common) - this is done for convenience in booting, as most machines power-up or RESET to bank 0 being selected. The CCP and user programs (TPA) are in bank 1 (plus the unused part of the common memory up to RESBDOS). RESBIOS is in the highest part of common memory, RESBDOS is directly below that (also, the SCB is in there). Starting at the top part of bank 0, you have BNKBIOS and then BNKBDOS. Below BNKBDOS is typically used for buffers and/or storage of CCP.COM for faster warm boots. Other banks are used as configured by GENCPM (or the BIOS). CPM3.SYS contains the system image, in the format described by the manuals.

CP/M 2 has the BIOS in the highest part of memory, then the BDOS directly below that, and the CCP (transient) is below the BDOS.

The details of booting the OS from ROM depends on the system architecture. This can also dictate how the initial OS boot image is stored on disk, but typically it is in the "boot tracks" (defined by the "offset" field of the DPB) and is in the same layout as it will reside in memory (straight load). Note that CP/M 3 is booted by first booting a "read-only CP/M 2.2" system image (typically on boot tracks) that then reads the CPM3.SYS file and loads that. The exact details can vary depending on the system type. Some systems do not reserve enough space in the boot tracks, and some portion of the OS image will reside elsewhere. Sometimes, a "CCP.SYS" file will be used, so that space for the CCP is not need in boot tracks. I've also seen where part of the BIOS is stored in extra, reserved, directory blocks. Many other possible solutions exist.

Some systems will load a bootstrap routine off the first one/two/few sectors of the disk, which then has the code to load CP/M. Some systems have a "header" in sector 0 that directs where/how to load CP/M (within limits). Some systems just assume the OS is always loaded at the same address and the OS image begins at sector 0. There are probably many other ways.

CP/M 2.2 can be loaded as an image also... So it doesn't really matter how it gets into memory, as long as it gets there... It's entirely possible to load the BIOS/BDOS straight from ROM, since CP/M 2.2's BDOS and CCP are identical on every system. Only the BIOS changes.

I load my own CP/M compatible OS from ROM, and even though it's not CP/M, it still works if I replace it with CP/M and even then I still pull the CP/M BDOS/CCP from ROM as a ROM disk when desired and drop them into memory, then update the zero page vectors.

There are a lot of ways to do it, but generally CP/M 2.2 needs a way to reload the CCP when a warm boot is performed.

Amstrad PCW also does not have a ROM at all, but loads everything ( including the BIOS, Bootstrap and CRTC initialisation software ) from Track0 of the boot disk... It literally executes code straight from the boot disk on cold boot.

Yes, lots of different ways to boot - especially factoring in modern systems where you have more ROM storage than legacy floppy disks had. Digital Research did not specify how the system was booted, except for the case of CP/M 3 (or MP/M) where there was a loader program to "boot" the CPM3.SYS or MPM.SYS file. But in those cases, you still had to boot the loader program. Even the CP/M 3 and MP/M loader programs could be built to run as a normal program (in the TPA) under CP/M 2.2 (e.g. you boot CP/M 2.2 "normally" and then run "cpm3ldr"). Digital Research just defined the layout of memory - and even that was potentially subject to some customization as long as certain rules/relationships were followed.

Thank you all for a great discussion, I am so glad to learn about the various booting methods, do to DRI flexible design.

Doug, I knew about CPMLDR stored in track 0+1 but never realized it was a special CP/M 2.2. Always learning, happy learning...

durgadas311 said:

CPM3.SYS contains the system image, in the format described by the manuals.

Click to expand...

Doug, thanks for pointing me in the right direction. CP/M Plus System Guide Jan1983, Appendix D on page 115, it shows the CPM3.SYS file format.

Record 2-n: "CP/M 3 operating system in reverse order, top down."

Please forgive me if I am restating the obvious, but I am trying to confirm what I understand.

For a non-banked CPM3.SYS:

For a banked CPM3.SYS:

CPM3.SYS is created by GENCPM.COM

CPMLDR.COM, it is stored in normal byte order from low to high and it embeds LDRBDOS followed by LDRBIOS, correct?

Now, for CP/M 2.2 CPM.SYS is stored in normal byte order from low to high as CCP, followed by BDOS, followed by BIOS, correct?

For CP/M 3, typical memory layout is that banked and resident BDOS and BIOS are in "bank 0" (bank 0 + common) - this is done for convenience in booting, as most machines power-up or RESET to bank 0 being selected. The CCP and user programs (TPA) are in bank 1 (plus the unused part of the common memory up to RESBDOS). RESBIOS is in the highest part of common memory, RESBDOS is directly below that (also, the SCB is in there). Starting at the top part of bank 0, you have BNKBIOS and then BNKBDOS. Below BNKBDOS is typically used for buffers and/or storage of CCP.COM for faster warm boots.

Click to expand...

Clear, clear and clear. I have always misunderstood Figure 1-5 on page 8 of the same System Guide. I have found it confusing and the "COMMON MEMORY" label seems to float above BANK 0; your clarifications points it to right, center column above the "tear off" BANK 1. I wish there was more space separating the top "tear off" Common Memory from Bank 1.

Thanks for clarifying the confusions.

Technically, "common memory" is not part of any bank. But generally it is what the system resets with and never changes.

I'm not familiar with your CPM.SYS file, that must be something that a particular vendor did. That may only be part of the OS, or might not even be what boots (i.e. it might be what is used to write to the boot tracks during sysgen). It is hard to tell without more information.

Note that for CP/M 3 there is a gap (in almost all cases) between the RESBDOS and the BNKBIOS. The loader uses "top of memory" and "common memory boundary" to orient those components in memory. Top of memory is almost always "00" which represents a full (64K) system (plus banks). Then there is the common memory boundary, for example "C0" for a system that has 48K banks, which is where the loader orients BNKBIOS (and BNKBDOS below it). The area between the lowest byte of RESBDOS and the highest byte of BNKBIOS (common memory boundary) is part of the TPA, the rest of which resides in bank 1.

The loader image is typically 3 blocks: the loader program, the loader BDOS, and the loader BIOS, in that order from low to high memory. The exact location in memory that it runs depends on the system. The file is typically that exact image, although it might vary depending on how it is being used.

Thank you all who replied, I have read all the manuals before but I never got the boot process. I finally understand the mysterious booting process; CP/M 2.2 and CP/M 3. Elegant yet simple. Thank you all again. Jim

JimA1 said:

...for CP/M 2.2 CPM.SYS is stored in normal byte order from low to high as CCP, followed by BDOS, followed by BIOS, correct?

Click to expand...

CPM.SYS appeared in my personal notes that I took a while back. So when smarter people than I point out a discrepancy, I doubt my own notes and sends me searching for the manuals. CPM.SYS is not mentioned in any DRI CP/M Plus, any CP/M 2.2 nor earlier manuals; and neither mentioned in any of the vendors manuals for CP/M 2.2.

durgadas311 said:

I'm not familiar with your CPM.SYS file...

Click to expand...

CPM.SYS does appear in the DRI CP/M-86 System Guide June1981 in Section 1 on page 1 (PDF page 8) as the file is loaded during the Cold Boot process. Apparently CP/M-86 boots in a similar fashion to CPM 3.0; since they both are banked CPM. So, the Cold Start Loader resides in the system tracks (track0+1), which loads CPM.SYS; CPM.SYS contains CP/M-86's CCP, BDOS, and BIOS. Please see the same manual, section 7 pages 81-84 for the LOADER, pages 84-86 for the CPM.SYS.

So, I stand corrected, CP/M 2.2 does not have CPM.SYS but simply the system tracks 0+1 contain the memory image of CCP+BDOS+BIOS written to disk from low memory addresses to high memory addresses.

Thanks again to all who replied for your clarifications and help shedding light on the Cold Boot process.

JimA1 said:

So, I stand corrected, CP/M 2.2 does not have CPM.SYS but simply the system tracks 0+1 contain the memory image of CCP+BDOS+BIOS written to disk from low memory addresses to high memory addresses.

Click to expand...

Because the system tracks (often 0+1, but that depends on the disk format) may be too small to contain the final memory image, some implementations use a CCP.SYS (or some other file) which replaces the booted CP/M with a more advanced version (for example, a larger BIOS with additional disk formats).

Other systems use completely different methods of booting. For example, I've created a version which is loaded and relocated from the native ROM-based OS. How CP/M makes it into memory does not matter, it's only important that it eventually does. Using tracks 0+1 is one possible approach documented by DR.

Also, DRI shipped a "reference implementation" (Intel MDS-80?) and created the de facto-standard 8" SD floppy format of CP/M. That format had two "reserved tracks", which is where they chose to put the OS for booting. I don't know whether the MDS-80 booted using a small bootstrap routine on the first sector of track 0, or something else. This was how the first CP/M system worked, and so it became the template for many others that followed. The idea of booting from the first N sectors of a disk goes back long before CP/M, though.