rice123

delta_t = maincpu_clk - snddata.lastclk; This can be abnormally high during shutdown: (gdb) p maincpu_clk - snddata.lastclk $30 = 14544 so when reSIDfp::SID::clock() is called with this value as the argument, retval can become too large for snddata.buffer to handle. Why is delta_t so high? Normally, sound_run_sound() is called at the end of every raster line: #0 sound_run_sound () at /src/sound.c:1397 #1 sound_flush () at /src/sound.c:1517 #2 vsync_do_end_of_line () at /src/vsync.c:531 #3 vicii_raster_draw_handler...

The problem is that mon_update_all_checkpoint_state() is called only in load_snapshot_trap() which is called from: advance_hassnapshot() (as stated in the comment above the function definition) autostart_snapshot() so as far as I can tell, it's called only when you autostart a .vsf: Autostart: Done. Autostart: Restoring snapshot. Thread 8 "x64sc" hit Breakpoint 1, load_snapshot_trap (unused_addr=58836, unused_data=0x0) at /src/autostart.c:996 996 { => 0x00005555565ea579 <load_snapshot_trap+0>: f3...

and here's the exact reason why the store watchpoint is unstable for me and Querino: (gdb) bt #0 monitor_watch_push_store_addr (addr=addr@entry=1536, mem=e_disk8_space) at /src/monitor/monitor.c:2873 #1 drive_store_watch (drv=0x7ffff2f74800, address=1536, value=255 '\377') at /src/drive/drivemem.c:121 #2 drivecpu_execute (drv=drv@entry=0x7ffff2f74800, clk_value=clk_value@entry=2359362) at /src/6510core.c:3042 #3 drive_cpu_execute_one (drv=drv@entry=0x7ffff2f74800, clk_value=clk_value@entry=2359362)...

That said, the drive CPU is slightly faster than the C64, so it actually sounds logical that you (sometimes) see two cycles of drive cpu for one cycle of C64 cpu (can you make this behave the other way around by switching to NTSC?) I think we're talking about different things. As far as I can see, a single drivecpu_execute() call can execute multiple drive CPU cycles. How many of them will be executed is calculated using the main CPU clock delta (calculations also include the scaling factor, which...

Here's something I noticed: when a drive watchpoint is executed and the user changes the default device to C: then the drive CPU executes recursively, see frames #1 and #9: Thread 8 "x64sc" hit Breakpoint 3, drivecpu_execute (drv=drv@entry=0x7ffff2f74800, clk_value=clk_value@entry=2751966) at /vice/src/6510core.c:2337 2337 DO_INTERRUPT(pending_interrupt); => 0x00005555568844dd <drivecpu_execute+4542>: 44 88 75 b0 mov %r14b,-0x50(%rbp) (gdb) bt #0 drivecpu_execute (drv=drv@entry=0x7ffff2f74800, clk_value=clk_value@entry=2751966)...

yes, hopefully fixed, the ticket can be closed

Yeah, I can see the duality here. For the purpose of building an accurate memory map, cycle 2 in LDA #$00 should be treated like a normal load. For the purpose of triggering a watchpoint, it should be treated like a dummy load. There seem to be three classes of loads: 1) Dummy -> usually no real effect on the executed code (discarded opcode fetches, indexed accesses before fixing the high address byte, etc.) 2) Not dummy, but not very interesting in the context of watchtpoints -> opcode/operand loads...

Another problem is, that for one-byte opcodes, the second fetch most likely IS a dummy cycle that should be handled as such. This is true, currently LDA #$00 and RTS are handled by the same code.