Recent changes to bugs

#2221 Watchpoints get a wrong PC during interrupts

2026-04-20T17:46:54.721000Z

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
+++ b/mon_breakpoint.c
@@ -534,6 +534,11 @@ bool mon_breakpoint_check_checkpoint(MEMSPACE mem, unsigned int addr, unsigned i

     ptr = search_checkpoint_list(list, addr);


+    // Temporarily revert PC for `mon_evaluate_conditional()` calls below
+    if (is_loadstore) {
+      monitor_cpu->mon_register_set_val(mem, e_PC, (uint16_t)(addr_location(loadstorepc)));
+    }
+
     while (ptr) {
         cp = ptr->checkpt;
         ptr = ptr->next;
@@ -608,6 +613,11 @@ bool mon_breakpoint_check_checkpoint(MEMSPACE mem, unsigned int addr, unsigned i
         }
     }


+    // Restore the current PC
+    if (is_loadstore) {
+      monitor_cpu->mon_register_set_val(mem, e_PC, (uint16_t)(addr_location(instpc)));
+    }
+
     return must_stop;
 }

#2221 Watchpoints get a wrong PC during interrupts

2026-04-20T15:31:23.372000Z

the second example at least doesn't seem unexpected to me. Note that any registers used in the condition are "live" - the condition triggers when the expression becomes true. So when an instruction changes/updates PC (like JSR) that will cause this condition to become true mid-instruction (indeed after fetching the 3rd byte)

the first case is a bit odd, it looks like a similar thing, but i wouldn't expect it to be this stable (is it really?)

perhaps (i dont know if this is realistic) some special cases like this can be checked for, and then when the watchpoint hits, it also disasassembles the instruction after the PC changed

#1940 Joystick up key gets stuck

2026-04-19T19:45:31.407000Z

I was able to make the iCode Retro Gaming Adapter work with the SDL version of VICE. GTK is what has problems.

#2201 Logitech F310 (Dual Action) not detected on macOS unless SDL_JOYSTICK_MFI=0

2026-04-19T17:50:28.167000Z

vice-arm64-gtk3-3.10 detects the F710

./x64sc -verbose -debug
Joystick: Registered device "Logitech Cordless RumblePad 2" [046d:c219] (2 axes, 1 button, 1 hat)
Joystick: joystick_init(): resource JoyDevice2: opening device 0 (Logitech Cordless RumblePad 2)

#2201 Logitech F310 (Dual Action) not detected on macOS unless SDL_JOYSTICK_MFI=0

2026-04-19T17:39:38.793000Z

This is with the F710 (in D-mode)

./x64sc -verbose -debug
SDLJoystick: No joysticks found.

SDL_JOYSTICK_MFI=0 ./x64sc -verbose -debug
SDLJoystick: Got 1 potential devices.
SDLJoystick: SDL_JoystickNameForIndex(0) = "Logitech Cordless RumblePad 2"
Joystick: Registered device "Logitech Cordless RumblePad 2" [046d:c219] (4 axes, 12 buttons, 1 hat)

#904 joystick bit 3 (right) does not interfere with keyboard column 7

2026-04-19T12:52:20.450000Z

status: open --> open-need-test
assigned_to: gpz
Version: v3.0 --> v3.x

#904 joystick bit 3 (right) does not interfere with keyboard column 7

2026-04-19T12:51:58.243000Z

r46083 handles this a little bit better

however, we really need a proper test program so we can really test all cases against the real thing

#1785 Joysticks on MacOS not working.

2026-04-19T11:33:05.074000Z

Sorry about that. Yes confirmed it works on 3.10. Some page showed 3.9 as latest. Thank you very much...

#1785 Joysticks on MacOS not working.

2026-04-19T09:16:50.929000Z

please try the latest release, 3.10

#1785 Joysticks on MacOS not working.

2026-04-19T08:36:50.381000Z

I am running 3.9 on GTK, but I have the same issue. Only the button works. I send a fix in this thread 3 years ago which works for me.
I use the Speed-Link Competition Pro USB joystick.