mame: move dip switches to regular input

[vadosnaprimer]

Initially I thought having them as sync settings would be enough, but for games that only let you configure them based on switch positions, that requires a workaround of subtituting saveram and sync settings to simulate hard reset. More details here: https://tasvideos.org/Forum/Posts/524851

So it seems it would make sense to move dip switches to regular input just like they are in actual mame. And that also involves adding some way to hard-reset the machine (mame has that command but I don't remember if it's exposed via hotkeys, maybe only lua).

see also #3203

[OtakuTAS]

The only issue to your plan is they are locked on, meaning input would need to remain locked on.

As stated in the TASVideos thread, I own around 150 arcade machines and worked with 12 hours a day and know all the ins and outs particularly of the older variety. A majority of machines (90% and higher) read the switches at boot and then they are not accessed again, effectively ignored for the rest of the run cycle as they aren't accessed with code. So the abuse concern during a run would likely be nil. There are a few that continue to read them though and update the game, and then some that continue and don't update the game, and then some that don't update it all the way and create glitchy results. (i.e. adds lives but this is not shown in the life counter)

Approaching the late 1980s most manufacturers used a dipswitch to access a service mode (not always accessible using the service button, which will usually just adds credits for free play for the operator without disrupting settings, but a few manufacturers allow opening the service menu with a button - not many however), and then the dipswitches were virtual and set using SaveRAM and held by battery. This eliminated all of the dipswitches but one, but did rely on a SaveRAM. Games prior to this either didn't have SaveRAM at all (games like Pac-Man have a "high score" reading but the reality is this is the high score for the day and it resets every night as soon as you shut the power off), or didn't use the SaveRAM for dipswitches.

So in the late 80's this became quite standard with 1 dipswitch and others being virtual dipswitches, however prior to that it was usually around 20 physical dipswitches. For things like coinage settings, this usually took up a whole bank of 10 dipswitches, as a switch has 2 settings... so for 10 different options, you'd need a lot more switches and a hell of a lot more combinations to do what you want.

Hope this helps

Glad to see this fixed

OtakuTAS

[vadosnaprimer]

The only issue to your plan is they are locked on, meaning input would need to remain locked on.

What does that mean exactly?

[OtakuTAS]

The only issue to your plan is they are locked on, meaning input would need to remain locked on.

What does that mean exactly?

They are like light switches, not like a button. Not sure how that would correspond in TAStudio. Input is locked and held of course.

[OtakuTAS]

http://arcaderestoration.com/Media/Graphics/misc/dipswitch.jpg?x=150

[vadosnaprimer]

So just a toggle.

[YoshiRulz]

see also https://github.com/TASEmulators/BizHawk/issues/2048#issuecomment-634026908

[vadosnaprimer]

Yeah I mean how do we have a toggle input that you don't have to manually keep in the last position for the entire movie? Is there a way to toggle input once and make its state persist? Previously I thought analog would work for that, but analog has mid state which it returns to unless you keep overriding it on new frames.

[CasualPokePlayer]

A toggle input would by its nature would just be an indication that the "switch" should be flipped in the other direction. If it's not pressed, nothing happens. If it is pressed, it either flips the switch off to on or on to off.

If you don't want to allow "toggling" them every frame then just make an additional sync setting for only consider the newly toggled inputs on hard reset, or maybe forgo the setting and just only consider the dipswitch inputs on hard reset. Or don't bother limiting it and only apply such a restriction on movie rules or whatever.

[vadosnaprimer]

A toggle input would by its nature would just be an indication that the "switch" should be flipped in the other direction. If it's not pressed, nothing happens. If it is pressed, it either flips the switch off to on or on to off.

Do we have cores that do it that way? IIRC A2600, right?

[OtakuTAS]

Maybe you can just have the inputs in the first frame of the movie in those columns repeat infinitely, but only be editable in the first frame? For stylistic choice, you can also gray out rows 2 and further in those columns.

This prevents abuse, prevents games that have issues with the switched being changed mid-operation, and so on.

The only other issue with this is the massively different amounts, variables, etc., for all the different game. It's not standard whatsoever and it's all over the place, but thankfully the MAME database has the years of work for that, so I'm guessing you guys already have that handled. It's not like an NES where you can expect what controls to be there, nor where they point to whatsoever. It's a wasteland. Some games have 1 option, some have 20+, and they all point to different memory addresses. That's already handled that way in the sync settings, so I'm assuming that's not a problem.

[YoshiRulz]

As natt wrote years ago, these really are a third type of input, distinct from axes. It shouldn't be that hard to implement on the back-end (copy-pasting the axis implementation will do), but the UX has to be completely different.