B439 === Subject: Re: just a second of your time...a newbie question Yes ! I have a Corsair 512 MB 40X speed and works perfect. Also has a Kingston 128 MB normal speed that I use in the GPS to collect data and transfer to the HP49G+ works fine but the 40x is MUCH MUCH better. Daniel. === Subject: Re: Release: ExtraFunc49+ v0.88 > I've just submitted a new lib to www.hpcalc.org: ExtraFunc v0.88. > It's as described a few months ago (C-based lib with - currently - 30 > extra functions for the HP49G+), I just never got around releasing it > until now. I hope to update it soon. The latest What's New? on hpcalc is dated May 14. === Subject: Re: Release: ExtraFunc49+ v0.88 > The latest What's New? on hpcalc is dated May 14. Yes, Eric doesn't update very regularly, but he'll probably get around to it eventually. I expect he has other things on his mind occasionally If you want the library from me instead, I can send it to you on an email - just drop me a line. Steen === Subject: Re: Release: ExtraFunc49+ v0.88 >>The latest What's New? on hpcalc is dated May 14. > Yes, Eric doesn't update very regularly, but he'll probably get around > to it eventually. I expect he has other things on his mind occasionally > If you want the library from me instead, I can send it to you on an > email - just drop me a line. Steen What are the functions in it? Marty === Subject: Re: Release: ExtraFunc49+ v0.88 > What are the functions in it? Currently: ACOT(z) ACOTH(z) ACSC(z) ACSCH(z) ASEC(z) ASECH(z) BELLNUM(n) BETA(p,q) CATALAN(n) COT(z) COTH(z) CSC(z) CSCH(z) DBLFACT(z) DELTA(n) FACTORIAL(z) FIBNUM(n) HEAVISIDE(n) LUCASNUM(n) LUCASSEQU(p,q,n) LUCASSEQV(p,q,n) NCR(n,k) NPR(n,k) PARTFACT(a,b) PELLNUM(n) SEC(z) SECH(z) SINC(z) STIRLINGNUM1(n,m) (slightly buggy because of unfinished C-code) STIRLINGNUM2(n,m) (slightly buggy because of unfinished C-code) Steen === Subject: Re: Release: ExtraFunc49+ v0.88 >>What are the functions in it? > Currently: ACOT(z) > ACOTH(z) > ACSC(z) > ACSCH(z) > ASEC(z) > ASECH(z) > BELLNUM(n) > BETA(p,q) > CATALAN(n) > COT(z) > COTH(z) > CSC(z) > CSCH(z) > DBLFACT(z) > DELTA(n) > FACTORIAL(z) > FIBNUM(n) > HEAVISIDE(n) > LUCASNUM(n) > LUCASSEQU(p,q,n) > LUCASSEQV(p,q,n) > NCR(n,k) > NPR(n,k) > PARTFACT(a,b) > PELLNUM(n) > SEC(z) > SECH(z) > SINC(z) > STIRLINGNUM1(n,m) (slightly buggy because of unfinished C-code) > STIRLINGNUM2(n,m) (slightly buggy because of unfinished C-code) Steen How about log(gamma)? For complex args? === Subject: Re: Release: ExtraFunc49+ v0.88 > How about log(gamma)? For complex args? Not yet. I have a list of ~200 functions I'd like to implement, many of them relatively easy to implement given the C-code I've already done. I'm at the moment tryng to code an efficient integer division routine, which I need for the Stirling functions (which is why the Stirling functions in the lib currently are somewhat unstable). This lead to integer factorization, and then to primality testing and so on. Now I'm trying to decide if I should return to binary internal representation find the 700,000th Fibonacci number anyway?) but will make much of the math much simpler to implement. It'll probably also save some bytes in the C-lib. I'd also like to code a complete expression-parser in C (since I need that for a solver, a plotter and a numeric integration routine), but that entails coding C-versions of all (or most of) the built-in numeric functions. Steen === Subject: Re: Release: ExtraFunc49+ v0.88 Some interesting ones, I guess mainly for students. Still I look forward to give it a try once it appears on hpcalc.org. What is the size of the library? Arnaud === Subject: Re: CLKADJ? Scott Chapin schrieb .. > I am using Heiko Arnemann's program , ClkAdj, with much success. It adjusts > the time by full seconds and keeps a running total of fractional seconds not > adjusted for. It keeps the clock running between .5 seconds slow to .5 > seconds fast. That's about all you can hope fpr with the HP49G+. .. Hello together, hello Scott, yes, that's the point, a time keeper for the 49g+ should only allow to adjust with multiples of 1 s. I have started a test run with my ClckAdjst+ for the hp 49g+. After calibration I got a required adjustment of about 1.819 s/d With this adjustment I have an average drift of -0.006 s/d, so my hp-clock calibration is still improveable I am testing with ROM 2.06, recomanded is ROM 2.0 or later. For those who would like to try, download from: http://users.belgacom.net/EAA/Heiko/HP49/index.htm Version 3.0, 2006-03-17 79 kByte Version 3.0, automatic clock adjustment, time zones, automatic daylight saving time change: Program with english docu. The program is a lib with 3 kByte. Please note, that hp 49g+ canot be adjusted better than +/-0.5 s, but it is possible to check, *when (at which time of the day) it would run without drift. That is what my program provides. For those who are interested, I can provide a program which calculates the drift. Sorry, no up to date version on Eric's site :-( Heiko === Subject: Re: A bit of fun: A very old computer language Yeah, pretty funny. I need a new keyboard for these symbols, right? Just like APL. BTW (and I realize a lot of you already know this) there is a serious open-source statistical computing language known as R. See: http://lib.stat.cmu.edu/R/CRAN/ Mark === Subject: Re: A bit of fun: A very old computer language BTW (and I realize a lot of you already know this) there is a serious open-source statistical computing language known as R. See: http://lib.stat.cmu.edu/R/CRAN/ ------------ I had actually Google searched for that statistical R language and came upon the Druidical version. I don't think druidical R is Turing complete, but it made me smile. Lance === Subject: Numerical Problems with SOLVEVX and EVAL Here is a problem I ran into some time ago: Let's say you want to solve the quadratic equation, (*) A*X^2 - 2*B*X + C = 0, with A=1.E-13, B=1., C=1. Well, SOLVEVX returns {'X=(2*B-SQRT(4*B^2-4*A*C))/(2*A)' 'X=(2*B+SQRT(4*B^2-4*A*C))/(2*A)'}, and subsequent EVAL returns X=2.E13 and X=0. Obviously, X=0 is wrong (should be X=0.5 instead). If (*) is evaluated first, i.e., 1.E-13*X^2 - 2*X +1 = 0, SOLVEVX returns {'X=0.55 'X=2.E13'}. X=0.55 is still wrong, unfortunately. I realize that the equation is not well conditioned, and that a cancellation error is responsible for the solution of X=0, but X=0.55??? Why should a prior EVAL make such a difference? Any insight is appreciated. P.S. And here is somethig else: change A to 1.E-14, so the equation should even be worse conditioned, right? However, now SOLVEVX gives the correct answer {'X=2.E14' 'X=0.5'}, but only with a prior EVAL (otherwise it's wrong again). === Subject: Re: Numerical Problems with SOLVEVX and EVAL format=flowed; reply-type=original > (*) A*X^2 - 2*B*X + C = 0, with A=1.E-13, B=1., C=1. Well, SOLVEVX returns {'X=(2*B-SQRT(4*B^2-4*A*C))/(2*A)' > 'X=(2*B+SQRT(4*B^2-4*A*C))/(2*A)'}, and subsequent EVAL returns X=2.E13 > and X=0. Obviously, X=0 is wrong (should be X=0.5 instead). One way is to use the command ->FNUM in the LongFloat library by Gjermund Skailand and Thomas Rast. For example, 'A*X^2-2*B*X+C' SOLVEVX << EQ-> SWAP DROP ->FNUM Format >> MAP Then you get { 0.50000...., 0.199999...E14 } Another way is that transforming the answer 'X=(2*B-SQRT(4*B^2-4*A*C))/(2*A)' to avoid ill condition, which can be found in a book of numerical analysis. Matsubara === Subject: Re: Numerical Problems with SOLVEVX and EVAL format=flowed; reply-type=response >> (*) A*X^2 - 2*B*X + C = 0, >> with A=1.E-13, B=1., C=1. >> Well, SOLVEVX returns {'X=(2*B-SQRT(4*B^2-4*A*C))/(2*A)' >> 'X=(2*B+SQRT(4*B^2-4*A*C))/(2*A)'}, and subsequent EVAL returns X=2.E13 >> and X=0. Obviously, X=0 is wrong (should be X=0.5 instead). > Another way is that transforming the answer > 'X=(2*B-SQRT(4*B^2-4*A*C))/(2*A)' to avoid ill condition, which can be > found in a book of numerical analysis. One way to do this is as follows: First, delete variable A, B, C and multiply the numerator and the denominator simultaneously by (2*B-SQRT(4*B^2-4*A*C))/A using EQW. In EQW, EVAL the denominator and the numerator independently, you get C/(B+sqrt(B^2-A*C)). After that, store the values in A,B,C and evaluate the above. Then you can get 0.5. Matsubara === Subject: Re: Numerical Problems with SOLVEVX and EVAL format=flowed; reply-type=response I made a mistake. > One way to do this is as follows: > First, delete variable A, B, C and multiply the numerator and the > denominator simultaneously by (2*B-SQRT(4*B^2-4*A*C))/A using EQW. by (2*B+SQRT(4*B^2-4*A*C))/A is correct. > In EQW, EVAL the denominator and the numerator independently, you get > C/(B+sqrt(B^2-A*C)). > After that, store the values in A,B,C and evaluate the above. > Then you can get 0.5. Matsubara === Subject: Re: Numerical Problems with SOLVEVX and EVAL It enables one to use SOLVE or SOLVEVX, so without having to go root hunting, one still gets the complete set of solutions, even for ill-conditioned problems! Of course, one needs the LongFloat library. Very nice! And within LongFloat, there is NRSOLVE, which also works fine for X=0.5, e.g., A*X^2-2*B*X+C X 2 NRSOLVE -> 500000....E-25 ERR: 0 (But for some reason I can't get it to work for 1.99999....E13). === Subject: Re: Numerical Problems with SOLVEVX and EVAL I played around with Longfloat, and you need at least 14 digits to get the solution X=0.5, and you need at least 15 digits to get both solutions X=0.5 and X=0.199999999999995E14. And, by the way, NRSOLVE has a problem. It returns 500000000000012500...E-25 with DIGITS set to 25, which is wrong. === Subject: Re: Numerical Problems with SOLVEVX and EVAL format=flowed; reply-type=original > And, by the way, NRSOLVE has a problem. It returns > 500000000000012500...E-25 with DIGITS set to 25, which is wrong. This result is correct. The answer is not exactly 0.5. The answer is C/(B+sqrt(B^2-A*C)) as I posted. This is 1/(1+sqrt(1-1E-13)), hence this is larger than 0.5. Set DIGITS=30 and do again by SOLVEVX and ->FNUM. Then, you can get the answer as NRSOLVE. Matsubara === Subject: Re: Numerical Problems with SOLVEVX and EVAL I get {x=0 x=2E26} Maybe you have a X value stored in HOME dir or you mess with calc config, to reset all calc parameters without losing your vars: :2:BACKUP ARCHIVE [ON]+[F1]+[F6] [F6] :2:BACKUP RCL RESTORE hgabert@xmission.com ha escrito: > Here is a problem I ran into some time ago: Let's say you want to > solve the quadratic equation, (*) A*X^2 - 2*B*X + C = 0, with A=1.E-13, B=1., C=1. Well, SOLVEVX returns {'X=(2*B-SQRT(4*B^2-4*A*C))/(2*A)' > 'X=(2*B+SQRT(4*B^2-4*A*C))/(2*A)'}, and subsequent EVAL returns X=2.E13 > and X=0. Obviously, X=0 is wrong (should be X=0.5 instead). If (*) is evaluated first, i.e., 1.E-13*X^2 - 2*X +1 = 0, SOLVEVX returns {'X=0.55 'X=2.E13'}. X=0.55 is still wrong, > unfortunately. I realize that the equation is not well conditioned, and that a > cancellation error is responsible for the solution of X=0, but > X=0.55??? Why should a prior EVAL make such a difference? Any insight > is appreciated. P.S. And here is somethig else: change A to 1.E-14, so the equation > should even be worse conditioned, right? However, now SOLVEVX gives > the correct answer {'X=2.E14' 'X=0.5'}, but only with a prior EVAL > (otherwise it's wrong again). === Subject: Re: Numerical Problems with SOLVEVX and EVAL This is strange. What ROM version are you running? (I'm running 2.04-5). Are you sure you're inputting the same equation? In any case, your solution is wrong as well. The correct solution should be X=0.5, which can be verified by putting on the stack [A*X^2-2*B*X+C] [X] [0.1] MSLV -> [.5] I guess the calc doesn't carry enough digits of precision to support this type of ill-conditioned equation using SOLVEVX. But I was really vexed by the fact that SOLVEVX would return different results (all wrong, of course) *based* on whether the equation is input with global variables A, B, and C, or input with those variables already evaluated, i.e., 1.E-13, 1., and 1. And then, SOLVEVX returns the correct answer for A=1.E-14!!! Weird. === Subject: Re: Numerical Problems with SOLVEVX and EVAL > I guess the calc doesn't carry enough digits of precision to support > this type of ill-conditioned equation using SOLVEVX. That's correct. The calculator support no more than 12 digits of precision when doing ordinary algebra (which this is). Internally, some numerical operations carry 15 digits of precision though. > But I was really vexed by the fact that SOLVEVX would return different > results (all wrong, of course) based on whether the equation is input with > global variables A, B, and C, or input with those variables already > evaluated, i.e., 1.E-13, 1., and 1. You shouldn't be. Since it's a question of resolution in algebraic evaluation, you'd expect different round off errors depending on how your algebraic expression looks. The two expressions (that yield different, wrong, results) are algebraically not equal. > And then, SOLVEVX returns the correct answer for A=1.E-14!!! Weird. A coincidence. PROOT will handle these types of polynomial problems much better (it's specially designed to postpone round-off errors like the ones you've found). The algebraic solvers (like SOLVEVX) are dumb - they cannot choose a different algorithm if ordinary algebraic evaluation fails. It's a matter of knowing the limitations of your tools. Steen === Subject: Re: Numerical Problems with SOLVEVX and EVAL dangerous, as we just saw). But PROOT gives 2E13 as the second root, which is also wrong (should be 1.999.... E13); however, as you pointed out, it's the best approximation within the calc's 12 digit accuracy. P.S. I also tried your Numeric49 library's NSOLVE and CNSOLVE commands; they solve the expression correctly for X=0.5 (but no other variables besides X are allowed, i.e EVAL or NEVAL need to happen first. Why?). === Subject: Re: Numerical Problems with SOLVEVX and EVAL > is dangerous, as we just saw). Doing anything without thinking about the context is prone to error :-) > But PROOT gives 2E13 as the second root, which is also wrong (should > be 1.999.... E13); however, as you pointed out, it's the best > approximation within the calc's 12 digit accuracy. Exactly. > P.S. I also tried your Numeric49 library's NSOLVE and CNSOLVE > commands; they solve the expression correctly for X=0.5 (but no other > variables besides X are allowed, i.e EVAL or NEVAL need to happen > first. Why?). Because those are numeric solvers, as stated in the manual. The variable name does not have to be 'X' btw, but only the unknown variable may exist in the equation. Steen === Subject: (HP48G) Saturn and Cycles I'm still working on my game and as I looked for more informations about the performances of the Saturn, I stumbled across this : http://www.hpcalc.org/details.php?id=1707 (cycle count, looks like the one in Voyage au centre de la HP and all the official stuff) and this : http://www.hpcalc.org/details.php?id=4923 (cycle count found using experiment). the Saturn's frequency truly 8 MHz or 4 Mhz? === Subject: Re: (HP48G) Saturn and Cycles hello, these cycles are not really good... the saturn is at 4Mhz, optimization is as follow: - reduce memory access (read/write) as much as you can (slow) - reduce jumps as much as you can - use A feilds whenever you can - make sure that every instruction does something (acheive the ulterior aim), ie: use action instruction, not affectation or data excahnge and you will be in good shape. of course, the cycles are completly different on the new 49 due to the emulation... cyrille I'm still working on my game > and as I looked for more informations about the performances of the > Saturn, I stumbled across this : http://www.hpcalc.org/details.php?id=1707 (cycle count, looks like the > one in Voyage au centre de la HP and all the official stuff) and this : http://www.hpcalc.org/details.php?id=4923 (cycle count found using > experiment). the Saturn's frequency truly 8 MHz or 4 Mhz? === Subject: Re: (HP48G) Saturn and Cycles X > of course, the cycles are completly different on the new 49 due to the > emulation... X Any knowledge on Emulated Saturn cycles? Even approximate figures (ARM CPU cycles?) would be nice 2 know === Subject: Re: (HP48G) Saturn and Cycles <50Zcg.993$xg7.675@news.cpqcorp.net> These are good overall hints. But I want to optimize as much as I can my basic graphic routines : tile drawing, sprite drawing and screen scrolling (even though I want to do hardscroll, I have to prepare the screens on which I am going to work). E.g. my tile drawing routine : My tile are 12x12 pixels (I know, working on 3 nibbles is not the fastest but 25x25 tiles are too big). %D0 points on the beginning of the data of the tile %D1 points on the screen at the right place LC (5) JumpLine % e.g. 34q -- my screen is wider in fact A = DAT0 A D0+3 DAT1 = A 3 % I can't write more than 3q otherwise I'll overwrite the tile on the right AD1EX A=A+C A D1 = A twelve times (saves a test and a jump) I skip the fact that I've to do it once more (for grayscale). Since I want this routine to be as fast as possible, I'd rather have precise cycle counts. And I'd like to know if the speed of the instructions truly depends on the address of it, since it could save me a few cycles if I manage to put the first instruction on the best address (even or odd). The number of sprites I may handle depends of it. What do you think about it? === Subject: Re: (HP48G) Saturn and Cycles hello, what you describe is the fastest way to do it (according to your requirements). the only way to speed it up would be to go to a fixed scan line size and use D1=D1+xxx (provided that the xxx is not so big that it overrides the benefits of it). routine address parity will not change much because you have mixed odd and even sized instructions, and that will interleave the odd and even address in your function and at the end, you will not have much more than a cycle or 2 difference. knowing that your routine takes around 2000 cycles. don't be too annal in low level optimization, it helps only to a certain extend, I mean, gaining 10 cycles on a 2000 cycles routine won't change anything in the final product. you still have not told us which calcualtor you are using exactly... cyrille These are good overall hints. But I want to optimize as much as I can > my basic graphic routines : tile drawing, sprite drawing and screen > scrolling (even though I want to do hardscroll, I have to prepare the > screens on which I am going to work). E.g. my tile drawing routine : My tile are 12x12 pixels (I know, working on 3 nibbles is not the > fastest but 25x25 tiles are too big). %D0 points on the beginning of the data of the tile > %D1 points on the screen at the right place > LC (5) JumpLine % e.g. 34q -- my screen is wider in fact A = DAT0 A > D0+3 > DAT1 = A 3 % I can't write more than 3q otherwise I'll overwrite the > tile on the right > AD1EX > A=A+C A > D1 = A twelve times (saves a test and a jump) I skip the fact that I've to do it once more (for grayscale). Since I want this routine to be as fast as possible, I'd rather have > precise cycle counts. And I'd like to know if the speed of the > instructions truly depends on the address of it, since it could save me > a few cycles if I manage to put the first instruction on the best > address (even or odd). The number of sprites I may handle depends of it. What do you think about it? > === Subject: Re: (HP48G) Saturn and Cycles <50Zcg.993$xg7.675@news.cpqcorp.net> cyrille de Brebisson a .8ecrit : you still have not told us which calcualtor you are using exactly... > HP48GX. I'm trying to get a new one since the keys of the rightmost column are not working properly anymore. I'll keep the graphic routines as much separated as I can from the other code in order to be able to port them as easily as possible to 49G+. === Subject: Re: (HP48G) Saturn and Cycles > Since I want this routine to be as fast as possible, I'd rather have > precise cycle counts. And I'd like to know if the speed of the > instructions truly depends on the address of it, since it could save me > a few cycles if I manage to put the first instruction on the best > address (even or odd). The number of sprites I may handle depends of it. What do you think about it? -there are old documents about instruction cycles (execution times) -note that timings/cycles depend on operators field size, instruction position (odd/even address) and addressing alignment (D0/D1 odd or even). -detailed cycle-analysis is not plain counting cycles and it has at least 2 scenarios (depending on your code -even more) -since Saturn has variable-length instructions placing first instruction on odd/even address won't help, on the other hand RISC processors (like ARM) are beauty in this regard. -even if you do all the optimisations up to cycle, even if it is correct it won't apply to new ARM based series which will dominate the sceene for shure once people realize what they are missing in old GXes :-) (not ment to insult anyone) Conclusion... You will loose a lot of time on the other hand you will gain very little if anything at all. Just follow the Cyrille's guidelines and you will be fine. In most cases general optimisation guidelines give better results than cycle-counting. (you gain one here -you loose one there) but if you follow the general path (idea) you will be ok. Also during processing try to use as small fields as possible, and try to re-use registers as much possible: if you use 20 bits (A-fields) of registers try to use higher 40+ bits for other stuff (shift, of course, is quicker than load from memory) enough :-) : Read the entire sprite (or larger section) in to some register(s), (A to read the sprite, B and D as counters and C as helping register during write) In your case A is not big enough to hold the entire sprite so you should consider doing the sprite in 2 stages. You will be able to read your entire sprite in 3 read cycles, you will (most probably) write 4 lines in each cycle this makes total of 15 memory operations (not a bad job) If you read and write your sprite in lines you will do 24 memory operations (bad job) of course if you decide to mix your sprite with the background and, or, add... whatever, you will need additional cycles With 49G+ and OPENFIRE it gets very easy since you have your pixel 4 bits so 16 grayscales is very easy. 4 grayscales is not so bad as well but is a bit tricky since pixel size is not so practical (on the other hand -you can process more of them at the same time). Something like MMX / SSE technology inside your pocket-calculator he he :-) Have fun ! manjo === Subject: Re: (HP48G) Saturn and Cycles <50Zcg.993$xg7.675@news.cpqcorp.net> manjo a .8ecrit : > Read the entire sprite (or larger section) in to some register(s), (A to > read the sprite, B and D as counters and C as helping register during write) > In your case A is not big enough to hold the entire sprite so you should > consider doing the sprite in 2 stages. You will be able to read your entire sprite in 3 read cycles, you will (most > probably) write 4 lines in each cycle > this makes total of 15 memory operations (not a bad job) > If you read and write your sprite in lines you will do 24 memory operations > (bad job) > of course if you decide to mix your sprite with the background and, or, > add... whatever, you will need additional cycles I thought about it - reading 12q once, then writing 4 lines of 3q. But when I checked in the cycle table, I found that the shift operation is also time-consuming. According to the table, reading 3q and moving the D0 pointer takes approx. 21 cycles A=DAT0 A % faster than reading just 3q D0+3 % write data Reading 12q, shifting 3q, shifting 3q, shifting 3q and moving D0 takes approx. 106 cycles, and 106 > 21 * 4 A=DAT0 12 % write data ASR 12 ASR 11 ASR 10 % write data ASR 9 ASR 8 ASR 7 % write data ASR 6 ASR A ASR A % faster than ASR 4 %write data D0+12 Are these cycle tables completely wrong and useless? Is there a faster way to perform shifts? Am I missing something? > With 49G+ and OPENFIRE it gets very easy since you have your pixel 4 bits so > 16 grayscales is very easy. > 4 grayscales is not so bad as well but is a bit tricky since pixel size is > not so practical (on the other hand -you can process more of them at the > same time). > Something like MMX / SSE technology inside your pocket-calculator he he :-) I had in mind 4 levels of grayscale. I guess that 16 levels mean twice more data to write... > Have fun ! > manjo === Subject: HHC2005 HP Handheld Conference Video Available The HHC2005 HP Handheld Users' Conference, held 9/17-18/2005 in Franklin Park, Illinois was videotaped and the entire 14-and-a-half-hour event is now available on DVDs. If interested, check http://www.pahhc.org/video.htm on the web. Jake Schwartz ( jakes pahhc org ) P.S. - The HHC2006 conference is in the planning stages now. It will be held in September. Check http://holyjoe.net/hhc2006/ for details when they are available.... === Subject: Re: HHC2005 HP Handheld Conference Video Available > Check http://holyjoe.net/hhc2006/ > for details when they are available.... A notice will be posted here as soon as the HHC 2006 website contains any information. It's currently just a placeholder. -Joe Horn- Webmaster, HHC 2006 === Subject: Buying advice After seeing quite a few RPL HP calcs in use I decided to take the plunge and buy one. I ordered a hp 48gII and have been quite impressed with the features so far. I love the equation writer and the CAS system and great display. Of course a couple of my keys are starting to go bum and i'm thinking it's time to order a new one. Has the key problem been fixed on the 49 series new production runs? Or should I look into a true 48 series calc? Zorton === Subject: Re: Buying advice This excellent post from someone who knows is required reading: And I guess you want to get a 49g+ which is not that much more expensive than the 48gii but more powerful and supported on this forum. Arnaud === Subject: Re: Buying advice It looks like i'll be getting a 49g+ for sure as the 48gII I use just blew it's enter key. Very annoying. I'll contact HP in the morning and see what's what. Zorton === Subject: Re: Buying advice It looks like i'll be getting a 49g+ for sure as the 48gII I use just > blew it's enter key. Very annoying. I'll contact HP in the morning and see what's what. Maybe the 50gs will be out before you want to order it JY === Subject: Re: Need help converting a user input into rpn in sys rpl I have idea programing with user rpn exactly not sure what you wan to do with RPN and system rpl? elaborate further perhaps someone will help. === Subject: Re: New HP 50 G ? > Remember: Anyone who talks about a rumored product did not work on the product. Why? Because anyone who worked on a rumored product would be under a strict > non-disclosure agreement where they cannot talk about a purported > product. That is ALWAYS the case. If someone did talk about a product before it was released, regardless > of the manufacturer, they would either a) be in trouble with the > company, b) not work on any future products or c) both. AND since I'm not a betatester or anyway involved I can freely say that yes it seems to be a slightly evolutionary product with excellent keyboard and some other enhancements 4*AAA batteries and both RS & USB The ROM is naturally updated , but there is no HUGE changes If I'm not taken in I can also start to talk about the HP-51G project What about the new secret handheld, which is based on a iPAQ and these features: How do I know these? a) anyone could guess it b) bull***** around with no knowledge whatsoever c) calculator division of HP is so predictable d) demonic powers so me the future e) evolution of CAS calculatrice is so obvious f) full knowledge of all HP project is available on a crackers net site g) googling around & putting the pieces together h) I have broken into several web sources and gained secret information i) I'm so good at guessing j) just rumours ... z) zomeone at HPQ in the USA is tipping me off now & then === Subject: Re: New HP 50 G ? <4d8f2fF199rlpU9@individual.net> <4dfqd1F1accegU1@individual.net> <3Njdg.1112$kO4.605@reader1.news.jippii.net> If it is just an evolutionnary product then i am absolutely not interested. Especially if the HP50G is what the HP49G+ was supposed to be. Seriously i wonder why HP has fired the ACO as they obviously need the help of hydryx to release even barely improved products over their current line. They should make an agreement with hydryx to let them design the replacant of the HP49G series with Qonos as the starting point. === Subject: Re: New HP 50 G ? hp is obviously off track and flailing wildly at best. They need to do something drastically different. They should be considering all possibilities to return their reputation to it former status! > If it is just an evolutionnary product then i am absolutely not > interested. > Especially if the HP50G is what the HP49G+ was supposed to be. > Seriously i wonder why HP has fired the ACO as they obviously need the > help of hydryx to release even barely improved products over their > current line. > They should make an agreement with hydryx to let them design the > replacant of the HP49G series with Qonos as the starting point. > === Subject: Re: New HP 50 G ? > ...a rumored product... But here are the first actual *photos* of HP50G (and HP50S!) On http://www.katiestreasures.com.au/jewe-earring.html [bottom right] Head Pins HP50G Gold $ 0.10 each HP50S Silver $ 0.10 each To compute, move the pins around your Cribbage board. === Subject: Re: New HP 50 G ? <4d8f2fF199rlpU9@individual.net> <4dfqd1F1accegU1@individual.net> ...a rumored product... But here are the first actual *photos* of HP50G (and HP50S!) On http://www.katiestreasures.com.au/jewe-earring.html [bottom right] Head Pins > HP50G Gold $ 0.10 each > HP50S Silver $ 0.10 each To compute, move the pins around your Cribbage board. So the R&D and possibly production of the new units has moved back to Australia. Good news!!! HP's merger with Katie's appears to be very apropos (Where Customer Service is #1, according to the website). Good to know! Also, the keyboard issues seem to have been laid to rest once and forever. The new shapes are simply revolutionary. Too bad for Kinpo, but you just can't hold up progress! === Subject: Re: New HP 50 G ? <4d8f2fF199rlpU9@individual.net> <4dfqd1F1accegU1@individual.netAnyone who talks about a rumored product did not work on the product. Correct, but he CAN talk about the RUMORS, as such, since they are publicly known. He cannot, of course, reveal which rumors are accurate, if any. > So, again, why would you think JYA would publicly answer this type of > question? Lead us not into temptation? o:-) -jkh- Disclaimer: That's the rumor, anyway. === Subject: Re: emu48 running on Linux > Here it is, after some minor modifications in the sources of emu48, > emu48 is working correctly. The *only* thing you need to run the > executable is the library libwine.so So now, emu48 can run on any UNIX platform :) If you want the patch, please ask me (replace the .invalid with .fr in > my mail address) Khanh-Dang, your email seems to be invalid, so i'm asking here - could you give me the patch? Pretty please -- If you cut off my head, what would I say? Me and my head, or me and my body? === Subject: Re: emu48 running on Linux Here it is, after some minor modifications in the sources of emu48, > emu48 is working correctly. The *only* thing you need to run the > executable is the library libwine.so So now, emu48 can run on any UNIX platform :) If you want the patch, please ask me (replace the .invalid with .fr in > my mail address) Khanh-Dang, your email seems to be invalid, so i'm asking here - could > you give me the patch? Pretty please Sorry, I cannot find the patch anymore. I might have lost it somewhere in my hard disk. However, did you try to launch emu48 with wine ? You are likely to use freebsd on x86, so wine is available for your system and should emulate more or less flawlessly emu48. To emulate a hp49, you should use a special version of emu48 which can also emulate a HP49G+. I am using emu48 v1.38+, which is available in the latest Debug4x package available on hpcalc.org. You can try to use a legacy version of emu48, but the screen will certainly not be emulated correctly. There is no problem with emulating a HP48 ROM through. If you don't need the powerful debugger of emu48, you can try the emulator saturn, available on hpcalc.org. HP39/40): - Emulating a HP38 calc with saturn: - Transfering a file to a HP38 emulated by wine: calcs on UNIX systems. === Subject: Re: emu48 running on Linux >> Here it is, after some minor modifications in the sources of emu48, >> emu48 is working correctly. The *only* thing you need to run the >> executable is the library libwine.so >> So now, emu48 can run on any UNIX platform :) >> If you want the patch, please ask me (replace the .invalid with .fr in >> my mail address) >> Khanh-Dang, your email seems to be invalid, so i'm asking here - could >> you give me the patch? Pretty please Sorry, I cannot find the patch anymore. I might have lost it somewhere > in my hard disk. OK, i managed to compile it using winelib. There is still one 'small issue', though - most of the display (everything except the top - one where 'alpha', shift etc markings appear) is black all the time Also, i have problem with ROM images - trying to load most of them, including these known to work in x48, results in 'Packed ROM image detected!' error. > However, did you try to launch emu48 with wine ? You are likely to use > freebsd on x86, so wine is available for your system and should emulate > more or less flawlessly emu48. Same problem. I'll try again with different wine version. > To emulate a hp49, you should use a special version of emu48 which > can also emulate a HP49G+. I am using emu48 v1.38+, which is > available in the latest Debug4x package available on hpcalc.org. You > can try to use a legacy version of emu48, but the screen will certainly > not be emulated correctly. I was trying (with effect described above) with these sources: http://privat.swol.de/ChristophGiesselink/Emu48/e48sp41.zip. > There is no problem with emulating a HP48 ROM through. If you don't need the powerful debugger of emu48, you can try the > emulator saturn, available on hpcalc.org. Right now i'm using x48. Works very well - including receiving files from host using 'serial over pseudoterminal' - but has no (working) debugger. And no HP49 emulation. > HP39/40): > - Emulating a HP38 calc with saturn: > calcs on UNIX systems. -- If you cut off my head, what would I say? Me and my head, or me and my body? === Subject: Re: emu48 running on Linux <44781458$0$20138$8fcfb975@news.wanadoo.fr> [running emu48 with wine] > OK, i managed to compile it using winelib. There is still one 'small > issue', though - most of the display (everything except the top - one > where 'alpha', shift etc markings appear) is black all the time Yes. This is a known issue. That's the reason why I adviced you to use the emu48+ version. Just extract the emu48.exe file in the Debug4x archive: including these known to work in x48, results in 'Packed ROM image > detected!' error. I am not sure, but there is a unpack script in the x48 package, or the saturn (see below) one, I can't remember. > To emulate a hp49, you should use a special version of emu48 which > can also emulate a HP49G+. I am using emu48 v1.38+, which is > available in the latest Debug4x package available on hpcalc.org. You > can try to use a legacy version of emu48, but the screen will certainly > not be emulated correctly. I was trying (with effect described above) with these sources: > http://privat.swol.de/ChristophGiesselink/Emu48/e48sp41.zip. You should try the emu48+ executable, as stated above. > Right now i'm using x48. Works very well I can't remember why and how, but I sometime got a frozen x48, so I don't use it anymore. > - including receiving > files from host using 'serial over pseudoterminal' - but has no > (working) debugger. And no HP49 emulation. Yes. Using a terminal is really powerful, and useful too. There is a native Unix emulator that can emulate HP49. It's called saturn: I find saturn really great. The only missing function is the debugger. === Subject: Re: emu48 running on Linux >Yes. Using a terminal is really powerful, and useful too. There is a >native Unix emulator that can emulate HP49. It's called saturn: >I find saturn really great. The only missing function is the debugger. Is there any interest in a GTK front-end to Saturn with KML support? I use x48 on my Linux workstation and Zaurus PDA (http://sense.net/zc/x48) with a lot of success, but would like some type of skin support. For future development I am leaning toward Saturn over x48 becasue Saturn overhead is much less--important for embedded devices. I have already explored porting EMU48 to Linux twice--it is non-trivial and WINE is not an option for non-x86. What is of more interest, GTK/KML support for Saturn or x48? Is this good enough or is EMU48 for Linux the only answer? Would a community support Saturn and make it better than EMU48? === Subject: Re: Debug4x with HP48GII > HP48GII library. > Should I be in 49 mode or 48 mode for a Library? Will it even work? The 48GII is really a 49G- Only use 49g program, and 49g mode in program such as Debug4x JY