Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Program to parse HEX into data words

39 views
Skip to first unread message

Mal

unread,
Mar 23, 2008, 2:17:55 PM3/23/08
to
I have a 35s and 48g. Can they--or any currently available HP--parse
data words? What I want to do is write a simple program that will take
a transfer off of a 64-bit bus in HEX, convert it to binary, slice it
into 18-bit words (don't ask, not my decision), then convert it back
to binary and place it on the stack. So, for a 64-bit bus it would be
three 18-bit words and one partial word all on the stack in X,Y,Z, and
T. Thanks.

Joe Horn

unread,
Mar 23, 2008, 10:17:16 PM3/23/08
to

Both machines could do that, but my guess is that it'd be a lot faster
and easier to do it on a 48g. If you could give us an example input
and the expected outputs, we could give you several workable
solutions.

-Joe-

Mal

unread,
Mar 24, 2008, 12:18:56 AM3/24/08
to

Great. Thanks. Okay, so for example say you had the HEX number...

0xB5D94F2C4E65C8E2

That would be equal to the BIN number split into 18-bit words...

1011010111 011001010011110010 110001001110011001 011100100011100010

Broken into words on the stack would be (least significant word in X
register)...

1011010111 (T) (this is the "chunk" left over)
011001010011110010 (Z)
110001001110011001 (Y)
011100100011100010 (X)

And then back to HEX...

2D7 (T)
194F2 (Z)
31399 (Y)
1C8E2 (X)

I hope that was clear enough. I apologize if messed up somewhere along
the way in that example. It's a chore doing one parse by hand let
alone thousands over the course of troubleshooting a chip design.
Thanks.

data...@gmail.com

unread,
Mar 24, 2008, 3:29:55 AM3/24/08
to
> Great. Thanks. Okay, so for example say you had the HEX number...
>
> 0xB5D94F2C4E65C8E2
>
> That would be equal to the BIN number split into 18-bit words...
>
> 1011010111 011001010011110010 110001001110011001 011100100011100010
>
> Broken into words on the stack would be (least significant word in X
> register)...
>
> 1011010111 (T) (this is the "chunk" left over)
> 011001010011110010 (Z)
> 110001001110011001 (Y)
> 011100100011100010 (X)
>
> And then back to HEX...
>
> 2D7 (T)
> 194F2 (Z)
> 31399 (Y)
> 1C8E2 (X)
>
> I hope that was clear enough. I apologize if messed up somewhere along
> the way in that example. It's a chore doing one parse by hand let
> alone thousands over the course of troubleshooting a chip design.
> Thanks.

Here is a way that could be ported to the 35s, but the 35s cannot take
very long inputs:

%%HP: T(3)A(R)F(.);
\<< 0 \-> n e
\<<
WHILE n B\->R
REPEAT
n #3FFFFh AND
n #40000h / 'n' STO
'e' INCR DROP
END
e \->LIST
REVLIST
OBJ\->
DROP
\>>
\>>

data...@gmail.com

unread,
Mar 24, 2008, 3:36:41 AM3/24/08
to
Here is a better version:

%%HP: T(3)A(R)F(.);
\<< 0 \-> n e
\<<
WHILE n B\->R
REPEAT
n #3FFFFh AND
n #40000h / 'n' STO

'e' INCR ROLLD
END
\>>
\>>

Wes

unread,
Mar 24, 2008, 6:58:47 AM3/24/08
to
On Mar 24, 7:18 am, Mal <malliga...@gmail.com> wrote:

> Great. Thanks. Okay, so for example say you had the HEX number...
>
> 0xB5D94F2C4E65C8E2
>
> That would be equal to the BIN number split into 18-bit words...
>
> 1011010111 011001010011110010 110001001110011001 011100100011100010
>
> Broken into words on the stack would be (least significant word in X
> register)...
>
> 1011010111 (T) (this is the "chunk" left over)
> 011001010011110010 (Z)
> 110001001110011001 (Y)
> 011100100011100010 (X)
>
> And then back to HEX...
>
> 2D7 (T)
> 194F2 (Z)
> 31399 (Y)
> 1C8E2 (X)
>
> I hope that was clear enough. I apologize if messed up somewhere along
> the way in that example. It's a chore doing one parse by hand let
> alone thousands over the course of troubleshooting a chip design.
> Thanks.


Here a 48 program that I think will do what you want.

<<
-> x
<<
@ most sig chunk (10 bits)
@ shift right 54 bits
x 1. 6. START SRB SR NEXT

@ 2nd most sig chunk (18 bits)
@ shift right 36 bits
x 1. 4. START SRB SR NEXT
@ keep 18 bits
# 3FFFFh AND

@ 3rd most sig chunk (18 bits)
@ shift right 18 bits
x SRB SR SRB SR
@ keep 18 bits
# 3FFFFh AND

@ least sig chunk (18 bits)
@ keep 18 bits
x
# 3FFFFh AND
>>
>>

Or if you prefer a smaller stack based program

<<
@ chunks
@ 4321
DUP @ 4321 4321
RLB RL RL @ 4321 3214
DUP @ 4321 3214 3214
#3FFh AND @ 4321 3214 4
SWAP @ 4321 4 3214
RLB RLB RL RL @ 4321 4 2143
#3FFFFh AND @ 4321 4 3
ROT @ 4 3 4321
DUP @ 4 3 4321 4321
SRB SRB SR SR @ 4 3 4321 432
#3FFFFh AND @ 4 3 4321 2
SWAP @ 4 3 2 4321
#3FFFFh AND @ 4 3 2 1
>>

Both programs assume a word size of 64.
-wes

Mal

unread,
Mar 24, 2008, 9:23:27 AM3/24/08
to

You all have been a great help. I really appreciate it. I believe I've
underestimated the complexity and usefulness of programming HP
calculators. Thanks again.

Wes

unread,
Mar 24, 2008, 9:29:48 AM3/24/08
to
or taking the best ideas from both programs, weighing in at 83 bytes
on the 48 emulator:

%%HP: T(3)A(D)F(.);
\<<
RLB RL RL # 3FFh
1. 3. START
OVER AND SWAP
RLB RLB RL RL
# 3FFFFh
NEXT
AND
\>>

-wes

Mal

unread,
Mar 24, 2008, 11:14:52 AM3/24/08
to

I can somewhat decipher most of the lines, but the first is really
throwing me. Could someone explain %%HP: T(3)A(D)F(.);? Does that line
manipulate flags? Thanks.

Wes

unread,
Mar 24, 2008, 2:48:54 PM3/24/08
to
On Mar 24, 6:14 pm, Mal <malliga...@gmail.com> wrote:
> > %%HP: T(3)A(D)F(.);

>
> I can somewhat decipher most of the lines, but the first is really
> throwing me. Could someone explain %%HP: T(3)A(D)F(.);? Does that line
> manipulate flags? Thanks.

Sorry about that. If you're keying in the program by hand, just
ignore that line. It's a header for when you are transferring the
program to the calculator. On my 50g, I can still transfer without
this header, but then it asks me if the file is text or binary. I
confused the issue even more by using a 50g header, which I'm guessing
is probably different from the 48 header. Just leave it out.

Here's a line by line description of what the program is doing.

\<< @ starts off with binary in the form: 4321
@ most significant chunk has only 10 bits
RLB RL RL @ 3214 (rotates 8+1+1=10 bits)
# 3FFh @ 3214 mask
1 3 START @ repeat loop 3 times
OVER @ 3214 mask 3214
AND @ 3214 4
SWAP @ 4 3214
RLB RLB RL RL @ 4 2143 (rotates 8+8+1+1=18 bits)
# 3FFFFh @ 4 2143 mask (ready to repeat loop)
NEXT @ 4 3 2 4321 mask (after all 3 loops)


AND @ 4 3 2 1

\>>

-wes

John H Meyers

unread,
Mar 24, 2008, 6:24:03 PM3/24/08
to
On Mon, 24 Mar 2008 13:48:54 -0500, Wes wrote:

Re: %%HP: T(3)A(D)F(.);

> 50g header, which I'm guessing
> is probably different from the 48 header.

Nothing different about "ascii mode" (program as text) transfer header,
since program text language is the same across entire 48/49/50 series.

T(3) "Translation mode 3" ("\<<" and "\>>" as program delimiters, etc.)
A(D) "Angles in degrees" (affects only vectors expressed as polar coordinates)
F(.) "Fraction mark" (a/k/a the "decimal point" display character in real numbers)

For F(.) the "argument separator" in algebraic/complex expressions is ","
For F(,) the "argument separator" in algebraic/complex expressions is ";"

The [.] and [,] keystrokes automatically generate the correct pair
of characters, according to the "Fraction mark" flag (-51) setting.

"Exact" vs "Approximate" mode for HP49/50 series was never included.

Binary object headers are
"HPHP48-x" (48S[X]/48G[X][+]) vs. "HPHP49-x" (49/50/etc. series)
indicating non-compatibility of binary objects between series.

[r->] [OFF]

Wes

unread,
Mar 26, 2008, 3:34:19 AM3/26/08
to
On Mar 25, 1:24 am, "John H Meyers" <jhmey...@nomail.invalid> wrote:
> On Mon, 24 Mar 2008 13:48:54 -0500, Wes wrote:
>
> Re: %%HP: T(3)A(D)F(.);
>
> > 50g header, which I'm guessing
> > is probably different from the 48 header.
>
> Nothing different about "ascii mode" (program as text) transfer header,
> since program text language is the same across entire 48/49/50 series.
>
> T(3) "Translation mode 3" ("\<<" and "\>>" as program delimiters, etc.)
> A(D) "Angles in degrees" (affects only vectors expressed as polar coordinates)
> F(.) "Fraction mark" (a/k/a the "decimal point" display character in real numbers)

Thanks. That's good to know. All this time I thought it was
something much more complex. I guess I should stop guessing in
public.

> "Exact" vs "Approximate" mode for HP49/50 series was never included.

That, and the fact that different models have different commands
available (as per Bill Markwick's list). Two previous attempts at
the small program I posted were rejected when I tried it on 48
emulator because I had used NIP and UNROT.

By the way, back on May 17, 2001, John had a detailed post explaining
this header issue even further. Worth the read.
http://groups.google.com/group/comp.sys.hp48/browse_frm/thread/32f48652f35df82c/6f01f0c397daec84


-wes

John H Meyers

unread,
Mar 27, 2008, 5:17:17 PM3/27/08
to
On Wed, 26 Mar 2008 02:34:19 -0500, Wes wrote:

> different models have different commands available...


> Two previous attempts at the small program I posted were rejected
> when I tried it on 48 emulator because I had used NIP and UNROT.

NIP and UNROT will compile to "global names," on HP48,
so that if you have small programs named 'NIP' and 'UNROT'
in your HOME directory,
doing what those commands would do in the 49/50 series,
then programs using those newer UserRPL commands
will work on the HP48 the same as they would on later models.

A set of small programs which handle various common
new 49/50 series commands is posted here:

"UserRPL commands from 49/50 for 48[S/G]"
http://groups.google.com/group/comp.sys.hp48/msg/b966a46c7ad0ad34

Commands included, with UserRPL versions for all,
and alternate SysRPL versions for the six "stack" commands:

NIP, DUPDUP, UNROT, PICK3, UNPICK, NDUPN, I\->R, R\->I, AXM, AXL

Once these are installed in an HP48,
many more HP49/50 series UserRPL programs in "text" form
will then function identically on the HP48, without modification.

[r->] [OFF]

0 new messages