Arcade Interfaces

ARCADE INTERFACES

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.

DEFINITION

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.

INTRODUCTION

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.

SHORT SUMMARY

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:

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.

ANTI-BIAS STATEMENT

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.

COMING CLEAN (A PERSONAL SUMMARY)

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.

LESSONS LEARNED

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).

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).

EMERGING TRENDS

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:

DE-BUNKING SOME MYTHS

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.

REALITY CHECK

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).

IN PERSPECTIVE

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:

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):

This results in the following categories, as shown in the Comparison Table section:

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.

THE PLAYERS

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)		 Shifted Inputs
(Note 4)		 Programming
(Note 5)		 USB-PS/2-Other
(Note 6)		 Console Support
(Note 7)		 Connection Methods
(Note 8)		 Keyboard Pass-thru
(Note 9)		 LED Support
(Note 10)
GAMEPAD ENCODERS (BUTTONS ONLY) (Note 11)
Gamepad Hack
(Note 11.1)		 $5 (USB)
$20+adapters (Playstation)		 14 (max)
Usually Matrix Buttons		 None No, (occasionally limited)
(Note 11.2)		 USB, Gameport Yes, for Playstation Pad Hacks Individual Bare Wires or Solder Points N/A No
GP-WIZ
GP-WIZ Max (Note 11.3)		 $20, solder Terminals
$23, IDE Header
$35, Max		 32 Direct Buttons
(Note 11.4)		 None No (Note 11.2) USB No Solder or IDE header (Std)
Terminal Strips (Max)		 No, Not needed. No
LPT Switch
(Note 11.5)		 $10 (Note 11.6) 60 Matrix Buttons
(Note 11.7)		 None Yes (Note 11.8) LPT Port
(Note 11.9)		 No Your choice No, Not needed. No
Interface Price (Note 1) Inputs
(Notes 2 and 3)		 Shifted Inputs
(Note 4)		 Programming
(Note 5)		 USB-PS/2-Other
(Note 6)		 Console Support
(Note 7)		 Connection Methods
(Note 8)		 Keyboard Pass-thru
(Note 9)		 LED Support
(Note 10)
GAMEPAD ENCODERS (ANALOG CONTROLS AND BUTTONS) (Notes 11 and 11.10)
Microsoft Sidewinder Dual Strike Gamepad Hack (Note 11.11) $5 to $15
(Note 11.12)		 2 Axes and
13 Matrix Buttons
(Note 11.13)		 6 (Note 11.14) Yes (6 buttons) (Notes 11.2 and 11.15) USB No Solder N/A No
AKI - Analog Kontrol Interface
(Note 11.16)		 $33 5 Axes and
14 Direct Buttons (Note 12)		 None No (Note 11.2) USB No Terminal Strips No, Not needed. No
A-PAC
(Note 12.1)		 $39 Configurable Between
4 Axes and 24 Direct Buttons to 0 Axes and
32 Direct Buttons
(Note 12.2)		 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)		 Shifted Inputs
(Note 4)		 Programming
(Note 5)		 USB-PS/2-Other
(Note 6)		 Console Support
(Note 7)		 Connection Methods
(Note 8)		 Keyboard Pass-thru
(Note 9)		 LED Support
(Note 10)
GAMEPAD ENCODERS (49-WAY JOYSTICKS AND BUTTONS) (Notes 11 and 12.4)
SJC - Simple 49-Way Joystick Controller
(Note 12.5)		 $33 1 49-Way Joystick and
10 Direct Buttons
(Note 12.6)		 None No (Note 11.2) USB No Terminal Strips No, Not needed. No
GP-WIZ49 Eco
GP-WIZ49 Max
(Note 12.7)		 $20 Eco, solder Terminals
$23 Eco, IDE Header
$35, Standard		 1 49-Way Joystick and
23 Direct Buttons
(Note 12.8)		 5 (Note 12.9) Yes (Note 11.2
and 12.10)		 USB No Solder or IDE header (ECO)
Terminal Strips (Std)		 No, Not needed. No
Interface Price (Note 1) Inputs
(Notes 2 and 3)		 Shifted Inputs
(Note 4)		 Programming
(Note 5)		 USB-PS/2-Other
(Note 6)		 Console Support
(Note 7)		 Connection Methods
(Note 8)		 Keyboard Pass-thru
(Note 9)		 LED Support
(Note 10)
KEYBOARD ENCODERS (Note 11)
TOKN KB16
(Note 12.11)		 $28
(Note 12.12)		 16 Matrix Buttons
(Note 12.13)		 None Yes
(Note 12.14)		 PS/2 No IDE Header Yes No
Keyboard Hack Free ;-), + solder and wire. 16-18 Useable Matrix Buttons (max), 107 Total Buttons
(Note 13)		 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)		 Shifted Inputs
(Note 4)		 Programming
(Note 5)		 USB-PS/2-Other
(Note 6)		 Console Support
(Note 7)		 Connection Methods
(Note 8)		 Keyboard Pass-thru
(Note 9)		 LED Support
(Note 10)
KeyDog
(Note 15.2)		 $80 (PS/2)
$80 (USB)		 24 Direct or 14x8 (104 Useable) Matrix
(Note 15.3)		 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
ButtonBox Approx. $30
(Note 18)		 27 Direct or Up to 128 (101 Useable) Matrix (Up to 8x16 Matrix) Buttons
(Note 19)		 None Yes, EEPROM (Note 20) PS/2 No Your choice. Yes Yes (Note 21)
Interface Price (Note 1) Inputs
(Notes 2 and 3)		 Shifted Inputs
(Note 4)		 Programming
(Note 5)		 USB-PS/2-Other
(Note 6)		 Console Support
(Note 7)		 Connection Methods
(Note 8)		 Keyboard Pass-thru
(Note 9)		 LED Support
(Note 10)
I-PAC/2 $39 (Standard)
$43 (USB)		 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)
$61 (USB)		 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 Spinner
(Note 22)		 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
(Note 29)		 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.4)		 None No PS/2 No Existing Hardwires Yes No
TOKN KB32
(Note 30.5)		 ??? (Note 30.6) 32 Matrix Buttons
(Note 30.7)		 None Yes
(Note 12.14)		 PS/2 No IDE Header Yes No
Interface Price (Note 1) Inputs
(Notes 2 and 3)		 Shifted Inputs
(Note 4)		 Programming
(Note 5)		 USB-PS/2-Other
(Note 6)		 Console Support
(Note 7)		 Connection Methods
(Note 8)		 Keyboard Pass-thru
(Note 9)		 LED Support
(Note 10)
KeyWiz ECO
KeyWiz STD KeyWiz MAX
KeyWiz ECO 2
KeyWiz MAX 1.5		 $27 (Eco, discontinued 17Nov04)
$34 (Std, discontinued 25Nov03)
$37 (Max, discontinued 25Nov03)
$20 ECO 2, solder terminals
$23 ECO 2, IDE header
$35 (Max1.5)		 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
(Note 36)		 28 (Note 37) Yes, SDRAM (Note 23) USB No Terminal Strips No, Not needed Yes (Note 25)
Hagstrom KE-USB36
(Note 37.1)		 $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)		 Shifted Inputs
(Note 4)		 Programming
(Note 5)		 USB-PS/2-Other
(Note 6)		 Console Support
(Note 7)		 Connection Methods
(Note 8)		 Keyboard Pass-thru
(Note 9)		 LED Support
(Note 10)
I-PAC/4
(Note 38.1)		 $65 (Standard)
$69 (USB)		 56 Direct Buttons
(Note 39)		 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 Direct Buttons
(64 With 4 Duplicates)		 None No DIN5 No IDE Header (groups of 8) No No
MK64 (Discontinued)
(Note 41)		 $63 64 Direct Buttons, or 52 Direct Buttons Plus Mechanical Rotary Joystick Support.
(Note 42)		 7 (Note 43) Yes, EEPROM (Note 44) PS/2 No IDE Header Yes Yes (Note 45)
Hagstrom KE-72
KE-72T		 $120 (KE-72)
$140 (KE-72T)		 72 Direct Buttons, KE-72T Also Includes a Trackball to PS/2 Mouse Port Interface None Yes, EEPROM
(Note 46)		 PS/2 No IDE Header Yes Yes (Note 47)
Interface Price (Note 1) Inputs
(Notes 2 and 3)		 Shifted Inputs
(Note 4)		 Programming
(Note 5)		 USB-PS/2-Other
(Note 6)		 Console Support
(Note 7)		 Connection Methods
(Note 8)		 Keyboard Pass-thru
(Note 9)		 LED Support
(Note 10)
OPTICAL INTERFACES (Note 48)
DIY Mouse Hack (Note 49) Free ;-), + solder and wire. 3 Matrix? Buttons
(Note 50)		 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
(Note 53)		 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)		 Shifted Inputs
(Note 4)		 Programming
(Note 5)		 USB-PS/2-Other
(Note 6)		 Console Support
(Note 7)		 Connection Methods
(Note 8)		 Keyboard Pass-thru
(Note 9)		 LED Support
(Note 10)
Hagstrom KE-USB36
(Note 37.1)		 $80 36 Direct Buttons + Trackball None Yes (Note 16) USB No IDE Header No, Not needed Yes (Note 38)
Hagstrom
KE-72T		 $140 72 Direct + Trackball to PS/2 Mouse Port Interface None Yes, EEPROM
(Note 46)		 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)
Opti-Pac $39 (Serial)
$43 (USB)		 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)		 Shifted Inputs
(Note 4)		 Programming
(Note 5)		 USB-PS/2-Other
(Note 6)		 Console Support
(Note 7)		 Connection Methods
(Note 8)		 Keyboard Pass-thru
(Note 9)		 LED Support
(Note 10)
ROTARY JOYSTICK INTERFACES (Note 57)
Direct Connection
(Note 58)		 ??? (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
Rdagger's Rotary Interface
(Note 60)		 $10 (Note 61) Requires 2 inputs per Joystick (Plus Directionals)
Controls two joysticks		 N/A N/A Same as Encoder N/A Your choice. Same as Encoder Same as Encoder
Druin's Rotary Interface
(Note 60)		 $25 Requires 2 inputs per Joystick (Plus Directionals)
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
MK64 (Discontinued)
(Note 41)		 $63 64 Direct Buttons, or 52 Direct Buttons Plus Mechanical Rotary Joystick Support.
(Note 42)		 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)		 Shifted Inputs
(Note 4)		 Programming
(Note 5)		 USB-PS/2-Other
(Note 6)		 Console Support
(Note 7)		 Connection Methods
(Note 8)		 Keyboard Pass-thru
(Note 9)		 LED Support
(Note 10)

NOTES:

(1)  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 purchase decision.
(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:

(41)  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 comparison (Aug03)
(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.)

GENERAL CONSIDERATIONS

This section will give an overview of the device types and the Specific Considerations section will deal with individual items related to arcade interfaces.

Gamepad Encoders

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.

Gamepad Encoder vs. Keyboard Encoder

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.

Gamepad Encoder Useful Software

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.

JoyToKey is available here.  A local mirror but possibly not the latest version is available here.

RBJoy is available here.  Setup instructions are available here, or included in the local mirror of the file (possibly not latest version) here.

USB Device ID's

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.

UPDATE:  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.

Gamepad Hack Info

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:

Gamepad Hack Emulator

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.

Analog Controllers

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.

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]

A 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.  DaveB has posted a way to do this on the AKI with an eight-way 8PDT switch on his wiring page (local mirror).  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 required connections (of course, you would wire to the outer edge of the terminal strips):
apac_gas-brake.jpg (47130 bytes)
(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:

49-Way Joystick Controllers

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.

Keyboard Encoders

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.

Optical Interfaces

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.

I will refer to Mame Analog Plus for version ID's, but some versions of NoNameMAME incorporated the analog plus code so the appropriate version of it could be used as well.

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:

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.

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.

Rotary Joystick Interfaces

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:

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.

SPECIFIC CONSIDERATIONS

Direct vs. Matrix Mode

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:

Now the disadvantages:

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.

Matrix-Mode and Swappable Panels

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!

Shift Keys

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. 

Programmability

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:

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:

USB Vs. PS/2 Mode

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.

Performance Issues:

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:

Other Considerations:

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:

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:

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.

Input Connections - Screw Terminal Strips vs. IDE Headers vs. Solder Points

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.

gpeco.png (71253 bytes)gpwizns.png (71726 bytes)gpmax.png (212855 bytes)terminalstrip.png (25362 bytes)

Here is how each one is used:

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:

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.

Keyboard Pass-Thru Alternatives

There are basically four workarounds if your encoder does not have a keyboard pass-thru:

Keyboard LED's

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.

ButtonBox LED Considerations

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:

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.

ButtonBox LED Wiring

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.

I-PAC LED Considerations

On all Ultimarc encoders with LED support, LED's are bi-directional with the following inputs:

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.

I-PAC LED Wiring

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):

I-PAC_LED_header.gif (5134 bytes)

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).

Additional I-PAC LED Considerations

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.

Hagstrom KE-72 (KE-72T) LED Considerations and Wiring

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.

Hagstrom KE-USB36 LED Considerations and Wiring

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.

MK64 (Discontinued) LED Considerations and Wiring

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.

MISCELLANEOUS CONSIDERATIONS

(All Encoders) Keys to Avoid - This is pretty much a hypothetical discussion at this point for the following reasons:

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.

A TALE OF THREE ENCODERS

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.

Level of Usage

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).

Software

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:

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:

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.

Operating System Compatibility

I decided to cover this separately as it is different from how the actual software works.

I-PAC Software Compatibility

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        
WinIPAC (DOS) (New) (Note 4)      
WinIPAC (DOS) (Old)        
WinIPAC MAC (New) (Note 5)      
WinIPAC MAC (Old) (Note 6)        
WinIPAC Linux        

NOTES:

(1)  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.

Usage

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.

Summary and Conclusions - If you thought you saw some duplicity (double-mindedness) in the earlier parts of this comparison, this section should definitely confirm that!

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.

MY RECOMMENDED KEY ASSIGNMENTS

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.

COMPARISON TABLE

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.


ENCODER Street Fighter
(20)		 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)                      
ENCODER Street Fighter
(20)		 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)

NOTES:

(1)  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.

HEAD-TO-HEAD

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.

KeyWiz vs. I-PAC/2

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.

KeyWiz vs. I-PAC VE

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.

KeyWiz vs. GP-Wiz

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.

I-PAC/4 vs. KeyWiz

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:

Terminals 1U,1L,1R,1D,2U,2R,2L,2D - Joysticks 1 and 2, as expected.
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)

Terminal SS4 - 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.

A-PAC vs. AKI

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.

OSCAR USB Mouse Interfaces vs. Opti-PAC

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.

Mini-PAC & two OSCAR USB Mouse Interfaces vs. Opti-PAC

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.

GP-Wiz49 vs. SJC

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.

GP-Wiz49 vs. KeyWiz

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:

KeyWiz Eco and 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:

KeyWiz Eco and two T-Stick Plus joysticks:  $23 plus $48.
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!

Mini-PAC vs. GP-Wiz or KeyWiz or I-PAC VE

$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.

Mini-PAC vs. I-PAC/2

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.

I-PAC VE vs. I-PAC/2

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.

GP-Wiz vs. I-PAC/2, I-PAC VE

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).

Dual GP-Wiz's (or KeyWiz/GP-Wiz) vs. I-PAC/4

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.

Druin's Rotary Interface vs. Direct Connection (GP-Wiz)

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.

A-PAC vs. GP-Wiz

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.

GP-Wiz vs. AKI

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.

CONCLUSION

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:

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.

EPILOGUE

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":

Category 1: Hummer H1, Ford Expedition XLT 4x4 V-10 Cummins Diesel, Any Ferrari, Ford GT, Ford Mustang GT (4.6L Saleen/Rousch/Cobra), 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.

Category 2:  Hummer H2, Ford Expedition Eddie Bauer 4x2 4.6L V-8, Any BMW, Chevrolet Corvette, Ford Mustang 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.

Parting Shots

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. . ."