Speedlink Competition Pro Extra USB not recognized/working on C64

[zeegerman1]

I use the latest firmware from 2021-11-18 (via mouSTer.fw.3.16.2600.zip).

• The mouSTer works well with Xbox controllers using a Commodore 64.
• However, my Speedlink Competition Pro Extra USB joysticks are not properly recognized on a C64 with mouSTer, and moving or pressing buttons doesn't do anything.
• These joysticks work perfectly with all additional buttons when connected to my Macbook Pro directly via USB.

Interestingly, the DBG file indicates that the Competition Pro joysticks are identified differently by mouSTer (see attached DBG file, which looks like the ID of a "Sony DualShock 3 / Sixaxis" controller) than on my Macbook Pro, the latter of which identifies them as:

SPEEDLINK COMPETITION PRO
Product ID:	0x2217
Vendor ID:	0x0738  (Mad Catz, Inc.)
Version:	1.09
Speed:	Up to 12 Mb/s
Manufacturer:	MY-POWER CO.,LTD.
Location ID:	0x14140000 / 3
Current Available (mA):	500
Current Required (mA):	100
Extra Operating Current (mA):	0

My current INI and DBG files are included below. (Ultimate goal is to have the two main buttons function as "fire button 1", and two of the others a POTX, POTY, respectively - with the attached INI file this works for my Xbox controller, but not for the Competition Pro.)

debug-and-ini.zip

[willyvmm]

This issue has been reported a few times through different channels.
Seems like I need the real hardware to debug this issue.

[zeegerman1]

I've been able to re-confirm this issue with another C64 and a third Competition Pro USB joystick in the meantime.

Are there any news on this?

[willyvmm]

Please try the latest Pre-Release Firmware: https://github.com/willyvmm/mouSTer/releases/tag/3.17.3309

[zeegerman1]

Tried the latest firmware 3.17.3309 with both my Competition Pro USB joysticks and both of my mouSTers on my C64, but seeing the following issue: With the attached INI, only the fourth button is recognized, and incorreclty as "fire 1" rather than as "paddleB".

Attaching INI and DBG files as usual.
DBG_and_INI.zip

[zeegerman1]

@willyvmm I also just tried the very latest firmware release 3.17.3470, but it has the same exact issue as the one described in my previous comment: With the ini settings identical to the ones in that comment, it recognizes only the fourth button, and incorrectly so as "fire 1" rather than as "paddleB".

[willyvmm]

@zeegerman1
This joystick is a kind of Chameleon device.
Some other Programmers call it BROKEN DEVICE.

Depending on ... I have no idea what ... it presents itself as a:

SPEEDLINK COMPETITION PRO / Mad Catz (mostly windows)
Game Controller for Android (Saw that on Linux)
Sixaxis/Playstation DS3 (Linux and mouSTer)

This device is already BLACKLISTED fx in. SDL, HWInfo, VirtualBox.

Because it's recognized as a DS3, buttons are remapped to easily support the TRUE SixAxis/DS3 controller.
I can add a config flag to force remapping buttons for that device. That should not be a big problem.
And I am willing to do that only because this is one of the best Pseudo Digital USB Joysticks on the market.

[zeegerman1]

@willyvmm I see - very odd they chose to build it that way. If you could add a flag for the device, that would be great.

[willyvmm]

Everything seems to be working as expected. It has been already fixed. Fw. [3.17.3475 - Pre-Release 3]

The firmware has been upgraded to 3.17.3475, and then I uploaded your config.

This is the label on the bottom side of my Speedlink JoyStick:

[zeegerman1]

@willyvmm very odd! I tried again with the newest 3.17.3475 firmware, but still the same issue.

Looking at the label at the bottom, I see your says "V3" after the article number - mine doesn't have that version indicator (see photo below). What could they have changed between versions that could make the V3 work, but (presumably older ones) not, and is there anything that can be done besides buying a newer joystick version?

[willyvmm]

Let's verify if you have the proper config active.
Put an empty Pendrive into the mouSTer, and attach the generated INI file. (from mouSTer dir)

[zeegerman1]

@willyvmm here you go:
MOUSTER.INI.zip

[willyvmm]

Everything is ok with the config.

Try step-by-step debugging.

Keep the revpotlines=true

Map all buttons to fire:

gbutton01=fire
gbutton02=fire
gbutton03=fire
gbutton04=fire
gbutton05=fire
gbutton06=fire
gbutton07=fire
gbutton08=fire
gbutton09=fire
gbutton10=fire
gbutton11=fire
gbutton12=fire
gbutton13=fire
gbutton14=fire
gbutton15=fire
gbutton16=fire

And verify if all buttons are responding.
If yes, then find what is the correct mapping.

You may also try to map ALL the buttons to paddleA and then to paddleB to verify the correct reading by your Hardware.
In all 3 cases, you should see activity on button 1 for fire, 2 for paddleA, and 3 for paddle B respectively.

I use joyride for tests.
https://csdb.dk/release/?id=219494

[zeegerman1]

@willyvmm when I set all gbutton values to "fire", I see button 1 reacting for all joystick buttons in Joyride.

When I use the following, then buttons 1, 2, and 3 remain without response in Joyride, regardless of which button I press:

gbutton01=paddleA
gbutton02=paddleA
gbutton03=paddleA
gbutton04=paddleA
gbutton05=paddleA
gbutton06=paddleA
gbutton07=paddleA
gbutton08=paddleA
gbutton09=paddleA
gbutton10=paddleA
gbutton11=paddleA
gbutton12=paddleA
gbutton13=paddleA
gbutton14=paddleA
gbutton15=paddleA
gbutton16=paddleA

[willyvmm]

So.
The 1st test tells us, the joystick is OK, and all buttons are reported.
The 2nd - something is wrong. That may be broken SID or mouSTer.

What happened when you set all buttons as paddleB?

[radius75]

Check if you set up in the [GamePad] section
reversepotlines = true

[willyvmm]

@radius75 the revpotlines setting has been already verified here:

@willyvmm here you go: MOUSTER.INI.zip

[zeegerman1]

@willyvmm interesting - it looks like one of my mouSTers is indeed broken.

I just attempted with my second mouSTer, updating to 3.17.3475, and the following gbutton config, and the two large buttons now read as "fire", with the two smaller triangular buttons reading as paddleA and paddleB:

gbutton01=paddleB
gbutton02=paddleA
gbutton03=fire
gbutton04=fire
gbutton05=none
gbutton06=none
gbutton07=none
gbutton08=none
gbutton09=none
gbutton10=none
gbutton11=none
gbutton12=none
gbutton13=none
gbutton14=none
gbutton15=none
gbutton16=none

[zeegerman1]

@willyvmm yes that seems to have been the problem. Tested further with my second mouSTer, and it definitely works now.

Could the other mouSTer have been part of a faulty batch?

[willyvmm]

Can you remember when have you bought it?

[zeegerman1]

@willyvmm one of them I got on April 7, 2021, and one on December 29, 2021. I remember we also swapped one of them because it seemed to have an issue (though I don’t remember which of the two it was (probably the first one), or which of them appears to not work at the moment).

[willyvmm]

Yes. I have received one faulty mouSTer but can't figure out who send it to me!
Please drop me an email, so we can find out how to proceed.
If you don't have my email you can guess it, by concatenating my nick with the "at sign" and the name of the free email service provided by the biggest search provider.

[zeegerman1]

@willyvmm email sent!

[zeegerman1]

Marking this as closed / resolved, as the latest firmware 3.17.3475 did indeed fix the problem, at least on my working mouSTer.