Problem with ::N, {}N and ->LIST and any composite building - Hewlett Packard

This is a discussion on Problem with ::N, {}N and ->LIST and any composite building - Hewlett Packard ; Actually, could be said as a problem with COMPN_ as called in extable 2 which all of those use. I discovered this when making a small program to put a custom menu into the matrix writer. I pulled out the ...

+ Reply to Thread
Results 1 to 13 of 13

Thread: Problem with ::N, {}N and ->LIST and any composite building

  1. Problem with ::N, {}N and ->LIST and any composite building

    Actually, could be said as a problem with COMPN_ as called in extable
    2 which all of those use. I discovered this when making a small
    program to put a custom menu into the matrix writer. I pulled out the
    flashpointer code, and replaced the relevant parts using ::N to
    rebuilt things. I discovered that one or two of the higher pointers
    were changed after using ::N

    As an example, take a look at this

    ::
    '
    PTR 6FBC5
    BINT1
    ::N
    '
    PTR 6FBC6
    BINT1
    ::N
    '
    PTR 6FBC7
    BINT1
    ::N
    ;

    Results in:

    :: PTR 1E431 ; :: PTR B1E43 ; :: PTR 2B1E4 ;


    I haven't had time to look into what is happening behind the scenes
    and thought I'd post this to see if this was a known issue or if this
    was expected behavior for some strange reason.

    TW

  2. Re: Problem with ::N, {}N and ->LIST and any composite building

    On Oct 6, 2:30*pm, "Veli-Pekka Nousiainen"
    wrote:
    > on my real HP 50g + extable2
    > ASM


    Then EVAL the resulting program to get 3 programs on the stack as a
    result.

    TW


  3. Re: Problem with ::N, {}N and ->LIST and any composite building

    on my real HP 50g + extable2
    ASM
    then
    ->S2
    gives back the same text
    excluding
    !NO CODE
    !RPL
    which I added to the beginning as a test
    I repeated the test without those two lines
    and yet again no change in the code
    are you using debug4x ?
    and emulator ?

    "TW" wrote in message
    news:90502b85-ebc3-4075-901f-3aa320da8f97@n33g2000pri.googlegroups.com...
    > Actually, could be said as a problem with COMPN_ as called in extable
    > 2 which all of those use. I discovered this when making a small
    > program to put a custom menu into the matrix writer. I pulled out the
    > flashpointer code, and replaced the relevant parts using ::N to
    > rebuilt things. I discovered that one or two of the higher pointers
    > were changed after using ::N
    >
    > As an example, take a look at this
    >
    > ::
    > '
    > PTR 6FBC5
    > BINT1
    > ::N
    > '
    > PTR 6FBC6
    > BINT1
    > ::N
    > '
    > PTR 6FBC7
    > BINT1
    > ::N
    > ;
    >
    > Results in:
    >
    > :: PTR 1E431 ; :: PTR B1E43 ; :: PTR 2B1E4 ;
    >
    >
    > I haven't had time to look into what is happening behind the scenes
    > and thought I'd post this to see if this was a known issue or if this
    > was expected behavior for some strange reason.
    >
    > TW




  4. Re: Problem with ::N, {}N and ->LIST and any composite building

    using SysRPL Stack display

    :: PTR 3DBC0 ;
    :: #+ ;
    :: PTR B03DB ;

    I verified with ->S2

    ?????

    "TW" wrote in message
    news:c71cb0b3-3d2a-4fc4-968c-4a26199ed7b4@a3g2000prm.googlegroups.com...
    On Oct 6, 2:30 pm, "Veli-Pekka Nousiainen"
    wrote:
    > on my real HP 50g + extable2
    > ASM


    Then EVAL the resulting program to get 3 programs on the stack as a
    result.

    TW



  5. Re: Problem with ::N, {}N and ->LIST and any composite building

    The problem is what results when you _run_ the program;
    HP48 gives the results expected, while HP49/50 does not.

    [r->] [OFF]

  6. Re: Problem with ::N, {}N and ->LIST and any composite building

    Hello Tim,

    > I haven't had time to look into what is happening behind the
    > scenes and thought I'd post this to see if this was a known
    > issue or if this was expected behavior for some strange reason.


    This happens for all pointers that are composite objects and stored in
    a bank that normally is not visible to the system. If you call them
    the memory is normally configured through the FLASHPTR call which
    swaps in the bank, executes the code and swaps back to the original
    bank.

    So you have to configure the memory correctly while breaking them up
    to see the correct code inside (Nosy does this, for example) and if
    you build them back together (after some possible modifications) and
    there are pointers for a different flashbank than that the system is
    normally configured for you have to configure the memory for that as
    well.
    After you have build them back together they might show up as pointers
    again, as the flashbanks are configured back to the normal view
    afterwards.

    As you surely know ::N is a composite of :: TYPECOL_ COMPN_ ;
    TYPECOL_ is the prolog for a system rpl program and COMPN_ actually
    builds the program.

    To get your code as a working version back together you need to call
    something like this (instead of ::N):
    TYPECOL ' COMPN_ FLASHPTR #NumberOfTheBank 0
    This will correctly configure the memory for that bank and call an
    EVAL (at the beginning of each flashbank there is an EVAL) to build
    your secondary while that bank is active. Note: You need to know from
    which bank your program is running !

    Also if you want to call any unsupported pointer from any bank use
    ' PTR xxxxx FLASHPTR #NumberOfTheBank 0

    But beware: All of this is "dirty" and might not work if the pointer
    changes and/or the code is moved to another flashbank.

    HTH,
    Andreas

    P.S.: This is kind of hard to explain so feel free to email me your
    exact problem.

  7. Re: Problem with ::N, {}N and ->LIST and any composite building

    > This happens for all pointers that are composite objects and stored in
    > a bank that normally is not visible to the system. If you call them
    > the memory is normally configured through the FLASHPTR call which
    > swaps in the bank, executes the code and swaps back to the original
    > bank.


    Yes. I know all about how this works, it was just a little unexpected
    for something that seems to be used for nothing but object
    composition.

    > So you have to configure the memory correctly while breaking them up
    > to see the correct code inside (Nosy does this, for example)


    Yes. I am doing this and getting the correct pointers, it was just
    rebuilding it that showed the problem.

    > TYPECOL ' COMPN_ FLASHPTR #NumberOfTheBank 0


    I am going to be very busy for the next few days, but I will give it a
    try when I get some time.

    > But beware: All of this is "dirty" and might not work if the pointer
    > changes and/or the code is moved to another flashbank.


    Yup. It is in the matrix write code. I'm replacing the menu with one
    of my own and it is only one flashpointer deep.

    > HTH,
    > Andreas


    Indeed it did. I was already using the FPTR BANK 0 thing, but I still
    am not sure why COMPN_ behaving like that would be desirable. . .

    TW
    > P.S.: This is kind of hard to explain so feel free to email me your
    > exact problem.



  8. Re: Problem with ::N, {}N and ->LIST and any composite building

    Hi Tim,

    >*I was already using the FPTR BANK 0 thing, but I still
    > am not sure why COMPN_ behaving like that would be desirable. . .


    Well, IŽd look into COMPN_ for that and the way it is building
    composite objects.
    Maybe the code got never adjusted for the added banks while migrating
    from 48GX to 49G ?
    However, it works for me that way ;-)

    > I'm replacing the menu with one
    > of my own and it is only one flashpointer deep.

    Mind posting the FlashPointer and what you are doing exactly ? That
    way we all could benefit from it.

    HTH,
    Andreas

  9. Re: Problem with ::N, {}N and ->LIST and any composite building

    > Mind posting the FlashPointer and what you are doing exactly ? That
    > way we all could benefit from it.


    DoOldMatrix is the one I was working through and yes I was planning on
    posting that since I've seen several people on the group wonder how to
    do a cusom menu in the matrtix writer before.

    That brings me to another question I guess regarding actually
    extracting out the flashpointers. There are several little code
    snippets on the newsgroup scattered over the years, and one in OT49
    for pulling out flashpointers. Which one do you use? Or did you make
    your own? As far as I know there isn't one in the ROM anywhere.

    TW

  10. Re: Problem with ::N, {}N and ->LIST and any composite building

    Hi Tim,

    I use a modified version of Flashptr_@ from OT49 to extract a Flashptr
    from the ROM. So far it has not failed on a single Flashptr that I
    tried to extract ;-)

    HTH,
    Andreas

  11. Re: Problem with ::N, {}N and ->LIST and any composite building

    Hi

    On 2008-10-07 06:17:20 +1100, TW said:

    > Actually, could be said as a problem with COMPN_ as called in extable
    > 2 which all of those use. I discovered this when making a small
    > program to put a custom menu into the matrix writer. I pulled out the
    > flashpointer code, and replaced the relevant parts using ::N to
    > rebuilt things. I discovered that one or two of the higher pointers
    > were changed after using ::N
    >


    You just can't do that.

    '
    PTR 6FBC5
    BINT1
    ::N

    PTR 6FBC5 is in a covered area and when you run ::N that pointer points
    to something invalid as you probably haven't configured the flash banks
    properly.

    The code inside the matrix writer hasn't been designed to be re-used elsewhere


    --
    They who would give up an essential liberty for temporary security,
    deserve neither liberty or security (Benjamin Franklin)


  12. Re: Problem with ::N, {}N and ->LIST and any composite building

    > You just can't do that.

    Indeed. Because the pointer is rewritten.

    > '
    > * PTR 6FBC5
    > * BINT1
    > * ::N
    >
    > PTR 6FBC5 is in a covered area and when you run ::N that pointer points
    > to something invalid as you probably haven't configured the flash banks
    > properly.
    >
    > The code inside the matrix writer hasn't been designed to be re-used elsewhere


    Yes I know. In the past when I've modified things on the fly I'd
    never run into this rewriting that ::N does. I've pulled the
    composites apart, made the few modification to do what I needed,
    rebuilt them, and put in calls to use the FPTR BANK 0 trick. It isn't
    that complicated most of the time. . .

    TW

  13. Re: Problem with ::N, {}N and ->LIST and any composite building

    Care to share us what you did, why it was needed, etc
    We might learn some new tricks...
    Thank U & may JHWH bless U!

    "TW" wrote in message
    news:31233a07-9f12-4664-a313-91d5a2aab741@r15g2000prh.googlegroups.com...
    > You just can't do that.


    Indeed. Because the pointer is rewritten.

    > '
    > PTR 6FBC5
    > BINT1
    > ::N
    >
    > PTR 6FBC5 is in a covered area and when you run ::N that pointer points
    > to something invalid as you probably haven't configured the flash banks
    > properly.
    >
    > The code inside the matrix writer hasn't been designed to be re-used
    > elsewhere


    Yes I know. In the past when I've modified things on the fly I'd
    never run into this rewriting that ::N does. I've pulled the
    composites apart, made the few modification to do what I needed,
    rebuilt them, and put in calls to use the FPTR BANK 0 trick. It isn't
    that complicated most of the time. . .

    TW



+ Reply to Thread