A39 ==== As is meanwhile known, also the SysRPL-programmer can add HELP options to his library commands in the catalog from ROM 19-6 on. However, it seems that the normal user (who does not know SysRPL) can neither use this nor some other functionalities of $EXTRG in his self-made libs. For him, even no exhaustive explanation on what can really be done with $EXTPRG seems to be available. For that reason, I plan to expand the library the normal user will also be able to create libs whose commands show a HELP option in CAT. I'll make get an additional field $EXTPRG where the user just puts a list of lists of the shape {Name help text} where Name is a variable (occurring also in $VISIBLE) and help text is the text to be displayed if using the HELP option in CAT of the corresponding command. This is perhaps the most interesting functionality which has been activated by $EXTPRG in ROM 19-6. The problem of including a lib menu or some modification of it in the APPS choose box is solved since long by APPSman. Even much better, shorter and equally fast as it can be done with $EXTPRG, acting on BINT0. In ==== Hmmm, the problem with this approach is that you probably will just include this list into the EXTPRG. It is quite likely that some people will then put massive documentation strings in this, which will lead to a general slowdown of the HP. Each operation which uses messages executes the EXTPRG Rompointer, which means that the contents of the ROMPTR have to be copied into RAM. The documentation should IMO be located in a separate ROMPTR, not in $EXTPRG itself. Each EXTPRG should be small and as fast as possible in order to limit the performance penalty. I actually disagree with this. I think message 0 is really the most important one on the HP49G. The great idea about APPS is in fact that each new library can show up there automatically, in a way the ==== Hallo Wolfgang, for me, as an non-SYSrpn-user it would be more than nice. ==== I know that. Hence I plan that the additional option in also in $HIDDEN) in which the user has already prepared his list or table of help messages. This will avoid any slow-down problems. Clearly, OT49.txt will ask the user to keep his help-file small (it's in his own interest to keep his library reasonably small :-) Moreover, OT49.txt will ask *not* to include a help option on *every* visible command as you did in Emacs. This is, IMHP, a misuse of the calculator. The user must read anyway the documentation and if often applying a certain command, he will remember. Here I totally disagree with you. IMHP, message ZERO is dispensable in $EXTPR. If every library programmer appends his lib to the APPS box, it becomes quickly too long and will nerve the user. We're just on the Windows level in such a case :-). For instance, I don't need any Emacs menu in the APPS box because my Emacs configuration setting is Good idea. Less work for the user who ==== I try to recompile some not too big SysRPL programs from the HP48 to the HP49. As I'm new to SysRPL I don't know exactly what a supported entry vs. an unsupported entry means. I assume a supported entry always has a name. But are there supported entries without a name too? In some libs there are pointers like PTR 5FC24 or PTR 37DB9 and a few others which I would need in the HP49. How can I find out where the pointer moved to in the HP49. When I just find the new location of the pointer I guess that the new HP49 lib would be ROM version dependent in most or all cases :-? Am I right that the better approach would be to find out what the pointer does and try to program it's function with only supported entries. Till now I've used the hack.lib and DIS from Jazz light to get the sources on the HP48 and pasted the source to the HP49 emulator, added the @ at the end of the programs and ASM'ed it on the HP49. This does work for very simplesmall SysRPL programs. Would another way be better when I try to port a library? Greetings from Cologne Peter -- ==== I remembered reading about surfing the ROM with Jazz (full version) and found the DOB command to look what a PTR yields. That'll get me going I think :-) So long P.S.: I tried DOB from Jazz light as on my real Rev. R I only have enough memory for Jazz light, but am not sure what the input on the stack is. I'll have to try some things out. Greetings from Cologne Peter -- ==== [changing unsupported entries to supported ones - to easeallow a stable 49 port] (I make my own thread here ;-) I just had time in the subway and DOBed happily with Jazz. My not very elegant approach was to DOB the PTR's and replace them with their content. Sure that's not the smallestfastest (runtime) solution, but I thought it might get me going to get a first working port of some libs without taking too much time. That has worked so far, but I ran over one (HP48) PTR which has some ML code in it: PTR 1C731 In uentries.a (by Mika) I found: =SYSSTOF EQU #1C731 * and in entries.all it says: Does this mean I could also use xSTOF to replace it in a HP49 program? This seams to work! (That'll allow me to port at least two libs I like :-) Gotta contact the authors if they allow to release a port to the public! I looked into STOF and found CK1&Dispatch (o.k. there has to be an argument!) FIVE (what's that for?) DOSTOALLF ELEVEN (and here another one??) DOSTOSYSF Why is there a command SYSSTOF to store the system flags, when another DOSTOSYSF command is there? I tried to use the command DOSTOSYSF instead of the original pointer or the xSTOF command and this seems to work also!?!? In Eduoardo's Programming in SysRPL) the command SYSSTOF is set in braces. Why do some commands have a name, but not a real one and are not listed in the extable (thats the name of the PTR-name table, right?) Why does SYSSTOF have some ML code in it, when I also can do xSTOF to do the same thing (I guess I'm wrong, but I don't see the difference). P.S.: No I'm not programming SysRPL. I'm just curious and *want* to have some libs ported ;-) If the day would just have more hours... BTW, is there a list of the SysRPL commands available for the HP49 to have it at hand when needed? For the HP48 I think there's a lib from the same author where I already have the UserRPL reference loaded :-) Greetings from Cologne Peter -- ==== now I'm looking for a better way instead of diving into the ROM and with some tips, but still don't know how to handle this case here. I have two pointers (description from entry.all): and it's counterpart 55FA8 :: NS:SYM- How could I be lucky to find the equivalent PTR's in the HP49 and if they are expected to be stable there? Or should I stay with the solution I have now and use the memory intensive approach to replace the pointers with its contents (SysRPL commands). That blows up the size of the lib quite a bit. Although when that's the price to be paid to be ROM independent then I think it would be better than to have a smaller, but ROM dependent version. Greetings from Cologne Peter -- ==== X Argument type Argument type X ==== If you are using xNAME's in your own SysRPL progs, it would be better to use EvalNoCK on them, like: ' xSTOF EvalNoCK This avoids saving the STOF arguments as last arguments (returned by UNDO if your prog errors and you want to return the stack as it was before executing ==== I have the tutorial. Yet I don't understand why a number is put on the stack when I just store the flag settings? Greetings from Cologne Peter -- ==== I have one problem. When I try to solve sqr(x-3)+sqr(3*x+7)-sqr(2*x+10)=0 ==== The answer is 3. That expression is the same as -6 + 2x = 0 ==== Mine it is working. #1,19-5 Result: {x=3 x=-73} Input RPN ... 2X*10 sqr 0= SOLVEVX :-) ==== Mine it is working. #1,19-5 Result: {x=3 x=-73} Input with RPN ... 2X*10 sqr 0= SOLVEVX :-) I mention this, because there is no space or ENTER rqd between 2 and X :-)) Ok to your problem: What gives RCLF? or ==== Mine it is working. #1,19-5 Result: {x=3 x=-73} Input with RPN ... 2X*10 sqr 0= SOLVEVX :-) I mention this, because there is no space or ENTER rqd between 2 and X :-)) Ok to your problem: What gives RCLF? or ==== I believe that by 'sqr' he means 'sqrt', that's why it says Not reducible to a rational expression. (it is not SQ..) I'm afraid that you need to use the equation writer [EQW] then write in the form sqr(x-3)+sqr(3*x+7)=sqr(2*x+10) ==== Unfortunately, SOLVEVX will not work on this equation all by itself. However, you have two options that I can see. You can either (1) manually solve it in EQW (which I believe someone has suggested) or you can (2) make some substitutions to transform the equation into something the 49G can deal with. For example, let T = SQRT(X-3), U = SQRT(3*x+7), and V = SQRT(2*X+10). Then we can rewrite the original ==== Sorry that the information was quite unclear. OK. These sqr is sqrt (square root). Unfortunately it does not work anyway. RCLF is { # 204010FF0h # 0h # 4802000000h # 0h } ==== to him: It's a very powerful method :-) ) Do the following : ['T^2 = X-3' ' U^2 = 3*X+7' 'V^2 = 2*X+10'] LNAME (you get ['T' 'U' 'V' 'X']) SOLVE (If you're in VERBOSE mode then you'll notice that it's using Grobner basis: GBASIS :-) ) now, you get the solution { [ 'T=0' 'U=4' 'V=4' 'X=3' ] ==== Well, I did exactly as you typed ist, but after entering SOLVE I receive an error: SOLVE Error: Problem Uninitalized ==== I would like to mention that I keyed in SOLVE, i.e, [alpha][alpha]SOLVE[Enter] ==== Actually, I keyed in SOLVE. If I try SOLVE from the solver menu I'll get an Invalid Dimension error. What's wrong here? ==== oops!! It's my fault. I beg your pardon :-) I forgot to add the equation 'T+U-V=0'.. We want to solve the equation sqrt(x-3)+sqrt(3*x+7)-sqrt(2*x+10)=0, where T^2 = x-3 U^2 = 3*x+7 and V^2 = 2*x+10 So, use ['T^2 = X-3' ' U^2 = 3*X+7' 'V^2 = 2*X+10' 'T+U-V=0' ] (There are 4 variables and hence we need 4 equations, that's why you get the Invalid Dimension error) The reason why we are doing this is to reduce our problem consisting of solving a complicated equation with radicals into that of solving a system ==== Let me try to summarize what's going on here. Here's scenario #1. :2: [three EQs] :1: [doesn't matter how many VARs of those EQs] If I *key in* SOLVE or invoke it via CAT, I'll get the Problem Uninitalized-error. And here's #2. :2: [three EQs] :1: [more than three VARs of those EQs] If I invoke SOLVE from the solve-menu, I'll get an Invalid Dimension-error. BTW: The order of SOLVEVX and SOLVE depends on how the SOLVER-menu ==== Yes, the menu should, for the Users sake, read, say: SOLVX which could also be a new Nick-name to that command etc.... and some in a ~ way: but, then sometimes a new Command has been added and the old retained as a Cataloged name as well: COLLECT vs. COLCT EXPAND vs. EXPAN TAN2SC2 does no more take care of prefer sincos flag, use the new command TAN2CS2 etc... AND new functionality has been added often, like: XLIB~ finally works both ways TABVAR accepts now some non rational functions: e.g. EXP(X)-X EXPAND does now EXP2POW (convert EXP[c*LN] to power) SOLVE SOLVEVX can solve 1 rational inequality in 1 var Step by step implemented for: integration, GCD and IEGCD for integers, PARTFRAC SOLVE LINSOLVE accept systems written as a symbolic: use AND between equations You can now create your own user functions and combine functions together like: Y2(X)=Y1(SIN(X)). Symbolic series: SUM(I=1,N,I) will return (N^2+N)2 & Totally new ways to operate have been added: 2: Real 1: unit string old functionality has been returned, like MINIT, MITM, MROOT, MSOLVR, MUSER & external libraries have been integrated to the calc: Lib789 by Parisse: EXP2POW, DISTRIB, FDISTRIB, MSLV, POWEXPAND and there has been various versions of ASM, ASM2, asm, ER, er both internal & external AND AND ... ==== I managed to port an old library (from 1993) for the HP48 to the HP49, but can't contact the author. As this program is free (as nearly all HP4X programs) - can I release this port? Surely I'll include the original docs and mention what or if I have changed something. Greetings from Cologne Peter -- ==== One for the experts: How easy is installing this new ROM over 1.18? It looks complicated compared to Installing 1.18 over the original Rom which I have done successfully many moons ago. Don ==== little bit of user FLASH rom (port 2). So there is additional steps required if you have stuff stored in your port 2 memory, specifically bank 0. These steps allow you to temporarily copy the affected portion of the bank 0 flash memory to RAM so you can later re-install them after you upgrade to 1-19.6. Its not scary or hard, just follow the directions. Once you have made the jump, you dont need to do it again, further rom upgrades wont spill into bank 1. I've serached RPLMAN.doc and Programming in SysRPL (by Eduardo K.) to answer my question, but was out of luck. ROMPTR AB 61 instead of the expected xTAIL. I know I've asked a similar question a long time ago, but can't find the reference :-( Why does this happen here, while most other commands DISsasemble to their xCOMMAND form. In addition I just tried if Jazz would be able to ASSemble xTAIL as a command and that works! Isn't that strange? So what's the differencecommon between a PTR, a ROMPTR and a user command? Might that knowledge help me to find an equivalent command on the HP49, when I try to port a library? Greetings from Cologne Peter -- Great HP4849 links: ==== A user command is nothing more than a human readable alias of ascii characters that is *parsed* and converted into its associated object. When you type in a command, the parser calls the unsupported entry point COMPILEID ( GX: # 7C18h ) which looks up the name and converts it into a pointer or a ROMPTR depending on if the library that the name resolves to is in uncovered ROM or is someplace else respectively. Now that we have that out of the way, let me explain the behavior of Jazz. When ASS encounters xSOMETHING it basically does the same thing as the internal COMPILEID. Jazz doesn't know about the user command SOMETHING any more than COMPILEID does. It just mindlessly searches the hash tables. This is why any user command will compile with Jazz. On the other hand, when you DISassemble something the process is different. If you're disassembling a pointer and Jazz can't find it in it's entry tables it then looks at it to see if it is a library command . This is possible due to the fact that all named library commands whether in ROM, a port, or temporary memory ( copied from a covered portROM ) are preceded by their own 6 nibble ROMPTR body. If the potential ROMPTR body is valid and references the object then Jazz retrieves the name from the associated library's hash table *if the library is not covered*. When disassembling ROMPTR objects Jazz just looks up the command in the associated library's hash table and again *only if the library is not covered*. So, we see that if Jazz spits out a ROMPTR at you when you're expecting it to resolve the PTRROMPTR to a user command name then you know that the command is covered. There is no fundamental limitation with decompiling the names of covered library commands it is just that the authors of Jazz chose not to implement it for some reason ( The built in 48 decompiler has no problem with this ). Probably the easiest way to get the 49 equivalent of a 48 user command is to type it into the 49 emulator and decompile the resulting PTRROMPTR :). But be warned that ( I might be wrong on this ) the ROMPTR's for 49 user commands have been known to change between ROM revisions. If this is true then you might want to do something like this : http:groups.google.comgroups?selm=3uhfdtkkd0bmh3gdh0sc424b2p1l95dpte%404a x.com but possibly more sophisticated. For example, you could compile all the user command names you use at startup and store them in a table - a kind of dynamic linking . palparse might cause problems though because of its extreme slowness so you might have to write a custom assembly language COMPILEID unless the equivalent entry point in the 49 is stable ;). Hope this helps... ==== X X ==== Just purge the sigmaPAR from all the directories in the tree Just to be sure, did you also PURGE and created sigmaPAR again in the ==== This is some code in user RPL that I had to write to compensate for the ever returning need (and significant lack of HP) of sequence handling. I am posting it here in the hope of some comments and suggestions. It works OK on my HP49 in RPN mode. Usage example : put '3*S(n-1)-4*S(n-2)+1' for f() in first field, [1 1] for initial values and 5 for number of terms and you will get the ouput of the first five terms : [1 1 0 -3 -8]. Ç DO Sequence { { f() S(n) =f(S(n -1 ),S(n - 2),...) } { Init. Values [S(0) S(1)...] } { N Number of Terms } } 1 { NOVAL [ 0 ] 10 } { NOVAL [ 0 ] 10 } INFORM IF 0 == THEN KILL DROP SWAP DUP 'S' 'FROM' STO S SWAP RDM 'S' STO 'f' STO FROM 1 + N FOR n1 'S' n1 n1 'n' STO f NEXT 'S' N EDITB UNTIL 0 ==== This can be done with a simple recursive definition. Suppouse you have: S(n)=3*S(n-1)-4*S(n-2)+1 with, say, S(0)=1 and S(1)=1 Got to the EQW and TYPE: S(n)='IFTE(n==0,1,IFTE(n==1,1,3*S(n-1)-4*S(n-2)+1))' Now press ENTER and DEF. In the menu VAR you have now a soft menu button for S. Type some number and then press this soft menuy key. You get the result for this number. If you want the results for a range of input values (say from 0 to 5) in a vector, you can use something like: << {} 0 5 FOR I I S NEXT AXL ------snipped lengthy part------ Indeed! I remember a previous thread, where similar things were discussed. The HP49G would also allow to make user defined functions with memory, that means functions that store previous calculated results (even in their own code, even in User RPL), and access them when they are needed again. So repeated calculation of already known results is much more speedy. Especially for recursively defined functions this can speed things up, if at some point of the recursion a known result appears. (When S(50) must be calculated and S(45) is already known and stored.) Greetings, Nick. P.S. The recursively defined function is slow, but its straightness and elegance, as you said, have always fascinated me. :) ====