Identify 48s or 48g in UserRPL?
in [HP48]
|
From: Mark Edmonds on 19 Jul 2008 09:28 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
From: John H Meyers on 19 Jul 2008 19:50 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]
From: John H Meyers on 19 Jul 2008 20:23 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]
From: Mark Edmonds on 20 Jul 2008 08:08 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" <jhmeyers(a)nomail.invalid> wrote in message news:op.uekd0we0nn735j(a)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]
From: Mark Edmonds on 20 Jul 2008 08:32
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" <nomail(a)nomail.com> wrote in message news:r8KdneUxiekItx7VnZ2dnUVZ8uGdnZ2d(a)posted.plusnet... > 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" <jhmeyers(a)nomail.invalid> wrote in message > news:op.uekd0we0nn735j(a)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] > > |