Ultimarc rotary encoder issues

[Rip]

title was: Why are digital rotary joysticks set up as analog controls in MAME?


I just bought a very simple rotary encoder from Ultimarc for my Ikari style rotaries.  Simple enough...they generate a [ on left clicks and a ] on right clicks.  I checked this out independently on notepad and it is perfect.

I go into MAME and setup the "dial" control (MAME 0.113 introduced "positional" controls for Ikari games but basically the same thing) settings to map to these key strokes.  I would think that'd be enough, but then I have to go jack around with dial (speed an sensitivity).  No matter what I do, it is impossible to get a 1 to 1 click setting.


Any ideas?

[Rip]

I just read Derrick Renaud's recent thread on this issue and have made the correct settings for Ikari games

http://forum.arcadecontrols.com/index.php?topic=60720.0

Positional Speed = 0
Positional Sensitivity = 100%

Yet it still misses clicks ?!  Again in notepad the [ and ] happen perfectly without fail.

Is it possible the Ultimarc encoder is not generating a long enough keypress?

[MaximRecoil]

Why are digital rotary joysticks set up as analog controls in MAME?

It's a hack I guess. Why are hacks like this acceptable, but other hacks to enhance playability on a PC, such as speed-up hacks for games that run slow on currently available PC hardware, are not? I wish MameDev were consistent with their ideology.

Is it not possible to compile a version of Mame and/or the Ikari Warriors Mame driver that accepts 12 discreet digital inputs, one for each rotary position, like the actual hardware does? Then you could just use 12 inputs on any old keyboard encoder, with one wire of the rotary switch's harness for each of the 12 positions and it would be perfect. There are actually 13 wires in an LS-30 rotary switch harness, but I believe one of them is ground.

[2600]

Are you actually using MAME > 113?  If not, you will not get a 1 to 1 click setting.

If you think it is the Encoder, then try a keyboard to prove that it is either the encoder or joystick.

[Derrick Renaud]

This post is not directed to anyone in particular, so do not take the rant as a personal attack.  It's just time to vent a little and clarify some things.    

In the newest versions of MAME, using Digital Speed = 0, and Sensitivity = 100% should exactly change 1 position in positional controls.  The behaviour for other controls is a little unpredictable due to some drivers hacking the mouse data to simulate the original control.  That is why I came up with the positional type, so it would create a standard type control.  One day it might be expanded into the "1 of X" type control of the original Ikari game.

Something that people who complain about "MAME not being consistant in their standards" forget, is that MAME is an ongoing project.  Things are constantly being updated.  New features may only be added to certain drivers and not others.  I know its hard to believe but every Dev does not intimately know all 6000+ games, so some drivers miss getting updated to new features.  Over 10 years, some drivers may have not been updated for a while.

Analog controls are really a misnomer in MAME.  There is really no such thing.  Every input port type is digital.  MAME only concerns itself with the data received by the CPU.  Which is digital.  As far as MAME is concerned, any input that is not just 1 bit data is considered analog.  This is so all the scaling and conversion (eg. inc/dec buttons) features can be applied to it, allowing for a variety of computer connected controls to emulate a variety of original hardware.  If you want to enforce rigidity on the standards we could start by removing inc/dec button controls, not allowing joysticks to be emulated by mice, etc.

As far as the IKARI controls being emulated as 4bits instead of a 1-of-12 positional control, this is because that is what the CPU receives.  The original control is connected to a ROM (at least in gwar it is) that outputs the data to the CPU that is currently emulated in MAME.

With the new positional code dividing an analog joystick into 12 chunks for ikari controls, I'm supprised no one has figured out that you should be able to create an easy joystick interface for it.

Finally a little bit of a rant.  For those who think MAME should do this or that, or fix X driver because it does not follow the standards of Y driver.  Remember this is a hobby done by people on their spare time.  Feel free to offer constructive criticism.  But things only get changed when someone finds the time/motivation to change it.  So feel free to delve into the code to change your favorite pet peeve.  I had to learn electronics and programming on my own.  I have to delve into the code to figure out how MAME works and make the changes for what I want it to do.

There are all sorts of features I want to add to MAME.  If anyone wants to pay my yearly wage so I can quit my job and solely work on MAME, then these features will get added quicker.  Until then, just like anyone who has added code to MAME, I have real life issues to attend to.  So I only get a chance to work on the code when the time and motivation is right.

D.

[Ed_McCarron]

So I only get a chance to work on the code when the time and motivation is right.

And, the majority of us realize this and applaud you (and the others) for it.

Thanks!

[Derrick Renaud]

So I only get a chance to work on the code when the time and motivation is right.

And, the majority of us realize this and applaud you (and the others) for it.

Thanks!

You are welcome. 

Just some further clarification.

I never took anything in this thread as a personal attack against me or any of my code.

I was just trying to clarify why there are inconstancy's in MAME.  Every forum on the internet that mentions MAME, always attacks MAME for being inconstant in their policies.  While forgetting that they are pointing out 1 small thing in 6000+ games.  And not realizing how easy it is to miss something in MAME's huge multi-megabyte source code.

So when people mention that X has been done, so that means MAME should allow Y.  Talk like that usually means that X is removed too.  It's just easier to fix that way.

FWIW, I want to see the analog menu completely removed.  The name is confusing.  In it's place would be a control X setup menu.  That means when you go to the player controls menu, instead of seeing Player 1 Trackball X analog, inc, dec items, you would see a Player 1 Trackball X setup item, that would bring up another menu that would group the analog input with the inc/dec buttons and the items from the analog menu (Digital Speed, Sensitivity, etc).

D.

[MaximRecoil]

I was just trying to clarify why there are inconstancy's in MAME.  Every forum on the internet that mentions MAME, always attacks MAME for being inconstant in their policies.  While forgetting that they are pointing out 1 small thing in 6000+ games.  And not realizing how easy it is to miss something in MAME's huge multi-megabyte source code.

Those inconsistencies in policy would probably not be brought up all that often if it were not for all the disciples who preach with fervor the "For Preservation, Not For Gameplay!" gospel. For example:

Mamedev wouldn't care if NONE of the games run on current hardware. Their stated mission is to preserve these classics in as close to original form as possible.
The fact that hardware has progressed to the point that many of them are usable is just a bonus.
Those that don't contribute to the cause (and I consider myself among that number) should just be grateful that we are reaping the benefits of their work.

"Boo-hoo-hoo, Pacman is only 3 times faster than it needs to be. If those know nothing devs didn't mess with the code it could be 5 times faster than required, then the world would be all rainbows and lollipops."

Gimme a break.

[ahofle]

There are all sorts of features I want to add to MAME.  If anyone wants to pay my yearly wage so I can quit my job and solely work on MAME, then these features will get added quicker.  Until then, just like anyone who has added code to MAME, I have real life issues to attend to.  So I only get a chance to work on the code when the time and motivation is right.

If I were rich I would do just that.  Seriously.
Your work is much appreciated.  In addition, you are very civil to users despite owing them nothing.  I can only imagine how hard that must be given that I write software in the real world for users I can't stand.  Thanks for all your work.
 

[Rip]

Are you actually using MAME > 113?  If not, you will not get a 1 to 1 click setting.

If you think it is the Encoder, then try a keyboard to prove that it is either the encoder or joystick.

Yes.  I am using 113u2 (MAME32) and using the positional setting games.  Here is how it behaves.

In Guerrilla War (gwar):

Regular keyboard gives a 1 for 1 click (using the [ and ] keys)
Ultimarc encoder (USB) misses clicks consistently (but not always the same place)

In notepad:

Regular keyboard seems to generate a 1 for 1 click (using the [ and ] keys)
Ultimarc encoder (USB) gives a perfect 1 for 1 click

So I am stumped.  It can't be the encoder because it works flawlessly outside MAME.  It can't be MAME because the regular keyboard seems to work. 

Could it be a USB conflict within MAME?  Does MAME recognize one USB HID (my regular kb) over the Ultimarc HID (the encoder)?  Maybe a DirectInput issue?

p.s. - I am not dumping on the devs...just curious and looking for any tips.  This may force me to crack open the once and for all.

[Rip]

I downloaded the Passmark KB test application to see how long the key
presses are. This shortest keypress I can generate on my kb with the [ and ]
keys is 15ms. The encoder only generates somewhere between 7ms and 15ms
keypresses, usually on the 7-8ms end. Could this be too short for MAME to
recognize?

[Rip]

If I take off the throttling in MAME, although the game runs at 5x its speed, every click of the encoder is picked up correctly.

So this is my theory thus far, Derrick maybe you can confirm or correct.

A throttled MAME runs at 60fps max, which is a frame every 16ms.  If the encoder is generating 8ms clicks, it is possible that an entire click starts and ends within a frame and is therefore lost.

With throttling off, I am actually getting 300 fps, which is about a frame every 3ms.  With this level of granularity, a click of 8ms will always be spread across more than 1 frame and therefore it is always recognized.

Does this make sense?

So the corrective action would be to make the encoder generate > 16ms key-presses, say 30ms, so that they are always recognized at 60 fps. 

[Kremmit]

Those inconsistencies in policy would probably not be brought up all that often if it were not for all the disciples who preach with fervor the "For Preservation, Not For Gameplay!" gospel.

No, this stuff gets brought up so often because there's a very, very large group of MAME users out there that doesn't know what they're talking about.

And for crying out loud, Leave Derrick Alone.  He's the one dev that seems really interested in fixing a lot of the controller-specific issues and inconsistencies that we're talking about here in the first place. 

[MaximRecoil]

Those inconsistencies in policy would probably not be brought up all that often if it were not for all the disciples who preach with fervor the "For Preservation, Not For Gameplay!" gospel.

No, this stuff gets brought up so often because there's a very, very large group of MAME users out there that doesn't know what they're talking about.

That doesn't preclude what I said. So while your statement is no doubt true, it has no reason to begin with the word "no".

And for crying out loud, Leave Derrick Alone.  He's the one dev that seems really interested in fixing a lot of the controller-specific issues and inconsistencies that we're talking about here in the first place. 

I didn't say anything against Derrick, or even, about Derrick. I pointed out a common reason for people pointing out inconsistencies in MameDev policies. When you have so many people who rudely respond to any statement or question that even hints that you might be interested in playing a game, with a "For Preservation, Not Gameplay" rant; then of course people are going to point out logical contradictions in that "policy" if they exist. On the other hand, when the stated policy/mission was accompanied with a wink and a grin, like in the early days of Mame (I'm pretty sure that Nicola Salmoria was far more interested in simply playing Pac-Man back in '97 than in any enlightened, altruistic, preservation crusade like gets hammered about so often these days), and not wielded like a weapon; then few people are going to mention inconsistencies in policy, because the policy isn't being slung at them in a confrontational manner in the first place. Like the old proverb says, "Those who live in glass houses shouldn't throw stones."

[AndyWarne]

If I take off the throttling in MAME, although the game runs at 5x its speed, every click of the encoder is picked up correctly.

So this is my theory thus far, Derrick maybe you can confirm or correct.

A throttled MAME runs at 60fps max, which is a frame every 16ms.  If the encoder is generating 8ms clicks, it is possible that an entire click starts and ends within a frame and is therefore lost.

With throttling off, I am actually getting 300 fps, which is about a frame every 3ms.  With this level of granularity, a click of 8ms will always be spread across more than 1 frame and therefore it is always recognized.

Does this make sense?

So the corrective action would be to make the encoder generate > 16ms key-presses, say 30ms, so that they are always recognized at 60 fps. 

I can certainly supply a version with longer keypresses for testing. But the maximum keypress rate will decrease of course.
Andy

[Rip]

I can certainly supply a version with longer keypresses for testing. But the maximum keypress rate will decrease of course.
Andy

Excellent, I'll shoot you an email with my address.  I'm not sure the maximum keypress will be an issue.  Perhaps you can send a board with a few chips with various key press timings.  I can just swap out the chips and see what works best.  Thanks Andy!  You have A++ support 

[Kremmit]

blah blah blah

Never mind, I don't want to play this game.

[MaximRecoil]

blah blah blah

Never mind, I don't want to play this game.

Then why did you respond? And what "game" are you referring to? Is it anything like the childish "game" where you change quoted text to "blah blah blah"? (Bravo @ that BTW -- masterfully done)

[RandyT]

Those inconsistencies in policy would probably not be brought up all that often if it were not for all the disciples who preach with fervor the "For Preservation, Not For Gameplay!" gospel. For example:

IMHO, the two are not mutually exclusive. 

Consider this:  What good would the preservation of the 1's and O's on a piece of digital media be, if you could not somehow turn them into something viewable?  Preserving only the bit patterns is pointless if it is to have any benefit to human society.  Therefore, one could easily view any device built, or code added that was done to facilitate the behavior of the original mechanical controls as crucial to the games preservation.

RandyT

[MaximRecoil]

Those inconsistencies in policy would probably not be brought up all that often if it were not for all the disciples who preach with fervor the "For Preservation, Not For Gameplay!" gospel. For example:

IMHO, the two are not mutually exclusive. 

Consider this:  What good would the preservation of the 1's and O's on a piece of digital media be, if you could not somehow turn them into something viewable?  Preserving only the bit patterns is pointless if it is to have any benefit to human society.  Therefore, one could easily view any device built, or code added that was done to facilitate the behavior of the original mechanical controls as crucial to the games preservation.

RandyT

I agree. Another benefit to playability is that it encourages wide circulation. Wide circulation is the best means of preservation for software, even if "preservation" is the farthest thing from the minds of the people downloading the software. When something is unplayable, i.e., unusable to the Average Joe, there is far less incentive to obtain a copy. Generally only "completists" and the such will end up with a copy of it, which hinders preservation. It is better to have forty-eleven thousand copies of a game with playability hacks floating around out there, that can always be polished at a later date, than just a handful of copies, due to most people's lack of interest in obtaining unplayable games -- if preservation is your goal.

The thing is, the people who get on their soapbox with the "For Preservation, Not For Gameplay" message, don't tend to take things like that into consideration, i.e., they do view them as mutually exclusive; and it turns confrontational very quickly.

[Derrick Renaud]

Don't really know why it would be missing keypresses.  MAME just reads the DX input.  But I have have not really looked too far into the keyboard code.  All my changes have been in the "analog" code.

I'll take a peek to see if there are any buffering issues during my next look through the input code.  Can't promise anything because I have no way to test it.  I have some more sound effects to complete before I look at the input code again though.

It does sound quite possible that MAME only checks the last state of a key when it polls it.  The inc/dec button code was added at a latter state to the input system, and no one probably envisioned keypresses faster then 1 frame being anything but keyboard bounce.

So for now the best way is probably to slow down the interface.  You would never be able to turn a real ikari control 60 clicks per second anyways during real game play.  You would be hard pressed to do 30.

D.

[Rip]

Don't really know why it would be missing keypresses.  MAME just reads the DX input.  But I have have not really looked too far into the keyboard code.  All my changes have been in the "analog" code.

I'll take a peek to see if there are any buffering issues during my next look through the input code.  Can't promise anything because I have no way to test it.  I have some more sound effects to complete before I look at the input code again though.

It does sound quite possible that MAME only checks the last state of a key when it polls it.  The inc/dec button code was added at a latter state to the input system, and no one probably envisioned keypresses faster then 1 frame being anything but keyboard bounce.

So for now the best way is probably to slow down the interface.  You would never be able to turn a real ikari control 60 clicks per second anyways during real game play.  You would be hard pressed to do 30.

D.

Thanks.  Andy at Ultimarc has agreed to provide me with chips which generate longer keypresses.  I'll update the status when I receive them, likely by next weekend.

[Tiger-Heli]

There are all sorts of features I want to add to MAME.  If anyone wants to pay my yearly wage so I can quit my job and solely work on MAME, then these features will get added quicker. 

It would likely be cost-effective for BYOAC to take up a collection to do so!

[u_rebelscum]

It does sound quite possible that MAME only checks the last state of a key when it polls it.  The inc/dec button code was added at a latter state to the input system, and no one probably envisioned keypresses faster then 1 frame being anything but keyboard bounce.

Yup, mame only looks at the current state (no buffering) with directInput.  If a button is pressed and released between mame polls, mame doesn't see it.  Makes sense with digital inputs.

[Rip]

Andy's fantastic customer service has come through again.  He sent me 3 chips with ~16ms, ~24ms, and ~32ms keypresses.  The 16ms still missed the odd click, 24ms caught them all as did 32ms.  From this it seems 24ms is the right number and clicks will be caught in all situations.

I have tested it in Ikari Warriors (has the new directional input device) and it works flawlessly.  Also tried it in Caliber 50, with the older style dial input, and it works like a champ.

Thanks Andy!

John

[Faerl]

It sounds like I have a similiar issue (same identical symptoms at least, works in notepad, random clicks miss in Mame). Are there any work arounds out? Maybe a plan to provide a firmware update for the ultimarc hardware?