Overcome the STO-bug - Hewlett Packard

This is a discussion on Overcome the STO-bug - Hewlett Packard ; Hello, finally Cyrille words make sense to me ;-) This did work manually for me (by modifying the RAM in the emulator while the program was running) and could be a way to bypass the STO- bug: Change the hash ...

+ Reply to Thread
Results 1 to 6 of 6

Thread: Overcome the STO-bug

  1. Overcome the STO-bug

    Hello,

    finally Cyrille words make sense to me ;-)

    This did work manually for me (by modifying the RAM in the emulator
    while the program was running) and could be a way to bypass the STO-
    bug:

    Change the hash table of the key libs at start-up and redirect it to a
    ROMPTR call of your choice. Now if a key is pressed the changed hash
    table will be used.

    0. The Sytem Outer Loop reads an evaluates key strokes. When a key is
    pressed the modified hash table of the key libs will be used. Now the
    following will happen, if a key is pressed:
    1. The redirected ROMPTR call through the modified hash table restores
    the default hash table of the key-lib.
    2. evaluates the pressed key ( this ROMPTR must handle possible
    errors, how about the command line ? )
    3. the redirected ROMPTR program is in the return stack, so after
    evaluation of the key press I still have controll with my ROMPTR
    4. switch the original hash tables of the key libs back to the
    modified versions, this will be done at every key stroke to ensure
    that they aren´t overwritten be the values of the STO-bug.
    5. The SOL waits for the next key stroke.

    Of course this has to be done in ML (and might only be possible form
    there). Exchanging the tables in ML is *very* fast, so it will have no
    noticable speed penalty. For speed enhancement the adresses that lead
    to the alternative hash tables will be saved in a lam at the lowest
    lam possible, this is always directly behind the DOLPENV. So it is
    assured that it won´t interfere with the lams used by the system. But
    if the lib is in a port > 0 I can store the ACPTR that lead to
    alternative hash tables in RAM ( at SAUV_REGISTR) so that I don´t need
    the time to calculate the ACPTR at each key press. I only need to
    recalculate the ACPTR addresses if the content of the port the lib is
    stored in changes.

    Now, having the above said in a program, this will circumvent the
    infamous STO-bug. But writing this program will be a little bit
    tricky, especially for running in a port > 0 because the debugger of
    debug4x only works with port 0.
    Of course this program should not run if ML development is done
    directly on the calc, because SAUV_REGISTR is used by the ML DBUG
    routine But this is surly not the normal usage of the calc.

    This will allow true stack replacements and true translation of all
    messages to another language regardless of what internal or external
    program is started (of course this is only true if this program does
    not change the hash table :-).
    Seems like I won´t get much sleep over the next few weeks. Also I not
    sure (at the moment, haven´t tried so far) how I create the hxs-string
    which will become the alternative hash table. RPL.S (available from
    hpcalc.org) gives some clues but a detailed explantion would be most
    welcome.
    (Gosh, I don´t think I got all tenses right in this post, but I hope
    it is understandable ;-)

    Greetings
    Andreas
    http://www.software49g.gmxhome.de

  2. Re: Overcome the STO-bug

    Hello to those who might be interested in the topic,

    > how I create the hxs-string
    > which will become the alternative hash table.
    It is possible to create this string with debug4x (once you figured
    out how the tables inside the lib are ordered and how to address them)
    meaning that the alternative table is calculated and created by the
    compiler. This of course means, that splitting the lib on the calc and
    rebuilding it will surly cause problems, especialy if the ROMPTRs of
    this lib are changed.

    Greetings
    Andreas
    http://www.software49g.gmxhome.de


  3. Re: Overcome the STO-bug

    "Andreas Möller" wrote in message
    news:1173892344.968291.54910@y66g2000hsf.googlegro ups.com...
    X
    Now, having the above said in a program, this will circumvent the
    infamous STO-bug. But writing this program will be a little bit
    tricky, especially for running in a port > 0 because the debugger of
    debug4x only works with port 0.
    X
    Avenard once helped me to create FinLib49
    which translates error messages into Finnish
    it should always be at port 0

    Veli-Pekka
    PS: Sorry for late posts, but be patient I'm catching up
    AND
    rejecting about 99% of the interesting stuff...


  4. Re: Overcome the STO-bug


    > Avenard once helped me to create FinLib49
    > which translates error messages into Finnish
    > it should always be at port 0
    And I told you at that time that your FinLib49 is affected by the
    infamous STO-bug as well. You can easily check it again by storing
    something in a port. After that all alternative messages above lib6
    are zeroed out.
    The STO-bug is still present in the latest ROM and it does not look
    like as it would be fixed at any time.

    Also my language packs work in any port. Replacing all messages needs
    about 48 kB of RAM which is not taken away from the RAM if stored in
    port2.

    Now, feel free to translate your *whole* 49 to Finnish. After that we
    can use my engine with your translation for a *complete* Finnish
    talking 49G.

    Greetings,
    Andreas
    http://www.software49g.gmxhome.de

  5. Re: Overcome the STO-bug


    "Andreas Möller" wrote in message
    news:e9684ab2-174d-457b-97c3-05803d863451@u72g2000hsf.googlegroups.com...
    >
    > > Avenard once helped me to create FinLib49
    > > which translates error messages into Finnish
    > > it should always be at port 0
    > And I told you at that time that your FinLib49 is affected by the
    > infamous STO-bug as well. You can easily check it again by storing
    > something in a port. After that all alternative messages above lib6
    > are zeroed out.
    > The STO-bug is still present in the latest ROM and it does not look
    > like as it would be fixed at any time.

    /&(/"!&¤)=(/&"=%

    > Also my language packs work in any port. Replacing all messages needs
    > about 48 kB of RAM which is not taken away from the RAM if stored in
    > port2.
    >
    > Now, feel free to translate your *whole* 49 to Finnish. After that we
    > can use my engine with your translation for a *complete* Finnish
    > talking 49G.

    Some help please
    nousiainen dot velipekka (at) gmail....


  6. Re: Overcome the STO-bug


    > nousiainen dot velipekka (at) gmail....
    I dropped a mail at this address, otherwise you can reach me through
    the email-address of my website.
+ Reply to Thread
« Job Description | Strange splash screen on hp49g »