Program to parse HEX into data words - Hewlett Packard

This is a discussion on Program to parse HEX into data words - Hewlett Packard ; 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, ...

+ Reply to Thread
Results 1 to 13 of 13

Thread: Program to parse HEX into data words

  1. Program to parse HEX into data words

    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.

  2. Re: Program to parse HEX into data words

    > 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.


    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-

  3. Re: Program to parse HEX into data words

    On Mar 23, 10:17*pm, Joe Horn wrote:
    > > 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.

    >
    > 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-


    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.

  4. Re: Program to parse HEX into data words

    > 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
    \>>
    \>>


  5. Re: Program to parse HEX into data words

    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
    \>>
    \>>


  6. Re: Program to parse HEX into data words

    On Mar 24, 7:18 am, Mal 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

  7. Re: Program to parse HEX into data words

    On Mar 24, 6:58*am, Wes wrote:
    > On Mar 24, 7:18 am, Mal 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


    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.

  8. Re: Program to parse HEX into data words

    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

  9. Re: Program to parse HEX into data words

    On Mar 24, 9:29 am, Wes wrote:
    > 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


    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.

  10. Re: Program to parse HEX into data words

    On Mar 24, 6:14 pm, Mal 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

  11. Re: File transfer headers

    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]

  12. Re: File transfer headers

    On Mar 25, 1:24 am, "John H Meyers" 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....01f0c397daec84


    -wes

  13. Re: File transfer headers and 49G/50G new commands for HP48

    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....66a46c7ad0ad34

    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]

+ Reply to Thread