HP-15 ==== >I'm having a big problem with my hp48. >Some keyes (A,B,MTH,PRG,',Sto,SIN,COS,ENTER) work no more. >Did anybody have this kind of problem ? >> >> Never buy version 1.0.... It will be a good calculator year from >> now. > >What are you talking about? The 48 has been around for a long time. He's >not talking about the 49 g+. > Ops... There is so much about 49 g+ that whan I hear calculator I think 49 g+ :) A.L. OK i fixed it... there is a small piece of rubber, (or what is it), it makes connection between keyboad and processor board... I sticked small piece of adhesive tape, and it works fine :) I also updated my memory, form 32k - > 128k... next 128k will come tomorow ==== > >I'm having a big problem with my hp48. >Some keyes (A,B,MTH,PRG,',Sto,SIN,COS,ENTER) work no more. >Did anybody have this kind of problem ? >> >> Never buy version 1.0.... It will be a good calculator year from >> now. > >What are you talking about? The 48 has been around for a long time. He's >not talking about the 49 g+. > > > Ops... There is so much about 49 g+ that whan I hear calculator I > think 49 g+ :) > > A.L. OK i fixed it... there is a small piece of rubber, (or what is it), it makes connection between keyboad and processor board... I sticked small piece of adhesive tape, and it works fine :) I also updated my memory, form 32k - > 128k... next 128k will come tomorow I wonder if this fix for the 48 would fix some of the problems people have been having with the 49G+? I think ill look into it later. ==== > By COLIB, I mean the library of scientific constants one accesses > through LEFT-SHIFT, EQ LIB, COLIB, CONLI. > > I'd love to be able to replace some of those with converted versions at > will, in a way similar to how UNITMAN does the same for units? I'm not sure that this is covered in the 48G documentation; I learned it from the application card's documentation. I think that what you're looking for are reserved variables with a name in the form of 'constNAME'. The CONST command first searches the path for such variables before looking for the value in the constants library. For example, normally, 'StdT' CONST returns 273.15_K. By storing 293.15_K in a variable named 'constStdT', now when I do 'StdT' CONST, my calculator returns 293.15_K. But note that when I look at the list by pressing CONLI, I still see the original value, and the ->STK key puts that on the stack, not the one that CONST uses. You're welcome. I hope that this is what you were looking for. -- James ==== the originally preprogrammed constants for editing. Oh, and what's this application card you refer to? Was it part of the printed materials that came with the calculator? Ah! You must refer to one of the GX modules. I started with a G and am now on a G+. So, I guess I won't be in possession of any of these materials. Is it on the > By COLIB, I mean the library of scientific constants one accesses > through LEFT-SHIFT, EQ LIB, COLIB, CONLI. > > I'd love to be able to replace some of those with converted versions at > will, in a way similar to how UNITMAN does the same for units? I'm not sure that this is covered in the 48G documentation; I learned it from the application card's documentation. I think that what you're looking for are reserved variables with a name in the form of 'constNAME'. The CONST command first searches the path for such variables before looking for the value in the constants library. For example, normally, 'StdT' CONST returns 273.15_K. By storing 293.15_K in a variable named 'constStdT', now when I do 'StdT' CONST, my calculator returns 293.15_K. But note that when I look at the list by pressing CONLI, I still see the original value, and the ->STK key puts that on the stack, not the one that CONST uses. You're welcome. I hope that this is what you were looking for. ==== > the originally preprogrammed constants for editing. Not very easily at least. On the 48G series, they're in ROM, so can't be changed. On the 49G and 49g+, they're in flash ROM, so I suppose that someone with sufficient knowledge and skills might be able to successfully hack into the ROM and modify them. On the 48SX, the library comes on a plug-in ROM card, which can't be changed, but I have successfully transferred the contents from the ROM card to a RAM card, and everything still worked just fine. I suppose that one could upload the contents of the RAM card to a PC, find and edit the values of the constants there, and download everything back to the RAM card again. But you might be able to develop your own application to be used in place of the built-in constants library if you really want to. It could even use the same names as the built-in commands. I expect that library commands are most often used as substitutes for built-in commands, but global variables are feasible for this purpose. When executing any object, the calculator pays attention to the object type. If it's been compiled as a global name, then it looks only for global variables; it ignores local variables, external library commands, built-in commands, or anything else that may be present. Similarly, if the object has been compiled as a local name, it looks only for local variables and ignores everything else. And so on for any object type. On these calculators, name resolution when compiling from the command line editor, a downloaded ASCII transfer, or by using OBJ-> or STR-> on a string works like this (much of this is plagiarized and paraphrased from Insights); follow the steps until the name is resolved: 1. A series of non-delimiter/separator characters that doesn't start with a numeral or fraction mark is presumed to be a name. 2. (not on the 48SX/S) If the name starts with a <- (the left arrow, character 142), then it's a local name. 3. If the name is within a local variable structure, and matches a local variable name defined for that structure, then it's a local name. 4. If a local memory (from any suspended procedures) is present that contains a local variable with a matching name, then it's a local name. 5. If a global variable with a matching name exists anywhere in the current directory, then it's a global name. 6. If the name matches a command name in an external library attached to the current directory, then it's an XLIB name. It's compiled using the library number and the number of the object within the library, but as long as the library is present, the library command name is used for display purposes. 7. If not already in the HOME directory, then the last two steps are applied to the parent directory, and to its parent, and so on, until the HOME directory and all external libraries attached to it have been searched. 8. If the name matches a built-in command name, then it's a built-in command name and is compiled using either the address (commands from the 48S series) or the built-in library number and number of the object within the library (commands added with the 48G series and newer) of the command, and for display purposes, the built-in command name is shown. 9. Otherwise, it's a global name. Of course, the design makes it a bit difficult to make a global variable with the same name as a built-in command, if for no other reason than that simply because by the time you get the name on the stack, it's already been compiled as a local name, in which case it's stored as the local variable, or an external library command which you can't store anything into, or the built-in command, which you also can't store anything into. I suppose that if you already had a global variable with a matching name anywhere on the path , you might be able to make another variable with the same name in the current directory, but how to make the first global variable with the name matching a built-in command would be the problem. But there are ways to get around that difficulty even in the 48 series if you really want to. I suppose that the SysRPL command $>ID (or the equivalent SYSEVAL sequence) should suffice; it changes a string to a global name. In the 49G (and I assume the 49g+ and 48gII) getting around the restriction is especially easy; the filer can be used to rename global variables to forbidden names, or the S~N command (on menu 256) can be used to toggle a string to a global name, even a forbidden name. If anyone sees a mistake in the above, please correct me. > Oh, and what's this application card you refer to? Was it part of the > printed materials that came with the calculator? Ah! You must refer to > one of the GX modules. I started with a G and am now on a G+. So, I > guess I won't be in possession of any of these materials. Is it on the Close, not a quick reference card, but a plug-in ROM card designed for the 48SX. It's the HP Solve Equation Library Application Card. I don't know what happens if it's plugged into the 48GX. The original HP 82211A has the Equation Library, Periodic Table, Constants Library, Finance, Multiple-Equation Solver, and Utilities. The 82211B adds the Tetris game to Utilities, slighty modifies the use of the MES, and changes a , as a separator to a ; in one equation, I suppose to avoid the possibility that it could be treated as a fraction mark. The Periodic Table, Tetris, and the ELVERSION command (which displays a splash screen with version information for the card) didn't make it into the 48G series, but as far as I know, the rest are incorporated into the 48G series ROM essentially unchanged. No, unfortunately the Owner's Manual for this card doesn't seem to be available on the Museum's CD set/DVD. But most of it should be available in the 48G series documentation, especially if you have the Advanced User's Reference Manual. I'm surprised that the AUR doesn't list the 'constNAME' variables with the other reserved variables, as it does list the reserved variables for MINEHUNT. -- James ==== 49G+ $129.99 http://www.graphingcalculators.net/hp49grca.html I went to Fry's this morning, and sure enough, they are sitting there with the calculators on the isle behind the cordless phones. I have been a long time 48GX user. After setting the soft menus and a couple other display items, the thing feels a lot more like the 48GX from a usability standpoint. However, many of the keys are changed around. The thing feels more like a cheap remote control than it does an HP calculator though. The increased speed on the UI is nice, and being able to port programs over the SD card is a plus. I really hope that HP improves the feel on the next version, if there is one. This one just feels cheap. ==== --------------------------------------------------------------------- The following routine reorders the varibles in a directory in order to have the directories first, in alpha order, and then the rest of the variables, in alphabetical order as well. I spent some time today playing with this task, so, this is the end result. %%HP: T(3)A(D)F(.); << VARS SORT OBJ-> { } SWAP { } 1 ROT START ROT IF DUP VTYPE 15=/ THEN SWAP + ELSE ROT + SWAP END NEXT + ORDER >> Enjoy! Toby ==== Try this out: << 15. TVARS SORT VARS SORT + ORDER >> It's 55.5 bytes smaller than your program, and 2 to 3 times faster. ==== > > Try this out: > > << 15. TVARS SORT VARS SORT + ORDER >> > > It's 55.5 bytes smaller than your program, and 2 to 3 times faster. Gosh, talk about bursting someone's balloon. Toby no doubt worked (or played) hard on that program, and has every right to be proud of himself. I'd bet he learned a lot writing it. I'm assuming, of course, that it works as intended. I didn't actually try it out, but offhand it looks to me as if it ought to work. Maybe he just didn't realize that various programs for accomplishing the same task have been around for over a decade. On the other hand, I guess that now he knows for sure that there are more things worth learning about programming these calculators. -- James ==== Don't worry about me, I'm still standing... Yep, your solution is more elegant. But it was good practice. I'm still planning to conquer the world! Toby > > Try this out: > > << 15. TVARS SORT VARS SORT + ORDER >> > > It's 55.5 bytes smaller than your program, and 2 to 3 times faster. Gosh, talk about bursting someone's balloon. Toby no doubt worked (or played) hard on that program, and has every right to be proud of himself. I'd bet he learned a lot writing it. I'm assuming, of course, that it works as intended. I didn't actually try it out, but offhand it looks to me as if it ought to work. Maybe he just didn't realize that various programs for accomplishing the same task have been around for over a decade. On the other hand, I guess that now he knows for sure that there are more things worth learning about programming these calculators. -- James ==== Try this out: << 15. TVARS SORT VARS SORT + ORDER >> It's 55.5 bytes smaller than your program, and 2 to 3 times faster. This reminds of when I was attending a course in APL (a nowadays mostly forgotten, very compact programming lkanguage) and having put very much effort into an excercise and come up with a an extremely smart three line solurtion. I walked up the teacher, very proud, and showed my solution. - Oh dear, Per, you have to think *APL*! Here is the one-line solution... Sigh. Per. ==== This reminds of when I was attending a course in APL (a nowadays mostly forgotten, very compact programming lkanguage) and having put very much effort into an excercise and come up with a an extremely smart three line solurtion. I walked up the teacher, very proud, and showed my solution. - Oh dear, Per, you have to think *APL*! Here is the one-line solution... Sigh. Per. Well, it's not just the number of lines that counts, but also the -- Bhuvanesh ==== >This reminds of when I was attending a course in APL (a nowadays >mostly forgotten, very compact programming lkanguage) and having put >very much effort into an excercise and come up with a an extremely >smart three line solurtion. I walked up the teacher, very proud, and >showed my solution. > >- Oh dear, Per, you have to think *APL*! Here is the one-line >solution... > >Sigh. > >Per. Well, it's not just the number of lines that counts, but also the -- Bhuvanesh Reminds me of Matlab, where there always seems to be a better, non-explicit-loop type, solution to every problem. Take a look in comp.soft-sys.matlab, and you'll see that a fair number of questions are of the form How can I improve the following code? Some of the answers are, to me, remarkably obscure. But that's my problem. Martin Cohen ==== For example, the very first case shown returns *exactly* 3*e^4 on the hp49g+ in 4.2 seconds in exact mode. No fair comparing its Approximate mode to the TI's CAS solutions! How fast does the TI find that solution, by the way? Just wondering. The TI returns the result essentially immediately. Generally, symbolic integration is much faster on the TI, which uses lookup tables, compared to the HP CAS. Numerical integration on TI89/Voyage 200 is typically a factor of 2 to 3 faster than on a HP49G+. -- Helen. ==== But it is something normal people often do, without even thinking about it. That's bad; integration is not necessarily a trivial operation. It is particularly non-trivial when the integration domain is infinite. Integration, by its nature, is a stable process, so the results should be clean, right? No, not at all, in particular when we are talking about improper integrals. If you are interested in the accuracy of algorithms for numerical integration, choosing difficult integrands over finite domains would have been more informative. Also, as others have remarked already, you need to be careful to make sure that you choose an integrand that is actually fed into the numerical solver, and not passed to and solved in closed form by a CAS, which happened in a few of your cases (mostly with the TI). Those cases are, of course, entirely useless for the question at hand. Point taken; however, it still seems reasonable (to me) for the average user to assume that the maximum range will give the maximum accuracy. That is a naive assumption. It may well be that the average user makes that assumption, but s/he may be very wrong in doing so. They shouldn't have to hunt for the range where precision stops increasing before the answer starts changing. Well, as I said, integration is not necessarily a naive operation. One would hope that somebody performing such an operation has a minimal understanding of what it is s/he is doing. This is what I mean: ... a numerical process is unstable if small errors made at one stage of the process are magnified in subsequent stages and seriously degrade the accuracy of the overall calculation. - Numerical Analysis, 2nd ed, by Kincaid and Cheney, 1996, p. 68. Yes, but what you are presumably interested in, given the context of all this, is the numerical stability of a particular implementation of a floating point arithmetic. That is not the same thing as investigating the stability of a numerical algorithm which is what Kincaid and Cheney had in mind. I really don't have the time to give an online course on the subject, but you would probably find some of Kahan's papers on the subject instructive. They are available on the web. Almost every machine on the planet can do x*y perfectly, ignoring the roundoff error. Numeric stability has _everything_ to do with the algorithmic implementation of higher level functions. No, that is an entirely different kettle of fish. You are talking about accuracy, not stability. The two concepts are essentially orthogonal. I feel justified in evaluating a calculator's performance based on how it handles a potentially ill-conditioned equation. If instabilities don't show up, then the calculator is suitable to a wide range of tasks; if they do, then you can't trust the calculator for a few more corner cases. What you found are inaccuracies; that is not the same thing as an instability. I happen to use trig functions a lot, so they seemed like a logical thing to play with. Maybe you would have preferred a demo of various matrix decompositions? That would, in fact, have been useful, if done right. -- Helen. ==== > >>Now, I have evidence, but its not quite what I expected. > > > Well, there seem to be quite a few problems with what you have done. There are a few, yes. > - First of all, testing numerical integration of improper integrals as > such is dicey, and in any case not a good test of numerical accuracy. But it is something normal people often do, without even thinking about it. Integration, by its nature, is a stable process, so the results should be clean, right? But not when 1 or both of the integration limits is infinite !! That's why it's called an improper integral 2nd - you used the exact mode for the TIs but not for the HP49s That not a fair comparison. The proper modes on the HP49G will allow it to get the same answers. > - I tried some of the integrals that gave you nonsense, and found that > I got identical results with all HPs, as it should be; the > implementation of the basic numerics and arithmetic is identical for > all the HP48/9 clones. There could have been issues with the emulators > you were using, or some combination of the various flag settings of > the HPs that got in the way; maybe the CAS got in the way (as it is > wont to) on the 49s, too. That is good; I was bothered by the differences. This is why I documented what I was doing - so any sources of error could be rooted out. FWIW, I didn't touch the flag setting on the emulators, other than to change plot axes and the like. The emulators WILL give you the exact same answer for all numerical calculations - no ifs or buts about it. This means that the plots WILL be the same. BUT, If you had bothered to check the mode settings - you'd see that you would get similar results as the TIs. > All of the integrals gave reasonable answers when I tried them, > restricting the integration domain reasonably, of course (it should be > obvious that there is no reason at all to go to MAXR or -MAXR for > exponentials) Point taken; however, it still seems reasonable (to me) for the average user to assume that the maximum range will give the maximum accuracy. They shouldn't have to hunt for the range where precision stops increasing before the answer starts changing. The pre-TI92s (i.e. TI81,82,83,85,86) will all give you a bad answer to these integrals if you give it a ridiculously large number for 1 or both of the integration limits. > a) What you are looking at has very little to do with numerical > stability as it is commonly understood, and everything with the > particular implementation of trigonometric functions. As such, it is a > poor indicator of overall numerical quality. What do you mean by numerical stability? This is what I mean: ... a numerical process is unstable if small errors made at one stage of the process are magnified in subsequent stages and seriously degrade the accuracy of the overall calculation. - Numerical Analysis, 2nd ed, by Kincaid and Cheney, 1996, p. 68. Almost every machine on the planet can do x*y perfectly, ignoring the roundoff error. Numeric stability has _everything_ to do with the algorithmic implementation of higher level functions. I feel justified in evaluating a calculator's performance based on how it handles a potentially ill-conditioned equation. If instabilities don't show up, then the calculator is suitable to a wide range of tasks; if they do, then you can't trust the calculator for a few more corner cases. I happen to use trig functions a lot, so they seemed like a logical thing to play with. Maybe you would have preferred a demo of various matrix decompositions? You are refering to numerical accuracy NOT numerical stability. No matter what calculator or computer you use, you can always find equations that the device will give incorrect answers IF you force it to give you a numerical answer. I don't think any of the CAS softwares will automatically rework an equation to give a good answer for all locations - you'd usually have to do it yourself - or set the accuracy calculation to some large number - like 300 digits. BTW, the TIs will have the better numerical accuracy as they carry 15 digits internally for all numbers and calculations. The HPs only keep 12 digits. Also, for your first example (1+x)-1 - if you had used 5.0001E-12 you'd get 1E-11 for an answer, but apparently a nearly 100% error is not important to you. > b) In your example I, y(x) is approximately equal to 1/12-x^2/360, so > the function should converge to a constant of 1/12 near x=0, not > 1/x^4. You're absolutely correct here; I should know better than to do math when I'm tired. (Mistakes found the morning after: dropping all i's, and swapping several signs). However, the point that none of the calculators (or emulators) converged still stands. > c) The real HP48/9x's should give exactly identical results in all > cases; again, they use exactly the same arithmetic, although I could > imagine that there might be differences in the way plotting is > handled. If I could test this, I would not have spent money on a new calculator, but alas, my 48 is departed from me. > e) If I try to calculate 2*cos(x)-2+x^2 for y=0.001 or smaller, I get > an exact zero on the HP48; that should translate into a zero for your > function, too, no matter how small x becomes (as long as it is finite, > of course). Er, which function? Actually, Helen, if you look at various oddball numbers, you will see the result jump all over the place - so it's not zero everywhere. Daniel - set your RAD mode on the HPs & you'd get the same result as the TIs - you probably had it on DEG. Again the TIs will not show this behavior at a smaller number that the HPs - because of the extra 3 digits carried internally. -.001 to .001 is small enough for both to show the same behavior. It's late, so I won't find out at what point the results deviate from the actual results to say 100% or more at. I'll let somebody else do that. The RAD mode will let the HPs get the same answer for your 4th integral. Later, Daniel Herring John Edry ==== A friend of mine tells me that his HP-49g to PC tranfer cable fits into the coummincations port of his HP-100LX. Can you successfully advance. ==== > A friend of mine tells me that his HP-49g to PC tranfer cable fits > into the coummincations port of his HP-100LX. Can you successfully > advance. I have an HP palmtop cable that fits my 49G. Well, not perfectly, the key, or bump on top is wider than on the calculator's cable, but it's not hard to use it by mistake. But connecting it even momentarily results in the screen going dark; I haven't experimented with leaving it connected. They do look much the same, but electrically they're definitely different. Emphasize that he shouldn't even try, unless he's prepared to sacrifice his 100LX just to find out what happens. -- James ==== The only relevant difference (as far as speeds concerned) between user and sysrpl is that the former conducts error checking on function arguments. Therefore if your program makes many calls to functions you will notice a good speed increase. IMO it is worth the effort to learn SysRPL, especially if you already know UserRPL. The Kalinowski/Carsten manual is all you really need, and Debug4x allows fast, easy and safe compiling on the PC. dave Do you have comparison feedback on SysRPL vs ASM too? Ed Sutton ==== where can I order it? -JP ==== I've seen speculation but no announcements of success (nor do I have one yet to try out myself)... has anyone managed to program ARM code directly on the HP49G+? As a veteran ARM coder from back in the days when they were Acorn RISC Machines ;-), I'm quite happy at the thought of being able to target my calculator using this extremely elegant instruction set! -- Tom Garcia Support http://www.amnesty.org/ and http://www.fsf.org/ ==== I hope you feel better now about the whining ... but a lot of us industrial / commercial types aren't able to port our software as easily as you make it seem. I doubt that *you* could, either, (at least at this point). For example, please tell me how you would port *rs-232* based software over to the 49+ flawlessly! I'd even settle for a few minor flaws! Backward compatibility in this case? (Forget about it!) Try hp 48gII - it has the serial I/O and not only 9600, but up to 115,200 This is a HW issue, not software. I sincerely hope that a new 49GX would be announced with serial connection on the side and SDIO slot (added?) Maybe music is a small niche interest; but you gotta love the innovation and detail of the engineering that permitted such versatility - - at least historically. The new CPU allows more simultaneous channels the music software needs a redesign anyway - and is a niche area I see COS, quare root, 1/X on keyboard I also see EVAL & tick [ ' ] & SYMB on keytops That's what this calc is for. (WR's calc would have BEEP & NOTE [ d ] & MUSIC on keys) (-; -Dale- > >I was able to port my software (all SysRPL) to the 49+ flawlessly. I >suspect that most programs that are used for work purposes will also >follow this example. That, to me, is backward compatibility. As for >the rest. take heed of your own last statement: Forget about it! ==== DispOff was used as a very dirty trick to have a slight speed gain. This will have no effect whatsoever on the 49G+ Hence, he simply killed the supported pointer DispOff. Thus, nearly the entire section SOUND on hpcalc.org is unusable on the 49+. Are JYA and CdB really that unmusical? Did they never realize that DispOff didn't serve speed-up but improving the sound quality? MIG-performances are in asm and speed doesn't play any role. Only sound quality is what counts. Interesting which other supported SysRPL or asm pointers they killed. Backward-compatibility? Forget about it! I would think this is highly exaggerated. In fact, the HP49G+ is a completely new hardware platform, and I consider it amazing that most HP49 software either runs directly on it, or with minor modifications. This shows a major commitment of the designers of the HP49G+ to backward compatibility. It is obvious that when moving to new hardware, programs relating to hardware may have problems, including sound or communication software. I certainly was not aware that turning off the display was important for the smooth running of music - maybe other people where not either. I don't know if on an arm, turning off the display would have the same effect - do you? - Carsten ==== > > DispOff was used as a very dirty trick to have a slight speed gain. > This will have no effect whatsoever on the 49G+ > > Hence, he simply killed the supported pointer DispOff. Thus, nearly the > entire section SOUND on hpcalc.org is unusable on the 49+. Are JYA and > CdB really that unmusical? Did they never realize that DispOff didn't > serve speed-up but improving the sound quality? MIG-performances are in > asm and speed doesn't play any role. Only sound quality is what counts. > Interesting which other supported SysRPL or asm pointers they killed. > Backward-compatibility? Forget about it! I would think this is highly exaggerated. In fact, the HP49G+ is a completely new hardware platform, and I consider it amazing that most HP49 software either runs directly on it, or with minor modifications. This shows a major commitment of the designers of the HP49G+ to backward compatibility. It is obvious that when moving to new hardware, programs relating to hardware may have problems, including sound or communication software. I certainly was not aware that turning off the display was important for the smooth running of music - maybe other people where not either. I don't know if on an arm, turning off the display would have the same effect - do you? I think a lot of people are missing the point. A SUPPORTED ENTRY POINT WAS REMOVED! That's a lot worse than a bug; it's a deliberate omission of something that should *never* change in an emulation! Or was all that stuff about the 49G+ emulating the 49G's Saturn just marketing hype? Because if it's a true emulation, then *all* supported entry points have to *continue* to be supported, whether anyone was using them or not. I intend to bring that point up the next time JYA (or anyone else) criticizes someone else's software for using unsupported features. -- 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 ==== X >> Hence, he simply killed the supported pointer DispOff. X >> Interesting which other supported SysRPL or asm pointers they killed. >> Backward-compatibility? Forget about it! > I would think this is highly exaggerated. X I think a lot of people are missing the point. A SUPPORTED ENTRY POINT WAS REMOVED! That's a lot worse than a bug; it's a deliberate omission of something that should *never* change in an emulation! Or was all that stuff about the 49G+ emulating the 49G's Saturn just marketing hype? Because if it's a true emulation, then *all* supported entry points have to *continue* to be supported, whether anyone was using them or not. I intend to bring that point up the next time JYA (or anyone else) criticizes someone else's software for using unsupported features. Yeah! WAY to go NExt, WAYNE! ==== DispOff was used as a very dirty trick to have a slight speed gain. This will have no effect whatsoever on the 49G+ Hence, he simply killed the supported pointer DispOff. Thus, nearly the entire section SOUND on hpcalc.org is unusable on the 49+. Are JYA and CdB really that unmusical? Did they never realize that DispOff didn't serve speed-up but improving the sound quality? MIG-performances are in asm and speed doesn't play any role. Only sound quality is what counts. Interesting which other supported SysRPL or asm pointers they killed. Backward-compatibility? Forget about it! - Wolfgang Now this really is bad news. MiG was one of the most impressive pieces of software for HP48/HP49, much more than just handheld number crunching. IMHO, if HP49G+ is announced as software compatible to HP49G, this should cover all supported entries, except where real HW changes makes this impossible (like serial I/O, or maybe some aspects related to display size). Switching off the display (as many advanced programs do) should still be easy on the new machine. I don't (yet) own a HP49G+, but hearing of this incompatibility does not really spur me to get one. What other supported entries are missing? If I make the switch, I want to retire my 49G, not add one more to the zoo. (I guess some others think along similar lines.) Please, JYA or CdB, or whoever can do this, re-check the removed supported entries and add whatever possible. At least DispOff _still_ makes sense. Georg Zotti Georg Zotti Institute of Computer Graphics and Algorithms, TU Vienna, Austria / http://www.cg.tuwien.ac.at/~gzotti | | v :.: o o -O- O ::: . o o . ==== > JKH confirmed that the Display-off command (dashed D in OT49+) does not > work on the 49+ anymore. It contains the following ASM-code: > GOSBVL SAVPTR > GOSBVL DispOff > GOVLNG GETPTRLOOP DispOff was used as a very dirty trick to have a slight speed gain. This will have no effect whatsoever on the 49G+ Hence, he simply killed the supported pointer DispOff. Thus, nearly the entire section SOUND on hpcalc.org is unusable on the 49+. Are JYA and CdB really that unmusical? Did they never realize that DispOff didn't serve speed-up but improving the sound quality? MIG-performances are in asm and speed doesn't play any role. Only sound quality is what counts. Interesting which other supported SysRPL or asm pointers they killed. Backward-compatibility? Forget about it! - Wolfgang Was there any word on how audio and other hardware aspects will continue to be supported, or just word of what no longer works? I have yet to get around to connecting my 49G to put sound software on it to play, but now wondered if there were any new suprises for me to find available for the 49G+. Hopefully the new hardware platform expands the calculator's abilities rather than cripple it. After all, its obvious that a new and larger screen with (presently some) functionality was able to be added despite that docs I read said that the previous hardware was limited to a screen of the previous size. Ed Sutton ==== > http://www.firmwaresystems.com/ > > thanks 49g+ can't use this - it uses RS-232. How about the 48gII ? ==== The ROM for a 49G & 49G+ are different (ARM9 emulating a Saturn - some native code) It's your calc - you may try to fry it... I was wondering if the file format of ROM updates is similar between the HP49G and the G+. I'm trying to figure out if it is likely that I can update the ROM under linux. There is an HP49G updating program for linux that shouldn't be hard to convert to work with the HP49G+ if the protocol and ROM update file format are similar. In the meantime, how much does the 1.20 ROM affect my batteries. Should I remove them (perhapse including the lithium) when not using it since there isn't anything important in memory? Ed Sutton ==== The 2 manuals for the HP 49G+ are missing 2 rather important subjects from its contents: the I/O functions of the calculator and a complete commands reference. I guess they are explained in the 49G user guide and in the downloadable (www.hpcalc.org) 49G commands reference, respectively. But it's just that the manuals that came with the 49G+ doesn't explain anything about transferring files or printing the display, and it's also missing the commands reference section which would explain all of the 49G+'s functions in its entirety. Yes, a separate (free as a PDF) Programmer's Reference Manual is needed. It should have the command reference and programming examples RPL right on the right side and HP-BASIC is left to the left side ==== # modprobe safe_serial i can't load this module, where can i activate this module in my kernel connfiguration. I'm using a 2.4.22 kernel -- debian gnu/linux 15:51:53 up 6 min, 2 users, load average: 0.15, 0.38, 0.21 www.elwater.net ==== > # modprobe safe_serial i can't load this module, where can i activate this module in my kernel connfiguration. I'm using a 2.4.22 kernel Apparently, this module doesn't exist in 2.4. It is still experimental in 2.6, actually. Maybe you can try on 2.4 without, but I doubt it will work. 2.6 is quite stable now (I'm using it since 2.5.75 without real trouble), you should try if you have the prerequisite (read Documentation/Changes). Samuel Thibault ==== Apparently, this module doesn't exist in 2.4. It is still experimental in 2.6, actually. Maybe you can try on 2.4 without, but I doubt it will work. 2.6 is quite stable now (I'm using it since 2.5.75 without real trouble), you should try if you have the prerequisite (read Documentation/Changes). i've installed the debian package of kernel 2.6 and i can load both modules (usbserial and safe_serial) but it don't work.... what else can i do? thanks for your help vicent Samuel Thibault -- debian gnu/linux 18:41:20 up 12 min, 1 user, load average: 0.01, 0.20, 0.21 www.elwater.net ==== > Apparently, this module doesn't exist in 2.4. It is still experimental > in 2.6, actually. Maybe you can try on 2.4 without, but I doubt it will > work. 2.6 is quite stable now (I'm using it since 2.5.75 without real > trouble), you should try if you have the prerequisite (read > Documentation/Changes). i've installed the debian package of kernel 2.6 and i can load both modules (usbserial and safe_serial) but it don't work.... what else can i do? did you load it with the correct parameters ? ie insmod usbserial vendor=0x3f0 product=0x121 after insmod & plugging & turning on the calc, launch dmesg to check what the kernel found. ==== it works!!! oeoeoeoeoeoe! :) now it's time to learn using xmodem, i've always used kermit... thanks!!! > > Apparently, this module doesn't exist in 2.4. It is still experimental > in 2.6, actually. Maybe you can try on 2.4 without, but I doubt it will > work. 2.6 is quite stable now (I'm using it since 2.5.75 without real > trouble), you should try if you have the prerequisite (read > Documentation/Changes). > i've installed the debian package of kernel 2.6 and i can load both > modules (usbserial and safe_serial) but it don't work.... > what else can i do? did you load it with the correct parameters ? ie insmod usbserial vendor=0x3f0 product=0x121 after insmod & plugging & turning on the calc, launch dmesg to check what the kernel found. -- debian gnu/linux 23:05:27 up 45 min, 3 users, load average: 0.12, 0.11, 0.19 www.elwater.net ==== it works!!! oeoeoeoeoeoe! :) now it's time to learn using xmodem, i've always used kermit... kermit should work as well, provided hp49g+ has the same support as hp49g's... Samuel Thibault ==== Are you able to use the USB port for Serial (RS-232) apps? Did you make a special cable and if so what are the pin outs? it works!!! oeoeoeoeoeoe! :) now it's time to learn using xmodem, i've always used kermit... thanks!!! >> > Apparently, this module doesn't exist in 2.4. It is still experimental > in 2.6, actually. Maybe you can try on 2.4 without, but I doubt it will > work. 2.6 is quite stable now (I'm using it since 2.5.75 without real > trouble), you should try if you have the prerequisite (read > Documentation/Changes). >> i've installed the debian package of kernel 2.6 and i can load both >> modules (usbserial and safe_serial) but it don't work.... >> what else can i do? > > did you load it with the correct parameters ? ie > insmod usbserial vendor=0x3f0 product=0x121 > after insmod & plugging & turning on the calc, launch dmesg to check > what the kernel found. ==== Are you able to use the USB port for Serial (RS-232) apps? Did you make a special cable and if so what are the pin outs? Yes it works, without any special cable. Just read every previous post on this very thread. Samuel Thibault ==== escribiÌ°å°Ì[Hyphen][ ARing]°Ì°å[Hyphen]Ì[Hy phen]åÒ: with the 2.4, running a dmesg i get this usb.c: USB device 2 (vend/prod 0x3f0/0x121) is not claimed by any active driver. with 2.6 i get nothing and usb is running cause i can use my digital camera -- debian gnu/linux 19:07:24 up 20 min, 2 users, load average: 0.11, 0.34, 0.27 www.elwater.net ==== escribiÌ°å°Ì[Hyphen][A Ring]°Ì°å[Hyphen]Ì[Hyp hen]åÒ: with the 2.4, running a dmesg i get this usb.c: USB device 2 (vend/prod 0x3f0/0x121) is not claimed by any active driver. with 2.6 i get nothing and usb is running cause i can use my digital camera Did you load the usbserial & safe_serial modules, giving the vendor=0x3f0 product=0x121 parameters to usbserial ? You may always check in /proc/bus/usb/devices for usb devices (mount none /proc/bus/usb -t usbfs if there is no devices file) Samuel Thibault ==== > # modprobe safe_serial i can't load this module, where can i activate this module in my kernel connfiguration. I'm using a 2.4.22 kernel He is probably talking about 2.6.0-testX kernels .. -- 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 ... ==== that's my question. I think that 80k is not too much. It is possible to add another 128K (if you are an expert) the system supports 128K and 256K RAM Ask rcobo, Steve Sousa, etc for HW modifications 200K free sounds much better (for a lot of port 0 libs) ==== LOL! I AM getting old! I was so used to the HP-48 4-pin connector being different- I heard that the closest thing and it wasn't exactly the same was the 4-pin connector you find at the end of something like a floppy to a motherboard! I am very happy to hear that it is standard item that stores carry! > > >>If you can salvage the specialized 4 pin HP49G+ end of the cable, you >>can try to rewire it. But first I'd make sure the the pinouts, etc. are >>obtainable from HP or someone knowledgeable here about the signal and >>ground connections in such a new machine. You don't want to fry it. >> > > Actually, the HP49G+ cable is an absolutly STANDARD Mini USB cable. > The connector on the calcaultor is defined in the USB norm as mini USB and > was devised especially for small devices such as PDA and other... X This is a serious drawback from the old calculators There is no backwards compatibility anymore! AND the RAM cards are replaced by a single SD card which does not have a backup battery anymore! Oooh! All these drawbacks we have to withstand! Also note that the batteries are different from those that I'm used to: the 41CV had good batteries and used four of them Now where's the fourth battery? Did ALG eat it? Yes - there is that terrible ALG mode that now forces me to go back to my old dear 41CV again (where is it, I can only find an CX, which is ofcourse a newer dull model) It goes on: the [-] [+] [*] [/] keysa are now on the other side? (must be some sort of ALGebraic mode thing) AND they are in X<>Y ROT ROT order, why? ENTER? Where is the ENTER? OK - it's where the R/S used to be... The Stcak soen't seem to duplicate from the top of stack anymore I can't use this flaed machine. It doesn't even show the USER mode assignments when I press a key for a while neither does it say NULL if I keep on pressing. (/&%/&Û#Û There are no more numbered registers, but I used a vector to overcome this. Little odd to use, but I could get buy. Hmmm... I founf the SST, but no BST??? C'moon HP?! d-8 ==== You know why you post is precisely so funny? It is all too true! I myself looked for (h) BST! I looked for (g) ISG, DSE, ..., what's worse, I cannot suppress my mind calling out f (FIX ..., f [root]x, ...), or g (something) or h (or another)! Woe is me. I am undone. I can no longer calculate. Now where are my log tables?? I have been using the 32SII some years, now, but the 34C much longer, so even when I'm using the 32SII (which really in terms of function ISN'T that different from the higher end Spices) I still call out in my head, f... or g... or h... . Rats. This is like some tune you want to keep out of your head; it'll probably stay in my head all day... f... g... h... >LOL! I AM getting old! I was so used to the HP-48 4-pin connector >being different- I heard that the closest thing and it wasn't exactly >the same was the 4-pin connector you find at the end of something like a >floppy to a motherboard! > >I am very happy to hear that it is standard item that stores carry! > > > >> >> >> >>>If you can salvage the specialized 4 pin HP49G+ end of the cable, you >>>can try to rewire it. But first I'd make sure the the pinouts, etc. are >>>obtainable from HP or someone knowledgeable here about the signal and >>>ground connections in such a new machine. You don't want to fry it. >>> >>> >>Actually, the HP49G+ cable is an absolutly STANDARD Mini USB cable. >>The connector on the calcaultor is defined in the USB norm as mini USB >> and >>was devised especially for small devices such as PDA and other... >> X This is a serious drawback from the old calculators There is no backwards compatibility anymore! AND the RAM cards are replaced by a single SD card which does not have a backup battery anymore! Oooh! All these drawbacks we have to withstand! Also note that the batteries are different from those that I'm used to: the 41CV had good batteries and used four of them Now where's the fourth battery? Did ALG eat it? Yes - there is that terrible ALG mode that now forces me to go back to my old dear 41CV again (where is it, I can only find an CX, which is ofcourse a newer dull model) It goes on: the [-] [+] [*] [/] keysa are now on the other side? (must be some sort of ALGebraic mode thing) AND they are in X<>Y ROT ROT order, why? ENTER? Where is the ENTER? OK - it's where the R/S used to be... The Stcak soen't seem to duplicate from the top of stack anymore I can't use this flaed machine. It doesn't even show the USER mode assignments when I press a key for a while neither does it say NULL if I keep on pressing. (/&%/&Û#Û There are no more numbered registers, but I used a vector to overcome this. Little odd to use, but I could get buy. Hmmm... I founf the SST, but no BST??? C'moon HP?! d-8 ==== It goes on: the [-] [+] [*] [/] keysa are now on the other side? (must be some sort of ALGebraic mode thing) AND they are in X<>Y ROT ROT order, why? ENTER? Where is the ENTER? OK - it's where the R/S used to be... The Stcak soen't seem to duplicate from the top of stack anymore I can't use this flaed machine. It doesn't even show the USER mode assignments when I press a key for a while neither does it say NULL if I keep on pressing. (/&%/&Û#Û There are no more numbered registers, but I used a vector to overcome this. Little odd to use, but I could get buy. Hmmm... I founf the SST, but no BST??? C'moon HP?! d-8 Hey Veli-Pekka, post that in the Museum Forum and you'll probably find some who agree with every word of that. No kidding! -- James ==== | 5. 2. | | 1. 8. | I wonder: How to convert this matrix to: | 5 2 | | 1 8 | ? Hav tried tu use the R->I command, but it didn't work. ==== XQ | 5. 2. | | 1. 8. | I wonder: How to convert this matrix to: | 5 2 | | 1 8 | ? Hav tried tu use the R->I command, but it didn't work. ==== Veli-Pekka Nousiainen skrev i melding XQ about that in the manual that ships with the calculator (HP49G). I have downloaded the newest hp49g+ manual from the net, but haven't read it yet. ==== Apparently R->I works only on numbers not on matrices. Thus, the following program can take care of it: << -> M << M SIZE OBJ-> DROP * 1 SWAP FOR j M j GET R->I M SWAP j SWAP PUT 'M' STO NEXT M >> Store it into a variable name such as 'MR->I' (Matrix R->I), and you have a program that can transform your real-number matrix into integer matrix. To operate, type the matrix of real numbers, then press [VAR][MR->I], if in RPN mode. In ALG mode, type, for example, MR->I([[1.,2.],[3.,4.]), then [ENTER] (By the way, the program development is easier if done in RPN mode). To change modes: [MODE][+/-][ F6 ] Gilberto E. Urroz, Ph.D., P.E. Associate Professor Dept. of Civil & Envr. Engineering and Utah Water Research Laboratory Utah State University Logan, Utah 84322-4110 gurro@cc.usu.edu http://www.engineering.usu.edu/cee/faculty/gurro/ ==== > The only Prangeble answer I can give you is: > Upgrade to M$ Windows XP Pro Ditto ! > Veli-Pekka > PPS: I have a multi-biit PC with 98SE, W2K SP4, XP Pro SP1 > MSI 845E Max2 BLR (no bluetooth), 1.8GHz P4, 512MB DDR, > IBM 120GB HD, slow DVD+RW drive, DVD&CD/RW drive, FD*2 > All six USB ports used and when I try to use my Sony F520 as a hub > It will not work! How to connect a 49g+ to a monitor hub? Heh? I have Sony G220 and it works fine with it's USB hub ! with your 49g+ that is? ==== > I don't know if this has been solved yet, but try to COPY your file to > be transfered from an open window and then PASTE into the Conn4x > window. > It works for me. Conn4x and using the SD card and reader for file transfers instead. If and when I see a new version of the USB driver or Conn4x available, Ill try again with Conn4x. -- James ==== Kickaha ha scritto nel messaggio > I'd like to announce the release of the new version of the library in subj. ...(SNIP library description)... Still I didn't receive any comment or feedback on my library from who My HD was giving me big trouble (the transfer to a new HD is still in progress) fixed and I've added a couple of functionality and revised the readme accordingly. I think I'll be able to release the new version in the next week. I'll send it to who requested be version 1.1, mainly because the bugs in the previous so. version (which can, in one case, give bad results from computations). Kickaha -- Per rispondere rimuovere il SiPAriuM To reply remove the SiPAriuM PAriSiuM ? (from Uderzo & Goscinny, 1966: Ast.8erix et les Normands) The's Swedish/Norwegian people of the good old days (Before 41C eg. B41C) Much funnier is the Ast.8erix chez les Bretons ==== The fact that the 49G+ clock eats up batteries get me puzzled. I have a watch that needs a battery replacement every 3 to 4 years. That battery is only the size of a quarter. This watch is more than 10 make a calculator clock as efficient as that. By the way, this watch display is alweays on and show the year, month, day, day of the week, hours, minutes, seconds plus eigth icons to access the database, alarm, timer and stopwatch functions. It is too bad that HP stopped offering top machines after the 48 serie. I was always eager to jump on the latest HP model after buying a 45, 25, 41C, 41CV, 41CX, 48SX and 49G. I have a mixed feeling with the 49G. Good, solid feel, powerfull, some glare in the display but the keyboard slows me down. I prefer my 41CX or even my 45 for real fast number crunching. After reading quite a few posts on this news group I think I will pass on the 49G+ and wait until HP revert to the super efficient keyboard that was on the 41CX. The 48 serie was not too bad either. To make my point I timed myself with some equations solving and, on the average I take about 80% more time to finish with the 49G. Of course, today I do most of my math with MathCAD or Excel but I still want the fastest and most efficient tool. The HP49 serie is not that tool, presently. I post mostly in hope that HP people read these and take note of our feeling. Jean (Johnny) Lemire from Montreal, Quebec, Canada ==== Interestingly, I notice even with the clock on its NOT flickering in EQW mode. Bizarre. Rom1.22, btw. A. Arabian > what kind of level of complaining do we need > to obtain in order for HP to address the lcd > flickering problem some of us are having ... > > You can solve the problem yourself by turning off the on-screen > clock. > That'll also make your batteries last a lot longer. > > -Joe- i turned my clock off and it stopped blinking. then i pressed -> + EQW, and it starting blinking again. only faster. gc ==== Can someone explain why telephones (touch tone) have the following layout: 1 2 3 4 5 6 7 8 9 0 While calculators and numeric keypads on computers keyboards have: 7 8 9 4 5 6 1 2 3 0 Why not use the same on both ? Of course I am just talking about numeric keys. Jean (Johnny) Lemire from Richelieu, Quebec, Canada. ==== > > Can someone explain why telephones (touch tone) have the following layout: > > 1 2 3 > 4 5 6 > 7 8 9 > 0 > > While calculators and numeric keypads on computers keyboards have: > > 7 8 9 > 4 5 6 > 1 2 3 > 0 > > Why not use the same on both ? > > Of course I am just talking about numeric keys. > > Jean (Johnny) Lemire from Richelieu, Quebec, Canada. Because the phone company is out to get me. They're trying to force me to look at each key as I punch in the number on any non-rotary phone, and when I don't they get to send a very unpleasant screech and nasty message through my left ear straight into my brain. That's why I still keep a rotary dial phone handy for when I want to dial without looking. I sure hope that this post slips past them without being noticed. On the other hand, maybe they just want me to think that they're out to get me, and really don't care a bit about me; I sure hope so; that would be a load off of my mind. But I sure hope that that nasty screech isn't really an encrypted brain virus. Now where did I leave my meds.... Watch out! They're really out to get everyone, especially those crazy people who don't even recognize the danger! Now where did I...well, I know I was looking for....something.... -- James (don't call me Jimmy) M. Prange from China Township, Michigan, U.S.A. ==== Can someone explain why telephones (touch tone) have the following layout: ... While calculators and numeric keypads on computers keyboards have: ... No (:-). More relevantly, the calculator keyboard layout came from the adding machine line, which BTW is zero-based. (I.e., the numbers run from 0 to 9 and the 0 is near the 1.) These evolved over time. (duh!), which is the product of extensive research by lots of quite intelligent people who put a lot of thought into it and felt that adding machines -- which had predated digit telephony by at least 50 years -- were not a good place to emulate. Their view was no doubt affected by the fact that they were numbering from 1 to 10 (!), hence they wanted the 0 to be next to the 9. Yes, the 0 on a telephone dial nominally corresponds to 10 as signalling zero pulses is problematic: the 0 on a dial telephone causes 10 pulses to be sent. Fortunately, humans are adaptable to stupid designs. Unfortunately, humans are adaptable to stupid designs (:-). If not for the latter, we would have a lot fewer stupid designs. Craig ==== Any sightings in office supply stores like Staples, OfficeMax, or other chain stores? (I don't live near a Fry's, *sniff*) Would prefer to buy locally, just in case. ==== I notice that the red IR cover on the 49G+ has a convex outer surface. Would this have the effect of spreading the IR beam, thus attenuating it and shortening its range? An interesting experiment would be to compare performance with & without the IR cover. Might a deliberately reduced IR range be an effort to regain acceptance for use in professional exams? Just wondering . . . ==== c. Printer errors ? probably due to an increase in IR output speed due to the faster processor? Could be fixed by adding printer delay using the DELAY command? On my 49G+, I found a DELAY of 1.8 works well with my 82240B IR printer. Tom Scott ==== >>c. Printer errors ? probably due to an increase in IR output speed due >>to the faster processor? Could be fixed by adding printer delay using >>the DELAY command? The printer expects a fixed transmission speed of 2400 bits per second. At that speed, even the 48SX manages to send faster than the printer can actually print. Well, except when printing graphics, which requires something like 7 times more bytes per full line than printing in text mode. That does cause a noticeable delay before each line while the printer waits for the data and the control code to tell it to print out everything that it's accumulated in its buffer, even if I use 0 for the delay value. In this case, the I/O annunciator is on steady from start to finish, no flickering at all, so I surmise that the delay is caused purely by the 2400 bps transmission speed. > On my 49G+, I found a DELAY of 1.8 works well with my 82240B IR printer. But how close to the printer does the calculator have to be? The best delay value depends on how long it takes the printer to complete each line, which in turn depends mostly on the battery condition and whether an external power supply is in use, but partly on what's being printed and even partly on the temperature and the darkness setting. Using an external power source, I find that a DELAY of about 1.1 works quite well. With batteries only, as the batteries get low, it may indeed be necessary to increase this to about 1.8 (the default on the old 48 series) or even higher. The delay doesn't come into play until 200 bytes have been sent out, because that's the size of the printer's buffer, and the calculator assumes that the buffer is empty when it starts sending to the printer. After that the calculator pauses the transmission after each end-of-line control code by the number of seconds that the delay parameter in PRTPAR calls for. So for short print jobs (200 bytes or less), the delay value doesn't make any difference. That's how it works on the older calculators, but I notice that the 49g+ sometimes delays, and then prints 2 lines with no delay between them. Maybe it has an improved algorithm for deciding how many lines and bytes it can safely send before the next delay. By the way, PRLCD starts out ok, but after it's printed an image of all 80 pixel rows correctly, it starts printing out a pattern of nonsense text after that. Same if I do LCD-> PR1. It prints other grobs ok. But now PRLCD seems to be fine. It seems that it must be one of those flakey now-you-see-it, now-you-don't problems. -- James ==== For these main reasons it would have been better to have named this model the 49GII and the 49G+ should have been called the 49GII+. Leave it to the marketing boneheads. You mean 49GX or 49gx+ eXpandable, you know? ==== The specs indicate that the 48GII should be able to transfer data with the 49s using the IR port. You would not be able to do it using the serial ports since the 48GII uses an RS-232 port while the 49s use USB. I have successfully transferred my FINLIB49 from a 49g+ to a 48gII The IR signal strength of the 48GII has been greately reduced. I can't get it to work with HP's own IR printer (82240B) outside of a few inches. Because of this, I doubt that it would work very well in this application. Right - it prints (only) from close range ok ==== X 1. Speaker volume is softer in the 48GII. Although fine in a quiet environment, it is very hard to hear when using the unit in real world applications. Should have been made louder than the 48G+ or (even better) variable volume. Agree. A real stereo load-speaker system would be perfect! 2. IR range has been reduced. IR communications are now limited to only a few inches (from around 18 in the 48G+). Agree - variable power (batteries) would be nice.... 3. Analog clock - this has to be a joke? If you want a good laugh, give it a try. 4. Intermittent Menu flashes are distracting. 5. Manual errors/omissions. a. Chapter 26 - This appears to be the documentation for a different product (probably the 49?). b. No documentation on flag functionality - Approximately 60 system flags have been added without any documentation on functionality. The Ugly: 1. The new fonts. Very hard to read in small sizes and in some instances do not reflect the original character at all. Try turning the # character into a graphic object using GROB with size 1. You will get something that looks like a not-equal sign. Some of the numeric characters fonts are also very difficult to read. Use bigger than minifont. FONT7 seems to be good. Is that size 2 for ->GROB? 2. Keys. Very bad. Although I cannot remember a single missed key stroke on our baseline 48G in almost 10 years of use, missed key strokes occur on the 48GII on such a regular basis it would be hard to use as a calculator (we use it as a programmable controller so it is not much of an issue for us). I have tried 5 different units - all exhibit the problem. Return them - explaining the problem - and get a new bunch 3. Compatibility Issues. Why, why, why? This unit should run 48G code straight out of the box - without modification - PERIOD. Think -- very large installed software base. I'm all for progress and added functionality but the baseline configuration (from the factory) should be compatible with the 48G code. All non-compatible added functionality should be enabled via system flags. Here are some of the issues I have run into so far: It runs all the UserRPL programs in Approx Mode (RPN) un-modified. SysRPL users/programmers need to use the new Debug4 to do software for both platforms (old 48-series and the new calcs) a. IR compatibility. Basically it doesn't appear as though you will be communicating with any existing 48G, 48G+ or 48GX. This is odd since they did decide to keep the existing IR transmission protocol which allows it to continue to communicate with the 82240B printer. The IRDA is fine, but the legacy IR receiving protocol should have been included also for compatibility sake. b. Algebraic mode is factory default (not PRN). This, of course, is just plain backwards for compatibility. c. Printer errors - probably due to an increase in IR output speed due to the faster processor? Could be fixed by adding printer delay using the DELAY command? Change speed from 115,200 to lower, like 9600 c. Key mapping - if you used many KEY command in your code get ready for some work. Most of the key locations have changed. A need for KEYSTR is imminent: The command would return A to Z and then *, -, +, ENTER, , ., ON, RS, LS, ALPHA (and naturally 0 to 9, plus the LA, UA, RA, DQ for arrow keys) Anyone to program this to work the same way regardless of the used calc (48S/48G/49-series) Maybe Wolfgang? d. Real numbers are now displayed with decimal points when operating in standard numeric mode. Although still logically correct, this affects precisely formatted field output to the screen or printer. e. The default font size for Choose boxes has been changed to MINI (from normal size on the 48G+). f. Symbolic representation rules have changed. For example, the factory result for the program <<1 TAN >> on the 48G (factory default) was 1.7455E-2. Running the same program with factory default settings on the 48GII returns TAN(1). Use Approx.(~) mode g. RS-232 communication problems - Cannot communicate with several RS-232 devices that worked fine with the 48G+. Use 9600 for speed (instead of 115,200) h. Cannot seem to load library routines written for the 48G+ onto the 48GII from a PC. Certainly not. The system HAD to change, so the entry points moved. You need to re-compile the source code ==== > 1. Speaker volume is softer in the 48GII. Although fine in a > quiet environment, it is very hard to hear when using the unit in real > world applications. Should have been made louder than the 48G+ or > (even better) variable volume. Agree. A real stereo load-speaker system would be perfect! If you can't hear the unit in real world applications it becomes useless for those applications. > The Ugly: > 1. The new fonts. Very hard to read in small sizes and in some > instances do not reflect the original character at all. Try turning > the # character into a graphic object using GROB with size 1. You > will get something that looks like a not-equal sign. Some of the > numeric characters fonts are also very difficult to read. Use bigger than minifont. FONT7 seems to be good. Is that size 2 for ->GROB? Problem is that existing code has to be re-written and distributed. > 2. Keys. Very bad. Although I cannot remember a single missed > key stroke on our baseline 48G in almost 10 years of use, missed key > strokes occur on the 48GII on such a regular basis it would be hard to > use as a calculator (we use it as a programmable controller so it is > not much of an issue for us). I have tried 5 different units - all > exhibit the problem. Return them - explaining the problem - and get a new bunch Check out the other threads on this issue. What makes you think another batch is going to be any better. This is plain and simple - bad engineering and/or bad manufacturing. They need to get a handle on this one quickly. > 3. Compatibility Issues. Why, why, why? This unit should run > 48G code straight out of the box - without modification - PERIOD. > Think -- very large installed software base. I'm all for progress and > added functionality but the baseline configuration (from the factory) > should be compatible with the 48G code. All non-compatible added > functionality should be enabled via system flags. Here are some of > the issues I have run into so far: It runs all the UserRPL programs in Approx Mode (RPN) un-modified. SysRPL users/programmers need to use the new Debug4 to do software for both platforms (old 48-series and the new calcs) > a. IR compatibility. Basically it doesn't appear as though > you will be communicating with any existing 48G, 48G+ or 48GX. This > is odd since they did decide to keep the existing IR transmission > protocol which allows it to continue to communicate with the 82240B > printer. The IRDA is fine, but the legacy IR receiving protocol > should have been included also for compatibility sake. > b. Algebraic mode is factory default (not PRN). This, of > course, is just plain backwards for compatibility. > c. Printer errors - probably due to an increase in IR output speed due > to the faster processor? Could be fixed by adding printer delay using > the DELAY command? Change speed from 115,200 to lower, like 9600 It is running at 9600 baud. > f. Symbolic representation rules have changed. For example, > the factory result for the program <<1 TAN >> on the 48G (factory > default) was 1.7455E-2. Running the same program with factory default > settings on the 48GII returns TAN(1). Use Approx.(~) mode I may have used a bad example. Approx mode does not fix. The problem stems from differences in the way the 48G handles symbolic constants vs. the way they are handled in the 48GII (due to the settings of flags 2 and 3). Just another incompatibility. > g. RS-232 communication problems - Cannot communicate with > several RS-232 devices that worked fine with the 48G+. Use 9600 for speed (instead of 115,200) We do use 9600 baud. I have since discovered the problem and have posted it to the RS-232 discussion threads. > h. Cannot seem to load library routines written for the 48G+ > onto the 48GII from a PC. Certainly not. The system HAD to change, so the entry points moved. You need to re-compile the source code The system did not HAVE to change. It worked great before. This was a decision (and a bad one) on HPs part. Bob ==== Just wanted to clear up some confusion going on in this thread regarding the serial port of the 48GII. When we talk about a custom 48GII HP cable we are talking about a cable with active electrical elements integrated beneath the connector hood. We are not talking about a simple proprietary connector scheme that some of the PDA use on their serial ports. Nor are we talking about a cable that could be easily built in your average home office. Although it would be possible to build one yourself, it would not be practical since there are 18 components required for the voltage level conversion circuitry. The HP-48GII (and all previous models 48G, 48G+, 48GX) DOES conform to the proper voltage levels of the RS-232 specification on both the drivers as well as the receivers. The cable connector is non-(de-facto)-standard but there are commercially available cables which have a 9-pin D-sub connector for the previous models (the 48GII comes with this a custom cable for this purpose). CPUs do not conform to the RS-232 standard since they lack the proper voltage levels to drive the cable. Most CPU contains a UART that handles the RS-232 protocol. The voltage level conversion is left to the system designer to handle outside of the CPU. Nowadays, this is almost always done using a charge pump IC that doubles the system voltage. This allows the proper RS-232 voltage levels to be generated from any 5 volt or 3.3 volt system without the additional cost of custom power supply circuitry. The voltage level used by the host system has nothing to do with RS-232 compatibility. HP has (for whatever reason) chosen to put this circuitry in the cable they supply with the unit. All would be well and fine (at least with me) if they had chosen to power the circuitry. Instead they use the RS-232 signals DTR or RTS (either will work) of the terminal device to power the cable circuitry. These signals are on pins 4 and 7 of the D-sub connector. All should work fine as long as you are connecting your HP to a PC (using proper driver software to toggle these modem control signals to the proper level). Try using almost any other 232 device and you are almost certainly out of luck. We used to use the HPs as portable instrument controllers and have used the RS-232 ports to control and communicate with any number of RS-232 devices. This will probably no longer be possible with the 48GII. I have heard some speculate that this was done for power reasons. (similar to the Maxium 3221E). This IC draws only 1 uA of current when not in use (and this is with the receivers active ö which could support a wakeup feature). I have also seen it noted that it might have been done for some sort of protection. Why would it matter where the transceiver were located if this was the case? The pins to the printed circuit card are still present on the back of the unit. The unit is much more likely to be damaged by ESD by not including the transceiver in the unit itself since there is a much more direct shot at the processor without the protection circuitry the transceiver provide. By the way, the SP3220E's ESD tolerance is over +- 15kV for both Human Body Model and IEC1000-4-2 Air discharge test methods. RS-232 devices do not typically destroy each other. The RS-232 specifications require that the transceivers are practically bullet-proof. You should be able to power the cable yourself by supplying 5V DC to either pin 4 or 7. I can't read the part number on the voltage regulator so I am not sure how low (or how high) you can go on this voltage. ==== 1. Is HP going even more proprietary than it has in the past i.e during the days of the HP41 series? HP-IL etc. The kulge with the cable for the 48gII. One now can not just build their own ant longer. Are they going to come out with an expensive HP only accessory to accomplish what is missing? Actually, this is a pretty common practice (the 2 PDA I have with RS232 cable do that) All CPU and similar that you can see around and that claim to 'support' RS232 in fact support the protocol, but not the signal strenght (they work in 0/3.3 v only, which is not a normal RS232 level, but much easier to acheive on a 3.3V powered IC. Moving the RS232 adaptor chip (that uses quite a lot of power) in the cable and powering it from the PC is common practice (this is BTW the way your mouse gets powered) and saves a lot of power from the device. Also, doing so allows to reduce risks of destruction of the final device (cable is cheaper than the calc). BTW, you should be able to connect 2 calcs with the RS232 using a hand made cable without any electronics in it. You might even discover that you can connect with a lot of devices without the adaptor circuitry... However, this is not the RS232 standard. 2. The fact that the 49G+ can only be a USB client and not a USB server that according to some knowledgeable people who contribute to the discussions on this group, the hardware is available to have two USB ports on the calculator. Again is an expensive HP only accessory in the wings that allows two way USB communications for the 49G+?. Ok, let us speculate that there is a USB host on the HP49G+: - Where does the power come from? remember, USB is suposed to provide up to 500mA for the periferials. at 800mAH of power on a standard AAA, how long will the calcualtor battery last? - Where does the drivers come from? USB clients need drivers to be installed on the calcaultor in order to work. I imagine that HP will have NO problems whatsoever to get EVERY USB device manufacturer to create the drivers for the HP49G+ calcualtor! After all, aren't they all already doing Windows, Mac drivers? ==== > 1. Is HP going even more proprietary than it has in the past i.e > during the days of the HP41 series? HP-IL etc. > The kulge with the cable for the 48gII. One now can not just build > their own ant longer. Are they going to come out with an expensive HP > only accessory to accomplish what is missing? Actually, this is a pretty common practice (the 2 PDA I have with RS232 cable do that) Actually, this is not a common practice at all. Could it be that two RS-232 devices do it - sure but keep in mind that there are literally thousands that don't do it. By the way I checked the 5 different serial PDAs we use - none of them do it. It violates the RS-232 standard and makes the device non-compatible with many different devices (of course if all you want to do is to connect to a PC - it should be fine) All CPU and similar that you can see around and that claim to 'support' RS232 in fact support the protocol, but not the signal strenght (they work in 0/3.3 v only, which is not a normal RS232 level, but much easier to acheive on a 3.3V powered IC. We are not talking about a CPU, we are talking about an assembly that claims support for the standard (at least they used to - I'm not sure what their official stance is now). Not sure what devices do this. Any device that used a 3.3 V RS-232 would be quickly fried when connected to a true RS-232 device (which would include a standard PC). Moving the RS232 adaptor chip (that uses quite a lot of power) in the cable and powering it from the PC is common practice (this is BTW the way your mouse gets powered) and saves a lot of power from the device. Also, doing so allows to reduce risks of destruction of the final device (cable is cheaper than the calc). The RS-232 adapter uses almost no power (only 1 uA) when not operating. Check the quiescent current draw of the static RAM. Of course the mouse gets its power from the PC but it is not a RS-232 device (nor does it claim to be). This is why you have a special mouse port on your PC (or why you use the USB which does supply power to it's devices). What risks of destruction? (see my follow-up post). BTW, you should be able to connect 2 calcs with the RS232 using a hand made cable without any electronics in it. You might even discover that you can connect with a lot of devices without the adaptor circuitry... However, this is not the RS232 standard. I would not suggest this unless you are ready to replace your 48GII. RS-232 voltages can (and do) swing +/-15 VDC. This would quickly fry your unit without the RS-232 protection circuitry the cable provides. > 2. The fact that the 49G+ can only be a USB client and not a > USB server that according to some knowledgeable people who contribute > to the discussions on this group, the hardware is available to have > two USB ports on the calculator. Again is an expensive HP only > accessory in the wings that allows two way USB communications for the > 49G+?. Two way USB communication is already possible. The issue is who initiates the transfer? Ok, let us speculate that there is a USB host on the HP49G+: - Where does the power come from? remember, USB is suposed to provide up to 500mA for the periferials. at 800mAH of power on a standard AAA, how long will the calcualtor battery last? About an hour and a half. USB devices are also allowed to power themselves. I would imagine that if you choose to connect a USB device that draws 500mA you would probably want it to be powered via an external source. - Where does the drivers come from? USB clients need drivers to be installed on the calcaultor in order to work. I imagine that HP will have NO problems whatsoever to get EVERY USB device manufacturer to create the drivers for the HP49G+ calcualtor! After all, aren't they all already doing Windows, Mac drivers? I guess it would be up to them but why prevent them if they wanted to? ==== > 1. Is HP going even more proprietary than it has in the past i.e > during the days of the HP41 series? HP-IL etc. > The kulge with the cable for the 48gII. One now can not just build > their own ant longer. Are they going to come out with an expensive HP > only accessory to accomplish what is missing? Actually, this is a pretty common practice (the 2 PDA I have with RS232 cable do that) All CPU and similar that you can see around and that claim to 'support' RS232 in fact support the protocol, but not the signal strenght (they work in 0/3.3 v only, which is not a normal RS232 level, but much easier to acheive on a 3.3V powered IC. Moving the RS232 adaptor chip (that uses quite a lot of power) in the cable and powering it from the PC is common practice (this is BTW the way your mouse gets powered) and saves a lot of power from the device. Also, doing so allows to reduce risks of destruction of the final device (cable is cheaper than the calc). BTW, you should be able to connect 2 calcs with the RS232 using a hand made cable without any electronics in it. You might even discover that you can connect with a lot of devices without the adaptor circuitry... However, this is not the RS232 standard. > 2. The fact that the 49G+ can only be a USB client and not a > USB server that according to some knowledgeable people who contribute > to the discussions on this group, the hardware is available to have > two USB ports on the calculator. Again is an expensive HP only > accessory in the wings that allows two way USB communications for the > 49G+?. Ok, let us speculate that there is a USB host on the HP49G+: - Where does the power come from? remember, USB is suposed to provide up to 500mA for the periferials. at 800mAH of power on a standard AAA, how long will the calcualtor battery last? - Where does the drivers come from? USB clients need drivers to be installed on the calcaultor in order to work. I imagine that HP will have NO problems whatsoever to get EVERY USB device manufacturer to create the drivers for the HP49G+ calcualtor! After all, aren't they all already doing Windows, Mac drivers? That is why I am thinking a UBS port on the 49G+ my not be all it is cracked up to be. I am getting a sinking feeling that maybe it was not such if a good idea ta abandon wire RS-232 transfer capability. We use both Vernier ULI boxes(for our in lab PCs), and LabPros for portable applications. I hate to have to tell my students that only a TI calculator will work with them.( LabPro) I really leaves a bad taste in my mouth not to be able to say HP's will work too. Harold A. Climer Dept.Of Physics,Geology,and Astronomy University of Tennessee at Chattanooga Chattanooga TN USA 37403 ==== > 1. Is HP going even more proprietary than it has in the past i.e > during the days of the HP41 series? HP-IL etc. > The kulge with the cable for the 48gII. One now can not just build > their own ant longer. Are they going to come out with an expensive HP > only accessory to accomplish what is missing? Actually, this is a pretty common practice (the 2 PDA I have with RS232 cable do that) All CPU and similar that you can see around and that claim to 'support' RS232 in fact support the protocol, but not the signal strenght (they work in 0/3.3 v only, which is not a normal RS232 level, but much easier to acheive on a 3.3V powered IC. Moving the RS232 adaptor chip (that uses quite a lot of power) in the cable and powering it from the PC is common practice (this is BTW the way your mouse gets powered) and saves a lot of power from the device. Also, doing so allows to reduce risks of destruction of the final device (cable is cheaper than the calc). BTW, you should be able to connect 2 calcs with the RS232 using a hand made cable without any electronics in it. You might even discover that you can connect with a lot of devices without the adaptor circuitry... However, this is not the RS232 standard. > 2. The fact that the 49G+ can only be a USB client and not a > USB server that according to some knowledgeable people who contribute > to the discussions on this group, the hardware is available to have > two USB ports on the calculator. Again is an expensive HP only > accessory in the wings that allows two way USB communications for the > 49G+?. Ok, let us speculate that there is a USB host on the HP49G+: - Where does the power come from? remember, USB is suposed to provide up to 500mA for the periferials. at 800mAH of power on a standard AAA, how long will the calcualtor battery last? - Where does the drivers come from? USB clients need drivers to be installed on the calcaultor in order to work. I imagine that HP will have NO problems whatsoever to get EVERY USB device manufacturer to create the drivers for the HP49G+ calcualtor! After all, aren't they all already doing Windows, Mac claculator drivers? OK, CdB! You're right about the different drivers for all the different devices No USB host then. How about a cable to connect the 49g+ to an RS-232C port then? Working with BOTH USB 1.1 and 0..3.3V serial would be great!! PS: The batteries will last 1_h ? ==== Unfortunately for small engineering and surveying firms the GX was a perfect solution for collecting,analysing, and storing data and then downloading it to a PC in the office. The new data loggers now available are much as 40 times as expensive as a GX. Now HP has given these small companies no upgrade route for the discontinued GX, GENE: You can't always upgrade from an old model. HP25 programs wouldn't run unless translated to HP67 programming language, for example. Surveying software will make its way to the 49G+...give it at least a few months! I know of one vendor who plans surveying software for $100 for the 49G+. Since the HP48GX is/has been discontinued because of CPU shortages (if the rumors are true), then the surveyors would have to change machines anyway. Companies ( like the one my brother works for) work on very small margins, and can not afford lots of new wis-bang equipment every year and still remain competitive with larger rivals. HP has forgotten who their core customers really are IMHO. At least the HP I have know for the last 30 years. It is really a shame that marketers have taken over the world. Harold A. Climer GENE: I don't believe HP's Core customers make up enough of a market by themselves to warrant building a calculator just for it. How many surveyors use HP calculators? 10,000? 50,000? I don't believe it would make business sense to make a model for a group that small. If it DID make sense, another company would jump in and take those profits for themselves. The 49G+ will have surveying software - give it a chance to be on the market long enough! The 49G+ has the ability to capture and store data for retrieval back on a PC through the SD card. These models are only the beginning too. Keep that in mind. Gene P.S. And, 48GX's are still to be found for people that really want them. ==== > > >>1. Is HP going even more proprietary than it >>has in the past i.e during the days of the >>HP41 series? HP-IL etc. > > > In my personal opinion, no, and in fact quite the opposite. Back > then, almost everything was proprietary; now we have lots of industry > standard and off-the-shelf partsm e.g. the ARM9 CPU, a USB port, SD > memory cards, and more-easily obtained batteries. Nothing to sneeze > at! All good points, and apparently they do bring the cost down considerably. I'd almost forgotten the problems with finding fresh N cells for the 28 series, and of course many earlier calculators required calculator model specific battery packs. I suppose that almost everyone has AAA cells on the shelf at home, and the CR2032 cell is commonly used and easy to find. I hope that the calculators manage the power so that they draw from the CR2032 only when they're off and the AAA cells are missing or too low to supply sufficient power to retain memory. The relatively cheap and widely available SD cards for expansion are especially welcome. Of course, when the earlier calculators were developed, perhaps suitable industry standard and off-the-shelf components and accessories simply weren't available. HP calculators really did invent new things back then. But why not keep the industry standard RS-232? Was there any real need to invent some new incarnation of RS-232 specific to the 48gII? Or to eliminate RS-232 from the 49g+? >>The kulge with the cable for the 48gII. One >>now can not just build their own ant longer. > > > Why not? I'm sure that, given sufficient information, one could. But perhaps not as easily and cheaply as with previous 48 series calculators. >>Are they going to come out with an expensive HP >>only accessory to accomplish what is missing? > > > Are you referring to the overhead-projector LCD panel, which requires > the same 10-pin serial port that is in the 38G, 39G, 40G and 49G? I'm glad that you mentioned that. How do we use one of those with the 49g+ or 48gII? Of course, besides the connection issue, with the 49g+, there's also the difference in pixel rows. Although the display panels are impressive and no doubt could be very useful, I wonder how many were ever made or used. I have a 3rd party display magnifier from Firmware Corp. that I noticed cheap on eBay. It uses a 48SX display and a big lens and plugs into an expansion slot on the 48SX or 48GX. Pretty nice, although for me, it's more of a nifty gadget than something that I actually have much practical use for. I still haven't gotten around to making the cable to connect it to the 49G. I wonder whether HP will market something similar for the new calculators. >>2. The fact that the 49G+ can only be a USB >>client and not a USB server ... > > > Same as your digital camera, MP3 player, and most other USB devices, > right? The reason that USB was included was to let the user upload > and download to/from a computer. All you need for that is Xmodem > Server mode. Making the 49g+ a USB controller would have taken more > hardware & software than could fit into the projected price point. I applaud adding the USB client port (although I do wish that the USB driver and Conn4x combination worked with my PC), but I think that not also keeping the RS-232 port was a mistake. Uploading to and downloading from a computer isn't the only thing that RS-232 on the old 48 series is used for. USB is great for connecting to a suitably equipped PC, but not for connecting to other devices. I know very little about how USB actually works; it's much like magic to me. But I suppose that it should be possible to build an accessory that's a USB host with the hardware and firmware/software for communicating with the 49g+ on one port, and has an RS-232 port for communicating with other devices. I don't know how big such a device would be, but I'd expect that handheld-sized should be feasible. Heck, with the miniaturization now-a-days, maybe it could fit into a cable connector. Taking that a bit farther, it could also have additional USB ports for communicating with other USB devices. Perhaps sort of a highly specialized miniature computer for communicating between a variety of USB devices. For that, we'd have to also have a way to add additional drivers, but with solid state flash memory, it should be feasible. Why not an IrDA port while we're at it? One that supports serial IR for communicating with the 48 series and other legacy devices. > How much extra would you be willing to pay for the 49g+ to be capable > of being a USB controller? Even more importantly, can you guarantee > that all other hp49g+ buyers would be happy to pay the same higher > price that you're eager to pay? Personally, I wouldn't pay much, if any, extra for a USB host port on a calculator, simply because I don't have any USB devices that I'd want to control from a calculator. But I certainly wouldn't rule out the possibility that others may have USB devices that they'd like to control from a calculator, or that I may have one in the future. > Anyhow, it won't be long before somebody develops a cable that plugs > into the SD card slot and connects to external devices. That's also > industry standard, and capable of robust I/O. An interesting idea, and yet another area that I'm ignorant in (there seem to be more such areas every day). Certainly it should be possible to build something that looks to the 49g+ just like an SD card. Maybe a sort of shared memory area that the 49g+ and some other device can each read from and write to. But I wonder about negotiating which device is writing. Certainly you wouldn't want the 49g+ to be writing to (or even reading from) this shared memory area while the other device is writing (or reading), and vice versa, and there may be a need to signal that the contents have changed, so it's necessary to read them again. >>is an expensive HP only accessory in the wings >>that allows two way USB communications for the >>49G+?. > > > It's already capable of that. Being only a USB client makes it > already capable of 2-way communication... also knows as I/O. Yes, certainly it's capable of 2-way communication, but perhaps not quite as simply as RS-232. Maybe I have some misconceptions about USB, but doesn't the host have to initiate any conversations? So, if the host wants to send something to a device, it says, Hey, pay attention and get ready for this! or asks Are you ready for this?. But if the device wants to say something to the host, it has to wait for the host to get around to asking Do you have anything to say?. So, if I have it straight, any 2-way communication is dependent on the device being connected to a host that understands how to communicate with that particular device. So for two USB devices to communicate with each other, they'd both have to be connected to the same USB host which knows how to communicate with each of them, if I understand correctly. No direct communication between devices, only via a host acting as an intermediary. Of course RS-232 also depends on the devices knowing how to communicate with each other. Whether to use other hardware signals besides the transmit and receive data signals, and if so, how. The speed, number of start bits, data bits, and stop bits, the parity (or pseudo-parity), if any. Whether to send and pay attention to XON/XOFF or other control codes. Whether flow control is even possible and if so, which method to use. Whether to use full duplex or half duplex. When to talk and when to listen. Whether a file transfer protocol such as Kermit or Xmodem is expected. Any special conventions for encoding and decoding control codes or non-ASCII characters embedded within the data. And no doubt a few other minor details that could frustrate me at times. But to me, it seems so much simpler, and, in my opinion, a lot closer to being industry standard than USB. -- James ==== But why not keep the industry standard RS-232? Was there any real need to invent some new incarnation of RS-232 specific to the 48gII? Or to eliminate RS-232 from the 49g+? sentence. The PC of the future doesn't have serial ports and a far bigger group of users will connect 49g+ to PCs than anything else. No one has mentioned using a PDA as a serial collection device - they are cheap, programmable in high-level languages, and have lots of memory, etc. compared to HP calculators - why not use a PDA? Pete M. Wilson Gamewood, Inc. wilsonpm@gamewood.net ==== > >> For connecting two calculators, IR may be ok. *If* it actually works. I >> notice that the signal to the 82240 printers is much weaker than it is >> in the previous calculators, and I haven't figured out a way to >> communicate with a 48SX or 48GX in Serial IR mode. Does anyone know >> whether the IrDA on the 49g+ actually works? > > > USB does not work on my PC running win98, so I regulary use IrDA for > transfers - it appears as a virtual COM port under '98, and works fine > with the old software. use the same software that I use with the other calculators then? Does the Kermit protocol (especially ASCII mode) still work on the 49g+? What about the serial I/O commands such as XMIT and SRECV? About what range does the IrDA have? Maybe an IrDA to RS-232 converter will also work for other devices, provided that they can supply the power or it's battery powered. I know that they're available; does anyone have any experience with them? Still, I'm curious as to why my 49g+ has such a short range to the 82240 printers. Do I have a defective unit (external serial CN331..., internal serial CN337...), or are they all like this? What about printing to IrDA printers? Seeing that the 49g+ does print to the 82240 printers, I surmise that it's using the Red Eye format for printing via IR; is there a way to make it use the IrDA format? And what about communicating with the old 48 series via serial IR? Is there a way to make the 49g+ use Serial IR? I notice that APPS I/o functions.. shows me Send to HP 49/48GII and Get from HP 49/48GII. I wonder what the deal is with those? Maybe they plan on making a special accessory for communicating with RS-232 devices? On the other hand maybe the 49 part refers to the 49g+, and it means via IrDA. -- James ==== use the same software that I use with the other calculators then? Well, if you are running win98, then yes. WinXP does not have support for a 'virtual COM port' using IR! There may be third party drivers, but I haven't found any. Does the Kermit protocol (especially ASCII mode) still work on the 49g+? Yes What about the serial I/O commands such as XMIT and SRECV? Yes, it acts just lioke it was attached via a serial port About what range does the IrDA have? The range is quite short - maybe less then a foot. Keep in mind I am usung a dodgey home made IrDA adaptor, so that may be the reason. Maybe an IrDA to RS-232 converter will also work for other devices, provided that they can supply the power or it's battery powered. I know that they're available; does anyone have any experience with them? No, but I'd imagine they would work fine. Still, I'm curious as to why my 49g+ has such a short range to the 82240 printers. Do I have a defective unit (external serial CN331..., internal serial CN337...), or are they all like this? I have an ext serial number CN331... as well, so I can't answer that. What about printing to IrDA printers? Seeing that the 49g+ does print to the 82240 printers, I surmise that it's using the Red Eye format for printing via IR; is there a way to make it use the IrDA format? No idea. And what about communicating with the old 48 series via serial IR? Is there a way to make the 49g+ use Serial IR? I remember hearing somewhere that this isn't possible, for both software and hardware reasons. later, Al ==== >> use the same software that I use with the other calculators then? > > > Well, if you are running win98, then yes. WinXP does not have support > for a 'virtual COM port' using IR! There may be third party drivers, but > I haven't found any. Well, that's real encouraging. If I were to upgrade from 98SE to XP, I might be able to use Conn4x, but would eliminate a chance to add an IR device that I can treat as a COM port. I wonder whether I'd lose my USB to RS-232 converter, and just what other improvements XP makes. Maybe with JP Software's 4NT.... >> Does >> the Kermit protocol (especially ASCII mode) still work on the 49g+? > > > Yes > >> What >> about the serial I/O commands such as XMIT and SRECV? > > > Yes, it acts just lioke it was attached via a serial port Definitely good news there. > About what range > >> does the IrDA have? > > > The range is quite short - maybe less then a foot. Keep in mind I am > usung a dodgey home made IrDA adaptor, so that may be the reason. Well, a bit disappointing, but better than nothing. Maybe someone else can contribute information on this? >> Maybe an IrDA to RS-232 converter will also work for other devices, >> provided that they can supply the power or it's battery powered. I know >> that they're available; does anyone have any experience with them? > > > No, but I'd imagine they would work fine. That's what I'd expect too. What I particularly wonder about is whether they can draw whatever power they need from the transmit and receive data lines, or do they need some other power source? I suppose that the information is available online, but I was hoping that someone in the newsgroup would have experience with one and share his experience. >> Still, I'm curious as to why my 49g+ has such a short range to the 82240 >> printers. Do I have a defective unit (external serial CN331..., internal >> serial CN337...), or are they all like this? > > > I have an ext serial number CN331... as well, so I can't answer that. > >> >> What about printing to IrDA printers? Seeing that the 49g+ does print to >> the 82240 printers, I surmise that it's using the Red Eye format for >> printing via IR; is there a way to make it use the IrDA format? > > > No idea. Anyone else? >> And what about communicating with the old 48 series via serial IR? Is >> there a way to make the 49g+ use Serial IR? > > > I remember hearing somewhere that this isn't possible, for both software > and hardware reasons. That could be, although the fact that it can send (albeit very weakly) in the format needed for the 82240 printers leads me to expect that it should also be capable of using a serial IR format. I was under the impression that IrDA was capable of a serial IR mode for communicating with legacy devices such as the 48 series calculators. But the fact that the I/O input forms don't offer a choice of speeds may be a clue. Perhaps sending to the printers involves some trickery such as sending bits widely spaced within the IrDA data stream or something like that, which may also explain the very short range. -- James ==== able to >> use the same software that I use with the other calculators then? > > > Well, if you are running win98, then yes. WinXP does not have support > for a 'virtual COM port' using IR! There may be third party drivers, but > I haven't found any. Well, that's real encouraging. If I were to upgrade from 98SE to XP, I might be able to use Conn4x, but would eliminate a chance to add an IR device that I can treat as a COM port. I wonder whether I'd lose my USB to RS-232 converter, and just what other improvements XP makes. Maybe with JP Software's 4NT.... Keep in mind that the old version of the PC connectivity Kit works perfectly well using win98 and IrDA. WinXP works fine with USB. So I guess it depends on whether you'd prefer paying for an IR adaptor instead of upgrading to XP. Al ==== WinXP Pro also works well with the old version (v3.04) of the PC Connectivity kit and my hp48sx, via RS-232. I use it almost daily. I messed around with the IR mode unsuccessfully, trying to make the hp49g+ communicate with the hp48sx via IR. Now the hp49g+ has assumed a mode that won't work with the new connectivity kit. I've toggled things around (back to wire mode, of course, and reset all parameters) but something must not have stuck. The hp49g+ worked before, so I think I can get it back to that point again. The hp48sx has a better I/O interface, though. -Dale- > able to > >> use the same software that I use with the other calculators then? > > > > > > Well, if you are running win98, then yes. WinXP does not have support > > for a 'virtual COM port' using IR! There may be third party drivers, but > > I haven't found any. > > Well, that's real encouraging. If I were to upgrade from 98SE to XP, I > might be able to use Conn4x, but would eliminate a chance to add an IR > device that I can treat as a COM port. I wonder whether I'd lose my USB > to RS-232 converter, and just what other improvements XP makes. Maybe > with JP Software's 4NT.... Keep in mind that the old version of the PC connectivity Kit works perfectly well using win98 and IrDA. WinXP works fine with USB. So I guess it depends on whether you'd prefer paying for an IR adaptor instead of upgrading to XP. Al ==== > >> able to >> >> use the same software that I use with the other calculators then? >> > >> > >> > Well, if you are running win98, then yes. WinXP does not have support >> > for a 'virtual COM port' using IR! There may be third party >> drivers, but >> > I haven't found any. >> >> Well, that's real encouraging. If I were to upgrade from 98SE to XP, I >> might be able to use Conn4x, but would eliminate a chance to add an IR >> device that I can treat as a COM port. I wonder whether I'd lose my USB >> to RS-232 converter, and just what other improvements XP makes. Maybe >> with JP Software's 4NT.... > > > Keep in mind that the old version of the PC connectivity Kit works > perfectly well using win98 and IrDA. Yes, so I gathered. > WinXP works fine with USB. So far, with the sole exception of the combination of the USB driver and Conn4x for the 49g+, 98SE also works fine with USB. > So I > guess it depends on whether you'd prefer paying for an IR adaptor > instead of upgrading to XP. Well, for now, using the SD card and reader works well enough for transferring files, and I don't have anything other than the calculators to use IR with. Maybe HP will find a way to get the 49g+'s connection kit to work even with the PCs that it fails with now. If I were to upgrade the operating system, I'd be far more inclined to from Microsoft. -- James ==== I measured the distance from the 82240B and hp49g+ at which it will work for my setup. Two inches is it. Beyond that no workee. Still, I'm curious as to why my 49g+ has such a short range to the 82240 printers. Do I have a defective unit (external serial CN331..., internal serial CN337...), or are they all like this? ==== > I measured the distance from the 82240B and hp49g+ at which it will > work for my setup. Two inches is it. Beyond that no workee. And I've seen other posts that mention a very short range for this. I'd be particularly interested in hearing from anyone who finds that their 49g+ can print to an 82240A or 82240B from a more or less normal distance, like about the 3 to 6 feet that I get from the 48SX and 48GX (I suppose that this depends on battery condition and perhaps model), or even the 18 inches specified in the printer manuals. > > >>Still, I'm curious as to why my 49g+ has such a short range to the 82240 >>printers. Do I have a defective unit (external serial CN331..., internal >>serial CN337...), or are they all like this? -- James ==== Ok Ok, if ou insist. Ill start with RPN, faster input, faster processing, jus faster. Of course theres that little learning curve... but every one who knows RPN cant let it go. It doesn't sound like you know about the RPN interface for the TI-68k and the fact that the 68k use RPN internally. In my opinion, RPN is no longer a significant factor when choosing between the TI's and the HP's (for the above-stated reasons). Then, Programing. User RPL, System RPL.... MAde specially for a RPN CALCULATOR DEsigned to juice out the calculators capabilities. Easy to learn (User RPL at least..) and extremely powerful and capable. IMO, TI programing has no comparison with HP. C programming is more powerful in my opinion. Of course, we're entitled to our own opinions :-) But in other specs (CAS mainly) TI arent that far behind, if not equal. Hey, cool, you finally admitted it! :-) I quote amazing TI89 or Voyage 200 cant do that much if you ask me. ??? That seems to contradict your statement above. > What problem are you referring to? > Processing capabilities, etc. What kind of processing? Has way bigger limits then TI. What you can do with User and System RPL is pretty much up to you. It's pretty much the same with the 68k. And i just happen to be one! You called mathematical physics, theoretical mechanics simple... I wouldnt. It depends on one's point of view. In one sense, the Einstein equation from GR is very simple, particularly in natural units, but if you go deeper, you have to compute all sorts of complicated tensors, and have to cope with intermediate expression swell. TO get to the point, TI can not correctly handle 10th grade high school physics What?! It gives wrong answers? Examples, please. -- Bhuvanesh ==== the RPN underlying system which does not allow easily for the same commandname for a variable number of arguments, Why not use an END_TAG as the 68k do (only for variable-argument commands)? It makes things slightly more complicated, but it's a good tradeoff, I think. Bhuvanesh. ==== >the RPN underlying system which does not allow easily for >the same commandname for a variable number of arguments, Why not use an END_TAG as the 68k do (only for variable-argument commands)? It makes things slightly more complicated, but it's a good tradeoff, I think. The reason is RPN entry. If you get args from the stack before the command name is entered, you can not allow a variable arg number, except by having an additionnal argument, which is the number of arguments itself (like DROPN does for example). In algebraic mode, the parser knows the actual number of args because of the closing parenthesis (and user functions are also correctly handled on the HP in an algebraic entry, it's done using the number of args before xFCNAPPLY). BTW I did not check, how does the TI rpn program handle commands with variable arguments number? Speaking of data structures, I find that the TI structure is better than the HP for symbolic object in algebraic mode because evaluation should begin with the operator, not with the arguments, since a given operator sometimes has to quote some of its arguments (like STO). But like the HP structure, it is very inefficient for large expressions because it keeps the whole data in one block, without pointers, and therefore requires a large copy each time you modify it. A graph data structure is much more efficient (that's what I choosed for giac/xcas). ==== All I remember is that they didn't follow the floating point spec (IEEE 754 and others) for floating-point arithmetic That's generally a good thing, as far as I can tell. and that certain functions were numerically unstable. Can you give examples? BTW, if you are so pro-TI, why bother reading an HP newsgroup? Speaking for myself, I always like hearing other points of view. Bhuvanesh. ==== OF course, its obvious that the largest market for calcs is the high school one (perhaps not the largest but a big one indeed) and (just my opinion), in the usa (prob biggest school market available), high school students are either nerds or the complete opposite. The none nerds will get and do whatever is easier, and TI being the case. Of course its also abvious that none nerds greatly outnumber nerds. There are lots of nerds in the TI camp, too. On the other hand, with TI, the problem is after typing in the stuff. Come on, get real! If youd actually know about HPs and actually be able tu use one (i mean *really* learn to use one) the benfits would be WAY bigger then with the crappy TI (Total Incompetence). I'm not gonna reply to that. For one thing, I have too much respect for the founders of HP, although the new HP is quite different from what they envisioned. What about software?? No doubt that *owns* TI. As a matter of fact, the two are pretty much functionally equivalent... well, as far as the CAS goes. One sore point is numerical linear algebra, but that should get better in a few months. Well Helen, what exactly do you teach?? Im sure TI will work for simple stuff. And complex stuff... residues, contour integration, ... ;-) [pun intended] I agree with demeter! Bhuv and peeps like him must be rescued! Peeps... is that the Internet abbreviation for people? -- Bhuvanesh ==== As a matter of fact, the two are pretty much functionally equivalent... well, as far as the CAS goes. One sore point is numerical linear algebra, but that should get better in a few months. Hah! Can you expand on that? -- Helen ==== hehe Don't be too harsh on our friend. After all, he is a rather intelligent TI user Oh, thank you :-) feeling discomfort and strain within the 'mentally challenged' crowd of the dark side That doesn't bother me at all. There are just as many, if not more, intelligent power-users on the TI side as on the HP side. that seeks desperately for a shelter within our sophisticated family group Yep, you guys squabble just like a family would! ;-) but often fails due to feelings of guilt for betrayal. I say we embrace this promising fellow and help him get rid of these pseudo-guilt emotions and help him rise above the emetic pulp of TI mob. Of course he will have to declare total and unconditional submission and allegiance to the Holy cause and values of this divine group. He will eventually become an obedient and humble servant to OUR needs. The rebellion will be crushed... that sort of thing? ;-) -- Bhuvanesh ==== > T.I-->Trash Industry > > Well, let's just say that it was not TI that got a couple of kids off kids of the street - Professor Parisse? He designed the CAS. > the street to slap together a duct-tape and chicken-wire contraption > of a calculator called the HP49G,[...] Well, youll just have to admit... Even though on the outside the 49g is just plain crap, its got power, lots of it, and thats pretty much all i care for. > by gutting the achievements of a > previous generation of real engineers who created the HP48 series, and > gluing a half-baked joke of a CAS on top of what used to be a nice > system, squeezing the whole package into a silly frozen-hamster butt > blue box with blue key labels and rubber-duck keys, and an obsolete > processor. [...] I repeat the above AND I am against it. The 49G is better than the 48-series. > It was not TI that then claimed that the thing is ten to a > hundred times faster than the old machine, despite the fact that > there is no difference in speed at all. [...] Or so you say... 49g software improves quite a lot of speed. Just use the EQW side by side and then try to use back-space to correct > before, with a flickering display for good measure. Oh sure, it comes flickering? What flickering? > with a new processor giving you a speed advantage of a factor of about factor 2? Plotting seems to be factor 3 and Multi-variable SoLver 3.5* bare (naked?) binary loops are 7* faster. I would say >3* average... > two, so there is ome benefit. But what good does that do you if you > continue to get wrong results because one of your key presses did not > register thanks to the absolutely worst keyboard in the industry, or > because you consequently slow down your typing in order to check that > each digit that you type actually appears on the display? Don't look, hear it with keyclick turned on. If your keyboard is really that bad then replaced the 49g+ with a new unit until it works. PS: I hate when my 49g+ misses a [ . ] when using reals... PPS: I will not return this calc - it has a strange greenish display, which is different from the standard black LCD. It could be a collectors calculatrice. ==== > I repeat the above The above being: Well, youll just have to admit... Even though on the outside the 49g is just plain crap, its got power, lots of it, and thats pretty much all i care for. AND I am against it. The 49G is better than the 48-series. Thats just what i am saying. 49g series owns. Just use the EQW side by side and then try to use back-space to correct > with a new processor giving you a speed advantage of a factor of about factor 2? Plotting seems to be factor 3 and Multi-variable SoLver 3.5* bare (naked?) binary loops are 7* faster. I would say >3* average... See Helen?? All yer rants were cr*p. id stick with 49g series any day. ==== See Helen?? All yer rants were cr*p. id stick with 49g series any day. Well, son, I notice that you haven't come up with an answer to any of the questions I asked you. I guess we both know why that is. -- Helen. ==== You are right about the out-of-control situation that evolved one-more-time. It seems as though there are people in this newsgroup that are fanatics to an insane degree (like myself) for no essential reason at all! We need more love in our lives! People who get obsessed about things with extreme points of view and aggressive attitude are usually those with a deprived balanced sexual life, proponents of conservatism and against radical social changes. Let us embrace all oneanother, men and women, kiss affectionately one another, irrespectively of sex (yes), color, and social beliefs. Let us put aside the poisons that wel call religion and politics and focus on the sexual animal that we call man! Then and only then shall we realize a better and class-less world. Besides, it is absolutely meaningless trying to kill all TI-borgs since there are so many of them :-) !Demeter! ==== A long time ago I stoped letting my little sister play Mario 3 b/c it annoyed me how horrible she played :) Typical big brother. Hopefully when she reaches your age she will have a better command of English. Tanya ==== This is the point of view of someone who want to use a CAS as a blackbox, something probably inevitable if you are a physicist teaching math to physicists. In my view, a CAS in a calculator is a pedagogical tool, it should help understand mathematical concepts, it should therefore not be a blackbox, it must do the computation you ask it to do and nothing more. I think we had this discussion before. I don't really have the time to rehash this again right now, so let's just agree that we disagree on this. For example, asking for a numerical or exact root of an equation is totally different, I find perfectly reasonable to have two commands (or an explicit flag switch) to do these tasks. Well, yes, it can be reasonable to have different commands for the numerical versus the symbolic operations. What makes little to no sense is the flag switches. Obviously, none of the PC CAS see any need for that. Or doing calculations in real/complex mode. I disagree, see above. Asking for a mode switch (which can be disabled using the silent flag) is therefore not silly, because it explicitely indicates a new mode of computation. Ditto. Apparently neither Maple nor Mathematica nor Macsyma see a need for such mode switches, or indeed the use of such modes. And at least, if you feel you need to switch modes for a certain calculation, the system should have the good grace to switch back to the previous mode once it's done. The way things are presently done is simply a horrible kludge. Not your fault, I know, but an abomination nevertheless. I don't think the HP CAS is perfect, far from it (I prefer giac/xcas), it has some limitations (partially because of the RPN underlying system which does not allow easily for the same commandname for a variable number of arguments, Yes, that is what I thought. The TIs do not have that problem. -- Helen. ==== I think we had this discussion before. I don't really have the time to rehash this again right now, so let's just agree that we disagree on this. Then next time you give your opinion about the 49 CAS, please explain that you don't like it as a physicist. I generally don't care about the opinion of stupid young people, that's not the case for you, then imagine your reaction if someone posted repeatedly categoric bad opinion on your work (just re-read your post and imagine you did the CAS). There are much more agreable ways to disagree, for example I would say that Bhuvanesh attitude is very fair. Well, yes, it can be reasonable to have different commands for the numerical versus the symbolic operations. What makes little to no sense is the flag switches. Obviously, none of the PC CAS see any need for that. >Or doing calculations in real/complex mode. I disagree, see above. PC CAS commands always depends on a context, for example Digits for the real precision, or the way some tests are done (like assumptions tests), etc. But also of course a command depend on all the defined variables. Ditto. Apparently neither Maple nor Mathematica nor Macsyma see a need for such mode switches, or indeed the use of such modes. And at least, if you feel you need to switch modes for a certain calculation, the system should have the good grace to switch back to the previous mode once it's done. The way things are presently done is simply a horrible kludge. Not your fault, I know, but an abomination nevertheless. See above about context. And maxima can interrupt a computation and ask whether a variable is positive, that's similar to a mode switch question. > I don't think the HP CAS is perfect, far from it (I prefer >giac/xcas), it has some limitations (partially because of >the RPN underlying system which does not allow easily for >the same commandname for a variable number of arguments, Yes, that is what I thought. The TIs do not have that problem. On the other hand, doing functionnal programmation on the TI is much harder, see Bhuvanesh mathtool to get an idea... ==== Then next time you give your opinion about the 49 CAS, please explain that you don't like it as a physicist. As I said, I am short on time right now, and we did have quite a bit of a discussion on this before. There is no need to rehash that, but the gist of it was that I believe that it is not only physicists that the 49G does not offer a good value for. The best evidence is the market success of this calculator, or rather the total lack of same. I generally don't care about the opinion of stupid young people, that's not the case for you, then imagine your reaction if someone posted repeatedly categoric bad opinion on your work (just re-read your post and imagine you did the CAS). Hold on right there: I have said, repeatedly, that it is not your work I am criticizing. While, as you say, the CAS itself is not perfect, my main criticism is about the way it is integrated, or rather not integrated in the system as a whole. Which is (mostly) a consequence of a decision by HP to try and enter the market in the cheapest possible way, and has little to do with the skill of the people doing core development on the calculator software, the capabilities of whom are beyond doubt. There are much more agreable ways to disagree, for example I would say that Bhuvanesh attitude is very fair. I am sorry if I hurt your feelings. That was not my intention. See above about context. And maxima can interrupt a computation and ask whether a variable is positive, that's similar to a mode switch question. No, it is entirely different: you are not changing, radically, the way the CAS operates. By the way, there are lots and lots of inconsistencies associated with those silly mode switches. For example, if I turn on approximate mode, then trying to evaluate the example for INTVX in the CAS help gives an error message, while putting the arguments on the stack and pushing the INTVX softkey still works. Etc., etc., etc. ... I also notice that, judging from your silence on that topic, you agree with me that not restoring the flags is simply inane, and entirely unacceptable. On the other hand, doing functionnal programmation on the TI is much harder, see Bhuvanesh mathtool to get an idea... Oh sure, the TIs have their own problems, too. -- Helen. ==== > I've noticed an increase of approx. 3--4 in mathematical calculation, > e.g., finding extrema of multivariate functions or simplex. > > Can you give me an example? Sure. Finding the exrema of a function of two or more variables via LNAME, HESS, SOLVE, SUBST, maybe followed by EXPAND, then EGV, all done in exact mode, is usually 3 times faster on the 49+ compared to the 49g. > I am talking about the speed of evaluation > of native functions, and I am not interested in CAS functions Well, that's what I'm interested in ... > No, I am talking about the 48GX, inversion of a random matrix, all > calculations done in approximate mode (see above; I am not > particularly interested in exact solutions). A 10x10 random matrix > takes about 6 seconds to invert on a 48GX, about half that on a 49G+. Yes, you're right. Anyway, in exact mode it's 70 seconds on the 49g compared to 23 seconds on the 49+. Exact mode? I used Approx. mode AND now LASTARG and Last Stack were off to save MEM I also set the Large Matrices ON, User mode off and clock off, ROM 1.22 Fresh set of Rayovac Rechargeable Alkalines. Never mind the 4 FIX results. 1: {48. 48.} {RANM} HEAD MEM ; TEVAL took 11.8619 seconds and gave 1 digits reals {INV} HEAD MEM ; TEVAL took 144.5029 seconds and gave 12 digits reals {INV} HEAD MEM ; TEVAL took 146.1499 seconds and gave 12 digits reals -52 SF (Show one line) {INV} HEAD MEM ; TEVAL took 145.7567 seconds ==== > Speed: Some things are quite a bit faster than on the 48/49G. > Mathematical calculations (yes, some of use our calculators for > that...) are a bit faster, but not dramatically so. I've noticed an increase of approx. 3--4 in mathematical calculation, e.g., finding extrema of multivariate functions or simplex. > Matrix inversion is about a factor of 2 faster on > the 49G+ compared to the 48GX; seconds on the 49, compared to 10.9 seconds on the 49+. I presume it'll take about a minute on the 48gx. I inverted a {10. 10.} RANM => 1 digit INV => 12 digits {INV}HEAD MEM ; TEVAL in 2.04 seconds (with LASTARG and Last Stack on) > Overall, I would say the 49G+ is roughly a factor of 2 faster than the > 48GX, ==== >active components within the cable then convert the logic > levels to RS-232 signal levels. Problem is they did not supply the > power necessary to drive these active components. Instead, they are > stealing power from the modem control lines of the RS-232. This is > fine as long as you 1) use the supplied cable, 2) don't use an > additional cable extender that does not support the modem control > lines and 3) connect your 48GII to a PC using HP's driver software > which will toggle either the DTR or RTS lines of the PC to the proper > levels. I have to admit that is a kludgey way to do it - fine for PC's, but quite unreliable for anything else. to mind. If you give it an external 5V supply. it converts CMOS to RS232 and back again. Is there any chance you can post pictures of the 48gii's PCB? I'd like to compare it to the 49G, and see exactly where this serial line comes from. thanks, Al Al, Sorry, I did not crack open the 48GII itself (just the serial cable connector). Keep in mind that the cable they supply with the unit already comes with a MAX232 type device (they use the Sipex SP3220E). All you need to do is supply the power. Bob ==== La documentation d'unitman est maintenant disponible en Fran.8dais. Visitez le site de Wolfgang Rautenberg, son auteur, et choisissez le bon drapeau http://page.mi.fu-berlin.de/~raut/WR49/index.htm Unitman est un logiciel extr.90mement utile car il permet d'.8editer facilement le menu int.8egr.8e des unit.8es pour; entre autres, lui rajouter les unit.8es qu'il vous manque. Indispensable pour les unit.8es Anglo-saxonnes, historiques ou dans des domaines sp.8ecialis.8es comme le magn.8etisme. Comme cela fait maintenant 5 ans que j'habite en Angleterre, la qualit.8e de la traduction n'est sans doutes pas parfaite, mais s.9erement meilleure que si elle avait .8et.8e faite par hp :-). N'h.8esitez surtout pas .88 m'indiquer les fautes, j'essayerai de les corriger. Arnaud ==== HP49g+, 1.22 I define a function f that does this: << -> X 'FLOOR(pi/ASIN(X))' >> When I try to compute f(1) on the calc, I get 1 as the result. It should be 2. Whats going on? -- Jostein Trondal ==== HP49g+, 1.22 I define a function f that does this: << -> X 'FLOOR(pi/ASIN(X))' >> When I try to compute f(1) on the calc, I get 1 as the result. It should be 2. Whats going on? When you do FLOOR(expression) the expression is *numerically* evaluated first. 'pi/ASIN(1)' evaluates to 'pi/(pi/2)' ->NUM gives 1.9999999999 (that's 3.14159265359/1.5707963268) Hence FLOOR gives 1. QED Say we have EXPANDFLOOR: << -> X << X EXPAND FLOOR >> Replace FLOOR with EXPANDFLOOR in your program, and you'll get 2, because 'pi/(pi/2)' will first be algebraically simplified to 2. Gerald. ==== Ich hab mal eine Frage bez.9fglich des G49+. Kann es im Gegensatz Ausdr.9fcke wie die TI Rechner automatisch auf ein Mindestma§ an Variablen vereinfachen oder zeigt er z.B: immer noch Wurzel(X)/X anstatt 1/Wurzel(X) und andere derlei Dinge? Gru§ Alexandra ==== If someone Want information and put it in a web then write me. It works perfectly. Bye ==== I posted this originally in the TI-89/92+/V200 discussion group. I'm posting this here also, in case Dr. Parisse or someone else can explain this. I'm curious: Isn't it possible to factor a (univariate) polynomial modulo a composite integer? I know one can find roots mod a composite integer by finding roots mod each of its constituent primes and then using Hensel lifting (to make the roots correct mod p^k) followed by the Chinese Remainder algorithm, but how would one find the multiplicities? Am I missing something obvious? Also, as an add-on to my original post, is it possible to determine how many roots a polynomial should have modulo an integer p (possibly composite) without doing the actual factorization? Bhuvanesh. ==== Can anyone tell me if the HP49+'s infrared is downward compatible with the 48GX? i.e. can we transfer data between a 49+ and a 48GX via infrared? Morgan ==== No it is not. John Can anyone tell me if the HP49+'s infrared is downward compatible with the 48GX? i.e. can we transfer data between a 49+ and a 48GX via infrared? Morgan