New breakpoint viewer is ready! | MSX Resource Center (Страница 3/4)

By santiontanon

Paragon (1770)

22-03-2022, 17:35

Oh, this new widget will be extremely useful!! Thanks a lot for creating it!!!

By pizzapower

Master (154)

22-03-2022, 22:38

AxelF wrote:

What would be cool, is an option to add a breakpoint when read/write to a specific address in to VRAM.

You can use a condition for that. Go to the Conditions tab and create a new condition. Write something like this in the condition to check:

[vpeek 0x1234] == 255

By Grauw

Ascended (10707)

22-03-2022, 22:59

Would be nice if debug set_watchpoint had support for read_debuggable and write_debuggable, but that requires an openMSX feature before the debugger can do anything with it.

By pizzapower

Master (154)

22-03-2022, 23:22

Grauw wrote:

Would be nice if debug set_watchpoint had support for read_debuggable and write_debuggable, but that requires an openMSX feature before the debugger can do anything with it.

Is there a feature request for that?

By wouter_

Champion (508)

23-03-2022, 10:18

pizzapower wrote:

Grauw wrote:

Would be nice if debug set_watchpoint had support for read_debuggable and write_debuggable, but that requires an openMSX feature before the debugger can do anything with it.

Is there a feature request for that?

Hi,

I'm not sure there is a feature request for that. But there's only a low probability that it will get implemented.

The reason for that is that we prefer to only add debug-features if it's possible to implement them without(*) slowing down the 'normal' emulation speed (that is when the debug feature is not in use). For breakpoints and watchpoints that was possible. I currently don't see how to efficiently implement a generic "read/write watchpoint on any debuggable" feature. But ideas are welcome of course.
(*) Or at least only a tiny slowdown, much less than 1%.

An alternative that works today is to set a "debug condition", and then for example check yourself if a specific VRAM location has changed value. Of course when any "debug conditions" are active, emulation will run a lot slower. But possibly when you're debugging some issue, this performance hit is acceptable?

By pizzapower

Master (154)

23-03-2022, 22:47

It has just been merged! It's part of the debugger now!

By mcolom

Champion (311)

25-03-2022, 18:05

So much improved now!
By the way, I've just compiled it from a clean github's clone, and I've observed that sometimes warnings are printed by the emulator:

$ openmsx -machine turbor -diska .
warning: Error executing delayed command: No such breakpoint: bp#288
warning: Error executing delayed command: No such breakpoint: bp#334

I'm using openMSX 17.0-330-g890c498ec on Debian Testing. Perhaps it's not even related to these last changes.
Not sure how to reproduce it :S

By pizzapower

Master (154)

06-04-2022, 22:53

mcolom wrote:

So much improved now!
By the way, I've just compiled it from a clean github's clone, and I've observed that sometimes warnings are printed by the emulator:

$ openmsx -machine turbor -diska .
warning: Error executing delayed command: No such breakpoint: bp#288
warning: Error executing delayed command: No such breakpoint: bp#334

I'm using openMSX 17.0-330-g890c498ec on Debian Testing. Perhaps it's not even related to these last changes.
Not sure how to reproduce it :S

It's easy to reproduce this: you just have to delete breakpoints you created on the debugger through the openMSX console by typing > debug remove_bp bp#<num> and the next time you try to edit or delete a breakpoint through the debugger, you will get this error, since it no longer exists. But now the widget detects if something is wrong and asks if if should reload all breakpoints through re-sync.

By pizzapower

Master (154)

08-07-2022, 00:11

This has been merged today: the breakpoint widget now supports labels in the address field. Like this:

Note: SDCC created functions starts with underscore.

By ToriHino

Paladin (826)

08-07-2022, 18:46

Thats a nice extension . Thanks!