SYSEVAL Question
in [HP48]
|
Prev: Is HP getting serious about calculators?
Next: HP 50G USB power & running faster - auto shift from 75Mhz to 203Mhz
From: LINEABOVE on 8 Oct 2006 22:15 Would somebody be kind enough to explain what HP 49g+ # 2EE67h SYSEVAL and # 2C2F9h SYSEVAL might do ? May I "convert" these 2 commands into URPL ? I am not looking for "speed" in execution and it does not matter to me if the program "grows" in size. What I am trying to do is understand the program flow, and at this time "SYSEVAL" is way over my head. Thanks
From: manjo on 9 Oct 2006 09:56 > Would somebody be kind enough to explain what HP 49g+ > # 2EE67h SYSEVAL and > # 2C2F9h SYSEVAL might do ? > > May I "convert" these 2 commands into URPL ? > > I am not looking for "speed" in execution and it does not matter to me > if the program "grows" in size. What I am trying to do is understand > the program flow, and at this time "SYSEVAL" is way over my head. > > > Thanks Hello, SYSEVAL is a simple way to execute SYSRPL commands and ROM ML (machine language) routines within your USERPL program. In order to do that you must know the valid entry points (numbers are entry point addresses) NOTE: if you're aware what you're doing this is a good way to introduce several SYSRPL or ML routines/commands in to critical part of your USERPL program. HOWEVER if you miss one digit while typing the address -you may get very heavy TTRM (try to recover memory) routine/error :-) So, use with cauton, use wisely, and don't over-use ! In any case get yourself a list of supported/valid entry points. In your case these two are: # 2EE67h SetDA1Valid (i'm not sure about this, but this seem to mark header to be valid -no need for refresh) # 2C2F9h DispStsBound (this draws the bottom line of the header) (i don't thin there are suplements in USERRPL for these) Guesswork here: -in other words your program most probably writes something in the header (DA1) area, marks it as valid and redraws the header bottom line (hoping that it will stay that way for a while :-) of course if you have a visible timer in header line it may interfeere with your program :-) have fun !! manjo
From: LINEABOVE on 9 Oct 2006 10:27 Thank you for your info Manjo. I am strictly at the User RPL level for writing programs. I wonder why people use SYSEVAL to begin with. For example, when another ROM version is introduced, or a change of calculator from say HP 48 to HP 49, the SYSEVAL's may be different. Once this happens your program is useless until you redetermine all the SYSEVALS. (If they are still "supported".) I am playing the FIF program originally by Joseph Horn. http://www.hpcalc.org/search.php?query=fif It was updated for the HP 49 by Steven Sandhorst http://www.hpcalc.org/details.php?id=4824 In both versions, the program will not deal with negative value input/ouput. For example, when you ADD -3' to 2' you obtain 1 instead of -1. So, I have been tweaking and have been successful to recognize negative input and ouput. I have futher tweaked so that you can apply a user defined value for the denominator which allows for rounding of values to your needs. The downside with these tewaks is that you are limited to adding or subtracting ONLY. That being said, I have 2 SYSEVAL (previously mentioned) within the program and I am concerned that when the ROM or HP model changes, the program will be useless until somebody with the knowledge takes the time to "port" the program over. (If it is even possible). This is why, I would much rather use User RRL than SYSEVAL.. Even at the cost of execution speed or program size. I will continue to tweak this program using your interpretation of the SYSEVAL and see where it leads. With any luck we will have a 3rd Version of the FIF program at hpcalc.org in the near future. Your information is very helpful Majo. Thanks manjo wrote: > > Would somebody be kind enough to explain what HP 49g+ > > # 2EE67h SYSEVAL and > > # 2C2F9h SYSEVAL might do ? > > > > May I "convert" these 2 commands into URPL ? > > > > I am not looking for "speed" in execution and it does not matter to me > > if the program "grows" in size. What I am trying to do is understand > > the program flow, and at this time "SYSEVAL" is way over my head. > > > > > > Thanks > > Hello, > > SYSEVAL is a simple way to execute SYSRPL commands and ROM ML (machine > language) routines > within your USERPL program. > > In order to do that you must know the valid entry points (numbers are entry > point addresses) > > NOTE: if you're aware what you're doing this is a good way to introduce > several SYSRPL or ML routines/commands > in to critical part of your USERPL program. > HOWEVER if you miss one digit while typing the address -you may get very > heavy TTRM (try to recover memory) routine/error :-) > > So, use with cauton, use wisely, and don't over-use ! > In any case get yourself a list of supported/valid entry points. > > In your case these two are: > # 2EE67h SetDA1Valid (i'm not sure about this, but this seem to mark header > to be valid -no need for refresh) > # 2C2F9h DispStsBound (this draws the bottom line of the header) > (i don't thin there are suplements in USERRPL for these) > > Guesswork here: > -in other words your program most probably writes something in the header > (DA1) area, > marks it as valid and redraws the header bottom line (hoping that it will > stay that way for a while :-) > of course if you have a visible timer in header line it may interfeere with > your program :-) > > have fun !! > manjo
From: manjo on 9 Oct 2006 12:19 > I am strictly at the User RPL level for writing programs. > I wonder why people use SYSEVAL to begin with. SYSRPL is much more powerfull as i said SYSEVAL is a way to execute SYSEVAL commands inside your USERRPL program (some things you do in several USERPL commands may be done in a SINGLE SYSRPL command) -there are many commands which, either do things quick and easy, or do things which simply can't be done (in a reasonable manner) in USERPL. > For example, when another ROM version is introduced, or a change of > calculator from say HP 48 to HP 49, the SYSEVAL's may be different. > Once this happens your program is useless until you redetermine all the > SYSEVALS. (If they are still "supported".) True, you can never be 100% sure but i am quite sure that currently valid entry points will not move -that's the idea "supported" entry point. (i didn't check but i don't think any of the supported entrypoints moved in all ROM versions currently available for G+) SYSRPL is based on these supported entrypoints so if these would shuffle around uncontrolled -it would be impossible to keep the compatibility between ROM versions. What i'm sugesting is: Try not to definitely resign things like SYSEVAL, because these will make your work simpler and faster :-) so much for now, keep up the good work manjo
From: John H Meyers on 9 Oct 2006 17:53
On Mon, 09 Oct 2006 09:27:49 -0500, LINEABOVE wrote: > I am strictly at the User RPL level for writing programs. > I wonder why people use SYSEVAL to begin with. SYSEVAL allows you to make use of any of the thousands of additional internal OS functions within any UserRPL program; it allows you to write a program almost entirely in UserRPL, but to call some otherwise unavailable internal OS function when you find that no UserRPL function comes close enough to what you want to do. As an example, if you want to compile any string (which means to produce what would result if the text were typed into the command line and executed), you can use STR\-> on the string, e.g. "1.2345" STR\-> will produce the real number 1.2345 However, what if an unknown string which someone presents to your program to parse contains "OFF"? If you do "OFF" STR\-> then your calculator will turn off, because OFF is an executable command (imagine what would happen if other, more harmful commands were in the string!); however, \->STR #2EF62h SYSEVAL DROP can be safely used in place of STR\-> (in 49-50 series *ONLY*), and in the case of the string "OFF" will produce the *unevaluated* command OFF on the stack. In fact, the complete program below can be used to safely compile any string, because it will never execute any commands in the string; it will also always produce a single result, no matter how many separate results would be produced by STR\-> (try each method on "1 2 3" for example). @ Safe string compiler for 49-50 series *ONLY* (includes 48Gii) \<< \->STR #2EF62h SYSEVAL #3AC0h SYSEVAL SAME { DROP2 #106h DOERR } IFT \>> @ Safe string compiler for HP48S[X]/HP48G[X][+] *ONLY* \<< \->STR #238A4h SYSEVAL #3AC0h SYSEVAL SAME { DROP2 #106h DOERR } IFT \>> For those interested, the supported entry point names corresponding to the above absolute addresses are "palparse" and "FALSE" > When another ROM version is introduced, > the SYSEVALs may be different. There are a couple of thousand "supported" (fixed location) entry points which may be safely used among all ROM versions for the same series of calculators (such as the two series mentioned above); if you install the original "extable" library for the 49-50 series and its GETNAME command accepts an address and returns a name, then that address is a "supported" entry point, and HP has committed to making that address stable in all ROM versions for the current product. > on a change of calculator from say HP 48 to HP 49, > the SYSEVALs may be different. Yes, many supported entries were relocated at that one time when the HP48 series ended and the HP49 series began, but *not* between any of the different ROM versions for the same product series. It is even much easier to maintain these addresses for the current series, because most of them are packed into special areas now reserved solely for entry point locations, with some spare locations for expansion. > Once this happens your program is useless until you redetermine > all the SYSEVALS. (If they are still "supported") Not only that, but most any HP48 binary program file at all, even if pure UserRPL, became incompatible with the new HP49 series, because even the addresses of most "user" commands changed at the same time (your programs, once entered, are translated into the current set of absolute ROM addresses of each command; whenever you see your program appearing again as text, that text has been produced by a *decompiler*, translating the absolute addresses back into readable commands). However, any program in source (text) form could simply be re-entered into the new series, and would then generally work as before, and it so happens that there is a nearly equivalent way to re-compile UserRPL programs containing SYSEVALs, found at either of these locations: http://www.hpcalc.org/search.php?query=syseval+translator http://groups.google.com/group/comp.sys.hp48/msg/b4c1512ee44cbda9?dmode=source Best wishes from http://www.mum.edu and http://www.maharishischooliowa.org |