A149 Subject: Re: USB chip in the HP49G+? > Does anyone know what USB chip is being used in the 49G+? Is it a re > UART The USB port is built into the Samsung processor. It is not a UART. > or does the windows driver just emulate one? Perhaps it emulates one. Does it show up as a COM port? === Subject: Re: USB chip in the HP49G+? >>Does anyone know what USB chip is being used in the 49G+? Is it a re >>UART > The USB port is built into the Samsung processor. It is not a UART. The samsung processor has the USB stuff built in.. it *is* an UART. -- For email: replace domain with okstate, with the usu education TLD suffix. === Subject: Re: USB chip in the HP49G+? UART = Univers Asynchronous Receiver Transmitter (Asynchronous means a start bit and a stop bit, with no embedded clocking information). USB = Univers Seri Bus (a synchronous protocol with embedded clocking information) The Samsung device used in the 49G+ contains three UARTs (one of which you use when doing IRDA) and a one port USB Device controller (which you use when communicating over USB). Interestingly, this Samsung device so contains a 2-port USB Host controller, which would low the 49G+ to be a USB master if HP had provided access to the signs and the sofare to drive it..... Monte >>Does anyone know what USB chip is being used in the 49G+? Is it a re >>UART > The USB port is built into the Samsung processor. It is not a UART. > The samsung processor has the USB stuff built in.. it *is* an UART. > Matthew F G > -- > For email: replace domain with okstate, with the usu education TLD suffix. === Subject: Re: USB chip in the HP49G+? > Does anyone know what USB chip is being used in the 49G+? Is it a re > UART > The USB port is built into the Samsung processor. It is not a UART. > or does the windows driver just emulate one? > Perhaps it emulates one. Does it show up as a COM port? Apparently it shows up in Linux as a /dev/tty using a gen USB driver. In Windows it *behaves* like a UART, you have to set the port speed and so on, but I'm not sure that has any effect. === Subject: Unitman (was Who is helen) > have noticed that the 'who is helen' thread degenerated off topic without > anyone providing the true answer. As Dr Rautenberg, author of UnitMan will > no doubt confirm, the Helen is the SI unit of beauty... Confirmed... And Unitman has been updated. Rechlin noticed that the version number in Unitman.htm differs from the intern version number. I took the occasion to improve the EditU (edit a unit) command. It nicely returns to the start menu, even after browsing infinitely often in the unit menus. One of many applications of EditU is the redefinition of the (US)$ as a time unit so that money and time units are mutuly convertible http://page.mi.fu-berlin.de/~raut/WR49/index.htm#Science === Subject: HP 49g+ Speed I just received my new g+ seri number CN40**** The keyboard is quite safisfactory. I do find some keypress misses with the arrow keys but if I just press a little harder there is no problem. It is just a matter of getting used to it. But the re reason for this post is the speed of the cculator. I have run some comparison speed tests with my old 49g and found the following using the TEV function running << 1 10000 FOR X NEXT >> speed improvement 2.1x Running << 1 10000 FOR X X SIN NEXT >> speed improvement 1.6x This is quite a departure from the 3x speed improvement I have read about elswhere on this group. Can someone else confirm these vues. Maybe the clock on my cc is running slow. By the way on the old 49g pressing ON-F4 and 2 gives the CPU speed, is there an equivent test on the 49g+? === Subject: LINEV on the HP49G+ ?? While looking on the LINEV vue (number of vertic lines of the lcd) i found it was 81 on the HP49G+ shouldn't it be 79 (80-1) or 80 ? === Subject: Re: LINEV on the HP49G+ ?? Oops.....Just replying to my own stupid question. In fact i forgot to shift right : it was 0x150 / 4 =84 ??? why 84 and not 79 ? when i put 79 it scrolls the screen indifinelty........ > While looking on the LINEV vue (number of vertic lines of the lcd) > i found it was 81 on the HP49G+ shouldn't it be 79 (80-1) or 80 ? === Subject: Re: [HP 49G] Program that didn't work > I have an important program I downloaded in hpcc. I uploaded this > program to my cc and the cculatrice didn't see it like a program > but like text ! I 't understand why! Please if someone can help me > it will be very greatful for me. Excuse me for my bad english. > The link to the program: > http://www.hpcc.org/hp49/apps/misc/ipcc.zip It seems that it's written with the assumption that you're using the HP Program Development Link (PDL) on your PC. It's been a long time since I've used the PDL, and never with a 49 series. If you care to try it out, search hpcc.org for PDL or Program Development Link. Looking at the file ipcc.app, I expect that you could modify a copy of it in a text editor to work with an ordinary Kermit transfer. First, it looks like any line starting with // is a PDL comment line, so remove l of those lines. I guess that the other words starting with / are PDL directives. Remove the lines /Angle Radians and /FractionMark and add an ASCII file transfer header %%HP: T(3)A(R)F(.); line as the first line. Replace the line /InstlDir with DIR and add an END as the very last line. Remove the line /AutoExec. Some lines start with /VAR ; remove that from the beginnings of the lines, so that, for example, /Var B->O is changed to just B->O. The file has a lot of UserRPL comments that would be stripped out by the compiler anyway, so you could remove those in the text editor to shorten the download time. The UsrRPL comments begin w1th @ and continue through the next @ or until the next end of line, whichever comes first. -- === Subject: Re: [HP 49G] Program that didn't work > I have an important program I downloaded in hpcc. I uploaded this > program to my cc and the cculatrice didn't see it like a program > but like text ! I 't understand why! Please if someone can help me > it will be very greatful for me. Excuse me for my bad english. > The link to the program: > http://www.hpcc.org/hp49/apps/misc/ipcc.zip Without more details it's hard to help, but I suspect you need to set TRANSIO 3 on the cculator. In RPN mode, type 3 TRANSIO then try to instl the program again. === Subject: TGV Plus converted for hp49g+ The TGV Plus library, created by HPNuts, HPdark, and modified by NScreetch and Cyrille Berger, has been slowed down in order to run on hp49g+. If someone can test it, I'd be glad to know about it. Download it at : http://www.hp-sources.com/SoftsHP/tgv.zip until updates his website. . === Subject: Re: HP49G vs. HP 49G+ sofare.. >>The 49G+ has an updated ROM, but, as far as I know, no new features. > Yes it has : > with the ARM programming, you can dispay non-flickering at l > greysce pictures. > Furthermore, you so have a remote control mode (ON-R). > And the cculator is able to display the capacity of the batteries : > ON-F then 8 (power). > The key testing procedure is quite nicer, too (a screen displays the > keys that have been pressed). > Perhaps some eastern eggs haven't been discovered yet, so > . Tell me about this remote control mode! === Subject: Re: HP49G vs. HP 49G+ sofare.. > Furthermore, you so have a remote control mode (ON-R). > And the cculator is able to display the capacity of the batteries : > ON-F then 8 (power). - What is remote control mode? === Subject: Re: Hp 48gII AYUDAAA!!! HP48(S, SX, G, GX) libs wont work on the HP48gII - it's actuly HP49 cculator. B where did you get that HP48gII? They were l recled, are they back? > necesito la siguente ayuda: > no puedo instar librerias en el puerto 0, estoy tratando de pasar la > libreria de las impresoras Hp, las paso en kermit y bin, pero me da error de > syntaxis cuando pongo 0 sto (rpn), y ademas el cabez de la variable es > hphp... > que hago?? como insto esa libreria?? porfa ayuda, gracasi, recuerden que > no es la gx es la 48gII > Translation: > I need the following help: > I cannot instl libraries in port 0; I'm trying to use the library for > HP printers. I used Kermit and binary, but it gives me a syntax error > when I do 0 STO (RPN), and the header is HPHP > What do I do? How do I instl it? Please help me, thank you, and > remember that it's not the 48GX, but rather the 48gII. > ------------------ > My response: > He has contacted me through #hp48 (EFnet). He is using the HP48 library > for HP printers. > Am I correct that 48 libs do not work on 48gII? I told him to go find > the HP49 version of said library and it should work. > ------------------- > My response (Espanol, para los chileanos): > .83l me ha hablado en #hp48 (EFnet). Est.87 usando la libreria de > impresadoras HP para la HP48. > Tengo razon que las librerias para 48 no funcionan en la 48gII? Le dije > que tiene que buscar la libreria para la 49 y debe funcionar. > ------------------- > === Subject: Re: Hp 48gII AYUDAAA!!! >HP48(S, SX, G, GX) libs wont work on the HP48gII - it's actuly HP49 >cculator. B where did you get that HP48gII? They were l recled, are >they back? Yes. At the university bookstore I saw them 2 or 3 days ago. Intersting to note they costed a little less than 100$ with tax and the 8 out on dispay were l sold when I passed through yesterday. . . maybe for < 100 there are some happy to buy it! If you 't want lots of programs, just a mathematic capable cculator it does the job for cheaper! And yes I did ask if they were sold or not. I was thinking maybe a second recl. . . ;-) ---------- === Subject: Re: Hp 48gII AYUDAAA!!! You wouldnt know anything about the keyboard, would you? >HP48(S, SX, G, GX) libs wont work on the HP48gII - it's actuly HP49 >cculator. B where did you get that HP48gII? They were l recled, are >they back? > Yes. At the university bookstore I saw them 2 or 3 days ago. > Intersting to note they costed a little less than 100$ with tax and > the 8 out on dispay were l sold when I passed through yesterday. . . > maybe for < 100 there are some happy to buy it! If you 't want > lots of programs, just a mathematic capable cculator it does the > job for cheaper! > And yes I did ask if they were sold or not. I was thinking maybe a > second recl. . . ;-) > ---------- > === Subject: Re: Hp 48gII AYUDAAA!!! >You wouldnt know anything about the keyboard, would you? Nope. I just noticed the colors and saw that they had forgotten to label the Z pha key. . . bet then i squinted a little more and saw it on the / key ;-). ---------- === Subject: Re: HP 32ii/33s programing... > X > > The keys click OK in your 33s ?! > I have not had any problems with the keys. The click is very good. I have > a > 42s, 32sii, 48sx, 48gx (black on gray) and I used to have a 48gx (blue on > green). I like the feel of the 33s keys better than my 48sx and black on > gray 48gx. > There are asthetic issues that I 't like, but the cculator seems to > be > well built. The slanted keys do distract a little, enough to make it a > chlenge at times to find the right key. Once I learn the layout it > shouldn't be a problem. > What about the wrist angle when thumbing the 33s > is is better with the V-style key thumbing > [VPN] I 't perceive any benefit. I think someone just thought it looked good. === Subject: Re: Problem reading HP48 programs on HP49G+ For text file compiling right on the 49g+ try looking at this posting by Michael Heinz from the other day: http://tinyurl.com/2q8nj Just transfer any UserRPL programs to your 49g+ as text files - they will likely appear as string-objects on the 49g+. Then recl the string to the stack and run IN. Or go directly from an SD card with the other commands. I have tried it, and it works well. Note that I have only used the program with text files transferred via SD card but I 't see why it wouldn't work with text files transferred with the connectivity kit. If the files are somehow being corrupted during transfer, you may run into conversion (compile) errors though. Good luck! > X > > The header looks like %%HP: T(3)A(R)F(.);HPHP48-x > X > This might help > 1) > << DUP 17. 17. SUB , == -51. SWAP :: SF :: CF IFTE 22. 1.E12 SUB > >> 'STRIP' STO > 2) > << 013 SREPL DROP > >> 'CLEAN' STO > 3) > << -> n > << n DUPDUP 2. DISP RCL STRIP CLEAN > IFERR STR- THEN HT > END SWAP STO n > >> DROP > >> 'DOIT' STO > 4) > << PUSH MyDir VARS 1. > DO GETI DOIT > UNTIL -64. FS? > END DROP2 POP > >> 'DOL' STO > 5) > STOre the PATH to your directory to 'MyDir' > where l your broken program are stored. > 6) > DOL > [VPN] > Maybe I did something wrong, but I am still confused. I could read > again my programms with the emulator downloaded from hpcc.org I > used the following programm > debug4x > and it worked. I will try to save them again and then download them in > the hp49g+ > If it still does not work, then I have to tip l again but I can at > least read my programms with the emulator. :) === Subject: Re: Problem reading HP48 programs on HP49G+ > For text file compiling right on the 49g+ try looking at this > posting by Michael Heinz from the other day: > http://tinyurl.com/2q8nj > Just transfer any UserRPL programs to your 49g+ as text files - they > will likely appear as string-objects on the 49g+. Then recl the > string to the stack and run IN. Or go directly from an SD card with > the other commands. I have tried it, and it works well. Note that I > have only used the program with text files transferred via SD card but > I 't see why it wouldn't work with text files transferred with the > connectivity kit. If the files are somehow being corrupted during > transfer, you may run into conversion (compile) errors though. Good > luck! === Subject: HP-33 Where is everyone buying the HP-33's. I have not found a source in my area, and I live in a college town. === Subject: Re: HP-33 > Where is everyone buying the HP-33's. I have not found a source in my > area, and I live in a college town. WMart got a speci de to sell the early lots on their website. Some of the other mail-order places may be offering them soon. It'll take longer to physicly stock them in stores, of course. Pleased with mine so far. bkr === Subject: Re: portable qwerty keyboard for hp49g+ > Would it be too complex a task to write a routine to enable communication > beeen the HP and a Belkin F8U1500 Irda keyboard??? t I 't think that it would be an overwhelming programming task given the availability of termin emulators available. I wonder, however, at the wisdom of doing so. IrDA applications are not known to be power misers and I could easily see you sapping your batteries rapidly. === Subject: Re: Sml, slightly useful ARM program to test for the HP49G+ by googling. The following .zip has o implimentations. 1) the long division method and 2) the add 3 method. http://www.cvin.edu/~sstear70/downloads/Int2str.zip In the add 3 method, loops where partily unrolled, and the code generates a lookup table (256 entries) to remove the need for isolating nybles in a byte, comparing to 5 and add 3. It so (roughly) avoids shifting and bcd adjusting un-needed leading zeros. I say roughtly because every 8 bits it recculates the working range with the 2.5x+1 formula, and it can work on leading zeros because of the loop unrolling. Using VTI and by counting in my head it feels like the add 3 method timings are not that great as they were e by counting in my head with VTI: my cculator is at school. By comparison the long division About the hw divide of the 68k. It takes a whopping 140 clocks. The first iteration of long dividing 299! by 10,000 will require 254 divu instructions then 4 more to isolate digits. This is a lot of clocks, but it guarantees 4 digits. === Subject: First impressions of warranty replacement 49g+ Well, at last, I received my replacement 49g+ a couple of days ago. On March 1st, I sent the origin (from Michigan to Cifornia) by USPS Priority Mail with Delivery Confirmation. The USPS web site still doesn't show it as being delivered, just that it was processed and left their Long Beach, Cifornia facility on March 3rd. So anyway, I 't know whether the unexpectedly long replacement time is because of a USPS problem or slow processing on HP's part. I suppose that I ought to ask for a refund of my extra 45 cents the next time that I happen to be at the post office. HP sent the replacement by FedEx Priority Overnight on March 17th labeled with Deliver by 18MAR04 12. Oh well, I do live out in the sticks and the gravel roads are especily bad right now, so FedEx is forgiven. I've barely played with the replacement yet, but here are my first impressions. As others have noted, the replacement was a complete retail package, not a bare replacement cculator in a box by itself, so the extra case, USB cable, batteries, CD-ROM, and user's manu sort of make up for my trouble and shipping cost. At least I'm reasonably sure that the replacement isn't a refurbished cculator. I expect that they'll change this as soon as they get a chance. The packaging hasn't changed; it still required leather gloves and a heavy-duty Stanley knife to get it open, but I managed without any bleeding injuries to myself. It certainly seems like way more than enough to discourage any shoplifter from trying to open it in a store. The seri number on the cculator still isn't visible until the cculator is removed from the packaging. Someone mentioned a visible change to the code at the lower right back cover of the user's manu. On my old one it's HDPMSG49E04 MWJ, and on the new one, it's HDPMSG49E21 MW1; how that correlates with the cculator's production date, I 't know. I haven't noticed any other change to the user's manu, but I 't care to go through it page by page. The extern seri on the replacement is CN402xxxxx, with an intern seri of CN403xxxxx. The battery cover seems a lot easier to remove. On the old one, that was a re bear. I'm not sure whether they've left any extra clearance for the top battery (the one with the spir contact under the battery button). With the Panasonic batteries supplied, there's just a tiny clearance beeen the barrel of the battery and the case, and the spir contact still looks quite flat. I haven't had any problem with battery contact so far, but I'll keep the possibility of a problem with a relatively short battery post in mind if I ever have any trouble with replacement batteries. One of the first things that I noticed is that the cursor down key is still defective. Offhand, other defective keys are E, cursor up, and cursor left. It seems that I have to press not just until I feel the key toggle, but just a little farther until it actuly bottoms out and won't go any farther. Those are the keys that I notice often miss keystrokes just typing normly, as I would on a 48 series. At least the CANCEL key seems to work ok; missing that particular keystroke on the old 49g+ was particularly annoying. If I rely try to make the new 49g+ miss keystrokes by setting it on a hard surface and pressing graduly with my fingernails, I think that l of them show this behaviour. I guess that HP still doesn't quite get it; this is still worse than the 49G, which has the same behaviour but not as bad. With the 16C, 28 series, and 48 series cculatoI can't make them miss a keystroke when I've pressed a key to the toggle point, and typing normly, I've never had a problem with them. I 't have the old 49g+ to do a side-by-side comparison, so it could be at least partily wishful thinking, but my impression is that the new keyboard is quieter and doesn't require as much force. Less force required may well contribute to missing fewer keystrokes when typing normly. There's still some unevenness to it though; for example, the 7 key has a sharper feeling click and is noisier than other. Overl, I think that the new keyboard is a lot better than the old one, though still not near the quity of the pre-49G cculators that I have. The replacement came with the latest Revision #1.23 ROM (VERSION: 03.54 BUILD NUMBER:0031 from ON-F or ON-D) instled. The SD card still works on the replacement. The new CD-ROM does have newer files for the manus; they're dated German, and Portuguese as well as the English and Spanish available on the old CD-ROM. I notice that the manus still waste a lot of white space on each page. The ConnectiveKit and UsbDriver files are website or hpcc.org. There's still no flash ROM file on the CD-ROM. Overl, I think that the improved (well, maybe I should say not as bad) keyboard made getting the warranty exchange well worth my time and expense, but I can't help thinking that maybe I should've waited a few more months. -- === === Subject: Re: First impressions of warranty replacement 49g+ Does your battery cover have a rubber pad (inside) to keep the batteries seated? My origin hp49g+ did not; but my warranty exchange unit does. This should address the battery issue >Well, at last, I received my replacement 49g+ a couple of days ago. >The battery cover seems a lot easier to remove. On the old one, that >was a re bear. >I'm not sure whether they've left any extra clearance for the top >battery (the one with the spir contact under the battery button). >With the Panasonic batteries supplied, there's just a tiny clearance >beeen the barrel of the battery and the case, and the spir contact >still looks quite flat. I haven't had any problem with battery contact >so far, but I'll keep the possibility of a problem with a relatively >short battery post in mind if I ever have any trouble with replacement >batteries. === Subject: HP49G+: What to optimize/rewrite in ARM code? Since it's now possible to rewrite commands to improve speed, I'm wondering what to rewrite next (When I get some free time). not because it's terribly useful. Now I'd like to try something else. Here are the conditions: 1)The command must be worth rewriting. If it is very rarely used, or executes fast enough ready then there's no point rewriting it. 2)It must be somewhat simple. I'm not a mathematician, and I 't know that much about the interns of the HP OS or CAS. So rewriting a complicated symbolic maths routine is out of the question. Any suggestions? As a guide, the factori rewrite gave a ten-times speed increase over the built in command (I've uploaded a new version), without any tricky coding. I'm guessing other routines should have the same gain. === Subject: Re: HP49G+: What to optimize/rewrite in ARM code? How about file searching routines? But To have the greatest impact faster file searching would have to be part of the rom so that the CAS and program interpreter can gain some benefits. I know open source isn't a magic word that guarantees hundreds of brilliant coders working for free, but hp rely aught to consider it for the 49g+. http://www.nyl.net > Since it's now possible to rewrite commands to improve speed, I'm > wondering what to rewrite next (When I get some free time). > not because it's terribly useful. Now I'd like to try something else. > Here are the conditions: > 1)The command must be worth rewriting. If it is very rarely used, or > executes fast enough ready then there's no point rewriting it. > 2)It must be somewhat simple. I'm not a mathematician, and I 't know > that much about the interns of the HP OS or CAS. So rewriting a > complicated symbolic maths routine is out of the question. > Any suggestions? As a guide, the factori rewrite gave a ten-times > speed increase over the built in command (I've uploaded a new version), > without any tricky coding. I'm guessing other routines should have the > same gain. === Subject: Re: HP49G+: What to optimize/rewrite in ARM code? > Since it's now possible to rewrite commands to improve speed, I'm > wondering what to rewrite next (When I get some free time). I was thinking about the BZ compressor but I am not sure it is that straightforward. It is however undoubtably useful Arnaud === Subject: Re: HP49G+: What to optimize/rewrite in ARM code? > Since it's now possible to rewrite commands to improve speed, I'm > wondering what to rewrite next (When I get some free time). > I was thinking about the BZ compressor but I am not sure it is that > straightforward. It is however undoubtably useful Much to risky! Remember the unstable TNT! The current BZ-decompressor from OT49 has 32.5 bytes only and is extremely fast even with very long BZ-strings. It is based on the asm-pointer aBZU from the ROM. That compressing needs more time is no problem at l. One doesn't BZ-compress every day. Something useful would be rewriting the first loop in ROMPTR 151 E from Headman in ARM code. It splits a huge text into pages with lines of a prescibed length and is based on FPTR 3 9B. This one is cled FPTR^StrCutNchar2_ in Carsten's Data base. (I wonder who suggested to him such a cumbersome name === Subject: Re: HP49G+: What to optimize/rewrite in ARM code? > Much to risky! Remember the unstable TNT! The current BZ-decompressor > from OT49 has 32.5 bytes only and is extremely fast even with very long > BZ-strings. It is based on the asm-pointer aBZU from the ROM. That > compressing needs more time is no problem at l. One doesn't > BZ-compress every day. I am sure that there are sever zip class compression tools e in ARM assembly that are just waiting to be ported to the 49g+. http://www.nyl.net === Subject: Re: HP49G+: What to optimize/rewrite in ARM code? > > Since it's now possible to rewrite commands to improve speed, I'm > > wondering what to rewrite next (When I get some free time). Some other funtions which would be extremely useful and would make multiprecision floating point operations practic on the cculator: integer addition integer multiplication integer division integer square root for decim integers (conversion of binary integers to hexadicim integers and vice versa) E.g. square root consumes about 50-95% of the work for ln, exp, asin acos atan and hypergeametric functions for re and complex numbers. The overl speed gain would be very high. See my longre library at http://www.praxelius.de/skailand/longfl32.htm http://www.praxelius.de/skailand/longfloat32.zip and let me know if I may be of any help. === Subject: Density Plot -- Putting Cyrille's Code to Work to insert a density plot. Find my handywork at http://home.comcast.net/~lass-ripper/. Not quick--be sure to have new batteries available. If someone can optimize this, I would be delighted. ----------my manu--------------- Density Plot Directory for HP49G+ By John Gustaf Stebbins lass-ripper-at-comcast.net The directory contains the following objects: DENSITYPLOT A program to generate a density plot. Takes five inputs. 5: function 4: minimum x vue 3: maximum x vue 2: minimum y vue 1: maximum y vue The function needs to take 2 inputs, x and y vues, and return a single vue. Return vues from 0 to 16 are matched to grey sces 0 to 15. Out of range vues are set to 0 or 15 as appropriate. The output is a string that can be compiled to show a greysce image. Incorporates code by Cyrille. STRDP Compiles and displays the strings as graysce image. SPIRSTR Example string of a spirling cosine curve. MANSTR Example string of a mandelbrot set plot. SPIR Function used to make spir plot. MANDELBROT Function used for mandelbrot set plot. HDR String object placed before graysce image. Contains ARM code. FTR String object placed after graysce image. so contains ARM code. ESTR String object used for padding graysce image lines. NTC Function that turns a number into a hex string character, 0 to F. Out of range numbers are truncated. === Subject: Re: Density Plot -- Putting Cyrille's Code to Work Beautiful! programs > to insert a density plot. > Find my handywork at http://home.comcast.net/~lass-ripper/. > Not quick--be sure to have new batteries available. If someone can optimize > this, I would be delighted. > ----------my manu--------------- > Density Plot Directory for HP49G+ > By John Gustaf Stebbins > lass-ripper-at-comcast.net > The directory contains the following objects: > DENSITYPLOT > A program to generate a density plot. Takes five inputs. > 5: function > 4: minimum x vue > 3: maximum x vue > 2: minimum y vue > 1: maximum y vue > The function needs to take 2 inputs, x and y vues, and return a single > vue. Return vues from 0 to 16 are matched to grey sces 0 to 15. Out > of range vues are set to 0 or 15 as appropriate. > The output is a string that can be compiled to show a greysce image. > Incorporates code by Cyrille. > STRDP > Compiles and displays the strings as graysce image. > SPIRSTR > Example string of a spirling cosine curve. > MANSTR > Example string of a mandelbrot set plot. > SPIR > Function used to make spir plot. > MANDELBROT > Function used for mandelbrot set plot. > HDR > String object placed before graysce image. Contains ARM code. > FTR > String object placed after graysce image. so contains ARM code. > ESTR > String object used for padding graysce image lines. > NTC > Function that turns a number into a hex string character, 0 to F. Out of > range numbers are truncated. === Subject: Re: IR on the 49G+: flags? > I decided to open this new thread to ask for help to the owners of a HP49G+ > who probably didn't read the post Sdiag in Emacs 2: l userRPL commands > are covered?. > I've readed here on the group that someone used the 49g+ IR successfully. > Since I 't own a 49g+ and C. Dominik asked me to edit a flag document > for the 49g+, I'd like your help to know if the I/O flags still affects I/O > operations... > The questions are the following: > * The I/O flags affects so the USB transfer? (e.g. the flag 35 affects > if the files are transferred in binary or ASCII mode)?.. easily tested with > the connectivity kit I guess. I expect that flag -35 is respected for IrDA Kermit transfers. With the Conn4x connectivity kit, flag -35 is ignored. The selection of binary/text is made on the PC when using Conn4x, with the cculator in Xmodem Server mode. Conn4x doesn't seem to use Kermit transfers at l. I suppose that, when in text mode, it may well use some sort of decompilation command on the cculator and may use the SysRPL translation commands KVIS or KVISLF and KINVIS and the SREPL command or similar for translating the control codes. On the other hand, I suppose that l of the decompilation/compilation and translation could be e on the PC. Perhaps only Bill Graves knows for certain. Note that Conn4x so works with the 49G and the 48G series, though I think that you have to instl the XSrvr library to use text mode and various other very nice features of Conn4x with the 48G series. > * Clearing flag 33 disable the IR I/O capability of the cc? Well, for certain, clearing flag -33 (Transfer via wire) enables USB transfeand setting it (Transfer via IR) disables USB transfers. I suppose that this flag switches beeen Wire and IrDA for norm I/O communications for Kermit and Xmodem, and perhaps the Seri I/O commands as well. Others have written that at least Kermit works via IrDA. > same for > setting flag 34? What I know for sure is that (regardless of the state of flag -33) with flag -34 clear (Print via IR), it sends in the Red-Eye format required by the 82240A/B printeand with flag -34 set (Print via wire), it doesn't. and I gather that with flag -34 set (Print via wire) and flag -33 so set (Transfer via IR), it prints in IrDA mode. Rather reminiscent of the 48 series printing in Seri IR with that particular combination of flag states. That leaves the combination of flag -34 set (print via wire) and flag -33 clear (Transfer via wire). Could it be printing via USB? The Busy and I/O annunciators turn on, so it looks as if it's at least trying to print something. On the 48 series and 49G, that combination would print to an RS-232 seri printer or print to HyperTermin via a COM port. But how to test this on a 49g+? As far as I know, l USB printers require a driver on the PC, and I 't know of any termin emulator that recognizes a USB port. I 't have any IrDA capable device other than the 49g+; I hope that others will enlighten us. -- === Subject: Re: IR on the 49G+: flags? > With the Conn4x connectivity kit, flag -35 is ignored. > transfers at l. I suppose that, when in text mode, it may well use > some sort of decompilation command on the cculator and may use the > SysRPL translation commands KVIS or KVISLF and KINVIS and the SREPL > command or similar for translating the control codes. On the other > hand, I suppose that l of the decompilation/compilation and > translation could be e on the PC. Perhaps only Bill Graves knows > for certain. Flag -35 is ignored. I just use ->STR and OBJ-> plus a whole lot of PC translations. The translations are multi-stage because of PC file name limitations. So commands are different then text and their are speci cases gore. I am surprised I got that feature working, but there were a few errors ong the way! Your earlier comment about the 48G is true. If one uses the server that comes with Conn4x, everything works for the 48. I rely wanted a migration path for older cculators and I managed to keep it working. -- - - - - - - ===hj Subject: Re: problems reformatting SD card The thing is, it wouldn't reformat on my cculator, it would fail. I would have to format it on my computer first using the panasonic program and then my cculator could format it. I think I figured out the problem, though. I'm pretty sure my SD card reader is not fully function. I'll get a new one and see what happens. >http://panasonic.jp/support/audio/sd/download/sd_formatter_e.html >My question is if there is any particular reason why the cculator >wouldn't format l 256MB of my card like it did when I first put the >card in and told it to format? Is there any other way of fixing this >problem aside from what I did? > If you'd like we can arrange a trade. . . your broken 256 card for my > fully function 128. Tell you what I'll even throw in a bunch of > free sofare pre-instled! > Or if that doesn't sound like a good de, just reformat it on the > cc again. No problems doing so except your data will have gone on a > long extended not to return vacation. =) === Subject: Input Form and Nordea SOLO Internet bank codes. little program for accessing the Nordea SOLO Internet bank codes from HP48. It uses system inputform, requires the MD5 encryption library and the BZ. If you are interested in it, then let me know. I shl be writing the documentation and ask Rechlin to put it on the hpcc.org. Of course with the sources, so porting to newer platforms should be relatively easy. Best wishes, Robert Tiismus === Subject: New FAQ for HP49 and HP49+ Do you think it is time for new FAQ for the HP49 and HP49+ similar to the one e in the 1990's by Andre Schoor? === Subject: Re: How to use SD cards to transfer sofare to/from a Mac > While trapped in an l-day meeting today, I managed to track down > everything you need to save HP49G+ programs as text files on an SD card, > edit them with a Mac and then load them back into the HP49G+. Good, but I can foresee some possible problems. Maybe I'm just paranoid, but the file that the 49g+ stores on the SD card begins with an 8-character binary transfer header HPHP49-X followed by the compiled object, which (assuming a character string object) starts with the 5-nibble character string prologue, followed by the 5-nibble character string size field, followed by the characters in the string. What if I change the number of characters in the string without adjusting the size field to match? What I do is ways remove those first 13 characters with my text editor, just to make sure that the size field doesn't confuse the cculator. Without a vid transfer header, the cculator just treats the file as a character string, so the STR-> or OBJ-> compiles it correctly. But maybe this isn't rely necessary; I haven't actuly tried it without removing those first 13 characters. To avoid changing exact integers (type 28.) to re numbers (type 0.), have the cculator in Exact mode when using your programs. That goes for any transfer except from a 48, in which case the 49 series should be in Approximate mode to avoid changing integer vued re numbers to exact integers. Without an ASCII (text) transfer header, there are some modes used in the file that the cculator has no way of knowing, so it just uses its current modes. I see that you take care of the translation mode in your programs, but be aware of the following. If you have an object that includes an angular component (vector or complex number uploaded with the cculator in polar (cylindric) or sph display mode, or if you use the >) symbol as the separator in one of these in the text editor), then be sure that the cculator's angular units mode (Radians, Degrees, or Gradians) is set to interpret it correctly. Be sure that the fraction mark (. or ,) mode on the cculator agrees with what you're using in the file. And of course, one should be aware that your programs force the num display mode to STD, the wordsize to 64, and the translation mode to 3. -- === Subject: Re: How to use SD cards to transfer sofare to/from a Mac > Good, but I can foresee some possible problems. , You're right, of course - these routines are a first step. I've been out of the cculator scene for a good 4-5 years and I'm still on a re-learning curve. I haven't even touched the SysRPL aspects of the 49G+ yet. At a minimum, what I'd like to see is a routine that can interpret the HP text header you refered to and make changes as needed. At best, what I'd like is something that either extends or works like the FILES menu, so that you can select, copy and translate objects in one step. I 't fully understand the exact/approximate issue at this point, since I 't understand the implications of an integer being cast as a re. Any advice you can give on this issues would be appreciated. === Subject: Re: How to use SD cards to transfer sofare to/from a Mac built-in command to compile text files... > While trapped in an l-day meeting today, I managed to track down > everything you need to save HP49G+ programs as text files on an SD card, > edit them with a Mac and then load them back into the HP49G+. > To get started, BACKUP YOUR CCULATOR - to get this program loaded you > will have to enter a SYSEV by hand, and if you type it wrong you may > crash your culator! > Once you're ready, cut and paste the following text exactly as it > appears and save it to an SD card - I cled it XLAT.TXT > DIR > ->SD > << SWAP OUT SWAP STO > >> > SD- << RCL IN >> > OUT > << STD 64. SS ->STR 3. TRANSIO # 2F34Fh SYSEV > >> > IN > << ->STR 3. TRANSIO # 2F34Dh SYSEV + STR- > END > Next, put the SD card into your HP49G+ and recl the file to the stack. > Third step - for this first time, you have to type in a program by hand > to convert the text file to an HP object: > << ->STR 3. TRANSIO # 2F34Dh SYSEV + STR-> >> > Note that those -> and <- are arrows, and << and >> are the > start and end program symbols. Once you've entered this and you're sure > it's right, you should have o items on the stack, a string beginning > DIR on level 2, and the program on level 1. Press EV. The text file > on the stack will be converted to a directory object. Type in a name > ('XLAT') and press STO. > Presto, you now have tools for converting SD files into HP objects. The > tools are: > IN - Convert a escaped text string to an HP object and leave it on the > stack. > OUT - Convert the HP object on the stack to a escaped text string. > ->SD - Stores an HP object as a text string. The object to be stored > should be on level 2 of the stack, the name of the destination text > file, including port number, should be on level 1. > SD-> - Recls a text file from the SD card, converts it to an HP object > and leaves it on the stack. The name of the file (including port number) > should be on level 1. > Finly, you need to know what the various escape codes are. These codes > are used to translate beeen speci HP symbols (such as start and end > program) and plain ASCII. Here's the complete table: > Complete Table of Escaped HP Ascii Characters: > Backslash > <) Angle > x- Mean (bar-x) > .V Inverted Triangle > v/ Square Root > .S Integration > GS Sigma > |> Solid Triangle > pi Pi > .d Derivative > <= Less or Equ > >= Greater or Equ > = Not Equ > /Ga pha > -> Right Arrow > <- Left Arrow > |v Down Arrow > |^ Up Arrow > Gg Gamma > Gd Delta > Ge Epsilon > Gn Nu > Gh Theta > Gl Lambda > Gr Rho > Gs Lower Case Sigma > Gt Tau > Gw Omega > GD Delta Triangle > PI Upper Case Pi > [] Square Dot > GW Upper Case Omega > oo Infinity > You now have everything you need to write HP49G+ sofare on your Mac! > You can use TextEdit, jEdit, bbEdit or any other tool for editing plain > text files. === Subject: Re: How to use SD cards to transfer sofare to/from a Mac > built-in command to compile text files... There is: STR-> or OBJ-> === Subject: Re: How to use SD cards to transfer sofare to/from a Mac > built-in command to compile text files... > There is: > STR-> or OBJ-> > Unfortunately, STR-> and OBJ-> 't de with the escape sequences, which you need for editting source code on unsupported platforms. Urk! Time to run. I'll explain more later. === Subject: Re: How to use SD cards to transfer sofare to/from a Mac >> built-in command to compile text files... > There is: > STR-> or OBJ-> True, but it would be nice to have built-in UserRPL options to store decompiled and translated (with the translation options as in Conn4x) objects on the SD card, and copy/move them to a glob variable and have them untranslated, compiled, and stored automaticly. To be sure, we can do l of this easily enough with the help of SysRPL commands (or the equivent SYSEV sequences), but that seems to be a bit much to expect of the average user. Oh well, maybe in a future ROM. -- === Subject: Latex for HP 49G+ NG in the Preface to http://page.mi.fu-berlin.de/~raut/WR49/ > I know nothing about programming on the HP 49G+ other than > quite simple user RPL. Your Headman reading program, > which I use on a daily basis, is very impressive. This makes > me wonder that if it is even possible to have a HP 49 program > that can display dvi files created with Latex or Tex? > Or better yet, one that can create readable copies directly > from Latex files? > With the most unlimited storage capacity of the SD card, > it is conceivable to have math papers stored in the cculator > and read conveniently away from a computer. Just a thought. > ... It would not be a big de to write a previewer program for *.dvi files, similar to dvips which makes a *.ps from a *.dvi. POSTSCRIPT is RPN based and has some similarity to SysRPL. In any case, l default fonts for LaTex and perhaps MATHFONT or LFONT must be present in l sizes. This is for reading only. For making changes, LaTex itself had to be instled, including its dvi compiler. IMHO, this is too much, at least for present handholds By the way, it would be nice if JYA includes the card in the font browser in MODE/DISP or even limits it to browsing the card, or better a suitable card subdirecty named FONTS. That would solve once and forever l font choose problems. === Subject: Re: Let's help HP Cculators to get back on track It's not that Aman engineers are more creative - it's that committed, in-house engineers are more creative. People working under contract on specific projects are not going to deliver *more* than the contract specifies - why would they? Even if they *do* get an idea that would make things better, they can do better for themselves by saving that idea and using it later. L GOOD POINTS I agree with. My observations weren't based upon interfacing, necessarily, with contracted engineers. These were folks working for their employer in a revenue sharing mode with my company. Still, what you say is right on target. That, more than anything else, is why out-sourcing destroys companies in the long term. No short-term one-project hired-gun is going to generate radic new ideas for your company. They're going to save those radic new ideas for starting their *own* companies. so true. In our case, outsourced services have to sign strict confidentiity and export control clauses.... but what are you going to do when the outsourced folks find themselves in a country that doesn't care too much about contracts and 't have the desire to enforce those contracts in their native countries? That is the hole the ostriches (CEOs) are sticking their head in. I'm scared for the future as I feel my company (and proably many others too) are giving away their soul/technology for short term (steth) profits. I feel this practice is as close to prostitution as one can get without actuly having sex. What a shame. In my case, I think it is ready starting to blow up in my companies face. In the end, we're L going to lose, the CEOs with pull the rip cord on their golden parachutes, while the dumb engineers and workers have been booted out without a parachute. I'm with you on l of your statements. -- > No way in h _ _ _ ...I have interfaced with engineers from l over the > world. US/European engineers are TOPS. Indian and Chinese engineers are very > good as well, but seem to be happiest and most effective when given specific > tasks which are well outlines and/or refining a proven concept. > That's easy to understand. It's not that Aman engineers are more > creative - it's that committed, in-house engineers are more creative. > People working under contract on specific projects are not going to > deliver *more* than the contract specifies - why would they? Even if > they *do* get an idea that would make things better, they can do better > for themselves by saving that idea and using it later. > That, more than anything else, is why out-sourcing destroys companies in > the long term. No short-term one-project hired-gun is going to generate > radic new ideas for your company. They're going to save those radic > new ideas for starting their *own* companies. === Subject: HP49g+ vs HP49g I have run some comparison speed tests with my old 49g and found the following using the TEV function running << 1 10000 FOR X NEXT >> speed improvement 2.3x Running << 1 10000 FOR X X SIN NEXT >> speed improvement 1.6x This is quite a departure from the 3x speed improvement I have read about elswhere on this group. Can someone else confirm these vues. Maybe the clock on my cc is running slow. By the way on the old 49g pressing ON-F4 and 2 gives the CPU speed, is there an equivent test on the 49g+? Luis