A559 === Subject: Re: making lists & matrices on a 49G+ > A small program like > << 1 N FOR I I NEXT { 1 N } ->ARRY >> > > would do the trick, just replace N with a number Or do << |-> N << 1 N FOR x x NEXT { 1 N } ->ARRY >> >> 'ABC' STO then one can put a number on the stack and merely press the ABC soft key or use ABC as a function with argument the desired number and value your matrix as in 'ABC(5)' EVAL producing [[1 2 3 4 5]] as output. > > Arnaud > > > hi group! > > > > I have looked through the manual & the news group without luck. > > > > What I'd like to know is, is there an easy way to create a matrix with > > say 1 column spanning from 1 to N , in increments of 1. > > > > eg, in MATLAB for a 1xN matrix X, with increments of 1: > > > > X = [1:1:N] > > === Subject: Re: making lists & matrices on a 49G+ === Subject: Re: SysRPL: Save/restore an OpenFire GBUFF area question. On Wed, 8 Nov 2006 03:16:48 +0100, manjo >Hello Scott, > >> 1. SysRPL entry to save/restore GBUFF? > >You could recall the buffer (or better the AREA which will be lazered :-) to >stack. >there are graphic sysrpl commands good for this. > >Some built in functions do store display area temporarily to alternative >location BUT >i'm sure those will get only the 132x80 area. >NOTE: >OpenFire buffer is either 2 or 4 times larger (depending on graphic mode >you're using) >otherwize the same thing as GBUFF. > >> 2. If OpenFire uses a special memory hook to display its GBUFF data? > >I'm not shure, what do you mean by 'special memory hook' ? >It realy depends on graphic mode: >INITGS and INIT4 are hardware modes. Other modes have additional routines >which >emulate fage-flipping techniques found in older games. (used to port older >games to 49G+ and 50G) > >> Finally got my Make Lasing Path routine to work, but it just returns >> a list of lists for the right path through the playfield. Now, I have >> to convert that to a graphic. Making good progress; I can't wait 'til >> it's done! > >A strategy... very nice ! >I would love to see your game too :-) > >manjo I suppose I have a rather linear brain, as I only understand the page flipping grayscale. I'm not sure how you're handling it in hardware. My concern over the buffer area was that if your grayscale routine used a specific memory location for the display area (to swap pages, etc.), then that may get corrupted if I put a new GROB into GBUFF. I wasn't even thinking about just copying the display area and then REPLacing it later into the same GBUFF area. Duoh! (hitting head). I decided to use 2-bit color for this game, as it's all I really need. Color (grayscale) was mandatory, as the pieces are fairly detailed and B&W just won't distinguish between the two players. Plus, you made it I see from the animation demo that indeed PICT is being changed all the time. The animation sounds neat, but there's no levels in this game--it's a board-type strategy game. I got the idea from www.khet.com and have permission to create a version for the calculator, with public distribution pending their approval. I would like to do something nice for the title screen, though, so I'll think about that. SOT: Being new to creating calculator objects on the computer (let alone grayscale objects), I tried artwork in Illustrator and Photoshop, etc., and had miserable luck in having gradients and textures come out right. After hours of work designing the game pieces, when it all came down to it, I ended up in Photoshop creating a 9x9 grayscale bitmap and hand-colored the pixels. It was much easier for me that way. For the title page, I think I'll try to create a suitable graphic that can be converted using OF-IC.exe. OpenFire is so easy to use--thank you so much! --Scott === Subject: Re: SysRPL: Save/restore an OpenFire GBUFF area question. > SOT: Being new to creating calculator objects on the computer (let > alone grayscale objects), I tried artwork in Illustrator and > Photoshop, etc., and had miserable luck in having gradients and > textures come out right. After hours of work designing the game > pieces, when it all came down to it, I ended up in Photoshop creating > a 9x9 grayscale bitmap and hand-colored the pixels. It was much > easier for me that way. For the title page, I think I'll try to > create a suitable graphic that can be converted using OF-IC.exe. > > OpenFire is so easy to use--thank you so much! I think you're right to hand-draw so small images with 4 graylevels. The game seems nice (challenging to play) I didn't think about it much so i don't know if it's a bright idea : Maybe it would be nice to have a 'Khet' or a 'Gun' -lazer gun that is, as a figure walking and turning around the board in some variation of the game ? keep up the good work :-) manjo === Subject: Re: SysRPL: Save/restore an OpenFire GBUFF area question. On Wed, 8 Nov 2006 09:20:27 +0100, manjo >I didn't think about it much so i don't know if it's a bright idea : >Maybe it would be nice to have a 'Khet' or a 'Gun' -lazer gun that is, as a >figure >walking and turning around the board in some variation of the game ? > >keep up the good work :-) > >manjo > Oooh, I LIKE that idea! Maybe after the main game code is written I can explore something like that--very clever, you! Scott === Subject: Re: My first ever HP calc Great first HP stories. Here's mine: While a freshman in my mechanical engineer's program, I finally got sick of buying new TI-55's after wearing out 3 or so. I found a 41CV for around $250, which was still a fortune to a student, but cheaper than a new one. The guy I bought it off of was a cop who was had written a simple program to bust speeders by entering the time it took them to travel a measured distance. He said that it looked too much like magic to the traffic courts of the day (ha ha), and the tickets kept getting thrown out of court (radar was just becoming available for speed detection). Since he couldn't use it for that, he didn't have any use for it any more, and was selling it cheap to a student, so someone could get some use out of it. Wow what a great machine! I got fairly good at programming it, and it (along with a Math I expansion pack) helped me get the rest of the way through college. I've still got it, and it still sits on my desk, because it's the best for quick calculations. I've since had an 11C that I somehow lost track of, and a 48 SX that goes with me in the field, because it's indestructable, and so very versatile. My 49G+ (third one), is keeping me interested in RPL programming, though I keep hoping the keys on this one will break, as I've been promised a replacment 50G if they do. Now I find myself checking out garage and estate sales in the hopes of finding a stray HP to pick up on the cheap (I especially like the 67). I'm constantly tempted by e-bay, but I guess I'm not a dedicated enough collector to pay $300 for a replacment 11C. === Subject: Re: My first ever HP calc I bough my first HP in 1997, when i take on my hands my brand new HP48G. I remember that i was in the college (in Guatemala) studing technical drawing and surveying, with a classmate that still have today a HP32SII, when i saw that calculator, i wondered of the use and the programming, but in the HP store i saw that the 48 was a Q200.00 ($30.00) more expensive than the 32, and i don't care the price diference. And i still have it. Then, in 2001, i bough a HP49G a drastic speed of procesing, but with many stupid problems like the hard press keyboard, but i used in this time for topograph class, surveying, structures, hidraulics, home and small building electric instalations, construction and material costs whem i'm studing my master's degree architecture. . Since two years, i have a HP49G+, and i passed all my 49 programs to the 49+ for the job. Ooohh what a times.... === Subject: Re: My first ever HP calc I bough my first HP in 1997, when i take on my hands my brand new HP48G. I remember that i was in the college (in Guatemala) studing technical drawing and surveying, with a classmate that still have today a HP32SII, when i saw that calculator, i wondered of the use and the programming, but in the HP store i saw that the 48 was a Q200.00 ($30.00) more expensive than the 32, and i don't care the price diference. And i still have it. Then, in 2001, i bough a HP49G a drastic speed of procesing, but with many stupid problems like the hard press keyboard, but i used in this time for topograph class, surveying, structures, hidraulics, home and small building electric instalations, construction and material costs whem i'm studing my master's degree architecture. . Since two years, i have a HP49G+, and i passed all my 49 programs to the 49+ for the job. Ooohh what a times.... === I am in contact with the author. -- - - - - - - - - - - - - - - - - Bill Graves RKBA! bgraves@ix.netcom.com === Subject: Re: hp-49g+ mini-b accessibility Not sure what you're getting at. If you want to grab battery power from the calculator, go buy a mini-b cable of some sort, cut it up to expose the wires, and go to town. Bringing a soldering tool close to a calculator is a no-no. > > I'm curious if there is is any way to solder some small wires to pins 1 > and 5 of the USB Mini-b connector on the hp-49g+. Those are the power > and ground pins, and I'd like to get the power for a little project I'm > tinkering with. > > I've looked at the pictures I could find of the 49g+ circuit board, but > none had enough detail in the region of interest. > > hopeless. > > -Jonathan === Subject: CAS Command List I have an HP49g, a 49g+, and a 50g. The early ROM releases on the 49g used to give access to the CAS Command List through the CASCM softkey on the second page of the TOOLS menu, but for the ROMs released over the past few years, this key has only given CAS Help, and not the actual commands list - it thus now actually DUPLICATES the function of the adjacent HELP softkey. The intended convenience and functionality of the CAS Commands List has disappeared. The only way I can currently find to access the CAS Command List is via the second page of Equation Writer softkeys. Here, CMDS does indeed give the actual CAS Command List, and HELP does give the CAS Help, as intended. But, of course, this isn't available outside Equation Writer. As I said, the CASCM softkey USED to work correctly in earlier ROM versions, and this bug must surely be due to a simple error, such as an incorrectly updated ROM pointer address, and would thus be very easy to fix. Am I missing something? Have others noticed this bug too? If so, please speak up now! I have reported this bug numerous times to HP Calculator Support, but no action has ever been taken to fix it. If you Stan === Subject: Re: CAS Command List >I have an HP49g, a 49g+, and a 50g. The early ROM releases on the 49g >used to give access to the CAS Command List through the CASCM softkey >on the second page of the TOOLS menu, but for the ROMs released over >the past few years, this key has only given CAS Help, and not the >actual commands list You can still use the CASCMD cmd which is available from the catalog. Assign it to your custom menu, if you like. Marcus von Cube Wehrheim, Germany -------------------------------------------------------------- http://www.mvcsys.de Cruising with eComStation and PMINEWS/2 -------------------------------------------------------------- === Subject: Re: CAS Command List I agree that this sounds like a bug. The HP50g User Guide describes the correct (but non-existent) behaviour on page 1-7 (aka p36 in the pdf file). The HP50g User Guide has a rather comical entry you may have seen on page C 10 (aka p821). Using the CAS HELP facility Turn on the calculator, and press the 'TOOL' key to activate the TOOL menu. Next, press the 'F2' soft menu key, followed by the 'ENTER' key (the key in the lowest right corner of the keyboard), to activate the HELP facility. This is clearly yet another error in the manual (there are many). Although I'm new to HP calcs I am very disappointed with the documentation. Good job the HP48 manuals are available. > > I have an HP49g, a 49g+, and a 50g. The early ROM releases on the 49g > used to give access to the CAS Command List through the CASCM softkey > on the second page of the TOOLS menu, but for the ROMs released over > the past few years, this key has only given CAS Help, and not the > actual commands list - it thus now actually DUPLICATES the function > of the adjacent HELP softkey. The intended convenience and > functionality of the CAS Commands List has disappeared. The only way I > can currently find to access the CAS Command List is via the second > page of Equation Writer softkeys. Here, CMDS does indeed give the > actual CAS Command List, and HELP does give the CAS Help, as intended. > But, of course, this isn't available outside Equation Writer. As I > said, the CASCM softkey USED to work correctly in earlier ROM versions, > and this bug must surely be due to a simple error, such as an > incorrectly updated ROM pointer address, and would thus be very easy to > fix. Am I missing something? Have others noticed this bug too? If so, > please speak up now! I have reported this bug numerous times to HP > Calculator Support, but no action has ever been taken to fix it. If you > > Stan > === Subject: Battery voltage for both 49g+ and 50g The following program is an attempt to display the voltage for either the 49g+ or 50g. It uses Edwin Cordoba's code from BatStatus 1.3 http://www.hpcalc.org/details.php?id=6400 and detects which model based on a pointer posted by JYA. With new alkaline batteries, it displays 4.49V or 5.99V initially. With recently charged NiMH such as I use, it starts at ~4.2 or ~5.5. In addition it displays 0.00V if the 50g is powered by the USB cable. BTW, it works best with header = 2. :: SaveSysFlags BINT111 BINT2 CODE 00079 8FB9760808F70300F14D29EF1520A3EC002282E0002295EC092185E0F18DB8E071341F001083 40300080B60340010880BFF808034FF3000EF68FC7530 * Edwin Cordoba's Excellent code UNCOERCE PTR 2F3C7 * T = 50g F = 49g+ ITE % .005859375 * % 6. % 1024. %/ % .00439453125 * % 4.5 % 1024. %/ %* BINT2 DOFIX DO>STR CHR_V >T$ $>grob XYGROBDISP SetDA1Temp RestoreSysFlags ; @ 131.5 bytes # 275Ch A shorter version can return just a real number to the stack. Enjoy. Chuck Rushton === Subject: Re: Battery voltage for both 49g+ and 50g Good information Chuck. I am not owner of a Hp50, for that reason I dont know if the conversion becomes from 0 to 4.5V or from 0 to 6,0 V in the Hp50. I complement the code with my source code :: SaveSysFlags BINT111 BINT2 CODE SAVE INTOFF SKUB { *start !ARM STMDB sp! { R4 R5 R6 R7 R8 LP } MOV R2 $7C00000 ADD R2,R2 $0C LDR R2,[R2] STR R2,[R1 #2316] LDMIA sp! { R4 R5 R6 R7 R8 PC } !ASM *end } C=RSTK D0=C D1=80100 LC(5) end-start MOVEDN LC 80100 ARMSAT INTON LC 003FF A&C.A GOSBVL PUSH#ALOOP ENDCODE * Edwin Cordoba's Excellent code UNCOERCE PTR 2F3C7 * T = 50g F = 49g+ ITE % .005859375 * % 6. % 1024. %/ % .00439453125 * % 4.5 % 1024. %/ %* BINT2 DOFIX DO>STR CHR V >T$ $>grob XYGROBDISP SetDA1Temp RestoreSysFlags ; @ Edwin C.97rdoba. > The following program is an attempt to display the voltage for either the > 49g+ or 50g. > > It uses Edwin Cordoba's code from BatStatus 1.3http://www.hpcalc.org/details.php?id=6400 > and detects which model based on a pointer posted by JYA. > > With new alkaline batteries, it displays 4.49V or 5.99V initially. > > With recently charged NiMH such as I use, it starts at ~4.2 or ~5.5. > > In addition it displays 0.00V if the 50g is powered by the USB cable. > > BTW, it works best with header = 2. > > :: > SaveSysFlags > BINT111 > BINT2 > CODE 00079 > 8FB9760808F70300F14D29EF1520A3EC002282E0002295EC092185E0F18DB8E071341F0010834 0300080B60340010880BFF808034FF3000EF68FC7530 > * Edwin Cordoba's Excellent code > UNCOERCE > PTR 2F3C7 > * T = 50g F = 49g+ > ITE > % .005859375 > * % 6. % 1024. %/ > % .00439453125 > * % 4.5 % 1024. %/ > %* > BINT2 > DOFIX > DO>STR > CHR V > >T$ > $>grob > XYGROBDISP > SetDA1Temp > RestoreSysFlags > ; > @ > > 131.5 bytes # 275Ch > > A shorter version can return just a real number to the stack. Enjoy. > > Chuck Rushton === Subject: Re: Battery voltage for both 49g+ and 50g > Good information Chuck. I am not owner of a Hp50, for that reason I > dont know if the conversion becomes from 0 to 4.5V or from 0 to 6,0 V > in the Hp50. > I complement the code with my source code X You should both send these to the www.hpcalc.org === Subject: Re: Battery voltage for both 49g+ and 50g > You should both send these to the www.hpcalc.org > I would suggest that Edwin perhaps include this as an update to BatStatus. My only contribution was that of a scurvy marauder in taking his very cool code and repackaging it without the graphics. Of course, I also suggest it be named 'BAT50' but that's not entirely necessary :-) Btw, the routine which returns the voltage to the stack is: < Edwin's code ob > UNCOERCE PTR 2F3C7 ITE % .005859375 % .00439453125 %* (101.5 bytes # E281h) Chuck === Subject: Re: Battery voltage for both 49g+ and 50g >> You should both send these to the www.hpcalc.org >> > > I would suggest that Edwin perhaps include this as an update to BatStatus. > > My only contribution was that of a scurvy marauder in taking his very cool > code and repackaging it without the graphics. Of course, I also suggest it > be named 'BAT50' but that's not entirely necessary :-) > > Btw, the routine which returns the voltage to the stack is: www.hpcalc.org *************** > < Edwin's code ob > > UNCOERCE > PTR 2F3C7 > ITE > % .005859375 > % .00439453125 > %* > > (101.5 bytes # E281h) > > Chuck > === Subject: picture of 50g circuit board Does anyone have a picture of the circuit board on the 50g? One with high enough detail to roughly identify parts would be great. -Jonathan === Subject: Re: picture of 50g circuit board > > Does anyone have a picture of the circuit board on the 50g? One with > high enough detail to roughly identify parts would be great. > > > -Jonathan > A pic of the 49G+ is here http://www.hpcalc.org/details.php?id=5896 The 49G+ uses the same circuit board as the 50G. === Subject: Re: picture of 50g circuit board <091120061451301536%zeno333@mindspring.com> > The 49G+ uses the same circuit board as the 50G. My guess was that the circuit boards were similar (why not?) but not the same. Specifically, what changes were made to allow the 50g to run off USB power? Are the USB power pins (1 and 5) routed to the inside somewhere? I have opened my 49g+ so I have that as a reference. If someone is willing to open their 50g and take a picture (scan) I would appreciate it. -Jonathan === Subject: Re: picture of 50g circuit board > The 49G+ uses the same circuit board as the 50G. They already had a footprint for the serial port connector on the 49G+ PCB??? === Subject: Re: Any way to get HP 50g to split a number across lines? > On Tue, 31 Oct 2006 16:28:26 -0600: > >> Flag -79 [Textbook] has to be off >> for complex numbers to display in two lines. > > Flag -79 has to be ON; > it's the check mark in front of Textbook > in the MODES > DISP application which has to be OFF > (the flag state in this case is the opposite of the check mark). > > Other user friendly examples from the Human Factors field: > > Check this box if you don't want to be notified... > > Yes, we have no bananas... Also: not all the flags are CLEAR when the calc resets === Subject: Re: New release :-) X > Checked the rumored ROM 2.10-7 it matrixwriter has nice ABC labeled > columns :-) > (it supports absolute and relative addresses, but it seems that it > doesn't make any difference > when cloning the cells. Cell addresses get updated the same way as > the ones without $) The cloning seems to depend on the EVAL flag > Conclusion: > -seams to be not as flexible as MXEval, and unfinished, sure > -but it looks very nice :-D > -it would be nice to have matrixwriter like this in an official > version If Cyrille can persuade the Markedroids & Legalbots + Bossputer that this will increase sales > Also, the mentoned ROM has KEYTIME issues back on > (seamingly it sets and recalls the valid keytime value BUT it is > ignored and i get double pressesss :-) Huh? That should be impossible with the new keyboard design... > have fun, > manjo nowadays more than ever I'm learning French while trying to read Parisse's documents... === Subject: Re: New release :-) X >> Is there a new version on the works? >> :-D > > Not at the time > -i was playing with current version (V2) seems to be working fine in > all currently available aspects :-) X I can make it halt in an error something about missing local variable?! === Subject: Re: ROM 2.10-7 / HP49G+/50G >> This is not an HP release whatsoever. >> It's Bernard Parisse project... >> >> I do not expect the geometry and spreadsheet function to be >> available on the official ROM any time soon. >> >> For all I know of course. > > It's a ROM that should allow the HP49 for the French math > teachers recruitement (named CAPES). Geometry and a small > spreadsheet are required for this, hence the new apps. The geometry > is a little bit slow especially on the original 49G. The > spreadsheet is slow, it has not been as tested as the geometry. Is the spreadsheet cached? Is there a possibility that you have time to write docs in Finnish? (English will do if you can't write Finnish) Thnsk you for an excellent application I hope You and Cyrille can make HP to accept it into a future ROM === Subject: Re: ROM 2.10-7 / HP49G+/50G Reply-to: Veli-Pekka Nousiainen > I just got a total failure of memory (ttrm) with this update. > > Use it at your own risk! > > I re-installed 2.09, and everything works well! It seems be early beta.... I think it's meant to be released for anything else but an appertizer... I hope that HPQ persuades Parisse to use ENGLISH for keywords.... === Subject: Re: Text File > On my 49g plus, I copied some plain DOS informational text files on to > the SD card from the computer and then copied them into the HOME dir. > on the calculator They can be called up and seemingly can be read > correctly. > I tried to copy the same files from the computer to my 49g (not plus) > thru HP conn4x and the serial port. The plain text files won't > transfer. Instead I get an error message that the files are not the > right type. > My question: How can DOS plain text files be transferred to the 49g > (not plus)?? > G . Depends on a) transfe type ASCII/binary b) text header missing when using ASCII === Subject: Re: HP48GX Prices Some sellers price it in the $300 range and manage to sell them easily if they are indeed brand new. > I am in Buenos Aires at present, and new ones seem to run around $150 > US here, and I was thinking of picking one up to take back to the US. > > How much would be considered an adequate price to pay for an HP48GX? > > - Marco === Subject: Re: HP48GX Prices I didn't realize that new 48GX's were still available for purchase. I think you could buy a few of them, bring them to the US and sell them for $200 pretty easily. The profits would pay for yours, making it effectively free to you. > I am in Buenos Aires at present, and new ones seem to run around $150 > US here, and I was thinking of picking one up to take back to the US. > > How much would be considered an adequate price to pay for an HP48GX? > > - Marco === Subject: Re: Spreadsheet BUG - ROM 2.10-7 >> and one can do TRN >> then use the spread sheet sideways >> and finally TRN the result >> BUT >> then you are limited to 26 rows.... >> >> > > That will not work, since TRN will not translate cell references. (/)&)(/&#)% - how silly of me... Then there is one more command to add TRANS === Subject: Re: Backup problem -- HP48GX > My Home directory is about 100 kB, so I can't create it into memory > card port, (b) clear memory (ON/A/F), and then (c) move the backup > object into main memory and (d) transfer it. That's feasible, although > has happened from time to time. There is a backup function in the HP > connectivity software on the File menu, which starts up but then hangs, > and which is supposed to cause the backup Homedir object to be streamed > out the serial port as it's built. Using the old Kermit protocol, one > can do this: establish connectivity and then put :IO: on > the stack before the ARCHIVE function. This version gets into dealing > with Kermit (slow) and translation (tricky), unless I could find the > old version of the connectivity software, which I had once but which I > don't have any more. I'd really rather have the XMODEM version work, > but so far I haven't figured out how to do that. > --Irl > Yes, that's right, Kermit did work well in that way. It's been so long since I've had a seial port on a computer in order to use it. The USB to RS232 adapter I have was always hit and miss.....the major reason for moving over to the 49g+ and 50g+. Are you just trying to backup the Home Directory? === Subject: Re: Backup problem -- HP48GX Yes, I'm just trying to backup the Home directory. It's too large to make a separate copy into main memory so my choices are (I think) either get the Conn4x Backup function to work (my preference), or drag-and-drop all the items from the home directory to the PC. Before I and alarms into a variable. It's kludgey. Irl > > My Home directory is about 100 kB, so I can't create it into memory > > card port, (b) clear memory (ON/A/F), and then (c) move the backup > > object into main memory and (d) transfer it. That's feasible, although > > has happened from time to time. There is a backup function in the HP > > connectivity software on the File menu, which starts up but then hangs, > > and which is supposed to cause the backup Homedir object to be streamed > > out the serial port as it's built. Using the old Kermit protocol, one > > can do this: establish connectivity and then put :IO: on > > the stack before the ARCHIVE function. This version gets into dealing > > with Kermit (slow) and translation (tricky), unless I could find the > > old version of the connectivity software, which I had once but which I > > don't have any more. I'd really rather have the XMODEM version work, > > but so far I haven't figured out how to do that. > > --Irl > > > > Yes, that's right, Kermit did work well in that way. It's been so long since > I've had a seial port on a computer in order to use it. The USB to RS232 > adapter I have was always hit and miss.....the major reason for moving over > to the 49g+ and 50g+. Are you just trying to backup the Home Directory? === Subject: Re: Backup problem -- HP48GX > Yes, I'm just trying to backup the Home directory. It's too large to > make a separate copy into main memory so my choices are (I think) > either get the Conn4x Backup function to work (my preference), or > drag-and-drop all the items from the home directory to the PC. Before I > and alarms into a variable. It's kludgey. If you check hpcalc.org at http://www.hpcalc.org/hp48/utils/memory/ you'll find a number of backup programs for the 48GX. I personally use BKUP 4.6 which backs up HOME and any ports you select, but if all you want is to back up HOME, you might prefer Backup GX which is described as: Simple backup program to back up HOME, including alarms and user keys, via XModem. -- Wayne Brown (HPCC #1104) [CapitalThorn].bes ofereode, [CapitalYAcute]isses swa m.beg. (That passed away, this also can.) Deor, from the Exeter Book (folios 100r-100v) === Subject: Re: Backup problem -- HP48GX <44L4h.13325$GU5.6461@bignews8.bellsouth.net> Excellent advice. My problem is solved -- using BKUP46 with the built-in HP XMODEM and the Upload file (Manual XSEND) command on ... and one more thing: is there a forum for reporting bugs in the connectivity software? The backup command in conn4x really ought to work ... Irl > > Yes, I'm just trying to backup the Home directory. It's too large to > > make a separate copy into main memory so my choices are (I think) > > either get the Conn4x Backup function to work (my preference), or > > drag-and-drop all the items from the home directory to the PC. Before I > > and alarms into a variable. It's kludgey. > > If you check hpcalc.org at http://www.hpcalc.org/hp48/utils/memory/ you'll > find a number of backup programs for the 48GX. I personally use BKUP > 4.6 which backs up HOME and any ports you select, but if all you want > is to back up HOME, you might prefer Backup GX which is described as: > > Simple backup program to back up HOME, including alarms and user keys, > via XModem. > > -- > Wayne Brown (HPCC #1104) > > [CapitalThorn].bes ofereode, [CapitalYAcute]isses swa m.beg. (That passed away, this also can.) > Deor, from the Exeter Book (folios 100r-100v) === Subject: Re: Backup problem -- HP48GX > Excellent advice. My problem is solved -- using BKUP46 with the > built-in HP XMODEM and the Upload file (Manual XSEND) command on You're welcome; glad I could help. > ... and one more thing: is there a forum for reporting bugs in the > connectivity software? The backup command in conn4x really ought to > work ... I can't help you there, but I remember having the same problem, which is what got me to try BKUP46 in the first place. -- Wayne Brown (HPCC #1104) [CapitalThorn].bes ofereode, [CapitalYAcute]isses swa m.beg. (That passed away, this also can.) Deor, from the Exeter Book (folios 100r-100v) === Subject: 48gx grob into 50g i'm sending off for 2 50g's and the seller is going to transfer the programs i have in my 48gx (which i'm sending him) into the new 50's. i want to revise my programs so that the identical program will work in the 48 or 50. with the help of members of this group i have learned that i can use { VER ) 1 GET TYPE in a program to find if it resides in a 48 or 50 and have used this to get the user key assignments i want in each model. i understand that the screen size will be different on the 50 and would like to know what will happen when i transfer graphic objects from my 48 which begin with GROB 131 64 into the 50. i would like to know if the grobs will transfer as is even if i mite have to correct it to work in the 50. what i don't want to happen is that i send my 48 out and find the transfer aborts because of the grobs. if it will transfer as is i can get it back home and correct it to work in the 50. if it won't transfer as is i can either make some sort of adjustment using VER TYPE so that it works in either model (my ideal solution) or i can just store anything (like the number 1) in the variables which are now grobs to make the transfer work and correct back home. with the 50 screen bigger i can forsee that all i'm going to have to do is add zeros to the top and bottom of the grob but will i also need to change the GROB 131 64 part and can this be done within the grob itself, based on VER TYPE. finaly, am i correct that the key number for say the bottom right most key on the 50g is 105. (non-shifted) ? === Subject: Re: 48gx grob into 50g > i would like to know if grobs will transfer as is They are both binary and ascii compatible; any calculator can display any size (larger than screen need scrolling, smaller than screen just don't fill the screen, and also do not need to pad the grob, just try the ->LCD or other commands as usual in UserRPL) > finaly, am i correct that the key number for say > the bottom rightmost key on the 50g is 105? Yes, ENTER etc. on 49/50 is 105.p [keyplane .0 acts like .1, just as in 48] [r->] [OFF] === Subject: Re: 48gx grob into 50g Arturo === Subject: 48GX battery life I had heard the other day that the 48GX should get about 6 months service calculators and both got about six weeks out of a set of batteries. What should be reasonable? If they should last longer, the only common thread is that I used the same is six weeks about right? Scott Chapin === Subject: Re: 48GX battery life >I had heard the other day that the 48GX should get about 6 months service >calculators and both got about six weeks out of a set of batteries. What >should be reasonable? > > If they should last longer, the only common thread is that I used the same > or is six weeks about right? As Han indicates in his response, it depends. You don't indicate whether your TDS card(s) have button or internal batteries. It makes a huge difference. Some years ago I purchased an SMI 1 meg card for the 48gx. It had the new, improved internal battery that is charged by the AAA batteries. For ~2 weeks I was putting in new alkaline batteries every other day. Obviously, unacceptable. I finally figured out (I think....) that since I was running libraries out of the card in slot 2 (ports 2-9), the card was just sucking the batts dry. This happened with 2 cards. Switched to an HP 1 meg card with button battery and never looked back. That HP card still works flawlessly today, after ~7 years. Serial port comms and read/write to the card use a lot more juice than just crunching numbers, as does decompiling/recompiling programs and libraries. I believe that 6 weeks is an acceptable lifespan for batteries under your usage conditions. 6 months is a stretch. Btw, are you a land surveyor? Your use of TDS cards gives me that impression (possibly way wrong). Chuck === Subject: Re: 48GX battery life X > Some years ago I purchased an SMI 1 meg card for the 48gx. It had the > new, improved internal battery that is charged by the AAA > batteries. For ~2 weeks I was putting in new alkaline batteries every > other day. Obviously, unacceptable. I finally figured out (I > think....) that since I was running libraries out of the card in slot > 2 (ports 2-9), the card was just sucking the batts dry. This happened > with 2 cards. Switched to an HP 1 meg card with button battery and > never looked back. That HP card still works flawlessly today, after > ~7 years. > Serial port comms and read/write to the card use a lot more juice > than just crunching numbers, as does decompiling/recompiling programs > and libraries. > I believe that 6 weeks is an acceptable lifespan for batteries under > your usage conditions. 6 months is a stretch. > > Btw, are you a land surveyor? Your use of TDS cards gives me that > impression (possibly way wrong). and I'm just using either the internal Flash or external SD Flash-card Neither needs batteries to keep memory AND the 49g+/50G has a replaceable back-up battery Those old BAD 48GX days are over === Subject: Re: 48GX battery life The battery life is dependent on usage. How often are you using your HP48GX? Even with regular use in a classroom, the HP48GX is still not as often used as out in the field. Moreover, when you use an HP48GX to do data collection, then presumably you must interface with some external device for communication. The use of the serial ports is what causes the biggest battery drain. If all you are doing are a few calculations for a math assignment each day, then the batteries will last for years, even. But if you constantly use it to download datapoints, then six weeks is not out of the ordinary. > I had heard the other day that the 48GX should get about 6 months service > calculators and both got about six weeks out of a set of batteries. What > should be reasonable? > > If they should last longer, the only common thread is that I used the same > is six weeks about right? > > > Scott Chapin === Subject: Re: 48GX battery life I rarely used it with an external device, except for the occasional backup. Working in a finance environment, I would crunch a few numbers every day and run some fetish programs that would crunch a large matrix. One program could take up to 9 minutes to execute, and I would run it about once each week. Just as long as 6 weeks isn't unreasonable, i won't worry about it! > The battery life is dependent on usage. How often are you using your > HP48GX? > Even with regular use in a classroom, the HP48GX is still not as often > used > as out in the field. Moreover, when you use an HP48GX to do data > collection, > then presumably you must interface with some external device for > communication. > The use of the serial ports is what causes the biggest battery drain. > If all you are > doing are a few calculations for a math assignment each day, then the > batteries will > last for years, even. But if you constantly use it to download > datapoints, then six > weeks is not out of the ordinary. > > >> I had heard the other day that the 48GX should get about 6 months service >> different >> calculators and both got about six weeks out of a set of batteries. What >> should be reasonable? >> >> If they should last longer, the only common thread is that I used the >> same >> or >> is six weeks about right? >> >> >> Scott Chapin > === Subject: sending picture to hp49G+ hello any idea how to go about sending a picture file to hp 49G+?? === Subject: Re: sending picture to hp49G+ > hello any idea how to go about sending a picture file to hp 49G+?? > Use XnView to change it to a grob (in your PC) then use the Conn4x to transfer it into your calc === Subject: Re: new - HP-GCC 2.0 Native Windows Distribution John, I appreciate having a native Windows tool. I've only been using HPGCC for a little over a month. Would you recommend I switch to the new version now or wait? Can I assume that the basic C compiler is still the same and it is just the windowing IDE feature that is new? Brion > http://hpgcc.org:8080/pebble/2006/10/29/1162093737334.html > > a pure, native Windows distribution for all NT based kernels === Subject: Re: new - HP-GCC 2.0 Native Windows Distribution > John, > > I appreciate having a native Windows tool. I've only been using HPGCC > for a little over a month. Would you recommend I switch to the new > version now or wait? Can I assume that the basic C compiler is still > the same and it is just the windowing IDE feature that is new? Please, don't get confused. There's no functional difference between the old 2.0 Windows distribution and the new one. The only difference is internal, one runs on an emulation layer provided by cygwin, while the other has true native tools. If you already have it installed and working properly, there's no reason for you to switch. If you start a clean installation on a machine that doesn't have cygwin installed, then the new distro will be smaller and faster. The windowing IDE is identical, and the tools work just the same from the user point of view. Claudio === Subject: Re: new - HP-GCC 2.0 Native Windows Distribution > http://hpgcc.org:8080/pebble/2006/10/29/1162093737334.html > > a pure, native Windows distribution for all NT based kernels I'm still holding my breath waiting for the HPGCC 3.0 with a blue face === Subject: Steen Schmidt's new library???? When will Steen Schmidt's new libray that he has mentioned a couple of times in the past become available?? I am sure some are waiting with anticipation :) :) === Subject: How to avoid evaluation of arguments I have coded in UserRPL 2 recursive functions which I intended to use to study some symbolic algebra algorithms, using my HP-50g, with rom 2.09. One function ALG->L converts an algebraic to a nested list structure. An expression such as (a) '2*(a+b*cos(x))' becomes (b) {2 {a {b {x cos} *} +} *}. The inverse function L->ALG takes nested lists like (b) and converts them back to algebraic as in (a). The key step in L->ALG is placing all the arguments from the list on the stack, then placing the operator on the stack, and doing an EVAL. This works a treat as long as nothing in the nested list is incompletely evaluated. However, I have hit a stumbling block. I was testing with this algebraic (c) 'int(l,u,x,x)', representing the definite integral from lower limit l to upper limit u, of x, with respect to x. It is EVALuable, and indeed, doing an EVAL on this algebraic gives us: (d) (u^2-l^2)/2 Therein is the problem. Conversion of (c) by ALG->L gives (e) {l u x x int}, as expected. (int being the integral function sign or operator). Conversion of (e) to algebraic by L->ALG gives me this: (f) (u^2-l^2)/2, the fully evaluated form, instead of giving me back (c) the original integral. Obviously, L->ALG is causing its arguments and its operators to be fully evaluated. How can I stop that? I experimented with QUOTE() but that didn't help. Is there some simple trick or some SYSEVAL I could use to stop the evaluation. Basically, I want something like an APPLY that works for builtin operators. Help me, Ani-wan! You're my only hope! === Subject: Re: How to avoid evaluation of arguments General remarks re Fri, 10 Nov 2006 01:03:23 -0600, for Joe Veazey: > I have coded in UserRPL 2 recursive functions which I intended to use to > study some symbolic algebra algorithms, using my HP-50g, with rom 2.09. > > One function ALG->L converts an algebraic to a nested list structure. > An expression such as '2*(a+b*cos(x))' becomes {2 {a {b {x cos} *} +} *} > > The inverse function L->ALG takes nested lists like the above > and converts them back to algebraic. The first task is easier than the second. The built-in ->LST and ->ALG (in built-in Development library 256) simply change the object type, and if these serve your purposes well enough (just to inspect algebraics), then use those. However, there may be various unseen internal elements in any algebraic which are not displayed in the list form, but which may be necessary, so you can not in general just take any bunch of RPL commands and apply ->ALG to create the proper algebraic object. The following is the ->RPN program produced by the HP48G series TEACH command, which uses OBJ-> to decompose algebraics, and recursively invokes itself as may be necessary, until a pure RPN list is obtained; its result may differ from what ->LST produces, in that the unseen elements are removed: << OBJ-> IF OVER THEN -> n f << 1. n FOR i IF DUP TYPE 9. == THEN ->RPN END n ROLLD NEXT IF DUP TYPE 5. =/ THEN 1. ->LIST END IF n 1. > THEN 2. n START + NEXT END f + >> ELSE 1. ->LIST SWAP DROP END >> '->RPN' STO This transforms the integral '.S(a,b,c,d)' to { a b c d .S } although what the original algebraic actually contains is { a b 'c' 'd' .S } which in SysRPL syntax reveals internal symbolic objects which quote some arguments, like this: { ID a ID b SYMBOL ID c ; SYMBOL ID d ; xINTEGRAL } Or, to say the same thing, what you saw in the list as 'c' and 'd' were not just variable names, but were themselves symbolic objects; this was obscured by the fact that the stack is normally displayed by the UserRPL decompiler, which doesn't show everything -- you can set flag -85 to use the SysRPL decompiler instead for stack display, which will present a different (and complete) view of all objects. You were unable to reconstruct your own original symbolic integral because even if you preserved the symbolic arguments, what you did, in effect, was equivalent to applying EVAL to the *original*expression*, rather than using its proper original arguments, commands, and object count with ->ALG; in other words, you *evaluated* the integrate *command* itself, rather than just inserting it into the algebraic object along with its arguments. E.g. '.S(a,b,c,d)' ->LST LIST-> shows what must be on the stack before performing ->ALG to re-construct this original algebraic. Note that what will appear as 'c' and 'd' on the stack are actually algebraic objects containing variable names, rather than just unquoted variable names; you can replace the *symbolic* objects 'c' and 'd' with just variable names before performing ->ALG, but then what you produce, while looking identical to the original algebraic, will nonetheless be different, and will if evaluated first evaluate 'c' and 'd' rather than quoting them -- the result might be the same if 'c' and 'd' are undefined; otherwise the result might be different. The built-in compiler knows how to build the algebraic object suited to each algebraic function, but in general you don't, so unless you simply preserve exactly what was in an original algebraic object and rebuild it with ->ALG, you may not produce the same thing that the compiler would have produced. Hope this has proved of interest. Best wishes from http://www.mum.edu and http://www.maharishischooliowa.org === Subject: Re: How to avoid evaluation of arguments > However, I have hit a stumbling block. I was testing with this algebraic > > (c) 'int(l,u,x,x)', > > representing the definite integral from lower limit l to upper limit u, > of x, with respect to x. It is EVALuable, and indeed, doing an EVAL on > this algebraic gives us: > > (d) (u^2-l^2)/2 > > Therein is the problem. > > Conversion of (c) by ALG->L gives > > (e) {l u x x int}, as expected. (int being the integral function sign or > operator). > > Conversion of (e) to algebraic by L->ALG gives me this: > > (f) (u^2-l^2)/2, the fully evaluated form, > > instead of giving me back (c) the original integral. Well this is interesting, I tried this on my G+ and it gives me the original 'int(1,u,x,x)' Which rom version do you use? Is the ALG->L and L->ALG, that you refer to, from development menu ? These 2 commands are actualy called: ->LST and ->ALG manjo === Subject: Re: How to avoid evaluation of arguments @ss408.t-com.hr: >> However, I have hit a stumbling block. I was testing with this algebraic >> >> (c) 'int(l,u,x,x)', >> >> representing the definite integral from lower limit l to upper limit u, >> of x, with respect to x. It is EVALuable, and indeed, doing an EVAL on >> this algebraic gives us: >> >> (d) (u^2-l^2)/2 >> >> Therein is the problem. >> >> Conversion of (c) by ALG->L gives >> >> (e) {l u x x int}, as expected. (int being the integral function sign or >> operator). >> >> Conversion of (e) to algebraic by L->ALG gives me this: >> >> (f) (u^2-l^2)/2, the fully evaluated form, >> >> instead of giving me back (c) the original integral. > > Well this is interesting, > I tried this on my G+ and it gives me the original 'int(1,u,x,x)' > > Which rom version do you use? > Is the ALG->L and L->ALG, that you refer to, from development menu ? > > These 2 commands are actualy called: ->LST and ->ALG > > manjo > > > That's a lower case L (lower case ell) in my examples, not a numeric 1, which is what you typed. Damned 1/l (one/ell) characters. Bad design. :-) === Subject: Fwd: RS232 Homebrew for interface from RS232 to Ham Radio If found the following message in my mailbox: -------------------------------------------------------------------------- === Subject: RS232 Homebrew for interface from RS232 to Ham Radio I do not post to this group yet. I saw discussion about HP50 signal from RS232. I built this interface and it works both ways. Many such as this are available already commercially or to build. Please post to the HP group this information. Also, I use eCom Station and before OS/2 since 1992. John Baranowsky http://www.seed-solutions.com/gregordy/Amateur%20Radio/Experimentation/CIVIn te rface.htm -------------------------------------------------------------------------- Marcus von Cube Wehrheim, Germany -------------------------------------------------------------- http://www.mvcsys.de Cruising with eComStation and PMINEWS/2 -------------------------------------------------------------- === Subject: Re: Fwd: RS232 Homebrew for interface from RS232 to Ham Radio OK. At home I can post to the group. The link is broken by insert of carriage return. See below. The author shows 5v power from both serial port and external with a discussion on how the 5v from the serial port was marginal. Note the LM7805 IC used as the 5v regulator. This circuit can be simplied for HP50g; no PTT is required. N4001's protect equipment; a good thing. The MAX232 is the signal leveler which is essential for the interface. Nice discussion on capacitors; some RS232 IC's have this built in. Within this link are other links. Or just goggle RS232 signal levelers and many hits come up. John http://www.seed-solutions.com/gregordy/Amateur%20Radio/Experimentation/CIVIn terface.htm === Subject: Re: Fwd: RS232 Homebrew for interface from RS232 to Ham Radio The link got mangled. I think it's http://www.seed-solutions.com/ gregordy/Amateur%20Radio/ Experimentation/CIVInterface.htm He's using a MAX32 chip. > If found the following message in my mailbox: > > -------------------------------------------------------------------------- > === > Subject: RS232 Homebrew for interface from RS232 to Ham Radio > > I do not post to this group yet. I saw discussion about HP50 signal from > RS232. > > I built this interface and it works both ways. Many such as this are > available already commercially or to build. > > Please post to the HP group this information. > > Also, I use eCom Station and before OS/2 since 1992. > > John > Baranowsky > > http://www.seed-solutions.com/gregordy/Amateur%20Radio/Experimentation/CIVInt e > rface.htm > > -------------------------------------------------------------------------- > > > Marcus von Cube > Wehrheim, Germany > -------------------------------------------------------------- > http://www.mvcsys.de Cruising with eComStation and PMINEWS/2 > -------------------------------------------------------------- === Subject: Quick ?s about Memory Card Just received my new 50G... (love it, BTW) MUCH faster than my blue bomber. I passed on the 49G+ due to the issues discussed here (keyboard, etc.) and the one I returned (an early 49G+ with a faulty key or two out of the box/plastic). A few questions regarding memory card(s)... If I insert a card, it is available via the filer as port3, if I understand correctly. .. Can I move things to/from the card via the filer at will, or is it required to use the command line for certain operations? It seems it's smarter to format the card via a PC and a USB card port, rather than the calc, . Is this true/advisable? I read a post some time back indicating that, while connected to the PC via the USB port/cable, the calc gets its juice from the PC... is my memory correct? (searched the NG, but I think the message appeared earlier than the cache on my machine) -- Grumpy Aero Guy === Subject: Re: Quick ?s about Memory Card Great... I'll play with it to see how it all works.... -- Grumpy Aero Guy > Just received my new 50G... (love it, BTW) > > MUCH faster than my blue bomber. I passed on the 49G+ due to the issues > discussed here (keyboard, etc.) and the one I returned (an early 49G+ with > a faulty key or two out of the box/plastic). > > A few questions regarding memory card(s)... > > If I insert a card, it is available via the filer as port3, if I > understand correctly. .. > > Can I move things to/from the card via the filer at will, or is it > required to use the command line for certain operations? > > It seems it's smarter to format the card via a PC and a USB card port, > rather than the calc, . Is this true/advisable? > > I read a post some time back indicating that, while connected to the PC > via the USB port/cable, the calc gets its juice from the PC... is my > memory correct? > (searched the NG, but I think the message appeared earlier than the cache > on my machine) > > > -- > Grumpy Aero Guy > > > > === Subject: Re: Quick ?s about Memory Card > If I insert a card, it is available via the filer as port3, if I > understand correctly. .. > > Can I move things to/from the card via the filer at will, or is it > required to use the command line for certain operations? Using the filer you can move from other locations (home, ports 0,1,2) to the sd root and from anywhere on the sd card to home and other ports. Moving into subdirectories takes a little more user intervention. An example: 2: obj STO > It seems it's smarter to format the card via a PC and a USB card port, > rather than the calc, . Is this true/advisable? I personally always reformat via pc and card reader, and from experimentation and advice from others (TW and John Evers), use fat16 with 16k clusters. Btw, I use a 512 meg card. I'm unaware of a way to make the 50g or 49g+ use alternate cluster sizes when doing on-calc formatting. > I read a post some time back indicating that, while connected to the PC > via the USB port/cable, the calc gets its juice from the PC... is my > memory correct? Yep. Works good and saves your batteries. One caveat is that if the 50g is already on (under battery power), I *think* you have to cycle on/off for the usb power to activate. Congrats on the new 50g. I like mine, too :-) Chuck === Subject: Re: Quick ?s about Memory Card >> I read a post some time back indicating that, while connected to the PC >> via the USB port/cable, the calc gets its juice from the PC... is my >> memory correct? > > Yep. Works good and saves your batteries. One caveat is that if the 50g is > already on (under battery power), I *think* you have to cycle on/off for the > usb power to activate. ...or is this just a bug in your/Edwin's recently posted battery-voltage program (returning 0.0V also *after* the calc is disconnected)? The power test display ([ON]+[ F], [8]) gets updated as soon as the calc is powered through USB!?! === Subject: Re: Quick ?s about Memory Card >> Yep. Works good and saves your batteries. One caveat is that if the 50g >> is already on (under battery power), I *think* you have to cycle on/off >> for the usb power to activate. > ...or is this just a bug in your/Edwin's recently posted battery-voltage > program (returning 0.0V also *after* the calc is disconnected)? The power > test display ([ON]+[ F], [8]) gets updated as soon as the calc is powered > through USB!?! I think, but can't prove, that the two are related. And no, I'm not sure whether it's a bug. I believe that power cycling or [ON]+[F] does * something * in the OS which then allows updated/correct power source indication. Exactly when or how it switches batts<>usb is not known by me. Then there's the phenomenon when under usb power the calc sorta gets unhappy if the PC suddenly shuts off. Cyrille or JYA might be able to definitively explain but I cannot. :-( === Subject: Please Consider marketing.. Please Consider producing a compact scientific RPN Calculator which is not Cut-off below the knees, so to speak. I'm stating this request because: I have a hope that Design might actually consider candid feedback. Despite featuring an electricaly functional 4-way edit key, The 33s will not allow expression, or history editing. The 33s has >30,000 strokes of continuous memory, but only 26 single character variables and subroutine labels. I've been told it lacks a fully integrated Radius/Angle mode. I Know that there is no facility for matrix functions, even 3x3. Would you mind please? I'm not alone in my view, and this is a matter of programming alone. I also mean to offer that this is a damaging introduction for the company's product design approach. Such omissions provoke remorse and anger in many customers. A winner wins. A cripple struggles. Choose. === Subject: Re: Please Consider marketing.. > Please Consider producing a compact scientific > RPN Calculator which is not > Cut-off below the knees, so to speak. > > I'm stating this request because: > > I have a hope that Design might actually consider candid feedback. > > Despite featuring an electricaly functional 4-way edit key, > The 33s will not allow expression, or history editing. > > The 33s has >30,000 strokes of continuous memory, but > only 26 single character variables and subroutine labels. > > I've been told it lacks a fully integrated Radius/Angle mode. > I Know that there is no facility for matrix functions, even 3x3. > > Would you mind please? I'm not alone in my view, > and this is a matter of programming alone. > > I also mean to offer that this is a damaging > introduction for the company's product design approach. > > Such omissions provoke remorse and anger in many customers. > > A winner wins. A cripple struggles. Choose. But it's still better than it's predicessor the 32S & 32SII the proice difference between 8KB and 32KB chips was neglible and possible in the future (from the decision moment) tha price and availability of the smaller chip might be a big question Now this is the 1st time in history that HP has too huge memory (comparable to other features) in their calculator I remember 41C soon upgraded to 41CV The worst cas being the HP-28C which was almost unusable with it's small memory (compared to the potential) lucky enough one can solder a big chip into it (Same as with the 42S, which memory was OK by me) Unfortunately extra labels are not available You should consider HP 39gs instead the variable names can now be long === Subject: Re: Please Consider marketing.. You're probably not aware that the design of the HP 33s was largely driven by the need to keep it acceptable for use on standardized tests. Some of what you mention -- such as only being able to use backspace for editing equations! -- surely wouldn't make it unacceptable if improved, but some of the other functions -- such as full matrix support or more variables -- probably would. Or maybe not -- there have been threads on here in the past about the functionality of various calculators that are acceptable on standardized tests, and unfortunately there isn't any hard and fast rule on what's allowed and what isn't. I doubt HP is going to make any changes and come out with, e.g., an HP 34. They're building what's clearly a feature-poor machine -- based on the hardware available (the 33s) -- in order to meet a particular market demand, and if you want more I believe the official marketing response would be, Get an HP 50g! For less than 3x the price, you get about 100x the functionality in an HP 50g... but of course you can't use it on standardized tests. I do wish the +/-/*// keys were in the same place on the 33s and 50g -- I make a lot of mistakes when switching between the two. > Such omissions provoke remorse and anger in many customers. In my case, as the HP 33s does little more than the 32S II, despite having about 100x the memory and a 10x faster CPU, it just provokes disappointment. :-) ---Joel === Subject: PC program for Library Creation Although in theory the maximum size for a library is 128k. in practice the maximum size is significantly less because the library has to be created from a directory in HOME (which has a total of 140k bytes) Is there PC program for creating libraries for the HP49/HP50 as there was for the HP48? Luis