Main Restorations Software Audio/Jukebox/MP3 Everything Else Buy/Sell/Trade
Project Announcements Monitor/Video GroovyMAME Merit/JVL Touchscreen Meet Up Retail Vendors
Driving & Racing Woodworking Software Support Forums Consoles Project Arcade Reviews
Automated Projects Artwork Frontend Support Forums Pinball Forum Discussion Old Boards
Raspberry Pi & Dev Board controls.dat Linux Miscellaneous Arcade Wiki Discussion Old Archives
Lightguns Arcade1Up Try the site in https mode Site News

Unread posts | New Replies | Recent posts | Rules | Chatroom | Wiki | File Repository | RSS | Submit news

  

Author Topic: Fixing MAME's handling of 12-position rotary controls  (Read 18382 times)

0 Members and 1 Guest are viewing this topic.

Dav

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 220
  • Last login:March 29, 2016, 05:39:35 am
Re: Fixing MAME's handling of 12-position rotary controls
« Reply #80 on: February 03, 2006, 05:08:56 pm »
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.


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

Yes, every other turn and backwards are easy to do.  Although it would be easier to modify mame with a read handler to modify the input data for you for each game. 

Getting relative ie R,L out of it would be much harder as it doesn't remember where it was last.

Dips don't normally work that way as it's very wasteful of eprom space.  However a lot of multigames and modern hacks do, since eprom space of that size is practically free now.


BTW the code changes I made to timesold in the inputs section of alpha68k.c

   PORT_START_TAG("IN5")  /* player 1 12-way rotary control - converted in controls_r() */
change input 5 from the line that said dial to this.
   PORT_BIT( 0x0010, IP_ACTIVE_LOW, IPT_BUTTON5  )
   PORT_BIT( 0x0020, IP_ACTIVE_LOW, IPT_BUTTON6  )
   PORT_BIT( 0x0040, IP_ACTIVE_LOW, IPT_BUTTON7  )
   PORT_BIT( 0x0080, IP_ACTIVE_LOW, IPT_BUTTON8  )

This is just a quick hack to test how it worked and it worked pretty well.  In reality I think it should be active high which reverses direction and I think there's an inverting read handler that may need to be removed.  You can press different combo's of buttons to see how it works. 

I verified on bermudaa that the encoded 4 bits goes straight to the cpu data bus so it should work, but I'm not an expert on relative inputs so who knows.  You may still need a read handler to cover specialized cases  ie apparently gwar doesn't like going from 5 directly to 6.  I don't really understand why unless 5 is not a valid number or the inputs are not consecutive.



SirPoonga

  • Puck'em Up
  • Global Moderator
  • Trade Count: (+1)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 8183
  • Last login:April 12, 2023, 09:22:35 pm
  • The Bears Still Suck!
Re: Fixing MAME's handling of 12-position rotary controls
« Reply #81 on: February 03, 2006, 05:19:23 pm »
I verified on bermudaa that the encoded 4 bits goes straight to the cpu data bus so it should work, but I'm not an expert on relative inputs so who knows.  You may still need a read handler to cover specialized cases  ie apparently gwar doesn't like going from 5 directly to 6.  I don't really understand why unless 5 is not a valid number or the inputs are not consecutive.
Well, find a wiring schematic for the game.  Maybe there's something missing??

Kremmit

  • - AHOTW -
  • Wiki Contributor
  • Trade Count: (+2)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 3164
  • Last login:November 22, 2020, 05:59:29 pm
  • Who the heck is that?
Re: Fixing MAME's handling of 12-position rotary controls
« Reply #82 on: February 04, 2006, 11:52:52 pm »
re: xybots-

Yes, it works fine with a Druin's.  Also works with a "left" and "right" button on the CP.

re:  tetsujin-

Have you seen the MAMEDevs VS. BYOAC thread?  MikeQ is starting a project.