Graphic ASM Code for HP49/50 - Hewlett Packard

This is a discussion on Graphic ASM Code for HP49/50 - Hewlett Packard ; Hello Everyone Still on my quest to better understand Debug4x and use it for porting HP48 software to HP49, i had some good results so far with SysRPL coding, so now is the time for some ASM coding. I typically ...

+ Reply to Thread
Results 1 to 12 of 12

Thread: Graphic ASM Code for HP49/50

  1. Graphic ASM Code for HP49/50

    Hello Everyone

    Still on my quest to better understand Debug4x and use it for porting
    HP48 software to HP49, i had some good results so far with SysRPL
    coding, so now is the time for some ASM coding.

    I typically use ASM for performance-intensive parts of application,
    graphics being one that come to mind. In this field, greyscale is a
    bit mandatory when it comes to make some good-looking interfaces.

    With HP48, 4colors greyscale is pretty well known, with many sources
    around.
    Basically, flip 2 images with different weight, and deal.
    Well, that sounds easy but...

    First limitation, on HP48, the graphic must start on even address only
    (byte-aligned).
    If it does not, you have to rely on a specific "shifting" mechanism,
    which is also fairly well documented.
    Here is a sample code :
    LC(1) #C
    D0=(5) =BITOFFSET
    DAT0=C 1
    D0=(2) =LINENIBS
    LC(3) #FFE
    DAT0=C X
    And then, you can also set image height, using simple routines :
    D0=(5) =LINECOUNT
    D1=(5) =DISP1CTL
    LC(2) #37
    DAT0=C B Linecount=37h=55d

    Ok, so where's the problem ?

    When trying to compile such a code for HP49, BITOFFSET, LINENIBS,
    LINECOUNT and DISP1CTL are not allowed by the compilator. It seems
    these mnemonics are no longer valid for HP49/50.

    What's strange however, is that if i'm hard-coding the corresponding
    address, it does work !!
    or at least it does with Emu48.
    Here is such an example :
    http://img21.xooimage.com/files/2/5/...n4c-534f76.png

    So i'm a bit surprised here.

    Such issue is more than likely already well known by today.
    What would be a "proper way" to handle this situation, greyscale
    graphics, as i guess that hardcoded address is probably not the best
    idea around ?
    Looking over Internet, i can find many greyscale animations or
    programs for HP49, but no ASM code nor advises on "good practice" in
    this area.

    2) If you have followed the link, you may have found another problem
    with the screenshot : some calculators (namely, HP49G+ & HP50) have
    bigger screens, of 80 lines (instead of 64).
    Here also, i guess this situation is already well known, so instead of
    re-inventing the wheel, i'm looking for some advises.

    For the time being, my main question would be : how can you check if
    the screen is 80 lines instead of 64 ?


    Regards

  2. Re: Graphic ASM Code for HP49/50


    "Yann" schrieb im Newsbeitrag
    news:27c19ab2-5bcc-4cc3-9d79-8b477d47f297@x35g2000hsb.googlegroups.com...
    > Hello Everyone
    >
    > [..]
    > For the time being, my main question would be : how can you check if
    > the screen is 80 lines instead of 64 ?
    >

    I think the keyword is 'IsBigApple? or similar...

    IIRC John H. Meyers made a general routine a while ago
    which could return the machine type it was running on.

    HTH

    Raymond



  3. Re: Graphic ASM Code for HP49/50

    On Fri, 01 Aug 2008 18:28:45 -0500, Yann wrote:

    > hardcoded address is probably not the best idea around ?


    Whenever I've used symbol tables that were missing anything I needed,
    I just inserted my own definition of the value of the symbol;
    this should be okay as long as it's a "stable" location.

    Otherwise perhaps there are more complete symbol tables.

    > how can you check if the screen is 80 lines instead of 64 ?


    In UserRPL: LCD\-> SIZE NIP B\->R @ 64. or 80.

    In SysRPL: DOLCD> GROBDIM DROP { #40 or #50 }

    In ML: ???

    [r->] [OFF]

  4. Re: Graphic ASM Code for HP49/50

    On Fri, 01 Aug 2008 19:09:45 -0500:

    [re screen size or just height, in pixels]

    > In ML: ???


    "Nosy" shows something called BIGAPP?
    (apparently sets/clears carry for 80/64)

    If the code could ever run on 49G or emulator,
    then IsApple? (or whatever it's called)
    should be checked first.

    Poke into "DOLCD>" via "Nosy" (library) to see it.

    Of course, someone who really does use ML
    would be better to ask

    I happen to like using LCD\-> or DOLCD>
    because these return the actual dimensions,
    on all calculators in entire HP48/49/50 series,
    without concern for anything at lower "bit-level"

    [r->] [OFF]

  5. Re: Graphic ASM Code for HP49/50

    Thanks for the tip John,
    that's actually a very good one,

    It is quite usual to "protect" an ML code using SysRPL header,
    to check inputs, types & conditions, and so on, for which it is much
    better suited.
    So this trick will helps.

    I will also take a look at this BigApp? or IsBigApple? possibility.

    One question : what do you mean by "Nosy" ?
    Thanks

  6. Re: Graphic ASM Code for HP49/50


    > > hardcoded address is probably not the best idea around ?

    >
    > Whenever I've used symbol tables that were missing anything I needed,
    > I just inserted my own definition of the value of the symbol;
    > this should be okay as long as it's a "stable" location.
    >


    Yes, i agree, that's also what i'm doing,
    but my reasoning was :
    if it is not even part of Carsten Entry list, which seems to do a
    pretty nice job at checking entry stability,
    ( These entries can be consulted here :
    http://staff.science.uva.nl/~dominik...ies/index.html )

    then there is probably a reason for this.

    Consequence : the address i could "hard-code" (using my own
    definition) may simply fail in circumstances i'm not able to test
    correctly right now. Well, sort of....

  7. Re: Graphic ASM Code for HP49/50

    Hello,

    > LCD\-> or DOLCD>

    What if the program changes the size of ABUFF through XYGROBDISP ?

    This is from my personal DEFINE-File, all addresses have been stable
    since the first ROM for the 49G+ (1.20 IIRC):
    =GetCurrentHeaderGrob EQU #2F3CF ( das neue Header-GROB ist leider )
    ( not needed for ROMs >= 2.00 )
    =SetCurrentHeaderGrob EQU #2F3D0 ( nur wirklich 131 x 16 Pixel groß )
    ( not needed for ROMs >= 2.00 )
    =PTR_IsApple_ EQU #3FEF1 ( setzt Carry bei ARM-basierten
    Rechner ) ( dies ist der IsApple_ Pointer der auf ARM-Architektur
    testet ) ( Pointer aus ROM 1.22, 2.01 )
    =IsBigApple_ EQU #2F3C1 ( IsBigApple ) ( hat keine Auswirkung
    auf das Carry-Flag ) ( dieser Eintrag wird über SYS-RPL und *nicht*
    über ML angesprochen )
    =IsAppleV2 EQU #2F3C7
    =IsBigApple_ML EQU #3FF14 ( setzt das Carry-Flag auf einem HP
    49G+ / HP 50G )

    * IsApple means it's an ARM based machine
    * IsBigApple means it's a 49g+ or 50g
    * IsMidApple means it's a 48GII
    *
    * You have a new stable entry point:
    * =IsAppleV2 EQU #2F3C7
    * IsAppleV2 means it has a serial port, 4 batteries etc.. This is true
    for
    * the 50g and the new 48gii (with a serial port)
    * will return TRUE on a HP50g. It exists since ROM version 2.0, on
    earlier
    * machine it would do strictly nothing... so you can use this entry
    points
    * on all calculators since the first release 1.05 provided you test if
    it
    * returns anything.
    * So IsAppleV2 will return TRUE on a 50g, always return FALSE on a 49g
    +
    * and depending on which version of the 48GII TRUE or FALSE
    * IsAppleV2 works since 2.0, before that this entry point did nothing
    (NOP) <- Das ist mit Vorsicht zu genießen, siehe auch
    * http://groups.google.com/group/comp....&q=ismidapple#

    However, it would be great if the entry data base by Carsten Dominik
    would be updated. Carsten has done a terrific job by presenting the
    entry data base.

    HTH,
    Andreas

  8. Re: Graphic ASM Code for HP49/50

    Thanks Andreas for all these usefull entries

  9. Re: Graphic ASM Code for HP49/50

    On Sat, 02 Aug 2008 05:03:55 -0500, Andreas Möller wrote:

    > Re LCD\-> or DOLCD>
    > What if the program changes the size of ABUFF through XYGROBDISP ?


    This sounds like a question calling for an actual experiment

    "Nosy" seems to indicate that the above
    make a new grob, having constant dimensions,
    combining both ABUFF (stack) and HARDBUFF2 (menu),
    to correspond with the LCD,
    rather than returning just the original ABUFF.

    "Nosy" is a great library by Jurjen N.E. Bos
    for decompiling/exploring objects and/or ROM:

    http://www.hpcalc.org/details.php?id=4323
    http://www.hpcalc.org/hp49/programming/misc/nosy.zip

    [r->] [OFF]

  10. Re: Graphic ASM Code for HP49/50

    Hi,

    On Aug 1, 7:28*pm, Yann wrote:
    <...>

    > 2) If you have followed the link, you may have found another problem
    > with the screenshot : some calculators (namely, HP49G+ & HP50) have
    > bigger screens, of 80 lines (instead of 64).
    > Here also, i guess this situation is already well known, so instead of
    > re-inventing the wheel, i'm looking for some advises.
    >
    > For the time being, my main question would be : how can you check if
    > the screen is 80 lines instead of 64 ?


    This is relatively simple from assembler.
    There's a new opcode called HSCREEN that returns the height of the
    screen in A.A. The opcode is good on all ARM machines, and my guess is
    that is should simply be ignored by the real Saturn (I never tested on
    an old machine).
    So, somehting like:

    A=0.A
    HSCREEN

    Will return:
    A.A=0 on an original Saturn processor
    A.A=64 on an ARM processor with the small screen
    A.A=80 on an ARM machine with the big screen

    Take a look at the following post for more complete information on
    extended opcodes:

    http://groups.google.com/group/comp....80880c48?hl=en

    Bear in mind that some of that information is incorrect, since it was
    posted when we were still "wild guessing" at many of the features. So
    always double check, don't assume that it works just because it's
    written there.

    Claudio



  11. Re: Graphic ASM Code for HP49/50

    One more thing...

    On Aug 1, 7:28*pm, Yann wrote:

    <...>

    > Looking over Internet, i can find many greyscale animations or
    > programs for HP49, but no ASM code nor advises on "good practice" in
    > this area.


    I think some of the games by Lilian Pigallio published on hpcalc.org
    may include source code.
    Also check the openfire website,

    http://fly.srk.fer.hr/~manjo/openfire/

    You'll find there information to make sure your grayscale graphics are
    openfire compatible (taking advantage of the hardware grayscale on ARM
    machines).

    Claudio



  12. Re: Graphic ASM Code for HP49/50

    On Aug 2, 6:03*am, Andreas Möller
    wrote:
    > Hello,
    >
    > *> LCD\-> or DOLCD>
    > What if the program changes the size of ABUFF through XYGROBDISP ?
    >
    > This is from my personal DEFINE-File, all addresses have been stable
    > since the first ROM for the 49G+ (1.20 IIRC):
    > =GetCurrentHeaderGrob EQU #2F3CF ( das neue Header-GROB ist leider *)
    > ( not needed for ROMs >= 2.00 )
    > =SetCurrentHeaderGrob EQU #2F3D0 ( nur wirklich 131 x 16 Pixel groß )
    > ( not needed for ROMs >= 2.00 )
    > =PTR_IsApple_ * * * * EQU #3FEF1 ( setzt Carry bei ARM-basierten
    > Rechner ) ( dies ist der IsApple_ Pointer der auf ARM-Architektur
    > testet ) ( Pointer aus ROM 1.22, 2.01 )
    > =IsBigApple_ * * * * *EQU #2F3C1 ( IsBigApple ) ( hat keine Auswirkung
    > auf das Carry-Flag ) ( dieser Eintrag wird über SYS-RPL und *nicht*
    > über ML angesprochen )
    > =IsAppleV2 * * * * * *EQU #2F3C7
    > =IsBigApple_ML * * * *EQU #3FF14 ( setzt das Carry-Flag auf einem HP
    > 49G+ / HP 50G )
    >
    > * IsApple means it's an ARM based machine
    > * IsBigApple means it's a 49g+ or 50g
    > * IsMidApple means it's a 48GII
    > *
    > * You have a new stable entry point:
    > * =IsAppleV2 * * EQU * * #2F3C7
    > * IsAppleV2 means it has a serial port, 4 batteries etc.. This is true
    > for
    > * the 50g and the new 48gii (with a serial port)
    > * will return TRUE on a HP50g. It exists since ROM version 2.0, on
    > earlier
    > * machine it would do strictly nothing... so you can use this entry
    > points
    > * on all calculators since the first release 1.05 provided you test if
    > it
    > * returns anything.
    > * So IsAppleV2 will return TRUE on a 50g, always return FALSE on a 49g
    > +
    > * and depending on which version of the 48GII TRUE or FALSE
    > * IsAppleV2 works since 2.0, before that this entry point did nothing
    > (NOP) <- Das ist mit Vorsicht zu genießen, siehe auch
    > *http://groups.google.com/group/comp..../thread/ae259a...


    Actually, from the thread it sounds like pre-Rom 2.00 the IsAppleV2_
    might crash the Calc.
    And on ROM 2.00 it may return an incorrect result. It should work fine
    on Version 2.01 and later.

    > However, it would be great if the entry data base by Carsten Dominik
    > would be updated. Carsten has done a terrific job by presenting the
    > entry data base.
    >
    > HTH,
    > Andreas


    My previous attempt to contact Carsten about his database have failed.

    I finally took it upon myself to look through the projects he was
    involved in and try updating them.

    I started with Emacs. The Emacs Source code included in the zip
    appears to be out of date. when compiled it identifies itself as
    version 2.10. It also notably has the long-press bug that was fixed in
    2.11a. By decompiling the result and comparing it to the result of
    decompiling the pre-built Emacs, it would probably be possible ti find
    the changes and correct the source. But since the one major bug I was
    encountering turned out to be due to a corrupted Emacs installation on
    my calculator, I really don't feel like messing around with it any
    more right now. I did not check to see if the SDIAG source code was up-
    to-date, but since on the hp49+ the interesting parts are those on the
    SD card, I did not feel it was worth bothering.

    Then I went to the EDB. This is the heart of the SDIAG documentation,
    Extable2, and the generated documentation files.
    It was easy enough to add IsAppleV2 to the actual databadse itself,
    although my current description of the command still needs to be
    revised. Unfortunately, the zip database is missing some important
    tools. After some effort I was able to replace some files needed to
    generate a new folder for SDIAG (the folder to place on the card. I
    verified that the files generated did not differ in any significant
    way from the original SDIAG files except the new entry. (Minor changes
    to the Keyboard access section of USERRPL commands occurred. Once
    Entry gain that section when it was missing due to a typo. One or two
    others had the ordering of the list of alternatives changed. There
    were no regressions). Once I set that up it is now trivial for me to
    generate new documentation files for the hp49+ version of SDIAG.

    Unfortunately, a rather important file for the generation of the
    documents detailing all the commands seems to be missing. This file
    looks difficult to replace.

    I have also successfully updated Extable2. While Thomas Rast made that
    library, he made it using a file generated by EDB, so I decided to try
    to update it to include IsAppleV2_. I was able to do that. In the
    process I corrected two entries with typographical errors in the name
    section, and one with an incorrect address. I have not done a thorough
    analysis of the accuracy of it, but those errors make me think that is
    a good idea. I have no good way to evaluate the accuracy of the
    entries not marked as unsupported (not ending in '_'), but I may be
    able to verify the rest of the unsupported entries anyway.

    Unless somebody requests that I do not, I intend to publish my updated
    files at some point in the semi-near future.

    In case anybody does manage to reach Carsten, or he reads this, the
    file I need to generate updated documentation is 'makecalc.pl' and if
    makecalc.pl does not generate it (although I think it does), the file
    called 'script'.

+ Reply to Thread