KeyPortari controller emulation (draft)

[DChristianson]

I'm working on a project that uses KeyPortari and was looking at adding support to stella for ease of testing (I don't have the hardware). This is a first pass, hope I'm interpreting the code right... (and apologies if I am missing any code style or contribution guidelines)

• Derived from CompuMate support
• Sends the ASCII code of typed key to joystick ports
• Has just enough keybindings mapped to test typing on TinyELF basic and 24 char console examples
• Some keys still trigger other handlers (you can't write a capital T)
• Does not allow rebinding/saving of configuration or other niceties

[thrust26]

At first glance I spotted a new checkbox in GameInfoDialog. Why is it required? If this is a new controller, it should be added to the dropdown only.

BTW: Can this be autodetected?

[DChristianson]

Thanks for looking at this.

Why is it required? If this is a new controller, it should be added to the dropdown only.

So this is a way to say "use KeyPortari in conjunction with two passthrough controllers that will be attached to the KeyPortari". KeyPortari allows you to connect a regular keyboard using both ports but also pass through to other controllers (joysticks, paddles etc). If no key is pressed the value will be read from the passthrough. There are also some behaviors depending on KeyPortari settings (those settings still need to be modeled)

So my thought was either

• try to discreetly add to the UX to be able to set all the options independently (KeyPortari + whatever controllers are selected + protocol)
• use dropdown with a typical combination of use cases (KeyPortari + Joystick, KeyPortari + Paddle, etc). But this could get weird fast
• only use autodetect or some other scripted way of setting these crazy options

BTW: Can this be autodetected?

I only have a couple of sample programs in front of me I think it could be possible to recognize the code seen in them as distinct usage from other kinds of controllers.

Doc link is here: https://forums.atariage.com/topic/382423-keyportari-docs-links/

[thrust26]

Hm, isn't that similar to the QuadTari? So when you select a KeyPortari, the 2nd controllers can be selected on a separate dialog? Except that there is only one per port, not two.

[DChristianson]

Hm, isn't that similar to the QuadTari? So when you select a KeyPortari, the 2nd controllers can be selected on a separate dialog? Except that there is only one per port, not two.

Yes, similar. I'm going to look at using a separate dialog. This would also help in being able to configure the different options for keycode mapping supported by the actual hardware (that I didn't support fully in the first pass).

If I switch this MR to configuring the KeyPortari from the dropdown, it's important for users to know it should be configured to use both left and right ports in order to process keys correctly (uses pins on both ports to encode keypresses) - wondering if there's a way to document this or message the user?

[DChristianson]

@thrust26 I've made some updates if you have thoughts on whether this is heading in a proper direction.

Configuration:

• I've changed the way the KeyPortari controllers are configured by using controller dropdowns in a manner similar to the QuadTari
• Also similar to QuadTari, there is a new button to launch a configuration dialog for KeyPortari specific properties.

How it works now - want to make sure I'm not misinterpreting how controllers were intended to be used:

• When no key is pressed the KeyPortari controller objects attached to each controller port rely on having access to a shared handler object to determine if a key has been pressed and then act accordingly (send the key code or try to use passthrough).
• This means if one controller is wired up things should work exactly as if a KeyPortari was only connected to that one port . This may be an undesirable combination but - it is physically possible to do...
• One concern I have is that due the independence of the controllers the routine to figure out what key press happened fires twice, and that means iterating over all possible keys twice. I'm wondering if that cost is acceptable and if not should I avoid that iteration or keep it but make sure it only happens once.

I've also attempted to make sure the docs and build is up to date for all systems, although right now I am only set up to test macos/XCode. Frustratingly in the process of me getting SDL3 working I wound up touching framework config and XCode wound up changing GUIDs in the xcodeproj.

[thrust26]

Sorry, but I am currently very busy, so I do not have the time right now. @sa666666, @DirtyHairy maybe you could have a look?

[DirtyHairy]

Looks sensible to me. There are a few parts of the code that are not quite clear to me, but as a understand this is a work in progress, I'll hold back until it is finished 😏 As for the repeated iteration: I don't see a good way around it without more invasive changes.

[DChristianson]

There are a few parts of the code that are not quite clear to me, but as a understand this is a work in progress, I'll hold back until it is finished

Sure thing, thanks for the quick look!

[sa666666]

I agree with @DirtyHairy. Once you are closer to completion with this, we can consider it. For now, I'll try to find time to review what you've done so far.

[thrust26]

@sa666666 Did you have a look already?