QuadTari support

[thrust26]

More info here: https://atariage.com/forums/topic/305226-quadtari/?do=findComment&comment=4618277

multitap_test.zip

[thrust26]

TODOs:

• ~implement and integrate new controller class~ (done)
• ~enhance GameInfoDialog~ (done)
• ~enhance StellaSettingsDialog~ (done, R77 should support QuadTari via OTG)
• ~enhance ControllerDetector~ (done, 'QUADL'/'QUADR')
• ~new debugger widget~ (done)
• ~new events for 3rd and 4th joystick~ (done)
• ~enhance PKeyboardHandler~ (done)
• ~enhance DefProps generation~ (done)
• ~support controller types other than joystick~ (done)
• ...?

If other or even multiple controller types per port are allowed, the might be more changes required.

[sa666666]

It seems to me the controller type for the port should be 'quadtari', and it should contain two other controllers as instance variables. This is closely related to how the real hardware works, as it plugs into a port, and then other controllers plug into it. And the 'quadtari' controller can issue commands/make changes to the underlying controller instances.

Of course, that brings up the issue of how to specify a controller, since technically when you say a 'quadtari' is plugged into a port, you really mean that two other controllers are plugged in too. So we'd need a way of saying that both a quadtari is plugged in, and a joystick/paddle, or joystick/AVox, etc, are plugged into that.

[thrust26]

Yup, that's where it starts getting complicated. We would have to e.g. enable QuadTari mode and then handle four ports instead of two.

And I have to come up with a good idea for the GameInfoDialog/Controller tab which doesn't make it overly complicated. A sub dialog (or something like that) only for the QuadTari (plugged into one or both ports).

I am pretty sure this controller will have other side effects which we will find during implementation.

[sa666666]

Maybe the type could be defined as "quadtari_x,y", where 'x' and 'y' are one of the current controller types. So "quadtari_joystick,paddles" uses joystick for 'left' controller (for that port), and paddles for the 'right' controller. And by default, if one specifies only "quadtari", it really means "quadtari_joystick,joystick".

I don't doubt that other issues may pop up, but I don't see it requiring major changes to the code. I suspect the UI will be the hardest, in how we present the info to the user. Also, we would need another set of events at least.

[thrust26]

Internally we could use such long definitions. But as you say, that's nothing for the UI.

[sa666666]

It would also be best that for one of the joysticks plugged into a quadtari, it would use JoystickZero events. That corresponds to the case where JC said that if only one joystick is plugged into the device, it acts as if the joystick is plugged directly into the port. The same would apply for the right port and JoystickOne events.

Internally we could use such long definitions. But as you say, that's nothing for the UI.

Well, in the UI it could simply be checkboxes or something. No matter what, it's going to require another dialog specifically for quadtari configuration.

[sa666666]

Also, I wouldn't worry about the dialog/configuration for now. The more important part is making sure it's possible with the current framework, getting it working for at least the common cases: joystick/joystick, joystick/avox, etc.

[thrust26]

It would also be best that for one of the joysticks plugged into a quadtari, it would use JoystickZero events. That corresponds to the case where JC said that if only one joystick is plugged into the device, it acts as if the joystick is plugged directly into the port. The same would apply for the right port and JoystickOne events.

Definitely. We then will have JoystickTwo and JoystickThree events. And if other controllers are supported even more of these duplicated events. But I suppose besides AtariVox or SaveKey there will be not that many other controllers used.

Also, I wouldn't worry about the dialog/configuration for now. The more important part is making sure it's possible with the current framework, getting it working for at least the common cases: joystick/joystick, joystick/avox, etc.

For a start we could only support joystick/joystick and call it QuadTari. And if other combinations are used then we enhance the GUI.

[thrust26]

It seems to me the controller type for the port should be 'quadtari', and it should contain two other controllers as instance variables. This is closely related to how the real hardware works, as it plugs into a port, and then other controllers plug into it. And the 'quadtari' controller can issue commands/make changes to the underlying controller instances.

Of course, that brings up the issue of how to specify a controller, since technically when you say a 'quadtari' is plugged into a port, you really mean that two other controllers are plugged in too. So we'd need a way of saying that both a quadtari is plugged in, and a joystick/paddle, or joystick/AVox, etc, are plugged into that.

I wonder how to define the ports/controllers of the two controller instances. We could extend the Jack enumeration by adding e.g. left2 and right2. But there is a lot of code relying on the two existing Jack values and we might break or have to rewrite it with additional values. Alternatively a simple boolean (e.g. player 0 vs player 2) which is just used for the input mapping would do. But I doubt this will be sufficient. And to make things more complicated, the 2nd controller in each port (re)acts like a controller in the other port.

Both alternatives seem not to fit well. Because now we have the two console ports and on top of each the two QuadTari ports. So in the former we address the console ports, for the latter we address the controllers. Until QuadTari this was always the same (except for Compumate, where have special code for one controller in two ports), but this has changed now. Maybe we need a 2nd enumeration?

@sa666666 what are your preferences or ideas here?