NEWS: This page was developed at 1152x864 resolution, looks best at something higher, and will be hard to read at less than 1024x768 :-((( Also, the new Frames Page makes it easier to find info, but disables printing the page. Use this link to drop out of the frames [for low-res or printing (reduce print margins if required), printing is possible at 640x480], and this link to return.
28 Oct 05 - Minor update to the USB_Vs._PS2_Mode section to highlight the differences in hot-swapping PS/2 devices under Win98 and WinXP.
1 Aug 05 - Added a Frames Page for easier Navigation. The page also uses an external CSS so it looks a little more professional. Thanks to KillerClown for inspiration for the Navigation Pane design. Revised to add Daveb's SJC, Druin's Rotary Interface, the GroovyGameGear GP-Wiz, GP-Wiz49, KeyWiz Eco2 (replaces the Eco), HotRod Encoder, LPT Switch, KeyDog, Microsoft Dual Strike Gamepad Hack, Ultimarc A-PAC, TOKN KB16, and TOKN KB32 encoders. Revised page to include Optical and Rotary Interfaces. Corrected information on the I-PAC VE LED's and default codeset. Added new sections SHORT SUMMARY, EMERGING TRENDS, ANTI-BIAS STATEMENT and HEAD-TO-HEAD. Added new topics on Gamepad encoders vs. Keyboard encoders, Gamepad Encoder Useful Software, Analog Controllers, 49-Way Joystick Controllers, additional comments to In Perspective, SDRAM sections, Additional I-PAC LED considerations, Terminal block connections vs. Pin Headers, USB Device ID's, and a cool (I think) epilogue. Added trademark to first reference to MAME. To many other changes to list, read the entire page and get back to me in a couple of weeks ;-)).
15 Oct 04 - Wow, less than a year has gone by and the scene has changed significantly. This revision to the page adds 3Tronics MAMI 30 (and updates all 3Tronics products to show terminal strips only), Daveb's AKI, GroovyGameGear's KeyWiz Max 1.5, Lupine System's 64-Key Encoder, 3DTronics MAMI30, Ultimarc's J-PAC, Mini-PAC, and I-PAC VE, X-Arcade's encoder (available again) and shows the KeyWiz Std and Max and the MK64 as discontinued. I also fairly extensively cover the new WINIPAC IPD software.
?? Aug?? 03 - Initial Release.
New visitors may not understand what this page is about. Many of us spent our quarters and even more of our mis-spent youth in arcades and bowling alleys playing classic arcade games like Pac-Man, Frogger, Asteroids, BattleZone, Centipede, Defender, Tempest, TRON, and others. Now many of these games can be played on home PC's thanks to the magic of emulation (MAME™). The emulation programs typically use the keyboard, gamepad, PC Joystick, or mouse to simulate the controls used by the game. But this can't compare to the actual feeling of the original joysticks, buttons, and trackballs. So an interface is required to connect the arcade controls to the PC. The initial versions of this page covered keyboard encoders. A keyboard encoder is basically a circuit board which can accept a switch (joystick or button) and generates a keypress on the PC when the switch is pressed. In simplest terms, they are the physical equivalent of a keyboard hack, but many of them can do a lot more than just that. Since the initial release, the page has been expanded to also include gamepad encoders, analog, optical, 49-way joystick, and mechanical rotary joystick interfaces.
This page sprang out of my attempts to decide on a keyboard encoder for my arcade control panels. Along the way, I picked up some rarely mentioned information and thought it would be helpful to share that info with others (and it pretty much mushroomed from there). The purpose of this page is to show the advantages and limitations of each interface. You may not want to cut IDE cables to wire up your arcade controller, or it may be geographically (shipping charges) cheaper to buy a KeyWiz than an I-PAC, or vice-versa, which is why all the different versions will be included. Constructive comments on this page should be sent here.
NOTE: This page is highly geared toward using an encoder/interface for arcade emulation, such as running MAME in an arcade cabinet. Many PC games and console games used 6 or 8 buttons per player and multiple players, so if you play these games, you will need an encoder with a suitable number of inputs.
Also, this page is not designed to pick out the "Best" encoder/interface, nor is it really set up as as a review of various interfaces. It is set up more as a tutorial to take you step-by-step through the process of determining what you need and choosing the interface that's right for you. Along the way, you will gain lots of (hopefully) useful information.
BTW, if you are already familiar with interfaces and arcade controls (or really impatient), you might want to skip to the The Players section, where I have a chart comparing features of the various products (I have tried to revise this so that most of the pertinent info is repeated in this section), or the Comparison Table section, where I list what games each encoder is capable of handling, and maybe the Key Assignments page, where I give sample configs for each encoder, then read the Conclusion section. (Don't forget to come back and read the rest of the useful info I included when you finish, though.)
If you're familiar with the various interfaces, you might want to check out the Head-To-Head section, as you probably have not seem them discussed in this way before.
This page attempts to provide detailed and factual information about all the available options for hooking up arcade joysticks, spinners, trackballs, analog joysticks, rotary joysticks, and buttons to a PC. However, the volume of information presented can be a little overwhelming. If you want a cut-to-the chase summary, here it is: Despite the multitude of options available, for keyboard/gamepad encoders (buttons/joysticks), you really shouldn't be looking anywhere except the products supplied by www.groovygamegear.com or www.ultimarc.com. (See the rest of the page if you need to decide between the two companies). There are only three (really two) exceptions to this basic rule:
- The majority of the encoders listed below will work adequately for gaming usage, but the two companies above have tailored their products toward the arcade controls specialty. However, if you find a deal on a used Hagstrom or MK64 or Lupine (or other) encoder, it may be worth getting if it has the features you need. However, I wouldn't go out of my way to specifically look for a deal on these, unless they happen to have some feature that the other encoders don't offer and that you can't live without.
- For a classics cabinet with a limited number of inputs, if cost is a major factor, and you are comfortable with soldering, and you only plan to use the encoder with MAME or another assignable input emulator, then a keyboard or gamepad hack MIGHT be suitable, but see the Emerging Trends section below before you decide on that route.
- There are some very limited situations where the TOKN16 encoder makes sense - i.e. basically if you can get one for the E-bay price (currently (12Jul05) about $10.50, at anything over that, the KeyWiz Eco2 at less than $25 is a better deal), and you don't like (or trust yourself) with soldering, and you want to use the encoder with an emulator (or games) that require very few inputs (otherwise a keyboard hack is a better deal b/c you have more functional inputs) and that same emulator is non-configurable (where the TOKN16 has an advantage over the keyboard hack b/c you can program any outputs you want) and you only have one such program to use it with (otherwise the KeyWiz Eco2 is a better deal b/c of programmability through software). Even with these limitations, the encoder still requires diodes or creative workarounds to avoid ghosting. See my review of the TOKN16 for details.
Generally, the decision of an keyboard/gamepad encoder will come down to the following steps: Determine the type of arcade controls you wish to connect and the total number of inputs required. Determine whether it is acceptable/desirable to share inputs for certain games (i.e. P2 B5 for the SF games can be P3B2 for 4-player games), primarily as a cost-savings. Determine which encoders support this number of inputs and determine whether there are certain features which make one encoder preferable to another. Make your purchase.
The previous version of this page was accused by some of being biased towards the GroovyGameGear line of products, and this revision will do little to change that impression. However, I again wish to point out that I strive to present accurate information about all the products listed. I make no money off of this page and have nothing to gain by unfairly presenting one interface over another. Nor do I have a personal interest in seeing you choose one interface over another, beyond seeing that you pay the least amount of money for an interface that meets your needs.
However, unlike certain other sites, I have come to the conclusion that it is impossible to write an objective and a helpful and informative page. One or the other is achievable, but not both. For example, I could eliminate everything from this page except the comparison table (without footnotes) The page would then be totally objective (except arguably the order that interfaces appeared in the table). But the new reader would end up saying "Okay, this encoder uses SDRAM and this one uses EEPROM, but what's that mean?" (And the more important but less often asked "Which one should I use for my particular set-up?") Once you try to answer that question, personal bias in bound to creep in!
And while we're on the subject, there is a distinction to be made between facts, opinions, and balanced opinions (As opposed to lies, d*mn lies, and statistics). For example:
FACT: EEPROM is a form of non-volatile (permanent until changed) memory as opposed to SDRAM or volatile memory (erased on power-down). (Doesn't tell you much). Note that facts aren't always accurate. The previous revision of this page had inaccurate info on the I-PAC VE codeset. But it was not an opinion.
OPINION: You should never buy an encoder which uses SDRAM, EEPROM is much better.
BALANCED OPINION: While EEPROM is preferable (all things being equal), it only comes into play if you don't want to use the default codeset, and even then, you can load a different codeset from a batch file at startup, so the main advantage for it is in the case of hot-swapping controllers.
My opinions are of course biased toward my usage, meaning I lean toward swappable desktop controllers, low price, high performance, high numbers of inputs, and high flexibility. Other users may place higher priority on keyboard pass-thru's, LED's, or even PCB input labeling. And that's fine, the important thing is to weigh my opinions out against how you will actually use the encoder.
To the interface manufacturers, I challenge you to "Show me the stuff!!!" I.e., if you come out with a reliable, high-performance, 36 or more-input, programmable (through software) encoder without soldering required for under $20, (and don't appear to be a flash-in-the-pan operation), I will be all over it with support and recommendations; but that's pretty much what it will take at this point in time.
Expanding on my anti-bias statement, I feel it only fair to disclose that since Jan 05, I have had the privilege of using a beta (prototype) KeyWiz encoder in my personal desktop control panel. Also, since 8Jun05, I have had access to a TOKN KB16 encoder which I used for testing and evaluation. Apart from these two items, I have no physical experience with any of these products. I am an active member of BYOAC and follow the user comments there, and I do ask for clarification from the hardware vendors on the items I am covering.
In the past, I had turned down offers of hardware, because I didn't want the review to come off as biased, but I decided I would rather have accurate controls in MAME <snicker>. I still feel that I do a good job of presenting the alternatives. Consider this a double-edged sword. While I am more aware of the advantages of the KeyWiz or TOKN KB16 than I would be with say, an I-PAC/2, I will also be more aware of its shortcomings. What it really means is I am more intimately aware of what these encoders can and cannot do, so if I read a post on BYOAC about some failure of the KeyWiz or TOKN KB16, I can test on my encoder and disprove or verify the condition. If I read a post on BYOAC about problems with an I-PAC, I have to refer to the documentation, and then assume that the reported problem really exists. And as my experience with the TOKN KB16 demonstrates, there may be a lot of issues with some of the encoders that are incorrectly or not reflected in the documentation or published reports, so you are missing out on that information. If you feel that my information is unfair, you are free to try your luck with other review sites.
Also, it bears repeating that I have a prototype version of the KeyWiz, so any features or flaws that I report may or may not be present in production boards. I only know of one instance where this might be a possibility (an intermittent problem that has lately not been present), but it needs to be considered.
So should you run out and buy a KeyWiz for your panel without reading the rest of this page? (After all, Tiger-Heli considered all of these for us, and that's what he chose!) Well, I don't think you would be disappointed if you did. I also don't think you would be disappointed if you just ran out and bought an I-PAC/2, I-PAC VE, I-PAC/4 or a Mini-Pac, A-PAC, GP-Wiz, or GP-Wiz49 or found an MK64 somewhere. These are all excellent choices. I do think you would be doing yourself a dis-service in not picking the encoder with the closest match of features to your specific requirements.
I still like the KeyWiz, but there are other options that I might consider if I were doing it again. Keep in mind, at the time I purchased it, I was looking at eventually relocating the encoder to a project box to enable four-player support. The KeyWiz is the most economical option for true four-player support, but I don't plan to use it this way. I like having the 32 inputs over the 28 of the I-PAC/2, although I only REALLY need them for PC gaming, and I only occasionally use that. In theory, I would prefer a USB controller (like the I-PAC VE) since I do hot-swap controls, but the KeyWiz hasn't given me any problems with this. OTOH, the default codeset on the KeyWiz is about perfect, while the I-PAC VE has some repeated keys so EEPROM for re-programming would be nice to have if I were choosing the I-PAC VE (but it uses SDRAM like the KeyWiz also). The GP-Wiz would also be a viable option, but it wasn't available when I was designing my CP, and even now would require an external JoyToKey type program for PC games, which would be slightly inconvenient. The point I am trying to make is that for any situation there is probably no solution that does exactly what you require, and you have to pick the unit that comes closest to what you want.
One thing to keep in mind as you read this review is that my opinions are largely based on speculation, and one thing I have realized is that once I started actually using an encoder, some of my pre-conceived notions were inaccurate. (And this will vary depending on the type of project your are building). I thought it might be helpful to share some lessons learned before we get into the full-blown comparison.
A key point to make before we go on is that some of these items are inter-related. Take Default Codeset and EEPROM - The I-PAC/4 has a poor default codeset (many repeated outputs), but is programmable and uses EEPROM, so you simply re-program it once and the problem goes away. OTOH, the I-PAC VE has a repeated output with SDRAM, meaning you must re-program the unit every time it is powered up (especially bad for a desktop controller), so it makes much more of a difference.
First off, in no particular order, these are some things that I consider possibly over-rated (I put too much positive emphasis on them, or they ended up not being that important to me).
- Price - Everyone likes to save some money when we can and in the case of a $100-$200 desktop controller, a $20 difference in encoder price is as much as 1/5 of the total cost. However, most of my readers will be making custom arcade cabinets. Compared to the cost of the total project, $20 is minuscule.
- Programmability - Given the price difference, it would be hard to recommend a non-programmable encoder, but I found that 99% of the time I play MAME and there is usually no reason to reprogram the encoder for MAME. So while it's a useful feature, it's one that I (and probably most users rarely use).
- Software Delays - I do reprogram my encoder for PC games. I am one of those people that delete the intro mpeg's to software and the Windows splash screen to make it load faster, so I thought delays waiting for the alternate codeset to be loaded would really bother me. It doesn't. And the KeyWiz software is supposed to be slower than the I-PAC software, so it would not bother me at all. (I run Win98 though, and it's supposed to be slower under XP, so I can't say whether that would bother me or not.
- Default codeset - See above. Basically, I think I make too much of a big deal out of this and most people totally ignore it. While I don't like the default codeset on the I-PAC VE, it's only one repeated key, you still have 31 others you can use. I doubt it would bother me that much in reality, it just bugs me that it is poorly laid out for no apparent good reason. OTOH, the default KeyWiz codeset is just about perfect unless you are one of those people that insist on re-programming MAME away from Ctrl and Alt keys, and I'm not.
- EEPROM - The KeyWiz is SDRAM based, and I rarely reprogram it, much less have a problem with it losing a custom setting. This is one of those things where if you don't like the default codeset (and try to hot-swap encoders) you don't want SDRAM, but otherwise, it's not a big deal.
- Macros - I like that the new I-PAC software allows you to assign key combos (particularly Alt-F4 to exit) to an input. That said, I rarely re-program my encoder at all. If I were going to do so, there are usually either wrappers, modified versions of the program, or background programs such as AutoHotKey or UltraKeyboard, that could accomplish the same thing for me.
- LED's - MAME flashes the keyboard LED's on coin start for a handful of games. I used to think this was really cool and something I would not want my control panel to be without. But it's only about 12 games out of the 500 or so that I like to play, and not any of my favorites at that. (I know BuddaBing and AdvanceMAME will allow you to have the LED's work on all games eventually). In the mean time, having used a panel with LED support, the majority of the time, the LED's are lit when they shouldn't be (in a front-end, for example) or not used in the current game. I still think it's a neat feature, but nowhere near as important as more inputs or fast accurate key response when choosing an encoder.
- USB vs. PS/2 - Not nearly the issue everyone makes of it, IMHO. My hot-swapped desktop CP is an ideal candidate for USB, but my encoder is PS/2 and I routinely hot-swap it. Regarding performance, I can't bring myself to believe that USB has a NOTICEABLE performance lag compared to PS/2, regardless of what the theory says.
- Keyboard pass-thru - Unless you are running DOS, it shouldn't matter whether your encoder is PS/2 and you use a USB keyboard, your encoder is USB and you use a PS/2 keyboard, or if you unplug the PS/2 encoder and plug the keyboard in to replace it. Even if you are running DOS, you should only need to use a keyboard when you are updating to the latest MAME version, and even then, there are ways to minimize the need for a keyboard. On my CP, I covered over the keyboard pass-thru connector and have never missed it.
And these are things that I consider possibly under-rated (I don't put enough positive emphasis on them, or too much negative emphasis on them).
- Raw number of inputs - The KeyWiz has 32 inputs and 24 shifted inputs. This should be more than enough for MAME. But I found that for PC games, I need every bit of the 32 basic inputs, and about 12 of the shift functions. The extra inputs were more useful than I would have thought.
- Shift Keys - I used to think these were a waste of time, b/c who wants to try to remember some weird combination when you want to do something. I've found F3 (Reset, Shazaaam!-P2B3 on the KeyWiz) extremely useful, but wouldn't want a button for it permanently on my CP. Nice feature.
- Screw Terminals - I've only had to swap wire locations a couple of times, but I found the screw terminals VERY handy for this. Whether there worth the extra money is a personal decision, but they are much more convenient if the extra cost isn't a factor.
- Auto Codeset Swapping - This is a KeyWiz feature which could be useful if you use MAME and one other non-assignable program. I didn't like it at all, and still don't use it, but I could see it being useful for some users, and it has never caused me any problems.
- Terminal Labeling - Okay, I have a hard time with this one. To my way of thinking, I could care less what the PCB says and would just as soon have it show symbols by each terminal and then wire up my controls however I thought best. However, I have heard several BYOAC members purchasing the I-PAC encoders b/c the inputs labeling seemed easier to understand, so I guess it makes a difference to some people.
Since I have been researching arcade interfaces for several years now, I thought it would be worthwhile to look at some emerging trends since my previous update. I see four main trends and GroovyGameGear is directly responsible for more than half of them:
- Death of the Keyboard/Gamepad Hack: Hacks like this used to be an affordable alternative to buying a keyboard encoder. If you are using MAME, most well-designed keyboard hacks can support a two-player street fighter layout as detailed on my page here. However, while the cost of the keyboard itself is often free, you still need about 4 hours of your time to map out the matrix, plan out the controls, and solder the wiring onto the processor card, only to end up with a very limited, non-programmable interface. If you have the skills to successfully solder a keyboard hack, you now can buy the KeyWiz Eco2, GP-Wiz, or GP-Wiz49 Eco, and get 98% of the functionality of a standard encoder for under $20. If you don't have the skills to solder, you can get the no-solder version of the above controllers for $23.
- Don't buy more encoder than you need: Mega-Encoders such as the I-PAC/4 and the MK64 used to be the hot item for building an arcade cabinet. They still have a place, for example, if you know for sure that you want to build a Frankenpanel™ and want to be sure you have enough inputs. I was considering one for my multiple arcade panel set-up, but decided that this would take a long time to build and figured out how to combine inputs and make a 32-input encoder work for my four player set-up (which I have yet to build). However, DaveB introduced the AKI, analog interface and gamepad encoder, GroovyGameGear followed with the more-affordable GP-Wiz gamepad encoder, and Ultimarc followed with the A-PAC analog interface and gamepad encoder. For a number of reasons, these products are advantageous as an add-on encoder for multiple panels, if not as a primary encoder. (For example, you can connect multiple gamepad encoders and they will "shift" from Player 1 to Player 2 to Player 3 automatically, which you cannot do with a keyboard encoder.) Also, because of aggressive pricing, it is very feasible to buy one 28-32 input encoder now and then add one (or more) of these encoders later when/if you decide to expand your system.
- The growing popularity of the 49-way joystick: 49-way joysticks have been around for a long time, but they were always something of an anachronism. There were only a few arcade games that used them (Sinistar, Blaster, Arch Rivals, and PigSkin 621 A.D.). Mame Analog Plus would allow direct connection of them through an encoder for these games, but that was about it. Then DaveB introduced the SJC which allowed them to be seen by the computer as an analog joystick. However, the sticks really gained popularity after GroovyGameGear introduced the GP-Wiz49 interface, and with good reason. The interface utilizes Digital Restrictor Selection (DRS)™ which makes the stick appear to the computer as either a true 49-way stick, 8-way joystick, 4-way joystick, rotated 4-way joystick, 2-way vertical joystick, or 2-way horizontal joystick. Now you have a stick still in production with a throw and feel similar to a Happ Super, with a centering grommet like the old Wico leaf joysticks (and soon a ball-top handle like one), with no clicking microswitches, which can play all the joystick games in MAME (except the true analog ones) flawlessly, and which can even be set to the correct mode of operation automatically by commands issued from a front-end. In addition, the interface supports 23 standard and five shifted buttons per joystick, making additional encoders largely unnecessary.
- New options for connecting analog controls: As previously mentioned, both DaveB introduced the AKI and Ultimarc introduced the A-PAC for connecting analog controls to the PC. This is a huge improvement over the previous method, which was either hacking a Microsoft Sidewinder Dual Strike gamepad, or modifying the controls to use 100K pots and connecting them to the gameport. However, these products lack the impact of the other products above, due to the relatively small number of games that require true analog controls, and the long throw of most analog joysticks, which makes them unsuitable for digital joystick games.
This is basically a place to counter some misconceptions about the Ultimarc and GroovyGameGear products. These products tend to induce as much controversy on BYOAC as a good Intel vs. AMD fanboy debate on the computer tech forums, so this is an interesting section to write (I need to get a life, I know). And again, these are my opinions and highly subjective.
First some history of product introductions, as best I remember it went like this: I-PAC/2, I-PAC/4, KeyWiz, Mini-PAC, KeyWiz ECO, I-PAC VE, GP-Wiz and GP-Wiz Eco, GP-Wiz49 and GP-Wiz49 Eco, A-PAC.
Myth 1 - The original KeyWiz is basically a stripped-down, less expensive I-PAC/2. (Attributed to Howard Casto). From a "bells and whistles" standpoint, I agree. The KeyWiz does not offer the USB option, LED support, non-Microsoft OS software support, EEPROM, or an active keyboard pass-thru. The I-PAC does not offer the alternate codeset swapping feature. From a performance and capability standpoint, the additional four inputs and the ease of adding stealth-shifted inputs make the KeyWiz levels above the I-PAC/2, very competitive with the I-PAC VE, and almost competitive with the I-PAC/4.
Myth 2 - The I-PAC VE is the bargain component of the I-PAC Line. (Attributed to KevSteele and SirPoonga). From a price standpoint, the three lowest priced Ultimarc encoders are (lowest to highest priced): Mini-PAC, I-PAC VE, I-PAC/2. From a features standpoint they are IMHO (lowest to highest): I-PAC/2, I-PAC VE, Mini-PAC. (Personal opinion, tie on the last two, but I rate the trackball interface on the Mini-PAC and EEPROM ahead of the four additional inputs on the I-PAC VE). It seems pretty obvious to me that the I-PAC VE was introduced as a direct response and competitor to the KeyWiz Max. It is priced identically to the KeyWiz Max when you figure in free shipping and the cost of the non-included USB A-B cable. It has the same number of inputs. It uses the same screw terminal connection method. It is the only Ultimarc product to use SDRAM, etc.
Myth 3 - The stripped down I-PAC is competing with the top of the line KeyWiz. (Attributed to SirPoonga). This comes from users not understanding Myth 2. The I-PAC VE is competing with the KeyWiz Max. IMHO, the additional four inputs outweigh the loss of a PS/2 interface and EEPROM, making the VE a more capable encoder than the I-PAC/2. It bears noting here that the GroovyGameGear Eco line gives up little compared to their MAX counterparts, other than screw terminals and a switchable pass-thru, for a huge cost savings. Ultimarc doesn't really have a product to compete with the Eco line, but the Mini-PAC comes close, depending on whether you want 4-player capability or a trackball interface.
Myth 4 - The A-PAC is a direct competitor to the GP-Wiz. Actually, other than price point, the fact that both encoders support 32 inputs, identify themselves as gamepads, and are USB, the units have little in common. The A-PAC is actually a much closer competitor to DaveB's AKI. While it can do most of the same things as the GP-Wiz, economically, it makes more sense to buy the GP-Wiz Eco, unless you plan to add analog controls at a later date.
This is a look at the number of buttons used by arcade games, so you can avoid buying an encoder that supports more inputs than necessary.
For 2-player games, many of the classics used only one button per player (Galaga, Gyruss, Time Pilot, Galaxian, Space Invaders, Mario Bros.). Even more used two buttons per player (Sky Shark, Twin Cobra, Tiger-Heli, (most vertical shooters), and for that matter, Rolling Thunder, and a lot of the horizontal scrollers, etc.) Three button games were somewhat rarer (Double Dragon, Gun.Smoke, Missile Command, Blasteroids). However, there were a fair number of 4-player 3-button games, and you could play any of these with only two people. There were a few four button games (Defender, Armor Attack, Rip-Off, Star Castle, and some of the Neo-Geo series of games, etc.) Of these, only Armor Attack and the Neo-Geo's were two player simultaneous. There were a few 5-button games, notably Asteroids, Asteroids Deluxe, Star Gate and Space Duel, and the early Mortal Kombat series. Of these, only MK and Space Duel were two player simultaneous. Finally, I think only the Street Fighter and Capcom Fighter style games were six-button simultaneous, but it is a good idea to support these games if there is any chance you (or your friends) might be playing them.
For 3-player games, there are many 3-player 3-button games. There are no 3-player 4-button games; however, you might want to play the 4-player 4-button games with only three players. There is only one 3-player 5-button game "Guardians of the Hood" in MAME as a test driver, and only one 3-player 6-button game - "Powerpuff Girls", Status unknown.
For 4-player games, there were many 4-Player 2-button or 4-Player 3-button games. There are three 4-player 4-button games - Dungeons & Dragons - Shadow Over Mystera, Dungeons & Dragons - Tower of Doom, and NBA Jam Extreme. There are no 4-player games with more than 4-buttons. Super Street Fighter 2 - Tournament Edition is 4-player but 2 players play at any time and alternate. War: Final Assault is 4-player with 6 buttons and a trigger stick with thumb button (8 buttons) but the game had 4 cabinets networked together, so it should be considered single player when selecting an encoder.
There are no 5-player games; however, I have included them in the chart below, because you might want to play a 6-player game with only 5-players present.
There is one 6-player 2-button game - Hard Dunk (emulated by Modeler), two 6-player 3-button games - X-men and JSR Arcade - Second Chapter and one 6-player 6-button game, Clue (although I think that one may be bogus).
In addition, while these games expect discrete coin inputs, in most cases the Px Start buttons, etc., while present on the CP, are actually mapped in parallel to the P1B1 buttons, so these can be eliminated when planning a CP. (See this page for details).
The first thing this clearly means is that the P3SW5 through P3SW8 and P4SW5 through P4SW8 inputs on the I-PAC/4 are meaningless for arcade emulation as defined (they are still useful to have as extra inputs - i.e. for admin functions, for console emulation; but they won't be used the way they are named).
The next thing is that we can play 99% of all MAME games with 4-players and 3-buttons each support. So, we need 28-inputs total, plus 4-coin buttons, or 32 inputs total.
The standard 4-player 4-button panel with a SF/NeoGeo layout (7 buttons) for player 1 and 2, can be easily handled with 48 inputs, either by the 56 input I-PAC/4 or 64 inputs with two GP-Wiz's as follows:
- 16 inputs for 4 joysticks.
- 14 inputs for Player 1 and 2 Buttons (7 each)
- 8 inputs for Player 3 and 4 buttons (4 each)
- 2 inputs for Escape and Pause
- 4 Coin Inputs
- 4 Start Inputs
OTOH, if we want to be able to play ALL emulated arcade games, with no overlap, and no compromises, the magic number of inputs is 68 as follows (this is based on using Druin's Rotary Interface for mechanical rotary joysticks):
- 24 inputs for 6 joysticks.
- 16 inputs for Player 1 and 2 Buttons (6 Action buttons each in a HotRod style layout, with one button repeated for Neo-Geo games, buttons 7 and 8 for joystick rotation).
- 8 inputs for Player 3 and 4 buttons (4 each)
- 6 inputs for Player 5 and 6 buttons (3 each)
- 2 inputs for Escape and Pause
- 6 Coin Inputs
- 6 Start Inputs
This results in the following categories, as shown in the Comparison Table section:
- Street Fighter - This is the standard, 2-player setup, as shown on the HotRod, X-Arcade, OzStick, etc. It requires two joysticks and 6 buttons each, so 20 inputs, or 22 with coin inputs.
- Ikari/Street Fighter - This is the same setup as above but with additional inputs for mechanical rotary joysticks. This requires 24 inputs, or 26 with coin inputs. Note that it would be possible to achieve the same functionality with no additional inputs by using optical rotaries, or by mapping the rotation inputs in parallel to buttons 5 and 6 and using switches to allow/prevent the rotation inputs from registering. (AFAIK, there are no rotary joystick games with more than 3 buttons each, most only have two buttons.)
- Tank Games - Basically, this is a set-up to support Sarge and Vindicators (two 2-way (vertical) two thumb buttons, two trigger buttons, and one action button per player), Assault (two 4-way joysticks and two buttons), and a handful of games requiring four 4-way trigger and thumb button joysticks. These require 26 inputs, or 28 with coin inputs.
- Three-player, 3-button games - These require 21 inputs, or 24 with coin inputs.
- Four-player, 2-button games - These require 24 inputs, or 28 with coin inputs.
- Four-player, 3-button games - These require 28 inputs, or 32 with coin inputs.
- Four-player, 4-button games, these require 32 inputs, or 36 with coin inputs. (And remember, we are only talking about three games (unless Tekken gets emulated).
- Five player, 2-button games, these would be six player 2-button games with one player missing. This requires 30 inputs or 35 with coin inputs. (only two games).
- Five player, 3-button games, again these would be six-player 3-button games with one player missing. This requires 35 inputs or 40 with coin inputs. (only one game).
- The next jump is six-player 2-button games - 36 inputs or 42 with coin inputs. (and again, only two games).
- The final emulation level is six-player 3-button games - 42 inputs or 48 with coin inputs. (and there's only one of these).
- Beyond this, for console emulation, 4-player games, we generally need 6 buttons per player plus Start and Select, or 48-inputs. (However, most console games are designed for and would play better on a USB gamepad than on true arcade controls, so I don't recommend using an encoder for these.)
There are also some PC games that require 8 buttons per player. I don't specifically cover these, but if you want to enable them with your encoder, ensure that you have enough inputs.
At this point, we're ready to examine our options. The encoders have been listed by increasing number of inputs, which is a fair measure of functionality. However, an encoder with more inputs than you need, is not cost-effective. The Hagstrom, MAMI, and some other units are included for completeness, but, IMHO, their limited features do not justify their cost compared to the other encoders. (Yellow text indicates discontinued and no longer available items.)
|Interface||Price (Note 1)||Inputs
(Notes 2 and 3)
|GAMEPAD ENCODERS (BUTTONS ONLY) (Note 11)|
Usually Matrix Buttons
|USB, Gameport||Yes, for Playstation Pad Hacks||Individual Bare Wires or Solder Points||N/A||No|
GP-WIZ Max (Note 11.3)
$23, IDE Header
|None||No (Note 11.2)||USB||No||Solder
or IDE header (Std)
Terminal Strips (Max)
|No, Not needed.||No|
|$10 (Note 11.6)||60 Matrix Buttons
|None||Yes (Note 11.8)||LPT Port
|No||Your choice||No, Not needed.||No|
|Interface||Price (Note 1)||Inputs
(Notes 2 and 3)
|GAMEPAD ENCODERS (ANALOG CONTROLS AND BUTTONS) (Notes 11 and 11.10)|
|Microsoft Sidewinder Dual Strike Gamepad Hack (Note 11.11)||$5 to $15
13 Matrix Buttons
|6 (Note 11.14)||Yes (6 buttons) (Notes 11.2 and 11.15)||USB||No||Solder||N/A||No|
- Analog Kontrol
14 Direct Buttons (Note 12)
|None||No (Note 11.2)||USB||No||Terminal Strips||No, Not needed.||No|
4 Axes and 24 Direct Buttons to 0 Axes and
32 Direct Buttons
|30 (Note 12.3)||No (Note 11.2)||USB||No||Terminal Strips||No, Not needed.||No|
|Interface||Price (Note 1)||Inputs
(Notes 2 and 3)
|GAMEPAD ENCODERS (49-WAY JOYSTICKS AND BUTTONS) (Notes 11 and 12.4)|
|SJC - Simple 49-Way
10 Direct Buttons
|None||No (Note 11.2)||USB||No||Terminal Strips||No, Not needed.||No|
$23 Eco, IDE Header
23 Direct Buttons
|5 (Note 12.9)||Yes (Note 11.2
or IDE header (ECO)
Terminal Strips (Std)
|No, Not needed.||No|
|Interface||Price (Note 1)||Inputs
(Notes 2 and 3)
|KEYBOARD ENCODERS (Note 11)|
|16 Matrix Buttons
|Keyboard Hack||Free ;-), + solder and wire.||16-18 Useable Matrix Buttons
(max), 107 Total Buttons
|None||No||PS/2 (Note 14)||No||Individual Bare Wires||No||Yes|
|Hagstrom KE18||$45||18 Direct or 81Matrix (9x9) Buttons (Note 15 and 15.1)||None||No||PS/2||No||IDE Header||Yes||No|
|Interface||Price (Note 1)||Inputs
(Notes 2 and 3)
|24 Direct or 14x8 (104 Useable)
|None||Yes (Note 15.4)||PS/2 or USB, depending on version||No||IDE Header||Yes||No|
|Hagstrom LP24||$80||24 Direct or
23x1 Matrix or Up to a 12x12 Matrix in Any Combination Buttons
(Note 15 and 15.5)
|None||Yes (Note 16)||PS/2||No||IDE Header||Yes||No|
|Hagstrom KE24||$100||Same as LP24||None||Yes (Note 16)||PS/2||No||IDE Header||Yes||No|
|MAMI 24||$45||24 Direct Buttons||None||No (Note 17)||PS/2 or DIN5||No||Terminal Strips||Yes||No|
|27 Direct or Up to 128 (101
Useable) Matrix (Up to 8x16 Matrix) Buttons
|None||Yes, EEPROM (Note 20)||PS/2||No||Your choice.||Yes||Yes (Note 21)|
|Interface||Price (Note 1)||Inputs
(Notes 2 and 3)
|28 Direct Buttons (Note 22)||27||Yes, EEPROM (Note 23)||PS/2 or USB (Note 6and 23.1)||No||Terminal Strips||Yes (Note 24)||Yes (Note 25)|
|J-PAC (Note 26)||$57 (Standard)
|28 Direct Buttons (Note 22)||27||Yes, EEPROM (Note 23)||PS/2 or USB (Note 6 and 23.1)||No||JAMMA Edge Connector and Terminal Strips||Yes (Note 24)||Yes (Note 25)|
|Mini-PAC or here (Note 27)||$29 (Board Only)
$46 (With Harness)
$49 (With Harness and USB cable)
$69 (With wiring and trackball harness)
|28 Direct + Trackball and
|27||Yes, EEPROM (Note 23)||PS/2 or USB (Note 6 and 23.1)||No||IDE Header||Yes (Note 24)||Yes (Note 25)|
|X-Arcade PCB||$60 (Note 28)||28 Direct? Buttons
|None||3 alternate code sets, EEPROM? (Note 30)||PS/2 or USB (Note 30.1)||Yes||Pin Headers with a Wire Harness that you would cut.||Yes||No|
|MAMI 30||$50||30 Direct Buttons||None||No (Note 17)||USB||No||Terminal Strips||No, Not needed.||No|
|HotRod Encoder (Note 30.2)||N/A (Note 30.3)||32 Matrix Buttons
|??? (Note 30.6)||32 Matrix Buttons
|Interface||Price (Note 1)||Inputs
(Notes 2 and 3)
KeyWiz STD KeyWiz MAX
KeyWiz ECO 2
KeyWiz MAX 1.5
(Eco, discontinued 17Nov04)
$34 (Std, discontinued 25Nov03)
$37 (Max, discontinued 25Nov03)
$20 ECO 2, solder terminals
$23 ECO 2, IDE header
|32 Direct Buttons (Note 31)||24 (Note 32)||Yes, SDRAM (Note 33)||PS/2||No||Solder (ECO)
Solder or IDE header (ECO 2)
Terminal Strips (Std, Max and Max 1.5)
|Not a traditional one (Note 34)||No|
|I-PAC VE||$35 (Note 35)||32 Direct Buttons
|28 (Note 37)||Yes, SDRAM (Note 23)||USB||No||Terminal Strips||No, Not needed||Yes (Note 25)|
|$80||36 Direct Buttons + Trackball||None||Yes (Note 16)||USB||No||IDE Header||No, Not needed||Yes (Note 38)|
|MAMI 48||$70||48 Direct Buttons||None||No (Note 17)||PS/2 or DIN5||No||Terminal Strips||Yes||No|
|Interface||Price (Note 1)||Inputs
(Notes 2 and 3)
|56 Direct Buttons
|2 Sets of 27 Each||Yes, EEPROM (Note 23)||PS/2 or USB (Note 6 and 23.1)||No||Terminal Strips||Yes (Note 24)||Yes (Note 25)|
|Lupine Systems 64-Input Encoder (Note 40)||$35||60
(64 With 4 Duplicates)
|None||No||DIN5||No||IDE Header (groups of 8)||No||No|
|$63||64 Direct Buttons, or 52 Direct Buttons Plus
Mechanical Rotary Joystick Support.
|7 (Note 43)||Yes, EEPROM (Note 44)||PS/2||No||IDE Header||Yes||Yes (Note 45)|
|72 Direct Buttons, KE-72T Also Includes a Trackball to PS/2 Mouse Port Interface||None||Yes, EEPROM
|PS/2||No||IDE Header||Yes||Yes (Note 47)|
|Interface||Price (Note 1)||Inputs
(Notes 2 and 3)
|OPTICAL INTERFACES (Note 48)|
|DIY Mouse Hack (Note 49)||Free ;-), + solder and wire.||3 Matrix? Buttons
|None||No||Any (Note 51)||No||Soldering||No, Not needed||No|
|OSCAR USB Mouse Interface (Note 52)||$9.00 (0 buttons)
$12.50 (2 buttons)
|2 Matrix? Buttons
|None||No||USB (Note 53.1)||No||Supplied Wiring Harness, Headers||No, Not needed||No|
|Happ Trackball Interface (Note 54)||$44 (Small T-ball)
$52 (4.5-inch) (Note 54.1)
|3 Matrix? Buttons||None||No||USB or PS/2||No||Supplied Wiring Harness||No, Not needed||No|
|Interface||Price (Note 1)||Inputs
(Notes 2 and 3)
|$80||36 Direct Buttons + Trackball||None||Yes (Note 16)||USB||No||IDE Header||No, Not needed||Yes (Note 38)|
|$140||72 Direct + Trackball to PS/2 Mouse Port Interface||None||Yes, EEPROM
|PS/2||No||IDE Header||Yes||Yes (Note 47)|
|Mini-PAC or here (Note 27)||$29 (Board Only)
$46 (With Harness)
$49 (With Harness and USB cable)
$69 (With wiring and trackball harness)
|28 Direct + Trackball and Spinner (Note 22)||27||Yes, EEPROM (Note 23)||PS/2 or USB (Note 6)||No||IDE Header||Yes (Note 24)||Yes (Note 25)|
|4 Direct Buttons and 2 Trackballs plus 4 Spinners (Note 55)||None||No||USB or Serial (Note 56)||No||Terminal Strips||No, Not Needed||No|
|Interface||Price (Note 1)||Inputs
(Notes 2 and 3)
|ROTARY JOYSTICK INTERFACES (Note 57)|
|??? (Note 59)||Requires 12 Inputs per Joystick (Plus Directionals)||N/A||N/A||Same as Encoder||N/A||Same as Encoder||Same as Encoder||Same as Encoder|
|$10 (Note 61)||Requires 2 inputs per Joystick
Controls two joysticks
|N/A||N/A||Same as Encoder||N/A||Your choice.||Same as Encoder||Same as Encoder|
|Druin's Rotary Interface
|$25||Requires 2 inputs per Joystick
Controls two joysticks
|N/A||N/A||Same as Encoder||N/A||Input - Pin header
Power and Output - Terminal Strips
|Same as Encoder||Same as Encoder|
|$63||64 Direct Buttons, or 52 Direct Buttons Plus
Mechanical Rotary Joystick Support.
|7 (Note 43)||Yes, EEPROM (Note 44)||PS/2||No||IDE Header||Yes||Yes (Note 45)|
|Interface||Price (Note 1)||Inputs
(Notes 2 and 3)
All prices are in U.S. dollars and should be accurate as of 26Apr05,
unless stated otherwise. I decided not to include shipping
costs, but these could
play a significant factor and should be considered before making a
(2) Do NOT merely use the number of inputs to determine what applications an encoder is capable of. Things such as Shift Key support and other shortcuts play a significant factor in their capabilities, and are accounted for in the Comparison Table section of this page. Note how much better the keyboard hack does than the KE18.
(3) See this section for a discussion of Direct Mode vs. Matrix Mode.
(4) See this section for a brief overview of Shift Keys and this page for a detailed discussion of Shift Keys and their usage. Also note that if your encoder does not support Shift Keys, a similar effect can be obtained in MAME as mentioned in the General Considerations section of the linked page.
(5) See the Programmability and SDRAM vs. EEPROM and Software sections for more information. This section is complicated by what is meant by programmability. For example, some encoders can be programmed from a batch file. Some retain custom codesets after power-down, etc. For purposes of this column, Yes means that there exists some way (outside of keyboard re-mapping software or Joytokey, etc), to change the default settings of the interface); however, I will try to add additional footnotes as applicable.
(6) See this section for a discussion of USB vs. PS/2 (Keyboard encoders only).
(7) This refers to the ability to use the encoder with an actual PlayStation, Nintendo, X-Box, or Dreamcast, not to support console emulation.
(8) Generally screw terminal strips are the most convenient (IMHO). However you can always go from an IDE header or even bare wires to a Terminal block and get basically the same effect for additional cost. See this section for more details.
(9) See the Keyboard Pass-Through Alternatives section for other solutions if your encoder does not include a pass-through.
(10) MAME flashes the Num Lock and Caps Lock LED's to simulate Coin inputs on certain Atari and Pac-Man games. The Scroll Lock LED is also used in some games, but it does not have a consistent function and I don't recommend using it on a control panel. If your encoder lacks LED support, you could gut a USB keyboard and use the LED lights from it on your panel. None of the encoders have the power to directly drive High-Intensity LED's which many people like to use to illuminate buttons, etc. However, OSCAR has a driver board schematic, which will allow the encoders to work with these LED's. Also, RandyT (KeyWiz designer) is working on an add-in card which will provide universal LED support and increased functionality and work with any encoder.
(11) See this section for a comparison of gamepad and keyboard encoders.
(11.1) See this section for gamepad hack info.
(11.2) Programs such as Joytokey and RBJoy can be used with gamepads to send keycodes, making them basically programmable. See the Gamepad Encoder Useful Software section for more details.
(11.3) The GP-Wiz is a 32-input gamepad encoder. As mentioned in the Gamepad Encoder vs. Keyboard Encoders section, it could principally be used as a stand-alone encoder, or an add-on encoder for additional panels/inputs in conjunction with an existing keyboard encoder. Yet another use would be as a way to directly interface SNK LS-30 or Happ Mechanical Rotary Joysticks directly to MAME Analog Plus as an alternative to using Druin's Rotary Interface.
(11.4) Inputs register as Joystick 1 Directionals and Buttons 1-28; however, buttons could be used for the digital inputs, or digital joysticks for the button inputs. Note that many PC Programs as well as ZSNES only recognize the first 16 gamepad buttons, so you have to use software to send keycodes instead of button presses to use these inputs with these programs. MAME is not affected.
(11.5) This is the cheapest and kit-wise easiest (but maybe not the best) way to add 60 non-ghosting inputs to your PC. The interface consists entirely of an LPT (DB25) connector, about 5 resistors, and about 60 diodes. There is no integrated circuit or even transistors involved. In fact, the circuit could be built without soldering, although this would add significantly to the cost. Two versions of the circuit exist, a 40-input version, and a 60-input version. In theory, the circuit could be expanded to support 108 or 156 inputs, although the software currently (5May05) doesn't support more than 60. OTOH, the device is matrix-based, so it is more complicated to wire up than a direct-mode encoder. For more information, refer to this BYOAC thread, Trimoor's page (local mirror) or the Fokker50 page (local mirror)
(11.6) Completed versions are not directly available. Price is estimated from the components required.
(11.7) For the 60-input version, inputs are reported as Joystick 1 Buttons 1-30 and Joystick 2 Buttons 1-30. Note that many PC Programs as well as ZSNES only recognize the first 16 gamepad buttons, so you have to use software to send keycodes instead of button presses to use these inputs with these programs. MAME is not affected.
(11.8) The interface can be re-programmed to different keyboard keys, however, the software seems to run through the control panel applet, so there is no way to save or load custom codesets. PPJoy seems to be the most popular software and the only current one to support 60 inputs. The Fokker 50 software only supports 40 inputs but does support macros and combinations. The software is also open-source so it is possible that more capable applications will be developed.
(11.9) The device connects to the LPT port, so no keyboard pass-thru is required. The LPT port is rarely used on an arcade machine, and additional ports can be added through PCI cards, if required. The port is much more common than gameports are; however, as more and more printers and scanners convert to USB, I am not sure how far into the future the LPT printer port will remain supported.
(11.10) See this section for a discussion of analog controls and interfaces, including special considerations for gas/brake pedals. Note that under Windows '98 you must connect at least one button to each joystick interface in order to calibrate it (not required for XP).
(11.11) The Microsoft Sidewinder Dual Strike Joystick is included because it was one of the earliest and cheapest ways to connect an arcade analog control to the PC. The device is popular b/c it was designed using 20K pots that only turned 1/4 of their normal travel, so it works perfectly with standard arcade controls which typically used 5K pots. See this page (local mirror) for a short review of the stock joystick, this page for a more in-depth review, here for a graphic stolen from the second review showing the button locations, here (local mirror) for 1Up's Dual Strike hack, here (local mirror) for Rdagger's Dual Strike hack, here (local mirror) for a BYOAC thread by Fitzy showing how to hook up the buttons to the PCB. And here (local mirror) (b/c pictures are worth 1000 words) for the same info in photos from UncleT.
(11.12) The Dual Strike is discontinued; however, the units often show up on E-bay. For pricing, it is often advisable to purchase a broken one, as the parts that are likely to break will be removed by the hack anyway.
(11.13) The Sidewinder Dual Strike supports two joystick axes and the following buttons: D-pad (4 buttons), A-Button, B-Button, C-Button, D-Button, X-Button, Y-Button, Shift Button, Left Trigger, and Right Trigger.
(11.14) The six-face inputs (A, B, C, D, X, and Y) can be shifted to perform a dual function.
(11.15) The driver software has an option to select between mouse, joystick, and keyboard functions, and also to select six keys (the six above?) to keyboard inputs.
(11.16) The AKI supports five analog axes and 14 buttons. The unit will auto-detect between 5K and 100K pots; however, unused analog axes must be tied to ground.
(12) Axes register as Joystick 1 Axis X, Y, and Z and Joystick 2, Axis X and Y, and Button Inputs register as Joystick 1 Buttons 1-7 and Joystick 2 Buttons 1-7.
(12.1) The A-PAC can basically be considered a cross between the AKI and the GP-Wiz encoders. Various values of potentiometers can be supported through the use of the appropriate capacitor. The encoder appears to the computer as two gamepads. Depending on application, the unit stacks up well to the AKI b/c of the greater number of digital inputs as opposed to one less analog axis, but lacks the ability to auto-detect values of potentiometers, and also requires both potentiometers on a "side" (Joystick 1 X- and Y-axis) to have the same value. IMHO, the unit stacks up well against the standard GP-Wiz due to the availability of analog connections, the availability of shifted inputs, and the convenience of being seen by the computer as two gamepads. Against the GP-Wiz Eco versions, you have to weigh the likelihood that you will utilize the extra capabilities against the additional cost of the encoder.
(12.2) The A-PAC supports up to 4-analog axes and 24-buttons, or full digital control and 32 buttons or a combination (32 digital inputs, or 1 analog axis and 30 inputs, or 2 analog axes and 28 inputs, or 3 analog axes and 26 inputs, or 4 analog axes and 24 inputs). Inputs are seen as Joystick 1 directionals and Buttons 1-12 and Joystick 2 directionals and Buttons 1-12. Only 15 inputs per Joystick (30 per interface) can be used for "Action" (non-administrative) buttons if shift functions are used (otherwise, you'll always be accidentally activating the shift function.) Also, the D (Detect) input on each side disables the axis inputs so really shouldn't be used for action functions (but could be used for administrative functions).
(12.3) The C terminal (Seen as Button 11 by the OS) can be used to shift the button inputs as follows: The directionals (R, L, U, D) send shifted Buttons 13-16, respectively. Buttons 1-12 send shifted Buttons 17-28, respectively. NOTE: Button 27 (shifted Button 11 - Terminal C - Shift Key) is not generated, but does show up in the Windows Game Controllers window.
(12.4) See this section for a discussion of 49-way Joystick Controllers. NOTE: For both interfaces, the controller is setup for installation with the joystick interface board facing left (when viewed from the top). This results in a horizontal orientation for the joystick. However, it is probably possible to remove, rotate, and re-install the interface board to allow a vertical orientation (still with the interface to the left). It also might (untested) be possible to mount the interface board to the top or bottom of the joystick and swap the axis leads to the interface.
(12.5) The SJC supports a single 49-way Joystick and 10 Buttons. The interface auto-detects between Happ or Williams sticks. Linear or progressive scaling is supported and selectable in hardware by connecting a terminal to ground.
(12.6) Inputs register as Joystick 1 Buttons 1-10.
(12.7) The GP-Wiz49 and GP-Wiz49 Eco allow the connection of a single 49-way joystick and 23 buttons (or other digital inputs). Digital Restrictor Selection™ allows the joystick to appear to the computer as either a 49-way analog stick, 49-way progressive, 8-way, 4-way, rotated 4-way, 2-way vertical, 2-way horizontal, or 16-way stick. Happ or Williams sticks can be auto-detected, and selection can be over-ridden through software. Modes can be selected either manually (using a button combination), manually using a rotary switch, or through software, either interactively, or remotely through command-line arguments.
(12.8) Inputs register as Joystick 1 Buttons 1-23. If the rotary switch option is utilized, the first 8 buttons are used for mode switching and the remaining buttons are renumbered as Joystick 1 Buttons 1 through 15. Note that many PC Programs as well as ZSNES only recognize the first 16 gamepad buttons, so you have to use software to send keycodes instead of button presses to use these inputs with these programs. MAME is not affected. Also, since one GP-Wiz49 is required per 49-way joystick, this is much less likely to be a problem, unless you were using a digital joystick for Player 2, for example.
(12.9) Shifted buttons are disabled when the rotary switch option is utilized, otherwise, Buttons 9 through 13 are shiftable (through the mode input) and seen as Buttons 24-28, respectively.
(12.10) Software for selecting the various DRS™ modes is available at http://www.groovygamegear.com/GPWIZ49.zip.
(12.11) The TOKN KB16 Encoder is difficult to recommend. At it's full retail price, it is more expensive than the solderless version of the KeyWiz Eco2, offers half the number of standard inputs (and at most 2/3 of these can be used without ghosting unless diodes are employed), no shifted inputs, the same IDE header connection method, but requires twice as many wires per switch due to the lack of a common ground connection, and cannot load a saved config file nor be programmed interactively without an attached keyboard. The "advantages" of the device are the use of EEPROM to allow memory retention of an alternate saved codeset and an active keyboard pass-thru which allows daisy-chaining of multiple encoders. YOU do the math! Even at the introductory price ($10.50), the device barely fares better (arguably) than a standard keyboard hack. The introductory price is higher than the cost of a keyboard hack, and the encoder has 16 total inputs ("effective" 12 inputs for a two-joystick solution without diodes), compared to an "effective" 20 active inputs (for a two-joystick panel) and an unlimited (104, 107) number of total inputs which could be used for admin functions for the keyboard hack. The advantages over a keyboard hack are the lack of soldering, the ability to program any keystroke to each input, and the presence of the active pass-thru. Basically the functionality of the device is limited to a small controller for a classics-only cab or CP. My detailed review of the encoder is available here. Current (8Jul05) documentation of the device is available from www.tokn.net and mirrored here, here, here, and here. As of 8Jul05, BYOAC threads on the device are here, here, here, and here.
(12.12) The TOKN KB16 is currently (26Apr05) readily available on E-bay for around $10.50, but I am not sure how long this price will be available. Units shipping after ??Jul05 now include a package of diodes at no additional cost.
(12.13) The TOKN KB16 basically uses an 8x2 matrix and exhibits ghosting unless inputs are carefully chosen or diodes are used.
(12.14) The TOKN KB16 and TOKN KB32 are programmable through an attached keyboard. No software is required and alternate codesets are retained in memory; however, there is also no way to save multiple codesets or load a different pre-configured codeset.
(13) Keyboards generally use a 16x7 or 16x8 matrix. This means you have 16 non-ghosting inputs and since Up and Down and Right and Left will never be pressed simultaneously, you can allow these inputs to ghost so you can support 2 joysticks and 6 buttons per player or 4 joysticks and 2 buttons per player. The firmware in modern keyboard chips prevents using diodes to gain more action inputs, but any of the remaining inputs can be used for non-action functions like Coin, Start, Tab, Esc, etc. Also, some PS/2 keyboards limit the number of inputs to 8 and are not useable for arcade emulation.
(14) USB keyboards are limited to six simultaneous inputs (plus modifiers such as Ctrl, Alt, and Shift) and are not suitable for arcade usage.
(15) I believe this encoder will exhibit ghosting in matrix mode, but this can possibly be overcome through the use of diodes.
(15.1) A jumper is used to select between direct and matrix mode.
(15.2) The KeyDog is mainly included for completeness. A unique feature of this encoder is the "WatchDog Timer" which can reset your computer in the event of a lock-up. The watchdog feature can be set to reset the computer after a settable time from 10ms to over 10 minutes. I am not sure how the unit senses lockups. KeyDog Tech Support said it was "dependent on seeing an LED state change at a regular interval" but I am not sure whether they meant the keyboard LED's or an internal LED on the KeyDog. I am a little leery that the device might re-boot your cabinet in the middle of a furious trackball game, but have no way to confirm this. The specification sheet on the KeyDog is available on their website and mirrored here.
(15.3) The KeyDog can be operated as a 24-input direct mode encoder, or a 104-input Matrix mode encoder. Selection of direct or matrix mode is made through software. In direct mode, the unit can be either common Ground or common +5V. For operation similar to the KeyWiz or I-PAC, you would select common Ground by placing a Jumper on Pins 1and 2 of header J10. The matrix mode uses a 14x8 matrix with 8 keys unassigned for 104 available keys. Diodes or careful key selection must be made to avoid ghosting. The encoder can actually support a 16x8 matrix on request at additional charge or custom matrix key assignments for quantity orders. The default matrix assignments are included in the specification sheet above.
(15.4) The KeyDog is programmable. Custom key assignments as well as the configuration or enabling/disabling of the watchdog timer, can be selected and loaded from a batch file. The direct mode key assignments can be changed but the matrix-mode key assignments are fixed and not programmable.
(15.5) Software is used to select between direct and matrix mode and to set key assignments.
(16) Key assignments can be changed through software, but I don't know if alternate configurations can be loaded on-the-fly (through a batch file, for instance).
(17) Encoder can be ordered with custom codeset instead of the default, but I don't know about cost.
(18) The ButtonBox is not available for purchase. All plans, parts lists, and schematics are available on their website.
(19) Diodes are used in Matrix Mode to prevent ghosting. All inputs are programmable, but only the standard 101 Keyboard keys can be assigned.
(20) The ButtonBox is programmable. Custom codesets can be loaded from a batch file, but the software for this only works in Windows 95, 98, or ME (not NT, 2000, or XP).
(21) See the ButtonBox LED Considerations and ButtonBox LED Wiring sections for details.
(22) See here for the Ultimarc default codeset. Only 27 inputs can be used for "Action" (non-administrative) buttons if shift functions are used (otherwise, you'll always be accidentally activating the shift function.)
(23) Very easy to program, Simple to understand software, Config files can be loaded from the encoder software or from batch files. Latest software (WINIPAC IPD) claims less than one second load time and supports macro assignments (useful for programs that need Alt-F4 to exit). See this section for a chart of software compatibility with the various Ultimarc encoders.
(23.1) The Ultimarc Encoders have the following limitations when used in USB mode: Simultaneous limit of 14, 16, or 22 keys plus multipliers. Key-Repeat is enabled on all keys. In PS/2 mode, key repeat is only enabled on the Up and Down arrow keys.
(24) The keyboard pass-thru was disabled in USB mode, but this might have changed recently.
(25) See the I-PAC LED Considerations and I-PAC LED Wiring sections for details.
(26) The J-PAC is basically an I-PAC/2 which is optimized for connection to a JAMMA (Japanese Amusement Machine Manufacturers Association) arcade cabinet. The board uses a JAMMA edge connector for input connections and includes a video amplifier. The board uses a JAMMA Edge connector for the joysticks and Buttons 1-4 and screw terminals for buttons 4-6. (Button 4 can be wired either way.)
(27) The Mini-PAC is basically an I-PAC/2 with an IDE header combined with 1/2 of an Opti-PAC. The board includes controls for a trackball and spinner, but these only work in USB mode. The bare board contains all the basic functionality and is a better value if you can make your own harnesses. See http://www.ultimarc.com/mp_inst.html for wiring instructions.
(28) Now available again. Otherwise, you would have to hack an X-Arcade Controller to use the encoder.
(29) From what I have read, I think this device is active Lo, that is, each button goes to a common terminal, but that terminal is at +5V, rather than GND. This means that you cannot easily hook up P360 joysticks to an X-Arcade. The main advantage of the X-Arcade encoder is the ability to buy adapters to use the encoder with other console systems.
(30) A 4-position switch allows programming and switching between the default and three custom codesets. There is no way to load an alternate codeset from software.
(30.1) The USB adapter is now included with the kit.
(30.2) The HotRod encoder is included for reference and completeness only. The fact that the encoder uses the Numpad keys for Joystick 1 rather than the direction arrows could indicate buffer and performance problems with the encoder, or it could be for compatibility with very old DOS programs. The unit is not compatible with some motherboards. Documentation of the pin-out for connecting controls is available here (local mirror).
(30.3) The encoder is not commercially available. The information listed here is either for someone who has purchased a HotRod controller and wants additional information about the encoder, or occasionally, the encoder itself will be available on E-bay presumably either by someone who broke their HotRod Controller, or someone who upgraded their unit to a different encoder.
(30.4) The HotRod Controller only uses 28 inputs, but the encoder actually supports 32 inputs.
(30.5) The TOKN KB32 Encoder is a revision of the KB16 with double the number of inputs. Currently (17May05) it is only available on E-bay, and no information is available on the TOKN website. If no one bids on one (roughly $10) it's not a bad solution if you don't require easy programmability. At anything approaching the price of the solderless KeyWiz Eco 2 ($23) it suffers from most of the same drawbacks as it's smaller sibling (KB16): no shifted inputs, the same IDE header connection method, but requires twice as many wires per switch due to the lack of a common ground connection (and also requires two IDE cables as the headers on the board are split), and cannot load a saved config file nor be programmed interactively without an attached keyboard. The "advantages" of the device are the use of EEPROM to allow memory retention of an alternate saved codeset and an active keyboard pass-thru which allows daisy-chaining of multiple encoders. A copy of the E-bay advertisement from 17May05 is mirrored here. My speculative page on how to maximize the encoder's potential is here, and a BYOAC thread on the encoder is here.
(30.6) The TOKN KB32 is currently (17May05) readily available on E-bay for around $10.50 (but most auctions seem to close around $30-$35 or more), but I am not sure how long this price will be available. I think units sent after ??Jul05 are including diodes at no charge.
(30.7) AFAICT (not confirmed), the TOKN KB32 basically uses dual 8x2 matrices. This theoretically has has a technical advantage over either a 16x2 or an 8x4 matrix, b/c while ghosting will occur without diodes, it will not cross-over from one matrix to the other, so you can gain some advantages by grouping high-risk and low-risk ghosting admin inputs together.
(31) See here for the KeyWiz default codeset. See here for the KeyWiz Eco 2 default codeset and wiring instructions. The Shazaaam! button is independent, so all inputs may be used as "action" buttons. NOTE: KeyWiz encoders produced prior to approx 31Mar04 have "3" as the default output for input K, rather than "P", all other outputs are identical. NOTE 2: While all inputs are useable, unpredicted behavior may occur if opposite joystick directionals are pressed simultaneously. (Of course this can't occur if a joystick is connected to these inputs!) If buttons are going to be connected to these inputs, it is recommended that they be assigned to admin or other functions that will not be used simultaneously.
(32) The joystick directionals cannot be shifted and don't register when the Shazaaam! key is depressed.
(33) IMHO, easiest to use software of any of the encoders tested. Custom codesets can be loaded and applications launched from the encoder software or from a batchfile. In addition, the default (MAME-compatible) and one additional custom codeset can be retained in memory, holding the Shazaaam! key and moving the P1 Joystick Right loads the custom code set and Left loads the default codeset. The KeyWiz software is available at http://www.groovygamegear.com/kw.zip. A "stealth" version of the software (no splash screen when programming) is available at http://www.groovygamegear.com/KWstealth.zip.
(34) The KeyWiz MAX includes a keyboard pass-thru and the keyboard or the KeyWiz is selected as the active device by moving a switch. On the KeyWiz Max 1.5, this switch is re-positioned on the rear of the panel for easy accessibility. The KeyWiz Eco and Eco 2 do not include a pass-thru.
(35) Requires a standard USB A-B cable, not included. Includes free air mail shipping.
(36) See here for the Ultimarc default codeset. Added inputs A and B use the same defaults as other Ultimarc I-PAC series boards' inputs for SW7 and SW8. Added inputs C and D use the following defaults: 1C-Apostrophe, 1D-X (same as 1SW6 (???) >:-((, 2C-5, 2D-Enter. (Thanks jcroach from BYOAC). Only 31 inputs can be used for "Action" (non-administrative) buttons if shift functions are used (otherwise, you'll always be accidentally activating the shift function.) Note that since this encoder uses SDRAM, and since inputs 1D and 1SW6 are identical in the default codeset, you only have 31 inputs available if you use the encoder without reprogramming it at startup.
(37) The new C and D inputs (four inputs) cannot be assigned a shifted input; however, they can be assigned as shift keys.
(37.1) The KE-USB36 is similar to the I-PAC Mini-PAC in that it is a keyboard encoder with included trackball interface.
(38) See the KE-USB36 LED Considerations and Wiring section for details.
(38.1) The I-PAC/4 is basically the equivalent to two I-PAC/2's daisy chained together on the same circuit board, with the exception that you can program both sides of the board without unplugging one of them.
(39) See here for the Ultimarc default codeset. Only 54 inputs can be used for "Action" (non-administrative) buttons if both shift functions are used (otherwise, you'll always be accidentally activating the shift function.)
(40) This encoder was NOS (New Old Stock) from a batch made in 1995. Approximately 60 were available on E-bay as of 16Aug04. None were available when I checked on 17May05. See here for a copy of the 16Aug04 product listing on E-bay, here for an edited BYOAC thread with an E-mail from the seller, here for an edited BYOAC mini-review of the encoder, including default codeset, and here for an updated BYOAC thread on the encoder. My personal opinion on this is as follows: The encoder does what it claims; however, keep in mind that you are buying a product that is no longer manufactured and apparently has been catching dust in a warehouse for approximately ten years, so might need some repair work. My comments are then similar to what I quote RandyT as saying in the intro to my Keyboard Hacks page, i.e. only recommended for penny-pinchers or personal conquest. In summary, I would only recommend this for the following types of projects:
- Applications - This encoder should only be considered for applications which a) require a low-cost encoder solution. b) require an encoder with more than 32 inputs but less than 61 inputs (Mechanical Rotary joysticks using MAME Analog Plus or 4-Player cabs with no shared buttons) and c) do not require a programmable encoder (MAME or modern emulators, but no older emulators or PC games).
- Individuals - This encoder should only be considered by individuals for which budget considerations are a primary concern and who like the challenge of not using a mainstream approach, and for which either a) they can live with one or two banks of inputs possibly not working (essentially a 52 or 44-input encoder), or b) they own a soldering iron, a multi-meter, and the requisite skill set to trace printed circuit board wiring and repair if required. (And if b) applies, they probably could afford a less-troublesome encoder.)
The MK64 was discontinued on 23Feb04. I have a mirror of the
website available here
for preservation in case the main site gets removed.
Note that the six new features on the site (F7 key support, three
programmable key map
banks (0, 1, 2), Typematic function support, Startup settings, Macro
scripts, and dual
rotary joystick support) were added on boards produced after 4May03 and
were not included
on previous MK64 Boards. There also previously was a 40-input
version called the
MK40, but it was discontinued before the initial release of this
(42) See here and here for the MK64 (discontinued) default codeset. NOTE: I believe the MK64 shipped unprogrammed and you had to select or modify one of these files and load the desired set. Support for two mechanical rotary joysticks requires 6 rotation inputs each, leaving 52 remaining available.
(43) Input 00 serves as the shift key, and inputs 01 through 07 can be shifted. Remaining keys are not affected when shift is depressed. Shift function can be disabled as well.
(44) Programming is functional and alternate codesets can be loaded from batch files; however, there is no Graphical User Interface programming software. The most useful parts of the software consist of creating a keymap file in Notepad or Wordpad, and then using a command line program to load the keymap into the MK64, either from the command prompt, or from a batch file. It's cumbersome, but it works, though.
(45) See the MK64 LED Considerations and Wiring section for details.
(46) Programming seems very similar to the MK64.
(47) See the Hagstrom KE-72 (KE-72T) LED Considerations and Wiring section for details.
(48) See the Optical Interfaces section for more details.
(49) This can be done one of two ways. The simplest method involves just mounting the mouse so that the new encoder wheel passes through the existing mouse optics. This is shown in the Twisty-Grip spinner design here. A variation of this is to use a belt to transfer motion of the arcade control to the mouse as done by the Rotary T-Stik Plus Willy Wonka edition. The other preferred but more difficult method involves removing the mouse optics and soldering the arcade controller's optics in their place. This does not modify the operation of the arcade controller (but the mouse is pretty much history as a mouse afterwards). For this method, OSCAR recommends in this thread using Kensington or Belkin Mice and avoiding Logitech or Microsoft mice and provides details on how he makes his mouse hacks in this thread. Other example pages are provided by Nathan Strum (Cheeptech), MinWah, LuSiD, Massive Mame, WilcoxOnline, and BobA. Thanks to all the "pioneers" for documenting their efforts for us.
(50) Typically up to three buttons are available. (Actually 4-button mice are supported by MAME and are available).
(51) The hacked mouse will use the same connection method as the unmodified version.
(52) The OSCAR USB Mouse Interface (pre-hacked USB mouse) will work for a single dual axis device (trackball), and an additional spinner can be connected using a DPDT switch as shown here. Note that you can't connect both a spinner and trackball without the switch (even if you didn't mind them both being active).
(53) The Interface is made from a 3-button mouse, but the center button is usually used for the trackball ground. On request, the interface can be supplied with all three buttons available, but I'm not sure about additional charges for this option.
(53.1) Wakerlet from BYOAC recently posted that he has successfully used a standard USB-to-PS/2 mouse adapter with OSCAR's USB Mouse Interface.
(54) Included for completeness, not recommended b/c of price.
(54.1) Currently (19Jul05), there is an E-bay seller named collectorofneon selling the (presumably older) serial-PS/2 Happ trackball interface (P/N 56-1000-00 ??) along with 3 buttons and an extension cable with a "Buy-It-Now" price of $15, and $4 US shipping, but I have no idea how long this offer will be available.
(55) The Opti-Pac has four sets of terminals: Player 1 Trackball, Player 1 Rotary, Player 2 Trackball, and Player 2 Rotary. Each of these "sets" can support up to a 2-axis device (one trackball or two spinners). When connected, the Opti-Pac will Auto-switch between the Trackball and Rotary inputs for each player, i.e., when one device is moved the corresponding device for the same player is disabled for a set period of time. This is useful if you plan to have multiple optical devices connected. You can achieve a similar result using MAME Analog Plus, but you have to configure every game manually.
(56) The optical devices are connected as either two serial mice, or two USB mice over a single USB connection. Mixing of USB/serial interfaces is not supported.
(57) See the Rotary Joystick Interfaces section for more details.
(58) Direct Connection requires 12 additional encoder inputs per stick, MAME Analog Plus Version 0.77.1 or later (or equivalent NoNameMAME version), only works on actual rotary joystick games (not optical rotary games or spinner games) and currently 9 Jul 05 only works on about half of these.
(59) Additional cost for direct connection depends on the choice of keyboard encoder. If you have dual 49-way sticks with Fl0yd's rotary adapter and dual GP-Wiz49 encoders, you probably have enough spare inputs to implement this. You also probably would have plenty of inputs by sharing Player 3 and 4 inputs on an I-PAC/4 or MK64. Otherwise, your most reasonable option is to add a GP-Wiz32 Eco for the rotary inputs.
(60) Both Rdagger's and Druin's Rotary Interfaces convert the rotary of the joysticks into button presses for incremental rotation right and left. These outputs are then sent to the keyboard encoder as two switch closures and then sent as keyboard presses to the PC. It is recommended (but not required) that you use the MC-Escher source files (released for MAME 0.59 and incorporated in MAME Analog Plus in 0.71.2, improved through 0.74.1 and included in later builds). Some adjustment to the analog sensitivity settings may also be required. Both interfaces also require an external +5V source supply, either from the encoder or the PC power supply. They also can only be used with direct-mode, not matrix-mode encoders. A local mirror of Rdagger's page is available here.
(61) Price is from Rdagger's site and is for the pieces/parts to build your own interface. Completed assemblies are not readily available. (An Interface Cable is required to program the chips and I'm still not sure how to do it.)
This section will give an overview of the device types and the Specific Considerations section will deal with individual items related to arcade interfaces.
While gamepad and joystick hacks have been around for a long time, true dedicated gamepad encoders are a fairly recent (??Apr05) development. Basically, the concept is similar to the keyboard hack, except that the encoders are seen by the PC as gamepads. This means that multiple devices can be plugged in without conflicts, and while some of the devices incorporate shift functions, there is really little reason to make the devices programmable.
Because of features/price, this section is aimed primarily at the GP-Wiz series of encoders; however, the general principles should apply to any gamepad encoder.
Performance Considerations: There has been lots of debate on the performance advantages of PS/2 over USB for keyboard encoders. Thankfully the same is not the case with gamepad encoders. The USB specification is geared toward gaming devices, and I have been informally told by a developer of these devices that the performance is at least the equal, if not slightly better, than their PS/2 keyboard encoders, plus the convenience of specification-supported hot-swappability.
Feature Considerations: There are three ways that these can typically be used - as a primary encoder, as multiple encoders with swappable panels, and as a controller for add-on panels in addition to a keyboard encoder. I will look at all the options below:
Primary Encoder: There are two concerns with using a gamepad encoder as a primary encoder - the type of software you run, and if you want to have a "Plug and Play" type controller. Regarding software, MAME will recognize all gamepad encoders, so you don't have any problems using it. You will have to re-configure the start and coin inputs, the admin functions, and (in the case of the GP-Wiz) the Player 2 controls to use gamepad inputs, but this is a simple one-time setting change. Most emulators will support gamepads directly. Many PC games will only support keyboard input, but there are programs to "translate" the gamepad buttons into keypresses. Using this software is no more difficult than programming your encoder to a different codeset, which you would have to do with a keyboard encoder for these games anyways. About the only disadvantage would be if you were taking a CP to a friend's computer, where a keyboard encoder with the default MAME set would work "out of the box", but a gamepad encoder based system would need to be configured initially.
UPDATE: Thurman from BYOAC recently posted that both ZSNES and Gene Rally only recognize the first 16 gamepad buttons for each gamepad. This creates some challenges for the GP-Wiz line of encoders. Ironically, the easiest and most practical solution is to use either of the software programs below to simulate keyboard inputs to be sent from your gamepad encoder to your console emulator that originally used gamepads. Go figure!!!
Multiple Encoders: This is an area where these products really shine due to the ability of the controls to "shift downward". For example, let's say I have a Street Fighter Style desktop controller, and an Ikari Style desktop controller. I want to be able to use either panel for any one or two player games, and I want to be able to use both together for 4-player games. There is no way to do this with multiple PS/2 encoders, b/c you can't connect them both to the computer at the same time. With multiple USB keyboard encoders, you would have to reprogram the second keyboard encoder to send Player 3 and 4 outputs when you are playing a 4-player game. With a large keyboard encoder, it could be done using DB25 ports between the encoders and the panels, but the wiring gets VERY complicated. With gamepad encoders, it becomes mind-numbingly simple: Plug the panel in. If no other panel is present, it becomes gamepad one. If another panel is installed, it becomes gamepad two, etc.
Add-On Panels: Another useful area for these encoders is in addition to a keyboard encoder panel for additional controls. The advantage is similar to above. Let's say you have a PS/2 keyboard encoder installed, but you want to add a secondary panel with more inputs. You could use one or more USB keyboard encoders, but you would have to program them away from the default configuration so they did not conflict with your PS/2 keyboard encoder. With a gamepad encoder, this is not required because you can use keyboards and gamepads at the same time, so there are no conflicts.
Either Joytokey or RBJoy can be used with a gamepad encoder to send keycodes rather than gamepad button presses. I have not used either program. Joytokey has been around longer, but RandyT says that RBJoy is more capable.
NOTE: The information below should be accurate for a Windows system. I am not sure if Linux suffers the same problems, or even if the USB Device ID is used by Linux. Contact me if you know and I will update this section.
What are these and what should you know about them?
The USB Device ID is how Windows identifies a peripheral device. Refer to this linked and the following question on this page for a detailed description of how MAME handles devices with the same device driver. (The reference page deals with mice and duplicate drivers in MAME Analog Plus, but gamepads are handled the same way and regular MAME (and Analog Plus) now supports up to eight devices. Also, for purposes of this discussion, devices with the same USB Device ID will act the same to MAME as devices with the same driver, and devices with differing USB Device ID's will be seen as devices with different drivers.)
In commercial arcade controls, I believe DaveB's AKI was the first device that could be ordered with specified USB Device ID's, and the option has since been added to the SJC, the GP-WIZ, the GP-WIZ49, and on-request to the A-PAC. BTW, it is important to mention that the device ID is not changeable, once it is determined it is permanent. (I think the manufacturer COULD reflash the microprocessor to change the device ID, but you would have to contact them on an individual basis to confirm this.)
So should my devices have different device ID's or not? The short answer is "If you are not sure - you are safer having different ID's". The long answer is below:
Arcade Cabs with permanent control panels - The biggest problem with having two devices with the same device ID is that if you leave the devices plugged in and restart Windows, they may swap locations. For example, let's say you have a two-player cabinet with 49-way joysticks and two GP-Wiz49 interfaces with the same device ID's. You set the left stick up as Joy1 and the right as Joy2 and set MAME up for all your games and re-boot. There is a good chance that the joysticks will swap positions when you restart and the left stick will appear as Joy2 in MAME and the right stick as Joy1. Slightly awkward if you don't know what to expect when you start the game, and a pain if you have to go inside the cab and re-connect your interfaces to get them in the right order. For this reason, I highly recommend specifying different ID's when you expect your interfaces to be permanently connected.
Krick recently (??Jun05) posted the following
on BYOAC: From what I've seen, you can avoid the swapping
problem by: 1) using a
motherboard with more than 1 pair of ports, and
2) plugging devices with identical IDs into different port pairs. Each pair of USB ports on a motherboard is tied to a single USB controller that shows up in device manager. Most current motherboards have 8 ports. 2 pairs on the back panel, and two pairs accessible via motherboard headers for front panel USB or extra ports on a bracket. 4 pairs = 4 controllers.
Items should only be able to swap when they are both attached to the same controller (plugged into the same port pair). <Added by Me> - And if you need to add more ports to an older motherboard, you can buy a PCI card which would also be seen as a different USB controller.
Swappable panels or Desktop controls - Here the situation becomes more tricky. The short answer is that if you will never use two of the same interfaces simultaneously, it doesn't matter whether the Device ID's are the same or not. If you will use two (or more) panels simultaneously and you want your panels to be seen by MAME in the order that they are SUBSEQUENTLY plugged in, then you want your interfaces to have the SAME device ID's. If you want them to be seen by MAME in the order that they were INITIALLY plugged in, then you want different ID's. Now for some real world examples:
Let's say you are using an adaptoid for Nintendo64 emulation and GP-Wiz's for all your control panels. You have a Street Fighter Panel, two Battlezone Panels (for Sarge or Vindicators), and an Ikari Warriors Panel. So long as none of the panels will be used together, it won't matter whether the device ID's are the same or different. For example, you plug in the Street Fighter Panel, the adaptoid, and the Battlezone Panel. Then you unplug all the panels and plug in the Battlezone Panel alone. If the GP-Wiz's have the same ID's, the Battlezone panel will be seen as Gamepad 1 to Windows, and by MAME as Joy1. If the GP-Wiz's have different ID's, the Battlezone panel will be seen as Gamepad 3 to Windows, but since MAME doesn't find the SF panel, it will still appear to MAME as Joy1.
Now let's suppose that for four player games, you use the Street Player panel as Joy1 for Players 1 and 2, and the Ikari Panel as Joy2 for Players 3 and 4. You have not previously installed any panels and you plug in the Street Fighter Panel, the adaptoid, and the Ikari Panel. Then you unplug all the panels and plug in the two MAME Panels. If the panels have the same ID's, Windows will assign the first panel plugged in as Gamepad 1 and the second as Gamepad 3, and MAME will read them as Joy1 and Joy2. If the panels have different ID's, Windows will assign the Ikari Panel as Gamepad 3 and the SF Panel as Gamepad 1, and MAME will see the SF Panel as Joy1 and the Ikari Panel as Joy2, REGARDLESS of the order they are plugged in.
Unfortunately, I'm not sure how much this clarifies anything, but if you re-read it a few times, hopefully it will be helpful to you.
I don't have detailed info on this and am mainly listing this as an option. First there are two popular ways to do this. One involves hacking a PC USB gamepad. The second is to hack a PlayStation Gamepad. For the Playstation mod, the Sony DualShock is recommended in this thread (also mirrored here as of 07-25-03 in case the link fails). This option is popular because you can then use these adapters to convert the pad and use your controller with any other console system or with the PC. Also PlayStation pads are usually common ground which makes wiring/soldering easier. Here is a list of considerations:
- Pro - Portable so you can have one in each panel and have a standalone panel that can plug into any computer and be ready to play.
- Pro - Designed to work together, so multiple gamepad hacks can be used at the same time.
- Pro - Hot Swappable.
- Pro - Playstation hacks can work with any console system with the correct converters.
- Mixed - Cost might be less than an encoder for a single-player panel, but will likely be higher if using multiple panels.
- Con - General limit of 14 inputs means they are only useful for single panel control panels or multiple pad hacks are required.
- Con - Windows/MAME sometimes forgets what order the pads should be in/swaps them around. This can happen whether the pads are constantly plugged in or not. I think the problem is less likely to occur if all the pads are the same model, or if none of them are the same model, but neither solution is extremely practical.
- Con - As a hack, they tend to be less well made, and less durable than a keyboard encoder.
- Con - Can't be reprogrammed.
- Con - If one breaks, it is unlikely that the same model will be available.
- Con - Lots of soldering required.
- Con - Drivers are inconsistent. This is not a problem for a newer MAME build with controller.ini files, because J1_Button_1 is the same on all pads. It can be a problem with older MAME's or other emulators, because Button 1 on Pad A may be J1_Button0 on Pad B it may be J1_button0 and on Pad C it may be J1_B0, so if you don't plug them in in the right order, MAME won't recognize them.
- Con - Mame only checks for gamepad installation at game start. So if I have multiple panels with a central encoder and DB25 ports, and I start a game of Twin Cobra, a second player can jump in. If I have multiple USB gamepads and they aren't all connected at startup, I have to exit MAME and plug in the second pad before MAME will recognize it.
One of the advantages of gamepad hacks are that certain PC games such as Electronic Arts Virtua Tennis only allow the keyboard to be used for Player 1. Other players are expected to use gamepads. A solution has recently been found for keyboard emulators by using a program known as PPJoy. This program normally sends the parallel port inputs to the Joystick outputs, so that a game thinks it is seeing multiple joysticks. Deon has modified the program to work with keyboard encoders. Allroy1975 from BYOAC has details of the problems and the eventual solution here. (Local mirror here in case the thread disappears). Kudos to Deon and Allroy1975 and others for their efforts in making this happen.
General Information: The first thing to look at are the types of devices which would typically require an Analog Controller Interface. Analog controllers use potentiometers (pots), a type of variable resistor, to sense how far a control is depressed. In order of popularity and number of games that used these IMHO, the main types of controls are: 270o Steering Wheels (OutRun, driving games), Gas/Brake Pedals (OutRun, Hard Drivin', SF Rush, Cruisin' USA), Clutch Pedals (SF Rush, Hard Drivin'), Star Wars Yokes (Star Wars, ESB, Return of the Jedi, Hydra, Stun Runner, etc.), Handlebars (Paperboy, Hang-on, etc.) Analog Joysticks (Afterburner, etc.), Analog Throttles (Afterburner, Lunar Lander), Positional Guns (T2, etc.), Baseball/Football controllers (1/2-turn spring-loaded right angle batting/kicking joysticks), and Paddle Controllers (Pong, Warlords, (although these could be played fairly well with an optical spinner)).
Note that under Windows '98 you must connect at least one button to each joystick interface in order to calibrate it (not required for XP).
Special Information on Gas/Brake Pedal Controllers: Gas and Brake Pedals deserve special consideration. First - many real arcade games only used a switch for the brake and/or for the gas. This means the brake was either on or off, never 1/2-way depressed. However, you can safely wire a pot-based control to these inputs, because most emulator's Analog-to-Digital conversion will read the pot value and convert it to button depressed or released. Second, there are two modes that these devices can be used in - Single-Axis and Dual-Axis. Oddly, I believe almost all arcade games and most high-end PC racing games (Need-for-speed, etc.) will expect dual-axis for proper Heel-and-toe driving feel, but most PC pedal sets that I have owned are set-up as single-axis by default, if they even have a way to use them as dual-axis. But now for some definitions.
- Single-axis - Both the gas and brake control the same axis. Pressing the brake pedal is functionally the same as releasing the gas pedal. On the windows calibration screen the cursor will be in the center if neither pedal is depressed, at the top if the gas is depressed, at the bottom if the brake is depressed, and in the center again if both are depressed.
- Dual-axis - The gas and brake pedal are on separate axes. It is possible to apply the brakes while still maintaining or increasing the throttle. On the windows calibration screen the cursor will be in the bottom left if neither pedal is depressed, at the top left if the gas is depressed, at the bottom right if the brake is depressed, and in top right if both are depressed. I think this is what MAME requires for most games.
UPDATE: It looks like most MAME games should support dual-axis, but there may be some early or incorrect ones that require single-axis. According to a recent (~15Jun05) post by u_rebelscum: Any game in MAME can use a single-axis setup. But for those games that expect separate axes, if you use a single, you'll miss some of the game play as mentioned above. As for if a game needs single axis, that depends on how the game is emulated. If the game driver has "Pedal 1" & "Pedal 2" listed in the inputs, you can use separate, whether or not the original game did. However, if the game driver uses "Stick Y" for both gas & brake, you need single axis. I don't know if any are stick Y, OTTOMH. And the listinfo/listxml isn't detailed enough to easily search for them. FYI, when I first got into MAME (~0.36b14), most drivers used Stick Y. Since then, slowly many have moved over to pedal 1 & 2. However, if MAME really wants to document properly, if the original game used a single axis, MAME should too, IMO, even with the can't-use-separate-axes problem it would cause. OTOH, inputs is one of the few areas MAME is "loose" (and in some cases has to be if people want to play them). [shrug]
circuit is detailed at BYO
Wheel and Pedals (local
mirror) for controlling pedals in either mode
using a single DPDT switch and wiring to the PC gameport.
This is a simple control
method, but requires re-calibration when switching between
modes. The method is easy
to wire, but cannot be easily adapted to the USB controllers b/c the
gameport uses two
wires to each potentiometer, while the USB interfaces require three.
posted a way to do this on the AKI with an eight-way
8PDT switch on his wiring page
Andy Warne posted
on BYOAC that
a similar circuit could be used for the A-PAC. Andy also
mentioned a simple method
which allows the pedals to be active and calibrated in either mode, but
requires the use
of one additional axis on the A-PAC (3 axes as opposed to 2).
This method involves
wiring the gas and brake as separate axes and then connecting wires
from the J2 side of
the board to J1 for the single-axis mode. Here is a graphic showing the
connections (of course, you would wire to the outer edge of the
(Click the image to enlarge)
An advantage to this method is that re-calibration would not be required when switching modes. Furthermore, mode switching could be done simply be selecting the appropriate joystick in the emulator software, with no intervention required by the user. I believe this method could also be adapted to DaveB's circuit by wiring the joysticks in dual-axis mode to J1 X and Y and in single-axis mode to J1 Z, using the proper resistors as shown on his wiring page (local mirror). The simplified method would not be available with a Dual Strike hack as you only have two axes available. However, it is possible (UncleT from BYOAC has done it) to connect one set of pedals in dual-axis to one Dual Strike hack and a second set in single-axis to a second Dual Strike hack and have them both available and active simultaneously.
Controller Options: In order of cost, the available options are:
- Pre-configured PC controls - These are readily available for Steering Wheels and Joysticks (and to some extent pedals). This is definitely the cheapest option, and not a bad option as far as playability. And yes, you can play Star Wars on a PC joystick. However, if you would consider this option, then the BYOAC hobby bug hasn't fully bitten you yet.
- The next least expensive option is hacking the controls to the gameport. This is a simple option, but I personally don't recommend it b/c 1) gameports are rapidly disappearing from new motherboards. 2) Gameport devices typically must be uninstalled and re-installed in device manager when swapped. At the very least, they would need re-calibration. 3) Gameports are notorious for losing their calibration settings.
- A third option is hacking the controls to the gameport and then using a gameport-to-USB adapter to plug the controls into the computer. Basically, this takes care of all of the problems above, except that different devices would still require re-calibration when re-connected, unlike dedicated USB controls which typically retain their calibration settings.
- The next option would be hacking a Microsoft Sidewinder Dual Strike Gamepad as mentioned in the comparison chart. This can be a very reasonably priced option; however, the gamepad is out-of-production and a fair amount of soldering ability is involved in the hack.
- Finally, you can buy a dedicated interface such as the AKI or A-PAC. This is the easiest method next to buying pre-configured PC controls, but it suffers a triple whammy in the price department. First, these controls cost almost three times what a single Sidewinder hack would typically cost. That can possibly be justified by the convenience and extra axes supported, but you typically won't want your analog joystick and your steering wheel and race pedals connected at the same time. Configuring the interfaces for swappable controls is a lot harder than configuring an encoder for swappable panels, and even if you figured it out, you would still have to re-calibrate your controls each time you connected them, which you would not have to do if you had a separate interface for each set of controls that you planned to use at the same time. Having a separate interface for each group of controls that you planned to use at the same time is the best solution, but this easily doubles or triples the cost of an expensive option to begin with. (Sorry that sounded like a Just Brakes™ commercial).
49-Way Joysticks have been around for a long time. Basically, the sticks use optical sensors instead of micro or leaf switchs with 7 positions per axis for a crude analog joystick. However, the sticks had very limited arcade usage (Sinistar, Blaster, Arch Rivals, Blitz, Pigskin 621 A.D.) and no way to interface with the PC (other than building your own conversion circuit to the gameport using plans on the Internet), and were fairly expensive (about $35 each) so saw very little usage. (Food Fight used a Hall-Effect stick but can be played with a 49-way joystick.)
That changed a little bit when DaveB introduced the SJC interface, but it really took off when GroovyGameGear introduced the GP-Wiz49 interface. The GP-Wiz49 has settings in hardware (software controllable) which allow the stick to accurately function as a true 49-way joystick (seen as an analog joystick to the computer), an exponential 49-way joystick, an 8-way digital joystick, a 4-way digital joystick, a rotated 4-way joystick (Q-bert), a 2-way horizontal joystick, a 2-way vertical joystick, or a 16-way joystick!
The software switching is new - and will take a while to get set-up and the bugs worked out, but I'm really excited about it.
Two points - there are a lot of times that I know what mode a game uses (Tiger-Heli is 8-way), but I was just playing PacMan and forget to change the Prodigy lever over until I notice the stick not playing well. That can't happen with software switching. Also, sometimes I will just let the frontend pick a random game that I have rarely played. I could scroll over in my FE and see that it is 4-way and set the Prodigy to the correct mode and play, but with software switching, I just start the game and a little icon pops up to tell me I am in 4-way mode and the stick is already set. Sweet!!!
But, that is only half of the story. The other half is the stick itself. The stick has a moderate to long throw (similar to a Happ Super) unlike the short throw of most restricted 4-way sticks, yet still performs well in 4-way games. It uses optical sensors so it avoids the clicky microswitches that most modern joysticks use. And it uses a rubber centering grommet rather than springs, giving it a similar feel to the highly-regarded Wico leaf switch joysticks which are no-longer produced.
There are even four current modifications in work for the joysticks. 1Up is selling a conversion for a Tron-style trigger-handle version of the stick. 1Up is working on Sinistar spiders for the Happ version of the stick and GroovyGameGear is selling reproduction spiders for the Williams sticks. And Floyd is selling a conversion to allow the stick to function as a Happ mechanical rotary joystick. Finally, GroovyGameGear is now selling ball-top handles for the sticks.
If we could combine all three of these, we just might have the ultimate all-purpose stick! And by itself, it is the closest thing to an all-purpose stick you can currently buy.
NOTE: A template for mounting the joystick (developed by Markrvp from BYOAC) is available here (local mirrors here, here, and here). And information on mounting it is here. The normal mounting method is horizontal (long side) with the connector on the left (viewed from above), but it is also possible to remove the PCB and rotate it so the stick can be mounted vertically (with the connector still on the left), or rotate it so the connector is on the right and re-map the axes in MAME.
Basically, these devices are what started this page, and they are still the most versatile in terms of number of games that they will allow you to play. They are the physical equivalent of a keyboard hack, but the better ones will allow you to program them to send alternate codesets (from software, possibly without intervention) as well as supporting shift functions and many other advanced features.
General Information - IMS, as opposed to analog devices, there are only four classes of optical devices for arcade games: Trackballs, Spinners, 360o Steering Wheels, and Optical Rotary Joysticks (Caliber .50, Alternative for IKARI Warriors). OTOH, these were used in many of the most popular games - Centipede, Millipede, Golden Tee, Bowling, Missile Command, Tempest, etc. According to OSCAR from BYOAC, when purchasing devices, Active HI is preferable to Active LO, given a choice. (But I "think" either one can be converted through the use of appropriate resistors).
The devices are interfaced as mice or mouse axes to the computer.
Analog Settings: It may be necessary to adjust the analog controls settings in MAME (especially Speed and Sensitivity) to achieve the proper rotation speed and distance per turn. Larry Smith posted the following info on BYOAC for Tempest calibration: "Here is the answer I got from someone with an actual tempest. Three turns of the spinner equals one spin of the shooter on the first tube. Thanks to Jim Tippins for the info."
OS/Emulator Considerations: This only matters if you are using two trackballs or spinners TOGETHER for multiple player games (CABAL, Marble Madness, etc.) (I.e. you can have a spinner and a trackball hooked up at the same time and play Centipede just fine regardless of OS. However, by default Windows and MAME lump all "mice" together as SYSMOUSE and use that so any connected mouse will control the cursor). Also, I am not familiar with Linux or MacOS. Win2K does not support this very well at all. I believe Windows ME would work the same way as 98SE, but 98SE is preferred. So I am only going to cover DOS, 98SE, and Windows XP. Note that you can (and probably should) run one version of MAME for your main build and only use the appropriate version of MAME Analog Plus for those games that require it.
DOS: It's been a while since I've played with DOS. USB is not supported, so you have to use either two serial or a combination of serial and PS/2 devices. Both mice must use different drivers. I'm not sure if a custom version is required.
Update - USB Support: Wakerlet from BYOAC recently posted that he has successfully used a standard USB-to-PS/2 mouse adapter with OSCAR's USB Mouse Interface. Also, Tristan from BYOAC posted that he had used the UHCI driver from here with good success, but can't vouch for the OHCI one. (Local mirrors here and here).
Windows98SE: Only multiple USB mice are supported (not serial or PS/2). Official MAME supports multiple mice starting with version 0.84u5 (currently (12Jul05) at version 0.98). MAME Analog Plus can be used from versions 0.55 through version 0.83.2, however mouse settings are not saved on versions 0.76.1 through 0.83 (fixed with version 0.83.2).
Windows XP: Multiple mice may be any flavor - USB, serial, PS/2, or a mixture. Your choice of Emulators is severely limited. AdvanceMAME 0.96 (and up?) supports multiple mice. MAME Analog Plus does starting with version 0.74xp.1, however the only versions that support multiple mice and mouse settings saving are 0.74xp.1, 0.74.2, and 0.83.2. (Note that 0.83.2 works with either XP or 9x, so a separate XP version is not required).
Device ID's: Basically, the same information as I posted above under USB Device ID's applies to USB mice. In this case, the issue is mice using the same driver may swap identities (positions) if connected to the same USB controller and left connected when the machine is rebooted. The best solution is to plug them into separate USB controller ports. If necessary you can add PCI cards containing additional ports. Note that a typical 5-port USB PCI expansion card only adds one USB controller, so two individual 2-port cards would be preferable for these purposes.
One saving grace to this is that an arcade PC is unlikely to be interfacing with USB printers, scanners, and cameras, so should have lots of USB ports available, and a desktop PC is likely to plug and unplug controllers, avoiding the problem.
"Dirty" Little Swappable Interfaces Trick: This is a problem that I ran into with MAME Analog Plus 0.74.2, but it might still apply. The problem will only occur with swappable modular controls. Let's say you have two USB trackball modules. You plug them in, start CABAL and set Player 1 to use Mouse 1 and Player 2 to use Mouse 2. Then you plug in the first trackball only and play a single player game. Now when you plug in both trackballs, Player 2 is no longer controlled by the second trackball. Here's the problem: When you start the single player game, MAME scans the ports, doesn't find a second mouse, and sets the Player 2 controls to N/A. Here's the solution: Plug in both trackballs. Start CABAL and configure. Exit CABAL and find the cabal.ana file in your MAME/cfg folder. Right-click Properties and change the file protections to "Read-Only". (For later versions, it might be the ctrlr/gamename.cfg file or some other that needs to be set as "Read-Only". (Thanks again to u_rebelscum for the tip!)
Controller Options: This will attempt to answer the familiar BYOAC question "Should I go with individual OSCAR USB Mouse Interfaces or get an Ultimarc Opti-Pac?" First off let's look at your available options:
- Dedicated Controls (including Happ Trackball Interface) - Many devices such as the Betson trackballs, and the SlikStik Tornado spinner come with a USB or PS/2 interface built-in and ready to use. Unlike the analog controls above, these are actual arcade-quality hardware. Another example in this category would be PC Trackballs. For purposes of this example, these devices will be considered the same as the OSCAR USB Mouse Interface. Note that if your device has a dedicated interface and you wanted to use it with an OSCAR USB Mouse Interface or an Opti-Pac, I think you could swap out the interface boards for replacements from either OSCAR or Happ and "convert" it.
- DIY Hack - This won't generally save you much money over the OSCAR USB Mouse Interface and should only be considered if a) you really want a mouse that uses a different driver b/c you don't have any more free USB controller ports available, or b) you have an extra mouse around and just enjoy the challenge of building items yourself.
- Oscar USB Mouse Interface - This will be discussed below.
- Mini-Pac - The Mini-Pac is basically one "side/half" of an Opti-Pac welded to an I-PAC/2. It will make sense in most cases if an Opti-Pac makes sense.
- Opti-Pac - This will be discussed below.
- Hagstrom KE-USB36 - This is basically a mouse hack with a keyboard encoder included. For purposes of discussion, we will consider it a very expensive OSCAR USB Mouse Interface.
- Hagstrom KE-72T - This is basically a mouse hack with a more expensive keyboard encoder included. For purposes of discussion, we will consider it a very, very expensive OSCAR USB Mouse Interface (even though it's PS/2).
NOTE: For discussion purposes below, I am going to assume everything is hard-connected. I.e., I will not cover plugging EITHER a steering wheel or a trackball or a spinner to the input side of an OSCAR USB Mouse Interface or Opti-Pac and swapping them using DB connector or CAT5 cables. This could certainly be done, but it complicates the logic and would provide similar cost savings to either device, so just keep it in mind when evaluating the options below.
So now that we are down to an OSCAR USB Mouse Interface (includes dedicated controls, DIY Hacks, and Hagstrom encoders) and Opti-Pac (includes Mini-Pac), here are the significant questions.
- How much of a factor is cost? The OSCAR USB Mouse Interface will cost less than the Opti-Pac, depending on number of interfaces, at worst case breaking even. For example, you could connect a single trackball and a single spinner to a single OSCAR USB Mouse Interface with one interface and a DPDT switch for about $12 (total including the switch and the interface). In the worst case of dual trackballs and four spinners, the (4) OSCAR USB Mouse Interfaces (two spinner per interface) would cost about the same as an Opti-Pac.
- How many devices do you plan to connect? Related to above, if you only want a single trackball, the Opti-Pac is overkill, as you add more devices, the balance shifts toward its favor.
- Do you plan to have swappable control modules, or will all devices be connected all the time? For swappable modules, multiple OSCAR USB Mouse Interfaces are almost always preferable. For always connected devices, the Opti-Pac provides a central connection point and has the auto mode-switching feature.
- Are multiple cords a problem? Assuming you are using swappable control panels on an arcade cab, the opti-pac uses a single USB connection whereas the OSCAR USB Mouse Interfaces will require one cable per "mouse" (or a USB hub).
- Is devices swapping positions a valid concern for you? Again, this is only a problem if the devices are always plugged in, and not a problem if the devices are on separate USB controllers. But if you have an older system and don't want to add a PCI USB expansion card, the Opti-Pac avoids this problem.
- Would it bother you to have a switch on your panel to select between the trackball and spinner? As mentioned above, this is an option with a single OSCAR USB Mouse Interface. Personally, I would find it a little unauthentic, but it works.
- If all devices will be connected, will it bother you if the both devices control the cursor in single-player games? This is where the automatic mode switching of the Opti-Pac comes in. The interface will disable the rotary inputs for the same player while the trackball is being used, and vice versa. If you wanted to save some money - I think you could use standard MAME under 98SE or MAME Analog Plus (or AdvanceMAME 0.96) under XP and map each game to use either Mouse 1 or Mouse 2 rather than the SYSMOUSE so both devices wouldn't be active, but this requires a lot of reconfiguration and will only work in MAME. NOTE: Minwah from BYOAC said he found the delay in automatic mode switching with the Opti-Pac to be annoying, but many BYOAC'ers also think it is great.
So in summary, the OSCAR USB Mouse Interfaces are better for swappable controllers and are cheaper for a Frankenpanel™, but the Opti-Pac is more convenient to set up if all devices will be permanently connected, and may make sense to purchase because of that.
Three joysticks, three interface methods - Coincidence? Absolutely.
Much of this information came from this thread on BYOAC. If anyone could "fill in some of the blanks", it would be appreciated. For those who want to do their own evaluations, the most useful test would be to rapidly and then slowly rotate the joystick 180o and see if the screen character repeatedly rotates the correct amount. NOTE: At least for IKARI - six clicks or 180o on the joystick should be 270o on-screen, e.g. the character should go from Up to Left.
General Information: This section details the interface options available for connecting mechanical rotary joysticks to the computer. Mechanical rotary joysticks consist of a standard joystick with a 12-position rotary switch attached to the bottom of the shaft. Spinning the joystick handle caused the player on the screen to rotate 45 degrees (in most games) per click of the joystick. The joysticks were only used in a few games (Ikari Warriors and it's sequels and Heavy Barrel being the most popular) but the games were almost impossible to play authentically without them.
Oddly (it seems like more) there were only 14 games that actually used these sticks - Bermuda Triangle, Downtown, Gondomania, Guerrilla War, Heavy Barrel, Ikari Warriors, Ikari III - The Rescue, Midnight Resistance, SAR - Search and Rescue, Time Soldiers, TNK III, Touchdown Fever, and Victory Road.
There are also some games that did not use these sticks, but could be played using them (at least with Druin's or Rdaggers's interfaces). Caliber .50 used an optical rotary joystick known as a Loop-24. Xybots used a joystick that would close a microswitch when twisted 45 degrees left or right. TopGunner had a bootleg version that allowed a rotary joystick to control the machine gunner. And to some extent even spinner games or Pong could be played with this type of stick.
The movement portion of the sticks (Up, Down, Right, Left) are interfaced identically to their standard counterparts. This section is dealing only with the rotary switch interface.
There are three variations of these sticks: Fl0yd sells an adapter to convert the Happ 49-way joystick to a rotary joystick, Happ sells a mechanical rotary joystick based on the Happ Super (Part #56-5618-00), and Video Connect (or E-bay) sell the original SNK LS-30 (yellow hex-handled) joystick. There was also a variation of the LS-30 sold by Data East which was very similar but had round rather than hex-shaped yellow handles.
There is also a similar style of joystick - The Happ Optical Rotary Joystick (Part #50-5619-00) or the SNK Loop-24 (Caliber .50) sticks which would connect to an optical interface such as a mouse hack or Opti-Pac.
There are also three ways to interface the joysticks to the PC - using Druin's (or Rdagger's) Rotary Interface, using the (discontinued) MK64, or directly using 12 encoder inputs per stick and MAME Analog Plus.
MC-Escher Source Files: Here is an explanation of these files: Source code fixes were posted by MC-Escher and are available here for MAME 0.59. (You can use the custom 0.59 build for the rotary games and the later builds for everything else). These files were added to MAME Analog Plus in 0.71.2 and improved through 0.74.1 and included in later builds.
Here's the problem: In standard MAME using the keyboard, the character will continue to rotate as long as the key is depressed. This is the best way to play with a normal keyboard. With a standard microswitch (very extreme examples), let's say I rotate the joystick VERY slowly one click. The character might rotate 180 degrees, because to MAME I have depressed the rotate key for 2 seconds. Now let's say I rotate the joystick VERY quickly six clicks. The character might only rotate 45 degrees, because, to MAME I only depressed the rotate key for 0.1 seconds.
What MC-Escher's build does is modify MAME so that if you were to press and hold the rotate key for 30 seconds (and not get killed) the character would not rotate more than one click (45 or 30 degrees, depending on the game). This should take the rotation speed out of the equation.
Here is how to set it up: If you have Druin's 12-way rotary interface, MK64 12-way rotary interface, or one similar; map the interface's left to button 4, and the interface's right to button 5 for each player. You also might want to disable the mouse and map nothing to the MAME "standard" Dial inputs for the specific games.
Based on BYOAC comments, the MC-Escher files work better with the MK64 interface, but I am unsure whether it or the standard settings work better with Druin's interface.
Analog Settings: When using any of the connection methods except direct connection in MAME Analog Plus, it may be necessary to adjust the analog controls settings in MAME (especially Speed and Sensitivity) to achieve one-rotation increment per click functionality.
Hardware Interface Options: As initially stated, there are three ways to interface the sticks in hardware:
- Using Druin's or Rdagger's interface and two encoder inputs per stick and either using standard MAME or MAME Analog Plus with the MC-Escher fixes.
- Using the (discontinued) MK64 interface and six encoder inputs per stick, and either using standard MAME or preferably using MAME Analog Plus with the MC-Escher fixes.
- Directly wiring the sticks to an encoder using 12 inputs per stick and using MAME Analog Plus Version 0.77.1 or later (or equivalent NoNameMAME version). Note that because of a problem with MAME Analog Plus, this currently (2Jun05) works on Time Soldiers, but does not work on Ikari Warriors or Victory Road. It actually works on about six games and fails on six others, but the actual games are unknown (at least to me). Note also that the GP-Wiz49 has enough inputs to make this a feasible option for a 49-way joystick using Fl0yd's rotary adapter. The other current practical options for connecting these directly (assuming two Happ or SNK joysticks are required would be):
- Using a GP-Wiz for the rotary inputs for both sticks with 8 inputs remaining, and using a different encoder for the buttons and (non-rotary) joystick movement.
- Using a GP-Wiz for both the joystick and rotary inputs for both joysticks, and a different encoder for the buttons and (non-rotary) joystick movement.
- Using two GP-Wiz's with each one controlling one joystick and the rotary functions, with 16 inputs per GP-Wiz for buttons.
- Using an I-Pac/4 with the rotary inputs using 24 inputs and 32 remaining for joysticks and buttons.
To implement the direct connection method, the following methodology is employed. Connect each switch position from the joystick to a separate encoder input. In MAME, (from u_rebelscum's ctrlr files) - Not sure about the correct numbering direction I assume as you turn the handle counter-clockwise, the button numbers increase, but it could be the other way. If someone could check this and let me know - but you would map the output of the rotary switch sequentially for Player 1 to P3 Buttons 1-10 and then P1 Buttons 9 and 10, and for Player 2 to P4 Buttons 1-10 and then 2 Buttons 9 and 10.
Recommendations: I will not consider the MK64 method since it is discontinued. It would be similar to Druin's or Rdagger's interfaces in terms of functionality. So the real choice is between the Druin's interface and a direct setup using a recent build of MAME Analog Plus and an inexpensive encoder such as the GP-Wiz Eco. In this case I highly recommend Druin's Interface. It is about the same price as a GP-Wiz Eco, but the interface will work with all true rotary joystick games, as well as pseudo-rotary joystick games such as Caliber .50 or Xybots, or even spinner games. However, if you had extra inputs available, or wanted the MOST accurate gameplay, you could wire your joysticks in parallel to BOTH Druin's Rotary Interface and a separate encoder, and use MAME Analog Plus in direct mode for the games it supports and Druin's Rotary Interface for the others.
Most people who have heard of a keyboard encoder are familiar with Direct Mode. In this mode, each button is connected between it's individual input and a common ground terminal. So what is Matrix Mode? Matrix mode is used by almost all keyboards the TOKN encoders, and as an option by the button box, Hagstrom, and KeyDog encoders. In Matrix Mode, each button is connected to one Row Terminal and one Column Terminal to define a Matrix of inputs. In fact, all the direct mode encoders use a single row, multi-column matrix in a sense. An easy way to understand this is to consider the Hagstrom LP-24 or KE-24 encoders. These encoders have 24 input terminals. The encoders can optionally be wired in a 23x1 matrix for 23 direct inputs. In this situation, they are wired and function identically to any of the direct mode encoders. They could also be wired in a 22x2 matrix for 44 inputs, a 21x3 matrix for 63 inputs, a 20x4 matrix for 80 inputs, etc., up to a 12x12 matrix for 144 inputs.
Matrix Mode Considerations - So what are the pro's and con's of matrix mode - First the advantages:
- Cost - Since a less complicated processor can be used, an encoder using Matrix mode should be cheaper to implement. For example, the same processor that handles 27 direct inputs on the button box in Direct mode handles 128 inputs in Matrix mode.
- Cabling - Another advantage is smaller cable interfaces for removable/swappable panels. For example, the LE-24 in Direct mode requires 24 wire inputs to support the 23 inputs. The same controller using a 5x5 matrix (really a 19x5 matrix with rows 6-19 unused) would support 25 inputs using only 5 wires in matrix mode. This is why matrices are often used for telecommunications and networking applications.
Now the disadvantages:
- Matrix mode is theoretically slower than direct mode, as the processor must scan each row of the entire matrix to detect keypresses. I have my doubts that this causes any noticeable effects on an arcade controller, however.
- Ghosting - Typically, matrix controls suffer from ghosting, masking, and/or blocking. See this page in the "Little known facts and Common Misconceptions" section for a detailed discussion of why this occurs. For a keyboard hack, this typically cannot be overcome, however, with an encoder, this can be avoided by adding a diode to each input, either as part of the encoder or in the wiring to your buttons.
- Device Support - As far as I know, there is no way to interface Perfect 360 Joysticks in Matrix Mode. Druin's Rotary Interface will work with it, but you have to do some extra steps to make it compatible. UPDATE: I just checked Druin's site and he no longer supports Matrix Mode, although he can design an adapter for it.
- Simplicity - Direct mode is easier to understand. There is only one wire from each button to be concerned with, as all ground wires go to the same terminal. Thus, you end up with "Button 1 is connected to Terminal 5 (labeled P1B1) which generates L Ctrl" as opposed to "Button 1 is wired to Row 2 and Column 3 which generates L Ctrl, which MAME uses for Player 1 Button 1"
- Translating Controls - I originally designed my control panels with a central encoder and multiple input ports. Thus when my joystick panel is plugged into Port 1, the Joystick Up control (Input terminal 4) generates P1UP - R. When I plug the panel into Port 2, the same input 4 terminal generates P2UP - NumPad5. The same concept could probably be used with matrix mode, but the complexity of having two wires per input, both of which need to translate, proved to be a nightmare, and I never figured out how to do it.
TECHNICAL NOTE: For simplicity, in the paragraphs above, I have referred to direct mode and matrix mode mainly as connection methods. In classical usage direct-mode refers to a direct connection between the button and an input pin on the microcontroller. Several of the encoders that I list as having direct inputs use common-ground connections, but actually use matrix or multiplex modes to read the inputs, which can slow performance.
This section will deal with how we connect multiple panels in Matrix Mode. I will provide examples for a keyboard hack (the least flexible), and the ButtonBox (the most flexible). I will assume DB25 connectors will be used between the encoder and the panel. Remember that in Matrix Mode, we are connecting between a row and column of a matrix, so these inputs need to be present, but GND inputs (as such) are not required.
KEYBOARD HACK - The typical keyboard microcontroller uses a 16x8 matrix (although some use 15 or even 14 columns) which provides 16 discrete inputs. Since the keyboard is non-programmable, we will probably want to pass the entire matrix through the connector, so we will need (16+8) or 24 pins, meaning only one pin is free, so either the LED's will have to be wired to the cabinet and not passed through the DB25, LED's will not be able to be used, or the LED's will need a separate connector.
BUTTONBOX - If we are using all 3 LED's (NumLock, CapsLock, ScrLock), we will need four pins, one for each LED and one for Pin 31 (the +5V lead). This leaves us with 21 remaining pins, so we can support a 13x8 matrix, or 104 inputs, which is basically what a standard keyboard uses anyway!
A detailed explanation of Shift Keys may be found here. I will also offer a brief overview below:
Definition: Think of a Shift Key on an encoder the same way you think of the Alt or Ctrl keys on a standard keyboard. Basically, it is a routine on certain encoders that allows one input to send one code when pressed directly, and a different code when pressed along with another key (the Shift Key). The main uses are to allow additional functions without having a bunch of buttons on your Control Panel, or to allow for additional inputs for administrative functions, without having to buy a more expensive encoder with more inputs. However, in no case should shift keys be used for other than administrative functions such as Pause, Escape, Tab, Coin Input, or Player Start keys. Generally I avoid using Shift Keys because it gets too hard to remember or explain "Okay, I want to insert a Player 2 Coin, so I press Player 1 Start and move the P1 Joystick Up (or was it Left), etc.?".
Common Misconceptions: The biggest misconception is that Shift Keys are "free" additional inputs. This misconception is more prevalent now that encoder manufacturers have introduced "Stealth" adapters, which allow you to send a shifted output with a single button press. This is usually worded like "The KeyWiz has 32 inputs, plus an additional 24 shift inputs, so I have as many inputs as an I-PAC/4 and can save a lot of money, right?" Nope, sorry. Shifted inputs should ONLY be used for ADMIN functions such as Pause and Tab, NEVER for ACTION buttons such as P1B5, or P4B2. The reason for this is that once the shift key is activated, all other keys are shifted also, so if you are using P1Start plus P1B3 to send a shifted output for P4B2, not only does P1B3 no longer work when P4B2 is pressed, but P1B2 and every other key now sends a separate function.
Keyboard Encoders: Also see the software comparison further down this page. What are the considerations? How important is this? It depends on what you plan to use the encoder for. First off, there are two levels of programmability:
Level 1 - Many of the encoders shown here have some way of loading a custom codeset; however, in some instances, this involves loading reprogramming software and cannot be done without manually running the encoders software.
Level 2 - The GroovyGameGear KeyWiz Line, MK64 (discontinued), and Ultimarc I-PAC line of encoders (and some others) all have a way of quickly loading an alternate codeset through either software (batch files) or a key combination "on-the-fly" so to speak.
For MAME, as long as I have used it (R31 or so) MAME has allowed re-assignment of keys. From R36B13 on, MAME has allowed and/or/not key combinations, and from 0.60 on, MAME has allowed you to set the key assignments of multiple games without even opening the emulator using ctrlr.ini (or ctrlr.cfg) files, so for MAME, this is fairly unimportant.
So let's take the worst case - assume I have a non-programmable encoder (read keyboard hack, or gutted HotRod, or Hagstrom KE-18), and I use an (probably older, DOS-based) emulator that doesn't allow key changes (P1Button1 is "A" and only "A"). What this means, is that you must carefully choose your key assignments and button placement to match with your encoder. In a worst case, the encoder may not be able to produce the key I need and I would not be able to use this emulator at all. This would be a rare occurrence, however. In my personal usage, I rarely use emulators other than MAME, and I don't typically use the default codeset, but I also rarely change codesets or re-program my encoder.
Here is a simplified explanation that I posted on BYOAC recently which may make this easier to understand:
If you just use your encoder for MAME, you don't really need a custom codeset or a programmable encoder. Whatever your encoder comes with, you can set MAME to match it.
Where it comes in, is if you want to Play PC game A and Button 1 is set as "G" and can't be changed and then you want to Play PC game B and Button 1 is set as "F" and can't be changed. With a non-programmable encoder, you are out of luck unless you wire Button 1 to a different input before you play each game. With a programmable encoder, you create a .cfg file for each game, write a batch file to load this and start the game, and you're set to play.
Gamepad Encoders: None of the gamepad encoders currently (21Jul05) offer any kind of native reprogramming software. While in theory there could be times that you would rather have the lower left button be "Button 3" rather than "Button 1", this is much less of a big deal than it is for a keyboard encoder for the following reasons:
- Very few software programs only accept gamepad inputs and are non-configurable. Most PC games only accept keyboard inputs, and about half (of arcade game software) accept keyboard and gamepad inputs.
- For the programs that accept keyboard inputs, it is possible to use one of the programs listed in the Gamepad Encoder Useful Software section to send keyboard outputs from you gamepad encoder.
SDRAM Vs. EEPROM - This section only applies to keyboard encoders. Most of the I-PAC series, the TOKN encoders, and the MK series encoders use a programmable EEPROM, while the KeyWiz series and the I-PAC VE use SDRAM. I am not sure about the other encoders. Which is better? The short answer is "It really doesn't matter, but you should be aware of the differences before you make a selection." Here is the detailed explanation of the differences:
- Longevity - SDRAM is supposed to be infinitely re-writable, while an EEPROM has a fixed number of re-write cycles before it stops working. Having said that, the number of cycles is usually quoted at either one million or 100,000, but these are averages. Let's put this in perspective. Let's take the unlikely situation that you have five different emulators that you play, and each requires a different codeset. You program your encoder to load the custom codeset for each emulator, and then load the standard codeset back after you are done. And you play one game from each emulator each day, so your EEPROM is reprogrammed 10 times a day. Using the more conservative 100,000 times number, your EEPROM will die in 27.4 YEARS!!!. (Using the less conservative number: 274 years!). In reality, the EEPROM in your encoder will probably be working longer than you will!
- Permanence - With an EEPROM, you are burning a custom codeset into the chip, and the chip will retain this information until it is programmed again. With SDRAM, a default codeset is permanently loaded and an alternate one can be loaded but will be lost on power off. The SDRAM method is useful if you usually use the default codeset and do not change codesets often. The practical implications of this are as follows: With an EEPROM, if you load a custom codeset for a different emulator, you probably want to reload the normal codeset on exit, otherwise the EEPROM will remember the alternate codeset. With SDRAM, this is not necessary, however, if you want to semi-permanently use a different codeset, you must load it from a batchfile when the system is first powered on. Either one can be used effectively with a minimum of effort. NOTE: The KeyWiz software can be loaded with a /a (Auto) option which loads the last used codeset, creating a "virtual EEPROM". To enable this, the default command would be: "c:\keywiz\keywiz_uploader.exe /A" (without quotes). This should be placed into a shortcut's command line argument and then dropped into the startup folder.
- Hot-Swapping - EEPROM has a definite advantage here. EEPROM will retain it's settings on power down, so if you use a custom codeset, it is pre-loaded. SDRAM will work for this application, as long as you use the default codeset, but unlike having the software change codesets on power-up, there is no way for the software to load a different codeset when the encoder is plugged in with the computer already on. However, the KeyWiz encoders fare slightly better than the I-PAC VE in this respect, because the KeyWiz default codeset is more suitable for MAME use without customizing MAME and the I-PAC VE default codeset includes one duplicate input, so only 31 inputs are useable without re-programming.
- Speed - Loading a custom codeset into SDRAM should be faster than programming an EEPROM, but specific software, Operating System version, and the like may have a greater effect than the type of interface itself. Generally, changing encoder codesets happens so infrequently that this will not be a major concern.
- Special Requirements -
Grasshopper posted something on BYOAC that I had not considered, but
which makes EEPROM preferable for his situation: "I'm using
my I-PAC with a converter that enables a PC keyboard to be used in
place of a Dreamcast controller. The converter cannot be reprogrammed,
and requires a particular key set which is not the same as the I-PAC's
default. So for me the ability to keep settings on power off is
OTOH, to some extent even this can be worked around (a quote I made on BYOAC): Having said that, I believe you could do what you want with the KeyWiz encoder thanks to a number of intelligent design decisions. This solution is not as elegant as an I-PAC, but I think it should work. Consider the following: Both the default codeset and the alternate default codeset are always available with the KeyWiz, and shifted keys are also programmed and loaded for both sets. Also, the alternate set basically covers all of the main keyboard keys. So it should be possible to hook your Dreamcast device up to the alternate codeset terminals of the KeyWiz and then press a button connected to the Shazaaam! and J1L terminals (with diodes) to load the alternate set. (If you wanted to get really fancy, I'm sure you could devise some kind of relay to do this automagically.). You might need some combination of shifted and non-shifted inputs, but the KeyWiz can handle this as well thanks to RandyT's stealth shifting adapters.
NOTE: The following discussion applies to keyboard encoders only. Basically all the gamepad, 49-way, and analog encoders use USB, and I have never heard of a performance advantage either way for optical interfaces.
The debate over USB vs. PS/2 is often fairly heated and controversial. The performance issues involved are well beyond my level to decipher and well beyond the scope of this page to convey. Here are a few initial comments on performance:
Statements on both the MK64 (discontinued) and KeyWiz sites all agree that USB keyboard technology probably should be avoided due to possible performance issues and limitations in simultaneous keypresses.
Andy Warne (I-PAC) feels that USB technology offers a performance advantage, especially for fighting games where simultaneous keypresses are required, and especially under Windows 2000 or XP.
Those wanting to decipher the more technical issues of the controversy can go here for Andy Warne (Ultimarc)'s comments favoring USB, and here for RandyT (KeyWiz)'s (edited to limit to this topic) comments favoring PS/2.
The short answer is: My personal opinion is that I would prefer PS/2 mode, but I don't think the performance issues are enough to keep me from using USB mode, if USB was more convenient for me. There are basically two reasons that I feel PS/2 mode is generally a better choice:
- The USB keyboard specification places a report structure limit of six simultaneous keypresses, plus modifiers such as Shift, Ctrl, and Alt. This is fine for typing, but bad for arcade games. A well-designed USB encoder can get around this limitation by specifying a different report structure during device enumeration (or possibly other workarounds), but you are still imposing a workaround that is not required for PS/2 mode.
- If we are using a keyboard encoder, we are using applications that are expecting input from the keyboard port. While a USB keyboard will work for these applications, USB is also used for printers, digital cameras, scanners, gamepads, CD-ROM drives, floppy drives etc. It is up to the operating system to determine what the device is and what priority to give it. It is then up to the operating system to convert the data to the proper format and pass this data to the application. PS/2 devices are either a mouse or a keyboard, period, and the information goes directly into the BIOS to send to the operating system, so one level of software intervention is avoided.
Aside from performance issues, here are some other things to consider:
If you are running a DOS based machine, you shouldn't even consider using USB. The BIOS resident USB support is only for very basic compatibility. Obviously, the same applies to Windows 3.1 or early releases of Windows 95. And Windows NT doesn't support USB at all.
If you're using an Apple (Mac, GS whatever), USB is unfortunately your only option.
OTOH, gameports are disappearing from most new motherboards to make room for more USB ports, and since there are USB keyboards and mice already available, there is some concern that PS/2 ports will disappear as well. However, a recent bit of research into new motherboard products from reputable manufacturers turned up no instances where PS/2 ports were absent. There are still serial ports and parallel ports on MB's as well, regardless of the fact that there are tons of USB modems and printers. The gameports are kind of an "apples and oranges" comparison. The original game port was designed to handle 2 analog sticks, each having 2 buttons. This has been grossly inadequate for a number of years, requiring programming trickery to handle most modern controllers. In this case, USB is vastly superior and results in much simpler and less expensive hardware in the controllers. In short, they really won't be missed. None of this is really the case with PS/2, as USB keyboard microcontrollers still seem to be a bit more expensive than the little blob of silicon in a PS/2 keyboard. I don't consider lack of USB support a serious enough concern to base a decision upon, but USB support does buy you some "future-proofing" if you are concerned about such things.
USB officially supports hot-swapping of controls, but this isn't a major concern for the following reasons: If you are building an arcade cabinet without swappable control panels, you won't be unplugging your encoder very often anyway. Even if you use swappable control panels, unless you use a separate encoder on each panel ($$$$), you will be unplugging from the input side of the encoder and hot-swapping works fine here. The same logic applies to multiple desktop control panels, typically you will mount your encoder in a project box and hot-swap panels from the input side. About the only time hot-swapping really provides an advantage is for a single desktop controller like the HotRod, X-Arcade, OzStick, etc. Even in this case, you can hot-swap PS/2 keyboard encoders, I have done it hundreds of times, it works (but don't blame me if you fry your motherboard). OTOH, people are used to front panel USB ports and hot-swapping other USB devices, and they are not used to hot-swapping PS/2 devices, so in this respect, USB makes sense if you will be installing and removing your controller often.
Related to the above is the fact that with a USB encoder, you can leave your keyboard plugged into the PS/2 port and not have it running through your encoder. Of course, you can also do the same thing with a PS/2 encoder by using a keyboard splitter or a USB or wireless keyboard (as mentioned in the keyboard pass-through alternatives section), but it is an additional item to buy, if you aren't using one already.
Update (28Oct05): Hot-swapping of PS/2 encoders works a little differently depending on whether you are using Win98 (or WinME?) or WinXP (or WinNT?, Win2K?). Under Win98, the drivers for the PS/2 keyboard are loaded at boot-up, whether or not a PS/2 keyboard (or encoder) is actually connected. Therefore, it is entirely possible to use a USB keyboard, and only connect the PS/2 encoder when required. Under WinXP, the PS/2 drivers are only loaded if a PS/2 keyboard or encoder is present at boot-up, otherwise, they are not loaded. If either a PS/2 keyboard or encoder is installed at system boot, hot-swapping between them is no problem. However, if neither one is present at boot-up, subsequently installing either one will have no effect, as it will not be detected, and even scanning for new hardware will not find it. This is only a problem for a desktop control panel, where it is likely the panel will not be installed at boot-up. And there are four possible solutions:
- If it is convenient to do so, you can just have the PS/2 Keyboard or encoder installed at boot-up and then hot-swap as needed (assuming you have access to the rear of the PC).
- You can plug in the encoder and re-boot before using the computer for gaming.
- The solution I settled on was to get a PS/2 F-F gender changer like this one. This can be plugged into the end of the PS/2 Keyboard cable. Then either the gender changer or the PS/2 encoder can be plugged into a M-M keyboard extension cable and hot-swapped at will.
- Finally, it is possible to use the PS/2 encoder with a PS/2-USB encoder, but there are likely to be performance issues associated with this, as documented here.
USB also allows multiple encoders to be connected. Computers only have one PS/2 keyboard port, so in PS/2 mode, unless you have a keyboard splitter installed, you are stuck with daisy-chaining two PS/2 encoders together to get additional inputs. And splitters are really designed for one encoder and one keyboard in an either-or situation. I am not sure how they would work in a dual encoder simultaneous scenario. OTOH, USB is designed for something like 128 (?) simultaneous device connections, so hooking up two encoders is no problem. The practical implications of this are that if you plan your panels correctly, you can use either USB or PS/2 as an interface, but if you already have a PS/2 encoder and don't have enough inputs, you will either need to daisy-chain another PS/2 encoder to your current one (if possible), get a separate USB encoder, or replace you current encoder with a USB or PS/2 encoder with more inputs.
I-PAC Specific Considerations:
NOTE: I am not sure which, if any, of the following limitations apply to the I-PAC VE.
Fact is there aren't many USB keyboard devices to choose from. The USB keyboard specification gives a limit of six simultaneous keypresses, so you should not hack a USB keyboard (does not apply to the I-PAC encoders). USB gamepad encoders and hacks are an exception, because they do not use USB keyboard technology. The Hagstrom KE-USB36 might work acceptably or might have the same 6-button limitation as USB keyboards. So, IMHO, one of the I-PAC's is your best keyboard encoder option if you are sure you want to use USB.
So the remaining question is: Should the I-PAC be operated in USB or PS/2 mode, since it supports both? I vote for PS/2 but here are some things to consider:
- Depending on board revision, there is a limit of 14, 22, or 16 inputs (plus modifiers such as Shift, Alt, and Ctrl) that the I-PAC supports in USB mode, unlimited in PS/2. While this isn't a very practical limitation (4 players each simultaneously pressing diagonals and pressing Buttons 1 and 2 simultaneously exceeds it, but not much else), it is a limitation which is not present in PS/2 mode.
- I have heard many reports of erratic behavior with the I-PAC in USB mode. In Windows 98, in many cases, these were solved by disabling USB keyboard support in the BIOS or some other workarounds. In Windows 2000 or XP, the USB keyboard support in BIOS problems will not occur at all. These are minor problems (assuming removing of USB keyboard support fixes them), but considering I have heard no reports of problems in PS/2 mode . . .
- OTOH, the I-PAC supports key repeat on the 1 Up and 1 Down inputs only in PS/2 Mode. In USB mode, key repeat is supported on all inputs. Andy Warne can supply an I-PAC supporting key repeat on all keys in PS/2 mode, if requested.
PS/2 - USB converters:
Okay, if your heart is set on a PS/2 only encoder, but you want to use USB, can't you just buy one of those PS/2 to USB Keyboard converters and hook it up that way. The short answer is "Yes with some less than ideal results." I use one of these converters for my keyboard and found lots of flaws with it for typing, but surprisingly few using it with an encoder in MAME. My results are posted in this thread.
Introduction: In this section, I will look at the various methods of connecting your controls to an encoder. I would not make this the primary decision in an encoder selection. In the past, you basically chose your encoder and then worked around whatever input method it's manufacturer chose. That all changed with the introduction of GroovyGameGear's ECO line of products. Currently (10Jul05), the entire product line is available in a Solder Point version for $20, an IDE Header Version for $23, and a Screw Terminal Strip version for $35. So the question that I am now trying to answer is "Is it worth $12-15 more just (in many cases) to get Screw Terminal Strips on the encoder?"
I would also like to point out that it is possible to basically change the input method. You can run your wires from the encoder to external terminal blocks. This is generally not cost-effective compared to buying a MAX, unless you are extremely budget-conscious, but could be useful for other IDE Header encoders (Mini-PAC, TOKN, MK64).
NOTE: If you wanted to, it would also be possible to downgrade (to allow you to use a hard drive cable on each swappable panel, for instance), but this would require soldering a pin header to some perf board (breadboard, project board) and then soldering your encoder wires to the terminals on the perf board. If you didn't understand that, the project is out of you league.
Examples/Usage: In case you still have no idea what I am talking about, here are some pics (Click to enlarge). From left to right, we have the GP-Wiz Eco with solder points, the GP-Wiz Eco no-solder with an IDE Header, the GP-Wiz Max with screw terminals, and an example of an external terminal strip.
Here is how each one is used:
- Solder Points: Basically, you insert a small wire through the pre-drilled hole, touch it with the soldering iron, apply solder, and continue. I despise soldering and in this case you have the very real possibility of overheating the board and damaging the circuitry. And even BYOAC users who are good at soldering have said that the $3 increase for the IDE header was well worth it for the time involved. So I am basically going to rule out this method unless you are extremely budget-conscious and technically skilled (and you probably know if you are).
- IDE Header: This is a designed to accept a hacked ribbon cable, such as you commonly see used with a computer hard drive or floppy cable. Basically, you place the connector end of the cable on the IDE Header, and then separate and strip the ends of the wires at the button end and connect to your buttons.
- Screw Terminal Strips: You strip a portion of the insulation off you wire (or wires), insert into the screw terminal, and tighten the screw to hold the wire(s) in place.
- External Terminal Strip: (BYO Max Encoder) Basically the same as the Screw Terminal Strips above, except: There are several different types of external terminal strips. The ones I am discussing basically have two rows of screw terminals connected together and you place the wires from the encoder in one side and the wires to the buttons in the other side. There are other styles of Terminal Strips (also called Barrier Strips) which have a single row of screw terminals and you connect the encoder wire and the corresponding button input to the same terminal. It's basically just a matter of cost vs. what you want to use.
Pros/Cons: Here are what I see and the advantages and disadvantages of each option:
IDE Header Pros: Cost. Also, some users like this setup for swappable control panels, as it is easier than running from screw terminals on the encoder, to cut DB25 cables, to the buttons.
IDE Header Cons: Most IDE ribbon cables use 28-32 gauge (thin) wires. This is not a problem for signal handling, but it is difficult to crimp to, even if you fold the cable over 3 or 4 times. Also the cable is a fixed length and usually 3 feet or less, so you may end up using extender cables or junction blocks. In addition, the cable is single wire per connection, so if you want two buttons to connect to the same input, you again end up with extension or jumper blocks. And if you size the cable to fit the buttons and then decide you want to change which input is used the change must be made at the button end and the wire might not be long enough. (The last problem could possibly be alternately solved by reprogramming the encoder, or changing the key assignments in the emulator software.)
Screw Terminal Pros: Basically you can use (within reason) any size of wire, you can run multiple wires to the same input, changing inputs connections for a button is as simple as loosening the screw terminal, moving the wire, and re-tightening the screw terminal. Wires can be individually replaced or lengthened without disturbing the rest of the wiring.
Screw Terminal Cons: Basically none except greater cost compared to the IDE header.
Terminal Strip Pros: Basically you get all the advantages of the Terminal Strips for less cost. Now is a good time to look at the cost of this option. GroovyGameGear actually has a good deal on a 12-position terminal strip for $1.25. If you want to avoid shipping, Radio Shack sells a similar item (Part #274-680) for $2.59. Finally, allelectronics sells a 22-position (TER-22) PC-mount strip for $1.25 (you could modify this without mounting it to a PCB, but allelectronics inventory is subject to change), . So the best deal ends up being $2.50 to $3.75 for the external strip as opposed to $12-$15 for the hard-coded strips.
Terminal Strip Cons: While you save a little money, you don't save enough IMHO to justify it, and you have two terminals to connect per button, and your wiring doesn't look as tidy.
Choosing: At this point, I haven't told you much that was new. You probably already knew that terminal strips were easier and preferable, but cost more. So which one should you get? Basically, it comes down to these considerations:
- Tinkerer vs. Planner - If you're the type of person that gets your encoder and hooks up a single joystick in a piece of plywood to be able to play Pac-Man on it, figuring you will hook the buttons up in the real control panel later, you probably want screw terminals. If you have planned out your panel for 6-8 months, thought through all the possibilities and are just now purchasing hardware, or if you're building your third cabinet to correct lessons learned from the first two, you can probably use IDE headers. However, beware that often plans will change when you actually start USING the hardware.
- General Cost concerns - Depending on whether you are making a desktop controller or an arcade cabinet, an additional $12 is not a lot of money. I try to pinch pennies more than most in the hobby, but if that is that big a concern to you you should maybe find a different pursuit. (The problem I have is justifying an additional 50% of the cost of an Eco encoder just to add screw terminals, but that's more a problem of the Eco's being a good deal than the screw terminals being a bad deal.)
- Economies of Scale - While I just said $12 isn't much in the grand scheme of things, if you are planning on building multiple panels with several encoders or a 4-player panel with GP-Wiz49's, now the price difference is $48, which could almost buy you a spinner or trackball, so now we are starting to talk about some serious money.
Conclusions: IMHO, generally for a single KeyWiz or GP-Wiz panel, it is worth the extra money to get the screw terminals on the MAX encoder. For the GP-Wiz49, where most of the inputs are pretty defined anyway, you probably can get by with the Eco. If you are cost-conscious, the external terminal blocks are a possible solution as well. However, in the end, you have to weigh the advantages and make your own decision.
There are basically four workarounds if your encoder does not have a keyboard pass-thru:
- If you have access to the rear of the computer and rarely use the keyboard (in an arcade cab for example, where you only use the keyboard for config and software updates), you can simply unplug the encoder and plug in a keyboard when you need to. It is recommended to power-down the computer before doing this. Having said that, I have hot-swapped keyboards hundreds of times with no problems, but don't blame me if it goes wrong.
- Stephen Hans has a circuit on his site, which you can build to connect an encoder and keyboard to the keyboard port. It should be around $10-15 to build, but you have to be able to solder and have the time to put it together. PI Engineering sells a pre-made splitter called a Y-Key Key, but at $50, it costs more than many of the encoders :-o.
- Of course, if you have a USB encoder, like the KE-USB36 or the I-PAC in USB mode, you can just use a PS/2 keyboard or a second USB keyboard. If you have a PS/2 encoder (or keyboard hack), you can simply buy and use a USB keyboard with the computer. Reasonably priced (under $10) models are available here, here, here, and here.
- If your computer is inside an arcade cabinet and access is a problem, a wireless keyboard might be a good option. These are available here, starting at around $20.
As mentioned previously in the Lessons Learned section, I would never base an encoder decision solely on the presence or lack of keyboard LED support. If you are nostalgic for the blinking Start buttons, the following paragraphs will provide the information you need.
In Matrix-Mode, the LED's are NOT bi-directional, and will not conflict with any button presses. In Direct-Mode, the ButtonBox LED's are bi-directional with certain inputs as follows:
- Num Lock - Input B25
- Caps Lock - Input B26
- Scroll Lock - Input B27
This means that the corresponding LED will flash whenever these buttons are pressed. If this bothers you, the only way to work around this is to design your panels so that these inputs are not required on panels that use the LED's. However, the effect can be minimized by mapping B25 to Start1, B26 to Start2, and B27 to Pause or one of the Coin inputs. For games that use the LED's, the LED's will already be flashing, so the extra button flash may not be noticed. For other games, people who aren't familiar with the game may assume that the LED was supposed to flash once when the Start Button is pressed.
In either Matrix or Direct Mode, the LED's are wired between +5V (Terminal 31 or 32) and the corresponding LED terminal shown above. The ButtonBox supports either +5V LED's or, if you use 2.1V LED's, you must use a resistor in series with the LED to drop the voltage. I recommend E-mailing the designer for specific resistor values.
On all Ultimarc encoders with LED support, LED's are bi-directional with the following inputs:
- Num Lock - P1 Button 8 (All encoders except the I-PAC VE); P2 Button D (I-PAC VE, thanks Kobex from BYOAC)
- Caps Lock - P1 Button 7 (All encoders except the I-PAC VE); P1 Button D (I-PAC VE, thanks Kobex from BYOAC)
- Scroll Lock - P2 Button 7 (All encoders except the I-PAC VE); P1 Button A (I-PAC VE, thanks Kobex from BYOAC)
This means that the corresponding LED will flash whenever these buttons are pressed. NOTE: The LED will flash when these buttons are pressed, whether the LED's are wired to the Button Terminals or to the LED header pins. If this bothers you, there are two ways to work around this: a) design your panels so that these inputs are not required on panels that use the LED's, or b) for the I-PAC/4 design, as above, I remap my panels so that the P1Button8 and P1Button7 inputs are wired to Start1 and Start2 inputs respectively and P2Button7 is wired to Pause or a higher Coin input. For games that use the LED's, the LED's will already be flashing, so the extra button flash may not be noticed. For other games, people who aren't familiar with the game may assume that the LED was supposed to flash once when the Start Button is pressed.
On the I-PAC/2 and I/PAC/4, the LED is wired between +5V and the corresponding LED terminal on the encoder (either the pin header or the terminal strip, as follows):
Here is an example showing how to hook up the Num Lock LED on the I-PAC encoders: The schematic above was taken from the Ultimarc Installation Instructions Page and shows the I-PAC LED Pin header looking from the top. The first step is to pick up +5V from the header. This can be done without soldering using a cut CD-Audio cable for the PC. This wire then goes to the longer lead on the LED. (A CD-Audio cable can be used here also to avoid soldering.) Then a wire is connected from the short lead on the LED through the 220 Ohm resistor (if using 2.1V LED's). (The resistor can be placed before or after the LED in the circuit, it works out the same.) From the resistor, the wire connects either to the appropriate terminal on the LED Pin Header, or to the screw terminal for the corresponding bi-directional input (P1Button8 or P2ButtonD for NumLock).
Grasshopper posted on BYOAC that the I-PAC/2 P1 Button 7, P1 Button 8, and P2 Button 8 inputs will eventually stop working if used for LED's and should be avoided. Also, Andy Warne posted on BYOAC that you should be careful with interference problems with long leads between the I-PAC/2 and buttons (say 6-10 feet or so) and that the cables should be grounded to the chassis. This confused me, so I did some research into it, and think I have some (unconfirmed) answers.
Dead Inputs -
Basically, I think the resistor values given
above are too low . . . The voltage alone doesn't tell the story. The
only LEDs that will
work are the very low current ones. The resistor will have to
be matched to the LED.
This is from the datasheet for the I-PAC's microcontroller:
Sink current - 7.2 min 16.5 max mA Port 3, Vout = 1.0V
This means that the max current at 1 Volt (1 V LED) should be 16 mA or less.
At 2 Volts (2 V LED) it should be 8 mA or less.
This means that in order to safely run a 2.1V LED, you would need to limit its current to around 7 mA with a 414 ohm resistor. 220 ohms would allow 13 mA to be pulled through the microcontroller, which is about twice what it is rated for. It may be okay like this for a while, but it will kill that input over time.
According to RandyT, the difference between the calculated and specified LED values may be accounted for by the fact that the LED output on a bi-directional pin would be modulated (meaning that the signal to the LED is still 5V, but it's cycling on and off very rapidly) so it may be possible to use a lower value resistor without harm. LED's are usually capable of much higher output when modulated.
A good LED choice would be this LED: http://www.fairchildsemi.com/ds/HL/HLMP-1700.pdf They are rated at 7.5ma at 1.8v....this would require a 426 ohm resistor in series with it. And, it should be absolutely safe to drive directly from the microcontroller. So again, my theory (and it's not anything more than that) is that the dead inputs are the result of incorrect LED and resistor choices.
Cross-Talk with long wires: I have several theories on this. One idea that I have seen mentioned is capacitance. Another is that pulsing the LED's can cause problems with modulating signals being picked up on adjacent wires. In any case, the key here is that it is only a problem when the LED's are active on any of these lines.
See this thread (local copy as of 25Jul03 of this original, local link has pictures) for details of Hagstrom KE-72 LED connections. For wiring, the connections go - +5V from the KE-72, through the LED and a series resistor, and back to the appropriate LED Terminal. (Note that the correct current limit is 8 mA, not 1.5 mA as originally stated.
This is based on some educated guesses, but I think the KE-USB36 uses 2.1V LED's and does not require a series resistor. Also the LED's connect directly between two pins on the encoder PCB (CD-Audio cable should work), rather than going to either a +5V terminal or a GND terminal.
Unlike the other encoders, the MK64 supports 2.1V LED's (which are more common than 5V ones) and does not require a series resistor. Also, the LED's are wired from the LED terminal through the LED to GND, rather than from +5V to the LED terminal. I prefer this method, because it saves you from needing the +5V input line on swappable control panels.
- If your encoder is not programmable, then you have no option other than to use its assigned codeset.
- If your software doesn't allow re-mapping of inputs, then you are stuck with the inputs that it accepts.
- In virtually all cases with modern hardware, if your encoder is programmable and your software allows input re-mapping, the chance of your encoder and PC suffering from buffer overflow is pretty slim.
Nevertheless, regardless of what encoder you choose, or even just using the keyboard directly, there are certain keys which send extra commands to the keyboard buffer and should ideally be avoided. These are Direction Arrows (note that both HotRod and X-Arcade avoid these), Windows Menu Key, L GUI, R GUI, R Ctrl, R Alt, Insert, Home, Page Up, Delete, End, Page Down, PrntScrn, Pause, Keypad Slash, and Keypad Enter. Details of how I came up with this list are available here. Most keys send three characters to the keyboard buffer. These all send five or more.
How serious is this really? Well, I've not about to tell you that you can't map your joystick to the direction arrows and play Pac-Man in MAME R36B12 using an advanced encoder and a 3.0 Ghz processor. I will give you a (rather extreme) personal example before this was pointed out to me. I was playing Top Gunner in MAME on a Pentium 200 MMX (at about frameskip six or seven) using a gameport joystick for Player 1 and the keyboard for Player 2. I had mapped Player 2's controls to Home, End, Page Down, and Delete, and Fire to R Ctrl and Right Shift. So five of the six Player 2 inputs were non-optimum keys. When I remapped the Player 2 inputs to the number pad, I saw a dramatic improvement in the key response times.
Eliminating Start Buttons - On most games with more than 2 simultaneous players, discrete start buttons are not used. This is done because the JAMMA standard also has a limited number of inputs. The confusing thing is that the control panels often do have start buttons shown, but they are wired in parallel to the Button1 action buttons. This same method can be used (at least in MAME) to gain up to six additional inputs. Details are here.
Combining Joystick Direction Inputs - Since each Joystick cannot be both Up and Down at the same time, it is possible (if you only use MAME) to connect a button to BOTH inputs and gain another encoder input. Using this for both axes of both joysticks provides up to four additional inputs. Details are provided here.
Multiple Buttons, Multiple Inputs - You have to try this out some before it makes sense. There are many cases where you might want to hook two controls to the same input. I do this with JoyStick 4 and the P1 and P2 Buttons 5 and 6. Or in hooking a 4-way and an 8-way stick to the same set of inputs. As long as both buttons will never be used in the same game, it's no problem. It's virtually NEVER a good idea to hook a single button to multiple inputs. (Say you wanted a button to act as Button 5 in Street Fighter, and as Pause in PacMan. If you wire the button to both inputs, you not only send two keypresses when the button is pressed, but any button connected to only one of the inputs will now also send both inputs. In effect you lose one encoder input. What you can do is only hook the button to one input, but have it perform different functions in different games, either by changing the game inputs, or by reprogramming the encoder.)
The Case For More Inputs - If you remember back to the In Perspective section, I said we could play 99% of MAME games with 32 inputs and the most complex (6-player, 3-button) game requires 48 inputs. Then in the next paragraph, I said that 68 was the ideal number of inputs for supporting all games. Why the disconnect, and why the extra 20 inputs? Well the 48 input number does not include the 6 Player Start inputs. (We don't need them for MAME as mentioned here, but we might for other programs, so let's add them in). Now we're at 54 inputs. We probably want Pause and Escape inputs, so now we're at 56 inputs, which is what the I-PAC/4 provides. So are you throwing your money away on a MK64 (discontinued) encoder (ignoring that the MK64 costs less than the I-PAC/4)? Not necessarily. Consider the following: The I-PAC/4 above supports enough inputs for 6-player 3-button games, but all inputs are used. This means that Player 1 buttons 4 through 8 and Player 2 buttons 4 through 8 are used for some of the higher numbered player inputs. But you probably have these buttons available on your panel for Street Fighter type games, etc. So Player 1 or Player 2 can mess with the other player by pressing the 4 through 6 buttons and making the other player shoot or move, etc. A controller with more inputs allows you to make each key a dedicated button and avoid this.
BTW, the other 12 buttons to get us from 56 to 68 are discrete buttons for Players 1 and 2, Buttons 4 through 6, Players 3 and 4, Button 4, and 4 inputs for mechanical rotary games.
The (Very Slim) Case For More Than 68 Inputs - As stated above, 68 inputs should cover anything you need for emulation. The only situations you would want more is either a) You want a lot of extra buttons for MAME admin functions such as Tab, Tilde, Enter, F12, F11, F3, F2, F8, etc., or b) You plan to use your panels for console (X-box, NES, Playstation) emulation, which often used 4 player games with 6 or more buttons each. However, in my opinion, these games were designed to be played on gamepads, and you would be better spending your money on a less expensive encoder, a USB hub, and a bunch of USB gamepads.
UPDATE: MAME Analog Plus now supports mechanical rotary joysticks directly, but this requires 16-inputs per joystick for motion and rotation and doesn't work in all rotary games. Usage in this manner is another justification for an encoder with a lot of inputs.
Multiple Devices - So far, we have only talked to single encoder devices and it would be impossible to compare all the variations with multiple devices. However, in case you already have an encoder, but need more inputs, here are some general guidelines. It is possible to daisy chain two I-PAC's (any flavor except the VE) together. I am not sure if it is possible to daisy chain more than two. If you intend to simultaneously use two I-PAC devices, you must connect and program them each separately before daisy chaining them. After connection, only the first I-PAC can be programmed through software. It is possible to use any number of I-PAC's in USB mode, or some in USB and one in PS/2, but I am not sure how programming would be affected. It should be possible to use an I-PAC in USB mode, and a KeyWiz or MK64 (Discontinued) in PS/2 mode and program either one. MK64's (discontinued) can be daisy chained. KeyWiz's should be able to be daisy chained to either MK64's or I-PAC's.
UPDATE: The recent gamepad encoders change this picture greatly. As long as your computer supports USB, you can now add as many gamepad encoders as desired, and since they are seen as gamepads, they will not conflict with your existing encoder nor with each other.
UPDATE2: Another popular trend is to use a J-PAC and daisy-chain it with either an I-PAC/2, KeyWiz, or GP-Wiz. This would be useful for individuals converting a JAMMA cabinet for 4-player emulation support.
Overloading Your Encoder - I will use the KeyWiz as an example here. This device can support 4-player 4-button games (32 inputs). However, to do this, it is required to use Shift Keys in Stealth Mode for Coin inputs, and not have Start Keys. This means that occasionally, you might get an unexpected extra coin up, if an action button is pressed while another player is adding a coin. It also means the encoder might only be really useable in MAME. If one of the 4-player 4-button games is your all-time favorite and you often have three friends over to play it, this is probably acceptable. However, if you only occasionally (if ever) need all these inputs, you would probably be better with a solution that takes less compromises, and then maybe using a keyboard for coin inputs to play those one or two games.
NOTE: Also, note that if the shortcuts are used, they are for the most part required for all games. For example, the KeyWiz will work fine for a Street Fighter set-up in any emulator. It will work for 4-player 3-button games in MAME if you don't use discrete Start buttons. But if you set it up this way, you can't go back and have Start buttons work in a different emulator.
I said this was not a review, as such, but I wanted to take a little space and do a quick comparison of the I-PAC, KeyWiz, and MK64 (discontinued) on a couple of issues. Basically, I want to touch on Level of Usage, and Software. Also, since the design philosophy is the same for all models of each brand, unless indicated otherwise, the KeyWiz comments apply to all GroovyGameGear keyboard encoders and the I-PAC comments apply to all Ultimarc keyboard encoders. I have not included any of the gamepad encoders in this review, because while they are a viable option, their configuration is so different that that don't really fit into the context of this section.
I chose these three encoders to cover here, because IMHO, they represent some of the best choices for an arcade set-up, in terms of price, performance, support, and general value. In general, the MK64 is looking for a more experienced user than either the KeyWiz or the I-PAC. Not that a newbie to the hobby can't master an MK64 or that you can't do some very advanced things with a KeyWiz or I-PAC, but the trend is as above.
Of the three main encoders, I've noticed for a long time that the I-PAC is the most beginner friendly, the MK64 (discontinued) is the most advanced in setup, and the KeyWiz is somewhere in between.
For example - the I-PAC has inputs labeled 1SW1 through 1SW8 which always leads to people posting questions like "What games need 8 buttons?" (Doesn't help when the X-Arcade uses this set-up too!). (Short answer: None, but they're handy for Joystick 3 or dedicated admin buttons). Then, when you get more advanced, you get to, "Well, I was going to use 1SW8 for Rotary Joystick CCW, but then the NumLock LED will flash when I rotate the joystick, and that's annoying, so I can reprogram 1SW8 to "1" and reprogram "Start1" to "V" and then I wire the Start1 button to the 1SW8 input, and the Rotary Joystick CCW output to the Start1 input, etc." which gets confusing.
OTOH, the MK64 just says "This Pin is Input 00, these Pins are Inputs 01 through 63, you figure out how to program them!" Which means the end-user has to figure out "What inputs do I really want, and what can I live without?" and occasionally "There, 64 inputs, now let's build: Where do I wire Coin 4 to? Oops, I didn't assign it anywhere!, Hmmmn, what do I need to drop out now to make room for it?" However, this is preferable if you know how you plan to lay out your panel and may not want the same inputs as everyone else.
The KeyWiz strikes a nice balance, IMHO, in that the Joystick Keys are pretty well set in stone, but all other terminals are alpha-numeric, but the default codeset gives hints about what to include. The KeyWiz Max 1.5 even improved on the previous version in that inputs are now shown as U1 and U2 (previously and on the Eco, they are both U, but the position on the board makes the usage clear).
First Disclaimer - I know this is an odd way to start a comparison, bear with me . . .
IMHO, there are four factors in determining the usefulness of an encoder's software, in order:
- Speed - How long does the software take to load a custom codeset into the encoder?
- Accuracy - How sure are you that the software loads the custom codeset without errors? (Note that the second item is often in conflict with the first item.)
- Usability - How easy is it to run the software and have it do what you want?
- Usefulness, Uniqueness - Basically, this bullet is added specifically to address the WinIPAC IPD (Interactive Panel Designer) which quite frankly has some features that no other encoder software duplicates.
Unfortunately, I can only comment accurately on the latter two factors, as I have no way (or time) to test the first two. I have been told by Andy Warne that the WinIPAC IPD will load a custom codeset in under one second while the older software was about five seconds. KevSteele stated in his Retroblast review (which I found fairly inaccurate) that the KeyWiz software took less than 20 seconds to load under Windows XP and RandyT has stated that load times under Win98 are less than half of this (and my usage tends to support this).
Assuming this data is true, the WinIPAC IPD has a big speed advantage, followed by the older WinIPAC software, followed by the KeyWiz under Win98, followed by the KeyWiz under WinXP, but I have no way to verify this. Even if I had the hardware available, I would not consider the issues conclusively proven until I had done tests under multiple OS's under low, middle, and high-end systems (and in the case of Ultimarc, with each of the various I-PAC models).
Second Disclaimer Bear with me . . .
When I was initially planning my arcade panels, I thought I would have a custom codeset to program for Asteroids, another one for BattleZone, another one for standard MAME games, another for Visual Pinball, etc. I have since done a 180-degree about-face and now recommend NOT using the encoder software at all unless absolutely necessary. See the Summary and Conclusions section for my recommendations, but I have made this change because of the following two issues:
- Complexity - Recently I had to explain to an I-PAC VE user from BYOAC (not trying to pick on anyone in particular, so don't get offended), what was meant by "Add a shortcut to the software to load on Startup". I grew up with DOS and am very comfortable around a PC, but the fact is, for many users, they are better off using the default codeset, and using MAME's "INPUT - ALL GAMES" menu to make MAME do what the encoder wants. None of the software is particularly hard to use, but still . . .
- Speed - As stated above, I cannot verify the speed of the individual software. But keep in mind, I generally run NoNameMAME so I can take advantage of the Skip Nag Screens and -Skip Startup Frames features. The less you make use of custom codesets, and the less you bring up the software, the less time you have to spend waiting on the software instead of playing your games.
And the winner is . . . (Yeah, I know it's non-standard to announce the winner before the discussion, but . . .)
Ummmmn, well, the fact is, I can't fairly choose a winner. Personally, I like the simplicity and ease-of-use of the KeyWiz software, but once you get past the learning curve the WinIPAC IPD has several useful features which the KeyWiz software lacks. The best I can advise you is to read the rest of my comments and then decide for yourself what's important to you.
I decided to cover this separately as it is different from how the actual software works.
- MK64 (Discontinued) - The MK64 software runs in a DOS window, so it is compatible with DOS through Windows ME. It can also be used on Windows NT/2000/XP provided a driver is downloaded and the software is run in full screen mode.
- I-PAC - The I-PAC is the most versatile of the three encoders compatibility wise. There are programming support programs for DOS, Windows, Macintosh, and Linux. There is also a built-in programming mode which allows you to program the encoder without a host computer present. Note that Linux software is in development, but is currently only available for the older versions of the encoders.
- KeyWiz - The KeyWiz software is compatible with all current versions of Windows. The Graphical User Interface is not compatible with DOS, but codesets may be created and loaded from the command line in a DOS-environment. The GUI will work with Windows 95 with the VB5 runtime files installed. Windows 3.1 is untested, but I suspect the GUI won't work, but the DOS command-line portion of the software should be useable.
- Considerations - Here is another result of the above statements: Let's say I am running MAME on Beos, OS/2, RISC, or some other non-mainstream OS. With the I-PAC, I can use the built-in programming mode and configure the keys as I want them. I won't be able to load a different codeset, but I can reprogram as often as I like. With the MK64, I would need to plug into a DOS (or Windows) computer and program the encoder whenever I wanted to change codesets, but after that, it would work with the new programs. With the KeyWiz, even if I used a Windows PC to program the encoder, the settings would be lost when I switched to the other computer because the SDRAM memory isn't saved. I could, of course, configure MAME to work with the KeyWiz default codeset and use this in the other OS. Also, the following procedure requires a dual-booting system and is cumbersome and not recommended, but possible. I could boot through DOS or Windows to program the KeyWiz and then run my other OS. The SDRAM retains all programming until you actually kill power to the encoder. Of course, I also have to be able to boot into both OS's without re-starting the computer.
There are currently seven versions of the I-PAC software (not counting independent programming), and (depending on your perspective) eight different encoders. Since this can obviously lead to confusion, I am including the following chart. Green boxes are compatible, yellow are marginally compatible, and red are incompatible.
|Software Version/Encoder||I-PAC VE||I-PAC/2, I-PAC/4, J-PAC (Boards after 15Jan04 or upgraded) (Note 1)||I-PAC/2, I-PAC/4, J-PAC (Boards prior to 15Jan04 and not upgraded) (Note 1)||Mini-PAC (Note 2)|
|WinIPAC IPD||(Note 3)|
|WinIPAC (DOS) (New)||(Note 4)|
|WinIPAC (DOS) (Old)|
|WinIPAC MAC (New)||(Note 5)|
|WinIPAC MAC (Old) (Note 6)|
An upgrade for older boards is available here.
(2) Mini-PAC's cannot be upgraded to use the newer software.
(3) Inputs C and D can currently only be programmed in "Table View" mode. Inputs A and B can be programmed in "Panel View" mode by treating them as buttons 7 and 8.
(4) I am guessing this program can be used, assuming you can use the USB-based I-PAC VE in DOS mode. Again, however, inputs C and D cannot be programmed and inputs A and B can only be programmed by treating them as buttons 7 and 8.
(5) I am not sure of support for inputs C and D with this software.
(6) Not available for download, but available by request from Andy Warne at www.ultimarc.com.
(Discontinued) - In fairness, I
haven't used the MK64 software extensively, just looked at it enough to
verify it will do
what I need. The software is strictly command-line driven
with no GUI (Graphical
User Interface). If you grew up writing batch files in DOS,
this will be no problem
for you. If you grew up with Windows 95 and are
InstallShield Wizards and
such, this will take some work, but then again, so would most
emulators, so you can figure
it out. Basically, with the MK64, you create a text file in
Notepad (Wordpad, Word,
DOS Edit Screen) containing all the key inputs for the
encoder. You then use the
MK64 software to load this set from a batch file, prior to launching
It's not the prettiest solution in the world, but then
again, I would only want to
program an encoder when I got a new software program (and then only
when the new software
program couldn't use my MAME defaults), so I personally wouldn't be too
The software consists of the following programs:
- Keymap.exe - This is the main program that loads the codeset into the encoder's memory.
- Revision.exe - Displays the revision number of the software on the encoder's microcontroller.
- Intest.exe - Shows the status of all inputs in real time.
- Auxout.exe - Controls the auxiliary outputs.
- Readid.exe - Read's a control panel's ID number for automatically detecting swappable control panels.
- Keycrack.exe - Causes the MK64 to display hex codes for analysis.
- Writeram.exe - Writes to internal MK64 memory.
- Bank.exe - Changes the active keymap bank.
- KeyWiz - Before the WinIPAC IPD was released, I felt that the KeyWiz had the best programming software I have used from any encoder, period. In many ways, I still prefer it over the IPD software, but the IPD has some advantages that I can't ignore. The KeyWiz software is very similar to the WINIPAC (non-IPD) software, but with the following enhancements:
- Displays both Normal and Shifted inputs for all keys without having to tab back and forth between them.
- All programming is done by clicking the mouse over a small keyboard in the GUI, so you can program the encoder without connecting a keyboard to your computer.
- Up to fifteen codesets can be loaded from the GUI by simply clicking on a corresponding square. (Additional codesets can be loaded from a batch file or command line shortcut by re-naming one of the codesets and calling it from the batch file).
- The software includes a "Virtual EEPROM" mode, where you can load the last used codeset when launching the program at startup.
- Codesets can be associated with an application, so when you launch the program, you also launch the corresponding application.
One thing I don't like about the software is that if it is launched without the KeyWiz connected, it will hang until you click on Exit rather than just making three attempts and quitting. This would never happen with an arcade cab, but can happen with a desktop controller when you simply want to launch a quick PC game and play on the keyboard. I got around the problem by creating one shortcut that launched the KeyWiz software and then the game and a different shortcut that launched the game directly, but I now feel I was being overly picky.
I have used the WinIPAC IPD, IPACUTIL and WINIPAC software. I will mention the other Ultimarc software, but cannot fairly comment on them. Also, some of these items are probably firmware and not software, per se. This is not an issue to me. The I-PAC software consists of the following programs:
IPD (Interactive Panel
Designer) - Ultimarc has created a very innovative
software idea in the
Interactive Panel Designer Software. The concept is
brilliant, however, the software has a fairly high learning curve
compared to more traditional software. The results may be
worth it though.
Here is what makes this software shine: Let's say you use a non-standard button layout and assignment or multiple panels on your cab. Six months after your cab is built, an emulator like Chankast comes along and you want to set your cab up for it. With classic software, you have three options: 1) Dig out the documentation from when you built the cab, showing what button went to which terminal. 2) Open the cab and chase down the rat's nest of wires to figure out which terminal each button went to. 3) Open Notepad and press a button and see what letter pops up. Open your encoder software and see which terminal generates the corresponding letter. None of these options are very pretty. With WinIPAC IPD, you just open the software and select your control panel and it tells you immediately what letter each button will generate. If you need to change an assignment, click the button, press the new key, and save the .ipc file. Sweeeet!!! In some cases, priceless . . .
An important consideration when using this software is that the software has two distinct "modes" and the second mode has two distinct views. The first mode is the Panel Design Mode. The second mode is the Set Keycodes Mode. Set Keycodes Mode can be viewed in either Table View or Panel View, and in either view, you can view either key assignments or user text.
This is how you would use this software: The first step is to click on Options in the lower right corner and tell the software what kind of I-PAC you have and whether it is USB or PS/2. Next you would go to Panel Design Mode. The I-PAC software ships with a couple of default panels pre-loaded, so you can click "Load Panel" and modify one of these, rather than creating your own from scratch. Next, you select "Go to Panel Design Mode" From here, you can select controls in the left corner, color the controls, and then drag the controls to a black background to re-create your control panel. Once created, you then click on the button or joystick direction and click the corresponding I-PAC input in the left pane to tell the software how the button is connected to your I-PAC. Once you are done, you can save this layout (as a .cpl file). You can also load previously saved .cpl files from this screen. (This would be useful if you had multiple control panels, for instance.) After the panel is saved, you would click "Go to Set Keycodes Mode". Now you will see the key that each button (or joystick direction will generate). You can click each button and type a key in to change what key the button generates. You can also view and change shifted keys here. Also, right-clicking on a control will allow you to set an input to "none" or assign a macro. Up to four macros can be saved per config file, and each one can be four keys long. (Macros implement sequentially - i.e, press and hold key one, then press and hold key 2, then press and hold key 3, then press and hold key 4, then release.) The software also has a table view for programming inputs, which is very similar to the more traditional Winipac DOS software (but without having to remember keyscan codes, thank goodness) or the KeyWiz software. In addition, you can associate text labels with a button, so if you have a custom config file for a flight simulator, you can remind yourself that the button in the middle of the upper row is "Gear Up", rather than "Okay, I programmed this button to "G", but what does "G" do?". When complete, you would save your file as a .ipc file. These files can then be loaded from the program or a command line to automatically program the I-PAC.
A unique feature (which I did not verify) is the reverse-lookup feature in table mode, where you can press a keyboard key and the software will highlight the I-PAC input that generates this keycode.
Now for the flip side, here is what I dislike about the software:
First, the software is not very intuitive. If you keep in mind what mode you are in, you can get through it, but I often found myself confused on whether I was telling the software which I-PAC input a button was wired to or which keycode I wanted sent when I pressed a button, and when assigning keycodes, whether I was actually programming the unit, or just setting things up. I don't know how to improve it, but it takes some familiarization to get comfortable with it. Keep in mind that I'm a person who picks up on software easily and is very familiar with the concept of keyboard encoders and programming custom codesets, and if I was having this much trouble, I think a new user would have a very steep learning curve.
Next, the list of available controls is somewhat limited, but adequate. You have the following controls to select from: Coin Slot, Pushbutton, P1-P4 Start Buttons, Joystick, Trackball, and misc. control. Each of these except the coin slot and start buttons and misc. control can be any of eight predefined colors. I'm not sure why the Trackball was included, because you can't assign it to any I-PAC inputs, but anyway . . . There are a number of additional controls that could be added. As a BYOAC junkie, I would like to see side-mounted buttons (for pinball or start buttons that were mounted to the front (think Frogger), a top-fire joystick (preferably a choice of trigger, trigger and thumb, and trigger and two-thumb models), rotary joysticks (which could be assigned to the I-PAC using Druin's interface), a Star Wars Yoke, a spinner (which could take two I-PAC inputs if it were a Discs of Tron model), a shifter and pedals for racing games . . . well you get the idea.
Also, in Panel Design mode, on my PC at 1024x768 desktop resolution, the controls appear about 100 pixels tall when you select them and stay this height when you drag them over, then change to about 30 pixels tall when you drop them in place. This makes it very hard to accurately position the controls. I think it would be better if the controls dropped to their final size as soon as you brought them over. It would also be nice if there were a positioning grid which could be switched on and off to align the controls. (There is a "snap to grid" option, but it didn't seem to make much difference in my testing. I suspect the grid squares are to close together.) Finally, sometimes when the buttons were lined up properly, the captions would overlap, and I would have to re-adjust the buttons to make more room. It would be good if a shadow caption were shown along with the button when you were positioning it.
Again, as previously mentioned, Panel View cannot be used to assign the four additional inputs on the I-PAC VE, and you have to use Table Mode for that. Which brings up:
Table layout: This has one glaring annoyance: If I accidentally click a key I can't do anything else until I assign a value to it. This means if I accidentally click on an input, I have to change the input to something, and if I didn't mean to change it, I have no way to make sure I am setting it to the same thing it used to be. There should be an option where clicking a different key (or the terminal name instead of the input) would cancel "assign key" mode and leave the key unchanged, but there isn't. Also, if I assign the Shift Key to "Player 1 Start", then I can still assign a value to "shifted Player 1 start", even though this could never be selected.
A very minor annoyance was the aesthetics of the layout. There is a legend at the right that shows "lime =normal", and "blue=shifted". The top half of the table shows I-PAC terminal names in lime with assigned keys in gray. The lower half of the table shows I-PAC terminal names in blue with assigned shifted keys in gray. I think it would have been better to show the I-PAC terminal logos in gray one time only, with assigned normal keys in lime below them and assigned shifted keys in blue below that, but that's just my personal opinion, and the software works the way it is setup, once you get used to it.
Finally . . . (sigh of relief) - There are a couple of features which were obviously picked up from the KeyWiz software and do not seem to work on my system. First is the on-screen keyboard. (I just noticed on the Ultimarc page that this feature only works under Win2K and XP and not on Win98SE, which is why I can't test it.) Presumably, this brings up a keyboard display so you can use a mouse or trackball without an attached keyboard to program your I-PAC. Next is the launcher. This is supposed to allow you to associate a .ipc configuration file with a program and launch the software. On my system, it generates a run-time error. I don't really mind that the features were initially introduced on a competitor's product (imitation is the sincerest form of flattery, and this is commonplace in the software world - Look at Windows 3.1 which was a theft of the Macintosh OS, which was designed by the guy who designed the copier interface screen for Xerox . . .). My main gripe is that software shouldn't be released with non-working features (Launcher) and nothing to let you know that the feature is inoperative.
- IPACUTIL (DOS) - This was a great program when it came out, but it has some problems now. The I-PAC reads the key assignments as a 3-digit numeric code. This software keeps you from having to remember the numeric codes, but the software displays the numeric code instead of the alpha code. The alpha code can be displayed by right-clicking on the input. Another major drawback to the program is that it can be used with or without a mouse. This sounds like an advantage, but I found the program constantly jumping to another input when I wanted to program something, or changing an input when I just wanted to select a different input to change. It was easier than looking up the input codes and typing them into a text file, and as long as I double and triple checked my inputs before saving the config files, it worked okay, but if you can run one of the WINIPAC-style programs on your computer, you will be much happier.
- WINIPAC (Windows) is much easier to use and very well written. The graphical display shows a standard control panel layout. Click an input to select it and type a key to change it. And the keys are displayed as alphabetic characters. The only minor gripe with the software, is that it tends to assume that you are using a standard configuration, much like the I-PAC terminal names assume you will use a standard configuration, and it can get confusing if you don't.
- The Macintosh version of the software seems almost identical to the WINIPAC, but again, I am only judging by screenshots.
- The Linux version of the software is command-line based, but a GUI version for Linux, similar to the WINIPAC version, is in work. No comments, except that if you can navigate in Linux, you probably can run a command-line software package. For that matter, you probably can write your own GUI.
- Independent Programming Mode - This mode allows the I-PAC to be programmed without any software installed. I believe this is similar to how an X-Arcade is programmed, in that you press a hot-key combination to enter programming mode, then press a button on the control panel and when prompted, press a button on a keyboard connected to the I-PAC. I haven't used this method, so I can't comment on how well it works. The actual menu and prompts are sent to the PC by the I-PAC "typing" them just as someone typing on a real keyboard, so some kind of text display program must be running such as Notepad, DOS prompt or the appropriate program for any other OS. A nice feature of this utility is that it uses the actual control panel to select the button to be programmed so you don't have to refer to a chart of how you have wired your panel (or even know how it's wired).
- Test Mode - The I-PAC also has a built-in Test mode for determining whether any keys are stuck or not responding. I have not used this personally. This uses the same "auto-type" method as the Independent Programming Mode described above, and can list all current key assignments or any pressed or shorted keys. This is useful for finding wiring errors or shorts. This mode displays the I-PAC input(s) affected and their current keycodes in a format such as "1 SW 1 L-CTRL".
As stated previously, I recommend avoiding use of encoder software as much as possible, and probably wouldn't base an encoder decision on that feature alone. Having said that, most of the other features are much less important. For example, assuming you got reasonably close on the number of inputs you require, you might hate wiring up a Mini-PAC without the optional wiring harness, but once it's set up and working, you can forget about that. OTOH, you will probably at least use the software every time you add a new program to your cab, and whenever using a non-default codeset, you will see the software every time you launch that particular application.
One nice attribute is that the MK64 (discontinued), I-PAC, and KeyWiz software are all freely available for download, so you can try out the look and feel (but not the performance) of the software before you make a decision. In fact, you could pre-setup your custom codesets so that once your encoder arrived you only had to connect the wires to start using it properly. Unfortunately, without some special trickery, the KeyWiz software will not allow you to do anything with the software unless a KeyWiz is detected.
At this point, I would like to recap some of the key features of each software and close with my recommendations on software use.
- MK64 (Discontinued) - The MK64 software has some advanced features that the other programs lack (ability to distinguish one control panel from another panel and swap codesets accordingly, for example), but the software is also the least intuitive. If you are not familiar with command line software, it will be difficult to use at first. If you are familiar with command line software, it will still take you a while to get used to it.
- KeyWiz - The KeyWiz software has the following key features:
- Simple and easy to use interface.
- Can be used with a trackball and mouse (and no keyboard) under any supported OS.
- Can load any codeset and launch the associated application with a single keyclick or associated shortcut.
- Virtual EEPROM feature makes the SDRAM-based KeyWiz work more like an EEPROM based encoder.
- WinIPAC IPD - The IPD software has the following key features:
- Unique interface allows you to program key assignments to buttons without having to figure out how the encoder is connected.
- Claims to be faster than other software.
- Macro capability. This is mainly useful for emulators such as Project64 or Visual Pinball (?) which require a combination like Alt-F4 to quit. However, if this is the primary usage for this, you could alternately use either Ultra Keyboard, Howard Casto's command-line wrapper, or Stuzza's modified emulators.
- WinIPAC (non-IPD) - This software is very simple and easy to use, but lacks most of the advanced features (auto-launch, fast load times, macro capability) of the programs above.
- Recommendations - Generally, these are my suggestions for setting up encoder software on a MAME cab. These may of course be modified, and you may want to vary them somewhat if you are using your encoder in conjunction with a standard keyboard, etc:
much as possible, use the default encoder codeset and re-program MAME
to match this codeset. It may seem awkward to have to set up
MAME to use "R" to access the TAB menu, for example, but once the cab
is completed, you won't know what keycode is being sent
anyway. (And you will appreciate not having to wait to
program the encoder everytime you get ready to start MAME.)
CLARIFICATION: The method detailed above is most useful for the KeyWiz series of encoders. The KeyWiz is SDRAM-based, so it will not retain (in memory) custom codesets after a power-down. However, it has a very well-thoughtout default codeset; so using the default codeset saves you from having to reprogram the encoder on each re-boot. For the I-PAC/2, Mini-Pac, and J-PAC encoders, this method is optional (but recommended, I have heard second-hand reports of these encoders "losing" a custom codeset) since the encoder uses EEPROM. The point here is that you would prefer to have one codeset (default or custom work for all of MAME). For the I-PAC/4, several inputs default to "None", so you will have to re-program the encoder at least once to use all the inputs, but again, the same codeset should be used for all of MAME. For the I-PAC VE, this encoder is SDRAM-based, but you would have to reconfigure MAME to recognize the default C and D keys, or re-program (from a shortcut launched at startup) the encoder on each reboot. For the MK64 (discontinued), I believe you have to program it once to load a default codeset, but you shouldn't have to re-program it again for MAME use.
- For programs that allow re-assignment of inputs (newer emulators and many simple PC games, Visual Pinball, etc.), re-program the game or emulator to use the same defaults as you have defined above for MAME, with the buttons that you plan to use. (This may seem awkward if you tried to use a keyboard to play the game, but will be perfectly natural when using your arcade control panel, and again avoids having to wait for software to load.)
programs that do NOT allow re-assignment of inputs (older emulators,
DOS based programs, many modern PC games, etc.), you will have to use
the encoder software to re-program the encoder to match the inputs that
the game uses. There are a couple of concepts to do this,
and different implementation methods for each concept and encoder.
CONCEPTS: For an individual game (Flight Simulator 2004, etc.), you would have to create a custom codeset and load this prior to launching the game (see implementation below). For a multi-game emulator (Stella, for example), you have two (or three) options for doing this, depending on your personal preferences and encoder: Option 1 would be to make a copy or your front-end or front-end directory, so you basically have a MAME front-end and a Stella front-end. Then you would have to create a custom Stella codeset and load this prior to launching the Stella frontend. Alternately, if you didn't want to do this, you could intermix the games with your MAME games in your front-end and call individual shortcuts to load the Stella codeset and launch the game. This might mean creating 30 to 40 shortcuts and/or 30 to 40 codesets (by copying and renaming previous ones).
IMPLEMENTATION: I will cover this on a per-encoder basis:
KeyWiz: For Flight Simulator, you have two options - 1) Create a MSFS.kwz (or A.kwz, etc.) file and and associate it with Flight Simulator in the KeyWiz software. Now create a shortcut to it. When you click the shortcut, the KeyWiz is re-programmed and Flight Simulator is launched. The drawback to this is when you exit Flight Simulator, your KeyWiz is not set-up for MAME until you re-boot. Option 2 works around this. 2) Create a batch file which launches the KeyWiz software and loads the MSFS.kwz profile, launches Flight Simulator, and then re-launches the KeyWiz software to load the default codeset.
For Stella, you would follow the same concept, but the shortcut/batch file would either point to the frontend or would launch individual games.
I-PAC: Programming of the I-PAC is similar, except that the I-PAC software cannot launch shortcuts, so you have to write batch files for each program and launch these. So you would write a batchfile to load the custom codeset, launch the application, load the default codeset, and exit.
I decided to include these on a separate page. This is set-up not so much to tell you what you HAVE to use, but more because someone will see the chart below and say "You can't support 4-player 2-button games with a keyboard hack!" or "You can't support 5 player 2 button games with a KeyWiz", so this is a way to demonstrate how to do this, rather than answering a bunch of E-mails.
Here, I provide a quick look at what each encoder will do. Headings in Red indicate a "Diminishing Returns" point, in that very few games use this many inputs, and more expensive encoders are required to support them (for example, MAME-wise, excluding clones, we are talking about 7 games out of approximately 2100; Encoder-wise, this is where we go to the $60-ish encoders instead of the $30-ish ones). I use the following color codes and provide details in the notes below the table:
|Won't work, not enough inputs|
|Maxed out (no coin ups, no Start buttons) (This is not a workable option)|
|Significant Shortcuts (Shift keys for Start buttons, etc.)|
|Minor Shortcuts, no effects on gameplay (no discrete Start buttons, for example)|
|No conflicts in this game.|
|No Conflicts with this Setup and with Street Fighter setup.|
NOTE: Before someone comments on this, Shift functions for coin inputs will be coded yellow. Shift functions for Pause and Escape are coded yellow for the I-PAC and MK64 because I have to remember a key combination to use them. They are coded lime for the KeyWiz, because I can use Stealth Mode and they seem like a normal button.
Update: I really need to update the table now that you can do single-click shift functions on the I-PAC encoders, but so far I haven't done so.
|Ikari/Street Fighter (24)||Tank Games (26)||3-Player, 3-Button (21)||4-Player, 2-button (24)||4-Player, 3-button (28)||4-Player, 4-button (32)||5-Player, 2-button (30)||5-Player, 3-button (35)||6-Player, 2-button (36)||6-Player, 3-button (42)|
|Gamepad Hack (14)||Note 1||Note 1||Note 1||Note 1||Note 1||Note 1||Note 1||Note 1||Note 1||Note 1||Note 1|
|AKI - Analog Kontrol Interface (14)||Note 1||Note 1||Note 1||Note 1||Note 1||Note 1||Note 1||Note 1||Note 1||Note 1||Note 1|
|Keyboard Hack (16)||Note 2||Note 3||Note 4||Note 2||Note 2||Note 4||Note 4||Note 4||Note 4||Note 4||Note 4|
|Hagstrom KE18 (18) (Note 5)|
|Hagstrom LP24/KE24 (24) (Note 5)||Note 6||Note 3, 6|
|Hagstrom LP24/KE24 (22x2)||Note 7||Note 7||Note 7||Note 7||Note 7||Note 7|
|MAMI 24 (24)||Note 7||Note 3, 7||Note 8|
|ButtonBox (27) (Note 5)||Note 3 or 8||Note 7|
|I-PAC/2, J-PAC, Mini-PAC (28)||Note 7||Note 9||Note 7||Note 9|
|X-Arcade PCB (28)||Note 7||Note 8||Note 7||Note 8|
|MAMI 30 (30)||Note 7||Note 10||Note 12|
|I-PAC VE (32)||Note 10||Note 10||Note 7||Note 9||Note 11|
|KeyWiz (All Versions) (32)||Note 10||Note 10||Note 7||Note 9||Note 11||Note 11|
|Hagstrom KE-USB36 (36)||Note 10||Note 10||Note 7||Note 8||Note 7|
|MAMI 48 (48)||Note 10||Note 10||Note 7||Note 8|
|I-PAC/4 (56)||Note 10||Note 10|
|MK64 (with rotary joysticks) (52)||Note 10||Note 10||Note 7|
|Lupine Systems Encoder (60)||Note 10|
|MK64 (standard) (64)|
|Hagstrom KE-72, KE-72T (72)|
|Ikari/Street Fighter (24)||Tank Games (26)||3-Player, 3-Button (21)||4-Player, 2-button (24)||4-Player, 3-button (28)||4-Player, 4-button (32)||5-Player, 2-button (30)||5-Player, 3-button (35)||6-Player, 2-button (36)||6-Player, 3-button (42)|
It is assumed that multiple gamepad Hacks/AKI's
will be used or that this is for a single-player cab. Using
one pad per player, any
configuration can be supported.
(2) By allowing the Down input to ghost with the UP input, etc., we need two inputs per joystick, so 12 buttons for 2 players, 10 buttons for 3 players, and 8 buttons for 4 players. Coin and Start keys and Pause and Escape keys can be included, but may have ghosting/blocking issues (meaning the key might not register if a diagonal or some other key combination is pressed at the same time. INTERESTING NOTE: While a keyboard hack will not have ghosting issues with any of the action keys shown above, and duplication of inputs is not required, blocking will occur if (for example) P1B3 and P4B1 are pressed at the same time.
(3) Rotary Joystick Inputs will need to share with Buttons 5 and 6. A switch can be wired to select between them.
(4) The two separate action buttons may have ghosting/blocking issues.
(5) Direct Mode shown, in Matrix Mode, this encoder will support any of the configurations shown with no conflicts.
(6) No Discrete Start Buttons (so MAME only), or No Coin 2 button, No Pause or Escape Button.
(7) No Discrete Start Buttons (so MAME only), but Pause and Escape Okay, or Start and Coin Buttons, but no Pause and Escape. Pause and Escape can use J1 Up and down (MAME only).
(8) No Discrete Start Buttons (so MAME only), and No Pause or Escape Inputs. Pause and Escape can use J1 Up and Down (MAME Only).
(9) No Discrete Start Buttons (so MAME only), Shift functions can be used for Pause and Escape, or Pause and Escape can use J1 Up and Down.
(10) Player 1 and Player 2 buttons 4 through 6 must be doubled as inputs if Street Fighter and these games are both to be supported on the same panel.
(11) No Discrete Start Buttons (so MAME only) Shift functions must be used for Coin and Pause, Escape.
(12) No Discrete Start Buttons (so MAME only), but Pause and Escape are okay.
This is a new section to the comparison page. Here I decided to pit a couple of competing products up against each other and see how they stack up. This is a popular topic on BYOAC, so it should make for some interesting and controversial reading (and more than anything else on the page, this is highly opinionated). Also, I meant this as like a 20 questions or word association format, so I may well overlook some indispensable (for you) feature on the losing product. That's what the main page is for.
I decided to limit the competition to products from DaveB, Druin, GroovyGameGear, OSCAR, and Ultimarc, mainly because these are all well-establish, value-oriented arcade products. I also do not include silly comparisons like Druin's Rotary Interface vs. Opti-PAC.
If both products are listed in Green, that means I was unable to determine a clear winner. If one product is listed in Green and the other is listed in Yellow, that means I would pick the Green product, but someone could make a case for the Yellow product. If one product is listed in Green and the other product is listed in Red, that means I clearly prefer the Green product. Products are listing in order of interest, in my personal opinion.
First things first, the big question - the one it all started with!!! One of the most asked posts on BYOAC.
First off, unless you care about blinking LED's, USB capability, non-Microsoft OS capability, a working pass-thru or screw terminals, the KeyWiz Eco at $20-23 is a much better value than the I-PAC/2 at $39-43, IMHO. Between the $35 KeyWiz Max and the $39-43 I-PAC/2 it's more of a toss-up (but don't worry, I won't leave it at that!).
KeyWiz Advantages: 32-inputs vs. 28 (27 action and 1 shift). Shift function operates more flexibly and doesn't rob an input. Easier to add "stealth" one-click shift buttons (but can be done with an I-PAC as well). Alternate codeset swapping. Software can be operated with a trackball and no attached keyboard. Software includes virtual EEPROM mode to load last codeset.
I-PAC Advantages: 27 shift inputs vs. 24 shift inputs. Shift function doesn't require an additional button on your CP (KeyWiz can mimic this, but not exactly replicate it). LED support. Active keyboard pass-thru. USB or PS/2 capability. EEPROM. Support for Linux, Mac, Windows, and DOS. Can also be programmed directly through an attached keyboard without any OS support. Windows software can program an input to send macros or single keys.
Capabilities: Most people won't take advantage of it, but using stealth-shifted inputs, the KeyWiz can (with some difficulty) support 4-player 4-button games and fairly easily support 4-player 3-button games. In theory, the I-PAC/2 should barely be able to support 4-player 3-button games, but because of the way the shift function is implemented, the best it can do is 4-player 2-button games.
The I-PAC VE is much closer to the KeyWiz Max than the I-PAC/2. Price is identical when you balance the free shipping against the cost of the USB A-B cable. Basically, it adds four additional inputs, swaps EEPROM for SDRAM, loses the keyboard pass-thru, and is USB only. Again, the same value statements apply between the KeyWiz Eco and the I-PAC VE.
Normally, this would just be a question of "Do you want LED support?" and "Do you want PS/2 or USB?" I would leave it this way except for one small factor: The default I-PAC VE codeset has two inputs with the same keycode assigned. This means that you HAVE to re-program the encoder if you want to use all the inputs. (And you have to do it every time you use it). Granted this isn't a big deal if you don't use all the inputs, but it's one of those easily avoidable oversights that drives me nuts.
Capabilities: The shift routine prevents the I-PAC VE from supporting 4-player 4-button games, but 4-player 3-button games can be supported as well as they can on the KeyWiz, although the stealth-shifted inputs require a resistor and capacitor per input rather than two diodes.
Again, this should come down to "Do you want USB or PS/2?" and "Do you use mostly gamepad software or keyboard software?" Again, it gets more complicated than that.
First off, I like the GP-Wiz as an add-on controller. The question here is how it performs as a primary controller. I think the majority of PC software is keyboard based (so you need RBJoy or JoyToKey with the GP-Wiz, but that's okay). The killer for me is that the GP-Wiz is seen as a single 32-button gamepad. This means that even programs like ZSNES, which are designed to work with gamepads require you to use JoyToKey or RBJoy. Similar to running two 12-inch M-F cables spliced together instead of a two-foot M-M cable. Either option gets the job done, but one is a lot tidier.
No, you did not read that wrong. Yes, I do realize that the I-PAC/4 is a 56-input encoder and the KeyWiz is 32-input. If you want independent inputs, the I-PAC/4 wins this hands-down. In fact, even if you don't mind sharing inputs, the KeyWiz is still struggling to keep up. But it puts up a valiant fight even when clearly outclassed.
First, a little reality check - Unfortunately the MAME controls data is very sketchy and inaccurate, but I think if you eliminate clones, there are only three 4-player 4-button games (and NO 4-player, more than 4-button games) in MAME as of 0.98 - Dungeons & Dragons: Tower of Druaga and Dungeons & Dragons: Shadow over Mystera and NBA Jam Extreme. With 32-inputs, the KeyWiz can handle this, but you need shifted inputs for both Coin, Start, and Pause/Escape buttons. You could work around this for MAME by having Pause and Escape be something like a triple-button press (with one button wired to three inputs with diodes), but it's not a great solution and would not work outside of MAME. On the other hand, there are a lot of 4-player 3-button games, and the KeyWiz can handle these fairly easily and with only a few hiccups.
Yes, you have to share and use stealth-shifted inputs, but it's not bad for a $35 (or in the case of the Eco, a $20/$23) encoder competing with a $65-69 encoder. For those who are doubting Thomas's about this, here's what I posted on BYOAC about it:
Basically you want a 4-player 3-button layout with coin and start keys. 28-inputs plus Pause and Escape plus 8 coin. Can't be done with anything but an I-PAC/4 or KeyWiz, but can be done with a KeyWiz if you don't mind shifted coin and start inputs. (RandyT's adapters or diodes).
Here's how you wire the KeyWiz:
1U,1L,1R,1D,2U,2R,2L,2D - Joysticks 1 and 2, as
Terminal 1 - P1B1
Terminal 2 - P1B2
Terminal 3 - P1B3
Terminal 4 - P1B4
Terminal 5 - P1B5, P4B2
Terminal 6 - P1B6, P4B3
Terminal 7 - P4 Left (optional P1B7)
Terminal 8 - P3B3 (optional P1 B8)
Terminal A - P2B1
Terminal B - P2B2
Terminal C - P2B3
Terminal D - P2B4, P4B1
Terminal E - P2B5, P4Up
Terminal F - P2B6, P4Down
Terminal G - P4 Right (optional P2B7)
Terminal H - P3B2 (optional P2B8)
Terminal I - P3Up
Terminal J - P3Down
Terminal K - Pause
Terminal L - P3Left
Terminal M - P3Right
Terminal N - Unused (F10, or Enter, or Tilde, or Tab, "if" you wanted)
Terminal O - P3B1
Terminal P - Esc (quit)
Stealth-Shift 4 (4 and Shazaaam! wired to
one button with diodes) - Start 1
Terminal SS5 - Coin 1
Terminal SS6 - Start 3
Terminal SS7 - Coin 3
Terminal SSD - Start 2
Terminal SSE - Coin 2
Terminal SSF - Start 4
Terminal SSG - Coin 4
With this layout you can play 2-player SF games or 3-player 3-button games NO conflicts (unless someone bumps the Player 4 joystick. . .) 4-Player 3-button games are no problem unless the P1 and P2 players start mashing the 4-6 buttons. You'll need to have some kind of honor system or control who uses those sticks, or you could wire a switch to swap grounds between the sets of buttons.
The other drawback is the Coin buttons - when a Stealth Shifted button is activated, all other buttons are shifted, so the joystick inputs are briefly disabled, and you could end up with an extra credit registering instead of an action button, or vice versa, but I've tried to minimize this. Should rarely be a problem and not a game stopper even if it did occur.
The A-PAC is slightly more expensive at $39 vs. $33 for the AKI. As a hard comparison, the AKI supports 5 axes compared to 4 for the A-PAC, but the A-PAC supports up to 32 buttons with up to 30 shifted inputs. My gut feeling is the AKI is probably better as a "pure" analog controller, while the A-PAC is better as a "general purpose" encoder.
Overall, I give the edge to the A-PAC for the following reasons. Neither one is very good for connecting swappable controls, but the A-PAC does slightly better b/c it does not have to have the unused inputs tied to ground (although I think they have to be enabled). I also think the additional and shifted button inputs and the fact that you could use it with digital controls and upgrade to analog controls later make it worth the additional cost.
The Opti-PAC costs $39/$43 and supports two trackballs AND four spinners in any combination and activates either the trackball or the spinner when operated. The OSCAR USB interface costs $9/$12.50 and controls a single trackball OR two spinners.
For most applications, I see the Opti-PAC as using a bazooka to kill a gnat. The auto-switching is neat, but to use dual trackballs in MAME you need a specific build of the emulator, and if you are using that specific build of the emulator, you can assign whether the spinner or the mouse controls the action anyway. The Opti-PAC would allow you to do this in any program, though. Basically, the Opti-PAC is a four mouse device, where the OSCAR Mouse Interface is a single mouse device (obviously), but the Opti-PAC costs four times as much. So either you are breaking even or you are paying extra for unused capability.
Closing thoughts: The Opti-PAC is generally easier to hook up and is more flexible in terms of Active HI or Active LO devices. And if you use OSCAR's custom harness with the OSCAR Mouse Interface, it eats up a lot of your savings. OTOH, the OSCAR mouse interface has a definite advantage for swappable panels and modular controls.
Basically $49 for the Mini-PAC and the OSCAR interfaces and $43 for the Opti-PAC, but that six dollars more buys you a 28-input encoder capable of controlling two joysticks for 85% of the games in MAME, at the expense of being able to disable the second pair of controls (which are active on the Opti-PAC anyway. Seems like a clear winner to me.
NOTE: Technically, the Opti-PAC still has an additional spinner interface over this combination, but I think it would be unlikely to be used in a real world panel.
Okay for the Max version, we are looking at $35 for the GP-Wiz49 as against $33 for the SJC. The GP-Wiz49 Eco version gives up screw terminals for a final cost of $20 and $23. But even on the Max version, that extra $2 gets you 13 more input buttons, 5 more shifted inputs, along with Digital Restrictor Selection™ firmware which allows the joystick to behave like any one of eight different types of joysticks. This one isn't even close.
Huh, what are you getting at? These two aren't even compatible. Bear with me. The GP-Wiz49 has been all the rage on BYOAC since it's introduction, but has anyone ever counted the cost of this setup. Well, I'm going to now. Assuming a two-joystick panel:
two Prodigy joysticks: $23 plus $70.
KeyWiz Max and two Prodigy joysticks: $35 plus $70.
GP-Wiz49 Eco (2) and two 49-way joysticks: $46 plus $66
GP-Wiz49 Max (2) and two 49-way joysticks: $70 plus $66
Price Differential for the Eco versions: $112 - $93 = $19
Price Differential for the Max versions: $136 - 105 = $31
I picked the Prodigies as a reference because of their easy switchability between 4- and 8-way mode, excellent control in 4-way and rotated 4-way mode, and to stay with GroovyGameGear products for consistency. An alternative would have been the Ultimarc T-Stick Plus joysticks, currently (12Jul05) at $24.
This would give the following revised figures:
two T-Stick Plus joysticks: $23 plus
KeyWiz Max and two T-Stick Plus joysticks: $35 plus $48.
Price Differential for the Eco versions: $112 - $71 = $41
Price Differential for the Max versions: $136 - 83 = $53
Is it worth $19-$53 to play Sinistar, Road Runner, Arch Rivals and a handful of other games and to be able to switch from a 4-way to an 8-way game without having to flip a lever back and forth (or lift and twist). You bet!!! After all, people are paying $150 on E-bay for Star Wars yokes that were only used in about five games! On top of this, not only do you not have to flip the lever back and forth, you don't have to REMEMBER to flip the lever back and forth, because the software will do it for you.
Ironic Fact: Assuming these three options (49-way, Prodigy, and T-Stick Plus) are the most versatile joysticks, you have a combination of what appears to be one of the longest throw joysticks with two of the shortest throw ones.
Ironic Fact 2: I originally had this set up to go the other way until I actually did the math!
$29 for the Mini-PAC against $23 for the Eco or $35 for the Max or I-PAC VE. Even at the ECO level, the basic question is "Is a mouse and spinner interface worth 4 inputs less and $6 more?" In my opinion, it is.
This one's even clearer than the Mini-PAC vs I-PAC VE comparison above. $29 vs. $39/43 and you gain a mouse and spinner interface and give up screw terminals and PS/2 capability (the mouse/spinner only works in USB). No brainer to me.
Another no brainer to me. $35 against $39/$43. $4 to $8 less and you gain four additional inputs at the expense of PS/2 connectivity. The only "iffy" thing is the loss of EEPROM, if that's important to you.
This is basically a combination of my GP-Wiz vs. KeyWiz and KeyWiz vs. I-PAC/2 thread. Again the Eco GP-Wiz at $23 is a better value than the I-PAC or I-PAC VE at $35 or more. On the I-PAC/2, I'm going to take a cop-out here and refer to my comments on the KeyWiz vs. the I-PAC/2. The price is the same, so the only difference is this is USB and you will have to use software for programs that don't accept gamepad inputs. For the GP-Wiz vs. I-PAC VE, the price of the two encoders are the same and both are USB, it's just a matter of keyboard interface and LED support vs. gamepad interface. I generally feel the keyboard interface gives you more compatibility, so I will pick the I-PAC VE. (Although I expect to be beaten with a wet noodle by RandyT for this because he asserts that USB is a terrible choice for a keyboard interface, but I'm tough, I can take it).
The Eco's again do well in this scenario. $46 for 64-inputs as opposed to $65/69 for 56 inputs. Even a pair of Max's is only $70, but the I-PAC/4 can hold it's own here. Against the max's, you are basically looking at the same features as the KeyWiz vs. I-PAC/2, but with more inputs.
I will weigh in on the Dual GP-Wiz's vs. KeyWiz/GP-Wiz debate. Unless you for some reason want a strictly USB solution, I like the KeyWiz/GP-Wiz option. The keyboard interface is compatible with more games, and you also get the 24 shift keys.
The GP-Wiz is mentioned in this scenario, b/c it is probably the most cost efficient method of adding this if you don't already use an I-PAC/4 or dual GP-Wiz49's. The Eco version is also priced reasonably close to the Druin Rotary Interface at $23 vs. $25. Basically, the direct connection is the most accurate control method, but the Druin Rotary Interface wins out for two reasons: The direct connection method currently (12Jul05) only works for about half of the applicable games. The direct connection method will not work for "pseudo" rotary games like Xybots or spinner games.
The ideal solution is to wire you joysticks in parallel using both methods.
Okay, these really don't belong in the same comparison - different functionality, but someone would be bound to ask. If you are hooking up analog controls (or plan to), you can't even use the GP-Wiz. If you just want a USB Gamepad interface for digital controls, the devices compare like this: The GP-Wiz is $23/$35 depending on Eco/Max versions. The A-PAC is $39. Generally, the A-PAC is a more capable device, but for digital controls, there is probably some overhead as I think it is basically doing an analog to digital conversion on the joystick directionals. OTOH, I prefer the way the A-PAC is enumerated as two separate joysticks, has 30 available shift keys, and gives you the option to add analog controls at a later date. For most applications, I would prefer the A-PAC.
These aren't even in the same ballpark but someone will probably ask. If you need analog controls, get the AKI. If you don't, get the GP-Wiz. End of story.
Hopefully, this information will prove useful in choosing an interface. In closing, I would like to recommend the following steps when choosing a keyboard/gamepad encoder:
- Determine what you can spend, and what games you need to support (will you ever really play a six-player game with 5 other people? Will you use any applications besides MAME?)
- Determine the number of inputs required to support the games you wish to play. For example, if you mostly play Pac-Man (4 inputs) or SkyShark or Tiger-Heli (6 inputs) or Tempest (3 inputs), and your wife plays Centipede (1 input) and Frogger (4 inputs) and the other games never get played, it's silly for you to buy an MK64 (Discontinued). In fact, it's silly for you to buy much more that a $5 gamepad hack, or for convenience, a KeyWiz (not that the KeyWiz is limited, but it is the least expensive option). OTOH, if you regularly play IKARI with mechanical rotary joysticks (the way it was meant to be played), and you also play The Simpsons with 3 other people and Street Fighter/Mortal Kombat, it hardly makes sense for you to buy anything other than an MK64 (discontinued) or an I-PAC/4.
- Determine if you are comfortable with doubling up inputs for a Street Fighter and four player set-up, and add additional inputs to the required number if you are not wanting to double up inputs. NOTE: Another option is to make a removable 4-player panel with only 2 or 3 buttons per player and swap this in and out. This requires approximately an additional $25 in joysticks and buttons, and IMHO is not worth the inconvenience of swapping panels, unless you already had an encoder hooked up and didn't want the hassle of buying a new one and re-wiring everything.
- If an encoder with the number of inputs you need is out of your price range, see if any of the shortcuts above (basically eliminating Start buttons, and mapping Pause and Start to joystick directionals) can help you use a less expensive encoder with less inputs.
NOTE: I said in several places that these changes are "MAME Only". Is this really true? That depends on the specific application that you want to use the encoder with. Basically, you probably won't have Start and Pause/Escape buttons outside of MAME if you use these methods. Here are three examples: If you play Microsoft Train Simulator and want to map the left joystick up/down to the locomotive brake and the right joystick to the throttle and have some buttons for the horn and lights, you can do this. The game doesn't use start buttons. Escape is used to pause the simulation, but you could use a different panel button to do this. For Visual Pinball, the game doesn't use a lot of buttons, but it does have player Start Inputs. You could make this work, but you couldn't use the Start buttons on your panel, and it might be difficult for people who were used to using your panel for MAME to get the hang of. For other emulation programs like Modeler, or Zinc, or Nebula, you might not have enough inputs to use these programs properly.
NOTE2: One thing to seriously consider though, is these shortcuts require wiring changes, so they are NOT reversible. For example, MAME works fine with the changes above, so if you ONLY plan to use MAME with your controller, they are worth considering. If you need a dedicated Start Button or Pause Button for some games; however, you can't make it work if you have these shortcuts incorporated.
- Definitely plan what you are doing and how you will use the encoder before you purchase.
- Have fun!!!
For better or worse, basically, while not a two-horse race, the encoder market basically boils down to a two-stable race between the KeyWiz line from GroovyGameGear and the I-PAC line from Ultimarc. This page was not intended to be a KeyWiz vs. I-PAC comparison, but since that's where we are, and since this gets asked a lot and I am not afraid to tackle this, humor me and you will at least get a fresh perspective on this. By the way, there is no "which one is better", they both work extremely well within what they were designed to accomplish.
So in the spirit of "What Color Is Your Parachute", I present "Tell me what you would CHOOSE to drive, and I'll pick an encoder for you":
1: Hummer H1, Ford Expedition XLT
4x4 V-10 Cummins Diesel, Any Ferrari, Ford GT, Ford Mustang GT (4.6L
Audi TT AWD
These are "not your grandfather's" vehicles. They feature balls-to-the-walls performance. The kind of cars that you can rev up to just below redline, drop the clutch and leave the competition (and most of your rear tires) in a cloud of smoke (and expect to do it again at the next red light). The trucks are the type that you can choose your own path when the official roads are closed. They might not fit in at the Country Club. The Hummer might need to take two parking spaces, not b/c it's owner is overly cautious, but b/c it NEEDS to take two parking spaces. Ferrari used to not even OFFER a radio. The salesman would happily tell you that if the music of the V-12 purring behind your head wasn't entertaining enough, perhaps you should consider another car.
2: Hummer H2, Ford
Expedition Eddie Bauer 4x2 4.6L V-8, Any BMW, Chevrolet Corvette, Ford
Convertible, 3.8L V-6, Cadillac STS.
While definitely not performance slouches, these vehicles are in a different category. These are the cars you can drive for a 12-hour trip and look forward to taking out again. These are the vehicles with 10-disc CD changers, with On-Star Satellite Navigation systems, with digital readouts to tell you your tire pressure and on-board air compressors to blow them back up again. These are the vehicles with computers to monitor contaminants in the oil to tell you when to change it, rather than just waiting 'til 3,000 miles click past the odometer.
So which set would you pick?
If you pick Category 1, you're a KeyWiz purchaser. The hallmark features of the KeyWiz are: Value (Bang for the Buck), Performance, and Versatility. Want a two-player cab, but might want to make it 4-player later - you don't even have to upgrade the KeyWiz. 32-Key Input Test - Not a problem. Want your shift key to not use a gaming input - it won't. Want it to work like the I-PAC - just wire a stealth-shifted button up. Want many shifted inputs with their own buttons so you don't have to remember combinations of presses - it can do that. Like the codeset swapping - you got it. Dislike the codeset swapping - change two wires on your joystick switches.
If you pick Category 2, you're an I-PAC purchaser. This could be called the "more frills for your bills" encoder. The I-PAC/2 has a number of features that the KeyWiz does not, such as USB support, support for OS's like MAC OS X, and Linux, automatic keyboard pass-through, support for keyboard LED's, etc. But while nice to have, none of these features are really required for the majority of encoder users. It won't work very well for a 4-player panel, but it also was never designed to either.
In the end, you pick the features that are important to you, and you make your choice.
I recently (Jul05) got into a discussion about the KeyWiz and I-PAC with Howard Casto. Howard is a big I-PAC fan, so it was interesting to compare notes. Basically, we agreed on the weak and strong points of each interface. The difference was in the importance we placed on each option. Then Howard came to the car section above and said basically he saw the KeyWiz as the souped up import tuner and the I-PAC as the classic Detroit Iron musclecar. (Which is pretty much diametrically opposed to what I said above. All I can say is closing, without being sacreligious or accusing either of us of megalomania, is that I am reminded of the lyrics from Dire Straits hit "Industrial Disease" - "Two men say they're Jesus, one of them must be wrong. . ."