1. Forum
  2. Usenet
  3. COMP.OS.CPM

  • Re: Compatibility between CP/M 2.2 systems

    From Douglas Miller@21:1/5 to All on Wed Aug 2 13:56:09 2023
    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).

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Martin@21:1/5 to All on Wed Aug 2 22:18:32 2023
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From dxforth@21:1/5 to Martin on Thu Aug 3 12:54:56 2023
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Martin@21:1/5 to All on Thu Aug 3 06:32:24 2023
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Martin@21:1/5 to All on Thu Aug 3 06:39:01 2023
    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?

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Douglas Miller@21:1/5 to Martin on Thu Aug 3 04:26:09 2023
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)