The Museum of HP Calculators

HP Forum Archive 14

[ Return to Index | Top of Index ]

48GX (R) & 48G AURM 4th Ed. erratta
Message #1 Posted by sbirdasn on 17 Mar 2005, 6:05 p.m.

In the interests of learning more about my 48GX (Rev. R firmware), I've been reading my Advanced User's Reference book from cover to cover (Reads like a dictionary, strange plot... ;) ).

Anyway, several program examples obviously don't work as shown, for various reasons like missing stack arguments, etc. Fine. I can figure out the missing thing and get them to work.

Even the program mode grob entry was figured out (e.g. GXOR example- pg. 3-135), though nowhere in the entire set of manuals is there an explanation of "x" between the grob size values being *inserted* during processing to push it onto the stack (but don't type the "x" yourself, but you see it when you view/edit the program object later though).

But, for my version "R" firmware, the RCLF (pg. 3-262-3) & STOF (3-327-8) commands don't seem to care about the current wordsize as the text would have you believe.

Try this:

HEX @ show integers in hexadecimal @

-64 SF 64 SF 32 STWS @ set sys & user flg 64, set w size 32 @

RCLF @ system & user flags list on stack @

You will see that the user flag portion does not display on the stack/view/edit modes as having sys & user flags 64 set.

Save the flags list object if you want to continue to test with them later...

Now change word size to 64 then back to 32 to verify that the sys/user flags 64 is still inside the object, but is simply not being displayed when smaller word sizes are set.

Next, do the following (w/ orig flag list on level 1):

32 STWS 64 CF @ set word to 32 (if reqd), clear UF 64 @

STOF @ my calc writes *all* flag bits, man says clears upper ones @

RCLF RCWS 64 SF? -64 SF? @ See what happened... @

Manual says that upper bits above the word size will be cleared, but the STOF writes all bits, regardless of word size. My 48GX now has both system and user flags 64 set, with the word size at 32-bits.

The behavior I describe seems more correct, as you can do in a single step saving/restoring the system flag states without having to remember the original word size separately. (Like RCWS 64 STWS RCLF 2 PICK STWS to get full set without disturbing things, but you will still need original word size to restore things fully again if the manual was right.)

So, when did system flag handling change? Or has it always been this way? This seems like a pretty substantial difference in behavior, if you ask me.

Now, I don't expect this to work if I start manipulating the objects with bitwise operations when the word size is less than 64.

Oh, and they neglect to tell you that word size bits are encoded as (wordsize - 1) i.e. 1 STWS => flag bits 000000b, 64 STWS => flag bits 111111b (Brings up the old 16C's word size = 1 becoming so inarticulate that you use setting word size = 0 to get it back to maximum word size again...)

Any other real howlers you've found?

Anthony Naef.

Re: 48GX (R) & 48G AURM 4th Ed. erratta
Message #2 Posted by Raymond Del Tondo on 17 Mar 2005, 6:56 p.m.,
in response to message #1 by sbirdasn


thanks for the info on the AUR errata.

For the wordsize: You could check it
with Emu48 and an older ROM file.
Both should be available on



Re: 48GX (R) & 48G AURM 4th Ed. erratta
Message #3 Posted by sbirdasn on 17 Mar 2005, 10:05 p.m.,
in response to message #2 by Raymond Del Tondo

True, but *I* don't own any older firmware rev. 48's, so there is that sticky bit about copyright. I know that it's a minor technicality in a discontinued line no longer supported by HP-- Still, I'm one for standing on principle whenever I can.

Besides, I'm still interested in knowing if anyone else has noticed this thing before as well.

Re: 48GX (R) & 48G AURM 4th Ed. erratta
Message #4 Posted by VPN on 18 Mar 2005, 2:33 a.m.,
in response to message #3 by sbirdasn

I think it's NOT a bug, but a safeguard!

Re: 48GX (R) & 48G AURM 4th Ed. erratta
Message #5 Posted by sbirdasn on 18 Mar 2005, 3:02 a.m.,
in response to message #4 by VPN

I agree that it's *not* a "bug" either. That's why I didn't use that term in my analysis. But it is a discrepancy between the documentation and the real product. By erratta, I was allowing for the discrepancy to be in either the manual or the device, or even both. The real behavior in my 48GX-(R) makes much more sense than the behavior described in the programmer's reference.

I'm more curious about if it changed somewhere in the 48 evolution itself or between the 28 -> 48 porting process.

The point being, someone at HP writing the manual went to a lot of trouble to describe what they *thought* was supposed to happen, but that's not what I'm seeing in real world on real hardware. That being said, the 48G AURM went through *four* revisions in rapid succession (1.5 yrs). That is a sure sign that things were thrown together in a hurry or munged from some previous document(s) with little time/resources for proper editorial oversight and cross-checking.


[ Return to Index | Top of Index ]

Go back to the main exhibit hall