d-21 === Subject: Re: Installing ARMtoolbox > the message should be: > STO error: Bad argument type... READ CAREFULL THE INSTRUCTIONS Just to make it clear: I didn't put any insulting messages in the toolbox!! The OP got the message from STO, not from the toolbox, so it had to be the standard calculator message and he added his own comment. The OP was simply using an incorrect syntax for STO, because the object is not a library, therefore the correct syntax to store an object in a port would be: 2: program 1: :0:'AnyID' STO In any case, that's not how you install the ARMtoolbox.You can't install it by doing STO, you need to EVAL the install program: 2: 0. (or 1. or 2., any port is fine) 1: setup.bin program EVAL The ARMToolbox should install fine on any port on both emulator and real calc. As for trying to run it, it depends on how the emulator handles the ARMSYS/ARMSAT opcode. If it ignores it (most likely), then trying to run an ARM program with the toolbox should return with no consequences. The rest of the toolbox should produce the expected results (alignment of ARM programs, etc.). Claudio === Subject: Re: PrLNK Error:Not an ARM program <4643c4F996saU1@individual.net> > Yeah! > I used the install.bin, and problem is over. > However, maybe be good to change this on chapter 1 of HPGCC online > tutorial. > Cause one who try to follow it may go search for a lib275.lib file like > I did. Sorry about that, hpgcc changes faster than the documentation. We can barely keep up with the source code changes, documentation is very hard to keep updated. We put all our effort in keeping the docs updated for the library functions (most important). The tutorial is not even close to the top of our priorities list, and we keep adding new stuff all the time. It's true that this particular installation step has changed since version 1.1 and the tutorial may mislead some users. We'll update the tutorial when we have a chance. Claudio === Subject: Re: PrLNK Error:Not an ARM program <4643c4F996saU1@individual.net> Hello Claudio, Unfortunatly I don't have enough hp49G/Cknowledgement to make HPGCC documentation by my own. But if I can help organizing information and making them look nice, I'm available. >Claudio Rui === Subject: EE?Pro / EEPro / EE Pro: for HP 49 > Brian, > I would like to know the status of your EE*Pro for the HP49 and if ready > where I can purchase it. Sorry for such a long delay. EE*Pro was actually finished way back in October. It took a bit longer to get the documentation finished. Still, it should have been released months ago. A bunch of things conspired to cause the delay. I won't go into the details, but it should be released within the month. BTW, The library supports the full 49G+ display. === Subject: Re: EE?Pro / EEPro / EE Pro: for HP 49 <11nl1bm5mda4g1e@corp.supernews.com> <11t55go59rrgm5c@corp.supernews.com> <43jn01F1nka0rU1@individual.net> <11tnegushc1ru6e@corp.supernews.com> This message might appear a few times under a different thread. I tried replying on a computer that only had Outlook Express, and it decided to post it under a thread of it's choice. Let's hope it works correctly in Google Groups. > Brian, > I would like to know the status of your EE*Pro for the HP49 and if ready > where I can purchase it. Sorry for such a long delay. EE*Pro was actually finished way back in October. It took a bit longer to get the documentation finished. Still, it should have been released months ago. A bunch of things conspired to cause the delay. I won't go into the details, but it should be released within the month. BTW, The library supports the full 49G+ display. === Subject: EE?Pro / EEPro / EE Pro: for HP 49 > Brian, > I would like to know the status of your EE*Pro for the HP49 and if ready > where I can purchase it. Sorry for such a long delay. EE*Pro was actually finished way back in October. It took a bit longer to get the documentation finished. Still, it should have been released months ago. A bunch of things conspired to cause the delay. I won't go into the details, but it should be released within the month. BTW, The library supports the full 49G+ display. === Subject: Re: New OPENFIRE Library Release >> Is it possible to _create_ grayscale graphics from UserRPL? >> I have the feeling you could use openfire to display stills only ... >> I hope I am wrong, am I? >Well you are wrong (i hope) :-) >animations, numerous effects... are possible, well that is moving of static image data ... what I meant by stills I would need something to at least put a grayscale pixel onto the display using userrpl ... the sand-demo is nice, but it just copies lines from a static image .... you see what I mean >-you can use UserRPL or SystemRPL as well (you would use POKE function or >REPL) any starters for new users? I know to programm ... but >-you will realize that elements used to create user interface or game are in >fact bitmaps. well .. on a calculator maybe .. otherwise I would use 'scaleable' elements to be able to user different resolutions but how do I render something using bitmaps? (do not tell me to use one bitmap for each possible grayscale-pixel ... that sounds pathetic) thnx anyway === Subject: Re: New OPENFIRE Library Release > (do not tell me to use one bitmap for each possible grayscale-pixel > ... that sounds pathetic) Hello Sascha, If you're not familiar with assembler : -use POKE and address returned by INITGS, -with POKE you can write many in-line pixels at the same time. -PEEK will read them (of course) Here's the quick guide : BASE ADDRESS is the FIRST parametter returned by INITGS, NOTE: this approach is different from SAND demo and my other demos which use bitmaps. example 1: << INITGS DROP 0123456789ABCDEF0123456789ABCDEF POKE 0 WAIT DONEGS -this will give you 2 short shaded lines in the first display line starting from top-right corner shaded from left to right You will need to calculate the address of your pixel using following fromula: BASE+160*Y+X (80 bytes in line = 160 nibbles) example 2: << INITGS DROP -> B << 0 80 FOR T B 160 T * + T + F POKE NEXT 0 WAIT DONEGS -this will make a diagonal line from up-right corner 0,0 to 80,80 using darkest shade It is a bit slow (userRPL) but simple. -very good to ilustrate the basics, -with optimized sysRPL you can get faster, although for optimal speed i recommend assembly. UserRPL is good only for less dynamic games using bitmaps as i described earlier, sysRPL is better but all great games are written combined sysRPL-assembly or pure assembly. For more details read readme.txt and history.txt have fun === Subject: Re: New OPENFIRE Library Release my calc does react on poke with 'poke' i.e. he does not know it ... how to get it? (I ask you because I want it to be compatible to openfire ;) ) === Subject: Re: New OPENFIRE Library Release > my calc does react on > poke > with > 'poke' > i.e. he does not know it ... how to get it? > (I ask you because I want it to be compatible to openfire ;) ) I'm not sure i think emacs or extable2 automatically attaches built in library 256 OR attach built in development library 256 type: 256 attach === Subject: Re: New OPENFIRE Library Release Development Library eg. 256 MENU POKE note capital letters Better have either OT49 lib attached or << { 256 } ATTACH >> 'STARTUP' STO > my calc does react on > poke > with > 'poke' > i.e. he does not know it ... how to get it? > (I ask you because I want it to be compatible to openfire ;) ) === Subject: Re: New OPENFIRE Library Release ... >F POKE NEXT FF would make a two pixel horizontal line, right? === Subject: Re: New OPENFIRE Library Release >F POKE NEXT > FF would make a two pixel horizontal line, right? Of course ! 770F0770F077 would make light dash-dot-dash-dot-dash line with dark dots :-) === Subject: Re: New OPENFIRE Library Release >If you're not familiar with assembler : >-use POKE and address returned by INITGS, >-with POKE you can write many in-line pixels at the same time. >-PEEK will read them (of course) >Here's the quick guide : ...*snip* very good thnx a lot! === Subject: Re: New OPENFIRE Library Release > Skywings a ?crit dans le message de >> One could alway try to port the TI's version of Zelda, which is written in >> C with full source available. > Only C or mixed with ASM ? I don't actually know. Just casually browsing the TI software repository for interesting programs, I noticed Zelda was listed as a program with C source code. I suppose I could just download it and have a look, but, you know... -- Skywings === Subject: simul8 Tutor wanted Hi - can anyone help me find a simul8 tutor to help one of our students? Ed www.tutoreasy.com === Subject: Re: simul8 Tutor wanted On 24 Feb 2006 03:45:23 -0800, ed@tutoreasy.com >Hi - can anyone help me find a simul8 tutor to help one of our >students? On calculator?... A.L. === Subject: Re: HP 49g+ Broken display <43fe2f3c$0$97815$892e0abb@auth.newsreader.octanews.com> Can this be done? I opened the 49, but I doubt if I have enough courage to solder this thing. Any recommenations? === Subject: Re: HP 49g+ Broken display Very Cool Is there a schematic developed for the HP49G+ yet? I've seen schematics for the 48G, but not the 49G+ and 48GII. A serial interface would be most helpful. One would hope that we can get to the serial interface signal(s) between the processor and the IRDA interface circuit. [?] Tomcee > I'm using my HP49g+ for over a year now. Last week my display went > black, that is most of the time. Shaking the device will sometimes give > me a normal display again, So I suspect that some connections may be > bad. > That's not an HP49g+ you're using. That's an Etch-A-Sketch. :) > But seriously, here's information on taking your HP49g+ apart: > http://www.hpcalc.org/details.php?id=5896 === Subject: Re: HP 49g+ Broken display Is there a schematic developed for the HP49G+ yet? I've seen schematics for the 48G, but not the 49G+ and 48GII. A serial interface would be most helpful. One would hope that we can get to the serial interface signal(s) between the processor and the IRDA interface circuit. [?] Tomcee > Very Cool > Is there a schematic developed for the HP49G+ yet? I've seen > schematics for the 48G, but not the 49G+ and 48GII. > A serial interface would be most helpful. One would hope that we can > get to the serial interface signal(s) between the processor and the > IRDA interface circuit. [?] > Tomcee > > I'm using my HP49g+ for over a year now. Last week my display went > > black, that is most of the time. Shaking the device will sometimes give > > me a normal display again, So I suspect that some connections may be > > bad. > That's not an HP49g+ you're using. That's an Etch-A-Sketch. :) > But seriously, here's information on taking your HP49g+ apart: > http://www.hpcalc.org/details.php?id=5896 === Subject: Re: HP 49g+ Broken display > Is there a schematic developed for the HP49G+ yet? I've seen > schematics for the 48G, but not the 49G+ and 48GII. > A serial interface would be most helpful. One would hope that we can > get to the serial interface signal(s) between the processor and the > IRDA interface circuit. [?] I believe JYA stated that he has done it. Although I guess he is one of the best placed persons to do it around here. However I am not sure he is allowed to issue the diagrams. Arnaud === Subject: HP49G+ Emulator / HPGCC I use EmuGaak Emulator. My propose is to test small programs made with HPGCC in PC. So, 1.bc Does anyone knows an emulator which can run ARM Tools? 2.bc At Hp website I've found an HP49G+ emulator just for educators. Does anyone tried? Does anyone know if it could serve my propose? 3.bc I have some c knowledges but almost none of HP49G+ programming. Is there a big risk to damage my calculator with this beginner programing? Rui === Subject: erfc function on hp48 Hi there, I am looking for either the erfc function key? or the Q (complementary CDF -tail ). I have misplaced my manual. any kind folk. === Subject: Re: erfc function on hp48 > I am looking for either the erfc function key? > or the Q (complementary CDF -tail ). Not sure if this is what you want, but the following functions are built in: UTPF - upper-tail (cumulative) distribution function for the F distribution Other related functions are: UTPC - upper-tail (cumulative) distribution function for the chi squared distribution UTPN - upper-tail normal distribution UTPT - upper-tail (cumulative) distribution function for the t-distribution As far as the erfc (and erf) functions go, here are some simple UserRPL programs: @ ERFC(x) - complementary error function << 0. .5 ROT UTPN 2. * >> @ ERF(x) - error function << 0. .5 ROT UTPN -2. * 1. + >> Or if you prefer, here are SysRPL equivalents: for erfc(x): RPL :: %0 %.5 xROT xUTPN %2 %* ; and for erf(x) RPL :: %0 %.5 xROT xUTPN %-2 %* %1+ ; Hope this helps, -wes === Subject: Re: XC - the secret society X > To set up your hassle-free CAS environment on 49G[+]: X [MODE] Angle Measure....Degrees @ set to Degrees using [+/-] [ENTER] 'COS(60.)*X' INTVX @ remember to use the command line ENTRY I can see why keep the flag settings pledge never appealed to Parisse Too much hassle with arguments How to cope with? 1) Avoid anything but RAD => you have to convert all the angle arguments 2) use integers and or rationals with integers as arguments 3) use angle units Please verify the above F-P === Subject: Re: XC - the secret society On Fri, 13 Jan 2006 23:11:17 -0600, VPN, > 'COS(60.)*X' INTVX > How to cope with? > 1) Avoid anything but RAD > => you have to convert all the angle arguments > 2) use integers and or rationals with integers as arguments > 3) use angle units Doing ->Q just before INTVX, I get the answer 'COS(60)/2*X^2' which looks right to me. If you then do EVAL or ->NUM, you'll get whatever angle unit interpretation your current flags ask for, and those mode settings are whatever you wanted them to be, unchanged when INTVX was evaluated using XC. YMMV and YADYA [r->] [OFF] === Subject: Re: XC - the secret society > Doesn't seem to work in Algeraic Mode? ROTFL -- so you've become an ALG mode user, now? IIRC, the ACO team decided way long ago to disable Vectored Enter in ALG mode; maybe you can find a way to re-enable it for yourself :) [r->] [OFF] === Subject: Re: XC - the secret society >> Doesn't seem to work in Algeraic Mode? > ROTFL -- so you've become an ALG mode user, now? You got my hjuumor? Strange? > IIRC, the ACO team decided way long ago > to disable Vectored Enter in ALG mode; > maybe you can find a way to re-enable it for yourself :) Poor Avenard was so lazy a programmer that he could not do auto-quoting in ALG mode without using the V-ENTER for that It happened @ 1.19-3 === Subject: Re: XC - the secret society Looks as if this year's vintage will be just like previous years. Another opportunity lost. When you work you are a flute through whose heart the whispering of the hours turns to music. And what is it to work with love? It is to weave the cloth with threads drawn from your heart, even as if your beloved were to wear that cloth. - Kahlil Gibran (The Prophet) === Subject: Re: XC - the secret society Does it work unindependently of flag -55 ??? === Subject: Re: XC - the secret society It works best under the Swiss flag, I think :) === Subject: Re: XC - the secret society > It works best under the Swiss flag, I think :) Be aware, Long-John! That was OFF-TOPIC Strike one! A terrible future waits for you: Strike three and you end up on a KILL-file !!!! [no, not mine, silly, to the Net-Cops...] F-P PS: I think that you should trice a year republish XC === Subject: Re: XC - the secret society On Fri, 13 Jan 2006 16:44:18 -0600: > I think that you should trice a year republish XC I don't recall reading anyone's experience using it, so perhaps it is not worthy or else not well offered, and I figure that this ought to be its last promotion. [r->] [OFF] === Subject: Re: XC - the secret society > On Fri, 13 Jan 2006 16:44:18 -0600: > I think that you should trice a year republish XC > I don't recall reading anyone's experience using it, > so perhaps it is not worthy or else not well offered, > and I figure that this ought to be its last promotion. > [r->] [OFF] I use it quite regularly, and it smooths a lot of operations out that used to bug me badly. I have expanded the library to include many of the commands one uses XC with. My code is to use the original command name with a . appended to it. So, for example, instead of SOLVE I can use SOLVE. representing the program << {SOLVE} XC >> in my version of the library, and so on. === Subject: Re: HP28S (ROM) to download the Hp-28S ROM. It's a little over 128K which exceeds the configuration is even possible. === Subject: Re: HP28S (ROM) Howard Owen schrieb im Newsbeitrag > to download the Hp-28S ROM. It's a little over 128K which exceeds the > configuration is even possible. On an HP-48SX, you can merge *both* port 1 and port 2, Raymond === Subject: Re: fscanf() and hpgcc I've done a few tricks of my own...and I'm now certain that I will probably make some very tiny custom sprites to correctly display a-t, albeit it will be very tiny. HpGnuGo is coming along very well. The only thing left is to modify the rules displayed at the beginning and to get endgame() working correctly. After that, its ready for a first release. === Subject: Re: HP 48 Card Hello Is-it easily to install the ram card 4x128kb for 48sx ? Do you know if you must open the calculator to install ? === Subject: Re: HP 48 Card > Is-it easily to install the ram card 4x128kb for 48sx ? Do you know if > you must open the calculator to install ? The Klotz 4 X 128KB card has tiny slide switches, so you can select into slot 1 or 2 of the calculator, the same as an original as described in chapter 34 of the 48SX Owner's Manual. It also has a coin cell battery memory back-up, and a write-protect switch, the same as the original HP card. It is somewhat expensive, but worth the money. Ed === Subject: Re: HP 48 Card Do you know it's expensive ? === Subject: Re: HP38/39: How to set DEG mode? Speaking as an experienced maths teacher and someone who has used both algebraic and RPN calculators IMHO it is easier to teach with an algebraic calculator. Before you all start jumping all over me, I don't mean for the top students. The top 15% of students will grasp RPN quickly, see the advantages (which I agree exist) and come to love it as most of you do. But they will be equally adept with either system. HOWEVER... the middle strata of students will gradually grasp it but probably never like it much. The lower ability students will generally never really grasp it and will tend to make mistakes. Ok... I stress that this has simply been *my* experience. As far as I know there have not been any proper comparative studies done on achievement levels of students using RPN vs algebraic so that's all it can be - an opinion. Anyone know of any HARD DATA? As opposed to rants I mean? As an aside, I've been using the 38G, 39G & 39g+ in my classroom since they were first released in the nineties. IMHO they are absolutely brilliant calculators despite the keyboard problems that have plagued them since the 39G. One of their major pluses is the way that you can swap from aplet to aplet and environment to environment with no loss of data and no need to ascend and descent through complex menus. >>the worse ever missing feature: >>* * * RPL * * * > Why are you so angry. This calculator wasn't meant for you. It was > meant for high school students who really don't have much interest in a > calculator beyond ease of use and games. For what it was *designed* > for, it is an exceptional calculator. For price/performance, it > probably beats any other high school calculator out there. The new > 40GS beats anything. > TW === Subject: {0} DUP NEG == On the hp49g+, ROM build 88, {0} DUP NEG == returns 0. return 0, but why should == return 0? In case it matters, {1} DUP NEG NEG == also returns 0. -jkh- === Subject: Re: {0} DUP NEG == > On the hp49g+, ROM build 88, {0} DUP NEG == returns 0. I assume you know that it is the same on 49G rom 1.19-6, and that it is the list processing which fails, e.g. { 5 } { 5. } == or { 500. } { 500 } == all do the same. [r->] [OFF] === Subject: Re: {0} DUP NEG == Perhaps an expanded list of results will clarify how we know that it's solely due to list processing (and is probably long known, but may not have been deemed worth the effort that might be needed to solve so weird and unusual a case): Start in Exact mode ( -105 CF ) 5 5. == Answer 1. { 5 } { 5. } == Answer 0. 500. 500 == Answer 1. { 500. } { 500 } == Answer 0. On the other hand, { 5. } { 5. } == Answer 1. { 500 } { 500 } == Answer 1. { 5 } DUP NEG NEG == Answer 0. { 500 } DUP NEG NEG == Answer 1. As you can see, when both arguments are lists, and varies in the last cases because of internal substitution of a ROM object result for certain small integer values. [r-> ][OFF] === Subject: Re: {0} DUP NEG == > On the hp49g+, ROM build 88, {0} DUP NEG == returns 0. > return 0, but why should == return 0? > In case it matters, {1} DUP NEG NEG == also returns 0. Joe, The first {0} decompiles as { Z0_ } The second, after DUP NEG, as { ZINT 0 } so they're not == . Is this a bug? Don't know. Chuck === Subject: Re: {0} DUP NEG == >> On the hp49g+, ROM build 88, {0} DUP NEG == returns 0. >> return 0, but why should == return 0? >> In case it matters, {1} DUP NEG NEG == also returns 0. > Joe, > The first {0} decompiles as > Z0_ > The second, after DUP NEG, as > ZINT 0 > so they're not == . > Is this a bug? Don't know. Surely it's bug == compares generally you don't even need { a list } for the bug === Subject: Re: {0} DUP NEG == > On the hp49g+, ROM build 88, {0} DUP NEG == returns 0. > return 0, but why should == return 0? > In case it matters, {1} DUP NEG NEG == also returns 0. > -jkh- My apologies if all of this is obvious and everyone already knows this... While I actually don't understand much in the way of SysRPL, I believe << -85 SF -79 CF >> provides some insight into this. -79 is textbook mode, and it intereferes with seeing what is really happening. -85 is SysRPL stack. As I understand it, to save space, the calculator has predefined certain ZINTs to have short forms, and so 0 can be defined as both Z0_ and ZINT 0. However, as you have noticed, the calculator does not appear to do this properly for NEGating. For those without a calc handy/don't want to play with the flag settings: After entering {0}: 1: { Z0_ } after DUP NEG: 2: { Z0_ } 1: { ZINT 0 } and, ==: 1: %0 Subsequent NEGs don't seem to affect things. As a matter of fact, being a list doesn't matter, either: Enter 0: 1: Z0_ DUP NEG: 2: Z0_ 1: ZINT 0 However, == seems to account for this, and properly handle it: ==: 1: Z1_ Shouldn't == check for ZINT 0 vs Z0_ when they are in a list? I wonder if I'm anywhere near the truth... Greg === Subject: Re: {0} DUP NEG == I can reproduce this on my 49g+. I have the 2.00 ROM upgrade. === Subject: Re: {0} DUP NEG == > On the hp49g+, ROM build 88, {0} DUP NEG == returns 0. > return 0, but why should == return 0? > In case it matters, {1} DUP NEG NEG == also returns 0. > -jkh- There really is a build 88? === Subject: Re: {0} DUP NEG == > There really is a build 88? http://www.hpcalc.org/details.php?id=6385 See the following thread: tinyurl in case that gets mangled: http://tinyurl.com/ackho Greg === Subject: Re: {0} DUP NEG == > There really is a build 88? > http://www.hpcalc.org/details.php?id=6385 > See the following thread: > tinyurl in case that gets mangled: > http://tinyurl.com/ackho > Greg === Subject: Programming questions Hi all, I was wondering how to write a routine that acts like the SysRPL entry WaitForKey, but doesn't pop the key from the keyboard buffer. I thought that writing the key (or the two keys in the case of shifted or alpha-ed keys) in the buffer with an assembly routine could do that. But I don't know if this is the cleanest (the less ugly) way to do what I want. Do I have to disable interrupts before? If so, which one? The other question is about transfering files for HP38 and HP39. I have two binary files: HPL.39 and LIB39.000. The latter is a library, and the first is an aplet attached to this library. I know there must be two other files in order send both files to a calc: HP39DIR.000 and HP39DIR.CUR. HP39AscA B 6 HPL.3918 HPlanetarium ApletH 9 LIB39.0005 LIB39 (without the double quotes). The problem is I don't know if the format is correct, especially for the field? The other thing I haven't understood is the purpose of the HP39DIR.CUR file. Can I copy the content of HP39DIR.000 into the .CUR file? Would it work? P.S.: by the way, I've just released the latest beta version of HPlanetarium, an astronomy program. This may be still buggy, as a beta version, but you can give it a try. It should work on HP39/40/48/49. I haven't tested at all on HP38 but it should work too. You can download the program there: . The sources are included in the archive. The documentation hasn't been written yet, but you can refer to the website: