Identify 48s or 48g in UserRPL? - Hewlett Packard

This is a discussion on Identify 48s or 48g in UserRPL? - Hewlett Packard ; Sorry if this is an old question but I'm new around here and haven't found this listed anywhere. I am looking for a simple way in UserRPL to identify whether the program is running on a 48S series or 48G ...

+ Reply to Thread
Results 1 to 7 of 7

Thread: Identify 48s or 48g in UserRPL?

  1. Identify 48s or 48g in UserRPL?

    Sorry if this is an old question but I'm new around here and haven't found
    this listed anywhere.

    I am looking for a simple way in UserRPL to identify whether the program is
    running on a 48S series or 48G series.

    The only solution I have so far is to eval VERSION in an error trap but if
    the 48s has a variable object called VERSION, it will fail.

    Is there a known best way of doing this please?

    Thanks folks!

    Mark



  2. Re: Identify 48s or 48g in UserRPL?

    On Sat, 19 Jul 2008 08:28:31 -0500, Mark Edmonds wrote:

    > I am looking for a simple way in UserRPL
    > to identify whether the program is running
    > on a 48S series or 48G series.


    > The only solution I have so far is to eval VERSION in an error trap
    > but if the 48s has a variable object called VERSION, it will fail.


    "{VERSION}" OBJ\-> 1 GET TYPE

    A result of 6 suggests HP48S[X].
    A result of 14 suggests HP48G[X] or HP49/50.

    Or use any other "48G-series" command (e.g. SORT, CYLIN, ...)

    This is not completely foolproof -- a library could implement
    the command on any HP48S[X], or a variable of the same name
    could be created by a bit of hacking on any later calculator --
    but it solves the case you pose, by not evaluating the name,
    even if a 48S[X] does have a variable whose name
    matches a future command name from a later series.

    The HP48S/G series can be distinguished from HP49/50 series via

    RCLF SIZE 3 > @ 0 on 48S[X]/G[X], 1 on 49/50 series

    (unless, of course, someone intercepts RCLF via hacking

    I think there is another trick, reported by Joe Horn, IIRC:

    :&:1 EVAL TYPE @ 20 on 48S[X]/G[X], 0 on HP49/50 series

    There no doubt exist more bulletproof ML solutions,
    but UserRPL was what was sought.

    [r->] [OFF]

  3. Re: Identify 48s or 48g in UserRPL?

    More about:

    On Sat, 19 Jul 2008 08:28:31 -0500, Mark Edmonds wrote:

    > I am looking for a simple way in UserRPL
    > to identify whether the program is running
    > on a 48S series or 48G series.


    > The only solution I have so far
    > is to eval VERSION in an error trap


    When would it cause an error?

    On 48G[X]/49/50, result is two strings;
    isn't result on 48S[X] either just the name 'VERSION'
    or the output of evaluating a variable of that name,
    in case such a variable has been created?

    Compiling "{VERSION}" OBJ\-> 1 GET TYPE is a way to just see
    whether it was a variable name or a command, however,
    without being uncertain as to how many stack levels
    would be created by trying to evaluate VERSION.

    It's not a good idea to lose track of how many things
    are left on the stack, which is why I always thought it
    a poor idea that DOLIST, DOSUBS and SEQ [in 48G and later]
    each may return a list, or might sometimes return nothing,
    in a manner sometimes unpredictable,
    but it's 15 years too late to correct that oversight

    [r->] [OFF]

  4. Re: Identify 48s or 48g in UserRPL?

    John - thank you for your help.

    You're right of course, trapping VERSION wouldn't cause an error! I had
    forgotten how that would work on an SX. I'll use the OBJ\-> TYPE technique
    in the program - and I wanted this to make code portable across 48G and 48S
    models so I could use the better 48G UI and list commands where possible.

    I am not sure I understand why TYPE returns an XLib on a G and not a Command
    but it seems all G specific commands are type XLib. Actually, I don't know
    technically what an XLib is anyway but does this mean that the new G
    commands are implemented as a library coupled with the original S command
    set?

    Overall, I am very surprised HP didn't implement a simple test like a flag
    to identify the model type but maybe this does exist at a lower level. I'll
    probably get onto SysRPL and assembler when I consider myself an expert in
    User RPL (which I am a long way off as yet!).

    Regards,

    Mark


    "John H Meyers" wrote in message
    newsp.uekd0we0nn735j@miu.edu...
    > More about:
    >
    > On Sat, 19 Jul 2008 08:28:31 -0500, Mark Edmonds wrote:
    >
    > > I am looking for a simple way in UserRPL
    > > to identify whether the program is running
    > > on a 48S series or 48G series.

    >
    > > The only solution I have so far
    > > is to eval VERSION in an error trap

    >
    > When would it cause an error?
    >
    > On 48G[X]/49/50, result is two strings;
    > isn't result on 48S[X] either just the name 'VERSION'
    > or the output of evaluating a variable of that name,
    > in case such a variable has been created?
    >
    > Compiling "{VERSION}" OBJ\-> 1 GET TYPE is a way to just see
    > whether it was a variable name or a command, however,
    > without being uncertain as to how many stack levels
    > would be created by trying to evaluate VERSION.
    >
    > It's not a good idea to lose track of how many things
    > are left on the stack, which is why I always thought it
    > a poor idea that DOLIST, DOSUBS and SEQ [in 48G and later]
    > each may return a list, or might sometimes return nothing,
    > in a manner sometimes unpredictable,
    > but it's 15 years too late to correct that oversight
    >
    > [r->] [OFF]




  5. Re: Identify 48s or 48g in UserRPL?

    Actually, when looking up something unrelated in the AUR, I just found this:

    #30794h SYSEVAL

    which returns a string and the last letter of the string is the ROM
    revision. I don't think the S and G ROM versions overlap (last SX ROM is J,
    first GX ROM is K?) so I asssume this test could be used without worrying
    about what happens to the stack.

    Mark


    "Mark Edmonds" wrote in message
    news:r8KdneUxiekItx7VnZ2dnUVZ8uGdnZ2d@posted.plusn et...
    > John - thank you for your help.
    >
    > You're right of course, trapping VERSION wouldn't cause an error! I had
    > forgotten how that would work on an SX. I'll use the OBJ\-> TYPE technique
    > in the program - and I wanted this to make code portable across 48G and

    48S
    > models so I could use the better 48G UI and list commands where possible.
    >
    > I am not sure I understand why TYPE returns an XLib on a G and not a

    Command
    > but it seems all G specific commands are type XLib. Actually, I don't know
    > technically what an XLib is anyway but does this mean that the new G
    > commands are implemented as a library coupled with the original S command
    > set?
    >
    > Overall, I am very surprised HP didn't implement a simple test like a flag
    > to identify the model type but maybe this does exist at a lower level.

    I'll
    > probably get onto SysRPL and assembler when I consider myself an expert in
    > User RPL (which I am a long way off as yet!).
    >
    > Regards,
    >
    > Mark
    >
    >
    > "John H Meyers" wrote in message
    > newsp.uekd0we0nn735j@miu.edu...
    > > More about:
    > >
    > > On Sat, 19 Jul 2008 08:28:31 -0500, Mark Edmonds wrote:
    > >
    > > > I am looking for a simple way in UserRPL
    > > > to identify whether the program is running
    > > > on a 48S series or 48G series.

    > >
    > > > The only solution I have so far
    > > > is to eval VERSION in an error trap

    > >
    > > When would it cause an error?
    > >
    > > On 48G[X]/49/50, result is two strings;
    > > isn't result on 48S[X] either just the name 'VERSION'
    > > or the output of evaluating a variable of that name,
    > > in case such a variable has been created?
    > >
    > > Compiling "{VERSION}" OBJ\-> 1 GET TYPE is a way to just see
    > > whether it was a variable name or a command, however,
    > > without being uncertain as to how many stack levels
    > > would be created by trying to evaluate VERSION.
    > >
    > > It's not a good idea to lose track of how many things
    > > are left on the stack, which is why I always thought it
    > > a poor idea that DOLIST, DOSUBS and SEQ [in 48G and later]
    > > each may return a list, or might sometimes return nothing,
    > > in a manner sometimes unpredictable,
    > > but it's 15 years too late to correct that oversight
    > >
    > > [r->] [OFF]

    >
    >




  6. Re: Identify 48s or 48g in UserRPL?

    On Sun, 20 Jul 2008 07:32:55 -0500, Mark Edmonds wrote:

    > Actually, when looking up something unrelated in the AUR,
    > I just found this: #30794h SYSEVAL
    > which returns a string and the last letter of the string is the ROM
    > revision. I don't think the S and G ROM versions overlap (last SX ROM is J,
    > first GX ROM is K?) so I asssume this test could be used without worrying
    > about what happens to the stack.


    You could do this -- but if your program ever finds its way
    into an HP49/50 series calculator, it may instead crash,
    because most ROM addresses (input to SYSEVAL)
    were changed between the HP48S[X]/G[X] series
    and HP49G/50G series.

    The method which inspects what type of object is created
    by a "G" series command is therefore more universal,
    and will survive migration to an HP49/50 series calculator.

    An old AUR could not predict this "future" development,
    unfortunately.

    > I am not sure I understand why TYPE returns an XLib on a G
    > and not a Command but it seems all G specific commands
    > are type XLib.


    > does this mean that the new G commands are implemented
    > as a library, coupled with the original S command set?


    You guessed it -- the HP48G[X] new commands
    were made into internal library number 171 (decimal).

    On a "G" calculator, 2219 MENU will display a menu
    of some of the commands of that new library;
    2050 MENU (even on an "S" calculator) might also be of interest

    > Actually, I don't know technically what an XLib is anyway...


    This type of object does not contain a ROM address,
    but instead contains two numbers: a library number,
    and relative function number within that library.

    One reason why new functions could not have direct addresses
    is that the memory map just didn't have room for them
    (IIRC the ROM may have doubled in size!)

    Some external libraries are "installed"
    by being stored into a "port,"
    while others may be in ROM,
    but the type of object which invokes a library function,
    no matter where the library resides,
    is still that special type.

    [r->] [OFF]

  7. Re: Identify 48s or 48g in UserRPL?

    Thanks for patiently explaining all that John! - and also for reminding me
    about ROM addresses in the 49/50 models being different. Actually, yesterday
    I got a 49g in great condition for the price of a beer so I can test
    portability with that now.

    Regarding Libraries, I've always had a slight confusion with them and
    exactly what is happening when you install one and how it is used (called).
    The code I am working on now would be ideal for a lib but I'm not ready to
    start getting into the low level detail of that. I might require your
    assistance again in the future! Meantime, thanks again for all your help.

    Regards,

    Mark



+ Reply to Thread