Do you mean that you downloaded a new version of the debugger 2 days ago, and it created problems? or that the same version you had, all of a sudden 2 days ago started failing?
Are you sure you activate (and remove) the breakpoints on the correct slot, subslot and segment? If one of these is not correct, the breakpoint will not trigger. And removing a breakpoint for one slot still can trigger on another slot.
Do you mean that you downloaded a new version of the debugger 2 days ago, and it created problems? or that the same version you had, all of a sudden 2 days ago started failing?
I did not download or changed the current version on my machine. It just stopped doing what to expect. Only breakpoints set via main toolbar menu will fire.... verified all sorts of things.... it's just not working anymore. Hopefully next msx fair in Nijmegen Manuel will help me :-)
Ok, I think it might have something to do with the fact that my code is self-modifying. Working on my source code is the only variable in this mysterious issue. That might causes some code to be located at addresses that it wasn't previously located at.
Ah, then that would explain! breakpoints are associated with an address, not with an instruction. So, if the instruction moves position in memory, the breakpoint will remain in the original address in which it was set
Hey inchl, try a fresh openMSX debugger build, it includes this recent pull request which fixes caching issues in the code debugging view, it may improve your situation.
Ah, then that would explain! breakpoints are associated with an address, not with an instruction. So, if the instruction moves position in memory, the breakpoint will remain in the original address in which it was set
I know, but even if I re-set the breakpoint at the new address it still doesn't work.
Quote:
Hey inchl, try a fresh openMSX debugger build, it includes this recent pull request which fixes caching issues in the code debugging view, it may improve your situation.
