MAME spinner games: Does mame emulate quadrature decoding?

[huygens]

I was wondering how much of the control hardware is emulated by MAME. All the spinner games use some form of quadrature decoding to convert the quadrature signal to a counter at 1x, 2x, or 4x the physical spinner resolution. Does mame emulate the decoding circuitry, or does it translate the mouse/spinner data to counter data directly.

If a game uses a 72 gap encoder wheel and has a 4x quadrature decoder should I set the analog sensitivity based on  a 72 gap spinner or a 72*4 gap spinner?

 

[Ummon]

I'm surprised u_rebelscum hasn't replied yet. I think this has come up before though I don't remember the details. I'd think at MameWorld, someone would know right off.

[ahofle]

I'm pretty sure MAME does not emulate the quadrature decoding, but I'm sure u_rebel will confirm.  Even if it did, you would get jumpy movement similar to cranking up the resolution too high on a low res spinner.  This is why you need a really high resolution spinner for games like Arkanoid.  In your example, I believe you would have to set the sensitivity at 72*4.

[2600]

Your mouse, opti-pac, or whatever other encoder you use does the quadrature encoding.  This value is what MAME sees.  MAME then has the ability to decrease or increase this value by a percentage IIRC.

I have a project on my list to make an encoder where you can turn off the encoding so that it reports at 1x.  The problem with the super high res encoders is that it can almost report too much information for games that only used 1x and had a small tooth count.

[u_rebelscum]

Heh, I'm late, and this has been mostly answered, again.  I'll put my two cents anyway.

Mame is designed to accept normal inputs: keyboard, mouse, joystick (and lightgun which is like a mouse, but not exactly ).  PC mice already do the decoding, so there is no need for mame to do quadrature decoding, or more precisely, unconverting mouse count to faked quadrature signals, and then decode back to a count through emulation.  Add that until "recently" there was no way to send the raw quadrature signals to the PC, and then mame to see it and emulate the hardware that decoded it, in real time without lag and/or missed changes (any even now it's not normal).

So the way mame "handles" different tooth counts and 1x, 2x & 4x decoders is the analog mouse sensitivity setting, input definitions (part is setting the defaults for aforementioned sensitivity), and (very rarely) hardcoded special input hacks.

There are a few threads at this site about tooth count and decoding state levels.  But, yah, inputs is one of mame's "weakest" AFA true complete hardware emulation, but almost completely due to PC limits & standards.

[2600]

I wouldn't call it MAME's fault.  It is getting quadrature data.  The various manufactures could easily send 1x or 2x data or even switch between them, but they don't.

[u_rebelscum]

I wouldn't call it MAME's fault.  It is getting quadrature data.  The various manufactures could easily send 1x or 2x data or even switch between them, but they don't.

Mame is not getting quadrature data, so of course it's not mame's fault. 

The mouse converts (decodes) it to counts (numbers increased or decreased per axis).  There was one (AKAIK) port protocol, busmouse, that didn't have the mouse decode the quadrature signal, but even so their was a hardware decoder between the CPU and the mouse.  All other protocols (serial, PS/2, apple's ADB, & USB) have the decoder inside the mouse, and do not transmit quadrature signals to the PC.

It's true that the manufacturers could have their decoders decode at 1x, 2x or 4x, but that's outside of mame's realm, as it would take reprogramming the decoder in the mouse (sort of like keyWiz/ipac remapping).