[Feature] Force refresh button [sf#165]

[openMSX-import]

Reported by sd-snatcher on 2009-03-07 14:25 UTC
Sometimes openMSX-debugger stays showing older data, then I have to close it and open again, to force it to reload everything. It would be nice to have a button to force the refresh of all data.

[openMSX-import]

Commented by sd-snatcher on 2010-08-23 22:47 UTC
Some more details to this feature request, since I'm not sure if it shouldn't be opened as a bug:

It frequently happens that the "Code View" window persists showing incorrect (not updated) code. This usually happens on the following situations:

1. When I close openMSX, recompile the code, run openMSX again and connect the debugger to it. All of this without closing the debugger to save time and not to lose the current breakpoints.

2. Sometimes on some types of paging: Mostly PPI paging and MegaROM paging.

The only current work-around is to quit the debugger and reopen it, and that shift of focus isn't good for concentration and productivity.

The best solutions would be:

1. OpenMSX-debugger should refresh all code/data windows upon connecting
2. A forced refresh button would also be helpfull

[openMSX-import]

Commented by manuelbi on 2014-02-08 16:15 UTC
Is this still happening?

[openMSX-import]

Commented by sd-snatcher on 2014-05-17 21:12 UTC
I just tested it and, yes it's still happening.

Tested with:

• openMSX 0.10.1 on Mac OS-X 10.9.2
• openMSX-debugger 0.9.0-dev12821

[Colpocorto]

Still the same...

There is another situation where the problem arises: on self-modifying routines!

For example, some Gremlin Graphics games build in run-time the needed op-code to check row and column of the keyboard matrix in an very efficient way.

If the modified address isn't close to that routine, you may not notice about it, so when you execute the new instruction you'll go bananas while trying to understand what's going on (because what you see is NOT what you get).

[grauw]

I frequently have the problem of the disassembly view showing old data as well, but I don’t agree with the suggested solution;

I think it would be much better to solve the problem in a way which doesn’t require explicit user intervention, otherwise I’ll be pressing the refresh button continuously because I don’t trust the debugger’s output… definitely a bad thing (the distrust), and also unnecessary manual labour the computer can do rather than me. Other fields on screen are also updated when I hit a breakpoint and step through the code, so why shouldn’t the code view be able to as well.

Additionally, the case where I most often encounter this issue is when I recompile and relaunch openMSX, and then reconnect the debugger. If the breakpoint I hit is close to where I previously disconnected the debugger is still using the cached data disassembly. Definitely when the debugger is reconnected it could flush the cache.

[MBilderbeek]

@edwin-v how hard is this to fix? Any hints/pointers?

[edwin-v]

If that happens, it's a bug. It should fully refresh on reconnect. I'll have a look.

[santiontanon]

Any progress in this front? btw

[edwin-v]

Haven't had a single bit of time. Every thing that requires concentration has been delay to vacation time. Which starts next week!

[santiontanon]

lol, ok! totally understandable! :) not much time on my end either (and using all the time I have to try to get my MSXDev entry on time), but if I can be of any use testing anything, I'm happy to help! :)

[MBilderbeek]

@edwin-v Any news on this? People keep posting about this problem...

[MBilderbeek]

@edwin-v Another report about this today:

<p_gimeno> ok, "step back" worked judging by the slots and the BC register, but the code window didn't refresh. Is there some way to force it to refresh?
I've heard more often about refresh issues, but Edwin couldn't reproduce them, he said
<p_gimeno> I can give a reproduction recipe if that helps
<p_gimeno> (1) run openmsx -machine Toshiba_HX-10, wait for BASIC to be ready; (2) run the debugger and connect, (3) set a breakpoint on a write to port $A8, (4) in BASIC enter out &ha8,15, (5) the debugger should now show all rst 56; select Step Back and notice it doesn't change
<p_gimeno> rst 38h*
<p_gimeno> I've noticed similar refresh issues when doing other things; maybe it should have a manual refresh command
<p_gimeno> I think that another one happened when single-stepping an instruction that wrote to FFFF

[bengalack]

+1 on this. Not sure how to reproduce, but code view did not show what I was expecting, and showed other data than the debuggable memory view.