A153 Subject: Questions about sofare I'm writing I have a few questions that have piled up in the last couple days. Please excuse my ignorance; I'm still getting used to my HP49G+, and references to existing documentation or tutoris would definitely be appreciated. Here goes: 1. I've just written a library for simulating air-pressure powered bottle rocket flights on the 49G+. Unfortunately, it takes a LONG time to finish. I'd like to do something simple to let the user know how much longer they will need to wait... While it would be rely cool to draw a graph of height vs. time as it works, I am not that ambitious and I'd be perfectly satisfied with just displaying the number of seconds cculated. However, l the references I can find to display manipulation are rather complicated, and seem to assume I want to do video-game graphics. Does someone have just a simple example of sticking a text counter on the screen while a cculation is running? Or is that going to be difficult enough that it's not worth it? 2. On a related note, would it be useful to learn Saturn (or, from recent posts, even ARM) assembly language and rewrite some parts of the application in that for speed? I'm skeptic, because literly the entire program consists of lots of re arithmetic. Would either processor do that better, or am I looking at being limited to cls into the cc sofare anyway so that assembly language wouldn't help much? (I have no desire to write my own code in assembler to perform basic floating-point math! I assume neither processor has a fp math coprocessor.) 3. I've noticed that a few programs produce data on the stack that's labeled as just Library Data. I can't find a reference to any SysRPL routines that interact with this kind of data. I'm sure I'm missing something obvious here. What is it? 4. If anyone has an interest in this area and would like to try out the program, please let me know! I'd especily love it if someone who knows something of the math here would look over the application and check for mistakes. I, myself, know neither SysRPL nor the math of bottle rockets very well, and have spent much of today reading web sites in an attempt to glean the necessary information to write this program. Just email me if you want the library and/or source code. When it's more put together, I'll submit it to hpcc.org. === Subject: Re: Questions about sofare I'm writing For your first question, have a look at the following and copy it. << 0 WHILE 1 REPEAT 1 + DUP Running time: SWAP 1 + 1 DISP 1 WAIT END If you want your code to run faster you have either to simplify your cculations or use sysRPL or both, ASM is not worth the trouble when doing cculations. LIB DATA objects are archive objects that can't easily be created using User RPL but it is easy to do it in sysRPL or ASM. I don't know anything about water rockets but I am not too bad at maths and not too bad at programming the hp. At the moment I have no re project that motivate me on the hp but yours seems interesting. Drop me an email if you are interested in cooperation and maybe learn a few tricks and sysRPL === Subject: Re: Questions about sofare I'm writing > I don't know anything about water rockets but I am not too bad at maths and > not too bad at programming the hp. At the moment I have no re project that > motivate me on the hp but yours seems interesting. Drop me an email if you > are interested in cooperation and maybe learn a few tricks and sysRPL Sounds great. I'll send you what I've got by email. I may try to add the time display code you provided first, just for kicks. Seems, though, that I'll need to convert it to SysRPL first. I can't embed a UserRPL program into my SysRPL code, can I? === Subject: Re: Questions about sofare I'm writing In case anyone is interested, http://cdsmith.u.net/HPBottle.zip contains the current version of my bottle rocket simulator. I did add a time counter, by the way. Just be careful of the input format; it's not completely checked for vidity, so you can probably crash your cculator by mucking it up. User-level documentation is included in the zip file. I don't consider the program to be complete yet, but I do consider it good enough that it might be useful. Subject: Re: Questions about sofare I'm writing What's a bottle rocket? Is it a flying toy? > In case anyone is interested, > http://cdsmith.u.net/HPBottle.zip contains the current version of my > bottle rocket simulator. I did add a time counter, by the way. Just be > careful of the input format; it's not completely checked for vidity, > so you can probably crash your cculator by mucking it up. > User-level documentation is included in the zip file. > I don't consider the program to be complete yet, but I do consider it > good enough that it might be useful. Subject: Compatibility beeen HP49G and HP49G+ I've just gotten an HP49G+ (first HP cc ever, and I rely like it so far!) and have been trying some sofare (mostly games at this point) from hpcc.org. I've noticed that the sofare there is very hit-and- miss on the G+ cculator. I guess I'm just wondering if other people have had the same experience, or if I'm doing something wrong. Specificly, I've noticed that some of the game sofare runs way too fast to be useful and that some of it seems to cause the contrast to be turned down, making the sofare nearly impossible to use. Yes, I know from previous mention on this newsgroup that the contrast on the HP49G+ is screwy, but this is sofare that shouldn't be touching the contrast at l. so, I'm wondering if it would be possible to slow down the cculator and make it more suitable for games that rely on processor speed for timing. Specificly, I wonder if there's a timer interrupt where a routine could be instled to just take up time. But I know nothing of the cc's hardware architecture. Anyone? === Subject: Re: Compatibility beeen HP49G and HP49G+ > I've just gotten an HP49G+ (first HP cc ever, and I rely like it so > far!) and have been trying some sofare (mostly games at this point) > from hpcc.org. I've noticed that the sofare there is very hit-and- > miss on the G+ cculator. I guess I'm just wondering if other people > have had the same experience, or if I'm doing something wrong. > Specificly, I've noticed that some of the game sofare runs way too > fast to be useful and that some of it seems to cause the contrast to be > turned down, making the sofare nearly impossible to use. The way of turning the screen off and on has changed in assembly language. Furthermore, handling the contrast has changed too. And the 49g+ is far faster thant the 49G, so games will have to be re-written for the 49g+ (slowing loops, etc.). > is screwy, but this is sofare that shouldn't be touching the contrast > at l. It depends. Some games using greysce levels displaying have to write > so, I'm wondering if it would be possible to slow down the cculator > and make it more suitable for games that rely on processor speed for > timing. Of course. See Navigator for 49g+ for instance (which isn't a game, though, but a Web navigator for HP cculators) at : http://www.hp-sources.com/navigator/english.asp, you'll see that it is just the right speed. > Specificly, I wonder if there's a timer interrupt where a > routine could be instled to just take up time. I don't rely think so. Even the timer has changed on the 49g+. (and it isn't quite regular, it has some annoying behaviour that makes it aelerate or slow down...) Yoann. === Subject: Re: Compatibility beeen HP49G and HP49G+ >is screwy, but this is sofare that shouldn't be touching the contrast >at l. > It depends. Some games using greysce levels displaying have to write Ah, that explains it. Come to think of it, it is mostly graysce games (which, incidently, l flicker horribly on the 49G+ as well -- I assume that's to do with a change in the screen refresh rate) that show this problem. Just as an amusing anecdote, the first program I tried on my new cculator was ZeldaHP, which seems to turn the contrast down just a tad each time you leave the items screen. I assumed it was batteries, and I threw away about $10 worth of dead batteries before reizing that I just needed to adjust the contrast. Unfortunately, adjusting the contrast seems to require extern sofare, and that sofare suffers from its own 49G+ migration issues... ack! >so, I'm wondering if it would be possible to slow down the cculator >and make it more suitable for games that rely on processor speed for >timing. > Of course. See Navigator for 49g+ for instance (which isn't a game, > though, but a Web navigator for HP cculators) at : > http://www.hp-sources.com/navigator/english.asp, you'll see that it is > just the right speed. Ah, but (unless I'm interpreting you wrong) that's not exactly what I meant. I was wondering about a way to slow down the cculator so that EXISTING HP49G games could run on the HP49G+. That means I want some extern program to slow down the cc -- hence the suggestion: >Specificly, I wonder if there's a timer interrupt where a >routine could be instled to just take up time. > I don't rely think so. > Even the timer has changed on the 49g+. (and it isn't quite regular, > it has some annoying behaviour that makes it aelerate or slow > down...) I'll have to assume that's not possible then, I suppose, and wait for more 49G+ stuff to come around. What a bummer. I should have bought a GameBoy instead! :) === Subject: Re: Compatibility beeen HP49G and HP49G+ > extern program to slow down the cc -- hence the suggestion: The system should have an option to Decrease the clock speed [ON] [Down-Arrow] 75MHz to 48MHz (to be 48GXII compatible) 48 -> 30 (to be 49G compatible) then back to 75 with the 3rd stroke of [ON]&[DA] I don't care a warmstart is needed or even a reset as long as one can get the speed down PS: How about getting the speed up? === Subject: hp49g+ won't solve limits Hello to l! I just tried to slove a limit problem with my hp49g+ and I got an error saying Non gebraic in expression. I have solved the same problem before and I got the answer with no problem, but now the cc refuses to solve the problem. I tried RPN mode and it works. Then I thought there might be problem with the gebraic mode so I tried solving a simpler problem. Still I get an error in gebraic mode, but RPN gives me the answer. I'm not that much familiar with RPN. But I need to solve the prolems in the gebraic mode. Can anybody tell me what is going on? I first tried this: lim(sqrt(2*x^2+3)-sqrt(2*x^2-5*x),x=infinity) - In gebraic mode: Error: Non gebraic in expression. - In RPN mode: After a long unusu delay - (5*sqrt(2))/4 - The right answer! Then I tried this: lim(2*x,x=1) - In gebraic mode: Error: Non gebraic in expression. - In RPN mode: 2 - The right answer! === Subject: Re: hp49g+ won't solve limits > Hello to l! > I just tried to slove a limit problem with my hp49g+ and I got an > error saying Non gebraic in expression. I have solved the same > problem before and I got the answer with no problem, but now the cc > refuses to solve the problem. I tried RPN mode and it works. Then I > thought there might be problem with the gebraic mode so I tried > solving a simpler problem. Still I get an error in gebraic mode, but > RPN gives me the answer. I'm not that much familiar with RPN. But I > need to solve the prolems in the gebraic mode. Can anybody tell me > what is going on? > I first tried this: > lim(sqrt(2*x^2+3)-sqrt(2*x^2-5*x),x=infinity) > - In gebraic mode: > Error: Non gebraic in expression. > - In RPN mode: > After a long unusu delay - (5*sqrt(2))/4 - The right answer! > Then I tried this: > lim(2*x,x=1) > - In gebraic mode: > Error: Non gebraic in expression. > - In RPN mode: > 2 - The right answer! I just tried both in G and I got the right answers What is going on here? Try to reset the CAS ConFiGuration with CASCFG === Subject: Re: hp49g+ won't solve limits ... > I first tried this: > lim(sqrt(2*x^2+3)-sqrt(2*x^2-5*x),x=infinity) > - In gebraic mode: > Error: Non gebraic in expression. > - In RPN mode: > After a long unusu delay - (5*sqrt(2))/4 - The right answer! I tried it using an hp 49g emulator (EMU48) with ROM Version 1.19-6 with the ccuator in Exact and Re modes and it gave me the right answer in G mode right away. When I tried it in Approx mode it asked me to switch Approx off, but then it refused to do it indicating that Mode Switch not lowed. Gilberto E. Urroz http://www.engineering.usu.edu/cee/faculty/gurro/ === Subject: RPN on TI's I was wondering if any experienced RPN users can comment on the quity of RPN emulation on the TI-89. I ask this because I like the benefits of RPN but because of the hardware problems that the HP's are currently having I want to buy something more reliable. === Subject: Re: RPN on TI's > I was wondering if any experienced RPN users can comment on the > quity of RPN emulation on the TI-89. I ask this because I like the > benefits of RPN but because of the hardware problems that the HP's are > currently having I want to buy something more reliable. B.R., I wouldn't presume to make decisions for you, but the keyboard issues with the HP49G+ seem easy enough to avoid. I bought one at the cheapest place I could find (namely, graphingcculators.net) and at least the one they shipped to me was a CN352 for which the keyboard has been great. I haven't experienced the older HP keyboards, but I certainly prefer this one to any keyboard I've ever seen on TI or Casio cculators in the past. In any case, isn't returning a cculator for a newer keyboard less hassle than learning to use a whole different variety? === Subject: Re: RPN on TI's I truely dislike l of the rpn implementations on the ti-89. They work for basic arithmetic and computations, but they are not much more than useless for anything else. > I was wondering if any experienced RPN users can comment on the > quity of RPN emulation on the TI-89. I ask this because I like the > benefits of RPN but because of the hardware problems that the HP's are > currently having I want to buy something more reliable. === Subject: Re: RPN on TI's > I truely dislike l of the rpn implementations on the ti-89. They > work for basic arithmetic and computations, but they are not much more > than useless for anything else. I thought RPN was intended for computation. -- === Subject: Re: RPN on TI's Haha, yes, RPN is for computations. I guess I didn't use the correct except numbers. They can't do symbolics, which is the whole reason someone would get a ti-89 over one of the lower models. I couldn't even integrate or differentiate with the emulators I tried. However, this was over a year ago, so things may have improved. >I truely dislike l of the rpn implementations on the ti-89. They >work for basic arithmetic and computations, but they are not much more >than useless for anything else. > I thought RPN was intended for computation. === Subject: Re: RPN on TI's > Haha, yes, RPN is for computations. I guess I didn't use the correct > except numbers. They can't do symbolics, which is the whole reason > someone would get a ti-89 over one of the lower models. I couldn't > even integrate or differentiate with the emulators I tried. However, > this was over a year ago, so things may have improved. You can do that with Lars Frederiksen's RPN interface. As far as I remember, you've ways been able to do symbolic manipulation in that interface. I'm not familiar with any other RPN emulators. -- === Subject: Re: RPN on TI's > I thought RPN was intended for computation. Yes, but the whole point is the consistency in the interface--ways postfix---not merely doing arithmetic. This means that the programming commands are so postfix etc, and the stack works in a straightforward logic way. The most annoying thing about most gebraic cculators is the inconsistency of the logic: infix for +-/*, but postfix for transcendents, and then god only knows for y^x, statistics % etc. Of course some gebraics are now designed to be truly gebraic (typicly this is still not quite correct) by making transcendents infix as well, so sin(x). The problem here is just the extra steps and closing parenthesis. Ultimately I think the gebraic approach is just as workable once you are austomed. But it is not as clear from a logic standpoint. And it is more keystrokes (which might be so what in the grand scheme). With multi-line screens, the true gebraic approach begins to become reasonable---but for single line direct computation, nothing beats RPN in my opinion. Now, as an interesting side note: Every computation has different needs, and no one logic system is perfect for every computation. Further, different logic systems may appear identic in operation in some circumstances. Take for instance the mundane task of adding up sums, where oasionly in the sum one must take a product or division of some number before adding to a sum (say doing a budget for instance by year where some item vues are known by month), the most efficient system here is the adding machine logic, which is postfix for addition and subtraction, but infix for mult and division. A sum is started with an implicit zero, and hitting + gives the tot (often the + key so says =). If you have to do a product, then it goes like this: [0] A + B + C x D + will give (A+B)+C*D. Notice that with an gebraic cculator with precedence, the keystrokes will be identic even though everything is infix! A+B+CxD+ gives (A+B)+C*D+ the only difference is the still pending addition with the gebraic. Now, if you do this in RPN, the additions will be identic to the adding machine, but you will have one more keystroke when you get to the product: A + B + C D x + . Now, for the worst of l, take a non-precedence gebraic (some have parentheses, e.g. HP 17bii, and others are your standard P.O.S. Wmart speci) A + B + ( C x D) = note that in the HP 17bii, you end up needing parentheses around products rather than around sums!!! (This is a stupid design, which is why I leave the 17Bii set to RPN....) In a cheapy, it is: A + B = M+ C x D = M+ RclM and if no memory, then you are pretty much SOL here (like, what's the point of this sort of cculator if you can't even do anything re with it!!). The mor of the story is that in computation, logic is ways a compromise. === Subject: Re: RPN on TI's > > as well, so sin(x). The problem here is just the extra steps and closing > parenthesis. Is there any kind of a patch to the TI system to autoclose any missing parenthesis? Bhuv? - The TI system is broken === Subject: Re: RPN on TI's > Is there any kind of a patch to the TI system > to autoclose any missing parenthesis? For gebraic entry, right? Yes, Kevin Kofler's AutoClBr (auto-close brackets). > - The TI system is broken Broken? Wow, I've been using the 68k for around 7 years and never noticed it -- === Subject: Complex Systems of Equations with 49G+? I am an Electric Engineering student and many of the circuits that I have to solve have complex numbers in them. Right now to solve a complex o equations, o unknowns problem I am entering them into a matrix and doing an RREF on the matrix. My answers seem to come out negative of what they should be (180 Degrees off). Has anyone seen this before? Is there some other way that I should be solving these equations? === Subject: Re: Complex Systems of Equations with 49G+? I tried solving the set of equations: 2*x+3*y = -9+10*i 5*x+2*y = 5+14*i with i the imaginary unit. The solutions are x=3+2*i y=-5+2*i which I checked with Maple 8. The hp 49g emulator (EMU48) with ROM version 1.19-6 gave me the right answer. Here is the augmented matrix I used: [[ 2 3 (-9.,10.) ] [ 5 2 (5.,14.) ]] After using function RREF with the cculator in Approx and Complex mode, the matrix reduces to [[ 1. 2.E-15 (3.,2.) ] [ 0. 1. (-5.,2.) ]] which is the right answer. I think that the reason why you are getting the negatives of the actu solutions has to do on how the augmented matrix is interpreted. A linear system of the form a*x+b*y = c d*x+e*y = f can be written in matrix form as _ _ _ _ _ _ | a b || x | | c | | || | = | | | d e || y | | f | - - - - - - Thus, the corresponding augmented matrix is: _ _ | a b c | | | | d e f | - - If you write the origin system of equations as a*x+b*y-c = 0 d*x+e*y-f = 0 You may have used the augmented matrix as _ _ | a b -c | | | | d e -f | - - which will give you the negative of the actu solution. For the specific example mentioned earlier, the wrong augmented matrix would be [[ 2 3 (9.,1-0.) ] [ 5 2 (-5.,-14.) ]] After using function RREF with the cculator in Approx and Complex mode, this augmented matrix reduces to [[ 1. 2.E-15 (-3.,-2.) ] [ 0. 1. (5.,-2.) ]] which gives as answers the negative of the actu solution to the origin linear system. Gilberto E. Urroz http://www.engineering.usu.edu/cee/faculty/gurro/ === Subject: Re: Complex Systems of Equations with 49G+? You are correct I was setting up the equations as: a*x+b*y-c = 0 d*x+e*y-f = 0 And I was using the augmented matrix _ _ | a b -c | | | | d e -f | - - It looks like I was doing it incorrectly. What you said totly makes frustration! --Dan === Subject: Re: SD card no longer appears on Files > Has anyone had such a problem ? can it be solved or should I send my > hp to repair or replace ? The SD card support in the boot loader is not as good as the one used by the OS. Re-format your card in FAT16 and reload the firmware on it and try again. Do NOT rename the file on the SD card itself, I've seen cases were it makes the card not being recognized. Those issues only happen when using the boot loader. === Subject: Re: SD card no longer appears on Files > >Has anyone had such a problem ? can it be solved or should I send my >hp to repair or replace ? > The SD card support in the boot loader is not as good as the one used by > the OS. > Re-format your card in FAT16 and reload the firmware on it and try > again. Do NOT rename the file on the SD card itself, I've seen cases > were it makes the card not being recognized. > Those issues only happen when using the boot loader. > Sorry for my ignorance but, what firmware are you tking about ? what should I not rename on my card ? I tried sever other cards and none was read. The autotest says there's a fail even when there is no card in the slot though the system slows at startup if a card is inserted... as if trying to read it. I won't be able to try and format the card til I get home tonight, I'll comment later on... === Subject: Re: Internation comparison of AAA cell prices Germany, no-name AAA: 4 cells for 1,99 EUR (as of today, $2.45) --- Rf Fritzsch Bundesanstt fuer Wasserbau Feder Waterways Engineering and Research Dienststelle Kueste Institute - Department Hamburg --- Unix _IS_ user friendly - it's just selective about who its friends are. --- === Subject: Re: Internation comparison of AAA cell prices sorry, in an earlier message i made a mistake here its the correct price: the 4 rayovac batteries costs $ 10 = u$s 3.48 = euro 2.78 and 4 duracell batts costs $ 16 = u$s 5.57 = euro 4.44 === Subject: Re: Internation comparison of AAA cell prices in Argentina, latinanerica (if you dont know where it is :) 4 DURACELL AAA batteries cost $10 = U$S 3.48 = EURO 2.78 but i personly use 4 RAYVAC AAA batteries cost $10 = U$S 3.48 = EURO 2.78 both brands come in pack of 2 units, so if hp use 3 batts, you have to buy 4, use 3, store 1 for the next replacement, buy 2, think where is natt you have stored, and so on ... when HP will make a 2 or 4 batts cculator? === Subject: Re: HP49G LGPL CAS release > therefore the whole ROM goes GPL > That never happened? > Did HP buy yu out from free source Sort of... lows me to finance my next project: the ultimate graphic cculator as we l dreamed of.. === Subject: Re: HP49G LGPL CAS release >therefore the whole ROM goes GPL >That never happened? >Did HP buy yu out from free source > Sort of... > lows me to finance my next project: the ultimate graphic cculator > as we l dreamed of.. The gadget-geek part of my brains loves you, ! lows me to finance my next project: the ultimate graphic cculator > as we l dreamed of.. > Can you give us an idea of what we l dreamed of??? Everyone has different dreams :) Beto Reply: Erase beeen the dot (inclusive) and the @. Responder: Borra la frase obvia y el punto previo. === Subject: Re: HP49G LGPL CAS release > Can you give us an idea of what we l dreamed of??? Everyone has > different dreams :) We will release the full feature set soon as well as expected time to market. It's gonna be rely cool. === Subject: Re: HP49G LGPL CAS release >Can you give us an idea of what we l dreamed of??? Everyone has >different dreams :) > We will release the full feature set soon as well as expected time to > market. It's gonna be rely cool. everything. === Subject: One sided limit on hp49g+ Does anyone know if the hp49g+ is capable of evuating one sided limits. An example would be greatly appreciated. Richard === Subject: Re: One sided limit on hp49g+ > Does anyone know if the hp49g+ is capable of evuating one sided > limits. An example would be greatly appreciated. Yes it can, instead of putting X=a as a both-sided limit, use X=a+0 for X=a+, or X=a-0 for X=a-. Beto Reply: Erase beeen the dot (inclusive) and the @. Responder: Borra la frase obvia y el punto previo. === Subject: Re: ASCII files on SD card? > I recently acquired an HP 49g+, and, being a Mac user, found the > included copy of Conn4x and the USB cable to be of no use--even under > Virtu PC it is impossible to establish a connection. Try the latest USB driver, Conn4x, and ROM, available at: http://h20000.www2.hp.com/bizsupport/TechSupport/DriverDownload.jsp?taskID=1 35&pnameOID=351776&prodTypeId=215348&loce=en_US&lang=English&prodSeriesId=3 3568 And yes, it would be nice if HP would provide support for non-Microsoft operating systems, but perhaps you can get these latest files working on your Mac. I don't use a Mac, but perhaps some helpful Mac users will jump in with some tips? > So, I > purchased an SD card and reader to use in transferring files beeen > the cculator and computer. However, I have found that when I > transfer a User RPL program to the card, it is transferred in some > sort of binary format. Yes, it's stored on the card as a binary transferred file, most exactly as if you used a Kermit binary transfer or Xmodem (outside of Conn4x) transfer. That is, it starts with the binary transfer header HPHP49-X, followed by the compiled object. It would so be very nice if the 49g+ gave us an option to store an object on the SD card as an ASCII transferred file, including translations for non-ASCII characteand preferably with independent options to translate ASCII control code and choices to leave LFs one, translate them to CRLF paior translate them to CRs. > Is there any way to get the cculator to put > an ASCII text file on the card, which could be edited on the computer > and then transferred back to the cculator, again via the SD card? > Obviously, the high ASCII characters would need to be translated (such > as << and >>). Yes, I do it (though my 49g+ is in for warranty replacement at the moment). First, be in the habit of ways using the same fraction mark (. or ,), and, if angular components may be involved (complex numbers or vectors in cylindric or spheric display mode), so the same angular display units (Degrees, Radians, or Gradians), and the same translation mode. For editing or displaying on the PC, I ways use mode 3, that is, translate LF (not immediately preceded by CR), , and characters 128 through 255. Execute 3 TRANSIO to set the translation mode to 3. Recl the object to the stack, and (if it's not ready a string) change it to its decompiled string form with the following program: %%HP: T(3)A(R)F(.); @ Argument: Level 1: Any object. @ Returns: Level 1: Object decompiled to command line editor character @ string form. @ Notes: 1: For a character string argument, the result is the string @ embedded within another string. @ 2: Re numbers are as in STD display format. @ 3: Binary integers use wordsize 64. @ Checksum: # 7771h @ Size: 30.5 @ For 49G and 49g+ @ NOT for 48S/SX/G/GX/G+! << DUP DROP @ Verify that an argument exists. # 25ECEh SYSEV @ EDITDECOMP$ for 49G and 49g+. As an ternative to the above, you could do STD 64 SS ->STR. Now translate as in a Kermit ASCII transfer: %%HP: T(3)A(R)F(.); @ Argument: Level 1: A character string. @ Returns: Level 1: A character string translated as in Kermit ASCII @ SEND transfers. @ Notes: 1: Respects translation mode in IOPAR. @ 2: If IOPAR doesn't exist in the HOME directory, then creates @ it with default vues. @ 3: If IOPAR exists but is invid, then errors out. @ 4: For translation modes other than 0, translates a bare @ NewLine (LineFeed or LF) to a CarriageReturn LineFeed pair, @ but a CRLF pair is left as is. @ Checksum: # 2AC1h @ Size: 28. @ For 49G and 49g+ @ NOT for 48S/SX/G/GX/G+! << ->STR @ Verify that an argument exists and @ force it to be a string. # 2F34Fh SYSEV @ KVISLF for 49G and 49g+. Or, if you wish to leave Line Feeds untranslated, use the following instead: %%HP: T(3)A(R)F(.); @ Argument: Level 1: A character string. @ Returns: Level 1: A character string translated as in Kermit ASCII @ SEND transfeexcept that NewLines (LineFeeds) are @ left as is. @ Notes: 1: Respects translation mode in IOPAR. @ 2: If IOPAR doesn't exist in the HOME directory, then creates @ it with default vues. @ 3: If IOPAR exists but is invid, then errors out. @ Checksum: # 8B49h @ Size: 28. @ For 49G and 49g+ only @ NOT for 48S/SX/G/GX/G+! << ->STR @ Verify that an argument exists and @ force it to be a string. # 2F34Eh SYSEV @ KVIS for 49G and 49g+. If the object is a string (or a composite that contains strings) that has ASCII control codes (such as when you use styles or font changes), you may want to translate the control codes to nnn translation codes. Use the following to do this: %%HP: T(3)A(R)F(.); @ Checksum: # 9807h @ Size: 131.5 << ->STR @ Verify that an argument exists and @ force it to be a string. 0 9 FOR n n CHR C$ 3 00 n + SREPL DROP @ Translate control codes 0-9. NEXT 11 31 FOR n n CHR C$ 2 0 n + SREPL DROP @ Translate control codes 11-31. NEXT 127 C$ 4 127 SREPL DROP @ Translate control code 127. Now store the string in a named variable on the SD card, move the SD card to the reader attached to you Mac, and edit it the text editor of your choice. The file starts with the binary transfer header HPHP49-X, followed by a 5-nibble character string object prologue, followed by a 5-nibble character string size field. Edit out these first 13 characters; an incorrect size field would, I expect, cause problems when you move it back to the cculator. Note that just saving the file from your text editor, even without making any explicit change to it, may make changes; end of line or end of file changes for example. When you're done editing, store the edited file on the SD card and move the card back to the 49g+. Recl the object to the stack (it should be the string as it appeared in you text editor). Be sure that your fraction mark, angular unit display, and translation mode are still the same. Now run the following program to translate the backslash codes back to characters: %%HP: T(3)A(R)F(.); @ Argument: Level 1: A character string. @ Returns: Level 1: A character string translated as in Kermit ASCII @ RECV transfers. @ Notes: 1: Respects translation mode in IOPAR. @ 2: If IOPAR doesn't exist in the HOME directory, then creates @ it with default vues. @ 3: If IOPAR exists but is invid, then errors out. @ Checksum: # CED2h @ Size: 30.5 @ For 49G and 49g+ @ NOT for 48S/SX/G/GX/G+! << ->STR @ Verify that an argument exists and @ force it to be a string. # 2F34Dh SYSEV @ KINVIS for 49G and 49g+. + @ Append any parti code. Now, if it's not supposed to be a string, compile it to a string by doing STR-> (or OBJ->). Finly, store it in the variable of your choice. The above programs can be cut and pasted to text editor files and downloaded to your cculator, but if you don't have Conn4x working, use the SD card to do it as follows. First, use your text editor to remove the ASCII file transfer headers (%%HP: T(3)A(R)F(.);) and you may as well so remove any leading comment lines. Start with the one that translates the backslash codes to charactethat is, the one with the KINVIS sequence in it (or key that one in manuly). Move the files to the SD card and the SD card to the cculator. Set the cculator to use translation mode 3 and the . as the fraction mark, if necessary. Recl the string to the stack, and run the program to translate backslash codes to characters (you'll have to do it manuly for that first one, if you didn't key it in), and then compile it with STR-> or OBJ->, and store it in the variable of your choice. > If it isn't possible to do it on the cculator, is there at least > some program that could be run on the computer to translate the file? It may be possible to use the file as stored on the SD card in one of the emulators (generly available at http://www.hpcc.org/); see whatever documentation comes with the emulator. > Given the HP 49g+'s keyboard (mine tends to drop some keypresses and > double others), I'd hate to have to key in a longer program entirely > on the cculator. It'd be nice to be able to edit them on the > computer, and so then post them online. Yes, and even without the keyboard problems, for other than than relatively simple ad hoc programs, I generly prefer to write and save commented source code with a text editor on the PC; QWERTY keyboard, bigger screen, and so on. hj === Subject: Re: ASCII files on SD card? such a kind and responsive group of users as those on comp.sys.hp48. -Kurt Raschke === Subject: Re: GROB LABELS > {{GROB 22 8 FFFFF3100002100002100002100002100002100002FFFFF3 > {NORM LEFTSHIFT RIGHTSHIFT}}} > BUT it does not seem to work anymore? The grob should be a 21x8 one, not 22x8 === Subject: Re: GROB LABELS >{{GROB 22 8 FFFFF3100002100002100002100002100002100002FFFFF3 >{NORM LEFTSHIFT RIGHTSHIFT}}} >BUT it does not seem to work anymore? > The grob should be a 21x8 one, not 22x8 Hmmm.... {{GROB 21 8 FFFFF0100080100080100080100080100080100080FFFFF0 {NORM LEFTSHIFT RIGHTSHIFT}}} === Subject: HP49G+ Return for replacement in Europe: any tips or experiences? Does anyone have experience with returning the old HP49G+ in Europe, to get a replacement with the working keyboard? I am not having a great experience with the agents in Europe (I live in the Netherlands). They say there is no problem that they know of, they will check the cculator and replace if they consider there is something wrong with it. Since they don't know of or acknowledge the keyboard problem, I am not feeling very confident. Questions about whether they will replace it with the redesigned cculator, or what seri number range they have in their replacement stock, are ignored. I first cled the US, but they will not support customers outside Nafta. Any experiences or tips would be appreciated. === Subject: Re: How to locate scratchpad memory? Sorry that I'm again replying to myself, but there's a bug in this: It would ign the ARM code to a word boundary and then execute the unigned code. The same warnings as before apply, you *need* a chunk of ARM code that at least sets D0 to a sensible vue. However, this one has been tested on an actu 49G+, so it should work. Changes are indicated by %% comments: :: CK1NoBlame DUPTYPEZINT? NcaseTYPEERR ERRSET CODE GOTO start ENDCODE ERRTRAP :: GARBAGE CODE *start GOSBVL SAVPTR A=0.W A=DAT1.A R1=A.W A=0.W A=R0.A R0=A.W AD0EX A+C.A B=A.A LC(5) (end)-(begin) RSTK=C B-C.A LC FFFF8 C&B.A B=C.A D1=C %% added B=C.A here C=A-C.A D-C.A SKNC { *memerr GOVLNG GPMEMERR } GOSUB end *begin % ARM code goes here *end C=RSTK D0=C %% removed B=C.A here C=RSTK GOSBVL MOVEDOWN C=B.A INTOFF $80BFF INTON % If the following line fails (jump too long) try to substitute the % next one GOC memerr % SKNC { GOVLNG GPMEMERR } GOSBVL Shrink$ % Uncomment the following line if you want a ZINT as a result % C=R0.W D0=C LC(5) DOINT DAT0=C.A GOVLNG GPPushR0Lp ENDCODE ; SWAPDROP ; If you want to reply by mail, substitute my first and last name for 'foo' and 'bar', respectively. === Subject: 49g+ printing to IrDA printer or 49g+ or via IrDA/RS-232 adapter to termin? Hmm, I must've overlooked these when they were posted. >> By setting flag -33 (Transfer via IR) and flag -34 (Print Via Wire), I >> was able to send the output of l the print commands to a DeskJet >> 990Cxi. There were some font mismatches, but the gener expected >> format is there. I was unsuessful with flag -34 cleared, so, it seems >> that, though both send via IR, flag -34 cleared sends at a much slower >> baud rate (as noticed by the hourglass indicator being on much longer). >> I assume less than 9600, which is the minimum IrDA baud rate. > Hmmm... > Maybe that flag now controls beeen SiR/IrDA ??? > Anyone there able to test with old HP Cc-Printer and a new IR printer? > ideas running out.... On the 48 series, having both of those flags set causes the cculator to print in SIR (Seri IR) mode. That is, fored as when printing via wire, but in the SIR mode, which can be captured to HyperTermin by a relatively simple SIR to RS-232 converter, or received on another 48 with flag -33 (Transfer via IR) set, using the SRECV command. I take it that on the 49g+, it causes it to print fored as in the via wire mode but via IrDA. If so, it should so be possible to use an IrDA to RS-232 converter to capture it to HyperTermin, or to another 49g+ set up for IrDA transfers. Can anyone out there confirm Toby's discovery and/or my speculations? What sort of range is possible using IrDA on the 49g+? That is, how close does it have to be to the other device? === Subject: Re: 49g+ printing to IrDA printer or 49g+ or via IrDA/RS-232 adapter to termin? Very close; 2-3 inches max. Another issue: there must be an active connection with the printer for a complete transmision in IrDA. Otherwise you'll loose some data at the beginning of the printout. I execute OPENIO, and then wait for the printer to detect he cculator (a printer LED turns on). Then I do the printing. This is probably a printer issue, though. I started a project to build some input forms to ease printing, but it is l hted (lack of time). I'll resume soon. > Hmm, I must've overlooked these when they were posted. > ... > What sort of range is possible using IrDA on the 49g+? That is, how > close does it have to be to the other device? > -- === Subject: Re: IRDA link beeen HP 48G and HP 49G+ ? >> 48G is 4800 IIRC, the 49g+ can be set to this speed.... > No. > The 48G is 2400bps. > It's possible with some ML tools to speed this speed up to 7500bps. But > by default it's 2400. > The 48G doesn't use IrDA it's a different protocol. One of the reason it > doesn't work with the 49G+ (which is using re IrDA). > Linking the 48G to the 49G+ through Ir could be done but it's extremely > unreliable as there are major hardware differences. But the 49g+ does manage to send to the 82240A/B printer in Red-Eye IR mode (though with reduced range), so I'm a bit surprised that it can't handle I/O in Seri IR format, which would seem a bit simpler to me. Perhaps a combination of a weak IrDA sign and the crippled IR receiver on the 48 series? Any idea why the 49g+'s range to the printer is so short? Is that intention? How close does the 49g+ have to be to the other IrDA device? Did they cripple the IrDA intentionly so that students can't use it to cheat? === Subject: Re: IRDA link beeen HP 48G and HP 49G+ ? > > > >> 48G is 4800 IIRC, the 49g+ can be set to this speed.... OK the Fast IR programs did the faster speed but 2400 could be used by this program: http://www.hpcc.org/details.php?id=2296 which I was thinkg about...maybe it works! The other way around you need to port this program to the 49g+ and do the opposite Maybe someone could code a mutu protocol === Subject: Re: IRDA link beeen HP 48G and HP 49G+ ? > But the 48G does have a seri port, right? Use the 49g+ to IrDA end > of the cable and plug the seri end into the 48G( Using the cable > that works with the G or GX). > The cable as advertized is an IrDA to seri cable. It has a plug for > an AC adapter or battery for power. > It does work, at least when tking to a Vernier Univers Lab > Interface( RS-232 input) or a Vernier LabPro interface.( RS-232 or USB > input). By working I mean there is a response for the interface boxes. > Writing sofare for the cculator is a project for this summer. Wow, nice! === Subject: Re: Relevance of RPN (please, no holy war...) > Anyone else remember the HP-71B? Wonderful gebraic mode as a > cculator (not EQW). I have asked beore HP to put this back into the cc. The CPU is the same so porting from the 71B should be easy. If they still have the source code IDS was released so getting the source is no problem Right Shift Hold ENTRY should start it == Subject: Curve fitting I find it inconvinience to manuplate the raw data for curve fitting. When I did my experiment, I collected raw data. Is there a possible way to put the raw data into the matrix writer ( like a spread sheet excel), then I manupulate those data example like In(X) or In(XY) then I will assign this In(X) as y axis, and In(XY) as x axis. After that I will like to use the curve fitting to find the solution. At least I know there is a long way by cculate l the raw data beforehand and then input into the matrix writer to solve curve === Subject: Re: new 49G+ direct from HP has SN CN333... >I only hope the new cculator's >keyboard is likewise reasonable... > I got a CN352... seri number as a replacement and it's just fine and > dandy - no missed keystrokes and solider. > Unbelievable: my replacement just arrived, and its seri number is CN334... I'm returning it without even turning it on first. Man, am I annoyed at HP. hpcc.org, here I come. === Subject: Transposing / Simplify Thought Hi l, Now that I've got the hang of some basic formula transpositions on the 49g+ I'm left wondering as to why the 49g+ wouldn't be designed to automaticly do a SIMPLIFY after a ISOL? so, can someone please clarify the difference beeen SOLVE and ISOLATE for me? I'm guessing that SOLVE tries to produce a numeric anser to fit the variable requested, whereas ISOLATE just transposes the equasion without trying to find a numeric answer? === Subject: Re: Transposing / Simplify Thought > Hi l, > Now that I've got the hang of some basic formula transpositions on the 49g+ > I'm left wondering as to why the 49g+ wouldn't be designed to automaticly > do a SIMPLIFY after a ISOL? << ISOL SIMPLIFY >> 'ISOLSIMP' STO Use it! === Subject: Re: Transposing / Simplify Thought >Hi l, >Now that I've got the hang of some basic formula transpositions on the > 49g+ >I'm left wondering as to why the 49g+ wouldn't be designed to > automaticly >do a SIMPLIFY after a ISOL? > << ISOL SIMPLIFY >> 'ISOLSIMP' STO > Use it! so you might consider something more sophisticated: http://www.hpcc.org/details.php?id=4750 Made possible by Man of ! === Subject: Re: Transposing a formula with the 49g+ Keep top-posting... > Ah, good point! (Me bad)! > [Still top posted, but with 5 miles of previous text deleted] >There is no 'L' in your equation. There is a 'LC'. If you meant L*C you >have to write that. === Subject: Keyboard experiences on HP49G+ SN : CN352 and above...? Hi Folks, Great newsgroup - usefull information for once :) I have just purchased my new 49G+ end february '04, seri# CN3520.., and have experienced some missing keystrokes ! Now, after reading some of our comments, it seems that there has been an improvement from earliere serinumbers - or what? What are your experienses - are the CN352 good enough? Are there a higher seri# available? Read some comments blaiming the sofare, and maybe there is something to it, I mean pushing the key very gently and result in a suessive keystroke everytime; but tapping the numbers and command in a hasty tempo in the classroom, often results in missen keystrokes? And correct about the audible feedback from the keyboard - it is very loud! === Subject: Re: Keyboard experiences on HP49G+ SN : CN352 and above...? I hate to say this because I RELY WANT to like everything about my 49g+, but ... My replacement is a 403xxxxx series and I think I'm actuly missing more keystrokes than my pre-352xxxxx model. Honestly, it's beginning to bug me more and more. In my opinion, whatever they did after 352xxxxxx hasn't made any improvements that I can see. I rely can't figure out why it's so hard for them to get this right. > Hi Folks, > Great newsgroup - usefull information for once :) > I have just purchased my new 49G+ end february '04, seri# CN3520.., and > have experienced some missing keystrokes ! > Now, after reading some of our comments, it seems that there has been an > improvement from earliere serinumbers - or what? > What are your experienses - are the CN352 good enough? Are there a higher > seri# available? > Read some comments blaiming the sofare, and maybe there is something to > it, I mean pushing the key very gently and result in a suessive > keystroke everytime; but tapping the numbers and command in a hasty tempo in > the classroom, often results in missen keystrokes? > And correct about the audible feedback from the keyboard - it is very loud! > === Subject: Re: My 49G+ will not Factor (2^67-1) >Not to correct you, but mine HP49g+ ccs it no problem - >147573952589676412927 (?) Sorry ! Wrong answer!!! That is merely 2^67 -1 , NOT it's factors!! === Subject: Re: My 49G+ will not Factor (2^67-1) > Not to correct you, but mine HP49g+ ccs it no problem - > 147573952589676412927 (?) But that's not the correct answer! The answer is: 193707721 * 761838257287 The 49g+ gave you an incorrect answer and gave no indication that it was incorrect. This could be a dangerous thing! === Subject: Re: My 49G+ will not Factor (2^67-1) >Not to correct you, but mine HP49g+ ccs it no problem - >147573952589676412927 (?) > But that's not the correct answer! The answer is: > 193707721 * 761838257287 > The 49g+ gave you an incorrect answer and gave no indication that it was > incorrect. This could be a dangerous thing! HP should change the gorithm limits now that the CPU is much faster A computer simulation should tell the best candidates for testing on the 49g+ === Subject: Re: My 49G+ will not Factor (2^67-1) > The re HP49G+ runs out of time while trying to factor 2^67-1 - the > yuserfast emulator does not. > As expected, this is one of the areas the V200/TI-89 are better at (finished in about 3 minutes). -- === Subject: Re: My 49G+ will not Factor (2^67-1) LnP3c.97677$Wa.68652@news-server.bigpond.net.au, Reth > Not to correct you, but mine HP49g+ ccs it no problem - > 147573952589676412927 (?) > ROM 1.23 > SER CN33208692 (int) > ON+D: > VERSION 03.54 > BUILD NUMBER 0031 > SN CN33108992 (box) That is the number not the factors...the number you mentioned being 147573952589676412927