Q/C-80 problems with CP/M 2.2 ?? - CP/M

This is a discussion on Q/C-80 problems with CP/M 2.2 ?? - CP/M ; I was going through the manual David provided here and suddenly I stopped because I saw something very interesting concerning the compatibility with CP/M 2.2 at the very last page (PDF p.183): --------------------------------------------------------------------- Appendix F Q/C on CP/M-Compatible Systems As ...

+ Reply to Thread
Results 1 to 3 of 3

Thread: Q/C-80 problems with CP/M 2.2 ??

  1. Q/C-80 problems with CP/M 2.2 ??

    I was going through the manual David provided here and suddenly I
    stopped because I saw something very interesting concerning the
    compatibility with CP/M 2.2 at the very last page (PDF p.183):
    ---------------------------------------------------------------------
    Appendix F

    Q/C on CP/M-Compatible Systems

    As I stated in Chapter 1, Q/C should run on CP/M-compatible systems, but
    this is not guaranteed. If you have problems, I will give you what
    assistance I can. Since the vast majority of users have CP/M, however,
    this is where the main support will be.
    When you run Q/C on a CP/M-compatible system, the problems stem from the
    way values are returned from operating system calls. When a BDOS service
    is needed, the function number is loaded in in the C register and any
    additional parameter is loaded in DE. Then a CALL is done to location 5H.
    Unfortunately, the CP/M Interface Guide does not clearly specify how
    values are returned. For CP/M 2.2 it says that single byte values are
    returned in A and double byte values are returned in HL. For
    compatibility with earlier versions, CP/M 2.2 returns L=A and H=B. It
    does not state what is in B when the value returned is a single byte,
    however. On the CP/M systems I have seen, B=H=0 for single byte returns.
    On CP/M-compatible systems this is not always true.
    Q/C puts its function return values in HL. To satisfy everybody it
    provides two functions to do CP/M BDOS calls, bdosl takes the single
    byte returned by CP/M in the A register and moves it to L. It then loads
    zero in the H register, bdos simply returns the two byte value which
    CP/M puts in the HL register pair. All BDOS calls in the Q/C library
    expect single byte return values, so they use the bdosl function.
    Although this technique makes Q/C and CBESET work on other systems, you
    may still have a problem with the programs you write. If you make any
    direct BDOS calls using the Q/C library routines, be sure to call bdosl
    when you expect a single byte return value and bdos when you expect a
    double byte.
    ---------------------------------------------------------------------
    What does that mean ? Is that a problem generated by the OS
    implementation or just a compatibility problem of a few applications ?

    Regards
    Peter
    --
    * A blog about vintage computers and CP/M - http://www.z80.eu/blog

  2. Re: Q/C-80 problems with CP/M 2.2 ??

    Peter Dassow schrieb:
    > I was going through the manual David provided here and suddenly I
    > stopped because I saw something very interesting concerning the
    > compatibility with CP/M 2.2 at the very last page (PDF p.183):
    > ---------------------------------------------------------------------
    > Appendix F

    ....
    ....
    > ---------------------------------------------------------------------
    > What does that mean ? Is that a problem generated by the OS
    > implementation or just a compatibility problem of a few applications ?
    >
    > Regards
    > Peter


    Compatibility problem caused by the OS, not emulating CP/M 2.2 100%
    correctly. Because the complete sources of the runtime library are
    available too, such compatibility problems could be fixed within there.

    Udo Munk
    --
    The real fun is building it and then using it...

  3. Re: Q/C-80 problems with CP/M 2.2 ??

    On Fri, 01 Aug 2008 18:43:42 +0200, Peter Dassow
    wrote:

    >I was going through the manual David provided here and suddenly I
    >stopped because I saw something very interesting concerning the
    >compatibility with CP/M 2.2 at the very last page (PDF p.183):
    >---------------------------------------------------------------------
    >Appendix F
    >
    >Q/C on CP/M-Compatible Systems
    >
    >As I stated in Chapter 1, Q/C should run on CP/M-compatible systems, but
    >this is not guaranteed. If you have problems, I will give you what
    >assistance I can. Since the vast majority of users have CP/M, however,
    >this is where the main support will be.
    >When you run Q/C on a CP/M-compatible system, the problems stem from the
    >way values are returned from operating system calls. When a BDOS service
    >is needed, the function number is loaded in in the C register and any
    >additional parameter is loaded in DE. Then a CALL is done to location 5H.
    >Unfortunately, the CP/M Interface Guide does not clearly specify how
    >values are returned. For CP/M 2.2 it says that single byte values are
    >returned in A and double byte values are returned in HL. For
    >compatibility with earlier versions, CP/M 2.2 returns L=A and H=B. It
    >does not state what is in B when the value returned is a single byte,
    >however. On the CP/M systems I have seen, B=H=0 for single byte returns.
    >On CP/M-compatible systems this is not always true.
    >Q/C puts its function return values in HL. To satisfy everybody it
    >provides two functions to do CP/M BDOS calls, bdosl takes the single
    >byte returned by CP/M in the A register and moves it to L. It then loads
    >zero in the H register, bdos simply returns the two byte value which
    >CP/M puts in the HL register pair. All BDOS calls in the Q/C library
    >expect single byte return values, so they use the bdosl function.
    >Although this technique makes Q/C and CBESET work on other systems, you
    >may still have a problem with the programs you write. If you make any
    >direct BDOS calls using the Q/C library routines, be sure to call bdosl
    >when you expect a single byte return value and bdos when you expect a
    >double byte.
    >---------------------------------------------------------------------
    >What does that mean ? Is that a problem generated by the OS
    >implementation or just a compatibility problem of a few applications ?
    >
    >Regards
    > Peter


    CP/M is very specific on the calls and how data will be returned,
    others may not be so. This is one case where the program has to be a
    bit defenively programmed and the OS has the obligation to play by the
    rules.

    In most cases if the OS is wrong fix the OS.

    Allison

+ Reply to Thread