• Please review our updated Terms and Rules here

CP/M 2.2 vs 3.0

M

MykeLawson

Experienced Member
Joined
Mar 21, 2014
Messages
382
I'm sure there are many of you that have put together a system using the S100computers.com boards, and I am now in those ranks as well. My current Z-80 STD bus system is running CP/M 2.2, but my new S-100 Z-80 system is going to run CP/M 3.0. I'm just wondering if anyone has a list of some of the most obvious, or commonly encountered differences in how the two operate in a system. Since most all of the code I write is standalone, the most glaring concern is over TPA being the same; as in it still being 0100H? Or any of the common 'gotchas' I should be on the lookout to avoid. Thanks
 
Shouldn't matter to basic CP/M 2.2 functions, in my experience. CP/M 3 is mostly additions to the 2.2 API and some support for bankswitching memory and time and date support for time-stamping files.
 
Programs that want to take advantage of CP/M 3 can make the BDOS call 12 (get version) and switch between features based on that. But programs written for 2.2 should run just fine on 3.0 - provided they are not "cheating". TPA is typically larger on 3.0 systems, but the same rules apply for finding the end of the TPA - the JMP at 0005h has the address. Programs that directly examine the directory entries need to take into account that possible entries for disk label and timestamps, if those have been enabled. But, those entries generally appear as "used but not as files" - provided the program is properly looking at the first byte of each entry. One difference is that the CCP is no longer below the BDOS, but rather runs at 0100h just like other programs. This has implications for procedures that assume 0100h is left untouched during warm boot. Direct access to the BIOS is also not recommended, instead use the "direct BIOS call" BDOS function.

What do you mean by "standalone"? If you mean that the program has no dependencies of what runs before or after, that covers the CCP being loaded at 0100h. If the program is "standalone" meaning it does not depend on any OS, that is another story.
 
when i setup my system i looked at both CP/M 2.2 and 3. many of 3's features would not work on my system. the only slight advantage might have been the slightly larger TPA space for programs.
but 2.2 had so many hacks and changes and software available that it made sense to build the best version of 2.2.

having now assembled an amazing 2.2 system with either 5mb or 8mb duel hard drives, i see no reason to go to CP/M 3, at this point its would be switching to a more limited system.
 
My take on the CP/M 3 from CP/M 2.2 issue is mostly one of taking advantage of RTC and bankswitched memory. If you don't have those, it wasn't worth it, at least in terms of general commercial productivity products. Apparently, among commercial system vendors, this attitude was not uncommon.

Management elected not to make the leap--and we'd already done an XIOS for MP/M, so it wouldn't have been a great deal more effort to host CP/M 3.
 
CP/ 3 (the banked version) had a better user experience. Things like timestamps were good, too. And the larger TPA was very nice for software development - being able to edit larger files (without having to swap chunks in memory), and compile/assembler larger programs. The RSX feature, while technically possible on 2.2, was easier to do. Command line history and editing was nice, although there was only a one-line history. Having the CCP in memory gave you a much faster warm-boot, and the SUBMIT facility was more robust. I never ran programs that needed the CHAIN facility, but I imagine that was useful to some.
 
Another important feature of (banked) CP/M 3 is directory hashing. You need to do more than the minimal (128K) RAM size, though. Hashing greatly improves access to drives with large directories (HDD). RAM disk is less important on "modern" retro systems, if you are using SSD (CF or SDCard).
 
I went with CP/M 2.2 over 3 because it was simpler to understand 2.2 and it seemed like it would be easier to write a 2.2 compatible OS without prior experience. Since then, I've learned enough probably to tackle CP/M 3 now, but even without knowing much about it, from what I have learned over the year it now feels like a technological dead end.

I don't know of any software I want to try that used CP/M 3, and 2.2 seems the most common. I've had no trouble adapting 2.2 to larger architectures, including effective ways to use memory and even use the BDOS as a defacto memory manager. It works beautifully when you converge memory and disk into a single architecture like that. Likewise, no problems with boot speeds, and you can more easily fit CP/M 2.2 into a BOOT rom to make for diskless startup and support for other OS anyway.

If your code is standalone, then CP/M 2.2 is probably just fine, since all you need to do is load it up at 100h and execute it. Unless you need extra memory and you want the OS to handle it, you might as well just page any extra memory from your own architecture directly.
 
The main reason for going to CP/M 3 was for user experience, not for programming experience. Since it is pretty rare that anyone actually does real work on these machines any more, the appeal of CP/M 3 is lost on most. It really depends on why your are running a retro computer. CP/M 3 might be a checkbox, depend on why you are here. But retro computing in general is all about technological dead ends. Digital Research was already off to the 16-bit (and 32-bit) worlds, and CP/M 3 was simply their last set of improvements before putting the 8-bit world to bed. Everyone knew that at the time, but customers continued to use 8-bit computers for quite awhile after that - and that was DRI's goal: to extend CP/M-80's life just a little longer (at least to give 8-bit customers an option - if the vendors chose to include it). Historically, it was the last version of an 8-bit OS from DRI, and so it has earned a place in retro computing conversations. If you are here to experience what it took to "stand up" (port) CP/M on a new platform, then CP/M 3 represents a unique sets of "challenges" and thus is a worth looking at. If you are actually doing "real work" or trying in some way to experience what users experienced back then, then CP/M 3 also has a place in that. But modern retro computing enthuseists, like some 8-bit vendors back in the day, may choose to ignore it.
 
@durgadas311 , Don't get me wrong - I don't dislike CP/M-3 - I have three CP/M machines I love.... My ZX Spectrum, An Amstrad CPC6128, A PCW8256, A PCW8512, A PCW9256 and a PCW9512 and a Bondwell 16... OK, that's maybe a bit more than 3.

And learning about them is fun.

I get the feeling though that Myke's project is more traditional. And it seems like the path to going to CP/M 3 is to start with 2.2 and then move that way. Your suggestion may well appeal to him from that basis. And starting straight with 3 is a lot harder as there's more to consider. That's why I made my original decision to start with 2.2 which I was reflecting upon. Later, I just kept going that way.

But now you have me curious.

Myke - I'd love to hear more about where your project is heading and why the 2.2 and 3 question came up?
 
Well, my first project, that I now just write code for from time to time, is an STD bus Z-80 @ 2MHz running CP/M 2.2. You all have helped me many times figure things out. My new project is an S-100 bus system with boards from S100computers.com which has the ability to run CP/M 3. So; why not..... And in the middle (sort of) will be a 'file server' for the two machines to interact with. Date, time, directory, delete, save, and load. And there will be an RS-232 interface between the two CP/M machines. Why? Because I can, and I have never done this stuff in well over 30 years.

BTW, you all are welcome to any schematics I have come up with, or code I have written. Retro computing is about as 'off the shelf, open sourced' as you can get these days. I just wonder, who on this planet, will be the last one to shutdown a 8080/Z80 CP/M machine for the very last time.....
 
MykeLawson said:
Well, my first project, that I now just write code for from time to time, is an STD bus Z-80 @ 2MHz running CP/M 2.2. You all have helped me many times figure things out. My new project is an S-100 bus system with boards from S100computers.com which has the ability to run CP/M 3. So; why not..... And in the middle (sort of) will be a 'file server' for the two machines to interact with. Date, time, directory, delete, save, and load. And there will be an RS-232 interface between the two CP/M machines. Why? Because I can, and I have never done this stuff in well over 30 years.

BTW, you all are welcome to any schematics I have come up with, or code I have written. Retro computing is about as 'off the shelf, open sourced' as you can get these days. I just wonder, who on this planet, will be the last one to shutdown a 8080/Z80 CP/M machine for the very last time.....
Click to expand...

Why not do both? Have a CP/M 2.2 boot disk and a CP/M 3 boot disk, and let us know which one you prefer and what you learnt? :)
 
Well, my STD machine will stay at 2.2 and I'm hoping the S-100 can be 3.0. We shall see.
 
Chuck(G) said:
Does that include file time-stamping? Using an RTC facility was one attraction for CPM+
Click to expand...
I was thinking about the file side of things also after Myke's last comment also, though that's still all the BDOS isn't it?

I would assume an "overlay" to speak of should be able to deliver the same outcomes I assume and basically upgrade CP/M from 2,2 to 3 as far as software should be concerned as long as it was hardcoded with the additional hardware rather than accessing it through a CP/M 2.2 BIOS I assume?

But it does make me wonder since I've never tried it - just how much more difficult or time consuming it is it build a CP/M 3 BIOS over a CP/M 2.2 BIOS? Asssuming it's all learning curve in both cases.
 
Time tracking in MP/M is done by setting two XDOS flags (1 and 2), from XIOS. I don't recall if CP/M 3.0 retains that functionality, or even if it cares about clock ticks.
 
CP/M 3 doesn't use any sort of IPC. The BIOS simply maintains the time directly in the SCB, from where the BDOS obtains it as needed. But generally that does not include reading the RTC chip every second (too much overhead). Usually the RTC chip is read on cold boot, and some sort of tick/timer interrupt is used to advance the time and date in the SCB. The RTC chip is also written if/when the user does a set time command. There are some programs that monitor the SCB time "seconds" field, so it is usually necessary to ensure that that field increments.
 
So how does a program know that the time in the SCB (offsets F6h et seq.) is correct/curent? Is there some mechanism that it notifies the XIOS that it's about to read the time? Seems to be a bit strange that there's no XDOS call to the XIOS to get the current/correct time. It's not necessary to have an interrupt-driven clock; one can read the current time and date from any number of different clock chips.
 
You must log in or register to reply here.
Back
Top