Main > Main Forum

Fixing MAME's handling of 12-position rotary controls

<< < (16/17) > >>

RandyT:

--- Quote from: u_rebelscum on February 02, 2006, 04:49:12 pm ---You guys ready? ;D  BIG post.

--- End quote ---

I had to get another cup of coffee to get through that one.  Nice job ;)


--- Quote ---RandyT, Mame takes the relative data (which is stored in a 256 value rolling counter) and multiples by 12 and divides by 256.  In integer.  This means rounding, which is why you get the two values in ikari.  Looks like timesold has same sensitivity as the other games, but a lower keydelta (keydelta shouldn't effect mouse inputs but seem to in small and mysterious ways).  It still is weird that timesold needs between 19 & 23 steps.  I could see it was the rounding problem if it took say 20 or 22, but with the range you list, it might be something else too. 
The reason Druin's interface doesn't work perfectly is that it "holds down a button" for a given amount of time for each mechanical click.  Mame reads the digital input and translates it to relative, the "delta" based on how long the button is pressed.  If the timing is not perfectly matched to mame's settings (keydelta & sensitivity), the microseconds add up and finally show up as a missed signal.  If the timing is bad, you see it every other click.  This is done in the core, not the driver, and is about as good as you can get when converting digital to relative.

--- End quote ---

It appears that the "19" may have been a mis-count on my part, as I didn't see it again just now.  It appears the actual numbers were 20 - 23.  I don't fully understand the significance, so I'll leave that one for you.

So in any case, I believe I have a solution to this problem.  Whether it's one that they would be willing to implement is another story, but seems clean to me.

They are using a rolling counter for the spinner / relative control .  The problem comes from the fact that the rolling counter isn't evenly divisible by 12.

So.........MAME needs a small piece of code that will allow the user to set the rollover value of the counter to one that is evenly divisible by 12, say 252, or any other number they fancy.  This would probably come in handy for other oddball absolute controls (although I can't think of any at the moment) using this method.  That way, nothing breaks and everything else still works the way it is expected.  The left and right button method still use the counter, it just rolls at a different spot.

Obviously there would be a slight performance hit, because one would need to compare for the value and set it to that value if the counter should go below 0, but that doesn't sound like the end of the world.

Or did I miss the gist completely?

RandyT

brandon:

--- Quote from: Dav on February 02, 2006, 06:34:35 pm --- I desoldered the decoder on my board and made an adapter to dump it.  It encodes the 12 bits as 0-11binary  so there's nothing tricky going on with that. 

--- End quote ---

what sort of chip did it use to do that? was it some generic TTL encoder?  maybe something we could order from Mouser for a few bucks?

Dav:
MB 7134.  That's not a chip I'm familiar with, but when I mapped out the lines I could see it was a 4k*4 bit prom.  It was not one I could dump on my programmer which is why I had to make an adapter.  Bascially any eprom should work, so as long as you have a eprom programmer it's going to cost less than a buck.  In fact anyone with an eprom program has old eproms laying around so it's closer to free. :)   You just wire the inputs to the address lines and the 4 output bits give you the raw data.  If you wanted to do it in different for different games you can use a rom with more than 12 address lines and put a dipswitch on upper lines to bank.  Here's a chart of what it looked like.  I didn't fill in all the values for where 2 switches where pressed, and of course the majority of the eprom is invalid so contained 0F but you get the idea.   I'll probably add this prom to the next mame version so everyone will have to download new rom sets for bermuda triangle and victory road.  When anyone asks why I'll say it's arcade controls fault.

ba98 7654 3210 <-address lines
                           switch number/address/data value i.e. raw bits
1111 1111 1110 1 / ffe/ 00        <--switch 1 is pressed
1111 1111 1100 1/2 ffc 01         <--switch 1 and 2 are pressed
1111 1111 1101 2 ffd 01           <-- switch 2 is pressed
1111 1111 1001 2/3 ff9 02
1111 1111 1011 3 ffb 02
1111 1111 0111 4 ff7 03
1111 1110 1111 5 fef 04
1111 1100 1111 5/6 fcf 05
1111 1101 1111 6 fdf 05
1111 1001 1111 6/7 f9f 06
1111 1011 1111 7 fbf 06
1111 0111 1111 8 f7f 07
1110 1111 1111 9 eff 08
1101 1111 1111 a dff 09
1011 1111 1111 b bff 0a
0111 1111 1111 c 7ff 0b



Also if you do try this, you can put a switch on the enable line to kill the output, when you don't want any keypresses.  If I were making one I'd probably still use the cpld because the cost  difference vs 2 eproms isn't that great, and I think there's more features that could be available.  Like a timer circuit to disable output if you don't move the stick for 30 seconds.

tetsujin:

--- Quote from: Minwah on January 30, 2006, 06:10:15 pm ---But yes I agree all games should be treated as they were in the arcade.  That way we can interface just about anything and have it work properly one way or another.  However if we came up with our own 'BYOAC build' we could be a little less arcade-accurate if neccessary, and have some solid rules in place for max compatibility with the hardware we use.

--- End quote ---

I think this would be a fantastic and important project.  Lots of great work has been done on MAME in the form of extensions and special builds but as far as I know not so much on integrating those add-ons together.  Things like improved input support and generalized output support (for interfacing with lights, etc.), common refinements like getting rid of warning screens, and so on.  I expect I'll have to do some work on MAME myself (unless I find there really has been a build done that ties it all together), either to get the combination of features I want or for some other reason...  it'd be wasteful to do a bunch of work on MAME and keep it to myself, and it'd be wasteful for someone else to do a bunch of work on MAME and not share it in a useful way...  (Making the work available to other people is useful - but the complication of integrating different branch builds together is a process of exponential complexity...)

brandon:

--- Quote from: Dav on February 03, 2006, 10:28:53 am ---MB 7134.  That's not a chip I'm familiar with, but when I mapped out the lines I could see it was a 4k*4 bit prom.  It was not one I could dump on my programmer which is why I had to make an adapter.  Bascially any eprom should work, so as long as you have a eprom programmer it's going to cost less than a buck.  In fact anyone with an eprom program has old eproms laying around so it's closer to free. :)   You just wire the inputs to the address lines and the 4 output bits give you the raw data.  If you wanted to do it in different for different games you can use a rom with more than 12 address lines and put a dipswitch on upper lines to bank.  Here's a chart of what it looked like.  I didn't fill in all the values for where 2 switches where pressed, and of course the majority of the eprom is invalid so contained 0F but you get the idea.   I'll probably add this prom to the next mame version so everyone will have to download new rom sets for bermuda triangle and victory road.  When anyone asks why I'll say it's arcade controls fault.

ba98 7654 3210 <-address lines
                           switch number/address/data value i.e. raw bits
1111 1111 1110 1 / ffe/ 00        <--switch 1 is pressed
1111 1111 1100 1/2 ffc 01         <--switch 1 and 2 are pressed
1111 1111 1101 2 ffd 01           <-- switch 2 is pressed
1111 1111 1001 2/3 ff9 02
1111 1111 1011 3 ffb 02
1111 1111 0111 4 ff7 03
1111 1110 1111 5 fef 04
1111 1100 1111 5/6 fcf 05
1111 1101 1111 6 fdf 05
1111 1001 1111 6/7 f9f 06
1111 1011 1111 7 fbf 06
1111 0111 1111 8 f7f 07
1110 1111 1111 9 eff 08
1101 1111 1111 a dff 09
1011 1111 1111 b bff 0a
0111 1111 1111 c 7ff 0b



Also if you do try this, you can put a switch on the enable line to kill the output, when you don't want any keypresses.  If I were making one I'd probably still use the cpld because the cost  difference vs 2 eproms isn't that great, and I think there's more features that could be available.  Like a timer circuit to disable output if you don't move the stick for 30 seconds.


--- End quote ---

wow.. I never would've thought of doing it that way in a million years ;D  so basically I can program any old eprom with those hex values at those addresses and that should do it right?  and by bank switching you could program it to only move every other turn (6-way) or run backwards or any other bit patterns that it needed right?  Would be cool if you could program it to work with Xybots. (but that couldnt work with this method..) and on that note.. anybody ever try Druins interface with Xybots?  I know its was a different stick but if the interface translated the movement to just left and right then it would still work.. just not "accurately" compared to the original...


EDIT*  now that I'm thinking about it.. is this how all dipswitches work on PCBs?  the dipswitch just bank switches an eprom so that aternate code is ran?  hmm.. maybe this stuff is starting to make sense to me after all... :P

Navigation

[0] Message Index

[#] Next page

[*] Previous page

Go to full version