USB Joystick not working pt2

[bnice]

Hi,

Well I upgraded to macos 26 and and I sorry to say the joystick still isn't working with VAmiga. It works perfectly with Virtual64 and FS-UAE. The movements are shown in preferences / devices for both VAmiga and Virutal64. I have attached a move of me moving the joystick in both emulators and it shows the preferences/devices and emulator for both.

Regards,

Ben

c64.capture.mov

amiga.capture.mov

[dirkwhoffmann]

@bnice. Thanks for the update. I'll try to track the issue down on Sequoia.

However, I am not sure if the next version of vAmiga will work on Tahoe, as I plan to downgrade my machine back to Sequoia and stay there until the next OS comes out.

[dirkwhoffmann]

I think I have tracked down the bug. Based on the videos you posted, your controller uses mappings like +a1 -> dpdown. My parser didn’t support these mappings, which caused the lookup table for incoming a1 events to remain empty.
I don’t have the exact same gamepad, but I dug up a rather crappy controller from my cupboard that uses a similar scheme:

I managed to get vAmiga working with it, so I believe version 4.3.1 (now online) should fix the issue. Could you give that version a try?

By the way, it works in VirtualC64 because only vAmiga uses the new SDL scheme–based mapping code. I still need to port that code back to VirtualC64.

[bnice]

Hi,
Just curious when you said you were waiting for the next OS version did you mean the final release of Tahoe final release, Tahoe .1 or MacOS 27? I was curious which version of Tahoe caused the toolbar issue in one of the other listed issues, as I am running the final release (released at the beginning of week and don't see this toolbar issue then again I am still running an Intel based Macbook.

[bnice]

Hi Dirk,

Tried for 4.3.1 it crashed on launch but then tried my version it crashed on launch too. Rebooted Mac and both versions work, looks like Tahoe has some an isssue. Anyway tried joystick, the directions now work fine but, no fire button... I was surprised that my joystick adaptor was output unusual codes, as works with all other apps.

Regards,

Ben

[dirkwhoffmann]

Thanks for reporting the button issues. The bug was caused by my misinterpretation of the SDL mapping scheme when I integrated their database. I mistakenly treated the strings "X" and "Y" as directions. Since mapping a button to a direction didn’t make sense, I skipped all mappings involving X and Y. In v4.3.2, this has been fixed: A, B, X, and Y are now all correctly treated as buttons.

[bnice]

Hi Dirk,

All good, the buttons and directions work :-) . Interestingly this is the first version that suffers from the big toolbar buttons under Tahoe for me. Previous version 3.2, 4.3, 4.31 the toolbar buttons appear normal size. I don't suppose I could convince you to port the joystick fix back to version 3.2 . This is the one is the version I use, as it is the last version to be able to open adfs from inside zip files, which my whole adf collection is. I use this same collection of ADFs with FS-UAE and a Mister. Tonight I did try renaming with the extension to adz but it turns out that is for gzipped adfs sigh.

Regards,

Ben

[dirkwhoffmann]

Interestingly this is the first version that suffers from the big toolbar buttons under Tahoe for me.

It looks like this is an Xcode 26 issue. I compiled version 4.3.1 on my old Sequoia MacBook with the previous Xcode release, and everything was fine. However, this morning Xcode auto-updated to version 26 on my Sequoia machine, and that’s when the oversized buttons appeared.

I'm really thinking about switching to Linux... Bugs aside, I cannot stand what they did to macOS visually in Tahoe.

[dirkwhoffmann]

BTW, you can work around the button issue in v4.3.1, as the SDL description is editable. Replacing x: by a: and y: by b: should make the emulator recognize the buttons.

[bnice]

Hi Dirk,

Thanks for the button trick. Tried to do the something similar for the directions. Ended up reading the code around joysticks. I see that you have to hard code all the HIDEvents this didn't feel right. Here is what I would of done to build the map:

descriptor = find descriptor in file
find pairs for descriptor
for each pair in pairs
switch (pair[0])
case "dpleft" :
map put key=pair[1] value= pull_left...
case "dpright":
map put key=pair[1] value= pull_right...
case "dpup":
map put key=pair[1] value= pull_up...
case "dpdown":
map put key=pair[1] value= pull_down...

Like this the code doesn't need to know what buttons are mapped. It gets whatever is defined in the file. Some crazy new controller comes along with all new event names that's between the OS and the file the code will continue to work.

[dirkwhoffmann]

@bnice: Do you mean this code?

   func query(descriptor: String) -> HIDMapping {

        var result: HIDMapping = [

            .AXIS: [:],
            .BUTTON: [:],
            .DPAD_UP: [0:[:]],
            .DPAD_DOWN: [0:[:]],
            .DPAD_RIGHT: [0:[:]],
            .DPAD_LEFT: [0:[:]],
            .HATSWITCH: [0:[:]]
        ]

        // Add default values for the directional pad
        result[.DPAD_UP]![0] = [0:[.RELEASE_Y], 1:[.PULL_UP]]
        result[.DPAD_DOWN]![0] = [0:[.RELEASE_Y], 1:[.PULL_DOWN]]
        result[.DPAD_RIGHT]![0] = [0:[.RELEASE_X,], 1:[.PULL_RIGHT]]
        result[.DPAD_LEFT]![0] = [0:[.RELEASE_X,], 1:[.PULL_LEFT]]

        // Add default values for the hat switch
        result[.HATSWITCH]![0]![0] = [.RELEASE_XY]
        result[.HATSWITCH]![0]![1] = [.PULL_UP]
    ...

The idea behind the lookup table is to provide a fast mapping whenever a HID event occurs. This is handled in the GamePad class:

       if let hid = hidEvent {
            // Map the HID event to an action list
            if let events = mapping?[hid.0]?[hid.1]?[hid.2]

In your code proposal, you use pair[1] as the lookup key. However, pair[1] is something like a0~, which comes from the SDL mapping scheme. I can’t use this in my lookup code. Maybe I’m just missing your point, though.

[bnice]

Hi, i will comment my code:

descriptor = find controller in sdl file
find pairs for descriptor //find pairs
for each pair in pairs //for each controller pair
switch (pair[0])
case "dpleft" : // find dpleft pair
map put key=pair[1] value= pull_left... /* map key pair[1] e.g “a0~” to the values the vamiga uses e.g pull_left. Note the value in pair[1] from the sdl file, is the same as the event value you get back in your hid callback in GUI/input/GamePad.swift */
case "dpright":
map put key=pair[1] value= pull_right...
case "dpup":
map put key=pair[1] value= pull_up...
case "dpdown":
map put key=pair[1] value= pull_down...

You can use the map built above when receive hid events for performance.

[bnice]

Hi Dirk,

I think I am wrong. I thought that you could get the same value as pair[1] out of the value received in your callback hidInputValueAction() in GUI/input/GamePad.swift and this is what was is been displayed above the controller picture in devices tab of the preferences dialog. However, I have now pulled apart the code more and now it is created in the code in PreferencesController refreshDeviceEvent().

I don't have any experience working GUI frameworks that use resource files (.xib) in macos and (.nib) in windows. My only GUI experience was in TCL/TK and Java AWT, Swing, Java FX and a very small amount on the Amiga.

Regards,

Ben

[dirkwhoffmann]

@bnice: The SDL mapping is a bit weird, in my opinion. If I were to define a controller format, I would naturally map HID events directly to virtual buttons. SDL’s scheme, however, does something else: it maps virtual controller entities such as a, b, or back to abstract descriptors like a0~, which, for example, means that axis 0 is reversed. As you’ve seen in my code, this required quite a bit of work to translate those descriptors into a mapping that can actually use HID events as lookup keys.