BigEd wrote:
Does CP/M manage memory at all? By which I mean, does it tell the application where usable memory starts and ends? I'm guessing there's no concept of allocation or of multiple users of memory needing to coexist. (Whereas in DOS, I gather there's the Terminate-and-Stay-Resident, which must mean that there are multiple occupants.)
CP/M didn't allocate anything - your program simply had to assume an origin of $0100. I don't recall if there was a way to check the top limit of memory - but if there wasn't an official way there's still a way to do it I'm sure (every time there's a warm-start, and that's after almost every program exit, the BDOS and CCP are loaded into high memory and CP/M knows where to put it. Your program has to end before that. EDIT: BDOS at the top, and CCP (command processor below that) - your program could overwrite the CCP, as long as you ended your program with a call to the warmstart function, which was the recommended way anyway. The warmstart would re-load the CCP.)
DOS had, or got, that TRS hack feature, via a specific INT call which left a chunk of memory alone. CP/M didn't clear out anything, so you could still hack something together to leave some code 'up there' somewhere. But you would have to hack some vectors to be able to intercept e.g. special key sequences to get to the code. But isn't that what you have to do in DOS as well? (I vagualy recall some CP/M tool that worked something like that. But it's been a long time so I'm not certain.)
MP/M was a multi-user CP/M, each user connected via their own terminal. So MP/M must have had a concept of memory management, but I'm not familiar with it. I have only used MP/M in single user mode (effectively CP/M), once, when I was called in to rescue all the files on the computer of an accounting firm. Somehow they managed to delete it all.. got it back though. So I don't know the internals of MP/M (the filesystem is just normal CP/M). CP/M had 'user' areas in the filesystem, but that's something else. A bit like virtual directories (the filesystem was otherwise flat, no subdirectories).
Quote:
Are CP/M programs, or indeed DOS programs, relocatable? It seems to me that load-time relocation as the Amiga did, or a CPU instruction set which allows for position-independent code, are major steps forward.
Run-time relocatable programs, or position-independent code, depends on the facilites of the CPU. I guess it's possible to write a small POC 8080 or Z80 programs. I don't think those architectures are particularly good for pic. But what programmers did was to create relocatable object code, which could be done by various means - e.g. the
PRL format. That's useful for linking modules (libraries) together, without that it's difficult to write real programs the way we still do them. Incidentally, the BDOS itself was relocatable - via the PRL concept, although it wasn't actually called PRL until MP/M or CP/M-3.0 AFAIK. Otherwise it wouldn't have been possible to create (via MOVCPM) a new version of CP/M when you e.g. increased the amount of RAM in your computer (the source of the BDOS wasn't provided as part of CP/M).