"Bad Load" or in the weeds

[Wayne Parham]

This is a question for the technical historians here.

I was a teenager when the Altair 8800 was introduced, and I always wanted one but couldn't afford one. So I went the 6502 route instead, mostly 'cause it was cheaper.

Now that I finally own one, I have enjoyed learning more about CP/M than just a casual observation about the commands and what-not. Back in the day, I'd been around CP/M enough to know how to navigate it from a user-perspective, but not enough to know what's under the hood or even how it acts when you drive it hard.

So after working with it for a year or so now, I have a few comments and questions.

I've noticed that when an application program exceeds TPA in CP/M 2.2, the load attempt will fail with a "Bad Load" message.

But it appears that an application program can exceed TPA in CP/M 3.0 without any sort of "guardrail" logic, so the load executes but it clobbers part of the operating system. Sometimes the program will start to run, then it's off in the weeds, crashing or hanging. Sometimes it reboots. No telling what will happen.

So those things make me ponder, hence my questions.

• Why did DRI choose to respond with the "Bad Load" error message in CP/M 2.2 when a program load attempts to exceed TPA? Was it just a "catch all" message? It seems better to have a TPA overrun error message that says "out of memory" or some such thing.

Not that I want to change it now - We're working with history now and I wouldn't want to change it - But if it was 1975 to 1985, I'd definitely consider rebuilding from source to include such a message.

• Why does CP/M 3.0 lack this guardrail logic? Are there some versions that do a better job of that? Is it maybe that the program loads, but then doesn't have enough room for the user stack, which then grows downward from the bdos/loader boundary into the application program?

I've seen this behavior from both assembly language programs and from compiled C programs that had no heap malloc'ed. And I've seen it in several builds of CP/M 3.0 with various device configurations. So my guess is it's a stack growth thing, but it could even be that the loader allows a program to overrun the OS code from the start. I don't know - haven't tried single-stepping it - but I'm curious.

[toml_12953]

Just a guess but since CP/M 3.0 came in a banked version, the limit on the TPA was fluid. Some implementations weren't tested thoroughly. Many versions of 3.0, such as Tandy's, were so buggy as to be unusable. Commodore's version, used on the 128 and 128D, was fairly robust and had no problem with programs larger than the TPA. By the time 3.0 was widely available, PC-DOS (MS-DOS) was taking over the market and development on CP/M was spotty, at best.