Do these sticks have an indicator pointing to the same direction as the on-screen action?
Nope, but they
could. The same side of the stick is always pointing straight up when the character is pointing straight up.
Also, are ALL of these games 12-way or are there 24-way and 6-way and whathaveyou? And if so, how do you manage these?
Nope, all the games using mechanichal rotary sticks are 12-way.
There are some other games that always come up when we get to talking about rotary games, that used different hardware: Xybots, Frontline, Cal. 50.
Xybots had a stick that didn't rotate all the way, it went a little less than 1/2 a turn either direction. Twisting it contacted either a "Turn Right" or "Turn Left" switch. MAME already correctly emulates this, by mapping "Turn Right" and "Turn Left" to button presses.
Frontline (and Tin Star & Wild Western) used a 8-way joystick with a knob instead of a regular handle. When you twisted the knob, it rotated an actuator that would contact the correct microswitch(es) to point the gun in the correct direction. You could also call this an 8-way rotary, but it does not use an 8-position switch, but rather 4 microswitches, just like a joystick. MAME already correctly emulates this, with aiming handled by the "P2 Joystick" controls.
Cal. 50 used a rotary joystick with an optical encoder wheel on the bottom. MAME already correctly emulates this, by using the "Dial" control type.
Don't get me wrong, for someone with a couple of GP-Wiz49 interfaces, direct input connection would be fine (there should be plenty of free inputs for it.)
Agreed. Two rotary joys could even be handled by a single GP-Wiz Eco, for less than $20.
If MAME were fixed.
but the problems may very well be mame's fault, not druin's. does MameAnalog+ work 100% correctly with druin's board?
The problem
is MAME's fault. MAME is forcing us to use an extra piece of hardware to translate an simple bit of absoulte data (which way is the switch pointing) into some very non-absolute data (how long were you twisting the knob), which MAME then attempts to re-translate back into absolute data (where would the switch be pointing if you turned it for x number of nanoseconds), and the result is that your guy doesn't point where he should.
Analog_+ works perfectly
without the Druin's board. It just doesn't support all the games.
It would be possible to build a USB rotary interface that did not require a keyboard encoder. It could have 2 headers for 2 rotary joysticks and a single USB plug. It could also have an on/off switch to prevent key presses when not in use. The interface could be designed to implement either a USB keyboard or joystick using HID drivers. The cost would probably be about the same as a standard rotary interface, but it would be easier to wire and not require any keyboard encoder inputs.
Why save keyboard encoder inputs by building a whole extra encoder? I just don't get this thinking. Again, don't get me wrong. If you build one, and it works better than what we've got now, good. But fixing the software seems like a superior fix in this case.
based on the code in snk.c, the ROM reads 4 bits from an input port and expects to see a number from 0 thru 11, so the 12 switch inputs must have gone through a hardware encoder.
If that's the case, then it was on-board the original PCB, and all it did was translate a simple closed circuit into a number. Can you tell what's feeding that number to snk.c now?
If you had 2 joysticks wired up using 24 inputs than there would always be 2 key presses being sent to the computer, which could be annoying when not playing a game.
If this proved troublesome, a dpdt switch wired to the ground for the rotary switch could be used to kill them when not in use.