50G--the accumulated experience to date?


I believe the 50g has been out the better part of year. I haven't got one, since my 49G+ has been until recently underused and still works fine, but I would be interested on the collective experience of the 50g.

I get the impression that 50g is basically the 49G+ with some extended I/0 and powering capabilities. It is considered by most to be more visually appealing. And I also get the impression is is mechanically more sound--indeed, I haven't read here over the past few months any complaints of keyboard failures of the type that have plagued some lots of the 49G+.

I ask this not because I want a 50g at this time. Rather, I am hoping the improved quality of 50g will be reflected in the much anticipated 35s. Also, have the manufacturing improvements transfered to newer production for the 12c, 12cp, or 17bii+? I get the impression that my recently made 17bii+, although lightly used, is really better made than reports here would lead me to expect. Yet my 12cp is a bit older and has a mildly fussy keypad.



I can report that my 50g, an early production model (SN CNA 61807135) has held up great under moderate use. With about the same amount of use, my 49g+ was showing the strain, with some keys going "mushy" and others having the legends partially rubbed off. None of those symptoms have appeared on my 50g. Its keys are all still "snappy" and the key legends appear completely unaffected by being repeatedly pressed by my grimy fingers for a year. Also, the annoying debounce problems of the 49g+ are completely absent on my 50g.

I just replaced my first set of batteries in this machine. The four alkaline AAA cells lasted quite a bit longer than the three AAA cells of the 49g+. That's what you would expect, of course, but I think that the USB power feature also played a role. I spent lots of time with the calculator tethered to the PC as I did programming.



my 49g+ was showing the strain, with some keys going "mushy" and others having the legends partially rubbed off.

In my first year of ownership my 49G+ got little use since I found it to to be a battery hog and I found UserRPL to be a little inscrutable.

Since getting good rechargeable batteries and a quick charger, plus developing an interest in UserRPL, I have spend a lot of time with the 49G+ over the past few weeks. No key failures yet, but the gold paint, which frankly I thought was an attractive look even though it was not the most popular colour scheme here, is beginning to wear and pit around the edges. Legends remain intact, but the gold paint is becoming irregular around them.

Plus, I have some dust and a single cat hair stuck under the display plastic. A bit distracting, but I have no idea how to safely pry the plastic up to blow the lint out.

I really have grown to like the 49G+ and when it dies, which I am led to believe it will, I look forward to replacing it with a 50g.



Plus, I have some dust and a single cat hair stuck under the display plastic. A bit distracting, but I have no idea how to safely pry the plastic up to blow the lint out.

See this thread and
this other thread.




See this thread and
this other thread.


Thanks! The suction cup trick is exactly what I need. I believe my partner has some around the house sticking cut decorations on windows, etc.

Since I have your attention, where would you recommend I go for discussion about HPGCC programming? is the hp48 newsgroup a good place to start?



Hi Les.

I think that




might be a pair of good places to discuss about HPGCC.

Hope this helps.

Best regards.


Edited: 12 June 2007, 1:34 p.m.


As with most new machines, I usually wait for a significant length of time to let the bugs get worked out of the system and uncover weaknesses. That is why I have asked for a new 50G for Father's Day. That is about enough time, I imagine.

A new machine may still have manufacturing issues. Even an identical process, installed and started up next to the old one can have problems, much less a new design on a new production line with new people. There are many potential reasons why this can be so.


I have had a 50g since January, and use it daily (though sometimes only to play Tetris ;-) The keyboard and the aesthetics are definitely much improved and I am quite happy with it.

My only complaint is that they keep changing the color of the @#$%! shift keys! I am hoping that the next version they will go back to good ol' blue & gold and stick with them.


My only complaint is that they keep changing the color of the @#$%! shift keys! I am hoping that the next version they will go back to good ol' blue & gold and stick with them.

NOOOOOOOOO! I don't know if it is just me (I'm strongly red/green color blind) but I find it almost impossible to distinguish between the shift key colors on my 48gx and my new 33s. I love the color layout on the 50g. Easy for my old broken eyes to distinguish. Can we keep it, please? Please?

Edited: 10 June 2007, 6:59 a.m.


Actually, the 48GX and the 33S use purple and green for the shift keys, which is even worse. Especially on the 33S, the purple is so dark, it is hard to distinguish it from the black background.

The 50g is definitely better in that respect, I just wish they would be more consistent.



Brian, please look at the picture in this post. Can you see everything I talked about there? Any advise from your point of view (sic!) for improvement?



The color choices look good, easy to differentiate. I also feel the arrows on the color keys are a source of confusion. If you use well differentiated colors you don't need directional arrows. Always seemed kind of goofy to me.

As for the function selection and layout, I'll have to defer to wiser folks. Whatever the layout, I'll be buying at least one...




Thanks for your feedback. You can find the results in said other thread.


My 50g is at build 92 which I believe is the current supported version.

There was a bug in the previous version with LINSOLVE() as it is illustrated on page 11-41 in the "User Guide." This still doesn't work at build 92. I never tested the bug extensively because of other active people involved, so I'm now sure about the symptoms, but it does feel a little different from my limited exposure to the earlier version. If there's been one, I missed the announcement about anyone dealing with this bug.

I thought I had a bug with symbolic calculus, but I had set the flag on in the configuration I had setup. The settings of flag 117 on created a situation during the step-by-step process which gave me one or more extra steps over the normal in some integration. The problem was that it changed access through the sequence causing opportunies to crash before getting started. The welcome extra steps in some of the patterns helped in the analysis since the integrator likes using rational or partial fractions when it can. When there are other approaches available I like to see them.

For example, try integrating the secant of x several ways. I start with the reciprocal of cosine(x). I say x which works best with the calculator. int(1/cos(x))dx is solved in at least three different ways by pencil and paper, and one each by the 50g and by Mathcad 13. FYI, the 50g usually gives the easiest response to follow of the three and it is fast enough to compete with the other two, a real advantage in the field when you are competing for the assignment.

I have had trouble with the memory manager and linkage via the devices offered (conn4x, etc. I am afraid the common denominator is me rather than the 50g. I am very happy to see the luck everyone is having with the SD card! There's a lot of opportunities for improvement there like the ability for multiple directories, etc.

The keys are definitely superior in quality over the original 49g. Enough said there. Also, I keep two sets of batteries charged for the unit. May seem like overkill, but mine have never run down.

I have not run benchmarks with the interpreter level, but will trade any "slowness" for a calulator that supports customized everything like your own input forms design capability. With that one gig SD card or 2 gig, you can have several differnt custom calculators in one little package including mass storage.


Now, I would like some information from those of you who are currently informed in other areas. I am not familiar with the total programming picture here, but assume that there are at least 3 ways to use the 50g: the RPN interpreter as it comes in the box, a medium compiler, probably using p=code on a virtual machine with some added features over the basic interpreter and a machine level language limited compiler. In addition there are probably ways to use C++ for very efficient customerization.

How do I get my hands on the next level above RPN, suppose that would be like RPL? Can RPL run under emulation for developing custom routines - on a PC? Are most RPL routines able to run on either? Will RPN routines all run on the basic system?

Thanks for everything you do,



The 48g, 49g, 49g+ and 50G (as well as the earlier 48s) are all RPL machines. They are not RPN. The behave almost like RPN with direct calculations, yet they are slightly different. There is an infinite stack, there is an input buffer in addition to the first stack level (which would b be "x" in an RPN machine) and most importantly, there are multiple datatypes.

RPL machines behave more like a line interepreter--the user is free to put an infitite number and combination of invalid information into the input buffer. In RPN machines, invalid input is finite, as the selection of inputs is limited, and you don't have a separate input buffer--you write directly to the x register.

An example of the difference in behavior is easily demonstrated with taking the square of a number using the stack:

--------- RPN --------| -------RPL
(x,y,z,t) (1,2,3,4...)
4 4,_,_,_ _,_,_,_... {sitting in input buffer}
enter 4,4,_,_ 4,_,_,_...
X 16,_,_,_ 4,_,_,_... "* Error: Too Few Arguments"

To square a number in RPL, you have to enter *twice* in order to push the inpuit inot both the 1st and 2nd levels of the stack.

User RPL programming is directly accessible from the keyboard simply by typing the << >> characters, whic hare the programming delimiters. There is no separate porgramming space as in RPN. Programs can be recalled to the stack, edited etc. You EVAL a program to execute it, or you save it into a variable, and simply select the variable from the softkey to execute it.

System RPL is a larger set of instructions which is also directly accessible to the user, but the coding is more machinelike. It is the underlying language that USER RPL is built from. The hazard of SYSRPL is that the inexperienced user can easily freeze the machine and dump all memory, as SYS RPL does not check for valid data, as USR RPL does. USER RPL is robust for an end-user programmer.

When the 49G+ came oout, the SATURN processor was emulated by a newer chip, and in doing so, that opened up the possibility of hacking into the base level of that machine code, which was successfully carried out less than a year after the 49G+ was released. In addition, there have been a number of people working on C porgramming for it but I don't know the details.

The 49G+ and the 50G are the same in their basic architecture nad language and processor--just the 50G addressed a number of issues in the hardware especially.

Edited: 10 June 2007, 10:07 a.m.


To add to what Bill has written, the C language system is HP-GCC (Linux and Windows versions, project home page). This consists of a translator from the elf format produced by the GCC arm code generator, a shim to enable loading and running the results on the calculator, and libraries for accessing the features of the machine from C code. If you want native 75Mhz ARM speed on the 50g, this is the way to go.



Thanks, Bill and Howard for clarifying the RPN/RPL thing. I suppose those benchmarks on speed are for 50g and others recorded under RPL. Would that be "User RPL" or native interpreter?

I plan to write up the photography questions for DEPTH OF FIELD and others using multiple equations. I believe they will be ideal for INPUT FORMS similar to the financial screen.

I take it that the develoment software is available through HPCALC'

Thanks again


Certainly UserRPL isn't "Classic RPN" as implemented in other HP
RPN models, but with the exception of program structures, UserRPL
is quite consistent in following the RPN (Reverse Polish Notation)
model, that is, any arguments first, followed by the operator;
it's a strictly postfix notation. I'd say that UserRPL
is an implementation of RPN, although not the same as
Classic RPN.

As a logical/mathematical notation, RPN doesn't impose any
inherent limit on the number of arguments waiting to be operated
on. Classic RPN has the limitation of 4 stack registers, plus
other registers which can be copied to or from the stack. For the
UserRPL models, the only limit to the number of stack levels is
the amount of available memory, so in this respect, I'd say that
RPL comes closer to being truly RPN than Classic RPN does.

For the RPL models, assuming that vectored ENTER isn't in effect,
when ENTER (or a key that invokes an implicit ENTER) is pressed,
source code keyed into the command line editor is parsed, and,
assuming valid syntax, compiled and combined into a secondary
(SysRPL program), which is placed on the stack and executed. For
source code "quoted" between UserRPL program delimiters, the
evaluation of the delimiters and their contents is to a program

The contents of the command line amount to the source code for the
contents of a program waiting to be parsed, compiled, and
executed, and the contents of a UserRPL program could be
considered the compiled unevaluated equivalent of a valid command

Note that an ENTER operation always compiles the command line's
(or other editor's) source code to some type of RPL object. The
"stack" is really a stack of pointers to objects elsewhere in
memory, and the "objects" that you see on the stack are really
decompiled character string versions of the objects pointed to.
For the stack display, this decompilation and the display update
takes place only just before the system is ready to accept
keyboard input, not while a program is running.

Similarly, editing, the \->STR command, transferring in "ASCII"
("Text") mode, or printing decompiles the object to a character
string (source code) equivalent, and in the case of transfers or
printing "via wire", optionally with non-ASCII codes "translated"
to pure ASCII sequences.

This compiling explains why all formatting ("white space" and
line-breaks) and commenting is lost as soon as you press ENTER. If
you want to preserve your formatting and comments, then either
write your source code within a character string or else write it
on your PC and transfer it to the calculator.

Note that for the RPL models, when in the "standard stack display"
(no command line or other "special environment" active), pressing
the ENTER key does not invoke an ENTER operation;
it's simply a "keyboard shortcut" that invokes a DUP command.

The UserRPL commands are actually special cases of named SysRPL
programs that include argument checking intended to prevent the
user from doing anything that would corrupt user memory. SysRPL
commands are unnamed on the calculator itself (unless a special
library is installed), and SysRPL commands are actually SysRPL (or
in some cases, machine language) programs that, in most cases,
contain other SysRPL commands and often have embedded machine
language code. Of course, ultimately, it's machine language code
that ends up being executed. If you want to investigate, then I
recommend a library named "Nosy", available from hpcalc.org.

For all RPL models, the ordinary user does have access to SysRPL
objects numerically by the use of the UserRPL commands SYSEVAL,
LIBEVAL (48G and newer only), and FLASHEVAL (49G and newer only).
Care must indeed be used with these commands. For example, SYSEVAL
does check that it has a user binary integer for its argument, but
other than that, it doesn't do any argument checking; it simply
causes execution to jump to that address, whether it makes any
sense to do so or not, and misuse of these commands may very well
cause memory corruption. Also note that "unsupported" entry points
may well change with different ROM revisions, and even "supported"
entry points often change with a different series of models (48S,
48G, or 49). If you want to use one of these operations
frequently, then I'd suggest that you write a small named program
that first checks for the required arguments, followed by the
numeric argument and the SYSEVAL, LIBEVAL, or FLASHEVAL command,
and then execute the program by name. If you want to embed one of
these commands within a UserRPL program, then make sure that the
program will definitely ensure that any required arguments for the
sequence are available on the stack first.

For the 48 series, HP provided tools for writing SysRPL and Saturn
assembly language programs on a PC, and 3rd-party external
libraries were developed to do this on the calculators themselves.
For the 49 series, a SysRPL/assembly language compiler (MASD, or
the "Development Library"), including assembly language mnemonic
keywords, is built-in, although "out-of-the-box", only numeric
SysRPL codes can be used. To use mnemonic SysRPL keywords with the
"Development Library", an extable library has to be installed.

For the ARM-based models (49g+, 48gII, and 50g), the Saturn
processor is emulated, but note that the emulated Saturn processor
has additional (apparently "unsupported", but, I hope, stable)
machine language opcodes and, for the Development Library, their
matching assembly language mnemonic keywords, and it's often
referred to as the "Saturnator" or the "Saturn+ processor".

SysRPL and assembly language programming are intended for
"developers", not for "ordinary users". In general, the results of
a mistake are often dire enough that most of us (Wolfgang and
perhaps a few others are exceptional) shouldn't attempt to use
them for ad hoc programs where development time is an important
consideration. That said, with the 49 series, (or a 48 series with
a RAM card installed), archiving and restoring all of user memory
(which may very well be corrupted in case of a mistake) isn't very
difficult, and the compiler is built-in on the 49 series with an
extable library easily installed, so it isn't unreasonable for an
"advanced" user who's willing to take the time to learn how to do
so to write his own "development language" programs.

The advantages of SysRPL programming are, first, that there are a
lot more commands available than with UserRPL, and second, most
SysRPL commands don't spend any time doing argument checking. Of
course, the disadvantages are that the lack of argument checking
means that the developer has to be more careful, there's a lot
more that can be learnt (much of which is "an exercise for the
student"), and with so many more ways to accomplish the same
thing, choosing which way to do it may be more difficult.

The advantages of assembly language programming are that you can
do things in it that would be difficult or impossible in RPL, and
a well-written assembly language program should be faster than an
RPL program that accomplishes the same thing. A disadvantage is
that it often takes several assembly language commands to
accomplish what could be done with just one RPL command, so
assembly language programs are typically larger. Of course, a
mistake in an assembly language program can be just as disastrous
as in a SysRPL program.

Note that assembly language (or machine language) code sections
can be embedded within SysRPL code.

With the ARM-based models, it's possible to access the underlying
ARM processor, and indeed HPGCC has been developed for using C++
code with these calculators. That said, I've never experimented
with this.

Of course the 49 series also have an ALG mode, and programming in
this mode seems to be what HP means by "hp basic" in regards to
these models. Note that this "hp basic" is not related to BASIC
(Beginner's All-purpose Symbolic Instruction Code). The only thing
that I've bothered to figure out how to do in ALG mode is
switching to RPN mode; if I'd wanted an algebraic model, then I
would've bought a "Brand X" model.

SysRPL is also the underlying "development language" for many of
the algebraic-only models that use the Saturn processor,
beginning with the 18C. In some cases it's possible to write and
compile a SysRPL / assembly language program and transfer it to an
algebraic-only model. I don't have any of the algebraic-only
models, and I have no personal experience with this.

The comp.sys.hp48 usenet group certainly seems a better place to
discuss the RPL models; many RPL experts frequent that newsgroup
and are generally very helpful, although of course it's best to
"do your homework" and try to avoid repeating the "Frequently
Asked Questions". I prefer to participate in that newsgroup by
using Thunderbird with my ISP's news server, but it can also be
accessed through
http://groups.google.com/group/comp.sys.hp48/. The entire
newsgroup archive, all the way back to 1991, can be searched from
http://groups.google.com/advanced_search? (which also works
for any "Google Group" or any usenet group that Google has

The current HP Museum CD-ROM set / DVD-ROM includes lot of
information about the RPL models, including documentation for the
48SX Equation Library card, which is useful for using the Equation
and Periodic Table libraries on the current models. I particularly
recommend the books by William C. Wickes. See

Certainly any 49g+/50g user should have the 48gII/49g+ Advanced
User's Reference Manual, available from HP's site.

Note that a version of the current 49g+/50g "ROM" without the
optimizations for running faster on an ARM-based model is included
with Debug4x. With minor tweaks to a copy of a 49G .KML file, this
can be used with the 49G emulator and transferred to a real 49G
with the ROMUPLOAD command. Except for the execution speed and
hardware-dependent operations (including Saturnator-only opcodes
and accessing the ARM processor), you can make the 49G behave very
nearly the same as the 49g+ and 50g, with the latest ROM revision.

Note that emulators for the 48GX and all 49 series models are
included with Debug4x, but also note that it's the "Hardware
Saturn" that's emulated, not the ARM processor with a
"Saturnator". See http://www.debug4x.com/.

Alternatively, a 3rd-party Version G Revision #2.10-7 ROM, with
some bug fixes and additional capabilities, can be found at
http://www-fourier.ujf-grenoble.fr/~parisse/english.html (or
http://www-fourier.ujf-grenoble.fr/~parisse/francais.html if
you read French). This version includes the Equation and Periodic
Table libraries for the 49 series. Information on the 49 series
CAS can also be found from there.

The most recent Equation and Periodic Table libraries for the 49
series can also be found from

Of course, any RPL user should be familiar with

"Training modules" for the 50g are available at

Other useful on-line resources for RPL models include
http://holyjoe.net/hobbies.htm (also
http://holyjoe.net/hp/types4.htm, and perhaps various other
files at http://holyjoe.net/hp/),
http://alaska.magpage.com/~jakes/, and

Each new RPL implementation is mostly a superset of the previous
implementation, and the documentation for earlier models is often
better, so don't ignore something just because it's written for a
different model; it may well apply to your model as well.

Take anything that you read with a grain of salt. If you want to
know how someone else (including an HP technical writer) thinks
something works, then read whatever information is available about
it; if you want to know for certain how it works, then experiment
for yourself.



James, what a wealth of knowledge, people, places, technical and non-technical things you share with us! Thank you for being so generous. Between this letter from you, the treatment you provided with the explanation for "COMPILED LOCAL VARIABLES," you recently gave me I feel that I have short-circuited a lot of work.

I will take your advice seriously and will be avoiding any development activities above UserRPL for some time, if not forever. Besides, I just had great response to a question about Lorentz transposes used in Relativaty, especially the advice from Plastics Guy. I expect to be too busy trying to derive them with my own differential equations and another summer project to design INPUT FORMS to work with photography.

Thanks again for your contributions,



I really didn't mean to discourage anyone from trying the "development languages", but trying them does mean that the calculator's memory should be backed up first, and extra care is needed, and yes, some study and sometimes experimentation is required, and you're still likely to occasionally crash your calculator and need to clear and restore memory, at least until you "get the hang of it". That said, you don't need to know or use every feature of SysRPL programming or every SysRPL command to write a useful SysRPL program, any more than you need to know or use every feature of UserRPL programming or every UserRPL command to write a useful UserRPL program.

I do recommend waiting until you're reasonably comfortable with UserRPL programming before venturing into SysRPL programming, but SysRPL really isn't all that much different from UserRPL.

A comparison of the source code for a UserRPL program and a SysRPL program that end up accomplishing the same thing, but the SysRPL program is much smaller (70 bytes versus 116.5 bytes) and faster (about 2.09 seconds versus about 6.30 seconds on a 49g+):

%%HP: T(3)A(D)F(.);
@ For 49 series only.
@ Arguments: None
@ Download or enter in exact mode.
@ Checksum: # A162h
@ Size: 116.5
128 255
" "
# 2F34Eh SYSEVAL @ KVIS for 49 series.
+ + + + + + +
"\010" +
%%HP: T(3)A(D)F(.);
@ For 49 series, MASD syntax.
@ Extable library required for compiling.
@ Arguments: None
@ Checksum of source code string: # 469Eh
@ Size of source code string: 280.
@ Checksum after compiling: # 7E4Fh
@ Size after compiling: 70.
Alternative source code for the same SysRPL program as above, but which doesn't require an extable library for compiling:
%%HP: T(3)A(D)F(.);
@ For 49 series, MASD syntax.
@ Extable library not required for compiling.
@ Arguments: None
@ Checksum of source code string: # E1C5h
@ Size of source code string: 337.
@ Checksum after compiling: # 7E4Fh
@ Size after compiling: 70.
PTR 26292
PTR 33B39
PTR 33733
PTR 33607
PTR 073F7
PTR 07221
PTR 03188
PTR 25F77
PTR 032C2
PTR 05193
PTR 03223
PTR 05A75
PTR 33B55
PTR 032C2
PTR 05193
PTR 05193
PTR 05193
PTR 05193
PTR 07334
To compile that last SysRPL source code string on any 49 series, even without an extable library installed or the development library attached, with the string in level 1, execute 256.06 MENU, and the press the menu key labelled ASM.

What that SysRPL program looks like as a string of hex digits, after compiling:


(Treat the above 2 lines as 1 long line.)

Saturn assembly language isn't too difficult either, although it seems to me that is has some "quirky" limitations on which registers can be used with each other and with which instructions, and using it tends to be tedious.

But UserRPL is quite powerful enough for most purposes, and when keeping development time low is important, seems the best of these languages for almost all users.

I recommend restricting "development language" programming to when you have some spare time to work on it.


Edited: 11 June 2007, 10:17 a.m.


I do recommend waiting until you're reasonably comfortable with UserRPL programming before venturing into SysRPL programming

That is where I am at right now, and I must admit that even the yellow-belt level is pretty gratifying.

I have recently developed an interest in writing routines for special functions that are not built into the calculator--the incomplete beta function, the incomplete gamma function, and the sine, cosine, exponential, and Fresnel integrals, to name a few. Right now, the code looks an awful lot like the C, Fortran, Pascal, or Basic templates I am cribbing from (be they from Numerical Recipes, Cephes, Netlib, or GSL, for example)--lots of local variables, for example, and the RPL equivalents of common operations in other languages. For example, the C statement "term *= fact/k" would appear in my program as "fact k / 'term' STO*" and "d = 1/d" would get rendered as "'d' SINV" -- that sort of thing. So far, I have produced a few neat little programs that give good results and run much more quickly than their RPN counterparts on the 41CX, 42S, or even the rather fast 33S.

My next goal is to develop an awareness of stack in order to write UserRPL routines that don't use a single local variable, but rather control the stack and manipulate it with PICK, ROLL, OVER, DROP, DUP, etc. to generate and track interim results. I expect such versions would be smaller in size and perhaps a little faster.

Then, if I ever have time, I will try to learn a thing or two about SysRPL.



My next goal is to develop an awareness of stack in order to write UserRPL routines that don't use a single local variable, but rather control the stack and manipulate it with PICK, ROLL, OVER, DROP, DUP, etc. to generate and track interim results. I expect such versions would be smaller in size and perhaps a little faster.

This is interesting, as you can see an eclecticism in the design of the 48 series: A pretty complete and very robust *structured* programming language, as well as a pseudo machine-code-line-interpreter stack-based paradigm. The former is easier to read, perhaps easier to debug, logical and pretty transferable as you demonstrated with your examples of "cribbing", whereas the latter seems to be an inescapable exercise in programming elan if nothing else.
One would think that the structured approach would win out and leave the stack concept behind, and yet there is something so versatile about the stack, and the genius of having both a stack and structured tools is what is to me the quintessential nature of the Champagnes and their offspring.


With the ARM-based models, it's possible to access the underlying
ARM processor, and indeed HPGCC has been developed for using C++
code with these calculators. That said, I've never experimented
with this.

I am not a C or C++ wiz, but I have downloaded HPGCC and will give it a try.

So far, I have been able to get the ARMToolbox successfully on my calculator. I have been able to "make" the examples that come with the installation and figured out how to convert, on the calculator, those files to native executables that run with a keypress so yo don't have to invoke the ARMToolbox PrRUN function.

There seem to be math libraries that carry out computations in double precision floating point. This is very intriguing to me--it seems possible to write math programs with increased accuracy.




I purchased one last week and spent the last several days playing with it's capabilities. I am comparing this to the 'classic' HP calculators, not the recent Kinpo mfg. models:


1. Build quality. Seems quite good. Solid, little case flex. Seems almost as rugged as the 48 series.

2. Keys. Good key color choices. Makes finding/differentiating functions easy. The keyboard is not too cluttered. Good key response. The arrow keys are a bit sloppy (you can wiggle them around) but otherwise all seems well built. While these keys have a good mechanical click they are not the same feel/response you will get from a 48-series machine. Still, all-in-all, pretty good!

3. Display. Better than the 48-series but can still be difficult to read in many lighting conditions.

4. Access to functions. I actually find the 50g easier to navigate around than the 48-series. For a time I was put off by the 'labrynthine' (is that a word?) 48gx menu structure. The 50g menu structure seems easier to work with and a bit more logical.

5. Expandability. I stuffed a cheap 1 gig SD card in mine and instantly had more storage space than I know what to do with.

6. Connectivity. USB, Serial and IR. Once I got the USB xmodem thing figured out everything went just fine. With the help of some forum members I was even able to get the calculator to talk to my old 82240B printer. Now I just wish there was a native 'trace' mode for printing...

7. Support. HP, on their website (www.hp.com/calculators) already has a wealth of special purpose tutorials that take you through some of the more complex functionality. I've only looked at a few, but they seem to be well structured and documented. There is also a 50g-specific forum on the HP website but it's not too well populated yet (most HP savvy folks seem to turn to the HPMuseum website for help).


1. Documentation. Folks in the HP calculator division need to be forced to read some of the classic HP calculator documentation (like for the 11C) to re-learn how to properly document a calculator. For example, there are two books that come with the 50g; the paper User's Manual and the User's Guide on CD. The paper User's Manual makes oblique references to the User's Guide but never explicitly states that the User's Guide is in PDF format on the CD. A first year technical writer could have done a better job with layout and content. Don't get me wrong - most of what you are looking for is in the User's Guide but all I can say is 'Thank heavens for the search feature in Acrobat Reader!'

2. Documentation

3. Documentation

(do you get the idea that I'm not too impressed with this calculator's documentation?)


.. (most HP savvy folks seem to turn to the HPMuseum website for help) ..

Actually, this site focuses on older HP calculators primarily. The real center for HP 50g support is the Usenet news group comp.sys.hp48 (link is to Google Groups.) As you have seen, you will probably get useful answers to HP50g questions here. But the folks who wrote the system software hang out on the news group, and they are backed up by an army of experienced RPL hackers.

I'm sure you're aware of it, but here's a link to Eric Rechlin's HPCalc.org. That site is the mother lode for RPL calculator knowledge and software.

The paper User's Manual makes oblique references to the User's Guide but never explicitly states that the User's Guide is in PDF format on the CD.

Also buried in the guide and manual are citations of the real manual, the HP-49G+ Advanced Users Reference (AUR)




Now I just wish there was a native 'trace' mode for printing...

In recent months I believe James Prange wrote one of his famously erudite and detailed posts on this very issue. He provided some RPL code which will emulate trace mode. Sorry I can't seem to find the archived post....



Thanks for the mention, Les.

For a way to implement user-customized print trace modes in the 48/49 series, see some of my posts in this thread.

The Museum Forum lacks a way to conveniently search all of its archives at once. A work-around is to use a Google advanced search, and for the "Domain" line, specify:

[Only] return results from the site or domain [hpmuseum.org]



A work-around is to use a Google advanced search, and for the "Domain" line, specify:
[Only] return results from the site or domain [hpmuseum.org]

Another way to get the same result without going to the advanced search is typing site:hpmuseum.org before the search key.




I stuffed a cheap 1 gig SD card in mine and instantly had more storage space than I know what to do with.

I have a 128MB card that was a throw in for a digital recorder. It holds only a few minutes of 96kHz WAV file stereo recording, and thus is pretty useless for serious use, so I got a 2GB card which accommodates an hour, and much more time in MPG formats. But the 128MB is positively huge as far as the 49G+ is concerned. And since I have a multimedia card reader on my PC, I can readily and quickly back up the card contents to my PC and not have to fuss with USB or serial connectivity.



Out of about 25 units sold I have problems with one. The thing kept burning out the batteries over 1-2 days. I even tried rechargeables. HP did change it though, without any problems. A couple surveyors actually prefer this over the 48 series, which amazes me though.


I know I feel kind of funny going into a meeting with my very portable 50g with the choice of 900 pages of printed documentation (2 volumes of 3-inch double sided paper,) or a laptop to read the pdf files. Kinda ruins the image you were trying to project about handy programming power in the field.

Have fun!


Possibly Related Threads...
Thread Author Replies Views Last Post
  Prime: how to detect date format giancarlo 1 601 12-02-2013, 11:21 AM
Last Post: Michael de Estrada
  Date/time formats R. Pienne 4 895 11-01-2013, 12:43 PM
Last Post: Marcus von Cube, Germany
  How to set the Date.Time etc on a WP34S Harold A Climer 4 847 10-29-2013, 09:32 PM
Last Post: FORTIN Pascal
  Date/time programs for the HP 35s R. Pienne 0 434 10-03-2013, 02:37 PM
Last Post: R. Pienne
  First experience with a slide rule aurelio 27 3,035 08-17-2013, 01:16 PM
Last Post: Garth Wilson
  Date & Time disappear on WP 34S René Franquinet 16 2,105 12-10-2012, 08:24 AM
Last Post: Walter B
  Estimating Accumulated Rounding Errors Egan Ford 13 1,371 08-16-2012, 01:49 PM
Last Post: Egan Ford
  A little OT: Blank date fields in 200LX database Dave Britten 1 538 07-12-2012, 06:11 PM
Last Post: Dave Britten
  HP SMB 15C LE ship date Scott Newell 9 995 12-17-2011, 11:25 PM
Last Post: Scott Newell
  38E/C, 12C, 12CP date arithmetic bug Katie Wasserman 26 2,127 10-19-2011, 08:57 PM
Last Post: Miguel Toro

Forum Jump: