Methodology for converting HP48 software towards HP49/50 - Hewlett Packard

This is a discussion on Methodology for converting HP48 software towards HP49/50 - Hewlett Packard ; Thanks very much to all contributors that have helped me out on Debug4x. I'm currently using this development tool to make an old software, initially written in 1993 for HP48SX, accessible to newest HP49/50 platforms. This post is about SysRPL ...

+ Reply to Thread
Results 1 to 3 of 3

Thread: Methodology for converting HP48 software towards HP49/50

  1. Methodology for converting HP48 software towards HP49/50

    Thanks very much to all contributors that have helped me out on
    Debug4x.
    I'm currently using this development tool to make an old software,
    initially written in 1993 for HP48SX, accessible to newest HP49/50
    platforms.

    This post is about SysRPL code. I will keep ASM questions for a
    separate one.

    So far so good, i've been quite impressed at the ease of conversion
    for SysRPL code with Debug4x, which just involve recompiling the same
    source code with a different target. For information, i've been using
    Carsten's HP Entry list instead of the default one. You can find it
    here :
    http://staff.science.uva.nl/~dominik...ies/index.html


    There are however some deeper differences sometimes. I've not been
    able to find the "one pit stop" for all relevant information on
    converting software from HP48 to HP49, but there are many usefull bits
    scattered around over Internet.

    In SysRPL, i'm mostly interested in creating different Keymaps for the
    different keyboards.

    My initial idea was to use conditionnal flags, like #IFDEF in C. But i
    could find none relating to selected target with Debug4x.
    Therefore, i'm considering a work-around, which is to create 2
    different project (one per target) using two different set of headers,
    from which the code will get its keymap values.

    I believe this should work, but instead of re-inventing the wheel, i'm
    willing to check :

    1) Is this the proper method for writing a code for both HP48&HP49
    target ? Is there any better recommendation ? Maybe conditionnal flags
    do exist after all ?
    2) Maybe some header files with all relevant keymaps already exist
    somewhere ? This would avoid me to create my own mnemonics, keeping
    the code as "standard" as possible.
    3) And last but not least, maybe there is some important information
    around on converting HP48 software to HP49/50, that it would be
    advisable to read first ?

    Regards

  2. Re: Methodology for converting HP48 software towards HP49/50

    Hello,

    > 1) Is this the proper method for writing a code for both HP48&HP49
    > target ? Is there any better recommendation ? Maybe conditional

    flags
    > do exist after all ?

    Take a look at the source code of HPlanetarium at
    http://pagesperso-orange.fr/kdntl/hp.../index.en.html (probably you
    prefer the French version ;-). In the source code you will find
    'conditional assembly' for compiling the source to different machines.
    Also chapter 3. and chapter 6.13 in SASM.doc explains the use of
    'conditional assembly'.

    > 2) Maybe some header files with all relevant keymaps already exist
    > somewhere ? This would avoid me to create my own mnemonics, keeping
    > the code as "standard" as possible.

    There are standard header files for the KeyMapping (48&49), the old
    DoInputForm engine (48&49), the new IfMain/IfMain2 engine (49) and for
    the two ChooseBox-engine, the old one (48) and the new one (49) and
    for the Filer (49).
    Of course all header files would be available from the ROM developers
    but unfortunately they are not available. The header files I use have
    been collected over the year from many different sources which I do
    not even remember and some are written by myself.

    Maybe Bill Graves could include more header files in future versions
    of debug4x, some are already in there.

    Also I do use "personal source" files where I strictly divide between
    code and messages. That way I can easily compile programs for
    different languages by just setting up another project which includes
    all the "technical" sources and a specific language file. That way I
    am managing more than 35.000 lines of code with debug4x for five
    languages ;-)

    > 3) And last but not least, maybe there is some important

    information
    > around on converting HP48 software to HP49/50, that it would be
    > advisable to read first ?

    Stick to supported or at least to unsupported but stable entries. If
    you really need to use an unsupported entry point rip it of the ROM or
    program it yourself, that way you avoid the trouble with ROM
    compatibility.
    The size of the screen is different so you probably want to pay
    attention to this.
    Also some reserved RAM areas have changed and some new areas have been
    added in the 49G. If you are sure that they will not be overwritten
    while your program is running you can use these areas as temporary
    storage (very fast) or even create you own one between GDISP and
    TEMPBOT (a little slower because the address are relative compared to
    the absolute addresse of the reserved RAM).
    Read SASM.doc (which I will also re-read again ;-)

    HTH
    Andreas
    http://www.software49g.gmxhome.de

  3. Re: Methodology for converting HP48 software towards HP49/50

    It seems you are right Andreas, SASM offers many many possibilities
    compared to RPLCOMP, including conditional compilation.
    This SASM.doc is really large, so i think i will take a while to
    digest it.

    Anyway, initially my question was limited to RPLCOMP, in the hope that
    there was no need to use ASSEMBLE, but it seems to be too limited.

    I'm not sure, however, that a conditional statement within ASSEMBLE is
    still valid after an RPL keyword.
    Something along the line :

    ASSEMBLE
    labelcheck #IF this-is-okay?
    RPL
    (... SysRpl code...)
    ASSEMBLE
    labelcheck #ENDIF
    RPL

    Would that work ?

+ Reply to Thread