HP-22 HP-22 ==== Just a note that http://bugs.hpcalc.org/ is set up to handle bug reports on the HP49G+ and HP48GII platforms as well as the HP49G platform. I'm not sure when Eric added these, but they're there now. Let's make use of this. I hope that HP is monitoring bugzilla. Of course, use common sense when posting bugs. Using bugzilla to ask for a higher resolution display or an RS-232 port on the 49g+, for example, wouldn't make sense. Make sure that you're really using the calculator correctly before posting a problem as a bug; maybe ask on the newsgroup first. Pay attention to the platform, version, and so on when making bug reports. Before reporting a new bug, check whether it's already been posted, and if it has already been posted, add any relevant additional information to the original post rather than starting a new one. If it's not really a bug but you'd like to see a feature added, post it as an enhancement. I'm not sure whether bugzilla would be the place to report hardware problems such as keypresses being missed; I'd think not. But on the other hand, for all I know, maybe that's partly or even entirely a software problem. Nor am I sure about reporting problems with HP supplied software such as the USB driver or Conn4x. I'd think it would be. Of course problems with non-HP software should be directed to the developer, not posted a on bugzilla. ==== http://belsky.net ==== Is it possible to make a user function which accepts two inputs, which I can also use in EQW? I'd like to be able to do this: ...RP(r1,r2)... to compute paralell resistances. I can do it for two resistances on the stack easily enough, but would like to be able to use it in EQW. XYZ ==== r1*r2 RP(r1,r2)= ------- r1+r2 This worked for me in EQW. I used the SPC (space) key separating the local variables for the function RP(r1,r2). Then use left shift 2 (DEF) key to create the function. Entering any combination of two resistor values then produces the parallel equivalent value of the network. Hope its what you were trying to accomplish. >Is it possible to make a user function which accepts two inputs, which >I can also use in EQW? I'd like to be able to do this: ...RP(r1,r2)... >to compute paralell resistances. I can do it for two resistances on >the stack easily enough, but would like to be able to use it in EQW. ==== > > I am talking about UserRpl and SystemRpl. I have all the usual books > and downloads for both languages but still need more. More indepth > expainations and examples. Take a case in point. Informs. Everything I > have read about it thus far cannot tell me how to program a checkbox > as a field in an inform. Yes there are programs to do them, but how > did the programmer program it in. What were the commands? see my > point. > > I am usually a helper in that I write lots of useful programs but I > need the tools. All I really have now is the HP49G+, I now need the > indepth manuals. > > HP where are they? -- James ==== Seriously though, I would love to find some real information on this calculator, and all my efforts to do so have failed. Reverse engineering it seems like the best way to me right now, but I don't have the spare change kicking around to get anything more than the ROM from HP's website. If someone could help me find some key pieces of information like the ROM entry point and which parts are Saturn assembly and which are ARM assembly, I'm sure that we could find out plenty with IDA and a saturn disassembler. ==== I agree with you completely, but for a different reason. Like you, I am right-handed and normally hold the calculator in my left hand. However, I generally use my left thumb to press the keys and use my right hand for jotting things down on paper, typing on a PC keyboard, etc. at the same time. The 41 is very easy to use this way, but the 48 is more difficult because it's a little bit wider and the keys are smaller. I have to shift the calculator a little in my hand to get my thumb to reach all the way across to the +, -, x and Ö keys. If those keys had remained on the left and the ALPHA, SHIFT and ON keys had been placed on the right then it would be much easier to use. The arrangement of the arithmetic keys and the choice of colors (for the G series) are my only complaints about the 48 keyboard. (At least ENTER is the right size and in the right place!) -- W If you're right-handed, why are you holding the calculator in your weak hand? Also it strikes me as a bit odd that you'd need to see the arithmetic buttons for speed. Maybe I've been using the calculator for too long, but the fingers (thumb really as I hold my 48G in my right hand, using my thumb to push the various buttons) knows where they are like in typing or playing piano, though without looking I can tell you its plus, minus, times, divide from bottom to top. ==== Because, as I said, I'm usually using my right hand for other things, like writing with a pencil or typing on a PC keyboard, or using a mouse, or holding a Coke, etc. When I'm *not* doing something else at the same time I usually have the calculator on a tilted stand on my desk so that I can use *both* hands to manipulate the keys. In that situation the layout doesn't matter as much, since I'm familiar with it and all the keys are easy to reach. For me the issue isn't speed or being able to see the keys, it's that my thumb isn't long enough to reach easily across the width of the entire keyboard. I can reach the first four columns easily but have to juggle the calculator a bit in my hand to reach the fifth column, which is a bit awkward and makes me worry that sooner or later I'm going to drop it while doing this. I'd prefer to have all the numeric and arithmetic keys in the first four columns for that reason. -- It depends on which usenet server you're using, but there's the Google archive. Visit http://groups.google.com/groups?q=comp.sys.hp48 to read this newsgroup all the way back to 1991 (see http://groups.google.com/groups?group=comp.sys.hp48&selm=1900%40seq.uncwil.e du). Well, I suppose some posts may have been lost in the transition from archive is a great research tool. But although it's great for researching old posts, the most recent message in the archive may be several hours old, so it's not the best server for active participation. What we write is available over the whole world and preserved for posterity, so restraint when posting is wise. -- James ==== : : 4. A small bit of golden paint has gone from the top. It is something : very small but unfortunately I SEE the damn thing everytime I look at : the screen. True, this time a new software improvement will not solve : this strange disease (paint peeling) unless the improvement is SO : incredibly GOOD that I forget about the rest. I've now had two -49g+s--first one died--and the paint is still sticking to both. But the main reason for paint peeling, I believe, is lousy preparation and lousy pre-cleaning of the surface before applying the paint. It's none of my business, but if I were you I would send the defective thing back--preferably to HP directly, although they won't take it until it's 31 days old--so that HP can see for themselves that they've got a major process problem. . ====4 HP 49G+ is selling for about US $ 130 and the HP 48GII for about US$ 90. ==== > The thing to check is there fully charged, leave them stand for 10 > minutes, not in anything, rest voltage. Batteries normally only need sit if they aren't near room temperature. Refrigerated batteries may store longer than room temperature batteries, but will begin operating like a dead battery and not get up to normal performance until they have warmed up. Running batteries in a heated state may make them seem to perform better for some applications, but is damaging to the batteries; a NiCD quickly goes from 500 charge cycles in a life to below 100 to provide an example. Another characteristic that effects voltage on NiCD (and probably others) is called topping off; 'rapidly' charging a battery that is already full, which adds an extra jolt in the initial use for high drain devices. Doing so results in a slightly higher voltage than a standard charged NiCD for the start of its use and reduced future charge cycles due to damage to the overcharged cells. Trickle (slow rate) charging is not as damaging to batteries, and even does not damage some batteries that are already full. Dead batteries will also appear to regain a little bit of energy if left sitting around (Try removing an unfunctional battery from a voltage sensitive device and restore it a few minutes later to see that you get, perhaose, a few seconds more use out of it). The battery will quickly drop to its previous state when used because it doesn't store much. > Different types of batteries have different voltages in view of the > different chemistry they use. For example nicad batteries when fully > charged tend to be about 0.1 v less than non rechargable batteries. If > a device needs 10 batteries, that adds up to say 14 V not 15 V. NiCD has 1.2v during normal charged operation, and that holds except at the end of the charge (where it drops lower) and the beginning of a charge (where it raises a little bit during charging). Alkaline have a normal charged voltage of 1.5v, with the voltage slowly falling down throughout its use (making battery level approximation easy). > Most devices are fairly forgiving, after all batteries loose their > voltage as they get used by about 0.1 to 0.2 V with AA batteries. The > HP calcs use only 3, so I imagine there will be no problems voltage > wise. NiCD are often considered 'drained' when they drop vrom 1.2v to 1.0v. I can't remember any standard 'drained' voltage for alkalines, but I usually just run them until they are unacceptable in performance anyways. Ed Sutton ==== >> It was a charger for AA/AAA rechargeable lithium-ion batteries. I >> wonder, has anyone tried these batteries before in the HP49/HP49+ or >> perhaps other models? >> I found these at RadioShack, link: >> http://www.radioshack.ca/estore Product.aspx?language=en-CA&product=2318298&category=Lithium-lo +Rechargeable&catalog=RadioShack > Your link was actually for rechargeable NiMH batteries which are > designed for a fast 15min charge ability. My previous experience with I was actually seeking information on Lithium-Ion batteries instead of NiMH or NiCd. I actually saw charger and batteries in the Lithium-lon Rechargeable section of RadioShack, the only item in the group. I thus assumed that these were indeed lithium batteries, but I guess not. I was specifically asking about lithium batteries because I've never had experience with them. > If you were considering rayovac, check out rayovac battery products > at http://www.rayovac.com for rechargeable alkaline batteries if you > want my suggestion of rechargeable batteries. TI used to sell calcs > with them, but I guess those days are over. I personally try to run > duracell ultra batteries in my ti86/89 because the calcs fade during > operations with most all other batteries quite noticeably since they > were overclocked. The rayovac generally worked like normal alkaline to > me as long as I would charge them 'before' they reach the point where > they are 'dead', after which a charge does not help out right; now I > find them hard to locate in stores near me though. I've used rechargeable alkaline batteries before, and they were fairly cheap and charged rather quickly. The only complaint I had with them is that you had to recharge them before their charge was depleated. The brand I used, Pure Energy claimed really long shelf-life as well, but typically half the batteries would begin to leak after a year. I generally like to use batteries until their last piece of charge, without worrying about them permanently loosing some of their capacity, as in alkaline cells. > alkalines could hold a charge. NiCD need to be charged once purchased > because they generally are discharged if they were charged prior to > packaging. I don't know how NiMH should act, but it seems like they > discharge on their own somewhere close to NiCD. Yes, NiMH batteries loose charge if not used up, but they're generally more reliable than NiCds, their memory effect is not as problematic as NiCd batteries, and the current provided is a bit higher. They can also be recharged many times, around 1000 times they claim. I generally use NiMH batteries in cases that require rechargeable batteries, but sometimes they're too expensive. Here it's around $10 CND for two AA NiMH batteries if I recall correctly. > Different batteries have their own care, life, application, etc. Did > this help, or would you like more information? It's 01:01 A.M.; time > for someone else to step in and correct my mistakes in the future... batteries in AA/AAA sizes, do they exist? RadioShack makes it seem like they exist, and it is possible to make them. Albert ==== AFAIK Li-Ion batteries are not available in standard sizes. The reason is that their charging requirements are quite different from NiCd and NiMH cells. Connecting Li-Ion cells to the wrong type of charger is dangerous and potentially explosive. Because of this the manufacturers are not permitted to sell them as replacements for standard cells. Yes, I realize the danger involved with Lithium-Ion cells, that's why I was surprised to see them in normal sizes. I thought they might have inplemented an automatic checking routine of some sort. ==== > > L4: 0 > > L3: +infinity symbol (left-shift 0) > > L2: 'EXP(-X)*(1-EXP(-X)' > > L1: 'X' > > > > then push right-shift TAN and 1/2 will be displayed almost > instantaneously. > > Try UNDOing the result (press right-shift HIST). The four stack > levels should come back. > > Then try integrating again (press right-shift TAN). The .5 result > appears about 30 seconds later. hmmmm. Thoughts? > > (Still better than the 49G.. consistantly takes around one minute). Calc was in exact the first time, and approx the second time. possibly a difference in wether symbolic vs. numeric integration is performed? ==== Does anyone know the bast program to use to make and view txt files on the HP480GX? I'm using MK and have a 1Mg card. It seem that I have to compile or convert the txt file into a VIT file? then load it into home or a list and execute a probram...but nothing seems to be working. ==== > Gosh, talk about bursting someone's balloon. Be assured that I didn't do this to show off or to put Toby down. It just looked a little like a MC ;-) No, seriosly - I have coded a lot of crappy programs when I started learning to program the HP48SX and GX (not saying that Tobys program is crappy, it's merely somewhat inefficient). There's no doubt that Toby learnt a lot when writing his program, and I hope he also learned a bit seeing my solution. I know I've learned quite a few things following the brilliant guys on this ng. It may be a silly little program, but the good part is doing the programming. The habit of writing compact code that performs very well (that was necessary on the HP48 to make anything work satisfactory) has helped me tremendously in my professinal life. I currently code for several types of embedded processor cores (as well as high level programming), and I often hear sighs from my colleagues when I provide them with a solution in 2 minutes that they have fought for days over. I just hope my little program helped shed a little more light on the RPL gem. ==== It did, seriously. The fact that tghe command ORDER can handle repeated entries so graciously was the oversight. Most of the job was to ensure a clean list, without repetitions. I'm allright, man... > Be assured that I didn't do this to show off or to put Toby down. It > just looked a little like a MC ;-) No, seriosly - I have coded a lot > of crappy programs when I started learning to program the HP48SX and > GX (not saying that Tobys program is crappy, it's merely somewhat > inefficient). There's no doubt that Toby learnt a lot when writing his > program, and I hope he also learned a bit seeing my solution. I know > I've learned quite a few things following the brilliant guys on this > ng. > > It may be a silly little program, but the good part is doing the > programming. > > The habit of writing compact code that performs very well (that was > necessary on the HP48 to make anything work satisfactory) has helped > me tremendously in my professinal life. I currently code for several > types of embedded processor cores (as well as high level programming), > and I often hear sighs from my colleagues when I provide them with a > solution in 2 minutes that they have fought for days over. > > I just hope my little program helped shed a little more light on the > RPL gem. > ==== WOW ! Friend brought a 256MB SD card (used and filled in Ipaq) and I tried it in HP49G+ . Well, it kinda worked -> - I was able to browse all files in the root dir - I was _NOT_ able to enter any subdir - I was able to copy from/to root dir any file Filer[1-5] behaved the same. HP Ipaq recognized any file I copied onto SD card. -- Mario Mikocevic (Mozgy) mozgy at hinet dot hr It's never too late to have a good childhood! The older you are, the better the toys! My favourite FUBAR ... ==== > > >> Today I requested and received a RMA for the return of a hp49g+ >>calculator. >> >>I ordered the hp49g+ calculator online DIRECT from HP's SMB web site on >>10/21/03. >>I received it via UPS on 10/27/03. >>It was shipped from Indianapolis, IN. >> >>It was received with the the DEFECTIVE operating system installed. >>Upon testing its operation, I found that some keys failed to function.. > > > >>I concluded hp CHOSE-TO-DELIVER -A-KNOWN-DEFECTIVE PRODUCT to me. > > > Don't expect any coments here. Your post is politically incorrect. > Everybody knows that HP calculators are The Best Calculators In The > World. Oh... They don't work?... Really?.... So what?... > > I returned mine too. Back to TI 89. If you haven't noticed plenty of strongly negative comments about the 49G and 49g+, then I guess that you don't read many posts in this newsgroup. Some of us are willing to give HP yet another chance and hope that they get things right. Carl and you choose not to, and I don't find fault with either of you for that. What is there to comment on? -- James ==== I always wondered why so many TI users post here. Are you just looking for complains so you can add your amen? I don't want to start anything here, but it seems to me that half the conflicts are resolved with HP sucks yah I love my TI. I believe there is a group for TI posters as well, and if not I suggest you create one. ==== Because I have some nice HP calculators from the time when they were manufactured by HP, and I like them (unfortunately, my HP16 was stolen last week from my office). I am using TI because the golden age of HP calculators is past, and the whole story with the newest one seems for me like an attempt to reanimate dead body. However, if they fix problems with their newest model, I will buy one. For a while I don't love them enough to pretend that there are no problems. ==== Actually, as a long-time HP calculator fan, and now one who has been forced into the TI side of things, I would say that there may be many here who keep hoping for a new HP that will be the TI-killer. I certainly do. I have a 41CV, a 48SX, a 49G, and now, a 49G+. As much as Carly appears to have ruined the company, and while my recent experience with HP printers has been unsatisfactory, I cannot help but hope for more in an HP calculator. I also have a TI-86 and a TI-89. I've read online that the HP-49 graphs more rapidly than the TI-89. Not even close. The 89 will graph in a couplle of seconds a function that my HP-49 ponders over for >20 seconds. My 49G+ is closer to the speed of the 89, but I've only had it for a day, and haven't had time to throw myself into the learning of all its features. I don't *like* algebraic entry, and the HP-49 irritated me because some functionality appeared to be available in algebraic mode that was not available in RPN. So far, the 49G+ seems to put algebraic and RPN on an equal footing. I'd love to toss my TI calcs, and find happiness in an HP, as I have since the HP-21 came out (I couldn't afford the original 35!) But I'm not willing to toss a Lexus in exchange for a Geo. I love what HP used to produce, but in my view, they have to win me over again. I hope the 49G+ will do that, but I shan't hold my breath. ==== Well, speaking as a HP style calculator fan, while I do feel uncomfortable reading the pro-TI posts, feel also that having comments like these shed more light on the entire calculator situation. IF indeed HP has fallen on their faces, and TI makes a superior product, it should be made known, especially to HP. That having been said, I think that the, well, at least my, 49G+ works well, for what it is, a very programmable graphing RPL/algebraic/with CAS calculator and since I havent' experienced any of the much discussed failures other than the occasional flicker (oh my, the machine is hereby trash :p ), I'd even say it's basically well made. As for well-designed... well, I am more at ease with a machine that is not graphing, scientific, RPN, keystroke programmable, so for what it was ostensibly intended for, I'd GUESS it's designed fairly well. But, I haven't gotten close to even basic competency in programming a 48 or 49 style calculator. I still find myself thinking and reacting in a RPN keystroke kind of a way. ==== >> You can solve the problem yourself by turning off the on-screen clock. >> That'll also make your batteries last a lot longer. >The only reliable way I have seen to solve the problem is to turn the >calculator off. What a great machine: There's a solution for >everything! ... Judging from most of your posts you really seems to hate the HP49G+. But why? If you dont«t like it, don«t use it. But it is really neccesary to make such noise about it, telling everyone how much better the TI calcs are (especially in a HP calc newsgroup) and that in an IMHO rude manner? ==== Also seems as though you should be able to use one of the commercially avaiable PDA keyboards with the new 48 & 49s since they now support IRDA. They are relatively inexpensive and work quite well. Would need to write a small driver routine. Bob ==== please!!! can you publish some more information about this keayboard? I am really interested on it. ==== >> << -> X 'FLOOR(pi/ASIN(X))' >> >> I get 1 as the result. >> It should be 2. > When you do FLOOR(expression) the expression > is *numerically* evaluated first. Ouch, thats an onion in the ointment. How do I know which functions behave this way? -- Jostein Trondal ==== Your program on the 49 g gives 2. I do not know why put thier must be a reason. Gary > >> << -> X 'FLOOR(pi/ASIN(X))' >> > >> I get 1 as the result. > >> It should be 2. > > > When you do FLOOR(expression) the expression > > is *numerically* evaluated first. > > Ouch, thats an onion in the ointment. > How do I know which functions behave this way? ==== Still nice to know, that one can get calculators, that do not work out of the box. The one I got today did not work - pressing on on did not work. I had to press reset once and the system was there .... ==== Probably with version 1.20 so your batteries are worn down before start. Get a set of new batteries and upgrade it to version 1.22 would be my advice. . Were the batteries installed in yours when you received it? They weren't in mine, they were next to the calc on the blister pack ==== Shouldn't HP provide these new batteries? They are selling the calculator with batteries, and therefore the batteries should work! ==== How was you calculator packaged? Blister pack or box. Mine came in a blister pack and the batteries were not installed in the calculator. ==== Excellent little game. Hp needs to refuse to replace the up arrow button if this game has been installed. I gave mine a good workout. My top score after 10 minutes was only 105. ==== >But just how standard is USB? It looks to me as if each client device >needs its own driver on each host that it connects to. That's not my >idea of standard. I don't think that is a fair criticism of USB. If I plug in any RS-232 device to a host, how well will it work without software? It is true that many USB devices have special drivers, but that is because of the nature of the device, or sometimes the poor implementation of their USB service. New digital cameras that use direct USB connection are an example of USB done right - they act just like a USB hard drive, and that makes sense considering the typical use of the connection. If the only purpose of the 49g+ interface was to send and receive files, there is no reason hp couldn't have implemented it as a USB disk drive and not required any driver. ==== This would be a good idea, if it was (easely) feaseable... Let me explain USB drive use a sector type of interface. ie: the pc asked for sector n of the hard drive and the sector is transfered to it, exactly as on an IDE drive. The PC then handles the files as a file system now, for a digital camera, no problem, they have a SD card, or similar in them and they send the sector requested by the PC from the SD card. on a hp calcualtor, there is a file system, yes, but it is COMPLETLY different from the PC file system. what would the calcualtor do when the pc request sector 0 (partition table)? well, it could, on the fly create a fony sector and send it to the pc... what does the calcualtor do when the pc require the FAT? well, same thing... up to here, all is good.... now, what happen when the PC read files? no problem again (I mean appart from the implementation that is starting to get tricky), it can generate something that looks like a hard drive from the internal file system... now, the PC starts to send writing orders on sectors for the calculator... what does the calculator do with them? well, this starts to get dificult, because these sectors are not linked with any file, and the calc does not know about sectors, only of files... well, let us save them (how many will we save? who knows).... anyway, at one point in time, the PC sends modifications to the FAT and the root directory, the calc can now go back on all the data received, make sense of it and transform everything back in calc files! ouf... (this include for example a file open for read/write and modified in the middle, files moved from A to B, directory changed (remember, on the calc, a directory is also a file... how does the PC deal with that)....) mind you, in this scenaro, how does the calc manage memory? oups... because as it need memory to work, but also needs memory that is the free memory on the hard drive... but as a hard drive can not resize itself, this will not work... again, what happends when the PC starts a defrag? that can not possibly make sense for the calcualtor... what I mean is that the idea is excelent, but unfortunately, not implementable due to the legacy of the HP48G file system... ==== It sounds like you are talking about things like baud rate, stop bits, parity, control flow, etc. Getting the settings right is only half of the battle, though. When I read James' post, I was thinking more along the lines of compatability at the electrical level. Lots of devices cut some corners in their RS-232 drivers/receivers. Usually it is done to save a little cost, sometimes because the designer didn't really understand RS-232 well enough. Either way, the devices typically work with *most* other devices, but then you'll run into a combination where both sides took shortcuts that conflict with one another. I believe a previous HP calculator (49G?) had problems like this with older Macintoshes. I saw one very odd case where two devices couldn't communicate, but then if the cable was made 3' longer everything worked fine. None of this is a problem with the RS-232 specification itself, but rather with the large collections of devices which are assumed to be RS-232, but don't really meet the full spec. Dave ==== Those and signaling on other lines besides transmit and receive data. not be required on either. Of course the various connectors can also be a problem; which pin is which signal? It helps if you have a manual for the device. > Getting the settings right is only half of > the battle, though. > > When I read James' post, I was thinking more along the lines of > compatability at the electrical level. Lots of devices cut some corners > in their RS-232 drivers/receivers. Usually it is done to save a > little cost, sometimes because the designer didn't really understand > RS-232 well enough. Either way, the devices typically work with *most* > other devices, but then you'll run into a combination where both sides > took shortcuts that conflict with one another. I believe a previous HP > calculator (49G?) had problems like this with older Macintoshes. I'm aware that it can be a problem, but I've personally only had it happen to me when trying to use a fairly long cable with a defective device putting out a very weak (well below RS-232 specifications) signal. Well, I have run across some that didn't go negative for the mark signal, just to 0V, but I was aware that they weren't really RS-232 (the manuals made that clear) before actually trying to make the connections, and I knew that level shifters would be needed. According to the HP 48 I/O Technical Interfacing Guide, the 48 series' transmit signal is +/-3.0V minimum, 3.5V typical. And for the received signal the operating ranges are -15.0V to .03V for a mark, and 1.0V to 15.0V for a space. The absolute maximum allowable voltage for both is +/-25V. I believe that the 49G (except for some early defective units) is the same. Quite possibly those early 49Gs with the serial port hardware bug having trouble with some Macintoshes and perhaps some other devices are what you heard about. cable might be the same, but I wouldn't want to count on it being able to take +/-25V, or even +/-15V, without anything getting fried; any volunteers? The special cable, I'd guess, is there to boost the signal into the recommended range, but could also limit the received voltage. I don't have copies of the RS-232 standards (they aren't free) but as far as I can tell, the RS-232 standards specify, for transmitting, -15.0V to -5.0V for a mark and +5.0V to +15.0V for a space. But for receiving, -15.0V to -3.0V for a mark, and +3.0V to +15.0V for a space. And everything should be able to withstand at least +/- 25V. So those calculators don't meet the recommended standard for transmitted signal levels, but with any luck (the other device meets or exceeds the standard for received signals and not much signal loss) it ought to work, and usually it does. My Sharp EL-5520 manual says that the output is 4-6V, and warns that it uses CMOS components, and voltages exceeding the allowable range may manual for the Sharp CE-137T level converter, it seems that what it expects from the handheld is 0 to +0.5V for a mark and +3.3V to +5.5V for a space, so I guess that straight from the EL-5520 it's even worse than the HP calculators; the signal doesn't swing negative for a mark. For the output from the level converter, it claims -10 to -3V for a mark and +3 to +5.5V for a space; still not necessarily up to the standard, but it works for me. I really don't know which (if any) standard the Macintoshes claim to support, or whether they meet it. > I saw one very odd case where two devices couldn't communicate, but then > if the cable was made 3' longer everything worked fine. That is strange. My guess is that it wasn't entirely the peak voltage levels, but perhaps more the pulse shape. Maybe the extra length changed the cable capacitance just enough to allow it to work. Or if it was a different cable entirely instead of a matter of adding an extension, maybe the longer cable actually had less signal loss or distortion. > None of this is a problem with the RS-232 specification itself, but > rather with the large collections of devices which are assumed to be > RS-232, but don't really meet the full spec. I agree. If the device has a serial port, then they should say which (if any) standard it meets. Best if the device actually meets some standard, but if it doesn't, then they should say so very clearly up front. At least the 48SX engineers were well aware of the problem, and did find a way to make it close enough to work with most RS-232 devices. But I don't think that the full story ever made it into the Owner's Manual; I think that it never actually mentions RS-232, but uses the term serial instead. So they didn't actually lie about it, they just let the buyers assume that serial means RS-232. As far as I can tell, the special cable for the 48gII is intended to be a way to get the transmitted data signal into the recommended range. Certainly that's a worthy goal, but in my opinion a misguided method of meeting it, even if some PDAs do it that way. Surely electronic devices have advanced a bit since the 48SX was designed; it would've been better to put it all into the calculator and draw any power needed from its own batteries, rather than relying on being able to get power from the other device. I guess that it's too late now; the 48gII is already in consumers' hands. Maybe on the next calculator.... -- > Anyway I'm afraid we will never see this changes made to the 49g+. Yes, it's quite unlikely, unless they hire a CAS developer. Actually, someone has addressed this with http://www.hpcalc.org/details.php?id=5493. It's not completely transparent as it requires some setup, but once setup it does appear to be transparent. BTW, I've not tried it as I don't care about the flag changes, though the variable twiddling might be helpful. ==== I can't exactly say whether you should buy it or not. I sit next to a guy in vector calc who has a 49g and I have a 49g+. We tried out each others' keyboards and definitely agree that the 49g+ keyboard is way better. I'm not sure about the display though. It is definitely faster. > > I have my hp49g for about 4 years and i am quite pleased with it. > But I really hate the keyboard and the display. and a faster calc will > always be great. > > What do you say - those of you who own the new model - sholud I buy it > or not ? > Will I be pleased with the new keyboard ? > Or should I wait a while - But I don't think HP will come out with a > new model than the hp49g+ in the 4 next years. ==== ==== I tried to update to 1.22 on my new 49G+, but no luck. The instructions in the dialog box do not appear to work, and neither do those in the read me file that came with the ROM update from the HP site (though they are different in sequence.) If anyone here can tell me how they did it, I'll be much happier than now. BTW, the USB connection to the connectivity kit, while attempting to follow the ROM update instructions, has several times sucked up all of my P4 under Win2K :( Oh, and the example of using DIV2 on page 5-12 doesn't work. I was hoping to see much improvement compared to the old HP49, but so far, am disappointed. -- Bill ==== On my hp49g+ I have rom v1.22 uploaded via conn4X under WinXP Pro. I did try the example on page 5-12 of the User's Manual. In RPN mode, entering each tick enclosed expression followed by DIV2 produced a result of X^7 + X^5 + X^3 +X X - 1 There were no labels, per se; but it seems reasonable that the stack level 2 contained the quotient, and stack level 1 contained the remainder. Don't give up on your calc ...(yet :^). I think experience and patience will reveal it to be a pretty marvelous tool. Sure beats the hell out of an abacus ... at least for me. Keep trying various things with your conn4X, also. I had trouble at first, but if you see your hp49g+ driver show up under device manager with the calc plugged IN and ON; then make sure you're using the RED right-shift key and the CHROME right-arrow to invoke the XMODEM SERVER it might just begin to make sense. The directions are a little intimidating; but they did work for me. Especially the calculator reset manuever afterwards. They say to hold the (+) and (-) keys down together and after you use the paper clip gadget trick , wait a little bit before releasing those keys. (I didn't do the WAIT thing, but it still worked, anyway!) Some win98SE user's haven't had any luck with conn4X and went the SD route, instead. I was ready to do that, too; until I discovered that I was using the wrong key for my right arrow. I used the little red right arrow above the 0 key ... WRONGO! heh heh! Pretty stupid on my part, but funny it is ... looking back on it! I bought a 256MB SD module from Costco, along with the SD Imagemate 8 in 1 interface adapter. It all works per the manuals (both SD and HP). Some people have had problems with that, too, but it seems to do all that HP claimed it would do. Good luck. and the example of using DIV2 on page 5-12 doesn't work. ==== from the old 49G, adding several functions to it. The problem is, it is now 113 functions, and that is really way to much for just one long soft menu (19 pages). Is there a way to have a nested $VISIBLE menu for a library, like how many of the built-in menus have? For example, if you press the [SYMB] button, then there are ALG, ARITH, CALC, etc. sub-menus shown, instead of all of the functions. This is basically what I would like to do with the menu for my library of functions. I am using the CRLIB from 256 MENU to create the library. ==== >>I don't agree, because if the calc would switch silently >>in rad mode to make the integral and then back to previous angle >>mode, you could get what appears to be a wrong answer >> Not if the switch is done correctly. >Then please explain how the mode switch should be done. ==== Why should I do it with a rational numbers? Why not as pi * a rational number? This is the same kind of question as if I ask you for the length of an arc of a circle of radius 1 given its measure in degree or radians. ==== When an angle is specified, how often is the reason so that someone can determine the length of the arc of a circle given the angle and the circle's radius, or the radius of a circle given the angle and length of an arc? I expect that more commonly, the interest is in the sides or other angles of a triangle. After all, doesn't the word trigonometry come from the Greek for triangle measuring? I expect that, at least initially, the ancients became interested in discovering and exploring the subject due to practical interests in the properties of triangles. Some angles of particular interest, although expressible as pi times a rational number of radians, can't be expressed as a pi times a non-repeating decimal number of radians. This one's weak, but just tradition and common usage. *We* would know that, for example, an angle specified as pi * 1/2 radian is a right angle, but I'd bet that a lot of people who need to use angular measures don't know what a radian is. Can you imagine a draftsman ever specifying an angle in radians? Even as pi times a rational number of radians? Or someone looking at the print understanding what it means? I doubt that radian measure is even mentioned in any of the relevant standards. If I have to calculate an angle and compare it to the specification, I need it in usually in decimal degrees, or just possibly degrees, minutes, and seconds, but never in radians. Radian measure does seem natural for mathematics, especially for mathematics beyond basic trigonometry, and even for that I'd think that understanding radian measure is essential to any real understanding beyond using cookbook formulas. But for non-mathematicians, I expect the familiar degrees for angular measure to be used a long time into the future, although with the use of calculators and computers, degrees, minutes and seconds are giving way to decimal degrees. And certainly mathematicians should be able to convert these to radian measure, but many non-mathematicians would have problems converting radian measure to degrees. > Could you not have some kind of indicator in the display if the calc has > changed mode during an operation? By default they are, approx/complex/angle mode are displayed in the status area. ==== > > The rpn program has menus that let you pick if the command and the > > version of it. You can pick the 2 arg version, the 3 arg version, > > the 4 arg, etc. > that's ok for interactive input, but you can not write > a program that way. Is the ti programmable in rpn with > the rpn program? The rpn program is just an interface. -Samuel http://www.calvin.edu/~sstear70/ ==== > Going in deeper at the hardware > -Flash ROM. Just Rocks. 1 MB user memory, practically uncorruptable, > another .5-1MB for the OS making it upgradeable, just awesome, allows > for easy bug correction and getting more add ons. WOW, i love this > feature. > I must add that ive never seen flash corrupting in any 49g. In fact > ive tried to purpously do it and wasnt able to. Ti also has this. You have more faith in HP than I do. I've considered buying a 49g+, but I ain't going to do that until hp updates the 49g. (Even then I doubt I'll buy one anyway.) They can fix a bug like battery drainage and they'll do it fast, but can they fix a bug in the CAS? I want to see ->v3 work correctly with symbolic inputs. I'll send see if the next 49g+ has it fixed. This should be really easy. ==== > It should be relatively simple to port some subset of BLAS and > possibly LAPACK. I just haven't had time to do it. I'm not > particularly good at porting, but no one else seems to want to do it. Ah, too bad, I thought you were hinting at a nice new revision of TIs AMS... I really don't understand why linear algebra is so exceedingly slow, given the speed of other operations. If they fix that, I may in fact consider switching to TI at some point. ==== > I don't think it is the case anymore if you compare with the 49+. It is. Someone posted an example of some integral, which takes something like 4.x seconds on a 49G+, and about 0.6 seconds on a TI89. I also mentioned the example of numerical integration, which is roughly a factor of 3 faster on the TI89 compared to the 49G+. > My own tests show that the 49+ is around 3 to 4* faster when > doing CAS operations than the 49. Sure, but the 49G is slow as molasses... > Numeric mode has been kept for 48 compatibility. I have never > understood what it was designed for. Yup, that is a complete mystery to me, too. It makes no sense at all. > You will get the same kind of error on the 48 -> you should redirect > your critic to the 48 designers. Sigh... Why do you have to take everything personally? > I just can't understand people who would accept a silent > mode switch degree to radian, integrate, and then back > radian to degrees which would lead to the false conclusion > that integrating cos(x) in degrees gives sin(x). Then why not give the correct result? > The only viable alternative to the current situation would > be to check every CAS function and make changes so that > degrees mode is handled. But I don't have time to do that, > I have another CAS to develop. Frankly, the radians switch is a red herring, I think. The switches to complex mode, or approximate mode, or symbolic constants, etc. are much more annoying. There is no reason at all not to save and restore these flags, silently, without any fussing. > And the annoyance of mode switch is not really that important, There are many, many people who disagree. I, for one, think this nonsense is entirely unacceptable. > it affects only a few CAS flags. Yup, with a total of maybe two dozen or so potential calculator configurations... ==== >> I don't think it is the case anymore if you compare with the 49+. > >It is. Someone posted an example of some integral, which takes >something like 4.x seconds on a 49G+, and about 0.6 seconds on a TI89. >I also mentioned the example of numerical integration, which is >roughly a factor of 3 faster on the TI89 compared to the 49G+. > But doesn't theTI use a table lookup for doing integrals etc? If it does, it is not quite fair to compare it to an HP unless it is using the exact same method. You can not compare Apples and Oranges. ==== > But doesn't theTI use a table lookup for doing integrals etc? If it > does, it is not quite fair to compare it to an HP unless it is using > the exact same method. You can not compare Apples and Oranges. Why in the world would that not be fair? All that counts is if I get a solution. I could not care less if the calculator uses a warp drive to cruise out to hyperspace in order to find out that int cos(x) dx=sin(x), or if it looks up the result in a table. Now, of course, if the subset of integrals that the HP can find was substantially larger than the one for the TIs, that would be a different matter, but that does not seem to be the case. On the other hand, Parisse is correct that there are, indeed, cases were the HP is faster fidning integrals than the TIs, so that is something one has to keep in mind. -- Helen. ==== Then set the silent flag on, and press shift-i or shift-num simultaneously to switch the modes if they have changed (something you can check with the header). Or even better define a user key assignement which restores your default flag configuration. > >>And the annoyance of mode switch is not really that important, > > > There are many, many people who disagree. I, for one, think this > nonsense is entirely unacceptable. > I have seen around 10 people in this newsgroup, that's not that many people, but they make a lot of messages about that:-) ==== >> Sigh... Why do you have to take everything personally? Well, Helen, your posts are often rude. Calling a stranger Honey or son, or telling him what you were already doing when he was probably still in diapers, or referring to someone as the little snot-nose or a team as a couple of kids off the street is just plain bad behaviour. I sure hope that you don't treat your students that way, and if you do, I certainly hope that they complain to the administration of wherever it is that you work. header, there's a good chance that I'll see you treat someone very rudely, and surely that person is likely to take it very personally. > When someone make a criticism on the CAS, then it is I can understand that. I also understand everyone working on the 49G was working under constraints, and that improving on and adding to legacy code is difficult. But I hope that you can understand that users may have valid complaints. >> And the annoyance of mode switch is not really that important, Just in case I haven't been counted yet, I find the mode switches without restoring the original modes to be one the worst annoyances of trying to use the 49G. How many seem to think that leaving the calculator in a changed mode after any built-in command, library command, or program that isn't specifically for changing modes is a good idea? I suspect that I could count them all with a single finger. Haven't you ever noticed that most the programs or libraries that others develop and make publicly available save and restore any settings that they force? In my opinion, not doing so is just plain bad programming. >Just in case I haven't been counted yet, I find the mode switches >without restoring the original modes to be one the worst annoyances of >trying to use the 49G. I have to go with Mr. Parisse here. Think of it: The calc silently changes these switches without telling while doing calulations and switches them silently back to the old settings (which is technically speaking perfectly possible). Now I«m forced to think, that the given results are valid for the old flag setting without any knowledge, that this is wrong. I personaly think, that Mr. Parisses approch is the best here: making a change, but telling about it. Mathias -- Mathias Habel mathias.habel_no-spam_@t-online.de Remove _no-spam_ before replying ==== > Think of it: The calc silently changes these switches without telling > while doing calulations and switches them silently back to the old > settings (which is technically speaking perfectly possible). Now I«m > forced to think, that the given results are valid for the old flag > setting without any knowledge, that this is wrong. I think you don't understand the situation. Apart from the red herring of the radians switch, the validity of the result has nothing at all to do with the flag setting. glk ==== What Mr. Parisse is saying: Option 1 - If solving a problem requires a mode shift, then error out & say the problem can't be solved in the current mode - rely on the user to change to mode manually & resolve the problem & then do whatever he/she wants to then. Option 2 - Offer to change the mode - realizing that the answer will be in that mode - AND leave the mode as changed - otherwise the answer may not be valid in the starting mode. For example - complex vs. real or approx. answer vs. exact answer. The user friendly option is # 2 - but at least warn the user that the mode change is needed & the calc is left in that mode when finished with the solution. Now for any problem that to be solved requires a foray into another mode but ends up with a result that is useful in the starting mode, then the mode change should be transparent. I don't know how many problem solutions result in this kind of action. Now about RAD vs. DEG: >Mr. Parisse: Moreover I'm not sure it is possible to find a good >definition for exp(i*x)*sin(x) if x is in degree. What should be >the antiderivative of this function? Really, radian >is the only reasonable unit for angles. Even exp(x)*sin(x), sinh(x)*sin(x) or x*sin(x) doesn't make sense to evaluate in DEG mode. HOWEVER, engineers like to do algebraic manipulations and calculus as if they were in RAD mode, but then evaluate in DEG mode. I can't think of a single reason why anybody in the world would ever want to take a derivative or integral of a function containing trignometric functions in DEG mode & screw around with the 180/PI constants. The solution is to do ALL algebraic manipulations & calculus as if RAD mode was set, but leave DEG mode set afterwards. Sounds simple? Maybe, but I wonder if this would screw up the step-by-step feature? John Edry > > >>Just in case I haven't been counted yet, I find the mode switches >>without restoring the original modes to be one the worst annoyances of >>trying to use the 49G. > >I have to go with Mr. Parisse here. >Think of it: The calc silently changes these switches without telling >while doing calulations and switches them silently back to the old >settings (which is technically speaking perfectly possible). Now I«m >forced to think, that the given results are valid for the old flag >setting without any knowledge, that this is wrong. I personaly think, >that Mr. Parisses approch is the best here: making a change, but >telling about it. ==== > > > >Just in case I haven't been counted yet, I find the mode switches > >without restoring the original modes to be one the worst annoyances of > >trying to use the 49G. > > I have to go with Mr. Parisse here. > Think of it: The calc silently changes these switches without telling > while doing calulations and switches them silently back to the old > settings (which is technically speaking perfectly possible). Now I«m > forced to think, that the given results are valid for the old flag > setting without any knowledge, that this is wrong. I personaly think, > that Mr. Parisses approch is the best here: making a change, but > telling about it. > > Mathias I would like another flag :-) Lets call it Silent mode change and restore on/off Torstein > > -- > Mathias Habel > mathias.habel_no-spam_@t-online.de > Remove _no-spam_ before replying ==== > Haven't you ever noticed that most the programs or libraries that others > develop and make publicly available save and restore any settings that > they force? In my opinion, not doing so is just plain bad programming. I agree. Even on the HP-41, with its limited resources for storing and manipulating flags, many programmers made the effort to save flag settings and restore them at the end of the program. Those familiar with synthetics often used RCL d and STO d for this purpose -- which can be a bit of a challenge given a four-level stack and the normalization issues involved if you try to store the flag register in a numbered data register. -- Wayne Brown (HPCC #1104) | When your tail's in a crack, you improvise fwbrown@bellsouth.net | if you're good enough. Otherwise you give | your pelt to the trapper. e^(i*pi) = -1 -- Euler | -- John Myers Myers, Silverlock ==== > I can understand that. > > I also understand everyone working on the 49G was working under > constraints, and that improving on and adding to legacy code is > difficult. > > But I hope that you can understand that users may have valid complaints. > > Usually, I try to improve the code when users have valid complaints and tell them in a constructive manner like you do. But unfortunately for the 49, I do not have time to invest in large changes like those that e.g. accepting degree mode in CAS functions would require (assuming it would make sense everywhere). Therefore the current situation is a trade-off, not perfect, but I think most users should live with that, especially since the modified flags are not modified without warning the users, and are displayed in the status area, and affected flags can easily be restored by a user-key press using a program and user key assignement. Note that this kind of behaviour was also present in the 48, if you are for example solving an equation numerically the X variable will be assigned and when you leave the solver it is not restored (or purged), this can also perturb the user when he later evaluates an expression that contains X. My conclusion on this is that users of previous HP calcs had some habits, they just did not learn a few new tricks. And that is most probably because the 49 can almost be used like a 48. ==== > Then set the silent flag on, and press shift-i or shift-num > simultaneously to switch the modes if they have changed > (something you can check with the header). Or even better > define a user key assignement which restores your default > flag configuration. You are just being obstinate. None of these silly gyrations should be necessary. > I have seen around 10 people in this newsgroup, that's not > that many people, but they make a lot of messages about that:-) Yup, disregarding your own opinion, a hundred percent of them think the mode switches are an unnecessary aggravation. -- Helen. ==== > Then please explain how the mode switch should be done. Why, such that the CAS resturns the correct result for the derivative and anti-derivative of trigonometric functions. I assume you don't need help figuring out what that means... -- Helen. ==== > > you could do the following: > > 1) save the CAS affected flags > > 2) do CAS processing silently > > 3) restore the flags > > 4) show result > > The HP calculatrice before the 49G *never* changed any flags > > automatically on any calculation - including limited symbolics > > nor should they do it today... > > I don't agree, because if the calc would switch silently > in rad mode to make the integral and then back to previous angle > mode, you could get what appears to be a wrong answer > (e.g. in degree mode the antiderivative of cos(x) would be sin(x)). > CAS + degree mode = bad idea. Well Parisse, i see your points. In fact i must say that what you have done is wonderfull. But, theres still a little problem. When using SOLVEVX for example, it asks for a mode switch to radians. IF i am using trig functions, what i do is change to rads, solve the equation and evaluate the functions after switching back to degrees. Now, i understand what you say; but how about this idea: Having a 3rd option. Switch to RAD mode? Yes No Silent. If silent is chosen then do what ==== > Now, i understand what you say; but how about this idea: Having a 3rd > option. > Switch to RAD mode? Yes No Silent. If silent is chosen then do what I'm not against that, but it requires a lot of work if you want to be sure that it is done consistently for all functions. And as explained in another thread, what is the meaning of exp(i*x)*sin(x) in degree mode? Should i multiply only the arg of sin or also the arg of exp? ==== > > >C programming is more powerful in my opinion. Of course, we're > >entitled to our own opinions :-) > > > Some people define the power of a language acoording to the number of > lines of code you need to solve a problem: the less code you need to > write the more powerful the language is said to be. Through this definition, User-RPL would be extremely powerful. OF course, taking the advantage of RPN. But, when i speak of power, what i mean is how well the language fits the hardware. Ill explain; Even though c++ (for example) is a very nice language that can solve tons and problems and do many many many things, if used in a regular calculator i assume that due to limited RAM and processing capabilities, it would not be to efficient. In this case, RPL is designed for use with RPN calculators, working optimumly with limited RAM, each program consuming very little space. ==== > >But, when i speak of power, what i mean is how well the language fits >the hardware. Ill explain; Even though c++ (for example) is a very >nice language that can solve tons and problems and do many many many >things, if used in a regular calculator i assume that due to limited >RAM and processing capabilities, it would not be to efficient. > Ah, I have to step in here... There are very few cases where C++ is less effecient than C when programmed in the same way, and some where C++ is more effecient. One of the designing principles of C++ was that it not ever add features that made it less effecient than C overall, i.e. if you use exception handling then that could slow down function call/return, but if you never use exception handling it should be as effecient as C and you don't have to pay a penalty for using the language. Pete M. Wilson Gamewood, Inc. wilsonpm@gamewood.net ==== I was poking around my SD card and decided to view something called HPERRLOG.TXT. It says Fatal Error number 19087409 (0x1234031) reported in Capture.cpp rev 1.103, line 475 (This card was taken from an HP Photosmart 812 digital camera and stuck into my 49G+ without formatting, so that might confuse things a bit . . .) Anyone know where that message comes from? ==== Well, as it's Capture.cpp, i'd be led to think it is from the digital camera capturing photos, but i could be wrong. -MrM > I was poking around my SD card and decided to view something called > HPERRLOG.TXT. It says Fatal Error number 19087409 (0x1234031) > reported in Capture.cpp rev 1.103, line 475 > > (This card was taken from an HP Photosmart 812 digital camera and > stuck into my 49G+ without formatting, so that might confuse things a > bit . . .) Anyone know where that message comes from?