Breakpoint on VRAM access?

Champion (301)

20-08-2013, 02:11

Just a small question:

Does anyone know if it is at all possible to create breakpoints in OpenMSX that trigger when a specific address/range in VRAM is accessed?

Something like that would be tremendously helpful for debugging blit and/or copy commands and such.

By wouter_

Hero (526)

20-08-2013, 10:20

Currently openMSX doesn't support watchpoints in VRAM (or more general on any 'debuggable'). We prefer to only add debug features when they can be implemented with (near) zero overhead in case the feature is not used. Z80-memory breakpoints/watchpoints or IO-watchpoints can be implemented without overhead (when not used). But in the current architecture this is not possible for VRAM. Emulation speed is still important for devices like dingoo and most current Android devices (or just to extend the battery life of your laptop).

However you can probably use the generic 'debug condition' feature in openMSX. After each Z80 instruction it's possible to check arbitrary (Tcl) conditions. And when this condition is true it's possible to execute arbitrary (Tcl) commands.

For example:

# break when vram address 0x1234 has value 255
debug set_condition {[vpeek 0x1234] == 255}

# break when vram address 0x5678 changes value
set old_value [vpeek 0x5678]
debug set_condition {[vpeek 0x5678] != $::old_value} { set ::old_value [vpeek 0x5678] ; debug break }

Note that these 'debug conditions' slow down emulation a lot (but only when actually used). Though on a recent desktop system, emulation should still run at (more than) real-time speed.

By Edwin

Paragon (1182)

20-08-2013, 12:24

It would be much easier to simply add an iowrite watchpoint to port 98h with conditional check on the vram access pointer debuggable.

Of course if you really need it for blitter commands, then wouter's solution is probably easiest. Of course you could try to write a condition that checks the area of the command when the command register is written. But that's definitely not easier. ;-) It will run quicker though.

By Sandy Brand

Champion (301)

26-08-2013, 20:43

Thanks a lot Wouter! That did the trick!

Had a bit of trouble tracking a bug that accidentally did a VDP fill command that filled an area that would make it extend through the bottom of a page into the top of the next page. I only saw the effects of the bug on the next page which was very confusing.

wouter_ wrote:

We prefer to only add debug features when they can be implemented with (near) zero overhead in case the feature is not used. ... Emulation speed is still important for devices like dingoo and most current Android devices (or just to extend the battery life of your laptop).

So why not make it optional and provide for a 'light' version with some #if defs? Unlikely that anyone needs debugging features on a dingoo or such anyways

Having break-points on RAM/VRAM is extremely useful stuff while debugging!

By wouter_

Hero (526)

27-08-2013, 10:24

Sandy Brand wrote:

Thanks a lot Wouter! That did the trick!...
So why not make it optional and provide for a 'light' version with some #if defs? ...
Having break-points on RAM/VRAM is extremely useful stuff while debugging!

You're welcome.

I prefer to keep all versions the same as much as possible.

Breakpoints are already fully supported, including conditional breakpoints. (Conditional) watchpoints on the 64kB Z80 memory space or on IO-ports (in other words all memory/IO read/writes initiated by the Z80) are also fully supported. There are also breakpoints on IRQ generation/acceptance. And last there are the generic debug conditions.

Sure we could add some extra built-in debug feature like VRAM watchpoints. But then next time someone wants a debug action that fires when a specific bit in the MSX-Audio status register flips or when the turboR timer reaches a certain value. For all these very specific cases you can use the 'debug conditions', like we did in the beginning of this thread.

That being said, openMSX is open source, so you're always welcome to add such a feature yourself (src/video/VDPVRAM.hh:521 seems like a good place to start). Let me know if you're interested and/or need any help.