rice123

yeah, same here in r46150, the watchpoint is unstable.

works fine in r46150, thanks

Thanks for the patch, the improvements look sound. I can't compile anything right now, so I'll test in production.

The first case (interrupts) works fine, thanks. which makes complete sense to me (dummy fetch from return address -1) does that make sense? I don't think that discarded dummy fetches should trigger watchpoints (that's only relevant for a handful of registers where some action is taken on access, or is there some other special case?), but even ignoring that, I don't see the dummy fetch from return address - 1 you're referring to. The dummy fetch in RTS is done before pulling the return address from...

Didn't know it needs to be enabled manually, sounds much better with it. The filters in real 8580 recordings are slightly stronger, and the 8580 filter curve setting seems to make very little difference (if any), but this is much more likely to be in an acceptable range.

No change, real SID recordings still sound much closer to resid-fp 0.16 from 2009 than r46108. Checked old VICE builds today, okay in v3.0, terribly regressed in v3.1

is it correct to assume that in this code from mon_breakpoint_check_checkpoint: instpc = new_addr(mem, (monitor_cpu->mon_register_get_val)(mem, e_PC)); loadstorepc = new_addr(mem, lastpc); instpc is $1003 and loadstorepc is $6000 for the second example? Cant check myself without debugging symbols for WinDbg. If this assumption is correct then maybe it can be special cased with something like this: diff --git a/mon_breakpoint.c b/mon_breakpoint.c index a8d2bd4..840b8d6 100644 --- a/mon_breakpoint.c...

I just noticed it also affects subroutine jumps: a 1000 jmp $6000 rts a 6000 jsr $1003 jmp $1000 r pc = 1000 watch 2000 9fff if (pc >= $1000) && (pc <= $1003) x The monitor thinks that loading the address high byte from $6002 happens when PC == $1003: #1 (Stop on load 6002) 12/$00c, 11/$0b .C:6000 20 03 10 JSR $1003 - A:00 X:00 Y:0A SP:f1 ..-...Z. 5013047