Compatibility between CP/M 2.2 systems

[Martin]

Hi. I'm totally new to CP/M. I'm asking myself a question: What would I
need to take into account to enshure, that a program developed for/on
one CP/M 2.2 system will run on another?

Say, I'd develop on Linux/RunCpm with 60 K of free RAM and have another
Z80-MBC with 56 K. Is this a problem? The code is not position
independant? What do I need to take care of?

Thanks in advance
Martin

[Douglas Miller]

Generally, you want to use only BDOS calls (no direct-BIOS calls) in order to remain compatible. In addition, you should not make any assumptions about the amount of available memory, or at least check your memory requirements against the "top of memory" address embedded in the BDOS entry JMP at location 0005H. You also don't want to directly access any hardware or make assumptions about the hardware configuration (possibly even including avoiding any terminal screen (ESC) codes, or else providing a mechanism to configure the program for different terminal types). Programs always run at location 0100H, so the code need not be position-independent or relocatable (unless you need that for the program itself).

For the file access BDOS calls, you should avoid manipulating the FCB, at least stay away from the fields called-out in the CP/M Programmer's Guide as being used internally or using fields in a way not defined in the manual. The FCBs must be initialized correctly for OPEN, MAKE, DELETE, RENAME, but otherwise one should generally not touch them (with the possible exception of the CR and random record number fields at the end).

[dxforth]

On 3/08/2023 6:18 am, Martin wrote:
> Hi. I'm totally new to CP/M. I'm asking myself a question: What would I need to take into account to enshure, that a program developed for/on one CP/M 2.2 system will run on another?
>
> Say, I'd develop on Linux/RunCpm with 60 K of free RAM and have another Z80-MBC with 56 K. Is this a problem? The code is not position independant? What do I need to take care of?

CP/M was written for the 8080. Depending on the intended audience you may wish to avoid
using Z80-specific instructions.

[Martin]

Am 03.08.23 um 04:54 schrieb dxforth:

> CP/M was written for the 8080. Depending on the intended audience you may wish to avoid
> using Z80-specific instructions.
>

Ok, this will not be that important for me, because I plan to have them
running on Z80 hardware or emulations only. Though, all my code, mainly
in C, was always be open source. So it can be compiled on other
processor architectures too, if needed.

At first CP/M code will be experiments and getting familiar with the
platform.

[Martin]

Am 02.08.23 um 22:56 schrieb Douglas Miller:

> Programs always run at location 0100H, so the code need not be position-independent or relocatable (unless you need that for the program itself).
>

Ah, great. So it seems, that this was the most unknown/important point
for me. So if only using BDOS, not manipulating the FCB after
initialization and using standard vt100 capabilities should produce
portable executables than.

There is no terminal abstraction layer, like termcap/terminfo or such?

[Douglas Miller]

On Wednesday, August 2, 2023 at 11:39:05 PM UTC-5, Martin wrote:
> Ah, great. So it seems, that this was the most unknown/important point
> for me. So if only using BDOS, not manipulating the FCB after
> initialization and using standard vt100 capabilities should produce
> portable executables than.
>
> There is no terminal abstraction layer, like termcap/terminfo or such?

CP/M did not have any standard terminal abstraction. Each app tended to do things differently. FYI, VT100 was not a very common terminal on CP/M machines. If your expected audience is users running terminal programs on their modern PC, then it's not a problem.

If you are using a HLL like C, you should not have too much problem remaining compatible unless you are adding ASM routines/code - in which case you just have to avoid dependencies on specific hardware.