48GX (R) & 48G AURM 4th Ed. erratta
#1

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.

#2

Hello,

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 www.hpcalc.org

Regards

Raymond

#3

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.

#4

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

[VPN]

#5

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.

sbirdasn.



Possibly Related Threads…
Thread Author Replies Views Last Post
  OT: Limited Ed. Egan Ford 16 3,822 09-09-2011, 04:28 PM
Last Post: Howard Owen
  Happy 4th. of Jully, folks! Vieira, Luiz C. (Brazil) 31 6,494 07-08-2010, 11:42 AM
Last Post: Walter B
  OT: Ed Roberts obituary Ken Shaw 1 903 04-29-2010, 12:26 AM
Last Post: Thomas Chrapkiewicz
  Ed Roberts: 1941 - 2010 Thomas Chrapkiewicz 0 606 04-02-2010, 09:06 AM
Last Post: Thomas Chrapkiewicz
  Need to contact Ed Austin Giovanni Jimenez 0 658 09-05-2009, 01:27 PM
Last Post: Giovanni Jimenez
  Op-Amp Gain and Offset Design for the HP-67 Stefan Vorkoetter 6 2,096 12-05-2008, 10:57 AM
Last Post: Tom Mathes
  AMP Rom for 71b PeterP 5 1,885 12-06-2007, 02:20 PM
Last Post: PeterP
  HP 48GX and 48SX and 48G and 48S and 48G+ Mad Dog ebaycalcnut 2 1,175 04-17-2007, 08:55 PM
Last Post: James M. Prange (Michigan)
  48G vs 48GX Black LCD vs 50G display Hal Bitton in Boise 8 2,087 09-14-2006, 02:20 AM
Last Post: Walter B
  hp-48 AURM editions? Bruce Bergman 1 722 09-14-2006, 01:35 AM
Last Post: sbirdasn

Forum Jump: