| Main > Main Forum |
| Fixing MAME's handling of 12-position rotary controls |
| << < (14/17) > >> |
| brandon:
somebody may have mentioned this but... IF we could change the way Mame handles the control of these games then I think the "ideal" solution would be some sort of cheap circuit using TTL logic to convert the 12 position switch to a 4-bit code so that only 4 inputs would be needed on the gamepad or keyboard encoder. I don't know if they make a 16 to 4 encoder but if not two LS74148 8 to 3 priority encoders would do the trick nicely(I think... :P) and as far as those 4 buttons being on all the time.. as somebody mentioned you could put a switch on the common (gnd) of the 12-ways or better yet maybe do something with the enable lines on the chips? BTW.. I took digital electronics class several years ago so I may be totally talking out of my arse ;D |
| RandyT:
--- Quote from: RobotronNut on February 01, 2006, 11:29:56 pm ---there's at least one more difference. mame 0.103 inserts invalid codes into the stream to work around the "joystick error protection in Guerilla War". it would seem that this would cause you to lose pulses, although i can't explain why this would once every 8 or 9 pulses. --- End quote --- Seems to do it with all versions. The only difference I saw was Ikari was less "sensitive" at 100% in the earlier version (.71, I believe) There is something seriously wrong with the way the input is working, if it's supposed to behave the way Dave described it. Designing an interface for this would be like chasing a moving target. RandyT |
| MikeQ:
I've only skimmed through this thread so forgive me if I am repeating anything. Does MAME truly poll the inputs or are inputs interrupt driven? If MAME is polling them and not reacting to an interrupt, it would seem very likely that signals would be lost. I think looking through the code (at least for key controls) MAME looks at what keys are pressed during vsync or v-retrace. I'm not sure how it works with analog devices. If the polling of analog devices is the problem, then switching to an interrupt approach that then queues the inputs until they can be dealt with would seem to be a safer approach. |
| RandyT:
--- Quote from: MikeQ on February 02, 2006, 01:39:41 am ---I've only skimmed through this thread so forgive me if I am repeating anything. Does MAME truly poll the inputs or are inputs interrupt driven? If MAME is polling them and not reacting to an interrupt, it would seem very likely that signals would be lost. I think looking through the code (at least for key controls) MAME looks at what keys are pressed during vsync or v-retrace. I'm not sure how it works with analog devices. If the polling of analog devices is the problem, then switching to an interrupt approach that then queues the inputs until they can be dealt with would seem to be a safer approach. --- End quote --- I'm not sure about the aquisition methods, but I'm pretty sure MAME wasn't missing the input due to speed. I was manually keying in quadrature on 2 pushbuttons connected to an Opti-Wiz :D It was the only way to know exactly what was happening. So, the signals were coming at MAME very slowly relative to actual spinner input. It seemed like an internal counter was screwy to me. RandyT |
| Dav:
--- Quote from: RandyT on February 02, 2006, 12:53:36 am --- --- Quote from: RobotronNut on February 01, 2006, 11:29:56 pm ---there's at least one more difference. mame 0.103 inserts invalid codes into the stream to work around the "joystick error protection in Guerilla War". it would seem that this would cause you to lose pulses, although i can't explain why this would once every 8 or 9 pulses. --- End quote --- Seems to do it with all versions. The only difference I saw was Ikari was less "sensitive" at 100% in the earlier version (.71, I believe) There is something seriously wrong with the way the input is working, if it's supposed to behave the way Dave described it. Designing an interface for this would be like chasing a moving target. RandyT --- End quote --- I don't know how mame works. I'm describing how spinners work. Every spinner I've ever seen (with the exception of omega race) has a constant ratio between the spinner movement and pulses. If mame doesn't do that it sounds like a bug to me. Whether the problem is in mame or a library or a driver I wouldn't even guess. Regardless it affects how well the interface works whether you're using using a mouse interface or druins. I'll see if I can find my time soldiers board tomorrow and solve the absolute or not question definitively. You could probably do the encoding with ttl's but a cpld might be cheaper and would give you more flexibility as far as features, such as disabling the output. As far as the changes required for mame to use it, I think they'd be fairly straight forward if it's just 4 bits into the rom as described. Shouldn't take more than a few minutes per game. |
| Navigation |
| Message Index |
| Next page |
| Previous page |