New Saturn to USB adapter config + issues.

[ReadOnlyCat]

Hei Frode,

I recently tested fs-uae launcher 2.6.2 on Mac OS X with a Saturn Controller to USB adapter from Raphnet with the analog MK 80-117 controller (both with this controller's analog and digital modes) and a Psychopad KO from Act Labs.
Buttons mappings were acquired using the simple but effective Joystick Show app.

I have attached the config file for the adapter created by fs-uae and modified by me in case you want to include it with future versions.

Note however that:

• I have modified it to generate Sega-specific

  megadrive_<button>

  button names since the Sega controllers have a distinctive "rows of three buttons" layout which does not map well with the cardinal-points scheme of the universal gamepad.
• the

  make

  entry was set to "RaphNet" (cf URL above) which I guess should be the proper name (or maybe "Raphnet Technologies" as is stated on the web page?).
• for the

  model

  entry, I chose "Saturn Adapter 2.0, MK 80-117" because these are the button codes the adapter generates when an MK 80-117 is plugged-in in analog mode since as you will see below, what gets generated differs depending on whether an analog or digital controller is plugged:
  • when the MK 80-117 controller is in analog mode (it has a dedicated digital/analog switch) it outputs this exact configuration with the subtle detail that the left and right analog triggers generate both analog signals and digital ones (buttons 6 and 7). It could be that the adapter is the one generating these digital signals but I have no way of confirming that yet. (I will write to the author of the adapter to ask him.).
  • when the controller is switched to digital mode, then its dpad now outputs analog signals (with only -max/0/+max values of course) in place of the analog stick ones and the analog stick seems to not produce any signals. The trigger buttons now also only produce digital outputs (still on buttons 6 and 7). The PsychoPad generates the exact same signals so it is probably signalling itself to the Saturn as a digital controller (which it is).
• Also, I have attached a new "sega/saturn.ini" configuration since the Sega buttons do not fit the cardinal-points scheme of "universal_gamepad.ini". This .ini is included from the adapter config file and generates events for the

  megadrive_[a|b|c|x|y|z]

  buttons for the [amiga] and [menu] config entries.
  I am not too sure if this is a good idea but using the universal gamepad logical button names just did not make any logical sense especially with the dual shock looking picture .

All in all, I am not too sure how I should handle the fact that the same USB controller will produce different signals depending on which type of controller is plugged (this type being modify-able live in the case of the MK 80-117) while still giving the same number of axis and buttons and returning the same ID.

In theory the adapter should be able to relay the type of controller plugged since the Saturn controller protocol supports it but in practice it does not (*), so one is faced with the desire of having two different configurations for the same USB adapter generating different events: since dpad events are generated by different signals depending on the mode they cannot be present in the same config file, alas only one config file can be used for the adapter.

I do not exclude however that I completely missed a current perfectly valid way to do it though so I would definitely appreciate some advice.

Also, I initially tried to define the [amiga] and [menu] sections straight into the controller configuration without including the "universal" config via an include statement but this did not work at all. Is there some documentation which explains exactly the inter-relation between .conf and .ini? The input mapping page on the the web site is not too clear about it and I have been successfully resisting the temptation to dig into the source code so far.

Also, I have noticed (cf universal_saturn.ini) that regardless of what action I map to the "start_button" it always does invoke the FS-UAE menu. It looks like the "menu_alt" event is hardcoded on that button. Is this by design?

Thanks in advance for your time and keep up the great job!

(*) I plan to mail RaphNet to ask him whether this could be changed. From what I understand he is receptive to suggestions.

[ReadOnlyCat]

Just bumping this thread gently in case you did miss it Frode.

[ReadOnlyCat]

Frode, I understand that you have a lot on your plate and thus possibly no time to answer/address the points listed in my original post and I certainly do not want to be the annoying guy who bumps a post every week, so could you indicate if there is any chance of you looking at the OP?

It's all fine if you cannot or do not want but knowing whether it might be looked into at some point or never would be helpful to me.

"no time" or "dream on" would be equally fine as long as I know.

Thanks.

[FrodeSolheim]

Hi, it's basically a case of being quite busy for the last week, and tired in the evenings

(A few more days may also pass before I have time to look into this and reply)

[ReadOnlyCat]

Originally Posted by FrodeSolheim

Hi, it's basically a case of being quite busy for the last week, and tired in the evenings

(A few more days may also pass before I have time to look into this and reply)

I can certainly understand that!
Thanks a lot for your answer, I will wait patiently and silently then.

[FrodeSolheim]

Hi, I've started looking over the configs, and here's the initial comments. There are several "issues" to figure out here, and I'm not addressing all of them in this post.

I suggest going with this:

axis_0_neg = lstick_left
axis_0_pos = lstick_right
axis_1_neg = lstick_up
axis_1_pos = lstick_down
button_10 = dpad_right
button_11 = dpad_left
button_12 = dpad_down
button_13 = dpad_up
button_6 = left_shoulder
button_7 = right_shoulder
...

(ignoring axes 2 and 3) - This way, the gamepads should work the same in both analog and digital mode, unless I missed something.

The fact that "lstick_left" is usually analogue isn't a problem here. When a digital joystick uses axis 0/1, FS-UAE will still handle it perfectly well. And as for emulation, FS-UAE automatically assigns both the dpad and the lstick to Amiga joystick movement (at least the standard universal config does this). With saturn.ini, you'd just do the same:

dpad_left = left
dpad_right = right
dpad_up = up
dpad_down = down
...
lstick_left =  left
lstick_right = right
lstick_up = up
lstick_down = down
...

As for including [amiga] directly and not needing the [default]/include, yes, that is possible. But then you must map "more directly", .e.g.:

[amiga]
axis_0_pos = left
button_1 = 1

What happens is that *if* [amiga] is not found in the device config, then it falls back to [default], and here, [default] sets up "virtual names" for the buttons/axes, and includes another config file which translates these virtual names to the real actions. So, with the direct approach, you basically do:

button_1 -> 1

While with the indirect/default/universal approach, you effectively do this:

button_1 -> south_button -> 1

FS-UAE does not really care about the virtual names, which is why it works with for example "megadrive_a", as long as this is *eventually* mapped to a recognized action for "amiga", for example "1" or "left". Hope this helps you understand it better.

So to answer your question about what's the difference between the .ini and .conf files - there isn't really any (and the different extensions are just due to some historical reasons). The system just allows to to have a [default] section which includes another config file if [whatever] (e.g. [amiga]) is not found, and look for [whatever] in the new file, optionally already having translated the input names to something else.

In the end, it still might be both easier and better to just map the buttons/axes to "appropriate" universal actions using the FS-UAE Launcher GUI, even though the system is quite flexible, and it's possible to do it your way (if some issues with saturn.ini is fixed).

[ReadOnlyCat]

Thanks a lot for this very detailed answer Frode! This does make the system much clearer for me now.

Originally Posted by FrodeSolheim

I suggest going with this:

<device config>

(ignoring axes 2 and 3) - This way, the gamepads should work the same in both analog and digital mode, unless I missed something.

The fact that "lstick_left" is usually analogue isn't a problem here. When a digital joystick uses axis 0/1, FS-UAE will still handle it perfectly well. And as for emulation, FS-UAE automatically assigns both the dpad and the lstick to Amiga joystick movement (at least the standard universal config does this).

Ok, this makes sense.
I did not want to map the analog axis (in analog mode) to digital input events because (as is visible in saturn.ini) I wanted to create real analog input events so I could read analog joystick values from my Amiga program but this is not really a priority at the moment. (This said, I kind of recalled having read that FS-UAE currently does not support analog joystick input events, is this the case?)

Originally Posted by FrodeSolheim

What happens is that *if* [amiga] is not found in the device config, then it falls back to [default], and here, [default] sets up "virtual names" for the buttons/axes, and includes another config file which translates these virtual names to the real actions. So, with the direct approach, you basically do:

button_1 -> 1

While with the indirect/default/universal approach, you effectively do this:

button_1 -> south_button -> 1

Ok, I am finally seeing the light.
My error probably lies in interpreting the

virtual_name = input_even

syntax as an assignation when it is actually a mapping:

virtual_name ->generates-> input_even

.

But I recall FS-UAE generating an error for duplicate definition when the two lines below were present in the device config's [default]:

axis_0_neg = dpad_left
button10 = dpad_left

So why is this not generating an error when mapping two different virtual names to the same input event? Shouldn't the virtual name to virtual name mappings be as liberal?

Originally Posted by FrodeSolheim

FS-UAE does not really care about the virtual names, which is why it works with for example "megadrive_a", as long as this is *eventually* mapped to a recognized action for "amiga", for example "1" or "left". Hope this helps you understand it better.

It does! Takk så mye!

Originally Posted by FrodeSolheim

So to answer your question about what's the difference between the .ini and .conf files - there isn't really any (and the different extensions are just due to some historical reasons). The system just allows to to have a [default] section which includes another config file if [whatever] (e.g. [amiga]) is not found, and look for [whatever] in the new file, optionally already having translated the input names to something else.

Oki, I got it. I feel like doing a pass of renaming all of them to .ini or .conf and modifying the code to support only one of them.

Originally Posted by FrodeSolheim

In the end, it still might be both easier and better to just map the buttons/axes to "appropriate" universal actions using the FS-UAE Launcher GUI, even though the system is quite flexible, and it's possible to do it your way (if some issues with saturn.ini is fixed).

I do agree. I would definitely prefer an approach which worked with all possible [stuff] entries without having to duplicate everything like the common/xarcade.ini is doing: this is way too much work and 80% of it is duplication of what is in universal.ini just with (unnecessarily) different virtual names

However, having to use the cardinal-points virtual names and the xbox/playstation image to configure a pad which is very different feels wrong and is completely unclear since the image and available virtual names do not match the actual pad at all.

How hard would it be to modify the code to allow users to provide a custom image with annotations so that non-standard controllers can still be configured visually?
Something like that would be nice:

-- saturn_adapter_______.conf
[sdl]
...
[default]
include = universal
button_0 = megadrive_x
...
[visual]
image = "saturn MK 80-117.png"
megadrive_x = line x1, y1, x2, y2, x3, y3, text x4, y5
megadrive_y = line x5, y5, x6, y6, text x7, y7

[ReadOnlyCat]

Hey Frode, any chance that you will have some time to reply to my last post?
No worries if you do not have time, I can wait a bit more.

Cheers!