1974 CP/M: In retrospect, what would you do differently?

[cjs]

I found the start of this thread interesting, but after a half page of on-topic responses, it seemed to turn into "Here's the 8-bit OS I would write in 1982" (around the time that CP/M was ceasing to be relevant, and of course using ten times the resources of CP/M), then some stuff about MS-DOS vs. CP/M, and then a long discussion about keyboard scanning and keyboard interfaces.

So I'd like to start a new thread for just the topic of: "If you could go back to 1974 and were writing CP/M then, what would you change?" If your response doesn't involve making a change to CP/M design or code in 1974, well, that other thread would be a better place for that.

It's worth keeping in mind that, whatever you're doing to future-proof stuff, you still have to deal with the constraints of the mid-70s in order to get CP/M off the ground. The original CP/M ran in 20K, with a 3.5K BDOS and a 2K CCP (and a 2K resident part of DDB). The BDOS start address with 0 bias is $3C00, giving just under a 15K TPA.) If you're proposing to change any of that, that's worth making clear.

(I'm not clear on why the most basic version of CP/M needed 20K instead of 16K, which it would seem to me that people would find significantly more affordable. Perhaps Kidall had utility programs that wouldn't run in an 11K TPA?)

 

[cjs]

Here's one of my (perhaps incompletely thought out) ideas about this: shrink the minimum memory size to 16K and assume RAM starts at $8000, and TPA at $8100. This lets CP/M work directly on systems that have ROM in low memory, greatly expanding the number of systems on which CP/M can run without hardware modification from around 1977 onwards. With luck, system designers such as Tandy would start their RAM at $8000 instead of $4000, immediately allowing their systems to be CP/M compatible with essentially no extra effort (and in particular, no bank switching) on their part. (The PC-8001 would also, in its 32K version anyway, be CP/M compatible; the initial 16K was at $C000-$FFFF, but even on the first version there were sockets on the board for a second 16K bank at $8000-$BFFF.)

As that stands it allows for a maximum 31.75K TPA, assuming the system had either RAM or ROM below $8000 in which to place the BDOS and BIOS. But we still have the issue of some systems using memory in the $F000 page for a frame buffer or similar. So let's set $F000-$FFFF as "possibly unavailable" and add it to my scheme below, giving a 27.75K TPA. When CP/M loads a .COM file, it will always load only the first $6F00 bytes of the file into $8100-$EFFF range.

So then, to be able to take advantage of more RAM, we add an API that can tell us what 4K blocks of RAM we have available at $1000-$7FFF and $F000-$FFFF. (This can be done as a simple bitmask: bit 0=4K at $F0000, bit 1=4K at $1000, through bit 7=4K at $7000.) And we add an API that, given the FCB to the .COM file (which would be left in the $8000-$80FF area below the TPA), can load an arbitrary 4K block from the the file into one of 4K blocks of RAM above, if available.

This gives us not only the ability to use more than just the 27.75K TPA, but also a basic overlay system on "larger" (>32K RAM) machines. And probably gets us through the period of 64K memory and bank switching being rare to a place a few years down the road where the standard assumption is that every machine has RAM available from $1000-$FFFF, this can easily be confirmed on any particular system, and you can fairly easily and with little code make use of all that RAM.

It doesn't really look forward to accessing more than 60K with bank switching, but perhaps with people used to this slightly more complex memory scheme from the start, some ways to extend this to bank switching would appear.

 

[cj7hawk]

Here's one of my (perhaps incompletely thought out) ideas about this: shrink the minimum memory size to 16K and assume RAM starts at $8000, and TPA at $8100. This lets CP/M work directly on systems that have ROM in low memory, greatly expanding the number of systems on which CP/M can run without hardware modification from around 1977 onwards. With luck, system designers such as Tandy would start their RAM at $8000 instead of $4000, immediately allowing their systems to be CP/M compatible with essentially no extra effort (and in particular, no bank switching) on their part. (The PC-8001 would also, in its 32K version anyway, be CP/M compatible; the initial 16K was at $C000-$FFFF, but even on the first version there were sockets on the board for a second 16K bank at $8000-$BFFF.)

As that stands it allows for a maximum 31.75K TPA, assuming the system had either RAM or ROM below $8000 in which to place the BDOS and BIOS. But we still have the issue of some systems using memory in the $F000 page for a frame buffer or similar. So let's set $F000-$FFFF as "possibly unavailable" and add it to my scheme below, giving a 27.75K TPA. When CP/M loads a .COM file, it will always load only the first $6F00 bytes of the file into $8100-$EFFF range.

So then, to be able to take advantage of more RAM, we add an API that can tell us what 4K blocks of RAM we have available at $1000-$7FFF and $F000-$FFFF. (This can be done as a simple bitmask: bit 0=4K at $F0000, bit 1=4K at $1000, through bit 7=4K at $7000.) And we add an API that, given the FCB to the .COM file (which would be left in the $8000-$80FF area below the TPA), can load an arbitrary 4K block from the the file into one of 4K blocks of RAM above, if available.

This gives us not only the ability to use more than just the 27.75K TPA, but also a basic overlay system on "larger" (>32K RAM) machines. And probably gets us through the period of 64K memory and bank switching being rare to a place a few years down the road where the standard assumption is that every machine has RAM available from $1000-$FFFF, this can easily be confirmed on any particular system, and you can fairly easily and with little code make use of all that RAM.

It doesn't really look forward to accessing more than 60K with bank switching, but perhaps with people used to this slightly more complex memory scheme from the start, some ways to extend this to bank switching would appear.

With 1974 CP/M? I probably wouldn't do too much differently.

Maybe it was overkill for the era, but putting the BIOS at the zero page would solve a lot of issues. But the original intent was to make all the memory available to the system, for whatever purposes - even if they overwrote CP/M, and you can always overwrite the BIOS too...

But in 1974, memory was so expensive, and small amounts were difficult to come by... Maybe to that extent, a cut-down version or minimal version - even smaller that CP/M 1 would be useful...

Originally, it didn't allow for video memory or anything like that, and nothing really changed through to CP/M+ there.

But by 1978, that was a very different situation and I'd do a lot differently, and in fact did in my own version of CP/M so as to remove memory limitations in a way that is native to the existing CP/M model.

Well this is about 1974... So first.

1) I'd write it all in assembly. Maybe PL/M was what Gary liked, but I'd do it in assembly.
2) I'd use 8 bit values for disk referencing. Actually, I'd go straight to logical block addressing as a 16 bit value, then increase this to 32 bits later... No Disk, Record, Track etc... And I'd increase the record size to 256 bytes.
3) I'd standardise ways to move the ROM in and out of the way, so that the BIOS calls could be made directly, and I'd just use a hook in lower memory somewhere to page it in and then call it. Slightly longer, but frees up enough RAM to be worth it. I'd also make it so that up to 64K of ROM could be installed.
4) I'd probably have used a linked list for the directory structure - as DOS did, which is a shame, because that would cut of something I would do differently in 1978 for CP/M 2.0
5) I'd make all commands execute from the disk itself.
6) I'd support interrupts and a system clock.
7) I'd still use a serial terminal for the console, but I'd do it through the ROM so that video systems could be supported.
8) I'd use the ROM for a basic CCP and even the BDOS. These never changed anyway (within the version) so why not put them in ROM? 2K ROM and 4K ROM were common. If it was made simpler, then it should be possible to fit a CCP/BDOS/BIOS into a single ROM and then CP/M is ROM boot.
9) I'd create a scratchpad RAM for the OS for Disk Access / deblocking, etc. Probably 2K. Then I'd create serial file read/write capabilities through the BDOS. I'd also support block mode, since it's possible to read instructions from a ROM and write anywhere in memory, and have both the ROMOS and System Memory paged in at the same time and co-mapped when fast-reading.
10) I'd turn CP/M into a boot system for other functions - so just enough access to get the computer started and load what comes next.
11) I wouldn't expand main memory - 64K should be enough for anyone (in 1974)
12) I'd extend the BDOS/BIOS and even the CCP to use an API so that programs could also use and automate functions that you might type in manually.

It doesn't really look much like CP/M anymore does it?

 

[bakemono]

Being able to read/write multiple sectors with one system call would be nice, and would result in better performance on systems with larger-than-128-byte sectors. An API for clearing the screen, cursor positioning, and getting the screen dimensions would also be rad.

 

[durgadas311]

CP/M was originally written for the Intel MDS-800. That was really the only 8080 system at the time, with the Altair 8800 and Imsai being something that happened later. Intel created the MDS-800 so that others had a chance of doing ANYTHING with an 8080 chip. The MDS-800 has it's monitor ROM normally at F800H, and used a manual switch to force it to also be addressed at 0000H in order to "bootstrap" the system. Later systems would use a flip-flop and an OUT instruction to automate all that. If you look at the operator's manual for the MDS-800, you start to see a lot of the CP/M facilities and designs fit into place. Including the idea of loading programs into 0100H.

So, exactly how much history does your question erase, and how much future knowledge are we allowed to bring to the answer? I'm not even sure when (8") floppy drives were added to the MDS-800, but it would seem to have been an option at some point early on.

 

[cjs]

Maybe it was overkill for the era, but putting the BIOS at the zero page would solve a lot of issues.

That seems like a bad idea to me, since in later banked systems the "BIOS" in main memory might be just a few bytes. Yet in old systems without bank switching you might need as much as 2-4 KB of space in "main memory" for the BIOS. That's why I did the scheme I described above: you can use as much or as little (down to about 4 KB) of the main memory for BIOS and BDOS as you care to once bank switching becomes available.

But the original intent was to make all the memory available to the system, for whatever purposes - even if they overwrote CP/M.

You'll have to explain that to me. I don't see any intent to let you overwrite the BDOS, since that would trash the OS, and completely remove your ability to read and write disk files (which was, after all, the whole point of CP/M).

I can see, I suppose, using it as a booter for things that take over the entire system, such as games, but why would you bother when you can just write you own boot sector that loads what you need, and also gives you the ability to do more than just load memory once and then trash your ability ever to load more from the diskette?

But in 1974, memory was so expensive, and small amounts were difficult to come by... Maybe to that extent, a cut-down version or minimal version - even smaller that CP/M 1 would be useful...

I'm interested to hear how you would cut it down. I don't know how big the original MDS BIOS was (but it seems hard to make it smaller, given the interface), and the original BDOS was only 3.5K.

Originally, it didn't allow for video memory or anything like that, and nothing really changed through to CP/M+ there.
But by 1978, that was a very different situation and I'd do a lot differently, and in fact did in my own version of CP/M so as to remove memory limitations in a way that is native to the existing CP/M model.

I think you missed the entire point of the exercise. Knowing now the changes you wanted to make in 1978, what could you have done in 1974 to make those changes easier and reduce incompatibilities? Is there really nothing that could have been done to CP/M in 1974 that would make those 1978 changes easier and more compatible?

2) I'd use 8 bit values for disk referencing. Actually, I'd go straight to logical block addressing as a 16 bit value, then increase this to 32 bits later... No Disk, Record, Track etc... And I'd increase the record size to 256 bytes.

Yes, this makes good sense to me. And if you want sector interleave, do it at the physical formatting level (i.e., in the sector headers).

3) I'd standardise ways to move the ROM in and out of the way, so that the BIOS calls could be made directly, and I'd just use a hook in lower memory somewhere to page it in and then call it. Slightly longer, but frees up enough RAM to be worth it. I'd also make it so that up to 64K of ROM could be installed.

I'd like to hear details about how you actually intended to do this and what the advantage is, including how this works on systems without a ROM BIOS, but just an IPL (or systems with no ROM at all, for that matter).

4) I'd probably have used a linked list for the directory structure - as DOS did, which is a shame, because that would cut of something I would do differently in 1978 for CP/M 2.0

Again, missing the point of the exercise. Given that you wanted X in 1978, why would you work in 1974, knowing you're going to want X in a 1978, to cut that off?

5) I'd make all commands execute from the disk itself.

That seems kinda terrible. DIR has to load from the disk every time and, if it's not there, you can't get a directory?

6) I'd support interrupts and a system clock.

What depends on this? What do systems without this do?

7) I'd still use a serial terminal for the console, but I'd do it through the ROM so that video systems could be supported.

How does this differ from doing this through the BIOS in a traditional CP/M system?

8) I'd use the ROM for a basic CCP and even the BDOS. These never changed anyway (within the version) so why not put them in ROM? 2K ROM and 4K ROM were common. If it was made simpler, then it should be possible to fit a CCP/BDOS/BIOS into a single ROM and then CP/M is ROM boot.

I'd like the details on this, and how it differs from my proposal.

(I think I'll just leave the rest, for the moment.)

 

[cjs]

The MDS-800 has it's monitor ROM normally at F800H, and used a manual switch to force it to also be addressed at 0000H in order to "bootstrap" the system. Later systems would use a flip-flop and an OUT instruction to automate all that.

That is interesting. I've long been wondering about the "RAM at $0000" thing. I wonder why they did it that way, and I kinda wonder even more about why Kidall followed that. (Though, I suppose, perhaps he just didn't want to waste 2K of RAM.)

So, exactly how much history does your question erase, and how much future knowledge are we allowed to bring to the answer?

I'm not clear what you mean by the first question, but for the second one, all the future knowledge you can muster.

 

[cjs]

An API for clearing the screen, cursor positioning, and getting the screen dimensions would also be rad.

This would be pretty interesting. I suppose on the "clear screen" call you type out something that instructs the user to rip off the paper and burn it? And getting the horizontal dimension is easy, but how do you tell how much paper is left on the roll? :-)

 

[Perico]

I think CP/M would have had a better luck if DRI had released an standard video reference, instead of being agnostic on that front and aiming for just "a barebones teletype-capable terminal". That would have reduced fragmentation and incompatibilities in office-targeted commercial programs.

 

[bakemono]

This would be pretty interesting. I suppose on the "clear screen" call you type out something that instructs the user to rip off the paper and burn it? And getting the horizontal dimension is easy, but how do you tell how much paper is left on the roll? :-)

That'll have to do until we can upgrade to fanfold paper.

 

[durgadas311]

That is interesting. I've long been wondering about the "RAM at $0000" thing. I wonder why they did it that way, and I kinda wonder even more about why Kidall followed that. (Though, I suppose, perhaps he just didn't want to waste 2K of RAM.)

The RAM at 0000H is actually a wise way to go. It does present a problem for CPUs that RESET to 0000H, but that is not so difficult to get around (everyone did). The "BOOT switch" solution used on MDS-800 was pretty ugly, but that was the first ever general-purpose 8080 computer so we can give it a break. Having the monitor ROM and OS high in memory is a good design, as those things will change size over time (on different platforms) and keeping user programs in low memory means they do not need to be recompiled for different ORG addresses every time the OS or ROM (platform) changes, or more when memory is added. It also means that programs are ORGed at an absolute (constant) address, meaning running a program does not require any sort of relocation to take place.

 

[durgadas311]

I'm not clear what you mean by the first question, but for the second one, all the future knowledge you can muster.

So, if we're supposed to be creating CP/M back in 1974, but have knowledge of things that didn't exist back then - like SASI harddisks and fancy CRT terminals - then we're back to the same question: how stupid was Gary Kildall not to have predicted the full future of technology from the beginning? Perhaps a better question would be: once things started to solidify in the world of microcomputers (~1978/80), what might Gary had done differently to evolve a better CP/M? There were probably some early design decisions that could have been changed without a major disruption of backward-compatibility, and some features added that weren't. But I don't think it is very interesting to use technology of 2025 to critique designs of 1974.

 

[cj7hawk]

That seems like a bad idea to me, since in later banked systems the "BIOS" in main memory might be just a few bytes. Yet in old systems without bank switching you might need as much as 2-4 KB of space in "main memory" for the BIOS. That's why I did the scheme I described above: you can use as much or as little (down to about 4 KB) of the main memory for BIOS and BDOS as you care to once bank switching becomes available.

Isn't that what you described when you said to put ROM at the zero page and extend from there, raising the executable to later memory - eg, $8000? I like the idea, but I also don't like the idea. It would mean my Speccy could have run CP/M, but it would limit what CP/M could do also. I don't think the objective was to enfranchise future machines.

You'll have to explain that to me. I don't see any intent to let you overwrite the BDOS, since that would trash the OS, and completely remove your ability to read and write disk files (which was, after all, the whole point of CP/M).

Yes, you can warm boot or cold boot from the BDOS. As long as you're rebooting each time a program exits, does it matter if you just load the CCP or the BDOS/CCP? I've seen approaches that combine these anyway, and yes, once you do that, you lose the BDOS interface to the disks, but if you're not performing file system activity, you can do this still. Especially since CP/M never quite provided the standardisation as you see on the PC.

I can see, I suppose, using it as a booter for things that take over the entire system, such as games, but why would you bother when you can just write you own boot sector that loads what you need, and also gives you the ability to do more than just load memory once and then trash your ability ever to load more from the diskette?

Of course you can still load from the disk... You just need to use your own routines. I'm not saying that's how it should be done, but I am saying that should be supported. Keep in mind, you should still always have the BIOS which is the true key to disk services.

I'm interested to hear how you would cut it down. I don't know how big the original MDS BIOS was (but it seems hard to make it smaller, given the interface), and the original BDOS was only 3.5K.

Once you simplify the disk system, reduce the BIOS size, remove the buffers ( temporary and preemptively, for all 16 drives! ) you can cut a heck of a lot from the BIOS. Same with the BDOS once you reduce the overhead of blocking/deblocking/translating etc. And then reducing the system code in the CCP. As you note, you need a capability to see a DIR, but that's it, and that could be greatly simplified for the purpose of command loading... It should be possible to build an OS, CCP/BDOS/BIOS in 4K... Maybe even in 2K if you cut it down further.

I think you missed the entire point of the exercise. Knowing now the changes you wanted to make in 1978, what could you have done in 1974 to make those changes easier and reduce incompatibilities? Is there really nothing that could have been done to CP/M in 1974 that would make those 1978 changes easier and more compatible?

Not really. I'm just recognizing that even with foreknowledge of events, I'd have made different decisions based on 1974 and 1978. Waiting for 1978 is also an option, but if I was Gary, with more knowledge that I have now, I'd make some adjustments.

Yes, this makes good sense to me. And if you want sector interleave, do it at the physical formatting level (i.e., in the sector headers).

I'd like to hear details about how you actually intended to do this and what the advantage is, including how this works on systems without a ROM BIOS, but just an IPL (or systems with no ROM at all, for that matter).

Some boot method is always needed. I'd use a ROM for that. And if I have to have code somewhere, then why not the ROM if it's small enough? I'd get rid of boot sectors unless I went the Amstrad way, where hardware loads the

Again, missing the point of the exercise. Given that you wanted X in 1978, why would you work in 1974, knowing you're going to want X in a 1978, to cut that off?

What I'd do in 1974 is different from what I'd do in 1978, given that CP/M 1 would already be out, and the z80 would be an option, and 64K was a lot more realistic an option.

That seems kinda terrible. DIR has to load from the disk every time and, if it's not there, you can't get a directory?

Obviously some kind of minimal search structure is necessary, but you don't need formatting and informational display routines - just look for dir.com, load and execute. This would reduce the code burden significantly.

What depends on this? What do systems without this do?

Who knows? But it's what I'd do. I like a way of standardising interrupts and providing a clock tick as a default architectural element.

How does this differ from doing this through the BIOS in a traditional CP/M system?

Only by being incorporated outside of the system RAM memory, with options only to bring it back within the main system 64K RAM space... ie, more TPA. And no chance of accidentally overwriting anything important or corrupting the BIOS -Note, the scratchpad memory ( all system memory ) is outside of the 64K TPA most of the time in this architecture. It's only really visible to the system ( or software the specifically pages it in ).

I'd like the details on this, and how it differs from my proposal.

It may not be any different - though I'm not clear on whether you were considering loading CP/M from a disk, or incorporating it in the BIOS. I'm just saying CP/M's core would be entirely BIOS based if I was doing it back in 1974. And all the functionality that a user can call ( and other apps via API ) would be disk based.

What I'd do in 1974 wouldn't resemble CP/M all that much, but what I'd do in 1978 with CP/M 1 out already is very different. I'd stay much closer to CP/M and build on it's existing strengths.

 

[cj7hawk]

So, if we're supposed to be creating CP/M back in 1974, but have knowledge of things that didn't exist back then

I can just imagine it...

ring ring. ring ring. Digital Research, Gary Kildall speaking.

Hi Gary, My name is Billy Lowe I'm from IB....

Fantastic, I've been waiting six years for your call. Yes, you can have CP/M 86 as long as you don't sell any competing OS with your product, and only the first version. Oh, and don't trust that Bill Gates guy. He's a snake. Just avoid Microsoft entirely. And you can't buy their word processor or GUI either. And can you please consider putting 16 colors in your CGA product? Trust me, the 4 color idea is going to cause lots of arguments about 45 years from now. In fact, I'll give you CP/M-86 for free for your PC and other 8088 based machines if you agree never to talk to anyone named Steve Balmer. Or Steve Jobs, Or Steve Wozniak. In fact, no Steves allowed. Or anyone who ever did anything in Seattle with the 8086. Oh, and I'll throw in a Harley Davidson and some leathers for free if you like? Just don't wear them anywhere in california.

Steve who? What? How did you know what we were calling about?

Perhaps a better question would be: once things started to solidify in the world of microcomputers (~1978/80), what might Gary had done differently to evolve a better CP/M? There were probably some early design decisions that could have been changed without a major disruption of backward-compatibility, and some features added that weren't. But I don't think it is very interesting to use technology of 2025 to critique designs of 1974.

Yep, I think by 1978/80 things were very different. Hence why what I'd do in 1974 and what I'd do in 1978 would be very different - even with foreknowledge of the future.

 

[cjs]

The RAM at 0000H is actually a wise way to go. It does present a problem for CPUs that RESET to 0000H, but that is not so difficult to get around (everyone did).

Well, wise if everybody provides a way to to have RAM at $0000. Which not everybody did (for fairly obvious reasons of cost and complexity) even well into the mid-80s on machines designed optionally to have more than 64K of RAM (e.g., MSX). So it's I guess a value judgement at in the end about whether you want CP/M running on fewer machines but with a bit more ease in using up to ~56K of RAM (as a single TPA), or you want a bit more complexity in using a >31.75K TPA (as in my scheme) but compatibility across far more machines, as in the scheme I presented above. (And keep in mind a lot of larger programs ended up using overlays anyway, which are essentially built in to the scheme I presented.)

I prefer the latter because at least it gets the OS more broadly accepted. It may not be a very good OS, but I still think that's better than than the fragmented state that led us to TRS-DOS, PC-8001 Disk BASIC, whatever the Spectrum did, etc. etc.

So, if we're supposed to be creating CP/M back in 1974, but have knowledge of things that didn't exist back then...then we're back to the same question: how stupid was Gary Kildall not to have predicted the full future of technology from the beginning?

Well, I'm not back to that question, but if you happen to be attracted to it, I can give you the simple and correct answer: "not stupid at all." This was years before the Trinity even, and nobody at the single-user-PC level had experience of computing prices coming down the way they did (though they might have, with good knowledge of the mainframe and minicomputer markets of the last decade or so, been able to predict the way costs would come down). And even if they did, there was still no experience anywhere of dramatic consumer take-up of computers. Heck, the original machines of 1974-1976 weren't even for consumers.

At any rate, whether it leads you there or not, for me this is just an interesting thought experiment about easing the move forward from about 1974 through around 1980. I'm definitely not interested in calling Kidall stupid.

Perhaps a better question would be: once things started to solidify in the world of microcomputers (~1978/80), what might Gary had done differently to evolve a better CP/M?

Well, "better" is a value judgement; it's certainly not a "better" question for me, since I find it a lot less interesting. But you should certainly feel free to start a thread for your question if you're interested.

But I don't think it is very interesting to use technology of 2025 to critique designs of 1974.

Well, this is more using the technology of the late '70s and, maybe, early '80s to critique designs of 1974; by 1990 I think that the 1970s designs would be gone regardless. But if that's not interesting to you, no problem; this just isn't the thread for you.

Yep, I think by 1978/80 things were very different. Hence why what I'd do in 1974 and what I'd do in 1978 would be very different - even with foreknowledge of the future.

I agree, which is why I limited the changes to 1974 CP/M, rather than CP/M rewrites post 1978.

 

[cjs]

Isn't that what you described when you said to put ROM at the zero page and extend from there, raising the executable to later memory - eg, $8000? I like the idea, but I also don't like the idea. It would mean my Speccy could have run CP/M, but it would limit what CP/M could do also. I don't think the objective was to enfranchise future machines.

Given that he was clearly designing CP/M from the start to be portable to other machines, I do think that the objective was to "enfranchise future machines."

And how much would my proposal really limit what CP/M could do? It does provide (albeit in a slightly more awkward way) the ability to use a full 56K of RAM, and even a standard overlay system that, if anything, makes it easier to run programs that need more code and static data on machines without enough main memory for all of it (via a more or less standardised, if limited, overlay system).

Yes, you can warm boot or cold boot from the BDOS. As long as you're rebooting each time a program exits, does it matter if you just load the CCP or the BDOS/CCP?

Right: but remember what a "cold boot" is: it's initialisation after the CCP, BDOS and BIOS have been loaded by the boot sector.. So no, that will not restore a BDOS (or BIOS) that's been stomped on; your only option is to reboot the whole machine, which CP/M did not provide an API for. (But I guess the user can always just hit the reset button.)

And I'm just not really getting the point: the whole idea you're looking for, "get rid of the OS and do a cold boot after to bring it back" just seems so much more easily (and, often, cheaply!) solved by not bothering with CP/M at all and simply doing self-booting games, which you could fairly easily "install" by having the user create a bootable CP/M disk for his system and then sticking your own code in the BDOS and CCP (and BIOS, if you like) sectors of it, though you still do have to deal with the relocation.

As long as you're rebooting each time a program exits, does it matter if you just load the CCP or the BDOS/CCP?

Not at program exit, but I don't see much point to keeping the BDOS until program exit and then trashing it just before you reboot. And you can't trash the BDOS earlier than that, because you lose your OS. If you don't need the OS while you're running (say for a game that doesn't need to load anything after its initial load, and provides its own console I/O routines, why bother with CP/M at all? Just do a self-loader and skip CP/M entirely. (As you point out in later comments.)

And let's also note that, if you're using my scheme above, you may not be able to replace the BDOS or BIOS (and possibly not even CCP) because that may all be in ROM.

Once you simplify the disk system, reduce the BIOS size, remove the buffers ( temporary and preemptively, for all 16 drives! ) you can cut a heck of a lot from the BIOS. Same with the BDOS once you reduce the overhead of blocking/deblocking/translating etc. And then reducing the system code in the CCP. As you note, you need a capability to see a DIR, but that's it, and that could be greatly simplified for the purpose of command loading... It should be possible to build an OS, CCP/BDOS/BIOS in 4K... Maybe even in 2K if you cut it down further.

This is interesting, but I'm not convinced that there's that much to cut down. I don't know what "buffers" you're talking about for the drives; there is a single 128-byte DIRBUF, but that's shared amongst all drives, and sector I/O is done from/to the DMA area in user memory. There is a per-drive disk parameter block, which is 16 bytes, but I'd imagine that most smaller systems would support just four of those, which is 64 bytes of ROM or RAM.

Not really. I'm just recognizing that even with foreknowledge of events, I'd have made different decisions based on 1974 and 1978. Waiting for 1978 is also an option, but if I was Gary, with more knowledge that I have now, I'd make some adjustments.

I think I'm just confused by this. Are you saying that here are no changes at all that could be made in 1974 that would make any difference to the changes you'd want in 1978; it would be just as hard and have just as many incompatibilities regardless of what the 1974 version looks like? That sounds...unlikely to me. But if so, I guess this topic has no relation to anything you'd do in 1978, and you just have to treat it as stand-alone.

 

[cjs]

Some boot method is always needed. I'd use a ROM for that. And if I have to have code somewhere, then why not the ROM if it's small enough?

Exactly. My proposal above gives you the ability to do really simple machines with the BIOS, BDOS and CCP all in ROM at the bottom of memory, for basically an instant boot, and a small but usable 16K TPA (well, yeah, -$100 so 15.75K, but I'm getting tired of typing that), that can be done about as cheaply as possible once 4116 DRAMs are available, and easily expandable to 32K TPA.

Want to replace the serial port with a terminal? Just stick the display RAM below $8000 and it doesn't get in the way of the TPA.

Or, if you don't want to licence CP/M for every machine, you have CP/M compatible BIOS routines in your ROM BIOS in low memory, and the "BIOS" that CP/M loads is a small (50 byte) stub which is just a jump table pointing into ROM. Let's take the TRS-80 Model I as an example: they move the start of RAM from $4000 to $8000 and have the CP/M BIOS stub call into ROM supplied by the Expansion Unit, so you load your BDOS and BIOS from disk into RAM at offset $AD80, giving you just over an 11 KB TPA, which is about what you get on a 20KB MDS system.

What I'd do in 1974 is different from what I'd do in 1978, given that CP/M 1 would already be out, and the z80 would be an option, and 64K was a lot more realistic an option.

Right. As I mentioned above, my interest here is not what you do once you're there, but how you get there in a way that maximises the spread of CP/M, as opposed to cutting off a large number of machines where the designers were not going to do significant extra work to make things CP/M compatible.

Obviously some kind of minimal search structure is necessary, but you don't need formatting and informational display routines - just look for dir.com, load and execute. This would reduce the code burden significantly.

I don't think it would. There aren't exactly a lot of intrinsic commands in the CCP (DIR, ERA, TYPE, SAVE, REN, USER) and at least one of those (SAVE) must be in the CCP. And actually, to save space overall, you do want certain routines, such as parsing filenames on the command line to FCBs, in the CPP where they can be done once and then removed (for larger programs) rather than having to be duplicated in every program. (Not to mention which you need that routine for SAVE anyway.)

So I don't see you saving a whole lot of space here. And let's remember, anyway, that saving space in the CCP isn't particularly helpful, since the CCP (unlike the BIOS and BDOS), doesn't shrink the TPA; it can be wiped out and reloaded. If anything, I'd probably put more stuff in the CCP.

Who knows? But it's what I'd do. I like a way of standardising interrupts and providing a clock tick as a default architectural element.

I guess my question is, what's going to use it if it's not always available. But now that I think further on this, yes, this does sound like a reasonable idea. Set up a standard 1/60s interrupt, and away to inform CP/M that you have a routine you'd like to be called during that interrupt.

Only by being incorporated outside of the system RAM memory, with options only to bring it back within the main system 64K RAM space... ie, more TPA. And no chance of accidentally overwriting anything important or corrupting the BIOS -Note, the scratchpad memory ( all system memory ) is outside of the 64K TPA most of the time in this architecture. It's only really visible to the system ( or software the specifically pages it in ).

I don't see what forcing this to be in ROM helps with. The option to put it in ROM, have banked ROM and banked scratchpad RAM and the like is already all there, at least in the scheme I proposed above.

It may not be any different [from your proposal] - though I'm not clear on whether you were considering loading CP/M from a disk, or incorporating it in the BIOS.

You can do either; it would be transparent to the system. You can even load CP/M from disk but into a separate RAM bank if you like, with just a stub in the first 4K of memory for handling system calls, machine-specific interrupts, video display, and whatever else you like. This would give programs a full 28K of TPA $(8000-$EFFF) plus
all eight optional 8K blocks ($1000-$7FFF and $F000-$FFFF) totaling 32K to do what they want with.

I'm just saying CP/M's core would be entirely BIOS based if I was doing it back in 1974.

I don't understand that. Are you saying that "CP/M" would provide only a standard BIOS interface for reading and writing blocks, supplied by the system vendor, and no BDOS supplying the filesystem? Sounds to me like you no longer have CP/M, just a standard interface to do straight block I/O to disks. Without the BDOS using this so you can actually run programs in files and they can read and write other files, I don't know why people would bother.

 

[cj7hawk]

Given that he was clearly designing CP/M from the start to be portable to other machines, I do think that the objective was to "enfranchise future machines."

Future CP/M architecture systems, sure, but not ROM booting systems that keep the ROM in the lower memory. I mean, I like the idea you presented - but if that was his objective, wouldn't saving everything as a kind of OBJ file make more sense, and having the CCP/BDOS restructure all the jumps with portable code?

And how much would my proposal really limit what CP/M could do? It does provide (albeit in a slightly more awkward way) the ability to use a full 56K of RAM, and even a standard overlay system that, if anything, makes it easier to run programs that need more code and static data on machines without enough main memory for all of it (via a more or less standardised, if limited, overlay system).

I think as long as the system
a) Ran on 8080 machines.
b) Was inexpensive to make the machines.
c) Removed the requirements to write your own system

then it would be a success no matter what it looked like.

Right: but remember what a "cold boot" is: it's initialisation after the CCP, BDOS and BIOS have been loaded by the boot sector.. So no, that will not restore a BDOS (or BIOS) that's been stomped on; your only option is to reboot the whole machine, which CP/M did not provide an API for. (But I guess the user can always just hit the reset button.)

My BIOS does, but I imagine you're right that some BIOS ( Maybe all other BIOS ) don't reload the entire boot process from the boot sector upwards.. I've never really taken the time to check all BIOS I encountered. I might be the only one that does it that way.

That's quite an interesting thought. It's a lot easier to do it through the BIOS - But you could have the bootstrap ROM do it and load the BIOS from disk also, or even relocate the BIOS from ROM.

@durgadas311 or @JohnElliott would probably know how different BIOS approach the cold boot.

And I'm just not really getting the point: the whole idea you're looking for, "get rid of the OS and do a cold boot after to bring it back" just seems so much more easily (and, often, cheaply!) solved by not bothering with CP/M at all and simply doing self-booting games, which you could fairly easily "install" by having the user create a bootable CP/M disk for his system and then sticking your own code in the BDOS and CCP (and BIOS, if you like) sectors of it, though you still do have to deal with the relocation.

It's just how I wrote my BIOS. It's not that complex. But as noted, I might be the only one who views it that way?

Not at program exit, but I don't see much point to keeping the BDOS until program exit and then trashing it just before you reboot. And you can't trash the BDOS earlier than that, because you lose your OS. If you don't need the OS while you're running (say for a game that doesn't need to load anything after its initial load, and provides its own console I/O routines, why bother with CP/M at all? Just do a self-loader and skip CP/M entirely. (As you point out in later comments.)

Trashing the BDOS and even the BIOS may not be ideal or even a good idea under CP/M, but you *can* do it. If it was all in ROM, then there's no need to worry about trashing it in the first place.

This is interesting, but I'm not convinced that there's that much to cut down. I don't know what "buffers" you're talking about for the drives; there is a single 128-byte DIRBUF, but that's shared amongst all drives, and sector I/O is done from/to the DMA area in user memory. There is a per-drive disk parameter block, which is 16 bytes, but I'd imagine that most smaller systems would support just four of those, which is 64 bytes of ROM or RAM.

I guess I am reflecting on what I had to code here - There are all kinds of tables - Vectors, Headers, multiple load buffers, stack etc. So much ! and then you get all the maths for things... Parsers, Syntax checkers, etc. And on top of that you end up with a fairly complex OS - If that complexity goes, so does most of the code. 2K is plenty of space to deal with the rest, and you could end up with rom slots for each additional piece of hardware that needs it's own code, in a parallel space alongside the OS but not in user memory. It's not paging, per-se, but it would work the same.

I'd probably drop save... I never really liked it. it always feels like a kludge to me, and while you need it in CP/M, that's because it's there and people use it. No commands means no matching logic, and minimal buffers. If you want a greater OS shell, load one that does more of what the CCP does. Sure, you'd get some curious issues such as not having commands you need at times, because disk space was used for something else - if I need a way to do stuff like that, I'd probably create something like function keys, that execute code when pressed. Save desired? Load and assign the save function key - or maybe make it an entire debugger somewhere in memory. Maybe set these up to run under interrupt even?

I think I'm just confused by this. Are you saying that here are no changes at all that could be made in 1974 that would make any difference to the changes you'd want in 1978; it would be just as hard and have just as many incompatibilities regardless of what the 1974 version looks like? That sounds...unlikely to me. But if so, I guess this topic has no relation to anything you'd do in 1978, and you just have to treat it as stand-alone.

I proposed a LOT of things I'd do differently with the 1974 approach. It wouldn't be CP/M anymore, but it would be OK. And I'm just brainstorming for ideas on how I'd approach it... I'd probably write up a list and rewrite it several times as I progressed, so anything I say I might change - but things like logical addressing? I'd probably keep that - and I'd probably keep simplifying it to a minimum - but I might go with a more CP/M-like disk structure since it simplifies loading -

Knowing a lot about the future, I'd probably spend some time planning to take advantage of things early... Hot Tub Time Machine style. Even that's not a guarantee of success. But if I could demonstrate an ability to generally predict future changes, I could probably gain enough of a financial following to get lucky.

But there are lots of questions -eg, How old am I? I was 5 in 1974. Am I still 5? Or should I be 15? 30? Do I already have a computing degree? Am I Gary Kildall?

So I'm just thinking about how I'd approach the problem rather than how I'd have changed the first CP/M.

Having written a CP/M compatible OS, I learned a huge amount about what he may have been thinking at the time, and of course, I made a lot of assumptions - such as Cold boot reloads the BDOS/CCP

But I remember hating the 7 bit limitations. And I even almost rewrote my OS with 256 byte file buffers...

 

[cj7hawk]

Exactly. My proposal above gives you the ability to do really simple machines with the BIOS, BDOS and CCP all in ROM at the bottom of memory, for basically an instant boot, and a small but usable 16K TPA (well, yeah, -$100 so 15.75K, but I'm getting tired of typing that), that can be done about as cheaply as possible once 4116 DRAMs are available, and easily expandable to 32K TPA.

We're thinking similarly - except I'd page the OS out and just leave hooks behind. That means standardising some architectural elements such as I/O addresses though. CP/M definitely stayed out of that space. That belonged to the BIOS.

Want to replace the serial port with a terminal? Just stick the display RAM below $8000 and it doesn't get in the way of the TPA.

I would have loved that in the 80s, but I'm not sure I'd have made the decision to do it that way.

I don't see what forcing this to be in ROM helps with. The option to put it in ROM, have banked ROM and banked scratchpad RAM and the like is already all there, at least in the scheme I proposed above.

They might be closer than I imagine - I'd just like to see a minimal OS entirely in ROM rather than on disk. The differences are slight and seem to be around whether the ROM is only paged in for system calls, or is always there.

You can do either; it would be transparent to the system. You can even load CP/M from disk but into a separate RAM bank if you like, with just a stub in the first 4K of memory for handling system calls, machine-specific interrupts, video display, and whatever else you like. This would give programs a full 28K of TPA $(8000-$EFFF) plus
all eight optional 8K blocks ($1000-$7FFF and $F000-$FFFF) totaling 32K to do what they want with.

I still like the idea of 64K of ram accessible. I guess it's a personal thing. It wouldn't make any difference once people started coding for it.

Having the ROM permanently availalable would certainly make the design a lot simpler.

I don't understand that. Are you saying that "CP/M" would provide only a standard BIOS interface for reading and writing blocks, supplied by the system vendor, and no BDOS supplying the filesystem? Sounds to me like you no longer have CP/M, just a standard interface to do straight block I/O to disks. Without the BDOS using this so you can actually run programs in files and they can read and write other files, I don't know why people would bother.

I did mention that, by the time I finished it, it might not be CP/M anymore. And not just block I/O... minimal rudimentary commands to locate a file and make it available as a byte stream via API. I did mention a way to load system calls via the API so if you wanted to load a file, you would use the basic loader in the BIOS - but if you wanted to do a directory, well you'd load a program to access the disk directly and produce the directory for you.

There would only be two ways to access files.
1) Block Transfer.
2) Serial transfer.

Both would support random access.

 

[durgadas311]

A lot of things being proposed here actually limit the platforms that CP/M could run on. Gary wisely (IMHO) did NOT get into deciding how a platform goes from power-on to CP/M prompt. There were lots of ingenious ways people found to do that on platforms that were not originally designed to run CP/M. The 1974 CP/M was designed for the MDS-800 and making it run on other platforms was painful. By version 1.3/1.4 Gary had reworked a lot so that it was comparatively easy to port it to new platforms - which was one of the great strengths of CP/M and something that propelled it along. I think Gary did a very good job of deciding what aspects of a platform were mandatory (very few) and which did not matter to core CP/M. I recall a discussion with DRI folks about establishing "standards" for auto-detecting and describing floppy disk formats, but while they were very encouraging and interested, they stated the DRI was not the one to be dictating that - it should be a consortium of vendors that should be proposing things like that. A very forward-looking approach.

There is an interesting documentary on youtube (

) that chronicles the life of CP/M (actually, the life of Gary Kildall and his CP/M). It tells things the way I remember them, for the most part. It is interesting to realize that all the times I remember interacting with Gary, Tom Rollander, etc was *after* that fateful meeting with IBM, but they certainly kept their secrets as we never had any idea. It is a rather glowing tribute to Gary, as I think he deserves, but certainly gives another side to "the story" of how things went down.