8443 === Subject: Battery > What kind of batteries is used in your HP50G? AAA-rechargeables. TW === Subject: Re: Battery > AAA-rechargeables. My batteries are AAA, 950mAh but it seems that 50g is not power saving calculator :-) !!! 50g drain power very very fast, specially when connected on PC and data transfer, executing programs with high CPU usage... This is just my observation, maybe i'm wrong... === Subject: Re: Battery 50g drain power very very fast, specially when connected > on PC and data transfer, executing programs with high CPU usage... > When connected to the PC (via USB obviously), the HP 50g gets its power from the PC, not from batteries. === Subject: Re: Battery 50g drain power very very fast, specially when connected > on PC and data transfer, executing programs with high CPU usage... When connected to the PC (via USB obviously), the HP 50g gets its > power from the PC, not from batteries. If you frequently work at a desk you can get one of the several ac to 5 volt DC power supplies with a USB connector for powering USB devices too. Lot more economical than powering up a computer to provide power to the calculator USB port IMO. Here is a link to the multi page Duracell NIMH battery technical specifications PDF. If you look at the power discharge curve for the NIMH batteries, picture 5.1.1, you will note that the battery is about discharged when the voltage drops to 1.2 volts, the 50G approximate low battery sensing voltage. http://www.duracell.com/oem/Pdf/others/TECHBULL.pdf It looks to me like the designers of the 50G designed it to be used with NIMH cells. Earlier HP 4X series calculators had their low battery sensing set to activate at closer to 1.0 volts per cell, per prior posts here. If using NIMH cells this would have them so thoroughly discharged that a crash could happen unless the batteries were immediately replaced it appears from the Duracell curve. Rich Wood === Subject: Re: Battery > Here is a link to the multi page Duracell NIMH battery technical > specifications PDF. If you look at the power discharge curve for the > NIMH batteries, picture 5.1.1, you will note that the battery is about > discharged when the voltage drops to 1.2 volts, the 50G approximate > low battery sensing voltage. > > http://www.duracell.com/oem/Pdf/others/TECHBULL.pdf > > It looks to me like the designers of the 50G designed it to be used > with NIMH cells. Earlier HP 4X series calculators had their low > battery sensing set to activate at closer to 1.0 volts per cell, per > prior posts here. If using NIMH cells this would have them so > thoroughly discharged that a crash could happen unless the batteries > were immediately replaced it appears from the Duracell curve. So do you think the only reason for now using four cells is to encourage (or accommodate) using NiMH cells instead of Alkaline? Will the 50G run on only three alkaline cells (plus one shorted-out dummy cell)? If it does, how much current does it then draw? (same as 49G+ with three alkaline cells?) The 50G User Manual says nothing about what kind of batteries to use; if it runs on three alkalines, then you could save by only using three. Will they then last as long as the same batteries in a 49G+ (ignoring low batt signal -- the actual running time until stops working)? I can not run far on three batteries myself, but I did run about 20_km on three MREs during one terrestrial excursion. -- Why does everyone run circles around me? === Subject: Re: Battery AAA-rechargeables. > TW My batteries are AAA, 950mAh but it seems that 50g is not power saving > calculator :-) !!! 50g drain power very very fast, specially when connected > on PC and data transfer, executing programs with high CPU usage... This is just my observation, maybe i'm wrong... You are almost certainly not wrong I believe. Look at the current drains listed for the HP 50G versus other older members of the HP family reported in the recent post comparing current drain of different models in the HP 48/49/50 series of calculators. Heavy worst case drain usage looks like it could drain the batteries in less than 10 hours. Even just running programs looks like about 50 hours maximum battery life. This is not helped by the fact that NIMH rechargeable batteries have a fairly high self discharge rate. Even with the calculator turned off there is some battery drain to keep the clock circuitry running. I know in my old 48GX a new set of alkalines is discharged in 6 to 9 months just by being installed in the calculator. I expect a lot worse from the 50C. Not like the old 11c and 12c where a set of three 357 silver oxide button cells could last literally for years even with the drain from powering continuous memory. If figures for the low battery indicator turn on voltage I have seen listed for the 50C are correct, and unchanged from early production, then when using alkaline batteries the low battery indication will be triggered while the batteries are only about half discharged. This looks like it could be as quickly as after 25 hours of program operation and quicker with very much I/O activity or SD card writing. With their lower operating voltage and internal resistance I am not sure what the low battery warning versus remaining battery charge is for NIMH batteries in the 50C. Rich W === Subject: My SysRPL Problem Hello all, I'm still a beginner SysRPL programmer, and I've run into a bit of a snag in my project that I can't seem to sort out myself. I've received some awesome assistance here before (I'm looking at you, John H Meyers!) and I'm hoping somebody can help again. I've set up a custom menu in which I will list some of the built-in functions. The feature I am trying to implement uses Keyman and SDiag to display a help box describing the command when I long-press the menu item. A normal press will execute the command. In edit/program mode I want it to act as normal (act as a typing aid). In order to implement this I have the code for my menu (simplified to show only one item): :: MenuMaker { { ROT :: ID DMNU xROT ; } } InitMenu ; And the DMNU (Do Menu) function I've placed in another program so I can reuse it in multiple menus: :: TakeOver 'R PrgmEntry? case DoKeyOb EVAL AtUserStack ; Some may notice that this is the exact code used by the system for its own menus (I stole it from PTR 19ECE). This is not exactly the code I will use to implement the help box, but I need to get this to work first. Adding the help to it will be easy. The problem is, something breaks down when I do it this way. Everything works as expected if I use PTR 19ECE instead of ID DMNU, but with ID DMNU nothing happens when I press the menu item when in program/edit mode. The code is identical in both, I just can't figure out what's wrong (although it seems to be the DoKeyOb command that does nothing...). Any assistance would be greatly appreciated. I'm stumped. ;) === Subject: Re: My SysRPL Problem short answer: An ID is not a pointer (or ROMPTR). Please use the debugger, and you'll see how the system works on menu lists;-) HTH Raymond Ryan Edwards schrieb im Newsbeitrag > Hello all, I'm still a beginner SysRPL programmer, and I've run into a bit of a > snag in my project that I can't seem to sort out myself. I've received > some awesome assistance here before (I'm looking at you, John H > Meyers!) and I'm hoping somebody can help again. I've set up a custom menu in which I will list some of the built-in > functions. The feature I am trying to implement uses Keyman and SDiag > to display a help box describing the command when I long-press the > menu item. A normal press will execute the command. In edit/program > mode I want it to act as normal (act as a typing aid). In order to implement this I have the code for my menu (simplified to > show only one item): :: > MenuMaker > { > { > ROT > :: > ID DMNU > xROT > ; > } > } > InitMenu > ; And the DMNU (Do Menu) function I've placed in another program so I > can reuse it in multiple menus: :: > TakeOver > 'R > PrgmEntry? > case > DoKeyOb > EVAL > AtUserStack > ; Some may notice that this is the exact code used by the system for its > own menus (I stole it from PTR 19ECE). This is not exactly the code I > will use to implement the help box, but I need to get this to work > first. Adding the help to it will be easy. The problem is, something breaks down when I do it this way. > Everything works as expected if I use PTR 19ECE instead of ID DMNU, > but with ID DMNU nothing happens when I press the menu item when in > program/edit mode. The code is identical in both, I just can't figure > out what's wrong (although it seems to be the DoKeyOb command that > does nothing...). Any assistance would be greatly appreciated. > I'm stumped. ;) > === Subject: Re: My SysRPL Problem short answer: An ID is not a pointer (or ROMPTR). Please use the debugger, and you'll see how the system > works on menu lists;-) I've looked at what's happening and I believe I understand what's happening, but I'm not completely sure what the best way is to proceed in this situation. Perhaps as a more general question: If I have a function such as this that I wish to call in multiple programs within a library, what is the best way to implement it and call it when needed? If I start by solving this problem, then I think I will be on better footing to move on. P.S. I've read as many of the SysRPL docs as I can find, but I find most tend to skip over what I would consider to be the basics. Very steep learning curve this SysRPL. :) === Subject: Re: Win 64 usb driver for 49g+/50g > EDoes anybody know if this exists? > NR Nothing shown on the HP 50C drivers page for different operating systems that I can see. Sure it is not built into the operating system already? Surprising how many devices XP recognizes automatically and installs drivers for. Rich W === Subject: Re: Battery life 49g+ there was a ROM version which seamingly resolved keyboard problem (not > entirely though) > but sideffect was that it was battery eater -be sure to use the latest > official ROM version. > I'm using the latest HP release on it and on my 50g+ > scenario b) > sometimes one of the batteries may be deffective and die in few days of > use > that's what happened to me few times -the first time i hadly belived it. > The other two were almost 90% when one of them died completely. > I'm thinking it's a bad battery, but two in a row? They did all come from the same lot, so maybe. > scenario c) > Battery life should be signifficantly greater than 8 days, but if your > programs write to > Flash (port 1 or 2) or SD (port 3) intensively or if you use IrDA or USB a > lot > it will burn your batteries a lot faster. > note: > it was not calculator, it was battery issue although expiration date was > fine. I do a home backup to SD twicr daily. Probably obssessive here, but I was getting good life out of the batteries, so I din't mind. > i tried several brand of batteries, but as it seams (for me) duracell have > decent lifetime and price (possibly the best) > Ironically, these were Duracells. > if it's none of the above then it's deffective :-) > Possibly so. > manjo > P.S. > The best way to do backup is to pull out the SD and make a backup on your > PC > using a card reader. I do this once every six monhts. I got lazy with the convenience of the SD card. I'm using NiMH on my 50g+, and I'm even less concerened about it losing juice. > Also copy (or keep) your data on SD from time to time -once every few > days. > (assuming you are using your calculator with set of tested programs and > your > favorite setup) of course if you use your calculator a lot, i sometimes use it so much > that > it gets warm underneath, > you can't expect long battery life. I wouldn't be so concerned except that I monitor battery changes, and the recent life of a set dropped dramatically. I think I got a bad batch of Duracells. Time will tell. Scott === Subject: Re: HP35S - Programming Form, e^(z), Re(z), Im(z), 100 Data Memory Utilities. Interesting. I had an original HP35 - it was not programmable in any way. I wonder what kind of 'programs' the 35s takes. The first HP programmable (I also had one of these) was the 45. jrc ------------------------------- > I've 'published' a few HP35s programs that may be of interest here: > > (It is an excel97 sheet - hopefully readable by all.) > > The code may not be optimized or maximally commented, but just wanted > to get it out there. > > Some notes (which perhaps should be on the page): > > The e^z routine [LBL E] is just a simple Taylor Series expansion - > with n in the y register and z in the x register, e^z approximation > mind, but found out to my surprise and pleasure that it works for > complex z input! Thus, this can give you the sine and cos for > imaginary z input. > > The Re(z) and Im(z) routines [LBL I] were from one I lifted from the > web - I modifed it slightly to return the real part in x and the > imaginary part in y. > > I've decided (somewhat arbitrarily) that 100 data registers (0 > through99) should be plenty for most any application - thus my form > has cells for all 100 in the bottom. > > There are a couple utilities to utilize this data block: Clear all > 100, recall and display all 100, store randome data in the data block, > STO(X) and RCL(X) which recall /store the x register based on index > given. > === Subject: HP 35s Programmable??? Original 35 was not. It's interesting reading about the HP 35s which is (or is not) now on the market - especially the comments about writing 'programs' for it. This must be a major upgrade for the original 35, which was not programmable in any way. Many of us original '35 owners, who paid $399 for an Hp-35, were abashed, then bought, the new HP-45 which came out shortly after. The '45 was the first programmable HP handheld, and used labels much as the 35s 'programs' suggest. The HP-45 was originally priced at $399. The '35 dropped to $299 when the '45 came out. Some of us were able to get '45's for a discount. Then mine was stolen. jrc === Subject: Re: HP 35s Programmable??? Original 35 was not. > It's interesting reading about the HP 35s which is (or is not) > now on the market - especially the comments about writing > 'programs' for it. This must be a major upgrade for the original 35, which was > not programmable in any way. Many of us original '35 owners, > who paid $399 for an Hp-35, were abashed, then bought, the > new HP-45 which came out shortly after. The '45 was the first > programmable HP handheld, and used labels much as the 35s > 'programs' suggest. The HP-45 was originally priced at $399. The '35 dropped to > $299 when the '45 came out. Some of us were able to get > '45's for a discount. Then mine was stolen. jrc jrc; Per my memory, and the HP museum site, the HP65 was the first programmable HP calculator, for $695. I still have one, along with a HP35, in my collection. I also have a full collection of the 65 Notes from the original support club that Richard Nelson founded. Those were the days. If you bought a 65 you almost certainly programmed it. After all in 1974 you were spending the equivalent of today's $3500 to $7000 or so for that unit and there was none of the internet support and program swapping the internet has made possible. BTW the HP 35s runs circles around my old 65 as far as program running speed is concerned. Rich W === Subject: Re: HP 35s Programmable??? Original 35 was not. > It's interesting reading about the HP 35s which is (or is not) > now on the market - especially the comments about writing > 'programs' for it. This must be a major upgrade for the original 35, which was > not programmable in any way. Many of us original '35 owners, > who paid $399 for an Hp-35, were abashed, then bought, the > new HP-45 which came out shortly after. The '45 was the first > programmable HP handheld, and used labels much as the 35s > 'programs' suggest. The HP-45 was originally priced at $399. The '35 dropped to > $299 when the '45 came out. Some of us were able to get > '45's for a discount. Then mine was stolen. jrc I can help you out. www.hp.com Bob === Subject: Re: Calculator defined Manjo, what you described is the Lua VM!! You almost copied its manual, haha! The only difference is that you like it with Python syntax, but the functionality is exactly as you described it below... > Of course, > when virtual machine is good, language is a matter of > configuring the interpreter/compiler the right way. Therefore all languages you listed here would be possible obviously there would be 2 modes of operation : > -interactive interpreter (for command line / user interface / file handling > etc...) It's already done, but I would like to change it to a stack-like display for usability. > -compiler mode for running programs or compiling Done. basically there would be 3 types of programs : > -scripts (compiled and executed when called -stored as source code) Of course, Lua compiles on-the-fly. > -compiled (pre-compiled for short start-up time -stored as byte code > executed by virtual machine) You got it. > -native ARM (assemblies stored as binary -macine code executed directly by > the processor bypassing the VM) Yes, you can call C (C=native ARM) routines with minimal interfacing. The outline of virtual machine could be something like this : > -memory handler (alloc, free, garbage, cpu-move, dma-move, dma-device) Done. > -display handler (framebuffer/blt operations alloc,free, scroll, > zoom,rotate, drawing operations. pixel, line box, poly, text, fonts) This is what would need to be done (all hardware management in general). > -file handler (SD, 1 and 4 bit including dma transfer...) My filesystem can be used with no changes, so it's done (except for the DMA, I use 'manual' transfers) > -keyboard handler (detecting keys, debouncing, keyboard state buffer, key > queue) Lots of hpgcc code can be reused for this. > -timer (system timer-triger, RTC) Same as keyboard. Needs to be done, but there's a lot of existing code that could be refactored. > -atom types (numbers 16,32,64 bit based binaries and BCD prefered over IEEE > float...) > -operators > -tasks > -flags All of this is ready to go. > ... > handlers are actualy portions of VM which talk directly with hardware in > your average everyday operating systems they would be called drivers > these could be updated separately as long as they follow defined model. that > way you could for example, plug your device to different display type > update the display handler/driver and all would work again much like your > everyday desktop OS. All current libraries in Lua can be 'hot-linked'. What we need to do is to focus on the specific hardware drivers, the framework is all done. NOTE : > -the VM iteslf could be a LOT like Saturn > only this VM is both firmware (BIOS) and OS in one : > meaning it talks directly with hardware no additional layers between them user <> application <> VM <> hardware > instead of: > user <> application <> emulator(VM) <> KOS(firmware) <> hardware nicer, > smaller applications which takes care of more of users needs, which finally > makes users happy :-) -these are just first few things in my mind i felt i should write down :-) Start writing them down... or you can download the Lua manual, http://www.lua.org Claudio === Subject: Re: Calculator defined <33v3c3thnc2biivlihnhp4hmmfs9uk2cfj@4ax.com> <46c22c38$0$30368$9b4e6d93@newsspool4.arcor-online.net> manual, haha! The only difference is that you like it with Python > syntax, but the functionality is exactly as you described it below... > Of course, > when virtual machine is good, language is a matter of > configuring the interpreter/compiler the right way. > Therefore all languages you listed here would be possible > obviously there would be 2 modes of operation : > -interactive interpreter (for command line / user interface / file handling > etc...) It's already done, but I would like to change it to a stack-like > display for usability. > -compiler mode for running programs or compiling Done. > basically there would be 3 types of programs : > -scripts (compiled and executed when called -stored as source code) Of course, Lua compiles on-the-fly. > -compiled (pre-compiled for short start-up time -stored as byte code > executed by virtual machine) You got it. > -native ARM (assemblies stored as binary -macine code executed directly by > the processor bypassing the VM) Yes, you can call C (C=native ARM) routines with minimal interfacing. > The outline of virtual machine could be something like this : > -memory handler (alloc, free, garbage, cpu-move, dma-move, dma-device) Done. > -display handler (framebuffer/blt operations alloc,free, scroll, > zoom,rotate, drawing operations. pixel, line box, poly, text, fonts) This is what would need to be done (all hardware management in > general). > -file handler (SD, 1 and 4 bit including dma transfer...) My filesystem can be used with no changes, so it's done (except for > the DMA, I use 'manual' transfers) > -keyboard handler (detecting keys, debouncing, keyboard state buffer, key > queue) Lots of hpgcc code can be reused for this. > -timer (system timer-triger, RTC) Same as keyboard. Needs to be done, but there's a lot of existing code > that could be refactored. > -atom types (numbers 16,32,64 bit based binaries and BCD prefered over IEEE > float...) > -operators > -tasks > -flags All of this is ready to go. > ... > handlers are actualy portions of VM which talk directly with hardware in > your average everyday operating systems they would be called drivers > these could be updated separately as long as they follow defined model. that > way you could for example, plug your device to different display type > update the display handler/driver and all would work again much like your > everyday desktop OS. All current libraries in Lua can be 'hot-linked'. What we need to do > is to focus on the specific hardware drivers, the framework is all > done. > NOTE : > -the VM iteslf could be a LOT like Saturn > only this VM is both firmware (BIOS) and OS in one : > meaning it talks directly with hardware no additional layers between them > user <> application <> VM <> hardware > instead of: > user <> application <> emulator(VM) <> KOS(firmware) <> hardware > nicer, > smaller applications which takes care of more of users needs, which finally > makes users happy :-) > -these are just first few things in my mind i felt i should write down :-) Start writing them down... or you can download the Lua manual, http://www.lua.org Claudio It seems like we will have a revolution in our Calcs!!! i can help when it`s done translating to Spanish... or maybe when i have more Knowledgements about it i can help doing that... it`s really amazing and exciting... === Subject: Re: Calculator defined > You are wishing a lot, but if you are willing to 'jump in' and create > such a beast, I'll create the basic development enviroment. What I have in mind is basically a humbled-down version of your dream > machine: 1) Hot-swapper program that can save your entire calculator to SD (all > saturn calculator, like snapshots). This is similar to what you want. > 2) New environment based on LUA, which is better than Python for this > application because: > a) It's ultralight > b) It's already running well in the calculator (hplua) > c) It's stack-based, very easy to incorporate in a new RPN > calculator! > d) It has existing libraries, including an interface with decNumber > for high precision math. I could easily put together a hot-swapper to achieve 1), and for 2) > all we need is to extend a little the current implementation of hplua > and create a nice stack interface, not a big deal really. > Is not your dream machine but could get pretty close to it, and this > one is 60% done before we even started. All we need is to get the > right people together... Anyone interested? > Claudio PS: > i mean... forget C, forget Pascal... No! don't forget C... hpgcc will be back very soon! > I just returned from my vacation with new thoughts, not entirely of topic, > here goes: > what if HP50 would have an OS which would offer: > -Python environment (for power users i'm sure there are people among you > which understand what i'm talking about) > powerfull language (high code reusability, modules, etc...) > (for power users like sysRPL or Saturn assembly at this time) > -LOGO for beginners (computer beginners and quick'n dirty routines :-) > immagine simple programming language easy and simple enough for everybody to > learn yet > helping new programmers to understand basic principles and way of thinking > while resolving various problems > -Saturn emulator (with a bit better emulation, more accurate graphics, > keyboard and sound emulation) > of course to keep the gigant library of programs, codes, games etc... from > the pas working in the future > but (sadly) is expected to extinct in the future > At power-up you could choose the default envronment, each environment, of > course, would have command to escape to > any of the available environments, all environments featuring the ability to > run native ARM programs, routines, modules or system calls. > Such a device, i think, would be worth twice it's current price, with no > modification in hardware at all > also... with additinal (learning) software similar and beyond Expander and > TInspire it would penetrate the schools (right from elementary) > and stay usefull to it's owner for entire life. > It would literally establish a world standard of pocket calculator once and > for all.. > what would that be worth for you ? > manjo > (my finishing thought: if i only had so much time... :-) I think that all of this projects are amazing, i still dont have the enought knowledgements to say that i can help doing that :-(... But i`ve been thinking about Saturn emulation and i don`t understand something... why to continue emulating saturn processor and not to do an completely ARM ROM HPs...? excuse me if it`s an stupid question... If an ARM ROM released, does it would be better than Saturn emulated ROM??? === Subject: Re: Calculator defined But i`ve been thinking about Saturn emulation and i don`t understand > something... why to continue emulating saturn processor and not to do > an completely ARM ROM HPs...? excuse me if it`s an stupid question... > If an ARM ROM released, does it would be better than Saturn emulated > ROM??? Except you'd lose all the 20+ years of work that had gone into the code running in the old 49, not to mention the loss of support of all the programs currently availiable. . . but more importantly it would have cost much more and taken much longer. I seriously hope HP is working on a next gen calculator that tosses all the old saturn code out, but it will take quite a while to design and code. TW === Subject: Re: HP 50G AC Power Supply > I just purchased a AC to 5V power supply for my 50G from Amazon. The > one I chose is a Sonnet USB Power Adapter for iPod. It cost > considerably more than many listed but did not have any customer > feedback reporting DOA units as the cheaper ones did. The wrong type > of failure on one of these could be fatal to the calculator. The wall transformer unit is extremely compact, with a folding AC plug > for even more compact storage. It includes a LED on top which is > green when the unit is powered on. This changes to amber when the > calculator is attached and powered up, drawing current. The unit is rated to output 500ma, far more than the calculator should > ever draw. I just used it to power the calculator while updating the firmware as > the calculator arrived with down level firmware. It worked great. The unit does not include a USB cable compatible with the calculator > so you need to use the cable included with the calculator or a similar > one. I suspect similar power supplies should also be available at Best Buy, > Circuit City and similar sources. Rich W Rich Wood Cell phone chargers and iPod chargers are relatively expensive. The 50G doesn't need that kind of current anyway. An alternate solution is a 4-port USB hub with external power supply, it costs only 10 US dollars and it allows you to actually use the USB port while powering your calc. (the host doesn't need to be connected for the hub to provide current to its devices). This is the one I got (tested), but any other should be OK: http://www.tigerdirect.com/applications/SearchTools/item-details.asp?EdpNo= 2205152&body=MAIN === Subject: new 50g user, seeking advice... hi everyone, i recently ordered my hp 50g from hp Philippines and it has been a week but still no clue of it coming to my door step. so i decided to make use of the waiting time to learn about it by using the emu48 program to try out things that can be of use to me. i downloaded some civil engineering programs, and tried them on the emulator and i dont know how to run it. one program i'm particularly interested is the reinforced concrete design(http://www.hpcalc.org/hp49/science/civil/ rcdesign101.zip). can anyone teach me how to run it on my emulator and also my calculator if it arrives? i tried to use the debug4x program, made use of its emu48 because the ROM file of the 50g is already included in it and i cant seem to find the proper ROM to use anywhere in the net. am i doing this right? please help me. since i am a beginner in using high powered calculators, can you guys also advice me where to start learning, where to find the materials and maybe the techniques you used. im interested in learning things that will be of use to my field of study, im a senior university student taking up civil engineering, hoping to specialize in structural eingineering. thank you for the help in advance. hope to hear from you all. elly