Newly created Mr. Spinner does nothing in MiSTer

[Tackemon]

Just completed soldering two buttons and a rotary encoder to an Arduino Pro Micro with code based on this adapter code:
https://github.com/MiSTer-devel/Retro-C ... rollersUSB

I modified the Arduino code to report buttons 1 and 2 on the same gamepad, but the encoder code is untouched. In my case, I wired directly to the board rather than make an adapter. I'm using an encoder only (no potentiometer).

In Windows, both buttons work fine and both Wheel and Dial work with the encoder in the USB controllers UI.

In MiSTer, my button 1 works as the main button in the Atari 2600 core and button 1 in arcade cores, but I get nothing in Night Driver or Super Breakout with the knob. I also tried the Arkanoid and Super Breakout arcade cores, selecting "Spinner" or "Paddle" as appropriate. Nothing.

I tried my new spinner on a different Windows machine, and everything seems to be fine there. I even tried it on a newer version of MAME. I got weird results on some games, but I think it's more MAME weirdness with certain ROMs. In Arkanoid and Tempest, I could move the paddles, etc, but there was a huge dead zone, and then it acted like a joystick (the paddle would keep moving when the knob was to the left or right but not moving). In those two games, MAME wants a "Dial." But in Outrun, MAME wants a "Paddle" for steering and I was able to steer the Ferrari very nicely.

I see there's a special ID of "MiSTer-S1 Spinner" that's supposed to have special MiSTer support. What does that buy us? I've done plenty of Googling on that, and I still don't quite get it.

I can't help thinking that I should change the code to report the spinner as a mouse X axis (and my two buttons as left and right buttons maybe?). It seems like that would be far more compatible with MiSTer and other platforms. What would be the down side?

Suggestions?

[jimmystones]

Have you tried the Input Test core (in Utilities)? The advanced mode should at least tell you what the controller is showing up as in MiSTer, if anything.

[aberu]

Can you attach a copy of the code after you modified it?

[Tackemon]

Have you tried the Input Test core (in Utilities)? The advanced mode should at least tell you what the controller is showing up as in MiSTer, if anything.

Just tried that. I get JOY1 A from my button 1. Nothing from button 2 (it shows up consistently in Windows as Button 2 though).

The only other thing I get from the advanced mode is a static 127 on PAD1.

[jimmystones]

Hmm, I'll be honest I dont have a spinner myself - anyone around who does that can confirm whether any manual mapping is usually needed?

[Tackemon]

Can you attach a copy of the code after you modified it?

Attached.

Mainly in Gamepad.cpp I changed this from 1 to 2:

Code: Select all

0x29, 0x02,                   // USAGE_MAXIMUM (Button 2) - Steve changed this to 2 to support 2 buttons

I yanked a bunch of stuff out and "unlooped" the multiple gamepad code in PaddleTwoControllersUSB.ino by just setting idx to zero, but this is the only real change (to report button 2 on the same gamepad):

Code: Select all

// spinner button #2
    if(!digitalRead(dbtnpin[1]))
    {
      rep.b1 = 1;
    }

[aberu]

Next thing, did you download the new new linux update that came out today? It changed back to the old usb drivers. I was about to start looking into your changes, but noticed the new linux update, and that might help.

[aberu]

Okay, so the big changes were in PaddleTwo ControllersUSB.ino. I'm no expert but maybe I can help notice something... The main reason I'm looking over this is to help me learn too by the way, so feel free to correct me on anything.

So you changed it to two buttons with this:

first change.png (18.23 KiB) Viewed 4015 times

I think you are right to assume that you didn't need to change REPORT_COUNT. Next, in PaddleTwoControllersUSB.ino:

second area.png (81.12 KiB) Viewed 4015 times

Important to mention, you don't need to remove the lines, if you comment lines out, the compiler will ignore any comments and it won't make any difference to the memory used or the performance on the Arduino. It will make it easier for you to debug and troubleshoot in the future if you just comment out lines you want to remove, so you can work through what you did and where.

Next you change to single input, that's good.

Next you removed #ifdef BEETLE from the beginning of the pins map on line 93 in the original. Is that important? Personally this was removed needlessly as there is already a switch to turn it on, that is turned off by default. This could be ignored as it won't impact the compile or the performance, since it's switched off anyways.

You converted the "driving controller button" into "two buttons" but it's still

Code: Select all

const int8_t dbtnpin[2]   = {6,15};

. Nothing about this has changed, but it's gone from being one button to two buttons.

Also on line 175 of the original, you removed

Code: Select all

for(int idx=0; idx<DEV_NUM; idx++)

and replaced it with just

Code: Select all

int idx=0;

. But isn't DEV_NUM important above?

Also I kinda have heard C is not super indent intensive like something like python, but when I use a format in vs-code, the indents are very different. I also suspect the following has some issue after being changed, but can't quite put my finger on it:

Code: Select all

pinMode(dbtnpin[0], INPUT_PULLUP); // Button 1
pinMode(dbtnpin[1], INPUT_PULLUP); // Button 2

Not sure if any of this helps. Personally when I edited the daemonbite code for my purposes, I just commented out something and turned another thing off, as opposed to deleting lots of lines. the if else statements here at time of compile will rule out things and not include them in the final product if you turn off the flags for them.

[Tackemon]

Next thing, did you download the new new linux update that came out today? It changed back to the old usb drivers. I was about to start looking into your changes, but noticed the new linux update, and that might help.

I just did update_all, assuming that will grab the driver changes. No difference.

[Tackemon]

Also on line 175 of the original, you removed

Code: Select all

for(int idx=0; idx<DEV_NUM; idx++)

and replaced it with just

Code: Select all

int idx=0;

. But isn't DEV_NUM important above?

Code: Select all

pinMode(dbtnpin[0], INPUT_PULLUP); // Button 1
pinMode(dbtnpin[1], INPUT_PULLUP); // Button 2

The original code is set up to report buttons and paddles across two HID gamepad controllers. Or at least that's how I interpreted it. Since I'm making a single controller and not an adapter that can do all sorts of things, it made more sense to me to just have the two buttons (and the dial/spinner) on the same gamepad. So that's all I did.

I was thinking in terms of Tempest (maybe we'll get an arcade core of that someday?) that had two buttons: the main fire button and "super zapper."

I yanked stuff out that was extraneous just to make it easier to read, since I don't need to support various configurations. Though I suppose if I get it working, I could post a cleaned up even shorter version in case anyone else out there wants to just build the same thing.

Stuff like DEV_NUM isn't relevant any more, since I removed the looping anyway and just forced idx to zero. If it was code I was intending to share, I'd clean it up quite a bit. Like, there's no need for the arrays and looping through two controllers and such any more.

You are correct, C doesn't care a bit about indenting. In fact, Python is the only language I've encountered that does.

The dbtnpin[0] and dbtpin[1] is just a convoluted way of saying pins 6 an 15. Note that the buttons do work in Windows, so I think the button stuff is fine? I'm mostly puzzled on why I'm getting Wheel and Dial to both show up in Windows, but MiSTer is like, nah.

[Tackemon]

I went ahead and tried reverting to the original code just for grins. Only change was commenting out PADDLE_SUPPORT (no potentiometer) and setting the PPR to 600. With DEV_NUM set to 1, I had to re-assign the button pins to what I've already soldered in. No difference.

Just for grins, I even tried DEV_NUM set to 2, and restored the original "driving" pins. As expected, with DEV_NUM 2, it shows up as two separate gamepads. The first gamepad has button 1 as its only button and the second gamepad has button 2 as its only button. I think the idea is to support both an encoder and a potentiometer at the same time. It reported Wheel and Dial in exactly the same way on gamepad #1. Made no difference to MiSTer. That's NOT what I want anyway.

Gotta say, it would seem that MAME supports arbitrary axes better than MiSTer at this point.

[aberu]

Thanks for helping me learn a bit, it was interesting. I hope you get it figured out! Good luck!

[Flandango]

Try this:
In your original code (that you attached), in Gamepad.cpp change:

Code: Select all

0x25, 0x01,                   // LOGICAL_MAXIMUM (1)

to

Code: Select all

0x25, 0x02,                   // LOGICAL_MAXIMUM (2)

[Tackemon]

Try this:
In your original code (that you attached), in Gamepad.cpp change:

Code: Select all

0x25, 0x01,                   // LOGICAL_MAXIMUM (1)

to

Code: Select all

0x25, 0x02,                   // LOGICAL_MAXIMUM (2)

My understanding is that the logical min/max is to define what states are available. So for a button, you have 0 or 1. Changing the LOGICAL_MAXIMUM to 2 would imply a 3-state switch I think. I mean, I tried it anyway, but it had no effect.

I found this guide to HID report descriptors that describes that stuff:

https://eleccelerator.com/tutorial-abou ... scriptors/

On a side note, it looks useful as a guide to just bail and set my encoder to drive a mouse X and have the buttons to go mouse left and right buttons.

[Tackemon]

OK, I ended up changing the code extensively to report as a mouse. Haven't quite got the buttons working as mouse buttons, but I'm sure I'll get there.

So now the encoder reports as a mouse X axis with Y forced to zero. Probably wouldn't hurt to just set Y to the same value. Even with the arcade Arkanoid core set to mouse control though, MiSTer will STILL not do anything. A real mouse does work though. Maybe MiSTer wants at least a two button mouse or something?

I was able to play Tempest and Arkanoid in MAME and it works GREAT. No jitter or anything. I need to bump up the base sensitivity a bit, but MAME has per-game sensitivity which is fine for now. Getting the two buttons working as mouse buttons will make it a complete Tempest controller.

Ended up installing an Atari 2600 emulator called Stella. Was able to play Night Driver, Super Breakout, Astroblast, and Warlords with my spinner, no problem.

This is a good example of software emulators being a good companion to MiSTer I guess. Part of the learning curve is figuring out what state we're in with some of this edge case stuff. I do hope that support for arbitrary axes improves over time. If we ever get an Out Run core or similar games, imagine using a PC gaming wheel / gas / brakes / shifter, for example. Hmm, might have to try that with MAME!

[sonik]

I think mr. spinner support is hardcoded on the mister.
Take a look at input.cpp

[Tackemon]

I think mr. spinner support is hardcoded on the mister.
Take a look at input.cpp

I've pretty much given up on MiSTer support for now. I got my buttons working as mouse buttons, so games on PC emulators are working great. MAME in particular doesn't seem to handle "gamepad" style spinners right anyway. MiSTer still doesn't recognize my controller as a mouse, even though Windows does. A commercial mouse does get recognized for some reason though. Honestly, Arkanoid doesn't play that bad with a mouse. I might try replacing the pots on my real Atari paddles too (those at least do work via the SNAC Atari 2600 core, just not that well).

Not a bad idea to look at the MiSTer code itself though. Haven't looked at that before.

In input.cpp, it looks like there's some hard-coded stuff for specific spinner models by specific vendor and product ID. Not that relevant, but kind of interesting.

Code: Select all

//Arcade Spinner TS-BSP01 (X axis) and Atari (Y axis)
if (input[i].vid == 0x32be && input[i].pid == 0x1420)

This seems to imply that mice can be reported as a spinners?

Code: Select all

//All mice as spinners
if ((cfg.spinner_vid == 0xFFFF && cfg.spinner_pid == 0xFFFF)
	//Mouse as spinner
	|| (cfg.spinner_vid && cfg.spinner_pid && input[i].vid == cfg.spinner_vid && input[i].pid == cfg.spinner_pid))

Not sure I follow that. Some extra parens sure would help.

This is also hard to follow (no comments either):

Code: Select all

if (inp->spinner_accept && diff)
		{
			inp->spinner_prev = ev->value;

			if ((inp->misc_flags & 0x1F) == 0xB && ((inp->misc_flags & 0x20) ? (diff < -30) : (diff > 30)))
			{
				inp->misc_flags ^= 0x20;
				Info((inp->misc_flags & 0x20) ? "Spinner: Enabled" : "Spinner: Disabled");
			}

And here's the "magic" ID it's checking for:

Code: Select all

// mr.Spinner
// 0x120  - Button
// Axis 7 - EV_REL is spinner
// Axis 8 - EV_ABS is Paddle
// Overlays on other existing gamepads
if (strstr(uniq, "MiSTer-S1")) input[n].quirk = QUIRK_PDSP;

Then QUIRK_PDSP is checked in various places, but that's about when I lost interest I guess, haha.