HP-139 Subject: Re: TI-89 Titanium instead of HP 49g+? You see Dan, You got it all right -this is just what i'm talking about, i'm just reacting, replying i never tried to compare G+ with TI -i don't need that at all, but TI users seem to be the ones with their feelings hurt since G+ is out. i didn't ever see an HP user to start comparing HP with TI, nor braging over TI nor anything like that, on the other hand TI users... do they feel left behind or somthing ? how would you reply to that ? all facts that you have written about working on 75... agreed you're right You see the privilege of choice is what i was talking about, with G+ you can program it as Saturn machine, as ARM, in userRPL, systemRPL, HP basic or even C. You can make it run at 200, 133 or 33 and kill your batteries with it if you like, the main phrase is : YOU CAN ! Ti users seem to be putting some (few) cases in which Ti is fast enough compared to G+, what about all these thins which TI CAN'T DO AT ALL -again... timers, SD slot etc.... over and out === Subject: Re: TI-89 Titanium instead of HP 49g+? posting-account=Dzyc9wwAAABCml63_5kidLcMpxekXI5I > You see Dan, > You got it all right -this is just what i'm talking about, i'm just > reacting, replying > i never tried to compare G+ with TI -i don't need that at all, > but TI users seem to be the ones with their feelings hurt since G+ is out. > i didn't ever see an HP user to start comparing HP with TI, nor braging over > TI > nor anything like that, on the other hand TI users... do they feel left > behind or somthing ? Please see every comment by VPN. === Subject: Re: TI-89 Titanium instead of HP 49g+? Nice, however where i come frome it's all the way around HP was standard ever since 48's (model not age :-) and we are (some of us) not afraid of mastering new evnironments provided by HP. I am realy glad that HP introduced new modern processor, and was smart enough to keep the well established standard (Saturn) by emulating one. What we have now is in fact (from programming point of view) dual-processor-like environment. True there was a time when i first saw TI in the store window, i didn't know about HP at all, however HP48SX was the first i owned, it was everything : expandability, programability, games, all kinds of software, powerfull doing math, you name it. With great currage of HP we now have 49G+ which is all that and more : foremost modern (in both exterior design and hardware design) yet classic looking -just about right for a calculator. I doubt if there is anything that coul dmake me convince to use TI on the other hand if i had TI i wouln't sell it, or throw it away, but i sure would wish i had G+ as well. Also i never judged people who were complaining about G+ and keeping to compare it with older models -i didn't get rid of my SX either, but i sure won't get rid of G+, because i like it very very much. I just wish it would be made better, in sence production and materials quality. manjo === Subject: Re: TI-89 Titanium instead of HP 49g+? > UserRPL and SysRPL are, frankly, among the worst programming languages I > have ever seen. Maybe you dont like, or you are just a C addict, like some programmers dislike java because is slow, or vb because is easy... but User and System RPL are based on FORTH, witch is a very small, compact and very powerful language. I think in just a weeks you can begin to *think* in User/SystemRPL and programming on the HP becomes to be a easy and intuitive task. (at beginning is a hell ..hehe...) definitively, UserRPL kick the ass of TI-BASIC in any factor (excepting in the learning curve) === Subject: Re: TI-89 Titanium instead of HP 49g+? > UserRPL and SysRPL are, frankly, among the worst programming languages I > have ever seen. > Maybe you dont like, or you are just a C addict, like some programmers > dislike java because is slow, or vb because is easy... but User and > System RPL are based on FORTH, witch is a very small, compact and very > powerful language. > I think in just a weeks you can begin to *think* in User/SystemRPL and > programming on the HP becomes to be a easy and intuitive task. (at > beginning is a hell ..hehe...) > definitively, UserRPL kick the ass of TI-BASIC in any factor > (excepting in the learning curve) Again Avatar you got it right, If i may add: consider sysRPL as meta-language -meaning that various high-level languages like C, java etc... can be easily translated to sysRPL with very simple compilers. And very effective too, some compilers sysRPL. the beauty of sysRPL lies in ints simplicity, it is so simple as ASM -so people may find themselves not being able to simplify their problem so much. :-) but then again -not everybody is a fighter pilot either :-) manjo === Subject: Re: TI-89 Titanium instead of HP 49g+? >>>UserRPL and SysRPL are, frankly, among the worst programming languages I >>>have ever seen. >>Maybe you dont like, or you are just a C addict, like some programmers >>dislike java because is slow, or vb because is easy... but User and >>System RPL are based on FORTH, witch is a very small, compact and very >>powerful language. >>I think in just a weeks you can begin to *think* in User/SystemRPL and >>programming on the HP becomes to be a easy and intuitive task. (at >>beginning is a hell ..hehe...) I have to agree with Chris here. I've been playing around with RPL for a fair while. While I like it as a calulating environment, I think its a lousy way to write large programs. Sure, simple things are easy, but writing anything nontrivial is painful to me. Of course this is just a subjective opinion. Just like some people like Functional Programming and others don't, there is not 'right ot wrong' answer. > If i may add: > consider sysRPL as meta-language -meaning that various high-level languages > like C, java etc... > can be easily translated to sysRPL with very simple compilers. And very > effective too, some compilers > sysRPL. But if you are working with a compiler, why on earth would you want to much faster and more powerful to generate asm code (either ARM, or emulated Saturn if you want to use lots of OS / Mathematical calls) > the beauty of sysRPL lies in ints simplicity, it is so simple as ASM -so > people may find themselves not being able to simplify their problem so much. > :-) but then again -not everybody is a fighter pilot either :-) There is a reason why 99% of people avoid asm code - using a high level language is much more productive, even if the result is slower and/or bloated. If you like it, great, but I prefer to get things done quicker :-) cheers, Al > manjo === Subject: Re: TI-89 Titanium instead of HP 49g+? Yes Al i understand and i support you in your choice -you're simply getting better along with C, that's why you choose C -again privilege of choosing at work i choose sysRPL and ASM because i can compile it everywhere anytime by simply having G+ with me, also if i send somone a source he can change and compile without troubles :-) sysRPL and C can not realy be compared, sysRPL would make sence compared to ASM (not by speed of course), but by level, by size of compiled code, by the *way of thinking* as Avatar_e said. just like any programming environment, sysRPL programer has to adjust techiques and way of thinking to the environment, Some may find this hard, because it realy is quite different from BASIC, C, PASCAL or similar languages. sysRPL can (of course) be function based -depends on your implementation, recursive linear, nonlinear any kind of programming works. It has very powerfull structure capabilies built in, all this at the same time having a lot in common with modern object-oriented languages. manjo === Subject: Re: User's Manual for the 49G+ > Personally I MUCH prefer a paper manual. If I have to get on a computer to > figure out how to use my calculator, whats the point of the calculator? My > computer can do way more than my calculator. > A calculator is designed to be small and portable. Tying it to a computer > with the manual is just silly. I totally agree with this and that is why I got so excited when I saw the printed German copy of it. Since I can read German, I am going to order it from the places the other posters sent and so have a physical copy of it. Alejandro === Subject: Re: User's Manual for the 49G+ You can probably take the pdf file on a disk to your local Kinko's and have it printed and bound for less than you can buy it, and you have the option of having it printed in a small format for easy portability but not easier reading. I think a quick reference that fits into the case with the calc (a la 48SX) would be a good useful thing to have on paper. === Subject: Re: User's Manual for the 49G+ : You can probably take the pdf file on a disk to your local Kinko's and : have it printed and bound for less than you can buy it, and you have : the option of having it printed in a small format for easy portability : but not easier reading. I went to my local Kinkos and they wanted ~$70 to print it. -- Keep working millions on welfare depend on you ------------------- fwp@deepthought.com === Subject: Re: User's Manual for the 49G+ > : You can probably take the pdf file on a disk to your local Kinko's and > : have it printed and bound for less than you can buy it, and you have > : the option of having it printed in a small format for easy portability > : but not easier reading. > I went to my local Kinkos and they wanted ~$70 to print it. Interestingly, I have JUST returned from my local Kinko's. They wanted $30.81 to print it and $6 for binding it. I thought that was expensive, but after reading Frank's message, I guess I am going back right now and get it done. Although for that price, I can get the original from HP.... mmmm... Anyway, it sucks that you cannot just order it. When I was still living in Germany and bought my HP 49G in France, it came with french manuals (of course), so I called HP in Germany and they sent me a whole set in English (the user's manual, advanced user's guide and pocket book) for free! Those were the good ol' days.... Alex === Subject: Re: Graphic on the 49G+ > Perhaps a better way for the speed in user rpl is to use the GROB and > REPL commands. The idea is to use a reverse BLANK command. > Gilles I guess I'm still not quite used to programming in rpl. I took the advice of using BLANK and this is what I came up with << -> c1 c2 << PICT c1 c2 c1 - EVAL BLANK #2609Eh SYSEVAL REPL >> -- Wing Wong. Webpage: http://wing.ucc.asn.au === Subject: Re: Graphic on the 49G+ Line algorithm looks fine and stright forward, but it is not even close as fast as if you make blank square of apropriate size, make a negative (fill it) and then REPL to required position. so something like this: (userrpl) PICT {#pos_x #pos_y} #with #height BLANK NEG REPL may proove to be very effective -even more if you rewrite it in sysRPL manjo === Subject: Re: Graphic on the 49G+ Very good ! I was totally ignorant that the NEG fonction works also with GROB objects :-)Interesting... Gilles manjo a .8ecrit: > Line algorithm looks fine and stright forward, > but it is not even close as fast as if you make blank square of apropriate > size, make a negative (fill it) and then REPL to required position. > so something like this: > (userrpl) > PICT > {#pos_x #pos_y} > #with > #height > BLANK > NEG > REPL > may proove to be very effective -even more if you rewrite it in sysRPL > manjo === Subject: Re: Faster Best fractions on the HP49 X-NNTP-Client: ROBOT/LX -=[ Fri, 22.10.04 4:15pm +1300 (NZDT) ]=- Hry Joe you might be interested in PDR6 below. in message ID <11372369ROBOTLX@news.individual.net> : > Since then I've been timing the second part. For some reason > the one-off PDR caclulation can be quite slow. I can't figure > out why but it is something to do with holding large integers > in the stack. I almost think it is quicker to give then names > and store then and recall them ... must do more research. Ahha DBUG showed me a very strange thing - a multiplication taking a long time. I guess it is really not surprising that the the execution *time* of multiplication is not commutative. For example 450 ALOG Pi ->NUM 13 ALOG * R->I 20 ^ puts 10^450 in Y and another non-zero digit 'rich' number in X A straight * takes .15 seconds But SWAP * takes .85 seconds... on a 49g+. Lucky we get the same 720 digit answers - just different timings. When such a multiplication is a main focus in a loop then many iterations can result in very significant timing differences. For example, in Joe's PDQ2 he has: UNTIL b n0 y * d0 x * ABS * That is the fast version when b is a multiple of 10. This is the slow version: UNTIL n0 y * d0 x * ABS b * But, if one already has the ABS argument sitting in the stack at the UNTIL one is inclined to code UNTIL ABS b * and for the famous PI500 13131 440 10^x / PDQ2 example this makes a big difference - a normal time of about 7 minutes becomes something over 14. Fortunately there is only one way to do divide :-) Here is a souped up PDQ, called PDR6. The R is for Rodger, and the 6 is just the version number This one can run twice as fast as PDQ2. On the raw cf iteration it seems 2.5X faster (see table below). -- Faster 49G implementation of PDQ2 Part 1 (finding sufficiently close normal convergent) ------ * faster as it only develops 2 series - the denominators and errors. The terminal numerators are merely *solved for* in part 2. * noticeably faster for many iterations - maybe twice as fast for 400, for example. Part 2 (finding closest interpolated convergent) ------ * implements a version of Roger's fast algorithm. * noticeably faster for a large final partial quotient. Comparisons The final EVAL timing has been split off as it stands out as being computationally intensive - especially for these cases. This is where the final N/D -a/b is evaluated. Tolerance= 13131 440 10^x / Timings in seconds on a 49g+ 1000 digit PI PDR6/ | 5000 digit PI PDR6/ PDQ2 PDR6 PDQ2 | PDQ2 PDR6 PDQ2 Part 1 794 311 .39 | 4079 1681 .41 Part 2 65 25 .38 | 582 356 .61 Final EVAL 80 72 .90 | 1476 1321 .89 Total 939 408 .43 | 6137 3358 .55 (min:sec 15:39 6:56 |102:17 55:58) The EVAL differences are fortuitous I think ... but I do get identical answers. It is interesting that Part2 is not too significant in the scheme of things, for this case anyway - 15 iterations for full bisection. Plus the complexity of the PDR Part 2 calc is starting to bite more with the 5000 digit PI. Algorithm Input ----- n/d and the tolerance a/b Initialization --------------- pe=n ce=-d pd=1 cd=0 Part 1 ------ DO -pe q=floor(----) ce new_cd=cd*q+pd pd=cd cd=new_cd new_ce=ce+q*pe pe=ce ce=new_ce UNTIL b*|ce|<=a*d*cd Part 2 ------ b*ce + SIGN(pe)*a*d*cd g=floor(------------------------) b*pe + SIGN(pe)*a*d*pd cn-g*pn output: ------- cd-g*pd where cn=(n*cd-ce)/d and pn=(n*pd-pe)/d (as ce=n*cd-d*cn, called the current error for want of a better name - really it is the numerator of [n/d - cn/cd] which is the opposite sign to the conventional error - i.e. actual-expected). Notes ----- a*d is computed once and kept temporarily on the stack. It is re-used in the 'UNTIL' error check, and finally at the beginning of the second part. q and g (IQUOT results) are un-named below - kept temporarily in stack. All other variables are named as in the description above. Except for the terminal numerators cn and pn. The stack usage increases the speed slightly, but it is the computational advantage of developing the errors recursively and not needing to develop the numerators of the convergents that accounts for most of the speed advantage. Versions PDR5,PDR4 ... etc prove this. RPL source for PDR6 First dozen lines are identical to Joe's PDQ2 %%HP: T(3)F(.); << THEN SWAP $TOF SWAP END IF OVER FXND MOD THEN IF DUP 0 < THEN NEG 2. LOG + END IF DUP 1 >= THEN NEG ALOG @ from here down is different to PDQ2 END TOF ROT TOF DUP2 NEG 1 0 -> a b n d pe ce pd cd << a d * DO pe NEG ce IQUOT pd OVER cd DUP 'pd' STO * + 'cd' STO pe SWAP ce DUP 'pe' STO * + DUP 'ce' STO UNTIL b SWAP ABS * OVER cd * <= END @ find g pe SIGN * DUP cd * b ce * + SWAP pd * b pe * + IQUOT @ now directly calc the best fraction @ first the numerator = cn-g*pn (see algorithm) n cd * ce - OVER n pd * pe - * - d / @ now the denominator = cd-g*pd and evaluate error OVER pd * cd SWAP - / DUP n d / - EVAL IF ROT THEN X ELSE N END ->TAG >> ELSE DROP :N: 0 END ----- Tony Hutchins === Subject: Re: Faster Best fractions on the HP49 X-NNTP-Client: ROBOT/LX -=[ Sat, 23.10.04 10:44 a.m. +1300 (NZDT) ]=- Hi Tony Hutchins ! in message ID <11088319ROBOTLX@news.individual.net> : > new_cd=cd*q+pd > pd=cd > cd=new_cd > new_ce=ce+q*pe oops sb =ce*q+pe ce develops just like cd. -- Tony Hutchins === Subject: Re: Faster Best fractions on the HP49 X-NNTP-Client: ROBOT/LX -=[ Sat, 23.10.04 06:23 a.m. +1300 (NZDT) ]=- Hi Tony Hutchins ! in message ID <11088319ROBOTLX@news.individual.net> : > -=[ Fri, 22.10.04 4:15pm +1300 (NZDT) ]=- > Hry Joe you might be interested in PDR6 below. Oops, that was Hey Joe [...] > Comparisons > The final EVAL timing has been split off as it stands out as > being computationally intensive - especially for these cases. > This is where the final N/D -a/b is evaluated. Oops - sb where the N/D output - the n/d input is evaluated. [...] > 1000 digit PI PDR6/ | 5000 digit PI PDR6/ > PDQ2 PDR6 PDQ2 | PDQ2 PDR6 PDQ2 > Part 1 794 311 .39 | 4079 1681 .41 > Part 2 65 25 .38 | 582 356 .61 > Final EVAL 80 72 .90 | 1476 1321 .89 > Total 939 408 .43 | 6137 3358 .55 > (min:sec 15:39 6:56 |102:17 55:58) > The EVAL differences are fortuitous I think ... I had PDQ2 running on a CNA413... machine and PDR6 on an original CN331... - I thought I'd give PDQ an advantage, running with a lot more memory free. But further testing of identical programs shows real strangeness - indeed the EVAL seems about 10% faster on the old machine but Part1 seems 4% *slower*. Overall, about the same. Doesn't really change the conclusion. Also I tested all the old PDQ 12 digit examples. The q-calc is consistently 20% faster, and the g-calc is always faster for q>1 - in fact for PDR the g-calc is simply constant at .2 seconds. Both work for a 6000 digit PI input. PDQ2 took 121 minutes and PDR6 66 minutes. My guess is they probably work for up to near 9000 digit PI. I did set 9000 PI running and after an hour *both* machines stopped remanding to be changed from DEG to RAD mode!! I suspect silent errors were occurring - but 9000 digit input would challenge battery life anyway. To get an answer within say 30 seconds keep the input N and D under 100 digits. year ;-) -- Tony Hutchins === Subject: Re: Vectors that contain fractions on HP49g You can also use the 'ROW->' command available from the [MATH][MATRIX][ROW] menu. Example: 5 2 2 'ROW->' returns [5 2] Using Keyman, I've got the 'ROW->' command set up on the 'R' key, and the '->ROW' command on the long press on the same key. The 'ROW->' command is the fastest way I've seen so far to create a matrix (especially if you use the custom keyboard). --CS === Subject: Re: Vectors that contain fractions on HP49g posting-account=Dzyc9wwAAABCml63_5kidLcMpxekXI5I My favorite bug: http://bugs.hpcalc.org/show_bug.cgi?id=99 -Samuel http://www.stearley.org > How can you enter a vector that contains fractions? (HP49g in RPN > mode) > For example, suppose I want to make this vector: [5/13, 12/13]. > Typing: > [] > 5 > Enter > 13 > / > ... > creates [5] because the Enter terminates entry of the vector. > Putting 5/13, 12/13 on the stack and then doing ->V2 gives me this > message: ->V2 Error: Bad Argument Type. > I'd rather not use real-number approximations in place of the > fractions if at all possible. > Ben Kovitz > Caltech > http://sbml.org === Subject: Re: Vectors that contain fractions on HP49g > My favorite bug: > http://bugs.hpcalc.org/show_bug.cgi?id=99 > -Samuel > http://www.stearley.org > How can you enter a vector that contains fractions? (HP49g in RPN > mode) > For example, suppose I want to make this vector: [5/13, 12/13]. > Typing: > [] > 5 > Enter > 13 > / > ... > creates [5] because the Enter terminates entry of the vector. > Putting 5/13, 12/13 on the stack and then doing ->V2 gives me this > message: ->V2 Error: Bad Argument Type. > I'd rather not use real-number approximations in place of the > fractions if at all possible. > > > Ben Kovitz > Caltech > http://sbml.org Try [ ] 5 space 13 / 12 space 13 / ENTER ENTER or [] '5/13' '12/13' ENTER ENTER or put 5/13 and 12/13 and 2 on the stack and then use ->ARRY You can even make a mini-program << 2 ->ARRY >> to use instead of the ->V2 command. Note precedes special symbols not exactly representable in ASCII as single characters. The meanings should be clear, at least in the above instances. === Subject: Re: How many really program? > I bought both TI and HP calculators and have done math problems with > both. When I started reading about people programming in RPL, ASM, > campus and looking through the NG, it seems like about 80% of the > owners of either just use the functions that come with the > calculators. I read how one calc is faster than the other to the point > of verbal wars. Does it really make all that much difference for the > majority of users, or is it something the highly technical people > > Don If you've payed 270 bucks for a calculator, it should do something really nice. Well, it does. It's a programmable calculator, which mean you can teach it to do something it does not automatically do. Eduardo M. Kalinovski, Programming in User RPL It sayes it all. V. === Subject: Re: How many really program? > If you've payed 270 bucks for a calculator, it should do something > really nice. Well, it does. It's a programmable calculator, which mean > you can teach it to do something it does not automatically do. > Eduardo M. Kalinovski, Programming in User RPL > It sayes it all. > V. US$270?? Did you really pay that much? It should cost less than half of that. -- Bhuvanesh === Subject: Re: How many really program? he's probably talking long ago :) > If you've payed 270 bucks for a calculator, it should do something > really nice. Well, it does. It's a programmable calculator, which mean > you can teach it to do something it does not automatically do. > Eduardo M. Kalinovski, Programming in User RPL > It sayes it all. > V. > US$270?? Did you really pay that much? It should cost less than half of that. > -- > Bhuvanesh === Subject: Re: How many really program? toys/tools to keep my brain exercised. I am a casual math person, who since I retired enjoy reading and playing with math problems. Don === Subject: Re: How many really program? > toys/tools to keep my brain exercised. I am a casual math person, > who since I retired enjoy reading and playing with math problems. > Don If you think playing with math problems is fun, you should try teaching a computer to do it :) --CS === Subject: Re: How many really program? > In my country, must of the 4x4 cars can go anywhere, but must of > their owners never left their city, never touch the mud, even knowing > the 75% cost of car is because you should need to be prepare for mud. > So the question should not be what does the people do with tools?, > the real and interesting question is what YOU can do with it !!! > Yes, much people have tools for a minimum or not use at all (I have > seen brand new cars, boats, computers, etc, just being stock in the > owner«s warehouse). The trouble is not in the tool. > But for those of us that really want to go to the limit of the tool > capacity .... you should try it, and, by the way, IMPROVE YOUR OWN > CAPACITY to go farther, faster and better than anybody, to a newer > place. > That«s the real discusion, what is YOUR capacity to do things with > whatever tool you have!!! Must of people does nothing or very little > things, because of their VERY SHORT capacity. Very well put Daniel, I agree with you 100% manjo === Subject: Re: Definite integration for abs(cos(x)) Hello all, > (-(Cos[Pi/8]*Log[1 + x^2 - 2*x*Cos[Pi/8]]) - > Cos[(3*Pi)/8]*Log[1 + x^2 - 2*x*Cos[(3*Pi)/8]] - > Cos[(5*Pi)/8]*Log[1 + x^2 - 2*x*Cos[(5*Pi)/8]] - > Cos[(7*Pi)/8]*Log[1 + x^2 - 2*x*Cos[(7*Pi)/8]] - > 2*ArcTan[Cot[Pi/8] - x*Csc[Pi/8]]*Sin[Pi/8] + > 2*ArcTan[(x - Cos[(3*Pi)/8])*Csc[(3*Pi)/8]]* > Sin[(3*Pi)/8] + 2*ArcTan[(x - Cos[(5*Pi)/8])* > Csc[(5*Pi)/8]]*Sin[(5*Pi)/8] + > 2*ArcTan[(x - Cos[(7*Pi)/8])*Csc[(7*Pi)/8]]* > Sin[(7*Pi)/8])/8 > So I understand that the HP48 cannot do it. I don't know about Mathcad... The HP48GX with ERABLE produces the same with the constants evaluated to approximate numbers. !Demeter! === Subject: Can't figure out how to compile my library HP development kit hello users: I've been off the scene for a while so bear with me. I am trying to compile my old Linbrary source using HP development kit. Would someone like to walk me through my errors. I prefer a e-mail as I don't have much time to read newsgroups === Subject: Re: replacing battery for hp 48s >There definitely is an internal battery because I did a test >where I stored a variable, took out the main 3 AAA batteries, >and when I put them back in, the variable was still in memeory. >DN > Ther is no internal battery in the 48. It is a small capacitor that > keeps the memory intact for a few minutes until you replace the three > AAA batteries. >>No internal battery... battery. Incidentally, I took out the 3 AAA batteries for more than 1/2 hour and the memory was still there. DN === Subject: Re: replacing battery for hp 48s > I took out the 3 AAA batteries for more than 1/2 hour > and the memory was still there. When you want the internal capacitor to die quickly (e.g. when the capacitor will die in the few seconds it takes to swap the AAA cells. This is called Murphy's Misery Maximization function (M3f) and is unfortunately an unavoidable quality of Mother Nature. The *nominal* capacity of that capacitor is required by HP Legal to be mentioned in the Hardware Specification, but is ignored by Reality. -Joe- Disclaimer: Everything in this posting is true, more or less. === Subject: Re: replacing battery for hp 48s |I have an HP 48S that's about 10 years old. I am wondering | if it is ever necessary/possible to replace the internal battery | on it. As you may know, this calculator has no ports to | | There definitely is an internal battery because I did a test | where I stored a variable, took out the main 3 AAA batteries, | and when I put them back in, the variable was still in memeory. No internal battery... === Subject: Re: OPEN FIRE 1.6 i was wrong about ARM conversion of planes -it is as simple as with Saturn, i was thinking Saturn way when i said it would be more difficult. 3 instructions per plane -in Saturn there was also 3 :-) manjo === Subject: Re: OPEN FIRE 1.6 > i was wrong about ARM conversion of planes > -it is as simple as with Saturn, i was thinking Saturn way when i said it > would be more difficult. > 3 instructions per plane -in Saturn there was also 3 :-) > manjo What do you mean by 3 instructions per plane? 3 instructions to process what, one pixel? 8 pixels? Oh, I think I know how you are doing it... (tell me if I'm wrong and you found a better way, just for curiosity) I think of it by using tables. To convert let's say to 4-bit packed-pixels I would create a table with 256 entries, each entry will be the index number with it's bits separated 4 bits apart (i.e. Table[3]=0x00000011, like binary expansion). To process one plane, I would read one byte (8 pixels monochrome) from a plane, get the expanded version from the table, rotate it according to which plane number is and OR with the final number. Since 8 pixels would expand to 32-bit, you can process 8 pixels at the same time and with full words (fastest in ARM). Is this what you are using? Did you find a better way? BTW, I noticed in my calc that #80100 IS USED by some commands that are in Flash. It is safe to use if you don't let any other program to execute while you are using it. If you are planning to leave something there permanently for a different program to pick up it might not be the best choice. I would recommend you the 'SavMisc' area. I ran extensive tests and this area was always unchanged (unlike #80100, which was used sometimes). Great job so far, Claudio === Subject: Re: OPEN FIRE 1.6 > BTW, I noticed in my calc that #80100 IS USED by some commands that > are in Flash. It is safe to use if you don't let any other program to > execute while you are using it. If you are planning to leave something > there permanently for a different program to pick up it might not be > the best choice. > I would recommend you the 'SavMisc' area. I ran extensive tests and > this area was always unchanged (unlike #80100, which was used > sometimes). > Great job so far, Yes you're absolutely right i was puzzled for a while with that -i noticed that 80100 is used by some routines, i was installing page converter to 80100 and then when checking to see if everything is right -i noticed that it's not my code there :-) anyway -while my program was running ARM code was at 80100 and it executed fine, so in Lilian's case it will work fine, but the good point is that Lilian sugested to specify the address where routines will be installed to, ...so, anyone can allocate some space, and install routine to his own space. Actualy my Saturn part of converter, which installs ARM code to specified address doesn't pass arguments trough common space it adjusts ARM code instead. Basically self modifying code -kinda (because Saturn modifies ARM code). For 3 instructions per plane -i ment: thightest loop (the inner loop) where data is converted has total of 6 instructions in 8x loop which do following: example on 4 bit values (in real life it does the same but with bytes it is realy 16 bit algorithm, because there is always whole number of bytes in a scanline) 1011 -> 1 0 0 0 1 0 1 0 1101 -> 1 0 1 0 0 0 1 0 (interlaced with zeros) 1 0 0 0 1 0 1 0 darker walue as is 0 1 0 1 0 0 0 1 lighter value shifted 1 bit right (or) result 11011011 <- this is a proper combined value of both planes in 2 bit sequence (4 pixels) how do i interlace with zeros ? (input byte is in LSB of R3 and R5) loop 8 times { MOVS R3,R3 LSR#1 ADC R4,R4 #0 MOV R4,R4,ROR#2 MOVS R5,R5 LSR#1 ADC R6,R6,#0 MOV R6,R6,ROR#2 } Result : 16 bit result is in upper half-word of R4 and R6, R3 and R5 are recycled (free to be used and zeroed) i was attracted to Saturn way -where solution was pure shifting in apropriate fields (very register effective), but here carry does the trick. this is actualy very common for most processors (not for Saturn though). what realy bothers me now is reading bytes of non-byte-aligned address. Saturn is capable of addressing nibbles, and it does it all the time, so data of pixel plane can be expected to start on nibble address, in that case ARM has to LDRB 2 two times and combine values. Another case is when data starts on byte address -normal LDRB would suffice, and the mumbo-jumbo with 2 partial reading won't work at all. This will be ugly part of code, in this part Saturn would be more effective. First i'll finish ARM version like we specified for version 1.7, then i'll do Saturn version, i expect Saturn to be fast enough, at the same time smaller, code could be installed at any address (word-alignment not necesary). Another thing that i was thinking about is : Do you have any idea how can we turn off ARM's LCD update process -is it trigered by some timer or something which could be masked ? I'm talking about process which copies emulator's screen in to LCD buffer. Why ? -with OPEN FIRE you get direct access to LCD buffer so LCD refresh task is not needed, however it's wokring all the time in the background, spending a great deal of processing power. With that task freezed we could get signifficant boost without overclocking. In star theck they would command : Transfer shields and life-support energy to boost warp drive :-) manjo === Hey, how you doing? So Lilian...whatcha wearing... Grazie! Jay oi maiale >:)) >Pig is MY surname. > Lilian Pigallio. >> Is this a good place to meet women? >> Jay the Pig === It has been pointed out to me that I have the both the wrong sex and language for Lilian and that the answer to my original question is most likely no. Still the HHC '04 appears to have been an outstanding value. The dinner seemed quite posh for a $45 registration and rooms were only $69 (how French!) in a Raddison Hotel. Not a whole lot of animated technical conversation where I live. Jay the Pig >Hey, how you doing? >So Lilian...whatcha wearing... > >Grazie! >Jay oi maiale >>:)) >>Pig is MY surname. >> Lilian Pigallio. >>> Is this a good place to meet women? >>> Jay the Pig === Subject: Re: User RPL Question > The documentation for the CHOOSE command says that > using a position number of 0 (zero) > means no item will be highlighted. > When I use 0 with CHOOSE it acts the same as using a 1. Known bug (or decision not to implement) in 49G; works as advertised (see Advanced Users Reference) in 48G: [r->] [OFF] === Subject: Convert Hp48G+ to HP48GII occasionally the battery dies, and then I have to re-install the program. I bought an HP48GII because it has a lithium battery to keep the memory alive when the main batteries fail, and has the LED to drive the HP82240 printer (OK - so after the fact I see that the HP49G has an LED as well, but I didn't ralize it at the time that I saw the HP48GII, and the HP48GII is cheaper). I am treating the HP48GII as an HP49G-, and assume that Debug 4X will give me the correct codes to load into the HP48GII. Is this correct? I am trying to load a global variable called ATR into a variable that can be recalled from the variable entries when the VAR key is depressed. The program compiles correctly under Debug 4X, but I can not load the program into even the HP49 simulator. This is the program that I am trying to load into the HP49 simulator. TITLE ATR RPL ( F:HP48GIICurrent ) * Sales slip summary information array * Bill # * Transaction type (0 -Void, 1 - Cash, 2 - Visa, 3 - M/C, 4 - Debit, 5 - Other * Bill total * * Array type is Real * * INCLUDE ATR.H INCLUDE TBLSIZES.H ( Define the table sizes ) ASSEMBLE * CON(1) 8 NIBASC /HPHP49-D/ RPL * ID ATR *ATR: :: { ATentries ATRcolumns } ^MAKEARRY ; { ID ATR } BIND As you can see, this only creates a 2D matrix. ATentries is 500 and ATRcolumns is 6. Compiling this under the old DOS compiler, and labelling it as ATR, Kermit would transfer it to the HP48 and it weould appear as variable ATR under the VAR key selection. On the HP49 simulator, there are some lines on the display after a build, but the variable ATR does not show up anywhere. It is obviously not loading properly. My POS program is very long, but I have got to the point where it compiles under Debug 4X, but also does not load. Can anyone point out what I am missing to get global variables into the HP49 (and presumably the HP48GII, when I hook up the transer cable)? === Subject: Dream Calculator If you could get your dream calculator, what features would it have? Dependable keyboard (%99.999 accuracy) and excelent manuals are a given. === Subject: Re: Dream Calculator posting-account=pV_biQ0AAADoB9PiKLE6iUQDWNb_aN1m I _have_ my dream calculator. It's hp49G. :-) === Subject: Re: Dream Calculator X-RFC2646: Format=Flowed; Original I also have your dream calculator. >I _have_ my dream calculator. It's hp49G. :-) === For those of us that could not attend the conference due to physical location, does anybody know if any downloadable video footage is available or will be available in the future. Noel Causerano (Registered Surveyor) GEOCALC SOFTWARE Registered Reseller HP Invent Cairns, QLD, Australia Email: noel@geocalc.net WEB: www.geocalc.net === Subject: Re: HP-33S tricks & ruminations X-RFC2646: Format=Flowed; Original > Sorry guys but you are both way out of line here! > You are talking about pityful BASIC pocket computers. > These toys your mention could not (can not) compete > against a formidable HP71B (HP BASIC) pocket computer > of the same era with programmable user fonts, redefinable > keyboard (all keys), clock-calendar-timer alarms, etc. > None of the toys you mentioned supported any of the above. OK, ok, I do remember the HP71B. I also remember that it was something like $525 vs. the $100-$200 for the Casio BASIC pocket computers! I suppose that if I actually had had any money at the time (I was in high school) I would have gone for the 71B... I thought long and hard before shelling out $249 in 1990? for an HP-48SX, let me tell you! The HP33S surely has a powerful enough CPU and enough memory to do everything the HP71B did and more. As I say, too bad that HP doesn't think there's much demand for a more sophisticated non-graphing calculator. ---Joel === Subject: Re: What's your calculator history? 1974ish - Panasonic something 4 function - was glad to have it. (long gone) When not using it for homework, would fill the display with 88888888 and use it as a light source under the blankets. 1978ish - TI-5x something? programmable? Was okay for a high school punk. (long gone) 1979 - Dad gave me a teeny tiny abacus and a teeny tiny casio 4 function - M-811 - came in handy every now and then. (still have it, not sure if it still works) I think I'll rustle up some new batteries and give it a whirl. 1980 - 41CV w/card reader for engineering sckool - choo choo! (still have it/use it) Did a fair amount of generic programming. 1982 - 10C Wanted a 4 function RPN and this was the closest thing. (still have it/use it) 1983 - Picked up a 2nd 41CV at a great price. (still have it but it doesn't work anymore - just get the flying bird - so sad. Probably have to replace some capacitors) nice. I take it to use in dirty or risky (theft) places. being a 41 centric lad. I'll get around to reading the manual about when HP comes out with a color screen version or leaves the calc business. The 12C came without pretty box or manuals so it was under $40. Jay the Pig === Subject: Re: What's your calculator history? My Calculator History 1996:Casio fx 7700Ge 1998:casio fx 9950Gplus 1998:HP48GX (bought 2) 1999:Hp48G+(bought 2) And I'm a student yet. I created an external keyboard for the 48 series, but none asked me about. Bye. === Subject: Reliable source for newer HP 49G+?? I need to get a graphing calculator, and I want it to use RPN, so have been considering the HP 49G+. However, I've read all these complaints about the keyboard not working well, etc. Do you know where I can buy a 49 G+ that can be expected to have the newer keyboard design (amazon.com, commerce.hpcalc.org, ...)? Is the newer keyboard design good enough to make it a reliable calculator? Tom === Subject: HP 48SX I have a used 48SX in good condition and works fine (no bad keys) with soft case, and three manuals that I would like to trade for a working 42S. Anyone interested contact me at kennym@ixpres.com === Subject: Re: To 49g+ or not to 49g+ > I'm sorry for the great possibility of both missleading information > and perhaps wrongly introduced false hope Don't worry, that is quite unlikely. Nobody around here takes your silly babbling serious anymore anyway. > PS: It just might be bettter to wait for Qonos.... Why not wait for Santa Claus. That's in just a few weeks, too. -- Helen. === Subject: Connecting a 49G+ under Linux Hi all, well the subject sums up my question. Is it possible to connect to the calculator using Linux (SuSE Professional 9.1). I guess more specifically, is there any program that will let me do this? Alejandro === Subject: Re: Connecting a 49G+ under Linux Yes, it supposedly is possible. The first thread that comes up contains the basic information that you should need. In the probable case that you don't have an x-modem server installed on linux, one can be obtained from http://www.ohse.de/uwe/software/lrzsz.html Unfortunately, I haven't been able to get the USB stuff working on my box yet; so I can't confirm that all this actually works. Good luck, Daniel P.S> There is a linux program available for the older HP series (http://hptalx.sourceforge.net/); this might work with (or be easily adjusted to) the 49G+ series. === Subject: Simple Snake game for 49g+ Hi all, Having a few hours to kill, I made a simple 'Snake' game for the 49g+. It really is simple - no fancy graphics or sound effects. The only good thing about it is it runs in a low power mode to conserve batteries. If anyone is interested, its at http://alpage.ath.cx/hptute/hpprog.htm For those who don't know, the object of 'snake' is to move around eating appels (little dots). Each time you eat one the snake gets bigger, and it becomes harder to get the next apple. If you run into the snakes body, or off the screen you lose. Please post any bug reports here, or email me. cheers, Al === Subject: Re: Simple Snake game for 49g+ Dang Al I was going to do that one lol Mick Carey www.deakin.edu.au/~mpcare/ > Hi all, > Having a few hours to kill, I made a simple 'Snake' game for the 49g+. > It really is simple - no fancy graphics or sound effects. The only good > thing about it is it runs in a low power mode to conserve batteries. If > anyone is interested, its at http://alpage.ath.cx/hptute/hpprog.htm > For those who don't know, the object of 'snake' is to move around eating > appels (little dots). Each time you eat one the snake gets bigger, and > it becomes harder to get the next apple. If you run into the snakes > body, or off the screen you lose. Please post any bug reports here, or > email me. === Subject: OT: TI joke A young engineering student went to a bar for a beer. He'd had a rough week, so he decided to leave his all of his school stuff in his car. As he went into the bar, he said to himself, I'm not studying tonight, I'm taking a break! Half way through his first beer, he realized that he'd left his car unlocked. To make matters worse, he'd left his TI-92 in plain view on the back seat. Realizing this mistake, he rushed out to his car. The whole way out, he was berating himself for leaving his car unlocked. He kept saying to himself, You did it again, didn't you learn last time!?! He got out to his car and looked in the back seat. His brow furrowed as he realized that he was too late. There on the back seat was three more TI calculators sitting next to his.