HP48G, HP49G VS HP50G

[mike]

Hello my name is Miguel and I live in Portugal.
I have an HP48G and HP49G. I am thinking of buying the new HP50G, but first I wonder if HP will launch a new calculator? What are the main differences between the HP49G and HP50G? The keyboard is in rubber or is like the HP48G? The HP50G is better (software) than the HP49G? The CAS system is the same in both calculators? Thanks. Sorry my english.

[mnhol...@yahoo.com]

Hello Miguel,

Your English is better than some native speakers I know! The HP 50g is a fine calculator, and you should enjoy it immensely. The keys are an improvement over the HP 49g, but nothing to scream about. You can even adjust the sensitivity of the keys; something called key bounce. I suppose HP will launch a new calculator when it is profitable for them to do so. I know a bunch of people who use HP calculator emulators on their cell phones. Maybe that's the future of the HP calculator market.

Regards,

Mark

[Antti Louko]

I think the future could be _a good keyboard_, like HP41 one, connected
with BT (or similar) to a smart phone (Android, iPhone or even Windows
phone) or a pad. Keyboard, if built properly, would last many
generations of phones or pads.

I would gladly pay for a good keyboard.

[mike]

Thanks for the responses.
But I wonder if the "CAS" (Computer Algebra System ) and software of the HP50G is better than the HP49G (not +) or is just more fast. Thanks

[TW]

On Friday, October 26, 2012 3:17:15 AM UTC-6, mike wrote:
> Thanks for the responses.
>
> But I wonder if the "CAS" (Computer Algebra System ) and software of the HP50G is better than the HP49G (not +) or is just more fast. Thanks

There are some small changes and improvements, but overall it is essentially the same. Speed and the better keyboard are the primary improvements. Also, the black color scheme is much better then that horrible metallic blue thing...

TW

[John H Meyers]

On 10/24/2012 7:28 PM, mike wrote:

> The HP50G is better (software) than the HP49G?
> The CAS system is the same in both calculators?

The degree to which it is even completely identical
depends upon to what ROM version you update your 49G.

I have either ROM version 2.09 or 2.10 in each of my 49G,
in which case the "software difference" is only where
dictated by the hardware -- e.g. screen heights differ,
functions on a couple of keys are exchanged,
and the hardware clock and alarms work perfectly on each 49G,
which the clock and alarms do not, on any of the later models
which only emulate the original "Saturn" CPU.

If you have a much older ROM in your 49G,
you can update it using an emulated 49G
in Emu48 for Windows or similar emulator,
provided that you also have a serial 49G calculator cable
and either a serial port or reasonable facsimile
(e.g. USB to serial adapter with COM port driver) in the same computer,
which then acts as the serial port of the emulated calculator.

Having prepared the emulator, cable, adapter, and 49G,
and with ROM 2.09 or 2.10 in the computer's 49G emulator,
a ROMUPLOAD command in the emulator
will do what a ROMUPLOAD command did in a real 49G,
which is to act as a source for a ROM update to another 49G,
when connected via a serial cable (once even supplied with the 49G).

Even the very last ROM versions were compiled with internal tests
which discern on which hardware they are running,
and adapt themselves perfectly to any of the 49G, 49G+ or 50G
(e.g. even knowing about the function swaps on the keyboard),
although I haven't heard of a "final" ROM 2.15 file for
EMU48 or real 49G which doesn't wipe out the Emu48/49G "boot block"
for the sake of some data logger, thus also disabling the ROMUPLOAD command.

I had the impression that other than addition of the data logger command,
potential sales for which provided motivation for HP to offer ROM 2.15,
skipping 2.10 etc., there's otherwise no software difference
between ROMs 2.10 and 2.15, and that there are only very minor
bug fixes between 2.09 and 2.10 -- hasn't anyone yet persuaded HP
to let www.hpcalc.org, which does have "official" files for 2.09
(including for Emu48) post the 2.10 ROM file update (including for Emu48),
which HP declined to distribute way back when they were generated and
given to one remaining HP employee by another who was then an ex-employee?

What portion of the entire world's decision-making
do you suppose might be the result of such petty politics,
rather than to do "real and permanent good in this world,"
as was the wishful grand thought accompanying Andrew Carnegie's bequest:
<http://carnegie.org/publications/carnegie-reporter/single/view/article/item/270/>

All that stands in the way of dissolving all pettiness
is more opening of the fullness of pure consciousness,
which is my "Season's wish" to everyone.

http://mum.edu

-[ ]-

[Jim Dumas]

On Wed, 28 Nov 2012 05:33:30 -0600, John H Meyers wrote:

> which the clock
> and alarms do not, on any of the later models which only emulate the
> original "Saturn" CPU.

Just to say that on my 50g the clock and alarms are extremely important
for medicinal use. A list of insulin doses is kept with time stamp and
alarms are set based on an insulin transport model area under the curve.

The transport model is 5 simultaneous first order differential equations,
as an example (fifth order DE solved in closed-form for speed on the
48). The transport model moves the insulin molecules from the
subcutaneous injection site, through the plasma compartment and into the
interstitial fluid compartment where binding to target cell receptors
occurs. The AUC used to set alarms is for this binding profile where
insulin-receptor bound molecules are moved from the target cell surface
into the cytoplasm. (I'm an EE, BTW.)

In any case, I've had good success with the HP50g alarms using the
shotgun approach (double alarms) and with the Clock Adjust 3.0+ for the
49g+. The clock is updated every two days at 5am. The drift is about 1
second per day relative to NTP references. It does gain a little over a
month but it is easy to adjust without starting the calibration over.

So I'm starting to like the 50g with SD card for daily backups.
--
Jim Dumas
hp48sx->gx->50g Lib 849 DMIT Dynamic Mathematical Insulin Therapy
Lib 849 is unpublished work for liability reasons.
Email mangled: change SeeSig2Fix to mindspring SVP.

[Jim Dumas]

On Wed, 28 Nov 2012 08:46:44 -0600, Jim Dumas wrote:

> Just to say that on my 50g the clock and alarms are extremely important
> for medicinal use.

I should also mention that the 48gx with 1MB HP ram card (slot 2) and
128KB HP ram card in slot 1 was crashing once or twice a year. I had
backups in the 1MB ram card, but it would take about 15 minutes to get
all the data back online. The 50g seems more stable so far and with SD
card, very quick to restore after memory loss/corruption.

And I have an hpgcc3 modified ROM on three hp50g's.

[Travis Evans]

On Wed, 28 Nov 2012 09:22:08 -0600, Jim Dumas <j_d...@SeeSig2Fix.com> wrote:
> On Wed, 28 Nov 2012 08:46:44 -0600, Jim Dumas wrote:
>
>> Just to say that on my 50g the clock and alarms are extremely important
>> for medicinal use.
>
> I should also mention that the 48gx with 1MB HP ram card (slot 2) and
> 128KB HP ram card in slot 1 was crashing once or twice a year. I had
> backups in the 1MB ram card, but it would take about 15 minutes to get
> all the data back online. The 50g seems more stable so far and with SD
> card, very quick to restore after memory loss/corruption.

I wish my HP 50g would only crash once or twice a year. I don't know if
it's a hardware defect on my unit or related to the clock/alarm/OS-
related bugs (though I don't recall anyone talking about crashes), but
it intermittently hardlocks, usually, it seems, when the ticking clock
and header are not being displayed. Sometimes I can go a few months
without it happening, other times it can happen multiple times in a day.
It's been like that ever since I got it a few years back.

--
Travis

[Jim Dumas]

I can force the 50g into a hard lock that requires a paperclip reset.
But this was caused by turning the LCD off in an hpgcc3 C program for
encryption of password data. The idea was to prevent input data from
being seen while the ARM was working on encryption. But I decided to
overclock at 120MHz and now it's so fast the LCD can stay on.

These lcd_off() and lcd_on() seemed to be the culprit so I commented them
out in the code. The symptom was encryption/decryption of data, get the
password of interest, turn the calculator off manually. Then there
seemed to be a ~10 minute delay (guessing) before it would turn on
manually. The encrypt/decrypt zero fills buffers and then frees them so
there is no memory leak.

The symptom was hit the ON key and wait. It would finally turn on. Or
do a paperclip reset if impatient.

The ROM version is 2.15 dated 15 April 2009 w/hpgcc3 R004 mods.

[Jim Dumas]

On Wed, 28 Nov 2012 11:51:30 -0600, Jim Dumas wrote:

> The symptom was hit the ON key and wait. It would finally turn on. Or
> do a paperclip reset if impatient.

I should also say that this is not a crash. This reset preserves memory
so nothing is lost. A crash is corrupted ram when the calculator asks if
you want to recover memory. I usually say no and use a backup.

So crash needs clarification.

[Jim Dumas]

On Wed, 28 Nov 2012 17:10:34 +0000, Travis Evans wrote:

> intermittently hardlocks, usually, it seems, when the ticking clock and
> header are not being displayed.

Just to say that I have set up my third 50g to simulate your hard locks
with the ticking display off. This third 50 was for crashing C code, so
nothing important on it. It does a daily clock adjust at 5am that has
worked fine to date. But a two line header is still on.

So will see if typical use will lock it up (no C code of course).

[Travis Evans]

On Wed, 28 Nov 2012 12:02:10 -0600, Jim Dumas <j_d...@SeeSig2Fix.com> wrote:
> On Wed, 28 Nov 2012 11:51:30 -0600, Jim Dumas wrote:
>
>> The symptom was hit the ON key and wait. It would finally turn on. Or
>> do a paperclip reset if impatient.
>
> I should also say that this is not a crash. This reset preserves memory
> so nothing is lost. A crash is corrupted ram when the calculator asks if
> you want to recover memory. I usually say no and use a backup.
>
> So crash needs clarification.

In my case, then, it's really just a hardlock. I can pull one of the
main batteries and put it back in [finding a paperclip is too much of a
hassle :-) ] and RAM is always intact. But it still results in data
loss if I was working on something in the editor or the stack. I've had
to get into the habit of keeping my editing sessions less than a few
minutes at a time.

I haven't been able to find much of a pattern. Usually when it happens,
I'll do something like enter an editor or display a choose box, set the
calculator down for a minute, pick it back up and it's frozen.

--
Travis

[Travis Evans]

Just to add more information, this type of hardlock I experience is such
that [ON]+... combinations aren't responded to. It requires a battery
pull or paperclip reset.

--
Travis

[Jacob Wall]

Travis, sounds like it could be corrupt memory, possibly corrupt
variables in the hidden directory used by the OS. You shouldn't see
regular freeze-ups. Although I suppose there is a possibility that it
is hardware related I highly doubt it. I have seen similar situations
also and it can usually be corrected by a hard reset with ON+A+F, then
choose NO to TTRM.

A ARCHIVE and RESTORE around a ON+A+F will not correct this because the
corrupt files would be copied right back with the RESTORE, but of course
you will not want to lose your user variables in HOME so you will need
to copy those to Port 2 or the SD card prior to ON+A+F.

I have a program that I wrote to do this using the SD card, it's System
RPL, the Debug4x source is below. You could compile and store it in
Port 2 to run it from there, or I can email you a binary if you like.
Of course you could just copy all contents from HOME to Port 2, perform
ON+A+F, then move all the objects previously copied to Port 2 back to HOME.

::
"ATTEMPT DATA RECOVERY\1F"
{
{
"Step 1: Backup"
ONE
}
{
"Step 2: Restore"
TWO
}
}
FLASHPTR RunChooseSimple
NOT?SEMI
#1=case
::
HOMEDIR
xVARS
DUPNULL{}?
case
::
DROP
"Error: Nothing to Backup"
FlashWarning
;
' ID dirTEMP
CREATEDIR
toLEN_DO (DO)
DUPINDEX@
NTHCOMPDROP
DUP
@
DROP
SWAPDUP
PURGE
ID dirTEMP
STO
HOMEDIR
LOOP
DROP
ID dirTEMP
xRCLF
' ID tempFLAGS
STO
HOMEDIR
' ID dirTEMP
@
DROP
TAG 3
ID dirTEMP
DUP
xPURGE
xSTO
FALSE
"Next hold down\0AON+A+F keys\0Ato reset your\0Acalculator
to\0Afactory state.\0A\0AThen run Step 2."
$>GROBCR
ViewGrobObject
DROP
;
HOMEDIR
ERRSET
::
TAG 3
ID dirTEMP
xRCL
TRUE
;
ERRTRAP
::
"Error: Run Step 1 first!"
FlashWarning
FALSE
;
NOT?SEMI
' ID dirTEMP
xSTO
ID dirTEMP
xVARS
toLEN_DO (DO)
DUPINDEX@
NTHCOMPDROP
DUP
@
DROP
SWAPDUP
PURGE
HOMEDIR
STO
ID dirTEMP
LOOP
DROP
HOMEDIR
' ID dirTEMP
XEQPGDIR
ID tempFLAGS
xSTOF
' ID tempFLAGS
PURGE
TAG 3
ID dirTEMP
xPURGE
"Recovery Complete!"
FlashWarning
;

Jacob

[Jim Dumas]

On Thu, 29 Nov 2012 17:42:37 +0000, Travis Evans wrote:

> But it still results in data
>> loss if I was working on something in the editor or the stack.

Hi Travis,

Just to say that I have my "test" 50g in RPN mode with a program on the
stack being edited. On the 48, when an alarm fires it would trash the
editing on the stack. This "test" 50g adjusts the clock every day at
5am. So I expect trouble then.

I'm also very careful with hidden directories. I used a hidden
subdirectory from my 48sx days that gave me some trouble on the 48gx. So
I stopped using it. It was supposed to backup data.

But so far no lock-ups with a two line header w/o ticking clock.

[Travis Evans]

On Thu, 29 Nov 2012 17:43:22 -0800, Jacob Wall <jac...@surv50.ca> wrote:
> Travis, sounds like it could be corrupt memory, possibly corrupt
> variables in the hidden directory used by the OS. You shouldn't see
> regular freeze-ups. Although I suppose there is a possibility that it
> is hardware related I highly doubt it. I have seen similar situations
> also and it can usually be corrected by a hard reset with ON+A+F, then
> choose NO to TTRM.

Well, I have gone through a couple of ON+A+F cycles and manual rebuilds
from time to time in the past due to subtle (and apparently difficult to
detect!) filesystem corruption that had occurred while I was developing
SysRPL software, including starting again with a fresh hidden directory,
but this doesn't appear to have changed the symptoms.

Recently, I encountered a particularly odd one where crashes would occur
when manipulating variables below one particular one in the Home root
directory, yet neither copying the directory to the stack and
decompiling it, nor recalling any of the variables showed anything odd,
and copying it to any other location and messing with it there didn't
seem to cause anything strange. In the meantime I had found some other
corrupted data that had apparently gone unnoticed for quite some time.
I solved all of this by fishing out good copies from my old backups and
manually repopulating part of the directory structure.

So I *think* everything is fine now. I can ORDER everything in Home
without crashes (I now run this test regularly and keep an eye out for
weird stuff like variables turning into "PTR 00000"s and such hoping to
catch any corruption earlier in the future). I don't suppose there's
some kind of comprehensive "fsck" or "chkdisk"-type tool for verifying
RAM filesystem and variable intergrity for certain, is there?

--
Travis

[John H Meyers]

On 11/30/2012 5:26 PM, Travis Evans [at TIcalc?] wrote:

> Well, I have gone through a couple of ON+A+F cycles and manual rebuilds
> from time to time in the past due to subtle (and apparently difficult to
> detect!) filesystem corruption that had occurred while I was developing
> SysRPL software, including starting again with a fresh hidden directory,
> but this doesn't appear to have changed the symptoms.

I seem to recall that the "recover memory" procedure (after ON+A+F)
originally (in my HP48G/GX) seemed to find and check all user variables
and delete only those which were clearly corrupt (in addition to wiping out
alarms and/or user key definitions, or perhaps everything
in the normal "hidden" directory at the end of HOME)

I also seem to recall that in my HP49/50,
"recover memory" was more inclined to never terminate
(or perhaps it "locked up"), and became much less useful
as a reasonably safe way to simply make sure that user memory was intact.

I used to count and add up the lengths of all variables in HOME (via BYTES)
to test whether anything was lost during "recover memory,"
the usual result being that any _extra_ null-named (and thus "hidden")
variables were removed, along with the original null-named "system"
hidden directory, and all other user variables survived intact, but again,
this seemed much more reliable in HP48 series than in HP49/50 series.

[r->] [OFF]

[John H Meyers]

On 11/30/2012 4:59 PM, Jim Dumas wrote:

> Just to say that I have my "test" 50g in RPN mode with a program on the
> stack being edited. On the 48, when an alarm fires it would trash the
> editing on the stack. This "test" 50g adjusts the clock every day at
> 5am. So I expect trouble then.

IIRC, "Control" alarms do not allow a running program to finish,
will also interrupt editing,
and may leave #DFFh as the value which a subsequent ERRN will return,
thus acting more or less like an asynchronous #DFFh DOERR
occurring just before the "alarm" function.

I don't seem to recall whether you can use a test for that
in your alarm function to determine whether the alarm did
kill something, nor whether you can do much about it if so.

> I'm also very careful with hidden directories. I used a hidden
> subdirectory from my 48sx days that gave me some trouble on the 48gx.
> So I stopped using it. It was supposed to back up data.

Do you recall the name of any associated program or library?

I seem to recall some very old program
which assumed that evaluating a null name
would always go to the system hidden directory,
or perhaps to a null-named variable which the program creates
for itself, which could go awry
whenever a user employed other "variable hiders,"
particularly if a null-named non-directory was sometimes used.

[r->] [OFF]

[Jacob Wall]

> Recently, I encountered a particularly odd one where crashes would occur
>
> when manipulating variables below one particular one in the Home root
>
> directory, yet neither copying the directory to the stack and
>
> decompiling it, nor recalling any of the variables showed anything odd,
>
> and copying it to any other location and messing with it there didn't
>
> seem to cause anything strange. In the meantime I had found some other
>
> corrupted data that had apparently gone unnoticed for quite some time.
>
> I solved all of this by fishing out good copies from my old backups and
>
> manually repopulating part of the directory structure.
>
>
>
> So I *think* everything is fine now. I can ORDER everything in Home
>
> without crashes (I now run this test regularly and keep an eye out for
>
> weird stuff like variables turning into "PTR 00000"s and such hoping to
>
> catch any corruption earlier in the future). I don't suppose there's
>
> some kind of comprehensive "fsck" or "chkdisk"-type tool for verifying
>
> RAM filesystem and variable intergrity for certain, is there?
>
>
>
> --
>
> Travis

System RPL can be a dangerous sport, I have many times corrupted memory during testing, etc. another reason I love Debug4x and Emu48+ for development.

The program I posted "might" be possible to enhance to only backup non-corrupt objects to the SD card. This would require more work, ie. inspecting each object within each directory and not treating directories as an object to backup. I have myself wondered if there was a chkdsk like utility to try and fix errors but definitely have never heard of such a thing. I haven't tested specifically, but I'm 99% sure xVARS will include names of corrupt variables. If there was a way to create a list of all the objects that are not corrupt, then a slightly modified version of my program could easily be used to flush out corrupt variables.

Anybody aware of a way to check the integrity of a variable without locking the calculator up on a corrupt object? Sometimes the names of corrupt variables contain null characters, have seen that from time to time, but not sure if that is always the case... I know I have a corrupt backup somewhere, maybe time to experiment.

Jacob

[robi...@gmail.com]

On Thursday, 25 October 2012 01:28:37 UTC+1, mike wrote:
> Hello my name is Miguel and I live in Portugal.
>
> I have an HP48G and HP49G. I am thinking of buying the new HP50G, but first I wonder if HP will launch a new calculator? What are the main differences between the HP49G and HP50G? The keyboard is in rubber or is like the HP48G? The HP50G is better (software) than the HP49G? The CAS system is the same in both calculators? Thanks. Sorry my english.

dunno I got a HP50G and all the buttons were in different places. v annoying