[go: up one dir, main page]

Menu

#2100 Monitor should wait until no more keys are pressed when closing

v3.x
open
dqh
None
GTK3
User Interface
2025-11-03
2024-12-14
robozz
No

After leaving the monitor with x[return], if the very next key press is return
then that key press is sometimes not recognized.

in the following examples:
? means return key is not recognized
! means return key is recognized
(press) means a short key press
(hold) means a longer key press

The first examples is when leaving the monitor after a break has been triggered.

After a short key press the next return key press is not recognized:

break c000
BREAK: 1 C:$c000 (Stop on exec)

(a)

sys49152

1 (Stop on exec c000)

x[return] (press)
[return] ?
[return] !

After a longer key press, the next return key press is recognized:

(b)

sys49152

1 (Stop on exec c000)

x[return] (hold)
[return] !

Instead of sys49152[return] put the cursor on the line with sys49152, enter the monitor,
and use the keybuf command.
Now it is the other way around (compared to example a) after a short key press
the next return key press is now recognized:

(c)

-> monitor
keybuf \n
x[return]

1 (Stop on exec c000)

x[return] (press)
[return] !

After a longer key press, there's now a return key press after a short delay
(if you hold return for long enough...)

(d)

-> monitor
keybuf \n
x[return]

1 (Stop on exec c000)

x[return] (hold)

This is what happens when just entering and then leaving the monitor:
after a short key press it is the same as example c
after a longer key press it is the same as example d

Discussion

  • gpz

    gpz - 2024-12-19

    I don't understand what the problem is here. Is it that you press AND HOLD "enter" after X in the monitor and then you expect it to get recognized in the emulated C64? And how are you even checking that it is or not?

     
  • radius75

    radius75 - 2024-12-19

    I checked these four examples. Indeed, after exiting the monitor, in these cases Return is not registered with the first keystroke.

     
  • gpz

    gpz - 2024-12-19

    i'd still like to know the exact details. i can see no obvious problem on my end for that matter.

    And that you will have to release enter, after exiting the monitor with X, before the emulated c64 sees another pressed "return" key, is expected.

     
  • robozz

    robozz - 2024-12-19

    The thing is that this used to work as expected in earlier version of VICE, so something must have changed recently.
    For example in 3.5 (GTK3 3.24.24, GLib 2.66.3) the (a) example above works (return is recognized) while the (d) example is the same as the one here. In even earlier versions none of these things happen.

     
  • gpz

    gpz - 2024-12-19

    Again, i'd like to know the exact details.

    As for what is expected - your expectations might be wrong too :)

     
  • gpz

    gpz - 2025-05-21

    putting this on "need info" now. we need a detailed description on how to reproduce the problem. in particular how is "return pressed" verified "on the c64"?

     
  • gpz

    gpz - 2025-05-21
    • status: open --> open-need-info
    • assigned_to: gpz
     
  • robozz

    robozz - 2025-06-09

    Is it that you press AND HOLD "enter" after X in the monitor and then you expect it to get recognized in the emulated C64?

    the opposite, the problem is that it is being recognized!

    look at the example program used here:
    https://csdb.dk/forums/?roomid=11&topicid=108602

    in older VICE versions (3.2 and earlier) if "g 0812" is used from the monitor and the return key is
    held down, the program will be in the inc $d021 loop.
    In newer versions, after a short while, it will exit the loop and return, so in other words
    VICE is somehow registering the return key after a delay, just as in the last example above:
    enter monitor, and then leave with x (hold return key down)

    another example:

    1 geta$:ifa$=""then1
    2 printa$;:goto1
    
    watch load 0816
    

    this will now break everytime you press a key, but press the same key again and it will not break!

    Also look at how the WinUAE debugger behaves, it only closes the window after you've released return key.

     
    • Querino

      Querino - 2025-06-16

      1 geta$:ifa$=""then1
      2 printa$;:goto1
      watch load 0816

      that is working in r42405, but fails in r42417

       
  • gpz

    gpz - 2025-07-29

    Also look at how the WinUAE debugger behaves, it only closes the window after you've released return key.

    OK. I totally misunderstood what the supposed problem was then. This behaviour makes sense. Not sure how easy this is to implement though :)

     
  • gpz

    gpz - 2025-08-21

    i had it almost working.... except it did hang, sometimes. Damn threading shit :)

    @dqh will have to look at it

     
  • gpz

    gpz - 2025-08-21
    • status: open-need-info --> open
    • assigned_to: gpz --> dqh
     
  • gpz

    gpz - 2025-08-24

    attached is my current hack... it kindof works except when it doesn't :) i am probably not doing some of this threading stuff correctly

     
  • gpz

    gpz - 2025-11-03
    • Category: Monitor --> User Interface
     
  • gpz

    gpz - 2025-11-03
    • summary: Return key press not recognized after leaving monitor --> Monitor should wait until no more keys are pressed when closing
     

Log in to post a comment.