HP-21 ==== > 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 with a > patch? > A solution to the flickering is [Press ON plus up-arrow]. I tried it and during the short time I had to watch it, it appears to work. That's the Print LCD command. The calc is probably busy trying to find the printer and forgets to service the clock interrupt. Tom Lake If it wasn't for the bullet in my pocket, the Bible would have killed me. ==== > That's the Print LCD command. The calc is probably busy trying to find the > printer and forgets to service the clock interrupt. will this impact battery life, (with or without the clock turned on)? // greenchile505 ==== The only time I notice a flicker is within about 1-2 seconds after I complete an operation IF I don't push anything else. Makes one wonder if it is somehow powering down after running something. If I'm continuing to work, I don't ever see a flicker. Rom 1.22, SN CN33103XXX. Gene -- * These statements and opinions are mine alone and do not reflect my employer's views. * > 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 with a > patch? > A solution to the flickering is [Press ON plus up-arrow]. I tried it and during the short time I had to watch it, it appears to work. Matt ==== I'm in serious trouble when using the subjected (funny word in this context :oD) sysrpl command. I want to use it to evaluate a string passed by the user in an inputline. To avoid strange results (E.G.: The user types only SIN; it's obvious he/she forgot the argument, and I don't want that DOSTR> for this string evaluate the SIN of the arg that already was in the stack), I've thinked to save all the rpn stack in the virtual stack before trying to evaluate the string. The problem is that if a syntax error occurs I can't pop the previously saved stack! That's very annoying, isn't it? Anyone has any idea on how save the stack, to evaluate the passed string and restore the stack indipendtly on errors during string evaluation? Thx to all! Kickaha -- Per rispondere rimuovere il SiPAriuM To reply remove the SiPAriuM ==== >I'm in serious trouble when using the subjected (funny word in this context >:oD) sysrpl command. I want to use it to evaluate a string passed by the >user in an inputline. >To avoid strange results (E.G.: The user types only SIN; it's obvious >he/she forgot the argument, and I don't want that DOSTR> for this string >evaluate the SIN of the arg that already was in the stack), I've thinked to >save all the rpn stack in the virtual stack before trying to evaluate the >string. The problem is that if a syntax error occurs I can't pop the >previously saved stack! That's very annoying, isn't it? >Anyone has any idea on how save the stack, to evaluate the passed string and >restore the stack indipendtly on errors during string evaluation? Thx to all! >Kickaha :: ... TRUE 1LAMBIND ( Set DOSTR> error flag ) ERRSET :: DOSTR> FALSE 1PUTLAM ( Clear DOSTR> error flag ) EVAL ; ERRTRAP :: 1GETLAM case :: ... ( Handle DOSTR> errors ) ... ; ... ( Handle other errors ) ... ; ABND ... ; ---------------------------------------------------------------------------- --- Jonathan Busby - before replying. ==== :: >... >TRUE 1LAMBIND ( Set DOSTR> error flag ) >ERRSET >:: DOSTR> FALSE 1PUTLAM ( Clear DOSTR> error flag ) EVAL ; >ERRTRAP >:: >1GETLAM >case :: ... ( Handle DOSTR> errors ) ... ; >... ( Handle other errors ) ... >; >ABND >... >; > Seems I neglected to take into account an important part of DOSTR>'s behavior (posting while half asleep is not recommended) in that I forgot it evaluates the result of palparse. So, in order to make sure that a syntax error is due to palparse and not the result of evaluating the compiled object, you'll need to call palparse directly. I don't know why you're using DOSTR> anyway, other than possibly to save a few bytes, but that doesn't work in this situation. :: ... palparse ?SKIP :: .. ( Handle syntax errors ) ... ; ERRSET EVAL ERRTRAP :: ... ( Handle errors due to evaluating the resultant object ) ... ; ... ; Again, this is a very simple error trapping construction. See the last two links mentioned in my other post or Carsten Dominik et al's HP48/49 Entry Database ( http://www.hpcalc.org/details.php?id=5476 ) for more information on palparse. ---------------------------------------------------------------------------- --- Jonathan Busby - before replying. ==== Thx Jonathan to spending your time answering me. I had still thinked of the classic ERRSET-ERRTRAP sequence, and I was convincted that I used it last night, noticing that it didn't work properly. Now retrying it I noticed that all goes as I expected... what can I say... I think that programming asleep it's not good as posting on ng (as you said) :o) Thx anyway for your time. At least you pointed out to me how to perform an error trapping based on LAMs used as flags; I never thinked to it before, I just used the error numbers. Thx again, Kickaha -- Per rispondere rimuovere il SiPAriuM To reply remove the SiPAriuM ==== :: >... >TRUE 1LAMBIND ( Set DOSTR> error flag ) >ERRSET >:: DOSTR> FALSE 1PUTLAM ( Clear DOSTR> error flag ) EVAL ; >ERRTRAP >:: >1GETLAM >case :: ... ( Handle DOSTR> errors ) ... ; >... ( Handle other errors ) ... >; >ABND >... >; > If you didn't want to evaluate the result of DOSTR> , then the above simplifies to :: ... ERRSET DOSTR> ERRTRAP :: ... ( Handle DOSTR> errors ) ... ; ... ; which is a simple and elementary error trapping structure. The virtual stack behaves exactly like the DO-LOOP or temporary environments with respect to error generation and trapping. For more information on the virtual stack, see : Avenard of the inner working of the virtual stack as well as listing describing each of the supported API functions ). Or for in depth explanations on the RPL error generation and trapping mechanisms, see http://www.hpcalc.org/details.php?id=1745 ( RPLMAN ) or http://www.hpcalc.org/details.php?id=5142 ( Programming in System RPL by Eduardo M. Kalinowski et al ) . ---------------------------------------------------------------------------- --- Jonathan Busby - before replying. ==== I am looking for a Darkroom Timer (a timer that beeps every 60 secs and gives a different tone beeps when the development time is finished). I was wondering if anyone of you knows if such sw already exists and where to find it. Similar timer to be modfied should be good also. Fabio BERETTA Lecco - IT ==== I am looking for a Darkroom Timer (a timer that beeps every 60 secs and >gives a different tone beeps when the development time is finished). I was wondering if anyone of you knows if such sw already exists and >where to find it. Similar timer to be modfied should be good also. >Fabio BERETTA >Lecco - IT I think there is one, but I am trying to remember this from a long time ago.(1992 or 1993) Yoou might search hpcalc.org and take a look at Joe Horn's Goodies Disks. Harold A. Climer Dept.Of Physics,Geology,and Astronomy University of Tennessee at Chattanooga Chattanooga TN USA 37403 ==== > Well, I decided to attempt to just disassemble the ROM. Does anyone > happen to have any pointers that could simplify this task a bit? For > starters, it would be quite helpful to know where the actual starting > point is and what this ROM contains. > > Sorry for the delay, here is what I could find: > > The 1.19.6 rom is ~4Mnibbles long. Actually, if you dump it with hexdump, > you'll see that only 2Mnibbles are really used, the rest seems garbage. > It starts with > 0000000 6 2 9 4 0 8 0 1 8 0 3 0 1 0 0 0 > > The 1.22 rom is ~2.5Mnibbles long. I looked for the nibbles above and > could find them at nibble #78000 (491520): > 0078000 6 2 9 4 0 8 0 1 8 0 3 0 1 0 0 0 > > So I got rid of the preceding ~500Knibbles (which might very well be arm > native code), and the result was a 2Mnibbles rom. I tried it on the > Saturn 4.1.1.1 emulator, but of course it didn't work :o) (why ? new > opcodes for instance, and some new hardware accesses) > > I then wanted to check for saturn-visible rom differences. On 1.19.6 > roms, what is seen by Saturn as address #0 resides at nibble #40000: > 0040000 7 0 0 0 0 4 3 0 5 2 3 6 d 6 1 8 > > So I again stripped off the previous 256Knibbles part of each rom. > > Then I launched vimdiff between both hexdumps, and I could then see only > the little differences between 1.19.6 and 1.22 (I should have kept a > 1.20 copy somewhere, there would have been even fewer differences). > That's how I could see the 81Bx and BUSCC tricks. > > What is left ? Well, I even don't know that much about the 49g rom > layout, so I can't tell much about the 256Knibbles part, but I'd really > try to disassemble the 512Knibbles part, and maybe find some saturn > emulator code ? > > Samuel Thibault ROMs. I've got an ARM disassembler as well as all the rest, so once I finish moving and get some free time I'll definately give this another go. Would you be interesting in maybe getting together on IRC or some other more real-time medium and work on this? Ideally I'd like to get a complete disassembly of the ROM with ARM and Saturn asm nicely seperated and a good idea of the boot up procedures (basicly how the calculator gets from OFF state to Saturn emulation). ==== > Would you be interesting in maybe getting together on IRC or some > other more real-time medium and work on this? Well #hp48, on the efnet network is there for this. I'm nicked youpi on it. Maybe a CVS holding commented disassembly would be interesting. Samuel Thibault ==== They say the display is excellent compared to the hp48GX. In most respects it is. But.....am I the only on a little peaved that the menu key Ms look like Hs unless they're both displayed simultaneously so that the difference can be seen? ==== > ... am I the only one a little peeved that > the menu key Ms look like Hs unless > they're both displayed simultaneously so > that the difference can be seen? I agree that the built-in minifont is fugly. But you can easily change it! You can set the 49g+ minifont to be identical to the 48GX minifont or to the UFL minifont or whatever you'd like. Just download a minifont from hpcalc.org and then install it with the ->MINIFONT command. If you already have the UFL library in your 48GX, use the 49g+'s UFL1->MINIF command to convert its minifont to an HP49g+ minifont. -Joe- ==== > ... am I the only one a little peeved that > the menu key Ms look like Hs unless > they're both displayed simultaneously so > that the difference can be seen? > I agree that the built-in minifont is fugly. But you can easily > change it! One can try to improve the 49-minifont with the library Fontman below. Pressing the command MiniF shortly views the current minitfont, pressing a bit longer edits it for modification. Modifying the minifont is not as easy as one might think. One has only 3 pixel for the width and this causes a problem for M and W. Theoretically, one may use 4 pixels, but then some menu names may not display 5 letters throughout as they do currently. One may critizise the 49/49+ in several points. But its minifont is as perfect as it could be if mixing menu names in upper and lower case. IMHO a definite plus of the 49/49+ over the 48. For this comfort one has to pay with some difficulty in distinguishing M and H. All minifont problems could be solved if the 49+ screen were made broader. But then the many problems in backward compatibility would be completely unsolvable. - Wolfgang http://page.mi.fu-berlin.de/~raut/WR49/index.htm#Science ==== Should be the same menu font as on the 48GX, FYI. However, given the number of pixels in the menu labels, I'm not sure how it could be drawn differently. Want more pixels in the menu labels? Wow. That WOULD be a big change. :-) Gene -- * These statements and opinions are mine alone and do not reflect my employer's views. * > They say the display is excellent compared to the hp48GX. In most respects > it is. But.....am I the only on a little peaved that the menu key Ms look > like Hs unless they're both displayed simultaneously so that the > difference can be seen? ==== My apologies for misinformation below! Oops. Gene -- * These statements and opinions are mine alone and do not reflect my employer's views. * > Should be the same menu font as on the 48GX, FYI. ^^^^^^^^ Wrong > However, given the number of pixels in the menu labels, I'm not sure how it > could be drawn differently. Want more pixels in the menu labels? Wow. That WOULD be a big change. :-) > Gene ==== > >> Today I requested and received a RMA for the return of a hp49g+ > >>calculator. > > >>I ordered the hp49g+ calculator online DIRECT from HP's SMB web site on > >>10/21/03. > >>I received it via UPS on 10/27/03. > >>It was shipped from Indianapolis, IN. > > >>It was received with the the DEFECTIVE operating system installed. > >>Upon testing its operation, I found that some keys failed to function.. > >>I concluded hp CHOSE-TO-DELIVER -A-KNOWN-DEFECTIVE PRODUCT to me. > > Don't expect any coments here. Your post is politically incorrect. > > Everybody knows that HP calculators are The Best Calculators In The > > World. Oh... They don't work?... Really?.... So what?... > > I returned mine too. Back to TI 89. > > If you haven't noticed plenty of strongly negative comments about the > 49G and 49g+, then I guess that you don't read many posts in this > newsgroup. > > Some of us are willing to give HP yet another chance and hope that they > get things right. Carl and you choose not to, and I don't find fault > with either of you for that. What is there to comment on? I know HP calculators have problems. I've been using them for years, and I have also been using TI calculators for years. Overall, TI has been much much more stable than HPs more recent calculators. I wasn't refering to negative comments about HP calculators. Negative feedback certainly has its merits and everyone is entitled to their own opinion. However, what I find curious is the number of posts in this group that contain nothing but yeah, I love my TI or something to that extend. ==== > > It's about 2 weeks since I got my HP49g+. But I read this group for > > months before it arrived. I am a programmer and now program in DELPHI > > and have owned every model calculator that HP has come out with since > > the HP65. Some many years ago I also programmed these calculators. But > > back then you got every bit of info from HP. Now with this purchase of > > the hp49G+ and the hp49G before it, the information that HP supplies > > is woofully inadequate. > > I have downloaded all the books and tutorials that I could find at > > hpcalc.org and others but I am still left wanting. If you think of the > > indepth manuals that you get with a product like Delphi (6 for the > > moment)you can imagine what I mean. > > HP we need complete and comprehensive manuals in order to program and > > use the HP49G+ to its fullest. If they exist now, could you tell me > > where to find them? > > I am talking about UserRpl and SystemRpl. I have all the usual books > > and downloads for both languages but still need more. More indepth > > expainations and examples. Take a case in point. Informs. Everything I > > have read about it thus far cannot tell me how to program a checkbox > > as a field in an inform. Yes there are programs to do them, but how > > did the programmer program it in. What were the commands? see my > > point. > > I am usually a helper in that I write lots of useful programs but I > > need the tools. All I really have now is the HP49G+, I now need the > > indepth manuals. > > HP where are they? > > If you haven't already done so, visit http://membres.lycos.fr/ekalin/. > > The 49G and 49g+ inherited a lot from their predecessors, the 48 series, > which in turn inherited a lot from the 28 series. Don't ignore > information written for these. > > Visit http://www.engr.uvic.ca/~aschoorl/ and > http://m.webring.com/hub?ring=hp48 I was mostly refering to the specific changes that had to have happened as a result of changing the processor. ==== Ah, I missed the part about ->Q in your post. My last calculator was a HP48SX as well. Look at appendix K in the manual. You need to go to the MAIN menu (look in the CATalog). Then go to the REWRITE submenu. The function is XQ() XQ(0.5) => 1/2 See XNUM also. Matthew F. G. > I have searched the manual and the right shift cat directory > but did not fine what I would recongnize as the Q key like on the > HP48sx. Where is it hidden? > > format question > > I set mode to display 3 dec places. when I input a number, > example 10000 then > 10000 is on the display > if I mult by say 1.2 then divide by 1.2 > the display is > 10,000.000 > > How can I get 10,000.000 by just entering the number all the time? > I like to see tha comma separators. > On the hp48 I just set the mode to fix 3 and when I enter > 100000 I get > 10,000.000 > > David ==== There are two ways you can do this: one, you can enter it like 10000. [1][0][0][0][0][.] with the decimal point Or, if you want it to show it like that w/o putting in the decimal point, you can change the CAS to 'approx' mode, by hitting [Mode][F3 (CAS)][down arrow][down arrow][F3 (chk)] then [F6][F6] for OK-OK There is a shortcut to switch modes, hold down right shift, then press enter -- you'll see a symbol in the header change between '=' for exact and '~' for approx mode. Hope this helps, I'm learning to use my 49g+ as well. Matthew F. G. > I have searched the manual and the right shift cat directory > but did not fine what I would recongnize as the Q key like on the > HP48sx. Where is it hidden? > > format question > > I set mode to display 3 dec places. when I input a number, > example 10000 then > 10000 is on the display > if I mult by say 1.2 then divide by 1.2 > the display is > 10,000.000 > > How can I get 10,000.000 by just entering the number all the time? > I like to see tha comma separators. > On the hp48 I just set the mode to fix 3 and when I enter > 100000 I get > 10,000.000 > > David ==== Sorry, but you are falling for a a couple of traps from the difference between the 48SX / 48GX and the 49G level calculators. 1) They have a new type called INTEGER. Input a number like 1000 and press ENTER and you have placed the INTEGER 1000 on the stack. Fix 3 does not place commas into integers. To show integers you must be in a fix mode and be dealing with REAL numbers. Type 1000 then the decimal point to get a real. It will show with commas. This has been true for 4 years now. The reason the 48 series doesn't do this is that they don't have the integer type. HP has been asked to find a way to show integers with commas as well as show commas when in standard mode. Given the LARGE number of things the user community asked for that were incorporated into the 49G+, I think there is a good chance this will come in the future. 2) The ->Q function is present but not as a key on the calculator. You can execute the function by typing '->Q' then EVAL. Press the single quote, press right shift, press zero, press ALPHA, press Q, then press ENTER. Then EVAL. If you use this function frequently, then I would assign it to a key and use the USER keyboard. Or develop a custom menu. Both are described in the Customizing your calculator training aid for the 49G+ available for download for free from HP's website. Gene -- * These statements and opinions are mine alone and do not reflect my employer's views. * > I have searched the manual and the right shift cat directory > but did not fine what I would recongnize as the Q key like on the > HP48sx. Where is it hidden? format question I set mode to display 3 dec places. when I input a number, > example 10000 then > 10000 is on the display > if I mult by say 1.2 then divide by 1.2 > the display is > 10,000.000 How can I get 10,000.000 by just entering the number all the time? > I like to see tha comma separators. > On the hp48 I just set the mode to fix 3 and when I enter > 100000 I get > 10,000.000 David ==== > 2) The ->Q function is present but not as a key on the calculator. You can > execute the function by typing '->Q' then EVAL. Press the single quote, > press right shift, press zero, press ALPHA, press Q, then press ENTER. Then > EVAL. If you use this function frequently, then I would assign it to a key > and use the USER keyboard. Or develop a custom menu. Both are described in > the Customizing your calculator training aid for the 49G+ available for > download for free from HP's website. Actually, pressing ALpha Right Shift 0 Alpha Q Enter will be easier and faster. ==== You need to be in approx (not exact) mode. Can be altered in 'CAS Modes' dlg box or by flag (clear -105). Alternatively do a ->NUM eval on the exact mode representation. Dunno what you mean by 'Q' key, if you mean the character that follows P, then it is directly under M. > I have searched the manual and the right shift cat directory > but did not fine what I would recongnize as the Q key like on the > HP48sx. Where is it hidden? format question I set mode to display 3 dec places. when I input a number, > example 10000 then > 10000 is on the display > if I mult by say 1.2 then divide by 1.2 > the display is > 10,000.000 How can I get 10,000.000 by just entering the number all the time? > I like to see tha comma separators. > On the hp48 I just set the mode to fix 3 and when I enter > 100000 I get > 10,000.000 David ==== Of course you didnt mean the Q character - sorry didnt read right. The command can be assigned to a key (need the GOKEYDAT - at http://www.hpcalc.org/) with a small UserRpl program - where 94.3 is the BASE key: << << ->Q >> GOKEYDAT 94.3 ASN >> Can also use the same approach to quickly toggle from real<->approx: << << -105 DUP FC? << SF >> << CF >> IFTE >> GOKEYDAT 94.2 ASN >> Just alter the ASN argument to the key of your choice. Dave > You need to be in approx (not exact) mode. Can be altered in 'CAS Modes' dlg > box or by flag (clear -105). > Alternatively do a ->NUM eval on the exact mode representation. Dunno what you mean by 'Q' key, if you mean the character that follows P, > then it is directly under M. I have searched the manual and the right shift cat directory > but did not fine what I would recongnize as the Q key like on the > HP48sx. Where is it hidden? format question I set mode to display 3 dec places. when I input a number, > example 10000 then > 10000 is on the display > if I mult by say 1.2 then divide by 1.2 > the display is > 10,000.000 How can I get 10,000.000 by just entering the number all the time? > I like to see tha comma separators. > On the hp48 I just set the mode to fix 3 and when I enter > 100000 I get > 10,000.000 David ==== > Whenever I use ON+C to reboot the calculator, > I lose my system font size setting and have > to re-set it every time -- none of the other > settings seem to be affected. This is rather > annoying -- think it'll be fixed in a ROM > update, or is there something I'm missing here? Store << FONT7 ->FONT >> into 'STARTUP' in the HOME directory. Then it'll set FONT7 automatically after each warmstart. Cool, huh? You can put almost anything you want into 'STARTUP' but be sure it's stuff that cannot possibly cause an error. A buggy STARTUP is a Bad Thing. My personal 49g+ STARTUP at this moment is << 256 ATTACH -62 SF 1000 ->KEYTIME >>. -Joe- ==== >It occurred to me that, with all the memory that's available on a >49g+, there isn't anything keeping one from storing a brief summary of >all available commands, to be utilized when trying something new. > Don't know if it is available (beyond the CAS Help) but definitely a good idea. Pete M. Wilson Gamewood, Inc. wilsonpm@gamewood.net ==== Doesn't seem like a good idea for the 49g+ - it removes the ' functionality making the default for ' be EQW (left over from 49G?). Pete M. Wilson Gamewood, Inc. wilsonpm@gamewood.net ==== --------------------------------------------------------------------- It was working fine, but now Windows does not recognize it. I rebooted, calc and PC, many (...many...) times... Any sugestions? Toby By the way, it's a 49G+ boundary=----=_NextPart_000_0014_01C3A4A1.675A58D0 ==== --------------------------------------------------------------------- Did you download the latest greatest USB driver? If so, have you rwmoved and reinstalled them? It was working fine, but now Windows does not recognize it. I rebooted, calc and PC, many (...many...) times... Any sugestions? Toby By the way, it's a 49G+ ==== --------------------------------------------------------------------- I thought I had installed it, but I had just downloaded it without updating the old driver. So, I just did. However, It seems that the cable is defective. I I mess with it a little before connecting it, it detects fine. I'll replace it as sonn as I find one. Toby Did you download the latest greatest USB driver? If so, have you rwmoved and reinstalled them? It was working fine, but now Windows does not recognize it. I rebooted, calc and PC, many (...many...) times... Any sugestions? Toby By the way, it's a 49G+ ==== Bugzilla is web based bug tracking software developed by mozilla.org for tracking bugs for the Mozilla browser. It's open source and freely available. Not sure if that's what you were asking... > > > Beta testing program?... > > A.L. ==== > >> Anyway I'm afraid we will never see this changes made to the 49g+. > >Yes, it's quite unlikely, unless they hire a CAS developer. > > You seem to implicate, that Mr Parrise and the rest of the team, which > developed the CAS of the HP49G(+) could not be called CAS > developers? > > Mathias Is the CAS ever currently further developed? I haven't known of much for updates besides what changes in hp49g* rom versions. Ed Sutton ==== > Anyone looking for an SD card, see this thread at the Museum Forum: > > http://www.hpmuseum.org/cgi-sys/cgiwrap/hpmuseum/forum.cgi?read=45314 now that the link expired, is the deal still good here? i thought it ended on the 11th or something but i dont have the message anymore and i think for that price its worth it =P (and i received my 49g+ since then so i now have the use) Ed Sutton ==== My 49g+ locks up whenever I exit from NOON (a routine in timeman). Any key I press causes an OFF (system shuts down.) Now when I attempt to turn it back on by pressing the ON key, it goes on for 2 seconds and then shuts off automatically. Sometimes, if I am very fast and very lucky, I can force a warmstart by pressing ON and immediately after pressing C (F3). Unfortunately this does not always work. In these occasions I have to reset by inserting my Hewlett-Packard Corporate-Issued System Reset Actuating Tool, otherwise known as a paperclip. Up to now I have always been able to reset the system. But I hold my breath every time. : >Wolfgang- : >Your HP49G+ page one of the first I checked out : >when I did a search a few days ago. Looks like you've : >got a good selection of tools there for download. Are all : >of the tools listed on your page 49G+ compatible? : : : >My question to you is this: I've not been able to find : >information on the commands and arguments required for : >the built-in libraries 256 and 257. Can you provide info : >or links to same? Are there any other built-in libraries : >that I'm not aware of? : : There are a lot of built-in libs. But these are the only two which are : not attached automatically. However, they are attached by the library : OT49+. Some of the commands of this libs are easily understood. But the : majority need some knowlegde of the operating system. Unfortunately, I : don't know a document which explains them to the normal user, not to the : hacker. Maybe somebody knows? : : - Wolfgang : http://page.mi.fu-berlin.de/~raut/WR49 ==== > My 49g+ locks up whenever I exit from NOON (a routine in timeman). Any key I > press causes an OFF (system shuts down.) Now when I attempt to turn it back > on by pressing the ON key, it goes on for 2 seconds and then shuts off > automatically. Sometimes, if I am very fast and very lucky, I can force a > warmstart by pressing ON and immediately after pressing C (F3). > Unfortunately this does not always work. In these occasions I have to reset > by inserting my Hewlett-Packard Corporate-Issued System Reset Actuating > Tool, otherwise known as a paperclip. Up to now I have always been able to > reset the system. But I hold my breath every time. system that has to do with its tendency for bouncing user-assigned keys. There is no bug in Noon or Timeman. It runs perfectly on the HP49. Noon will not lock up the way you described when exiting Noon by pressing a key very short (staccato). If an unshifted key is assigned, e.g., with a long-hold functionality, you are in danger. The only fixing which comes to my mind at present is to have a real about 500 in KEYTIME to prevent bouncing. But this may make the keys somewhat slower. Fortunately, this type of locking up of the 49+ is harmless. One has to use a paper-clip to provoke a warmstart. But no key assignment is lost and date&time are still correct. This type of a lock-up never happened on the 49. It occurs often and has nothing to do with Noon. I'm already used to it and fixed a paper-clip on my pullover :-) - Wolfgang > : >Wolfgang- > : >Your HP49G+ page one of the first I checked out > : >when I did a search a few days ago. Looks like you've > : >got a good selection of tools there for download. Are all > : >of the tools listed on your page 49G+ compatible? > : > : > : >My question to you is this: I've not been able to find > : >information on the commands and arguments required for > : >the built-in libraries 256 and 257. Can you provide info > : >or links to same? Are there any other built-in libraries > : >that I'm not aware of? > : > : There are a lot of built-in libs. But these are the only two which are > : not attached automatically. However, they are attached by the library > : OT49+. Some of the commands of this libs are easily understood. But the > : majority need some knowlegde of the operating system. Unfortunately, I > : don't know a document which explains them to the normal user, not to the > : hacker. Maybe somebody knows? > : > : - Wolfgang > : http://page.mi.fu-berlin.de/~raut/WR49 ==== I own a 48GX and now a 49G+, and I have a question: I like the custom menu feature (which is why I can't believe that it's shifted on the new calc), and I'd like to include an entry for the HP Solver (the one that comes up with left-shift+7, ROOT, SOLVR. To get it to work, I had to use {SOLVR <<30.01 MENU>>} as an entry in the list. This works fine, but does not display the little tab above the entry in the menu. Is there any way to get it to show up? Russ ==== With my new 49G+ I've tried to do the backup under the file menu in Conn4X. The result is a pop-up message that it can't find the file Arch49.hp2. Am I missing something here? Greg ==== Build 1783 hasn't got the file included. Need to install the previous build and copy it over. Btw, even with this file I've been unable to take a backup from the HP49G+, works fine with the Hp49G though. Dave > With my new 49G+ I've tried to do the backup under the file menu in Conn4X. The result is a pop-up message that it can't find the file Arch49.hp2. Am I missing something here? > Greg ==== I guess I'll wait and see if this gets fixed in a later version. Greg > Build 1783 hasn't got the file included. Need to install the previous build > and copy it over. > Btw, even with this file I've been unable to take a backup from the HP49G+, > works fine with the Hp49G though. Dave > With my new 49G+ I've tried to do the backup under the file menu in > Conn4X. The result is a pop-up message that it can't find the file Arch49.hp2. Am I missing something here? > Greg ==== You're right, I was throwing in too many ideas here. I am too opinionated especially when it comes to what areas of math should be taught when to whom. I do not know about Europe or Asia, really, but here in the US, the teaching of math to younger students is no longer coherent and focused in my opinion. I may be also a victim! This may be why I relate separate issues! Also, as in science, current understanding of people in industry or research of the importance of certain issues in math don't seem, at least here in the US, to filter down to the lower educational levels. This is probably one reason why HP has a harder time selling their version of calculators to most students. (If I offend anyone, I apologize in advance!) Still, I see your point. > >> Let's get even more fundamental- the nontechnical coworkers of the >> engineers and draftsmen all understand what a 180 degree turnabout is; >> they know 90 degrees (I'm not sure about 0 degrees, however), but they >> all think pi is something their auntie makes for them on a holiday. >> And then there are kids- students, pre-teenagers really, beginning to >> receive instruction on angles and circles. I think radians, polar >> coordinates, etc., are kind of beyond the complete grasp of most kids >> that age, no matter how bright, except for the gifted few. > > > You are mixing two different notions, radians and polar coordinates. > I believe that the perimeter of a circle expressed as pi*diameter > is teached in primary school. Therefore I don't see any reason > why a child who understands the perimeter of a circle would not > understand the measure of an arc of circle, and therefore the > measure of the corresponding angle in radians. It's just because > teachers are so used to degrees that they teach degrees before > radians. Polar coordinates is much more complex, and should > not be taught before say 15 years when people understand what > coordinates are. > ==== > But, when i speak of power, what i mean is how well the language fits > the hardware. Ill explain; Even though c++ (for example) is a very > nice language that can solve tons and problems and do many many many > things, if used in a regular calculator i assume that due to limited > RAM and processing capabilities, it would not be to efficient. Right. And the TIGCC team has made it clear that they are not going to even try to support C++ programming (because of extremely bloated code, among other things). > In this case, RPL is designed for use with RPN calculators, working > optimumly with limited RAM, each program consuming very little space. One can optimize C code as well... -- Bhuvanesh ==== > I don't consider your comparison to be correct, because the > game does not interfer with the rest of the applications. I agree, it would be really nice if the CAS did not interfere with the rest of the calculator system... > You will not for example use a result of the game that would > depend on the screen resolution in your spradsheet. I might. Why not? > The CAS answer after the CAS command that switched the mode > will be used in another command or displayed so that the user > will read it and it has a meaning depending on this flag. Let's cut through your obfuscation, why don't we? Here's an example: I am in numeric results mode, but for some reason I want to know what the integral of sin(x) is, a result which I may use later in order to obtain some numeric results. So, in order to do the integration, the CAS switches the flag, finds the result, and switches the flag back. Would you like to explain to me what would, or even could, be wrong with that result? Or, in what way the interpretation or meaning of that result would depend on any sort of flag setting? By the way, believe it or not, a TI89 will give you a result for your symbolic integral even if you switch it from automatic to numeric mode. How about that? And don't get me started on the kind of nonsense that happens on the HP if you select complex mode. I'll give you a hint: If I select complex mode, I might indicate that I _allow for_ complex results. It does _not_ mean that I want the CAS to take great pains in order to produce a complex result even if a much simpler real result is available. Again, that is something that all professional CAS, including the one on the TI calculators, seem to understand. On the HP, on the other hand, you have to be careful to try and always stay in real mode, if you want to avoid getting silly complex results even for things as straightforward as the integral of x*cos(x), say. And god help me if I happen to stumble upon a calculation where the CAS decides it needs to switch to complex mode, and I forget to switch back to real mode before trying to find a simple antiderivative... In short, the HP CAS is a mess, and essentially unsuitable for any market that one might target with such a device. I might add that I used to think that much of the fault for that lies with the poor overall management of the HP49G project, but you are telling me in no unclear words that a good part of this mess is in fact intentional, and by design. -- Helen. ==== > > The interesting question should be: given someone who does not know > any CAS system, and knows enough math to understand what really happens, > would he find my mode switches really silly? > > Yes, that is the question. The answer to the question actually has > little to do with whether or not we are talking about a CAS, or some > other system. This is a question as to how one should design user > interfaces in such situations. I'll give you an example: When you run > a game on a PC, often times the design of the game may require that > you switch resolutions and/or color depths of the display. All the > games that are on the market (all current ones, anyway) handle this in > such a way that, potentially after asking the user (there is nothing > wrong with asking, of course), the resolution is switched, and, once > the user quits the game, the graphics configuration in effect before > the game ran is restored (but not restoring the graphics configuration > would be considered inane). Hold it... That comparison is way off. Your talking about PC games. PLatform games like Mario Advanced pretty much dont have those settings. But PC games do. Now, i say your comparison is off, because a PC game is made, well for a PC, anyone that meets certain requirements. A game that needs 8 MB RAM and a pentium processor can run on a machine that has 8 MB RAM and a pentium processer as it can also run on a Pentium 4 with 1 GB RAM. The monitors used in different PCs, the OS settings, so many things that can influence potential resolution outcome. Unlike that, the HP 49g CAS is made... well for the HP 49g. So, I will slightly modify your comparison. I will compare it to a game like you did, just that it will be a platform game, a game made for a portable device, Mario Advanced (just an example). Lets say, that one gets used to certain controls. If at a certain level or for some reason, the controls have to be changed, then the user should be told so. If not, marios behaviour would be strange and wrong. You say it would be a good idea to change back the controls?? FINE CHANGE EM BACK WHATS THE BIG DEAL??????????????????????????????????? ==== > PS: Bhuv where ya from?? Just curious. India, originally, but I've been in the US since about mid-1995 (just when the Internet was getting really popular). -- Bhuvanesh ==== > > Yes, so why don't you restore the flags after the command is done? > What I am saying is that there are no issues of the kind one might > perceive for the degrees/radian switch for these flags. You know this > very well, and yet you try to suggest to people (apparently > successfully to some of the more naive participants in this thread) > that there is a rational reason not to restore the flags. There are many rational reasons. My personall favorite is to avoid mistakes.My friend who used another brand of calcs, you can guess which one im talking about, failed miserably in a 2 question phjysics exam because he couldnt correctly use trigs... why?? negative, weird and wrong answers.... IT was working with radians and he didnt notice. Worst thing is he didnt switch to radian mode. Hell, it wasnt even in radian mode!! I forgot what function he was using for that error, but, if you ask me, id rather be warned. >As I have > said before, there is no other CAS in common use that requires the > kinds of silly mode switches that yours has. Why do you think that is? > > > The interesting question should be: given someone who does not know > any CAS system, and knows enough math to understand what really happens, > would he find my mode switches really silly? > About approx mode, I believe that the TI89 solved this using AUTO mode, > following the blackbox-CAS philosophy I don't like. I think it is much > preferable that students are confronted to the problem > of choosing exact/approx mode as soon as possible. Remember that > I developped the 49G CAS as a mathematical pedagogical tool. Personally, about exact-aprox mode... I have no problems with that. It allows more customization, if thats what youll call it. When i enter, lets say 60 SIN, i get the answer v/3/2 (square root of 3 halves) in exact mode, and an irrational decimal number in aprox mode. Its detail like these that make the user dependace worth while. Not to mention it also affects the way expressions are evaluated... With some AUTO mode i would probably never get the answer i want when working with polynomials and stuff like that. ==== > There are many rational reasons. My personall favorite is to avoid > mistakes.My friend who used another brand of calcs, you can guess > which one im talking about, failed miserably in a 2 question phjysics > exam because he couldnt correctly use trigs... why?? negative, weird > and wrong answers.... IT was working with radians and he didnt notice. > Worst thing is he didnt switch to radian mode. Hell, it wasnt even in > radian mode!! I forgot what function he was using for that error, but, > if you ask me, id rather be warned. It can't have been working with radians in degree mode (or vice versa) unless your friend specifically asked it to. > Personally, about exact-aprox mode... I have no problems with that. It > allows more customization, if thats what youll call it. > When i enter, lets say 60 SIN, i get the answer v/3/2 (square root of > 3 halves) > in exact mode, and an irrational decimal number in aprox mode. Its > detail like these that make the user dependace worth while. Not to > mention it also affects the way expressions are evaluated... With some > AUTO mode i would probably never get the answer i want when working > with polynomials and stuff like that. You could always set it to EXACT or APPROX if you want. I personally prefer the AUTO mode. What do you mean when you say, working with polynomials? Solving polynomial equations? -- Bhuvanesh ==== > There are many rational reasons. My personall favorite is to avoid > mistakes.My friend who used another brand of calcs, you can guess > which one im talking about, failed miserably in a 2 question phjysics > exam because he couldnt correctly use trigs... why?? negative, weird > and wrong answers.... IT was working with radians and he didnt notice. > Worst thing is he didnt switch to radian mode. Hell, it wasnt even in > radian mode!! I forgot what function he was using for that error, but, > if you ask me, id rather be warned. > > It can't have been working with radians in degree mode (or vice > versa) unless your friend specifically asked it to. Really?? Im not so sure about that. There are some things that just wont work with degrees. There sort of an obolete unit if you ask me, but still should be used. I mean theyre pretty usefull. > > Personally, about exact-aprox mode... I have no problems with that. It > allows more customization, if thats what youll call it. > When i enter, lets say 60 SIN, i get the answer v/3/2 (square root of > 3 halves) > in exact mode, and an irrational decimal number in aprox mode. Its > detail like these that make the user dependace worth while. Not to > mention it also affects the way expressions are evaluated... With some > AUTO mode i would probably never get the answer i want when working > with polynomials and stuff like that. > > You could always set it to EXACT or APPROX if you want. I > personally prefer the AUTO mode. What do you mean when you say, > working with polynomials? Solving polynomial equations? Ill give you an example. Lets say X^2+2*v/3x+3 FACTOR Exact mode: (X+v/3)^2 Aprox Mode: (X+1.7320..,)^2 Auto Mode: ???????????????????????? My point is that its easy to get undesired answers. So, auto mode isnt a must IMO. ==== > Ill give you an example. Lets say > X^2+2*v/3x+3 > FACTOR > > Exact mode: (X+v/3)^2 > Aprox Mode: (X+1.7320..,)^2 > Auto Mode: ???????????????????????? I don't know what you were doing, but I get the same result as for exact mode. The HP, on the other hand, will not factor your expression at all when in approximate mode. > My point is that its easy to get undesired answers. So, auto mode isnt > a must IMO. The only point of your example that I can see is that it is easy to get undesired answers if you do not have any clue at all of what it is you are doing. -- Helen. ==== > Ill give you an example. Lets say > X^2+2*v/3x+3 > FACTOR > > Exact mode: (X+v/3)^2 > Aprox Mode: (X+1.7320..,)^2 > Auto Mode: ???????????????????????? In AUTO mode, you would get an exact result unless you put a decimal point in, say, sqrt(3.), or you do approx(factor(...)) > My point is that its easy to get undesired answers. So, auto mode isnt > a must IMO. Not a must, but it usually gives me what I want, just like the autosimplification (let's not start another discussion on the latter, please :)) -- Bhuvanesh ==== I received my new 49G+ today and have been playing around a bit and it is much better than I thought. The keyboard didn't register the 'X' key very well at first but now it seems to work OK. Anyway, the 'X' is I believe the most useless of all. Then I tried to observe the flicker but didn't manage to see it until I realised that it was actually pixels changeing from black to extremely dark grey. I really had to look. I haven't seen the earthquake yet. The feeling of the calc is quite hollow but that is fine. I don't like the pouch it makes the calc twice as big as it already is. However, it looks expensive, very Chinese like, and the calc can fit in the 48 pouch to take less space. I didn't have any problem with the connection kit, except for a warning that the driver is not XP certified or something. Although it looks like I should connect an Xpander not a 49+. The ROM update was really fast compared to the 49 but a bit tricky, especially finding out that the + and - button is not the +/- button but the + button and the - button. I haven't tried the SD card yet as I don't have one. (Until this weekend). So I should be a happy hp customer. Still a few details bother me. The header can be changed to display 2 , 1 or 0 lines however, it is still 2 lines high. I hope this will be fixed. It may be for 49 compatibility purposes but when we switched from the 48 we had to recompile the programs we could afford to add 2 ->HEADER EVAL for the 49+. When I went in to the graphic mode (left key) the display is lightly striped at the edge of the 6 menu columns and when moving the cursor (arrow key maintained) it kind of gets slowed down by those stripes. And now how I finally managed to go back in time with my new 49+. I wanted to see if the analogue clock was still so useless so I displayed it. It showed me 7:45. Then it moved to 7:50 and for a second came back to 7:45. After seeing that I checked the time, it was 19:50... I set my calc to 19:49 and watched I could not repeat. I guess it is linked with the random blinking of the column in the time. Hopefully this will be fixed. And to finish, something that is worrying me. My 49 came with 3 Chinese Energiser batteries my 49+ came with 1 and 1/2 pack of 2 GP super alkaline chinese batteries apparently made for eastern European markets. This looks cheap, especially the 1 and 1/2 pack. But what worries me is that Chinese batteries contain much more mercury (I think it is mercury but could be an other nasty metal) than is allowed in many countries. They have a lot of batteries are legal? Arnaud ==== oN 06-Nov-03, Arnaud Amiel said: > The ROM update was really fast compared > to the 49 but a bit tricky, especially finding out that the + and - > button is not the +/- button but the + button and the - button. Ah, so I'm not the only one who did that! -- Bill ==== Where did you buy it? > I received my new 49G+ today and have been playing around a bit and it is > much better than I thought. > The keyboard didn't register the 'X' key very well at first but now it seems > to work OK. Anyway, the 'X' is I believe the most useless of all. > Then I tried to observe the flicker but didn't manage to see it until I > realised that it was actually pixels changeing from black to extremely dark > grey. I really had to look. ==== > Where did you buy it? > www.classiccalculators.com But I can't say if I was lucky or they have a good batch. Arnaud ==== We at classic calculators got 30 of these units a few days ago. After all the issues I had read about I personally tested each and every unit before sending them out to customers. We rejected 3 units out of the 30, 2 with keyboard problems and one dead on arrival. All the units were upgraded to Rom 1.22 before we sent them out. Haven't had any customer returns yet but have had quite a few phone calls about various aspects of the calculator (mostly user issues). One customer called with an apparently DOA calculator but new batteries put this right. I think we may well ship all future calculators out with Duracell batteries replacing the questionable ones in the box. We are getting 30 Hp 17Bii units in next week (not the plus) Classic Calcualtors www.classiccalculators.com > Where did you buy it? www.classiccalculators.com But I can't say if I was lucky or they have a good batch. Arnaud ==== > > > >>>But just how standard is USB? It looks to me as if each client device >>>needs its own driver on each host that it connects to. That's not my >>>idea of standard. >> >>I don't think that is a fair criticism of USB. If I plug in any RS-232 >>device to a host, how well will it work without software? It is true >>that many USB devices have special drivers, but that is because of the >>nature of the device, or sometimes the poor implementation of their >>USB service. New digital cameras that use direct USB connection are an >>example of USB done right - they act just like a USB hard drive, and >>that makes sense considering the typical use of the connection. If the >>only purpose of the 49g+ interface was to send and receive files, >>there is no reason hp couldn't have implemented it as a USB disk drive >>and not required any driver. > > > This would be a good idea, if it was (easely) feaseable... > > Let me explain USB drive use a sector type of interface. ie: the pc asked > for sector n of the hard drive and the sector is transfered to it, exactly > as on an IDE drive. > The PC then handles the files as a file system > > now, for a digital camera, no problem, they have a SD card, or similar in > them and they send the sector requested by the PC from the SD card. > > on a hp calcualtor, there is a file system, yes, but it is COMPLETLY > different from the PC file system. what would the calcualtor do when the pc > request sector 0 (partition table)? well, it could, on the fly create a fony > sector and send it to the pc... what does the calcualtor do when the pc > require the FAT? well, same thing... > > up to here, all is good.... > now, what happen when the PC read files? no problem again (I mean appart > from the implementation that is starting to get tricky), it can generate > something that looks like a hard drive from the internal file system... > > now, the PC starts to send writing orders on sectors for the calculator... > what does the calculator do with them? well, this starts to get dificult, > because these sectors are not linked with any file, and the calc does not > know about sectors, only of files... well, let us save them (how many will > we save? who knows).... > anyway, at one point in time, the PC sends modifications to the FAT and the > root directory, the calc can now go back on all the data received, make > sense of it and transform everything back in calc files! ouf... (this > include for example a file open for read/write and modified in the middle, > files moved from A to B, directory changed (remember, on the calc, a > directory is also a file... how does the PC deal with that)....) > > mind you, in this scenaro, how does the calc manage memory? oups... because > as it need memory to work, but also needs memory that is the free memory > on the hard drive... but as a hard drive can not resize itself, this will > not work... > again, what happends when the PC starts a defrag? that can not possibly make > sense for the calcualtor... > > > what I mean is that the idea is excelent, but unfortunately, not > implementable due to the legacy of the HP48G file system... Ok, I'm well aware that the file system inherited from previous calculators is very different from the file system used on a hard drive (and the SD card). And the file system inherited from previous calculators is too well suited to a calculator to discard. I guess replacing it would mean scrapping RPL too, and I certainly don't want to ever see that. And I'm aware the the 49g+'s handling of the file system on the card is, so far, not up to what we'd like,; the inability to create subdirectories, for a start. But surely the 49g+ isn't totally ignorant of the SD card's file system either. I mean, it apparently can and does read to and write from directory entries, the FATs, and the appropriate clusters, and it can format the card. Obviously it gets information about the card's format from the boot record, and even information about the card is kept in the 49g+'s operating system when it's not actually accessing the card. Maybe the 49g+ could totally hand control of the card to the PC when it's accessing the card via USB? Of course, if the 48g+'s operating system is keeping information about the card in memory, it would have to be refreshed when control were handed back, but I suppose that this has to be done any time that a card is inserted anyway. By the way, I've been turning the 49g+ off when removing or inserting the card, but wonder whether that's necessary. Is the card supposed to be hot-pluggable? Just a few stray thoughts, and I'm glad that you guys know more about it than I do. -- James ==== > > >>But just how standard is USB? It looks to me as if each client device >>needs its own driver on each host that it connects to. That's not my >>idea of standard. > > > I don't think that is a fair criticism of USB. If I plug in any RS-232 > device to a host, how well will it work without software? I think that as a general rule, the firmware/software to configure the serial (RS-232 or similar) port and send or receive data is built into the device or its operating system. Sort of like a driver, except that I don't have to add separate firmware/software to connect to a different device. A terminal emulator works fine for sending and receiving from the 48 series. Heck, even the DOS COPY command will work. For something more than transferring a simple short data stream, like a file transfer, I'll probably want more appropriate software. Sort of like Conn4x, except that Conn4x seems to be specialized for a few calculators. With Kermit or Xmodem, for example, I can transfer to and from quite a variety of devices, as long as they have the matching software installed. > It is true > that many USB devices have special drivers, but that is because of the > nature of the device, or sometimes the poor implementation of their > USB service. New digital cameras that use direct USB connection are an > example of USB done right - they act just like a USB hard drive, and > that makes sense considering the typical use of the connection. If the > only purpose of the 49g+ interface was to send and receive files, > there is no reason hp couldn't have implemented it as a USB disk drive > and not required any driver. Well, maybe. I see that Cyrille has already responded to this part. I'm not sure of all that the USB port is supposed to be able to do. The documentation leaves a lot to be desired. The Conn4x and USB driver combination doesn't work on my PC yet, except for updating the flash ROM. For example, are we supposed to be able to print (to a terminal emulator) via USB? Or use the XMIT and SRECV commands via USB? -- James ==== > 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. > > Doesn't the HP48GII offer exactly what you need? If I'm not mistaken, > it has the same RS232 port as the original HP48SX/GX. > > -Joe- Unfortunately, they have significantly changed the serial port on the GII. It no longer works with many (possibly a majority of) RS-232 devices. Bob ==== > 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. > > Doesn't the HP48GII offer exactly what you need? If I'm not mistaken, > it has the same RS232 port as the original HP48SX/GX. > > -Joe- Unfortunately, they have significantly changed the serial port on the GII. It no longer works with many (possibly a majority of) RS-232 devices. Bob ==== The HP calculator entry database now also covers entries for HP38G, HP39G/40G/39G+. See http://zon.astro.uva.nl/~dominik/hpcalc/entries/ who have answered my questions about the HP39G There are still quite a few HP39-related entries in the database for which I have no idea what they do. If anyone is interested to help with this, please contact me at dominik at science dot uva dot nl - Carsten ==== Good job :) The HP calculator entry database now also covers entries > for HP38G, HP39G/40G/39G+. See http://zon.astro.uva.nl/~dominik/hpcalc/entries/ who have answered my questions about the HP39G There are still quite a few HP39-related entries in the database > for which I have no idea what they do. If anyone is interested > to help with this, please contact me at dominik at science dot uva dot nl - Carsten ==== as I said already, MIG is dead on the 49+. However, solo pieces may run if properly programmed. I reprogrammd the solo part of J.S.Bach's violin concert E major for the 49+ in the file JSBachP which may be loaded from my site below. During the performance (about 10 minutes) the tempo can be changed with [+] and [-]. Ritardandi and accelereandi are preerved. A note to JYA who recommended to buy a Cyrus CD7 CD-player to enjoy the recordings of the Berlin Philharmonic orchestra: I've several CD-players, but none can compete with the HP49. Do you know how fascinated are some musical girls with technical intelligence if listening to classical music from a hightec calculator not at all destinated for that? :-) - Wolfgang http://page.mi.fu-berlin.de/~raut/WR49/index.htm#Music PS. Some information: The buzzer is controlled by the ARM9 directly. Hence, display refrech does not affect the 49+ sound quality anymore. Clearly, the built-in clock must be turned off by any music program. Nontheless, it seems that the 49-sounds are nicer and more precise. ==== Bravo maestro! 8-D > as I said already, MIG is dead on the 49+. However, solo pieces may run > if properly programmed. I reprogrammd the solo part of J.S.Bach's violin > concert E major for the 49+ in the file JSBachP which may be loaded from > my site below. During the performance (about 10 minutes) the tempo can > be changed with [+] and [-]. Ritardandi and accelereandi are preerved. A note to JYA who recommended to buy a Cyrus CD7 CD-player to enjoy the > recordings of the Berlin Philharmonic orchestra: I've several > CD-players, but none can compete with the HP49. Do you know how > fascinated are some musical girls with technical intelligence if > listening to classical music from a hightec calculator not at all > destinated for that? :-) - Wolfgang > http://page.mi.fu-berlin.de/~raut/WR49/index.htm#Music PS. Some information: The buzzer is controlled by the ARM9 directly. > Hence, display refrech does not affect the 49+ sound quality anymore. > Clearly, the built-in clock must be turned off by any music program. > Nontheless, it seems that the 49-sounds are nicer and more > precise. ==== > > Just checked out your calculator comparison page. In equations 1-4, I > can confirm the results you got with the HP-49G emulator, but luckily > the real HP-49G that I own gives essentially identical and correct > results like the 49g+. The emulator is clearly screwed up in these > cases! > To Mike & Daniel: Strange that this gratuitous comment has been left unchallenged for so long. I'd check the emulator's ROM version (VERSION) and flag settings (RCLF) if I were you.. The emulator *runs the same ROM* and will therefore show the exact same results under the exact same conditions, period. If it's not the case, then *you* have screwed up. Werner he made me save so far. ==== > > Just checked out your calculator comparison page. In equations 1-4, I > can confirm the results you got with the HP-49G emulator, but luckily > the real HP-49G that I own gives essentially identical and correct > results like the 49g+. The emulator is clearly screwed up in these > cases! > > > To Mike & Daniel: > Strange that this gratuitous comment has been left unchallenged for so > long. > I'd check the emulator's ROM version (VERSION) and flag settings > (RCLF) if I were you.. > The emulator *runs the same ROM* and will therefore show the exact > same results > under the exact same conditions, period. If it's not the case, then > *you* > have screwed up. I mentioned in my post that both the emulator and real 49G had the same ROM version (1.19-6), however I did not perhaps rigorously enough check flag settings and such. I will do a memory reset on both my real 49G and emulator later tonight to check the results again. It may have been strictly a coincidence that both Daniel and I achieved exactly the same results. I had thought it plausible that the emulator's implementation of some underlying Saturn math routines might be ever so slightly different than a real Saturn processor, where this difference might only be obvious for extreme cases when the last significant digit of precision has a large bearing on the outcome of a calculation or plot. Of course, I am no expert on emulation software or on the low-level details of HP's math routines, so that assumption may have been naive. > > Werner > he made me save so far. Based on the above comment, it sounds like you have used emu48 a great deal more than I have! ;-) If I was a bit hasty in making my emulator is screwed up comment, then I apologize. I will do a more careful comparison soon. Mike Mander ==== > 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. -Joe- > > It takes about 0.6 seconds (roughly: calculator in one hand, stopwatch in > the other) on my TI-89. > > -MrM Doing an actual timing on the calculator, I get about 0.42 seconds. -- Bhuvanesh ==== Can someone tellme if there is a french HP calculator newsgroup. ==== You mean, a freedom HP49 NG? Toby > Can someone tellme if there is a french HP calculator newsgroup. ==== ludo a .8ecrit > Can someone tellme if there is a french HP calculator newsgroup. Salut, Ce groupe est international, avec langue d'usage=anglais. Pas de newsgroup fr usenet en tant que tel. Tu as cependant fr.comp.sys.calculatrices, qui est multi syst.8fme mais avec des utilisateurs HP, et les forum de sites tels que www.HP-sources.com . A+ ==== Salut Ludo, ludo a .8ecrit > Can someone tellme if there is a french HP calculator newsgroup. > Salut, > Ce groupe est international, avec langue d'usage=anglais. > Pas de newsgroup fr usenet en tant que tel. > Tu as cependant fr.comp.sys.calculatrices, qui est multi syst.8fme mais avec > des utilisateurs HP, > et les forum de sites tels que www.HP-sources.com . > Le mieux est peut-etre de poster dans fr.comp.sys.calculatrices. le forum de www.hp-sources.com n'est pas pas tr.8fs pratique .88 mon avis. Maintenant des messages en allemand ou autres passent aussi sur comp.sys.hp48 sans d.8echainer les foudres de nos amis anglophones... Donc si ce groupe est international, je ne vois pas pourquoi on y causerait pas aussi en italien, allemand, fran.8dais, espagnol ou esperanto ;-) Tu as d.8ej.88 une 49g+ ? Gilles ==== Il y a aussi le serveur news.zoy.org qui accueille quelques groupes. ==== > One feature request I would like to make of User RPL though: now that > we have lots of RAM and SD memory, why not add the ability to comment > one's programs ?!! HP? Are you listening...? You can comment UserRPL code when you develop it on a PC. During a Kermit > upload, the calculator will not only translate the << etc. trigraph > sequences to their RPL words, but also discard everything between @ and > newline. As you know, the programs are compiled during upload, so all formatting and > comments are lost. If you really want commented code on the calc, you may > want to keep source code as string object, or use comment DROP sequences, > both of which may be waste of memory. This is the only case I know where comments DO slow down programs and make them bigger :-) ==== > If you really want commented code on the calc, you may > ... use comment DROP > sequences, > both of which may be waste of memory. > This is the only case I know where comments DO slow down programs and > make them bigger :-) Indeed, the ideal slow-down tool for programs which run too fast on the HP49G+ and to fill up all this unused empty memory :-) By the way, it is no problem to write a small program for the reserved variable betaENTER which does the following: While still in the command line, each time you press ENTER on your commented program string, your source is not only nicely compiled but at the same time, a copy of the source with all its comments is saved automatically on the SD-card. ==== > > [...] > One feature request I would like to make of User RPL though: now that > we have lots of RAM and SD memory, why not add the ability to comment > one's programs ?!! HP? Are you listening...? > > You can comment UserRPL code when you develop it on a PC. During a Kermit > upload, the calculator will not only translate the << etc. trigraph > sequences to their RPL words, but also discard everything between @ and > newline. the past, but would (optionally) also like the comments to persist inside the calculator as well. Specifically, I would like the ability to make changes to my code on-the-fly, in the calculator, and then be able to seamlessly download the changes back to my PC for backup without losing all the original comments in the process. If memory in the calculator is tight, one could then strip the code of comments inside the calculator if needed (with a new STRIPCOMM function or something) to reclaim some precious memory space. > As you know, the programs are compiled during upload, so all formatting and > comments are lost. If you really want commented code on the calc, you may > want to keep source code as string object, or use comment DROP sequences, > both of which may be waste of memory. I have thought of such workarounds for commenting code as well but they are inelegant solutions at best. I don't mind the wasted memory since I would expect that from keeping comments in any case, but I wouldn't want the slowdown of constantly pushing and popping strings to/from the stack during program execution. I realize that until recently, HP's haven't really had enough memory to afford liberal use of source code comments, so I am not critisizing their current absence. Rather, it is just another feature request that (I feel) may be useful to add on in the future. > > Georg. Mike Mander ==== > I realize that until recently, HP's haven't really had enough memory > to afford liberal use of source code comments, so I am not critisizing > their current absence. Rather, it is just another feature request > that (I feel) may be useful to add on in the future. it would perhaps be better to think before posting :-) It is obvious that comments on any source code should *not* occur in a compiled program (thrown away during execution, say). An advantage of the SD-card is that you can keep in it your commented source code forever, with as many comments as you want. That was previously possible only on cost of built-in port memory or if programming with Debug4x which saves everything on a PC. Be happy that this is no problem anymore on the 49+, even for very large projects. - Wolfgang ==== > I realize that until recently, HP's haven't really had enough memory > to afford liberal use of source code comments, so I am not critisizing > their current absence. Rather, it is just another feature request > that (I feel) may be useful to add on in the future. > > it would perhaps be better to think before posting :-) > It is obvious that comments on any source code should *not* occur in a > compiled program (thrown away during execution, say). An advantage of I totally agree, one would not want the unnecessary overhead of skipping over comment sequences in a running program and I am not suggesting a simplistic implementation that would cause program execution to slow down. Despite the fact that I've been using HP-48/49 calculators for over ten years now, I consider myself a newbie in comparison to all the experienced people in this group. Therefore, what I am about to suggest may not be feasible on the 49g+, but how about this: When a UserRPL program gets compiled, whether from pressing Enter in the built-in editor or when transferring a text file from a PC, the compiler could strip out each comment sequence and place it in an array, in system memory somewhere, that is tied to that particular program with an index for each comment string indicating its position in the code. That way, there is no overhead during program execution, just more overhead during the compile phase - and of course memory overhead for the saved comments. Subsequently, when a program is decompiled during transfer back to the PC or when it is opened with the 49's built-in editor, the decompiler would place the comment sequences back into the displayed code at the correct positions. Obviously, the compile and decompile would be slowed by the need to take out and add in comments, but with a 75MHz ARM at our disposal now, couldn't that be a relatively quick process? I admit that there are more pressing things that need work on the 49g+, so I suppose something like this would be very low on the priority list. As well, maybe I am the only one here who would like to see something like this implemented? As I mentioned in my long post, I only have experience in UserRPL and not SystemRPL or Saturn Assembler and thus lack a detailed understanding of the underlying hardware and system software. Therefore, my above suggestion may not even be technically feasible. > the SD-card is that you can keep in it your commented source code > forever, with as many comments as you want. That was previously possible > only on cost of built-in port memory or if programming with Debug4x > which saves everything on a PC. Be happy that this is no problem anymore > on the 49+, even for very large projects. > - Wolfgang Mike Mander ==== > 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 keys are better than the 49g, but the new one's noticeably hollow. It echoes! ==== I've a little problem(?) with the CAS of HP 49G+ (ROM version 1.22): when I try to obtain the indefinite integral of x*asin(x) I write: INTVX(X*ASIN(X)) And then I evaluate it (in the Equation Writer). After the computation I obtain ((2*x^2-1)*ASIN(X)+X*SQRT(-(X^2-1)))/4 that's the right solution (if I copied it in the right way...). Then, when I try to derive this function that I've obtained with the DERVX command, if I use this function after using of INTVX without leaving the equation writer, I obtain again X*ASIN(X); but if I put the result in the stack, and then I use DERVX, I obtain another solution: -ASIN(X)*SIN(2*ASIN(X))*SQRT(-(X^2-1)))/(2*((X+1)*(X-1))) In this case, I can't simplify it to X*ASIN(X), and I' like to know if there's some way to simplify this formula in the original form. Daniele ==== > Then, when I try to derive this function that I've obtained with the > DERVX command, if I use this function after using of INTVX without > leaving the equation writer, I obtain again X*ASIN(X); but if I put > the result in the stack, and then I use DERVX, I obtain another > solution: > > -ASIN(X)*SIN(2*ASIN(X))*SQRT(-(X^2-1)))/(2*((X+1)*(X-1))) > > In this case, I can't simplify it to X*ASIN(X), and I' like to know if > there's some way to simplify this formula in the original form. > > > Daniele Try TEXPAND -- Bhuvanesh ==== > qu'il r.8epond... Vous a-t-il r.8epondu ? La traduction reste toujours aussi foireuse. :-) Eh bien finalement, oui, .88 ma grande surprise. Voici ce que j'ai re.8du : -------------------------------------------------- Monsieur Gibbons, Hewlett-Packard (Suisse) S..88.r.l. travaille tous les jours pour actualiser ses pages Internet au service de ses clients. Nos sp.8ecialistes sont entrain de r.8esoudre le probl.8fme et nous vous demandons de consulter nos pages .88 une date ult.8erieure. Nous vous remercions de votre compr.8ehension et vous adressons nos meilleures salutations. --------------------------------------------------------- Ce qui ne r.8epond d'ailleurs pas .88 la question initiale : comment quelque chose d'aussi mauvais a pu se retrouver l.88 en premier lieu ? Jeremy Gibbons X-Face: #0?irvdFiM!(Tpl}/tO%_kuSW_^9G5aeIEnY1uNPcd@N_U.B30*[%N-cnqSC,rEfeqm:b oR({RM{x03]Iv}^2xc7J][^MkbL3DYdLevZ$&h0WbH!i:>O1i#FLy/mO2G~xMF *uQnfN4xre8v9%0fqg;i.!ymm~6w2nEx);Q~Q*8&dUO(fn ==== Jeremy Gibbons a pr.8esent.8e l'.8enonc.8e suivant : >>> qu'il r.8epond... >> >> Vous a-t-il r.8epondu ? La traduction reste toujours aussi foireuse. :-) Eh bien finalement, oui, .88 ma grande surprise. Voici ce que j'ai re.8du : -------------------------------------------------- > Monsieur Gibbons, > Hewlett-Packard (Suisse) S..88.r.l. travaille tous les jours pour actualiser > ses pages Internet au service de ses clients. Nos sp.8ecialistes sont entrain de r.8esoudre le probl.8fme et nous > vous demandons de consulter nos pages .88 une date ult.8erieure. > Nous vous remercions de votre compr.8ehension et vous adressons > nos meilleures salutations. > --------------------------------------------------------- Ce qui ne r.8epond d'ailleurs pas .88 la question initiale : comment quelque > chose d'aussi mauvais a pu se retrouver l.88 en premier lieu ? Jeremy Gibbons Pour la m.90me raison qu'on a laiss.8e sortir la HP49 -- Ceci est une signature automatique de MesNews. Site : http://mesnews.no-ip.com ==== All 113 programs do need to be visible to normal users, since they are all intended to be user-level functions. Is there at least an easy way to make a soft menu item have the little manila-folder-like tab that they use for directories and sub-menus? Other than that, writing a nesting menu program would be trivial. > >>What Cyrille hints at is using the library message handler for this, >>as described in Appendix B.2.3 of Programming in SystemRPL 2nd Edition. >>I have used this in the constant Tools Library >>(http://www.hpcalc.org/details.php?id=3179) to implemented left and >>right shift functionality for keys in the $VISIBLE menu. >>You can even completely ignore the $VISIBLE rompointers and >>install any menu you like through the message handler >>The only disadvantage is that this only work if you access the >>library menu through the LIBS key/menu. If you do 1234 MENU, the >>message handler is (unfortunately) not called. > > > Theoretically, the MENU (and TMENU) command could easily be expanded to > do the same as if pressing the corresponding LIB menu key which calls > the library number as a message handler my means of which one can create > the most complex menus programmed by $EXTPRG. But only very few people > use $EXTPRG because it assumes familiarity with SysRPL. Thus, > reprogramming probably doesn't pay for the developers. > > First of all, Christopher has to know whether all his 118 visibles are > needed as visible rompointers. This is the case only if others should > use them in their programs or key assignments. The ones executable only > by key need not necessarily be rompointers but just menu names. > > Secondly, he has to know how the built-in menu system is organized - > very similar to that of a complex CST menu with subdirecties. Knowing > the latter would even suffice though some details may not be documented. > > There is still the possibility of destinating a special rompointer, call > it MkMenu, which sets the desired menu with all its subdirectories. This > is done in Timeman, for instance. The command Aset sets here a > particular menu related to alarms whose options need not be > programmable. This keeps the number of visible rompointers in a library > small. > > At any rate, the possibility of creating HELP options in CAT for complex > but important lib commands should be used as much as possible as soon as > somebody offers his library to the public. The more that memory space > isn't anymore a problem on the 49+. This is supported by the library > manager D<->L from OT49(+) for users not familiar with SysRPL. > > - Wolfgang > http://page.mi.fu-berlin.de/~raut/WR49/OT49.htm ==== > I just hope my little program helped shed a little more light on the > RPL gem. > So you are the mysterious author of this program documented at http://www.hpcalc.org/hp48/docs/programming/1minmarv.zip originally presented at the HHUC99 Conference, HP Vancouver as One-Minute Marvels by Wlodek Mier-Jedrzejowicz and Richard Nelson. One wonders why you were not listed as the author??? ==== Marlon, I think the author is John H. Meyers: http://groups.google.com/groups?selm=4qu3qv%245u4%40news.iastate.edu Didn't you ever reinvent the wheel? It's a great feeling ... as long as one doesn't search google groups :-) ==== [This is a reply and a sort of mini-challenge] > It also raises the issue of why it ever > was changed in the first place ... Simple answer: Right-hand efficiency. Longer answer: The [+] key was moved to the bottom right corner (where it has almost always been on huge clunky adding machines) for the simple reason that it's the key closest to your right hand and therefore easiest to reach. The [+] key is the most-used key on large adding machines (and that's why they are called -- all together now -- ADDING machines). On the latest HP calculators, the supposition is that the ENTER key is the most-used key, and that's why it was moved to that position, bumping up the [+] key. Are HP scientific calculators just glorified adding machines? Yes. For all their power and glory, the most-used function is *still* addition. (Maybe not by YOU, but certainly by most users). Bottom line: It was NOT an arbitrary choice. It may clash with your personal preferences, personal artistic sense, ingrained habits, or left-thumb usage (in my case, all four of the above), but there WAS a reason for the change. Mini-challenge: Can anybody here think of a way to write an invisible program that keeps count of exactly how many times each key is pressed? To be bearable, the program would have to be transparent to the user, that is, not interfere with regular operations, nor noticeably slow down the user interface. It would be very interesting to see an actual list of the keys sorted in most-used to least-used order. Placement of keys could then be based on reality instead of suppositions. It would also help individual users place their key assignments in the most efficient locations. -Joe- ==== > Sorry, but it was changed with the 10-series. > 11c, 12c, and 15c have the arithmetic keys arranged the way the 48/49 have > them > These calculators were intro'd back in 1981. Well, I *did* say almost every HP handheld from the first HP-35 right down to the HP-41, not every handheld. I'm quite familiar with the Voyager calcs, since my 16C is my most highly-prized HP and is the one I have owned the longest. But the Voyagers are horizontal-format calculators, and require (for me at least) two-handed usage anyway. It actually took me a little while to get used to the 41 keyboard layout because I'd been using the 16C for about a decade before getting my first 41. But I quickly became convinced that it was ideal for a vertical-format calculator. So now, I don't see any reason why these two basic layouts -- one for horizontal calcs, the other for vertical -- shouldn't be preserved (almost) unchanged for any conceivable future calculator. If you put an HP-35 and an HP-41CX side-by-side, there is a very clear family resemblance. A 41 with a card reader installed is almost the same size and shape as a 48. I don't see why the 48 couldn't have looked almost exactly like a 41 with a large LCD in place of the card reader. In fact, if HP is still making calculators 100 years from now, I think it *still* should look more like an HP-35 than a 49G+, or even a 48. -- 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 ==== Well, you had said Why was it changed on the HP48? It wasn't. It was changed on the series 10, the 75C, the 71B, the 28C, etc. By the time the 48SX was introduced in 1990, it had been 10 years since a vertical format calculator was introduced with the function keys on the left side. No surprise it me that the convention in place from 1972 until 1980 (8 years) was not carried over after a 10 year period where the function keys had been on the right side. By 1990, they had been on the right side longer than they had been on the left side earlier. The last calculator with the arrangement you prefer was the 41c/34c, I think. That was 23 years ago. I know the lack of a large ENTER key in the right spot of the keyboard is a show-stopper for you (although you do seem to get by with a vertical ENTER key in a different location on your 16c), but that's a preference that may not come back. Suppose someone had decided I'll never buy another business calculator unless it has a large key labeled 'SAVE' in the middle of the keyboard...it's nonsense to rename a key after it has been in use by business people for several years just to match what the engineering calculators show Things change. I'm just glad to have RPN. Gene -- * These statements and opinions are mine alone and do not reflect my employer's views. * > Sorry, but it was changed with the 10-series. 11c, 12c, and 15c have the arithmetic keys arranged the way the 48/49 have > them These calculators were intro'd back in 1981. Well, I *did* say almost every HP handheld from the first HP-35 right > down to the HP-41, not every handheld. I'm quite familiar with > the Voyager calcs, since my 16C is my most highly-prized HP and is the > one I have owned the longest. But the Voyagers are horizontal-format > calculators, and require (for me at least) two-handed usage anyway. > It actually took me a little while to get used to the 41 keyboard > layout because I'd been using the 16C for about a decade before getting > my first 41. But I quickly became convinced that it was ideal for a > vertical-format calculator. So now, I don't see any reason why these > two basic layouts -- one for horizontal calcs, the other for vertical -- > shouldn't be preserved (almost) unchanged for any conceivable future > calculator. If you put an HP-35 and an HP-41CX side-by-side, there is a very clear > family resemblance. A 41 with a card reader installed is almost the same > size and shape as a 48. I don't see why the 48 couldn't have looked > almost exactly like a 41 with a large LCD in place of the card reader. > In fact, if HP is still making calculators 100 years from now, I think > it *still* should look more like an HP-35 than a 49G+, or even a 48. -- > 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 ==== > Well, you had said Why was it changed on the HP48? > It wasn't. It was changed on the series 10, the 75C, the 71B, the 28C, etc. > By the time the 48SX was introduced in 1990, it had been 10 years since a > vertical format calculator was introduced with the function keys on the left > side. No surprise it me that the convention in place from 1972 until 1980 > (8 years) was not carried over after a 10 year period where the function > keys had been on the right side. By 1990, they had been on the right side > longer than they had been on the left side earlier. > The last calculator with the arrangement you prefer was the 41c/34c, I > think. That was 23 years ago. I thought the 48 was supposed to be the successor to the 41. Isn't that where the 4 in the model number comes from? So what difference does it make if some other models had a different layout? And what does the passage of 10 years (or 23, or any other length of time) have to do with it? I can't see what's wrong with having one layout for the vertical format machines and another for the horizontal models. (I would, in fact, be opposed to a Voyager-style machine with a 41-type key layout.) In fact, I wouldn't mind if every family of HP calcs had completely different layouts (as long as they're original HP-developed layouts and not copies of some other company's layout). But there always should be at least *one* top-of-the-line model whose design pays clear homage to the 35 design. > I know the lack of a large ENTER key in the right spot of the keyboard is a > show-stopper for you (although you do seem to get by with a vertical ENTER > key in a different location on your 16c), but that's a preference that may > not come back. The vertical ENTER is still large and prominent. As I thought I'd explained a time or two before, the primary benefit of the large ENTER key for me is that it proclaims loudly and unmistakably, THIS IS AÊHEWLETT-PACKARD RPN CALCULATOR! I like the idea of HP being *proud* of the technology they invented, of them *wanting* to emphasize that their products are different, that they have an unshakeable belief that anything HP invents must *by definition* be better than anything anyone else invents. I like the implication that you're not just buying a product, you're being initiated into an elite society and that you can't use Their Products unless you become One of Them. That's the clear impression that I received from them when working with their HP3000 minicomputers years ago. Calling one of their service technicians was like consulting a member of a priesthood of wizards and mysterious gurus who were only too happy to share their arcane knowledge with a willing pupil. (In all my years of dealing with IBM, I've *never* had an IBM tech instruct me over the phone to open the back of a CPU cabinet, rearrange some of the cables and dip switches and reinitialize an I/O board -- all with the processor running *Production* applications! Yet an HP Customer Engineer had me do that on several occasions while troubleshooting I/O subsystem problems. On another occasion a different CE talked me through dismantling a washing-machine-sized disk unit to remove a defective chip that he said wasn't needed anyway because, It's only there to keep idiots from formatting the wrong disk pack. You can run just fine without it. It was rather like working with Scotty on the Starship Enterprise to squeeze a little more out of the warp engines. :-) *That's* the kind of We're better than the rest, the rules don't apply to us attitude that I came to expect from HP -- not the current We're afraid to be different, we have to look and act like everybody else. > Suppose someone had decided I'll never buy another business calculator > unless it has a large key labeled 'SAVE' in the middle of the > keyboard...it's nonsense to rename a key after it has been in use by > business people for several years just to match what the engineering > calculators show Actually, I'd have no problem with that. Keeping the HP-80's SAVE key on the business models would be a good way to distinguish the business and engineering calculators. In fact, I think I'd prefer it that way. > Things change. I'm just glad to have RPN. So am I. Unfortunately, it looks like I'll only have it until all the older models have worn out... -- 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 ==== After the time wrap bug, I got an other one: Just to play around with my new 49G+ I tryed the ALG mode and here we go :12+3 15 :12+ANS(1) Too Few Arguments The same works all right on my 49G (not +) Arnaud going back to RPN ==== I just did exactly what you show below and it works fine. ROM 1.22 :12 + 3 15 :12+ANS(1) 27 I got the second line by typing 12, +, LEFT SHIFT ANS, ENTER What did you type? Gene -- * These statements and opinions are mine alone and do not reflect my employer's views. * > After the time wrap bug, I got an other one: > Just to play around with my new 49G+ I tryed the ALG mode and here we go :12+3 > 15 > :12+ANS(1) > Too Few Arguments The same works all right on my 49G (not +) Arnaud going back to RPN > ==== I just got my HP49G+ and am in the process of setting up. My key program is MODA, a library, and that installed ok. MODA is a wonderfull program that fits anything to weighted data. There is a LIST MDCAT that goes with MODA and I am supposed to transfer it in BINARY mode. That worked in the HP49G just fine. But now using Conn4x, all I get is something the calc id's as a STRING. What is going on? How can I transfer my LIST to my new calc? Does anyone know? Am I going to have problems if I try to transfer a data matrix to the calc? This seemed so simple and is turning out so hard. Dave Scott ==== as the subject suggests I've some problem with damn files I need to view in the same form they look on the PC. Calculator: HP48G+ Editor (PC): WinHP file format: .tgv Well, I've this damn file with bold and underlined characters, I correctly transfer files and fonts in the same directory (home at the moment). If I try to execute the file (binary), hp returns: Undefined XLIB name What the hell does it means? I don't find a single word, command or what have you about XLIB in the manual. If I recall (RCL) the file, it looks like the following: { text (with a little square as not viewable character and B standing for Bold, or U standing for Underlined, and so on)} XLIB 333 0 DROP in the line 1. If I edit the file on the PC in other formats (.xv, .eden) and send it and the needed fonts too (of course) there isn't any problem about XLIB (not required) but I continue to not see bold, underlined, superscripts, and so on, in other hands it doesn't use fonts. Not a single word about it in the manual. May anyone help me please? PS: a special greeting to everyone can put up with my broken English :-) ==== a .8ecrit dans le message de > as the subject suggests I've some problem with damn files I need to view in > the same form they look on the PC. > Calculator: HP48G+ > Editor (PC): WinHP > file format: .tgv > Well, I've this damn file with bold and underlined characters, I correctly > transfer files and fonts in the same directory (home at the moment). > If I try to execute the file (binary), hp returns: Undefined XLIB name > What the hell does it means? > I don't find a single word, command or what have you about XLIB in the > manual. > If I recall (RCL) the file, it looks like the following: > { text (with a little square as not viewable character and B standing for > Bold, or U standing for Underlined, and so on)} XLIB 333 0 DROP > in the line 1. > If I edit the file on the PC in other formats (.xv, .eden) and send it and > the needed fonts too (of course) there isn't any problem about XLIB (not > required) but I continue to not see bold, underlined, superscripts, and so > on, in other hands it doesn't use fonts. > Not a single word about it in the manual. > May anyone help me please? > You need the TGV library. (http://www.hpcalc.org/details.php?id=133) > PS: a special greeting to everyone can put up with my broken English :-) ==== You refer to the good old days of HP calculator. I call that the golden era of HP calculators. For those who missed that era here are the prices we had to pay for HP calculators in 1975 in Montreal. This was in the bookstore of the Polytechnic School of Montreal University. HP 35 : 350 $ Can HP 45 : 450 $ Can HP 65 : 1 000 $ Can (yes one thousand). And at this time the canadian $ was about on par with the american $. The fun part was that we agreed to buy these machines because we know we were buying top quality. This quality was showing in every aspect of the package, including the documentation which was also top notch. Just some ideas of what we got in these years. - Demo machines in the store for us to try as long as we whished. - Demonstrations by HP performed in the school auditorium to show the solidity of these machines. The guy trew an HP 45 on the terrazzo floor from a heigth of four feet. The machine ran perfectly. He did the same with an HP 35. Same result. He trew the 35 against the back wall of the auditorium. Aside from a cracked corner, the machine still functionned. - Support by HP that I would like to get today. A friend brough his defective 35 (yes, there were problems even at that time, nothing's perferct)in HP's offices, near Montreal. The clerck had him wait about 30 minutes while they actually fixed its machine. He walked out with a working 35. Another had a small problem with its 25. Since the machine could not be repaired in a short time, they lended him a 25C while his machine was on repair. In 1979, I was on the verge of buying a 67 after the price dropped to about 500 $ Can from the 800 $ can that was asked for in 1977. I am lucky to have waited long enough because I got a 41C instead, for 400 $. The common factor for all these machines up to the 48SX that I bough in 1989 was a continuous increase in power while maintaining an overall superior quality that showed even in documentation. Although the Hard plastic casing and the leather carrying pouch of the 45 had long been replaced by cardboard boxes and more vinyl like carrying pouches, the manuals were still very nicely done. I can comprehend that when there is so much stuff packed in a 49G or G+ machine that the required documentation would be as thick as a huge telephone book. But at least they could do what they did for the 48SX. Provide the basic manual and the programming manual and offer the advanced manual as option. I downloaded the advanced user guide for the 49G from the Web and printed it. No small task and I spent a lot of time, paper and printer ink. HP save big money by not including that with the machine. I understand where they cut prices to be able to offer such powerfull calculators for about 300 $ Can. They could at least pack a CD ROM containing the PDF files with the calculator. That way we would at least save the serch and dowload time on the net. I think that they should have enough time, since the introduction of the 49G, to assemble some complete documentation. At least we have now good Web sites and this newsgroup to get some help. But I cannot consider the actual era any more as a golden one for HP. They are only doing what every other company is doing, making the largest net income. I am sorry for all this complaining but, if, in the 70s and 80s I was a maniac in developping software for my HP calculators, today I consider these as a complement to my computer and use them only for pure number crunching. And for that function, the 49G keyboard is not efficient as per my standards. Too bad. I only play occasionnaly with it to check a few things but I do not use it for extensive number crunching. My 41CX is still my prefered one for that purpose. Some will ask why I did not bough a cheaper and simpler machine. The answer is that I bough a 48SX out of curiosity since my 41CX was still working well. This machine became my workhorse in the 90s. After it was stolen in 2001, the only logical choice was ieyher a 48GX or a 49G. I should have gone for a 48GX but the larger memory and power of the 49G was too tempting. With a good keyboard the 49G would be my workhorse but it is not. Jean (Johnny) Lemire from Montreal, Quebec, Canada ==== There might be: You might want to try ON-D where you be presented with a list of 10 options, number 9 of which is format. If you format your SD, it should be visible in Left-Shift Files the file manager, as port 3:SD . -Dale- >About SD. I just picked one up at Costco, and when I plug it in, >there's no indication that it is found. Following the sad little >instruction in the User's Manual shows no port 3. Is there some decoder >ring trick for that, too? > ==== oN 06-Nov-03, motz said: > There might be: You might want to try ON-D where you be > presented with a list of 10 options, number 9 of which is format. > If you format your SD, it should be visible in Left-Shift Files the > file manager, as port 3:SD . the inaquacy of both the User's Manual and the User's Guide, however. -- Bill ==== Since this issue rates fairly high on the 49G+ Concerns radar screen, I thought a new thread might be warranted as a helpful workaround for the those of us who are afflicted with the flickering LCD syndrome. This fix came from Shinsuke in his response to the thread 49G+ Questions at the Museum of HP Calculators (the thread starts at: http://www.hpmuseum.org/cgi-sys/cgiwrap/hpmuseum/forum.cgi?read=45540) Shinsuke's post said: A solution to the flickering is [Press ON plus up-arrow]. Ed Look mentioned this key-sequence is the Print LCD function. It really does seem to solve the issue, that is until the calculator's power is cycled, then you must repeat the sequence. Inserting this sequence into an autoexec-type program on power-up would be a nice way to automate the process. The real hope, since we can now feel pretty confident it's a software issue, is (if HP hasn't already determined what's causing the flickering) that this will provide a clue that points HP toward the real problem, and ultimately an updated ROM that fixes the flickering permanently (including Joe Horn's LCD storming-pixel display :-). Matt