HP-249 Subject: Re: Removing directory on SD card > i hope you're right (about flashng and directory deletion) > (the OS could be protected by flash-utility > in the way that only certain blocks are flashable > i figure that is the way how flash utility protects itself from being > destoyed with faulty flash > -so you can flash with proper firmware, of course if flash-utility would be destroyed and unit would be useless) Well, the datasheet for the Flash chip is at http://lebonpoint.chez.tiscali.fr/hp49gp/S71145.pdf You can see there doesn't appear to be any hardware write protection. As discussed earlier on this newsgroup the bootblock is totally unprotected. I guess the flash utility is normally programmed not to override itself, but theres no reason why the entire ROM couldn't changed by HP by providing a special setting. There is no protection at all, actually. No memory is protected. Accessing supervisor mode and overriding the interrupt vectors is almost trivial. This is A Good Thing in my opinion :) > It would be great news if ALL the firmware (including native ARM OS) is > flashable with no exceptions. I am very sure this is the case. Why wouldn't it be? If you disassemble one of the ROM files provided by HP, you can clearly see ARM OS code. So its probably updated every so often. === Subject: Breaking a loop in HP49G... How? What command could I use to stop a loop in the HP49G? Something like BREAK in C++ or Pascal. And another thing HALT causes an invalid sintax, Why? IF X==1 THEN HALT END (doesnt work) Error invalid Sintax THANKS it would help a lot === Subject: Re: Breaking a loop in HP49G... How? >What command could I use to stop a loop in the HP49G? Something like >BREAK in C++ or Pascal. >And another thing HALT causes an invalid sintax, Why? >IF X==1 THEN HALT END (doesnt work) Error invalid Sintax Because of the fact that your IF-clauses syntax is wrong ;-) Two possibilities: 1. IF 'x==1' THEN HALT END 2. IF x 1 == THEN HALT END Volker -- Im uebrigen bin ich der Meinung, das TCPA verhindert werden muss. === Subject: Re: Breaking a loop in HP49G... How? > What command could I use to stop a loop in the HP49G? Something like > BREAK in C++ or Pascal. > And another thing HALT causes an invalid sintax, Why? > IF X==1 THEN HALT END (doesnt work) Error invalid Sintax > THANKS it would help a lot === Subject: Re: Breaking a loop in HP49G... How? > What command could I use to stop a loop in the HP49G? Something like > BREAK in C++ or Pascal. > And another thing HALT causes an invalid sintax, Why? IF 'X==1' THEN HALT END There is no break, but: FOR k ... IF 'X==1' THEN MAXR 'k' STO ELSE ... END ... NEXT DO ... IF X 1 == THEN 77 SF ELSE ... END ... UNTIL ... 77 FS? AND END WHILE ... X 1 == NOT AND REPEAT ... END === Subject: Re: Breaking a loop in HP49G... How? X-RFC2646: Format=Flowed; Response >> What command could I use to stop a loop in the HP49G? Something like >> BREAK in C++ or Pascal. X There is no break, but: IFERR START ... IF X 1 == THEN BREAK DOERR ELSE ... END ... NEXT THEN IF ERRM BREAK == THEN ... ELSE ... END ELSE ... END === Subject: math in your head, rpn or algebraic? posting-account=cLlfiw0AAAChMJg5QaiY1LBfFgQqnnrf >No it doesn't. The keystrokes are in the wrong order. RPN is intuitive, its >the way you solve math in your head. > No. > I solve math algebraically. > RPN is as unintuitive as I've ever found a syntax to be. > And I use Lisp regularly. > Sorry, but there's my contribution to the growing flames. I'm interested in this, how does one solve math algebraically or RPN style in their head? Now, this is my take on math in ones head; you think of a number, and another number, then preform an operation on them. Does this mean I'm doing math RPN style? I don't think I could think of one number, preform an operation like adding, and then think of another number and have an answer. I'm not sure how to apply this to longer expressions or other types of operations. -Jonathan === Subject: Re: math in your head, rpn or algebraic? >>No it doesn't. The keystrokes are in the wrong order. RPN is > intuitive, its >>the way you solve math in your head. >> No. >> I solve math algebraically. >> RPN is as unintuitive as I've ever found a syntax to be. >> And I use Lisp regularly. >> Sorry, but there's my contribution to the growing flames. > I'm interested in this, how does one solve math algebraically or RPN > style in their head? > Now, this is my take on math in ones head; you think of a number, and > another number, then preform an operation on them. Does this mean I'm > doing math RPN style? Yes > I don't think I could think of one number, preform an operation like > adding, and then think of another number and have an answer. How about x = 3+2*4? You would think 2*4, multiply think 8,3 add At least that's how I do math in my head. I write math algebraically but think RPN. > I'm not sure how to apply this to longer expressions or other types of > operations. > -Jonathan -- -------------------------------------------------------------------- Purveyors of Fine DSP Hardware and other Cool Stuff Available at http://www.danvillesignal.com === Subject: PTR Is it possible to use directly PTR XXXXX in SysRpl ? Example: PTR 3BB1F for SIZE (hp49g+) . === Subject: Re: PTR > Is it possible to use directly PTR XXXXX in SysRpl ? Example: PTR > 3BB1F for SIZE (hp49g+) . Give it a try! You can use it that way, but the program will work only with that ROM, because that pointer might be moved in a ROM revision. -- === Subject: Re: Within tolerance? Try a b t - /<= a b t />= OR It should give you a single 1 or 0 to use with a IFT or CASE statement. Lee > Can someone think of a crafty way to test a number that must fall > within a specified tolerance? Example: > In userRPL, t is a given tolerance; and a calculatedresult is stored > in variable a: > if a is such that > a <= a + t AND a => a - t > then life is good, else a is not useful. > I can do it with a cumbersome group of IF constructs, but I bet there === Subject: Re: Within tolerance? Sorry I messed up .. Use a t b - >= a t b + <= AND > Try > a b t - /<= a b t />= OR > It should give you a single 1 or 0 to use with a IFT or CASE statement. > Lee >Can someone think of a crafty way to test a number that must fall >within a specified tolerance? Example: >In userRPL, t is a given tolerance; and a calculatedresult is stored >in variable a: > if a is such that >a <= a + t AND a => a - t >then life is good, else a is not useful. >I can do it with a cumbersome group of IF constructs, but I bet there === Subject: Re: hp49g+ versus TI calculator posting-account=DCDh0g0AAAClUU8ftahyKTTAfEsLo > alewando_won_@hot_won_mail.com says... >>I am very pleased with the hp 49g+ except I do have to watch the >>keyboard at times. I havew gotten a machine with a newer Serial # and >>the key action is much better. I certainly would not go for a TI >>calculator and its more limited capabilities. > Limited or not, but TI works.... Calculator without working kayboard >is as useful as a piece of brick. >A.L. > I have thought about this and I really think the keyboard thing has been > over inflated. Yes it is rather annoying that a key is missed once in a > while but I honestly don't think it is fair to say the calc is useless. > It is quite the opposite. If you pay a modest amount of attention to > your screen it will be fine. Too many folks are jumping on the > bandwagon and claiming the calc is a piece of and I really think > that it is a personal judgement. I for one find mine to be much more > useful and powerful than the so-called perfect TI-89. I tried a TI. I > took it back and got the 49G+ instead and havenever looked back. I use > my calc a lot at work, too so I think I am qualified to make these > statements. I had a TI-89 for about 6 months when I found out about the HP-49G+. About 2 months later, when the 49g+ was released I bought one, gave my 89 to my little brother, and have been pleased with the 49G+, except for finding the keyboard to be a minor nuisance. My biggest complaint is the lack of good documentation. The fact that I have to use a HP-48G manual to figure out what the commands do is a tragedy. === Subject: Re: hp49g+ versus TI calculator X-NNTP-Client: ROBOT/LX -=[ Sat, 11.12.04 09:43 a.m. +1300 (NZDT) ]=- Hi ! [...] > My biggest complaint is the lack of good documentation. > The fact that I have to use a HP-48G manual to figure out > what the commands do is a tragedy. http://www.hpcalc.org/hp49/docs/misc/49g_aug.zip A 3.3MB download. The 6 command*.PDF included are an excellent resource. I somehow missed this back in Jan 2000 when it apparently became available. I admit I still quite like my old HP48SX Programmer's Reference Manual though - one command per page - lots of room for notes :-) -- === Subject: Can anyone comment on Dust,Water,or Oil resistance? Is any evaluation available on environmental durability for the current design approach, outside of the standard Temp, Air pressure and Non condensing humidity? Is there any Shock data? What's tougher on a product: The interior of a 17 year-old's School Book Sack , or a avionic manufacture's test Lab ? I remember tossing my rucksack clear down the math building's primary stairwell after finals. My 10 series took a nice ding on the metal case, but it still functioned for my next year. === Subject: Re: Can anyone comment on Dust,Water,or Oil resistance? posting-account=QPL5xAwAAABFPcfm7160IIYN0SIaLJN5 Jack, I am a land surveyor. My hp49G+ has been in field use everyday since this time last year. I house my hp inside of an aluminum case that can be seen at www.pssllc.com. This hp has been operated in direct sunlight at temperatures of up to 100 degrees F. Mine has personally been used at temperatures as low as -22 degrees F. One I sent to aska functioned perfect at -44 degrees F. I have had at least 4 unplanned three to five foot drops to a concrete floor with no damage. Regarding wibration, as you can see on my website, the hp is mounted to a pole. This pole is made from carbon fiber, and the mount is as rigid as could be imagined. This pole is set down onto the ground thousands of times a day, and not always gently. This contant shock and vibration has not harmed the hp at all. Regarding dust,water and oil....I can work with mine in heavy rain with no problems. Soon we will have a much nicer case developed, that should be truely submersible. John === Subject: Re: Can anyone comment on Dust,Water,or Oil resistance? > Jack, > I am a land surveyor. My hp49G+ has been in field use everyday since > this time last year. I house my hp inside of an aluminum case that can > be seen at www.pssllc.com. This hp has been operated in direct sunlight > at temperatures of up to 100 degrees F. Mine has personally been used > at temperatures as low as -22 degrees F. One I sent to aska > functioned perfect at -44 degrees F. I have had at least 4 unplanned > three to five foot drops to a concrete floor with no damage. And mine made a single trip from desktop height to the floor in horizontal aspect ish... (slid out from inside a notebook), and cracked the screen diagonally across the middle. The keys missed from day one. (Wish I'd taken it back before I dropped it...8.-( ... === Subject: Re: Can anyone comment on Dust,Water,or Oil resistance? X-RFC2646: Format=Flowed; Response John, are the protective cases available for purchase? I just ordered a 49G+ to replace my 49G (which I have loved, except for it's annoying habit of pausing during calculations), and I was glad to hear that the 49G+ had held up so well for you. Please let us know how your new calc works out for you. John S. >> Jack, >> I am a land surveyor. My hp49G+ has been in field use everyday since >> this time last year. I house my hp inside of an aluminum case that can >> be seen at www.pssllc.com. This hp has been operated in direct sunlight >> at temperatures of up to 100 degrees F. Mine has personally been used >> at temperatures as low as -22 degrees F. One I sent to aska >> functioned perfect at -44 degrees F. I have had at least 4 unplanned >> three to five foot drops to a concrete floor with no damage. > And mine made a single trip from desktop height to the floor in horizontal > aspect ish... (slid out from inside a notebook), and cracked the screen > diagonally across the middle. > The keys missed from day one. (Wish I'd taken it back before I dropped > it...8.-( > ... === Subject: Re: Can anyone comment on Dust,Water,or Oil resistance? <41ba4ecd$0$45960$a344fe98@news.wanadoo.nl> posting-account=d8X8zw0AAAB_Eo2ldj3HF5DzN42pN3GY They will be shortly. In the future we have thought about plans for a soft nylon or neoprene case with some plastic inserts to give it better protection, some little pockets for SD cards, extra batteries, a beltloop, etc. TW === Subject: Re: Can anyone comment on Dust,Water,or Oil resistance? > Jack, > I am a land surveyor. My hp49G+ has been in field use everyday since > this time last year. I house my hp inside of an aluminum case that can > be seen at www.pssllc.com. This hp has been operated in direct sunlight > at temperatures of up to 100 degrees F. Mine has personally been used > at temperatures as low as -22 degrees F. One I sent to aska > functioned perfect at -44 degrees F. I have had at least 4 unplanned > three to five foot drops to a concrete floor with no damage. Regarding > wibration, as you can see on my website, the hp is mounted to a pole. > This pole is made from carbon fiber, and the mount is as rigid as could > be imagined. This pole is set down onto the ground thousands of times a > day, and not always gently. This contant shock and vibration has not > harmed the hp at all. Regarding dust,water and oil....I can work with > mine in heavy rain with no problems. Soon we will have a much nicer > case developed, that should be truely submersible. John, How are the keys? === Subject: Re: Can anyone comment on Dust,Water,or Oil resistance? posting-account=QPL5xAwAAABFPcfm7160IIYN0SIaLJN5 John, How are the keys? Well my keys are very interesting. I am using one of the first 49G+ units. I am now starting to occasionally miss a keystroke on the number 2 key if I do not press hard enough. The entire bot row of keys now has broken pivot hinges. Due to the fact that the lid of my environmental case is a clear membrane, the keys are forced to remain level, and unless I remove the 49G+ from the environmental case, this is actually an un-detectable situation. One of these days very soon I will order a few of the new batch of 49G+'s. I will continue to abuse this one everyday though. Due to the way that I use my 49G+, many of the keys have now been used more than 420,000 times in the past year. (rather good estimate) Overall, I am extremely pleased with the 49G+. John === Subject: Re: HP 49g+ Good except for keyboard? posting-account=nBkFWAwAAABGLr8lI-hSpBgNiMz5XoFp >The company is still releasing faulty software (ME Pro). > Me*Pro (and EE*Pro) are not TI applications. ME*Pro can be downloaded straight from TI's official website without any of the use at own risk disclaimers. If I was a calculator company, and I knew I was distributing a program that gave erroneous answers, I would either try to fix it, or stop distributing it. I might even warn people that the program has bugs. I wouldn't sit around and do nothing about it. Didn't TI used to charge people for that program? --CS === Subject: Re: HP 49g+ Good except for keyboard? following : >I'm new to this group. I have been getting ready to buy a new >calculator. One of my two HP-32S calculators died after working >flawlessly forever. > The hp 33s never misses any keys > If your Singapore-made 32 died, it was not flawless. Re: misses any keys.. 1.The hp 33 omits the big 4-way key functions. (expressions cannot be edited without deletion.) (prior expressions(history)cannot be accessed.) (Instead there is a unnamable unlabeled special expression stack) 2.The hp 33 omits common complex functions. 3.The hp 33 omits Matrix operations. 4.The hp 33 omits Variables and labels of more than 1 Character. There are a lot of details missing from the hp 33 operation. Be warned that this brand no longer engenders user confidence. Jack === Subject: Re: HP 49g+ Good except for keyboard? > following : >I'm new to this group. I have been getting ready to buy a new >calculator. One of my two HP-32S calculators died after working >flawlessly forever. >>The hp 33s never misses any keys but for me on very fast short time typing I weak sense is a SW-depend, not to physical button. >> > If your Singapore-made 32 died, it was not flawless. > Re: misses any keys.. > 1.The hp 33 omits the big 4-way key functions. > (expressions cannot be edited without deletion.) > (prior expressions(history)cannot be accessed.) > (Instead there is a unnamable unlabeled special expression stack) hmm - you thinking hp48 and up? > 2.The hp 33 omits common complex functions. hp32 not have it, only few complex function using special operation on pair of numbers on stack. hp42S have it, include hyperbolic and this inverse on complex numbers. very few (none?) small caculator can compare it and need going to hp48 and up, and Ti89 (not TI83 and TI85, is cannot handle ASIN etc. on complex numbers properly) to find same capability and more functions on complex numbers, but hp42s still fit in skirtpocket... > 3.The hp 33 omits Matrix operations. hp32 not have it, hp42S have it, also complex matrix handling and complex linear solver. - very usable to electrical problem > 4.The hp 33 omits Variables and labels of more than 1 Character. hp32 not have it, hp42S have upp to six character on variables, register and (complex)matrix, and 0-99 direct numbered register (also complex if you want) and above indexed. And upp to six character labled program name... --- I really miss numbered registers in hp48G/49G for fast and easy access and type always wrong and two times push on hp33s 0-9 button (eg. ZWXYTUVQRS-labled) register, > 10 year using of hp42S setting marks in mind... --- hp33 is a good and nearly equvivalent replacement for hp32sII, but not for Hp42s - hp33s only a 'poor' spare calculator in waiting time for new 'hp43s' - I hopefully... :-) hp33s is unfortunatly little bigger and thicker size than old hp32sii and I cannot understud why need to build bigger competent sci calculator??? I want smaller size!!! old hp32Sii and hp42S have IMHO near perfect skirtpocket size and not want bigger version of this - possible shrink to hp15C - hp16C format if _need_ to resize :-) /TE === Subject: Re: HP 49g+ Good except for keyboard? > following : >> X >>I'm new to this group. I have been getting ready to buy a new >>calculator. One of my two HP-32S calculators died after working >>flawlessly forever. >> X >> The hp 33s never misses any keys >> > If your Singapore-made 32 died, it was not flawless. > Re: misses any keys.. > 1.The hp 33 omits the big 4-way key functions. > (expressions cannot be edited without deletion.) > (prior expressions(history)cannot be accessed.) > (Instead there is a unnamable unlabeled special expression stack) > 2.The hp 33 omits common complex functions. > 3.The hp 33 omits Matrix operations. > 4.The hp 33 omits Variables and labels of more than 1 Character. > There are a lot of details missing from the hp 33 operation. > Be warned that this brand no longer engenders user confidence. Jack, Jack, Jack! You are now comparing the hp 33s to the HP-42S instead of the 33S or 33SII Shame on you! === Subject: Re: HP 49g+ Good except for keyboard? I also own a lot of HP calculators; the 48 up to current and also the 33. Same said for TI up through the 200. I have never had a problem mechanically with a TI. I have never had any problem upgrading the operating system on any of the TI's. Have had just the opposite on the HP's. I do like HP calcs and do like RPN and the way they program. CAS to me is a toss up on either. The thing I don't do on the TI is look at every entry to see if it made it. Maybe HP learned something out of all this. Don === Subject: Re: This unit has a great keyboard X-NNTP-Client: ROBOT/LX -=[ Sat, 11.12.04 08:53 a.m. +1300 (NZDT) ]=- Hi Erwann ABALEA ! in message ID : > Some users have tested up to 1 GB CF cards with success. DUP + . FWIW I use the 2GB Sandisk CF. The newer Sandisk CF are faster (I don't refer to the ulta-fast though) and power drain is still low. I was really surprised how well it worked - almost as if Sandisk made it specially to maximize the storage capability of the 200LX. -- === Subject: SSA formulas posting-account=d8X8zw0AAAB_Eo2ldj3HF5DzN42pN3GY I'm having trouble finding the equations for solving both cases of a SSA triangle. I've done some searching and haven't found the formulas used for these calcualtions. I know how to tell whether there is 1, 2 or no solutions, I just need to equations for solving them. I know there are several programs availible for this, but I don't want to look at them to avoid an possibility of accidentally copying someones code as it is for a program I'm writing. Anyone know where I can find these equations? I know they are quite simple, but I am challenged when it comes to trig. TW === Subject: Re: SSA formulas > I'm having trouble finding the equations for solving both cases of a > SSA triangle. I've done some searching and haven't found the > formulas used for these calcualtions. I know how to tell whether > there is 1, 2 or no solutions, I just need to equations for solving > them. If we know two adjacent sides and a non-included angle, then let's call the sides a, b, and let's call the angle A, that angle being opposite side a. (And B is the angle opposite b, C opposite c.) Now, the law of sines tells us that sine(A)/a = sine(B)/b. Therefore, we can find the sine of angle B by multiplying this equation by b. That is, sine(A) * (b / a) = sine(B). (1) In the case where B is non-obtuse (and if there are solutions, one of the solutions always involves an acute or right angle B), we can find B by computing the arcsine. That is, B1 = arcsine( (b / a) * sine(A) ), if B is acute or right. And if there is a solution with obtuse B, it can be shown that it will be the acute case's supplement, so we'll have B2 = pi - arcsine( (b / a) * sine(A) ). Naturally, the domain of the arcsine function is [-1, 1], and it is true that if b * sine(A) > a, then there is no solution for the triangle. If b * sine(A) = a, then we have a right triangle, if any. Rearranging, c = a * sine(C) / sine(A). Now, remember that A + B + C = pi, being the angles of a triangle. So, C = pi - B - A. Now, you'll remember that there were two solutions possible for B. So, for each of those solutions, there are two different values of C (corresponding to two different triangles), values of c1 and c2. Now, for each value of C (or c) which ends up positive, we have a valid triangle. If C is negative, then that solution is invalid. To summarize, we have a triangle with known sides a and b, with known angle A. The formulas are: B1 = arcsine( (b / a) * sine(A) ) B2 = pi - B1 If (b / a) * sine(A) is greater than 1 then no solution exists. C1 = pi - A - B1 C2 = pi - A - B2 Throw out values of C which are negative and use what's left below: c1 = (a / sine(A)) * sine(C1) c2 = (a / sine(A)) * sine(C2) Whatever solutions you get will be the solutions for the triangle. Note that C1 and C2 may be also be calculated by C1 = B2 - A C2 = B1 - A once B1 and B2 are calculated, which is slightly more efficient. === Subject: Re: SSA formulas posting-account=d8X8zw0AAAB_Eo2ldj3HF5DzN42pN3GY TW === Subject: Re: SSA formulas > I'm having trouble finding the equations for solving both cases of a > SSA triangle. I've done some searching and haven't found the formulas > used for these calcualtions. I know how to tell whether there is 1, 2 > or no solutions, I just need to equations for solving them. > I know there are several programs availible for this, but I don't want > to look at them to avoid an possibility of accidentally copying > someones code as it is for a program I'm writing. > Anyone know where I can find these equations? I know they are quite > simple, but I am challenged when it comes to trig. Try using the Law of Cosines [1] for the included angle case (a,B,C known) and or the Law of Sines [2] for side and opposite angle known (a and A known in addition to either B or C): [1] --> A^2 = B^2 + C^2 - 2*B*C*cos(a) [2] --> A/sin(a) = B/Sin(b) = C/sin(c) where and A,B,C are sides and 'a' is an angle opposite side A. It's hard to imagine you won't do something someone else has done. === Subject: Re: SSA formulas >> I'm having trouble finding the equations for solving both cases of a >> SSA triangle. I've done some searching and haven't found the formulas >> used for these calcualtions. I know how to tell whether there is 1, 2 >> or no solutions, I just need to equations for solving them. >> I know there are several programs availible for this, but I don't want >> to look at them to avoid an possibility of accidentally copying >> someones code as it is for a program I'm writing. >> Anyone know where I can find these equations? I know they are quite >> simple, but I am challenged when it comes to trig. > Try using the Law of Cosines [1] for the included angle case (a,B,C known) > and or the Law of Sines [2] for side and opposite angle known (a and A > known > in addition to either B or C): > [1] --> A^2 = B^2 + C^2 - 2*B*C*cos(a) > [2] --> A/sin(a) = B/Sin(b) = C/sin(c) > where and A,B,C are sides and 'a' is an angle opposite side A. > It's hard to imagine you won't do something someone else has done. www.hpcalc.org math misc maybe TrigLib 1.2 is what you want: http://www.hpcalc.org/details.php?id=5959 === Subject: Re: [49g+] More zint BUGs? >><< 0 'X' IFT >><< 1 'X' IFT >><< 0 'X' 'Y'IFTE >><< 1 'X' 'Y' IFTE >> all works for me... What are you flags settings? (not that i think it would make a difference) === Subject: Re: [49g+] More zint BUGs? >><< 0 'X' IFT >><< 1 'X' IFT >><< 0 'X' 'Y'IFTE >><< 1 'X' 'Y' IFTE > all works for me... > What are you flags settings? (not that i think it would make a difference) > If I compile << 0 :: DROP {ROT + SWAP} IFTE >> in exact mode, and run it or try to execute 0 :: DROP {ROT + SWAP} IFTE I get a bad argument type error. === Subject: Re: [49g+] More zint BUGs? X-NNTP-Client: ROBOT/LX Hi Virgil ! > in exact mode, and run > it or try to execute 0 :: DROP {ROT + SWAP} IFTE I get a bad argument > type error. Same here, I get IFTE Error: Bad Argument Type Typing in 0. works, but sure enough 0. R->I always fails. Of course the above is equivalent to just ROT+SWAP, not that that is relevant but I recognise the code from my disqualified 48S entry for the current MiniChallange. Quite a challenge :-) Ahha I see I need a 1 ->LIST before the ROT+SWAP otherwise I found that a {1} within the input list got shorn of it's {} if it made it into the output. That ROT+SWAP alone tells me your program must be similar to mine. Fascinating challenge! Only 45 hours to go. It's a shame HEAD and TAIL are 5.5 byte commands - yet another constraint. It's a bit like a game of chess. -- Hutchins === Subject: Re: [49g+] More zint BUGs? > Hi Virgil ! If I compile << 0 :: DROP {ROT + SWAP} IFTE >> in exact mode, and run >it or try to execute 0 :: DROP {ROT + SWAP} IFTE I get a bad argument >type error. > Same here, I get IFTE Error: Bad Argument Type > Typing in 0. works, but sure enough 0. R->I always fails. > Of course the above is equivalent to just ROT+SWAP, not that > that is relevant but I recognise the code from my > disqualified 48S entry for the current MiniChallange. Quite a > challenge :-) > Ahha I see I need a 1 ->LIST before the ROT+SWAP otherwise I > found that a {1} within the input list got shorn of it's {} if > it made it into the output. That ROT+SWAP alone tells me your > program must be similar to mine. Fascinating challenge! Only > 45 hours to go. It's a shame HEAD and TAIL are 5.5 byte > commands - yet another constraint. It's a bit like a game of > chess. Actually, I've been disqualified for having entered a previous challenge contest, so I'm just lurking as far as the contest goes. But I have been watching the various hints carefully, and have managed to take quite a few bytes off my own best program as a result of them. But for the IFTE bad argument type, my best program works fine if complied when in approximate mode and fed a real number as type number, but has occasional problems if compiled in exact mode. About a third of the bytes in my best program are dealing with the avoiding of various special case problems. === Subject: A few mini-challenge notes (was: [49g+] More zint BUGs?) >>Hi Virgil ! in message ID >If I compile << 0 :: DROP {ROT + SWAP} IFTE >> in exact mode, and run >it or try to execute 0 :: DROP {ROT + SWAP} IFTE I get a bad argument >type error. >>Same here, I get IFTE Error: Bad Argument Type >>Typing in 0. works, but sure enough 0. R->I always fails. And here too. At least there seems to be some consistency, but I really do wish that I understood exactly what the rules were for when IFT and IFTE need a real, and where they can also accept an exact integer, >>Of course the above is equivalent to just ROT+SWAP, not that >>that is relevant but I recognise the code from my >>disqualified 48S entry for the current MiniChallange. Quite a >>challenge :-) >>Ahha I see I need a 1 ->LIST before the ROT+SWAP otherwise I >>found that a {1} within the input list got shorn of it's {} if >>it made it into the output. That ROT+SWAP alone tells me your >>program must be similar to mine. Fascinating challenge! Only >>45 hours to go. It's a shame HEAD and TAIL are 5.5 byte >>commands - yet another constraint. It's a bit like a game of >>chess. > Actually, I've been disqualified for having entered a previous challenge > contest, so I'm just lurking as far as the contest goes. > But I have been watching the various hints carefully, and have managed > to take quite a few bytes off my own best program as a result of them. Keep working on it. ;-) > But for the IFTE bad argument type, my best program works fine if > complied when in approximate mode and fed a real number as type number, > but has occasional problems if compiled in exact mode. For the 49 series, I suggest including a decimal point (as in 0. or 1.) in all numbers in the program that have to be compiled as reals, and no decimal point (as in 0 or 1) on all numbers in the program that have to be compiled as exact integers (zints). Or if none of the numbers have to be zints, then compile it in approximate mode so that the all numbers are compiled as reals and none as zints. If that doesn't seem to work for you, specify which mode the program should be compiled in. The compiled program must work in either mode, but there's no requirement as to which mode it has to be compiled in. If I believe that a program was written on or for a 48 series, then on the 49 series, I compile it in approximate mode to avoid changing reals to zints, but if it was written on a 49 series, then I compile it in exact mode to avoid changing zints to reals. Of course, the 48 series never compiles anything to a zint; for them, numbers that would be zints on a 49 are compiled as reals instead. If someone specifies which mode a program has to be compiled in on the 49 series, then I'll go along with that. I also suggest uploading it to a PC with a Kermit ASCII translation mode 3 transfer or a Conn4x text transfer with all translations enabled. For the 49 series, if any numbers have to be zints, then have the calculator in exact mode while transferring. Just copy and paste the entire contents of the file (including the transfer header) to your post, and include the checksum, size in bytes, and which calculator model it's from. This makes it very easy to simply download it to my calculators without making any inadvertent changes, and gives me a way to verify that I have it compiled as intended. Of course you can just type the program into your post, but be careful of typos. If I don't get the same size and checksum, then I'll ask for clarification. so note that it doesn't have to work with a zint for the type number as the level 1 argument. Programs intended to take a type number have to work with a real as the level 1 argument. If it also works with a zint as the level 1 argument, then that's nice, but it's not a requirement. Of course, another kind of program is allowed in this mini-challenge. This kind takes as the level 1 argument an object that's an example of the type of element to be eliminated. Note that the kind of program that expects a real number can always be changed to the kind that takes an example simply by inserting a TYPE command at the very beginning of the program. Probably most programs that expect an example could be changed to the kind that expect a real simply by removing a TYPE command, but you can probably write a program where this can't be done. > About a third of the bytes in my best program are dealing with the > avoiding of various special case problems. any extra bytes that depend on whether the program is compiled in real or exact mode. -- === Subject: Re: A few mini-challenge notes (was: [49g+] More zint BUGs?) >Hi Virgil ! >in message ID >>If I compile << 0 :: DROP {ROT + SWAP} IFTE >> in exact mode, and run >it or try to execute 0 :: DROP {ROT + SWAP} IFTE I get a bad argument >type error. >Same here, I get IFTE Error: Bad Argument Type >>Typing in 0. works, but sure enough 0. R->I always fails. > And here too. At least there seems to be some consistency, but I > really do wish that I understood exactly what the rules were for > when IFT and IFTE need a real, and where they can also accept an > exact integer, >>Of course the above is equivalent to just ROT+SWAP, not that >>that is relevant but I recognise the code from my >>disqualified 48S entry for the current MiniChallange. Quite a >>challenge :-) >Ahha I see I need a 1 ->LIST before the ROT+SWAP otherwise I >>found that a {1} within the input list got shorn of it's {} if >>it made it into the output. That ROT+SWAP alone tells me your >>program must be similar to mine. Fascinating challenge! Only >>45 hours to go. It's a shame HEAD and TAIL are 5.5 byte >>commands - yet another constraint. It's a bit like a game of >>chess. >Actually, I've been disqualified for having entered a previous challenge >contest, so I'm just lurking as far as the contest goes. >But I have been watching the various hints carefully, and have managed >to take quite a few bytes off my own best program as a result of them. > Keep working on it. ;-) >But for the IFTE bad argument type, my best program works fine if >complied when in approximate mode and fed a real number as type number, >but has occasional problems if compiled in exact mode. > For the 49 series, I suggest including a decimal point (as in 0. > or 1.) in all numbers in the program that have to be compiled as > reals, and no decimal point (as in 0 or 1) on all numbers in the > program that have to be compiled as exact integers (zints). Or if > none of the numbers have to be zints, then compile it in > approximate mode so that the all numbers are compiled as reals and > none as zints. If that doesn't seem to work for you, specify which > mode the program should be compiled in. The compiled program must > work in either mode, but there's no requirement as to which mode > it has to be compiled in. If I believe that a program was written > on or for a 48 series, then on the 49 series, I compile it in > approximate mode to avoid changing reals to zints, but if it was > written on a 49 series, then I compile it in exact mode to avoid > changing zints to reals. Of course, the 48 series never compiles > anything to a zint; for them, numbers that would be zints on a 49 > are compiled as reals instead. If someone specifies which mode a > program has to be compiled in on the 49 series, then I'll go along > with that. > I also suggest uploading it to a PC with a Kermit ASCII > translation mode 3 transfer or a Conn4x text transfer with all > translations enabled. For the 49 series, if any numbers have to be > zints, then have the calculator in exact mode while transferring. > Just copy and paste the entire contents of the file (including the > transfer header) to your post, and include the checksum, size in > bytes, and which calculator model it's from. This makes it very > easy to simply download it to my calculators without making any > inadvertent changes, and gives me a way to verify that I have it > compiled as intended. Of course you can just type the program into > your post, but be careful of typos. If I don't get the same size > and checksum, then I'll ask for clarification. > so note that it doesn't have to work with a zint for the type > number as the level 1 argument. Programs intended to take a type > number have to work with a real as the level 1 argument. If it > also works with a zint as the level 1 argument, then that's nice, > but it's not a requirement. > Of course, another kind of program is allowed in this > mini-challenge. This kind takes as the level 1 argument an object > that's an example of the type of element to be eliminated. Note > that the kind of program that expects a real number can always be > changed to the kind that takes an example simply by inserting a > TYPE command at the very beginning of the program. Probably most > programs that expect an example could be changed to the kind that > expect a real simply by removing a TYPE command, but you can > probably write a program where this can't be done. >About a third of the bytes in my best program are dealing with the >avoiding of various special case problems. > any extra bytes that depend on whether the program is compiled in > real or exact mode. That is not the only special case one may have to deal with. Consider also, for example, dealing with empty lists, either as input or output. There are a lot of approaches, in fact most of the ones I have tried, that require special attention to dealing with an empty list either as input, or as output, or both. If one could ignore both of those empty list situations, one could deal with everything else much more briefly. In fact, I have an under 60 byte program that seems to do just that, but my best program which correctly deals with all empty list situations is significantly longer. === Subject: Re: A few mini-challenge notes > That is not the only special case one may have to deal with. Consider > also, for example, dealing with empty lists, either as input or output. > There are a lot of approaches, in fact most of the ones I have tried, > that require special attention to dealing with an empty list either as > input, or as output, or both. > If one could ignore both of those empty list situations, one could deal > with everything else much more briefly. In fact, I have an under 60 byte > program that seems to do just that, but my best program which correctly > deals with all empty list situations is significantly longer. Well, it is supposed to be a little challenging, isn't it? But seriously, my reasoning for the empty list requirements is that I envision this program as being something that another program could call, knowing that the level 2 argument is a list, but a list that may include any sequence of objects, including objects all of the type to be eliminated, none of the type to be eliminated, or no objects at all. To be sure, the empty list argument case could easily be checked by the calling program, but checking for all elements being of the type to be eliminated, or not containing any of the type to be eliminated, would be a little more trouble. Looking at it a little differently, the program is supposed to eliminate any objects of a particular type. What if the list doesn't contain any elements of the type to be eliminated? Should we have it error out for this special case? To me, it seems more reasonable to have it return a list identical to the original list. An empty list is just another case of a list that doesn't contain any elements of the type to be eliminated. Yes, I know that some built-in commands fail when an argument is an empty list. In some cases, this seems quite reasonable to me. But, for example, GSLIST requires at least two arguments because it starts out by adding the first two elements. It seems to me that the 1-argument list should've been treated as a special case for GSLIST, returning the original list, providing that it contained a real or zint. It would've been easy enough to start out by adding the first element to 0. But I don't see unfortunate limitations or bugs built-in to the calculator as a valid reason to have them in our own programs when they can be avoided. In any case, the requirements for empty lists as either input or output are the same for all entries, so I can't see anything unfair about them. -- === Subject: Re: [49g+] More zint BUGs? > Forgive me: I was referring to a new bug > Just read that help text and check the behavior > It has nothing to do with IFT(E) > It just has the wrong text Does it crash (loosing data, reboot etc..) or does it displays Bad Argument Type ? Zint should be auatically converted into reals though here... Jean-Yes === Subject: Re: HP48 Family Disassembly of ROM Code When I type voyager into the search at hpcalc.org, I get Voyager 1.07 in the results? >Hi Pete: > >> Look for Voyager on hpcalc.org, Derek Nickel's amazing re-write of my >> TA program from long ago... >> so see >> http://www.hpcalc.org/hp48/docs/programming/ >>Has anyone disassembled any parts of the HP48G series Rom. I am >>looking for commented code as a result of someone already >> >>Has anyone disassembled the ROM for the HP48G/X? I am particularily >interested in the bootup code and at least major outlining of the >calculator functions in the ROM code. Has anyone developed cus >ROMs for the HP48? > > > > > There is one called shellOS in hpcalc.org. but it doesn't use the > built in rom. it is a 32kb archive to put in port1. > It works great, but has not many applications. > > There is another called MKor metakernel that uses and expands the > built in rom. >> Pete M. Wilson >> Gamewood, Inc. >> wilsonpm@gamewood.net === Subject: Re: OT - China Quality posting-account=OWaGAw0AAABiuxuBDAUFZoN15p-5K8Fq My IBM Thinkpad T40p is made in China, and as ample people have already pointed out, not only are most of IBM's computers already made in China, so are just about everybody else's computers. China _can_ make quality items, if the company cares. Hopefully IBM will make damn sure they care. Once crappy doesn't always mean always crappy. That's the mistake the big 3 auakers made about Japanese autos'. Then one day, they woke up and realized the Japanese autos were better in everyway and they were losing massive sales to them...if they don't wake up soon, the Koreans will surpass them as well. === Subject: Re: MiniChallange: eliminate same TYPE in a list X-NNTP-Client: ROBOT/LX Hi M. Prange ! in message ID : > It occurs to me that NDUPN might better be named > NDUPDROPN? But there are certainly advantages to keeping > names short. Forgive me but when I read that I did giggle a little as it looks like NDUP followed by DROPN which could be expected to undo itself. The weirdest thing is that when I look at the NDUPN description again in the .PDF I almost understand it, as is. There are two arguments (Level 2 and Level 1) and I guess the assumption is these get taken from the stack. And what gets returned are the n duplicates and the n. It is as if the original from which the copies were made was worn out. -- === Subject: Re: MiniChallange: eliminate same TYPE in a list X > There are two arguments (Level 2 and Level 1) and I guess > the assumption is these get taken from the stack. And what > gets returned are the n duplicates and the n. Excatly -as all other commands with N should do, too. -- === Subject: Re: MiniChallange: eliminate same TYPE in a list X-NNTP-Client: ROBOT/LX Hi Veli-Pekka Nousiainen ! in message ID : >I haven't seen any code from you so cannot really present >it :-). I hope you present it though! >> BUT >> you can still shave off some nibbles >> look carefully at _all_ of your code I understood that hint :-) > Look outside of NDUPN and DOLIST I don't understand that hint I could shave nibbles but only at the expense of functionality. Mine have been sitting quietly unchanged, since NDUPN hit them, in an unsent usenet posting, ready to escape when Big Ben strikes midnight to end this week-end. > Maybe we should talk through e-mail > OR > only after 12.12. 12.12 approaches! I even changed my usenet template [date] header above to show Big Ben time, to remind me :-) Looking forward to seeing your work . -- Hutchins Wellington New Zealand #16 Beginnings and endings are truly artificial constructs. === Subject: Re: MiniChallange: eliminate same TYPE in a list Nope not at all. My last program that worked as required was the 99.5 byte program. These are just to see if i can go smaller. And to put them out ther if anyone wants them. This is from my own thought processes to see if i could get them working. If I add the req'd commands to check for a null list they go to about 105 bytes. And it looks like << -> b << DUP SIZE NOT :: KILL IFT { } 1 3 PICK SIZE NEXT >> SWAP DROP >> That works as req'd. But my other program beat it. No need to check this one On the subject of non checkable programs is 57.5 Bytes :: :: xOBJ> NULL{} SWAP COERCE #1+_ONE_DO SWAPDUP xTYPE LOOP ; ABND ; >Here's smaller >94 bytes ><< -> b > << { } 1 3 PICK SIZE > NEXT > >> SWAP DROP >Or 89 bytes ><< -> b > << { } 1 3 PICK SIZE > NEXT > >This one leaves the original list on the stack as well, thus the SWAP DROP >in the first one. >Should work just fine on the 48S series. As before it errors out on an empty >list as an input. > I hope that you're not expecting me to check programs that you > already know don't work. > -- > === Subject: Re: Whats wrong with HP? posting-account=Mar1jg0AAACF6QN5u0nozPQnCpvfsx_l Yes, very much. NC... === Subject: Re: Quolity vs. Affordable (read: CCC) > What do you think? > Are you ALL willing to pay for Quolity (& features)? > Would you rather buy > A) A hp 49g+ with it's variable quality keyboard 150 USD > B) HP-48GX at 250 USD > C) HP-41C-series calculator at 200 USD > Q) Qonos at 400 USD (at least 48 style keyboard) > X) Your choise > - currently using 49g+, Qonos in the future... > PS: The keyboard of my 48GX is broken > PPS: my 41CX is broken Actually, I can't see myself buying a new calculator anytime soon. The 49G was disappointing in some ways. The 49g+'s keyboard is easily the worst keyboard, short of membrane type keyboards, that it's ever been my misfortune to try to use. Maybe if they fix it, and there are no reports of missed keystrokes or broken keys for a year or so. 48GX? An excellent calculator, but I have enough 48 series that I suppose that they'll outlast me. If I really needed a new calculator, a 48GX or 48SX would be my choice. Future HP calculator models? Maybe, but I certainly wouldn't want to be an early adopter. 41C series? I would've loved to have had one when it was current, but now it has to be an RPL model. Qonos? The best things (for me) would be a keyboard that may actually work correctly, and better external I/O. But I haven't forgotten who broke software flow control, or made strings that contain NUL, , or incompatible for transfer from the 49 series to the 48 series. Much as I'd like to get my hands on it, I'll probably wait for a lot of good reports from reliable sources before I spend my money on it. But if it turns out to be as good as we hope that it will be, then I'd rather spend US$400 on it than buy another 49g+ with the quality that I've experienced so far. -- === Subject: Re: Quolity vs. Affordable (read: CCC) > The 49g+'s keyboard is easily the worst keyboard, short of > membrane type keyboards, that it's ever been my misfortune to try > to use. Maybe if they fix it, and there are no reports of missed > keystrokes or broken keys for a year or so. > 48GX? An excellent calculator, but I have enough 48 series that I > suppose that they'll outlast me. If I really needed a new > calculator, a 48GX or 48SX would be my choice. What is the difference (besides the keyboard) between the HP48GX & HP48GII? -- -------------------------------------------------------------------- Purveyors of Fine DSP Hardware and other Cool Stuff Available at http://www.danvillesignal.com === Subject: Re: Quolity vs. Affordable (read: CCC) I have no problems with your attempt (HP) to make a product, which suits as many people as possible. Great!! RPN as default would be better than ALGEBRAIC, but this doesn't matter, you still have RPN available. Does anybody really care about the colours? Too me they look fine. Just don't change them to fluorescent pink or similar. However the single most disappointment with both 49G+ and 48GII would definitely have to be the keyboard!!! We have been telling you this for over 12 Months now. Why does the general public think you don't care? Well the keyboard is it. Promises, promises, promises and yet I still see no resolution to this problem. Perhaps you need to introduce a professional level HP49G+. Keep the current budget level for the student market. And charge an additional $100 for the rugged/durable/reliable/weatherproof/etc HP49G+. === Subject: Re: Quolity vs. Affordable (read: CCC) > Cyrille, > I have no problems with your attempt (HP) to make a product, which > suits as many people as possible. Great!! > RPN as default would be better than ALGEBRAIC, but this doesn't > matter, you still have RPN available. > Does anybody really care about the colours? Too me they look fine. > Just don't change them to fluorescent pink or similar. I would prefer a fluorecent orange for a surveying calc > However the single most disappointment with both 49G+ and 48GII would > definitely have to be the keyboard!!! We have been telling you this > for over 12 Months now. Why does the general public think you don't > care? Well the keyboard is it. Promises, promises, promises and yet I > still see no resolution to this problem. > Perhaps you need to introduce a professional level HP49G+. Keep the > current budget level for the student market. And charge an additional > $100 for the rugged/durable/reliable/weatherproof/etc HP49G+. > Noel Causerano (Registered Surveyor) > GEOCALC SOFTWARE > Registered Reseller HP Invent > Cairns, QLD, Australia > Email: noel@geocalc.net > WEB: www.geocalc.net === Subject: Re: Quolity vs. Affordable (read: CCC) > Cyrille, > However the single most disappointment with both 49G+ and 48GII would > definitely have to be the keyboard!!! We have been telling you this > for over 12 Months now. Why does the general public think you don't > care? Well the keyboard is it. Promises, promises, promises and yet I > still see no resolution to this problem. I see no promises at all, what's more HP never admitted officially there was a keyboard problem. === Subject: Re: Quolity vs. Affordable (read: CCC) >Maybe a Mini-Mathematica could be ported using a 1GB SD card? Why SD? I would prefer CF-Cards, they're available with more capacity (up do 4GB - no, i don't mean MicroDrives) and, here in Germany, much cheaper than SD. 1GB CF Standard speed is EUR 89,- Volker -- Im uebrigen bin ich der Meinung, das TCPA verhindert werden muss. === Subject: Re: Quolity vs. Affordable (read: CCC) >> Q) Qonos at 400 USD (at least 48 style keyboard) >400USD is a very, very expensive calculator. Of course, it's not cheap, but it ist not very much more expensive than a TI Voyage 200. Volker -- Im uebrigen bin ich der Meinung, das TCPA verhindert werden muss. === Subject: Re: Quolity vs. Affordable (read: CCC) >What do you think? >Are you ALL willing to pay for Quolity (& features)? >Would you rather buy >A) A hp 49g+ with it's variable quality keyboard 150 USD no >B) HP-48GX at 250 USD no. but not because of its keybord, which is rather good, but because it is not really a modern calc. It was a modern calc when i buyed ist in 1995, but today it is'nt. >C) HP-41C-series calculator at 200 USD >Q) Qonos at 400 USD (at least 48 style keyboard) yes Volker -- Im uebrigen bin ich der Meinung, das TCPA verhindert werden muss. === Subject: Re: Quolity vs. Affordable (read: CCC) >PS: I hope for the 41C series kb qlty yessssssssssssssssss ;-) Volker -- Im uebrigen bin ich der Meinung, das TCPA verhindert werden muss. === Subject: Re: Quolity vs. Affordable (read: CCC) > What do you think? > Are you ALL willing to pay for Quolity (& features)? > Would you rather buy HP49G+ --- I'd consider purchasing it. HP48GX --- I did purchase it (actually a replacement unit.) It is plenty fast enough, and I have solved some serious problems with it. HP-41 --- No ... Quonos --- At this point, not likely. === Subject: Re: Quolity vs. Affordable (read: CCC) following : >> I disagree. Even a good keyboard wouldn't convince me. Painted >> keys, all these fancy colours, ugly shape not to mention the >> lack of decent IR and serial communications. The presence of >> algebraic is something I hate as well, but that's probably only >> me so I'm not including it in my critics. Last but not least, >> who are we talking to??? HP doesn't care and obviously >> never will. I'll never buy anything from HP again unless >> miracle happens. > Actually, HP does care, but we have to make a product that makes > as many people as possible happy, and sadly enough this usually > means that some peoples will not like it. it does work against the > unity and original simplicity of the original design. However, you > have to admit that everything is done in order to allow old timers > (like you or me) to use their calculator like we use to. > We can only do 1 product, so we have to make concessions. > for example, IR. It was not possible to have IrDa and IR limited > to 10cm at the same time. so IR was not included. > the fancy colors and ugly shape is actually extremly apreciated by > a whole lot of cuser (most certainly younger than we both are). > I have to admit that personally, I love the shape of the HP49G+, > and the colors of the HP48Gii. I made myself a HP49G+ with HP48Gii > colors :-) > Anyway, I could justify most of your critics, in ways that you > would accept or not, but would that change anything? > cyrille The users of engineering calculators will pay you Precision quality prices for presision quality tools. No meat = no sale. === Subject: Re: Quolity vs. Affordable (read: CCC) >I'm with you , >Just increase the quality. More reliable and more robust. >[NC] > I disagree. Even a good keyboard wouldn't convince me. Painted > keys, all these fancy colours, ugly shape not to mention the lack > of decent IR and serial communications. The presence of algebraic > is something I hate as well, but that's probably only me so I'm > not including it in my critics. Last but not least, who are we > talking to??? HP doesn't care and obviously never will. I'll never > buy anything from HP again unless miracle happens. Today, I have to go to a computer for calculations. I saw the 49+. It's not pretty. No meat = No sale here. I'd judge the hp products against precision small tools. Mass, Inertial characteristics, Ablative resistance is poor. Battery life is poor. Low-key but high power appearance is absent. Simple rapid efficent access to solutions? In which language; no. I'm told that it faults. Often. My goodness. I wonder who those hp people are selling to? It's not me, I have works to accomplish, and no time to burn. === Subject: Re: Quolity vs. Affordable (read: CCC) > That very much depends on where *one sees* the future for calculators - > and I don't mean CAS work which is rather trivial anyway within the > scope of any architecture these days ... (with all due respect) think > outside the traditional confines of a calculator and you'll know what I > am talking about. Well, even if I stretch my imagination, I don't see where any FPUs would actually help these days. Back 10 years ago when CPUs were very slow, a dedicated processor would make a different. Not anymore As of CAS being trivial resources wise.. yes sure... good try === Subject: How to test for empty stack? Say a program executes faithfully, and the output might be a list, or it might be an empty stack. I would just save and display the list if that were the result; but how can one test for the empty stack condition? ( It could result from a sequence of DROPS). === Subject: Re: How to test for empty stack? Nevermind ... I think I figured this one out by simply using 0 DEPTH as the test. >Say a program executes faithfully, and the output might be a list, or >it might be an empty stack. I would just save and display the list >if that were the result; but how can one test for the empty stack >condition? ( It could result from a sequence of DROPS). === Subject: Re: How to test for empty stack? > Nevermind ... I think I figured this one out by simply using 0 DEPTH > as the test. DEPTH alone should be enough :) >Say a program executes faithfully, and the output might be a list, or >it might be an empty stack. I would just save and display the list >if that were the result; but how can one test for the empty stack >condition? ( It could result from a sequence of DROPS). === Subject: Re: Upgrading HP49G+ rom problem? Could never get the SD Card upgrade working (tried all vaiants I could think of...) so I ended up upgrading over USB cable which was quite easy and worked well. (I'm quite happy now to get rid of the blinking screen in the 1.23 version) Rgds Johan > using a standard 8MB SD card. > I have copied the hp49g123.bin and update.scp to the root > of the card but I keep getting the message > NO CARD, OR ERROR CHECK CARD AND PRESS ANY KEY > when I try to do the update using the selftest/update menu. > The card is definitely there and it's readable. > Using the FILES menu I can read text files > on the card using the 49G+. It seems like just the upgrade > code for some reason doesn't like the card (or the ROM files) > The card is FAT (not FAT32) and I even tried formatting it > using the SELFTEST menu but to no help. > Any ideas? === Subject: Upgrading HP49G+ rom problem? ./upgrade does not work with the HP49G+. It is written for the HP49G. Even if the ROM-versions on the calcs are compatible the upgrade files are not. Otherwise I would have made it possible to upgrade a HP49G with an HP49G+ upgrade file ;-) I do not own a HP49G+ so I do not know about more compatibilities or incompatibilities. Do the other functions of upgrade work with the HP49G+? Bye Matthias -- mbunte@gmx.net === Subject: Connect my 48GX to PC Hi all, im looking for a HP48 <-> PC Connectivity-Program. I own the serial cable from the original connectivity-kit, but i don't find the disk anymore. The program should give at least the functionality, the original HP-program gave. Any ideas? My main system is running windows 2000, my notebook is running win xp home. Volker BTW: my notebook doesn't offer a serial connector, it only offers lpt, usb an firewire. any ideas hows to connect the 48 to the notebook? would an adaptor serial2usb do? -- Besides, i'm of the opinon, that TCPA has to be stopped === Subject: Re: Connect my 48GX to PC Volker Neurath meinte >Hi all, >im looking for a HP48 <-> PC Connectivity-Program. I own the serial >cable from the original connectivity-kit, but i don't find the disk >anymore. >The program should give at least the functionality, the original >HP-program gave. >Any ideas? >My main system is running windows 2000, my notebook is running win xp >home. You could either check one of those programms at http://www.hpcalc.org/hp48/pc/link/ or use the HP PC Connectivity Kit at HP web site. http://h10025.www1.hp.com/ewfrf/wc/softwareDownloadIndex?lc=en&lang=de&cc=de &product=60713&dlc=de&os=181&softwareitem=ca101en Gru§ G.9fnter === Subject: Re: Connect my 48GX to PC > Hi all, > im looking for a HP48 <-> PC Connectivity-Program. I own the serial > cable from the original connectivity-kit, but i don't find the disk > anymore. > The program should give at least the functionality, the original > HP-program gave. > Any ideas? > My main system is running windows 2000, my notebook is running win xp > home. > Volker > BTW: my notebook doesn't offer a serial connector, it only offers lpt, > usb an firewire. any ideas hows to connect the 48 to the notebook? > would an adaptor serial2usb do? > -- > Besides, i'm of the opinon, that TCPA has to be stopped Belkin makes USB to Serial converters. Mine was spotty in its sucess, but it did work. I got the software, for XP at least, at hp's site. I think I still have it, and could email it to you , it you so desire. Scott === Subject: 48GX NNTP-Proxy-Relay: library1-aux.airnews.net I read there are 3 fonts in the 48GX. Is there a built-in command to change the current font? === Subject: Re: 48GX > I read there are 3 fonts in the 48GX. Is there a built-in command to change > the current font? no