TOKN KB16 REVIEW

NEWS/UPDATES:

6 July 05 - TOKNmedia continues to claim that I, Tiger-Heli, and RandyT (KeyWiz Designer) are one and the same.  Rather than waste your time commenting on the ludicrousness of this, I will just say that I will take that as a compliment and more praise than I deserve, and let you draw your own conclusions.

On a more positive note, TOKNmedia is now including a set of diodes free of charge with the KB16 encoder.  And their on-line documentation has been revised yet again.  The new documentation still mentions not using L Ctrl or Print Screen (???), but does mention staggering the action keys (as I mention below) and/or using diodes.  The wiring diagrams have also been revised to make show staggered inputs and/or diodes.  All of these are a welcome change from the misleading statements that were in the previous documentation.  I still feel that this page provides more detail in what the encoder will actually do and how to best utilize it, but at least now it doesn't conflict with the official statements.

It also shows that regardless of what TOKNmedia publicly says about my comments, they do at least take the time to read what I say and reap the benefits of it, as you should also.

25 Jun 05 - Initial webpage release.

SUMMARY/OVERVIEW:

Here are some pics, compliments of Retroblast (thanks Kevin), of the TOKN KB16:

My reviews tend to be wordy, so I figured I would start with my conclusions and provide the background later.  The TOKN KB16 is an 8x2 matrix-based keyboard encoder, featuring EEPROM, limited programmability, and an active pass-thru.  With some careful planning, the unit could be used for a classics control panel with one joystick and six action buttons or two joysticks and 2 action buttons per player.  With diodes on the switches, all 16 inputs can be used.  Overall, I am less than impressed with the performance of the unit for its price point, and cannot recommend it.  If you find a deal on one, or have a specialized need, it can work for you, but don't expect to just plug it up and go.

BTW, Mattp recently revised the readme file of the unit to recommend not setting any of the outputs to L Ctrl.  I see no evidence either that having an output set to L Ctrl causes any problems or programming the input to something else would fix any problems.

Disadvantages:  While not necessarily show stoppers, the unit has some fairly severe disadvantages.

Matrix/Ghosting -  This unit exhibits ghosting, i.e. if you press the Button 1, Button 2, and Button 3 inputs, the unit will also send a Button 4 input.  I have decided not to condemn the unit b/c of this, it can be overcome with diodes and is present on most matrix encoders (for example, the Hagstrom KE-24, KeyDog, the ButtonBox if it did not use diodes to overcome it, etc.)  I did feel that I needed to mention it, b/c the unit has been advertised as not using a matrix and not producing ghosting, and that is just untrue.

Useable inputs - Unless you use diodes, you are limited to eight non-ghosting inputs for action buttons.  This is about half the number of action buttons and 1/6 the number of total inputs of a well-planned keyboard hack, and 1/4 of the number of action inputs of the KeyWiz line of encoders.

Input Labeling - First, the unit is labeled like the I-PAC/2 with inputs for a joystick, 8 buttons, 1 and 2 P start, Coin 1, and Escape.  It works fine like this as long as you don't press more than two inputs at a time!!!  But this implies that you can wire it up like this and expect to use all sixteen inputs like you could on an I-PAC/2.  If you try this you will run into the ghosting nightmare I described yesterday.  In fact, even if you were to only use the joystick and four action buttons, you will still experience ghosting if you wire your buttons to the encoder as indicated by the labels.

Hot-Swappability - By specification, the PS/2 port does not support hot-swapping, but I have done it many, many times with both keyboards and the KeyWiz encoder with almost no problems.  The KB16 seemed to be pretty temperamental with this.

Price - This is, IMHO, the biggest drawback to the TOKN KB16.  As previously stated a well-planned keyboard hack will provide twice as many action keys for about $3 in solder, but there is the time factor, and you will not be able to select default keys, like you can with the KB16.  However, the unit is priced higher than the KeyWiz Eco, which is a much more capable unit.  I feel a fair price for the unit would be somewhere in the $5 to $15 range (before shipping), but don't know if they could be sold profitably for that.

Features:  Unfortunately, I only found two features to compensate for the disadvantages above:

EEPROM - The EEPROM is a nice feature of the unit.  You can program it to output any key you want and it will remember the settings.  Unfortunately, the method of programming the unit makes this a "Do it once, Do it right, and Leave It Alone" method, and the default layout make re-programming the unit almost a requirement.

Keyboard Pass-thru - The unit also includes an active keyboard pass-thru.  While I didn't have any problems with it myself, I was also unimpressed with the performance of it.

Conclusions/Usage: The unit has three main uses, although at the current pricing, it is hard to recommend it for any of these:

• The unit could be used for a solo Street Fighter style panel for classic or 2-player alternating games and for many classic shoot-em-up's like Twin Cobra, Top Gunner, 1943, etc.
• Buddabing from BYOAC suggested that the unit could be used as a separate controller for swappable control panels, with one KB16 on each panel.< /li>
• The unit would work fine as a jukebox controller or for any application that didn't require more than two inputs to be pressed simultaneously.

BACKGROUND AND DEFINITIONS:

History -  I was sent the review unit from Kevin Steele on 9Jun05.  Kevin was concerned b/c it performed well in his tests, but comments by it's developer and RandyT called his conclusions into question.  I volunteered to test the unit, mainly just to be able to say "Yes, it works fine" or "No, it fails miserably".  As the end of the test, I ended up, with "It has some really big problems, but is still useable, with care."  In hindsight, I feel I was probably one of the best (IMNSHO) people to perform the testing on it, b/c my extensive background with keyboard hacking and the scanning matrix that they utilize allowed me to quickly determine what the unit was doing and even make some recommendations to work around it's limitations.

First, I need to define some key concepts for people who may not be familiar with matrix encoders.

Ghosting - See http://www.dribin.org/dave/keyboard/ for details.  Ghosting occurs when three inputs that could form a rectangle on the matrix are depressed simultaneously, and results in an unintended "extra" keypress (the key that would form the square).  For example, looking at the TOKN matrix below, if we press Button 4, Button 7, and Button 8, we will get a ghost Button 3 output.   Ghosting can usually be prevented through the use of diodes.

Masking -  Masking is related to ghosting.  Basically, for the same reasons that the encoder thinks a key is depressed when it isn't, if you release one of the three keys depress the ghosted key, and keep the other two pressed, the encoder will not pick up the key release and will still show four keys depressed.

Blocking - Blocking is a technique used on most modern keyboards (not encoders, but physical keyboard), where firmware in the microcontroller detects when a combination of keys might cause ghosting and prevents the third keypress from registering.  The KB16 does not use blocking.  The disadvantage to blocking is that diodes can no longer be used to enable keypresses, so inputs must be carefully chosen.  The advantage is that you don't have to worry about a sequence of keys accidentally generating an Escape keypress and ending your game.

TESTING/USAGE/MATRIX:

The initial test was an attempt to verify that the unit could be used without ghosting problems.  It failed badly.   Subsequent testing enabled me to empirically determine the matrix used.  By empirically, I mean that I did not verify this matrix with a multimeter, but it did predictably model the behavior of the KB16 in all instances, so I am fairly certain that it is accurate:

GHOSTING IMPLICATIONS:

Obviously having keys pressed when you didn't intend them can have some serious effects.  The most critical would be a ghosted Escape output ending your game.  Here is an example of what can happen when we press Button 1 and Button 2 at the same time along with another input.  Note that similar interactions would occur with Button 3 and Button 4, Button 5 and Button 6, Button 7 and Button 8, and 1P Start and 2P Start, (and Coin 1 and Esc, or the joystick directionals if these were used for buttons and pressed simultaneously):

Pressing Button 2, Button 1, and Joy Down should produce a "ghost" Joy Up output.
Pressing Button 2, Button 1, and Joy Up should produce a "ghost" Joy Down output.
Pressing Button 2, Button 1, and Joy Left should produce a "ghost" Joy Right output.
Pressing Button 2, Button 1, and Joy Right should produce a "ghost" Joy Left output.
Pressing Button 2, Button 1, and Button 3 should produce a "ghost" Button 4 output.
Pressing Button 2, Button 1, and Button 4 should produce a "ghost" Button 3 output.
Pressing Button 2, Button 1, and Button 5 should produce a "ghost" Button 6 output.
Pressing Button 2, Button 1, and Button 6 should produce a "ghost" Button 5 output.
Pressing Button 2, Button 1, and Button 7 should produce a "ghost" Button 8 output.
Pressing Button 2, Button 1, and Button 8 should produce a "ghost" Button 7 output.
Pressing Button 2, Button 1, and 1P Start should produce a "ghost" 2P Start output.
Pressing Button 2, Button 1, and 2P Start should produce a "ghost" 1P Start output.
Pressing Button 2, Button 1, and Coin 1 should produce a "ghost" Esc output.
Pressing Button 2, Button 1, and Esc should produce a "ghost" Coin 1 output.

PROGRAMMING:

The unit lacks the ability to load a custom codeset from software.  It can be programmed using a keyboard plugged into the pass-thru port, but it is more of a "Do-it-once initially and forget it" type of operation.

There are some errors in the documentation, but once you figure it out, the unit is simple to program.

Here is what the TOKN Manual says about programming:

1) Open Notepad or Wordpad.
2) Press Arcade Button to View Current Assignment.
3) Press Scroll Lock to Enable Key Changes.
4) Press Keyboard key and Button simultaneously for two seconds. LED will flash solid when done.
5) Press Arcade Button to view New Assignment.

Here are my observations on programming the unit:

I was going to criticize the unit for basically needing the LED to program it, then noticed that the LED was directly between the two keyboard connectors, where it would be visible. Then found that I was fixating too much on trying to make sense of what the LED was doing and that I was more successful in programming the unit without looking at the LED.

Here is how to program it. Press and hold the desired arcade button. Press and release Scroll Lock on the Pass-thru keyboard and then immediately press and hold the desired input key on the pass-thru keyboard. Release after at least two seconds. Release arcade button. Verify results.

NOTE1: The LED will flash rapidly and dimly when you depress the arcade button, flash brightly at one Hz when you press Scroll Lock, flash rapidly and dimly again when you press the desired key, illuminate brightly for about a 1/2 second (indicating programming is complete) and then resume flashing rapidly and dimly. But again, I found it better to ignore it.

NOTE2: KeyScan would usually indicate that the input that the KB16 was previously programmed to was stuck following programming, but I didn't see evidence of this when I programmed the unit in Notepad, and I think this is just a flaw in KeyScan.

NOTE3: AFAICT, there is no way to map an input to "nothing" i.e. "None - Not used". I considered requesting this, implemented as a Scroll Lock and then double click, but later decided that it would probably be confusing as there is no way to display assignments on screen, so MattP would probably get a lot of support calls from users who did this accidentally and now thought they had dead inputs. What you CAN do is program unused inputs to KP1, or KP2, etc. or other inputs that will never be used by MAME™.

NOTE4: I don't agree with the approach Mattp took to programmability of the unit. I THINK his theory was to make the unit so it could be easily programmable one time to match your control panel layout, and then it should work with whatever software you are using. I prefer to have the unit easily programmable multiple times so I can use it with any software I want. In the end, it's a moot point as the number of inputs really limits this unit to MAME (or emulators that can be re programmed to use MAME defaults) and MAME will accept any inputs regardless. As it turns out, the programmability ends up being a required feature if you want to use MAME defaults, as you cannot use the inputs as laid out without severe ghosting.

HOT-SWAPPING:

The PS/2 spec does not officially support hot-swapping, and it was problematic on the TOKN KB16.  When I first started the PC and hot-plugged in the KB16, the PC immediately went into suspend or shut down mode (monitor went black, CPU fan shut off, but PS fan was running). I shut off (rear switch) the PS, unplugged it, plugged it back in and re-booted and everything seems to be okay.   Afterwards, I hot-swapped the unit several times without problems.  I would estimate I hot-swapped the unit about 10-12 times and had some problems twice.  I am not sure why because I routinely swap keyboards and another PS/2 encoder on this PC and haven't seen similar issues.

PASS-THRU:

I typed about half of my initial review using the keyboard pass-thru. I noticed especially that holding down the space bar or arrow keys to get to a point in the document took longer when using the pass-thru. Even typing seemed slower thru the pass-thru. Part of this might be explained if the unit disables key-repeat on the pass-thru, but not all of it. I ended up plugging the keyboard back into my USB converter to type as this reduced the lag time. My point here is if the pass-thru is having trouble keeping up with a standard keyboard, I can't see it doing well with a second KB16, or especially with up to 8 downstream KB16's like Mattp specifies.

Another BYOAC member (jjd) saw very erratic behavior with the pass-thru on a KB32 encoder, but I did not experience this.

On a personal note, I use a PS/2 keyboard hooked up through a USB converter and a PS/2 encoder in my personal set-up, and found no reason to use the pass-thru, and also found it inconvenient to have to unplug my regular keyboard and plug it into the pass-thru to program the unit.  However, these are personal observations unrelated to the usability of the pass-thru.

Finally, Mattp initially included this in the readme file for an early 4Dec04 KB16.  I don't know if it still applies and I did not test for it with my test unit.

------------------------------------------------------------------------------
Known bugs firmware 0301
------------------------------------------------------------------------------
Passthrough key sequences of simultaneous shift-ctrl are not received correctly. As a result KB16 will occasionally not transmit the ctrl to the PC. This only applies to passthrough and does not affect gameplay.

***

I went back tonight, 23Jun05, and tested this and I do not see any of these effects on my KB16.  All I can speculate is that perhaps Mattp has a keyboard which exhibits blocking and the Shift-Ctrl problems that he is seeing would occur in normal windows as well as through the pass-thru, but this is purely a guess on my part.

NUISANCES:

For some reason, USB devices (noticeably my thumb drive, but also my joystick) do not seem to be detected if I connect them with the KB16 plugged in. If I unplug the KB16, and plug them in, they are detected again and work fine. No idea why, but it's happened often enough to not be a coincidence.

RECOMMENDED SETTINGS:

The input labels are terrible on the KB16.  There is no way without diodes that you can support 8 buttons with this encoder (see below for a diode solution), and if you wire it up per the defaults, you are almost guaranteed to have ghosting problems.  Fortunately, the labels are just guidelines and you can wire any button to any input and re-program the unit to support this.  Below is my proposed matrix layout for an 8x2 matrix encoder.  Using this matrix, you can use the aqua and green buttons for a single joystick and 6 button Street Fighter panel with no ghosting of the input keys.   You can use the aqua and yellow buttons for a two joystick, two button each panel, again with no ghosting of inputs keys.  You could also wire up both the yellow and green buttons to the same inputs, which would allow you to play both 2-joystick and SF games on the same panel.   (You would have to choose whether to use Mame single player or MAME dual player inputs for the defaults and then re-configure either your 2-player or SF MAME games to match).  The red buttons are for admin functions and will cause ghosting if pressed with certain other keys, more on that below.  The pink buttons are admin functions available on the 1 Player Panel, but I don't recommend using them.

Here is how you would implement this on the TOKN KB16 - Unchanged inputs are shown in white - reprogrammed inputs are shown in yellow.

GHOSTING RE-VISITED:

While ghosting is undesirable, I think we probably have over-rated the likelihood of it coming into play. My biggest concern with ghosting would be situations where a combination of inputs would result in a phantom Esc press and end the game. However, with careful planning, you can ensure that this almost never happens. Laying out a conservative 2P layout (as I have above), this could happen with this unit (after re-mapping inputs) whenever 2B2 is depressed along with 2B1 and 2P Start; 2B2 is depressed along with 1B2 and Coin 1; or 2B2 is depressed along with 1B1 and 1 Player Start. I know a lot of people complained about the I-PAC exiting when people pressed 1P Start and 2P Start at the same time. I personally had MAME mapped so ESC was "1&2" and had a game exit on me. But these are two keys that are fairly likely to be pressed at the same time. A three key combo is MUCH less likely to happen. Look carefully at my example above - in case 1, Player 2 is unlikely to be pressing P2B2 at the same time he is pressing P2 Start to start a game. In case 2, if either player is out of coins, they are unlikely to BOTH be pressing Button 2 while one of them pressed the coin credit. In case three, Player 1 is unlikely to be pressing P1B1 at the same time he is pressing 1P Start to start a game.

CAVEAT 1: The matrix is not layed out like this by default, and you have to be careful in assigning inputs to it. For example, in my first shot at it I had phantom Esc's being generated by a combination of P2B2, P2B1, and Coin1. This actually could easily happen in gameplay.

CAVEAT 2: I have only looked at ghosted Esc keys, because this is the one situation that will make you want to open the panel and take a sledgehammer to the KB16. You also have the same potential for generating Ghosted Credits, Start Button presses, and action keys whenever an admin button is depressed, but these are less troublesome. However, I mention this because in the one player scenario, you could add two more admin buttons (with the most likely being Pause and Tab) but if these are ghosted, they could get annoying also.

In the two-player alternating or one-player scenario, this is even less likely to come into play, because you typically have no reason to press Coin or Start while mashing an action button. However, if you utilize the additional available inputs, you increase the potential for ghosting.

So while this is an undesirable effect that would be nice to avoid, I don't know that it needs to be demonized as much as it often is.

THE DIODE FACTOR:

Again http://www.dribin.org/dave/keyboard/ does a nice job of explaining this.  I have not tested this (nor do I plan to), but I would fully expect it to work with the KB16 and allow you to use all inputs with no worries about ghosting.  Sixteen diodes would be required at an approximate cost of $1.60 total.  I am not authorizing you to do this, and take no responsibility if you damage your KB16, your computer or anything else trying to implement it.  However, if you do get it to work, please tell me how you did it and I will update this page so others can follow along.

What I can say from my experience with keyboard hacks and from looking at Dave Dribin's page is the following:  Only one diode per input is required.  It doesn't matter whether COM on the microswitch is connected to the lower (near the labels) and NO is connected to the upper row of pins on the KB16 IDE header, or vice versa.  Diodes are directional, but if they are connected the wrong way, the input won't register at all.  On Dave Dribin's page, diodes are connected to the row terminals, with current flowing from column to row, but they could be connected pointing from the row terminals and the circuit would work as well.

Unfortunately, we don't know the flow path of current on the KB16, but we can use some the statements above and make some inferences.  As a guess, I would expect the following to be the most likely situations (in order of likelihood, first answers being most likely):

• Diodes should be connected between the switch and the lower row (nearest the labels) of pins on the IDE header.  The current should flow toward the bottom row (diode stripe should be nearest the IDE header).
• Diodes should be connected between the switch and the lower row (nearest the labels) of pins on the IDE header.  The current should flow from the bottom row (diode stripe should be nearest the switch terminal).< /li>
• Diodes should be connected between the switch and the upper row (furthest from the labels) of pins on the IDE header.   Diodes should just be positioned to allow switch presses to register.
• There is a slim chance that diode position would need to alternate between upper and lower header rows, but I would still think that whatever position allows the switch closure to register will also prevent ghosting.

DISPELLING MISCONCEPTIONS:

Before I give my conclusions on the unit, I would like to address some things you will probably read elsewhere about this review.   First of all, this review has only two purposes: 1) To point out with the KB16 can (and cannot) do so potential users can make an informed decision before purchasing one.   2) To provide helpful information to those who have decided to or have already purchased the KB16 so they can use the unit up to its fullest potential.

You will likely read articles from Mattp stating that this page is an attempt by a KeyWiz supporter to denigrate the KB16.   That is not the case at all.  I initially thought that Mattp was making true statements, and the unit would work without ghosting.  It doesn't.  But I would like Mattp to consider this:  If my stated goal were solely to help the KeyWiz and discredit his product, why wouldn't I have just published my full test results and not mentioned the diode solution or alternate ways of wiring the unit to avoid the inherent ghosting problems.

Also, this page is not meant as a personal attack on Mattp, although I do dislike what I perceive as inaccurate marketing by him.  Mattp has made some personal comments on the BYOAC website about me, but he doesn't know me very well, and the members there who do know me were quick to come to my defense and, frankly, were more upset over it than I was.

Mattp has also made some thinly veiled comments about the testing method I employed, referring to "unqualified individuals out there creating their own test fixtures and publishing their own test data".   This isn't rocket-science.  I'm not sure how qualified you have to be to wire up a keyboard encoder and see what outputs are produced.  I didn't include the full test results here, b/c I didn't see much purpose in it, but they are available on BYOAC.   What I did was use motherboard jumpers to simulate a pressed key rather than actually wiring up switches to the encoder.  The fact that the unit worked as expected when only one or two jumpers were connected, produced ghosting when some combinations of three jumpers were connected, and could have eight jumpers connected without ghosting if jumper position were carefully chosen, verifies to me that the testing methodology was correct.  For those that are doubters - note that I didn't just post that I didn't think the unit worked well, I posted that I closed these SPECIFIC inputs and got these SPECIFIC results.  That is a pretty easy claim to refute if it is inaccurate, but it has since been verified both by KevSteele (exact verification using different testing software on a different KB16 board) and by jjd (similar results on a KB32).

Unlike other members of BYOAC, I don't dislike matrix mode, in and of itself.  Many encoders (Hagstrom KE-24, KeyDog, ButtonBox, LPT switch, and any keyboard hack) use (or can use) matrix mode and work well with it.  The problem I have is that the KB16 will exhibit ghosting (as will many of the MATRIX MODE encoders) without the use of diodes, but Mattp goes out of his way to try to deny this.  Other problems with matrix-mode are that you cannot use Perfect 360 joysticks or Druin's Rotary Interface with it, but that is probably not a real drawback for the KB16.  I think there is a performance loss between matrix mode and direct mode, but it's similar to choosing to drive a Ford Focus instead of a Ferrari to go to the grocery store, i.e., the extra performance is not needed/useable in the majority of situations.

Many readers may be surprised that I list EEPROM as an advantage to the KB16, given how outspoken as I am about the KeyWiz line of encoders, which use SDRAM.  Fact is, all things being equal, EEPROM is preferable to SDRAM.  In the case of the KeyWiz and the I-PAC VE, four additional inputs outweigh the loss of EEPROM, IMHO.  While EEPROM is a nice feature, it is mainly advantageous if you plan to hot-swap the unit (which the PS/2 specification does not officially support), and even then is unnecessary if you have a well thought out default layout, or use emulators that allow re-mapping of inputs in software.

Finally, I do understand the concept and the target market for the KB16.  I think there are more BYOAC'ers building 4-player FrankenPanels™ that will never see more than two players than building one or two player panels for 80's classic games only, but there are some out there.  And a good many of these people don't want to shell out $45.00 for an I-PAC or a KeyWiz Max for these small projects, and also lack the skills or don't want to be bothered with hacking a keyboard.  The problem is most of these people also don't want to shell out about $30.00 for a KeyWiz Eco non-solder or GP-Wiz32 Eco non-solder, and if they did decide to do that, I don't see them spending that same amount of money for half as many inputs, ghosting, an EEPROM, and an active keyboard pass-thru.

FINAL WORDS:

The TOKN KB16 has a few nice features, but I can't see the advantages outweighing the disadvantages and as of this time (23Jun05), I really can't recommend the encoder.

Advantages:

EEPROM:  Normally, I would gloss over EEPROM.  It's a nice feature to have but not something I would base my decision on.  However, in the case of the KB16, since you are REQUIRED to re-program the unit if you want to use it with MAME defaults without ghosting of the action keys, and without diodes, it is good that the unit has it.

LIMITED PROGRAMMABILITY:  This is one thing that distinguishes the unit from a keyboard hack.  The keyboard hack will actually have more available action keys, but you will never get a keyboard hack to use all MAME defaults.  And again, the programming comes in handy, because you cannot use the default inputs without ghosting or diodes.

SIZE:  The unit measures approximately 1.75 inches wide by 2.25 inches long, by about 0.625 inches high, so it is a very compact unit.

IDE HEADER:  The IDE header is very convenient for connecting and disconnecting multiple panels, although the same could be said for the KeyWiz Eco and the GP-Wiz32 Eco or MiniPAC encoders.

KEYBOARD PASS-THRU:  I consider this one of the most highly overrated features of an encoder, but lots of BYOAC'ers tend to really like it.  While the KB16 incorporates this feature, I found it to be extremely sluggish, and another BYOAC member found it to be unreliable.

Disadvantages:

DECEPTIVE MARKETING:  This is IMHO, the unit's biggest flaw.  I can handle that the unit has ghosting if you don't use diodes, most matrix-mode encoders do.  I can deal with the over-ly ambitious pricing, the market will ultimately determine the unit's worth.  The input labels are just letters on the PCB and can (must) be ignored.  But the product should be marketed as what it is.  Technically, I can't say that Mattp is purposely deceiving people or lying about the product.  I don't know his motivations and I don't know that he is aware the unit will not do what he says.  I do know that he is stating often contradictory and inaccurate statements about the product.  Here are some excerpts (yellow text) and I will let you decide if this is who you would like to buy your encoder from.

Mattp recently posted this on the BYOAC website in a thread asking about the KB16:

All,
The TOKN KB16 is not implemented in what would be called a traditional keyboard matrix.   There is no row and column scan or search and there are also no ghosting issues. No diodes are needed nor used.  Rather it is a two ground multiplex with high speed interleaved byte latching on a single microcontroller port.  Very effective and very fast for getting port status to the microcontroller and keycodes to your game session. These are details that the user need not worry about. Its just an implementation detail that is unique to the TOKN KB16 encoder.  Hopefully someone will do some benchmark tests in the near future. Now that would be interesting. Hey Mr. Kevin Steele, do you own a square wave generator that can simulate some high speed button mashing?

RandyT later responded to this post with the following:

Sounds impressive. But you just described a traditional keyboard matrix.

I don't have one of your products, but based on the descriptions you and others have given, it sounds like the 8 inputs are doubled (read: connected to a total of 16 pins on your header) and then you have 2 "ground" lines (which aren't always ground.)

If you are alternating high and low on those two "ground" lines (columns) and checking for a specific result at one of the other eight (rows), then you are indeed using a traditional keyboard-style matrix. And if this is so, and you are not employing firmware methods that block certain keypresses, or using diodes to prevent backfeed, then it would seem pretty likely that there would be potential ghosting problems.

There are only so many ways to skin that cat, are you saying you've come up with a new one?

RandyT

To which Mattp replied:

Thank you Kevin. To answer Randy-Helis question, yes the design approach can be referred as a 2x8 matrix.   This was a conscious design decision that required design and test to get it right. Keep trying to angle this as a downfall and you will fail. Your own comments regarding the validity of a matrix implementation that ten billion keyboards across the planet employ followed by open speculation are without merit.  Passthrough was and is a challenge.   TOKN stepped up to that challenge.  You side stepped that challenge and threw in a toggle switch as a band-aid.  Speculate all you want and bash TOKN until you are blue in the bicep.
Mattp

So we can now infer that it uses a matrix, but somehow not a traditional one.  I pointed out that AFAIK, 95% of the ten billion keyboards either employ blocking, ghosting, and/or a pressed key maximum and cannot easily be used for gaming (not that matrix mode is inherently bad, but it does limit your inputs or require diodes).  And the speculation at the time regarding ghosting has now been confirmed by at least three evaluators.

The next day, Mattp cross-posted this in this thread and two other threads referring to the TOKN KB16 (the only threads on the board about it at that time):

Saint,
This group of threads was launched by a registered user of your forum with the primary intent of denigrating a competitor's product. This type of sleaze marketing is common and unfortunately a gross misuse of public domain.

See this link to an internet marketing newsletter that summarizes these practices. http://www.apexpacific.com/newsletters/nl2004apr.html

I'll close by stating that I'm leaving it up to the mediator of this forum and those involved to examine the user profile registration dates and thread contents for signs of this type of abuse.

This was, IMHO, a deliberate attempt to get negative comments about his product out of the public eye where they could not be seen and would not show up in a search.

Around 21Jun05, Mattp added the following to his E-bay advertisements:

"In an effort to keep the general public well informed about the speed, performance, and reliability of Tokn Media's line of encoders, we've published the readme doc that is part of the documentation distributed to each paying customer on the toknmedia website. Reading these docs goes a far way in getting the best out of your purchase. Be sure to check it out. 16 simultaneous keypress supported. No ghosting, no delays, no stuck keys. We make this claim in no others terms but absolute. Others won't, other can't. Check one out. Cheers, Mattp Tokn Media"

Perhaps diodes have been built-in to units shipping after 21Jun05, but the unit I tested, the unit RetroBlast tested, and the unit jjd tested ALL exhibited ghosting.  It can be compensated for, but it's there.

BTW, here is the pertinent part of the "docs" that Mattp wants users to read:

Restricted Keys Note -
This release of the firmware has a restriction on the use of two keys, Ctrl and Print Screen. Print Screen is not supported at all. Ctrl key usage is supported but not in conjunction with other keys. It can be used as an administrative key but it can not be used for player 1, button 1 gameplay which is the default for some gaming emulators. The workaround is to assign some other alpha numeric key to P1 B1. Unpredictable keycodes will result if this key restriction is not observed. Plans are in place to support this in future releases.

It's hard to know what to do with this!  It's unusual for me to have to point out to Mattp that his unit does NOT have problems that he is claiming it does.  I hadn't tested this earlier, but RetroBlast did test the Ctrl key, and found no effect on the ghosting problems regardless of whether Ctrl was depressed or not.  Not wanting to rely on someone else's test when I had a working unit in front of me, I decided to test these claims out.  When I had previously finished testing the unit, I had reprogrammed it so that L Ctrl was not used.  I shorted Button 1, Button 2, and Button 3, and got the expected "ghost" Button 4.  I then removed the jumpers and shorted Button 5, Button 6, and Button 7, and got the expected "ghost" Button 8.  I then shorted the Esc input, pressed Scroll Lock and released it, and pressed and held Print Screen and released it.  KeyScan correctly showed that the Esc Input was now programmed to and generating Print Screen outputs.  I then tested by shorting and releasing the input, and then opening IrfanView and hitting Paste and verified that the image displayed was the same one that I was looking at when I shorted the Escape input.  I also verified that Print Screen worked correctly on the attached keyboard on the pass-thru port.  It did.

Again, all I can do is offer some pure speculation.

Regarding Print Screen, it is possible that either Mattp or a customer was thinking back to the earlier DOS days when pressing Print Screen would actually send the screen contents to the printer.  Since at least Windows 95 (maybe Windows 3.1), Print Screen has only sent the screen comments to the clipboard.  I halfway expected the Printer dialog to come up when I was trying to verify the output was useable in something other than KeyScan, and then remembered that it only sends to the clipboard now, so maybe Mattp just thought it wasn't doing anything when it really was.

The Ctrl key explanation is much harder to get a handle on.  All I can come up with is either Mattp really doesn't understand why the unit produces ghosting, and is thinking that Ctrl combinations have something to do with it, or he knows exactly why it produces ghosting and is hoping that if he puts out some excuse, people will continue to purchase the units.  I'm not comfortable with either answer, but it's all I can conjecture for now.

GHOSTING:  Again, I don't want to harp on the ghosting.  It exists, as it does on most matrix encoders.  It can be controlled through either diodes or careful selection of inputs.  The only point is potential purchasers of the KB16 need to be aware that the unit does produce ghosting.

PRICING:  In hindsight, I think Mattp may have been blindsided (like most of the gaming industry) by the introduction of the Eco line of GroovyGameGear encoder (especially the no-solder versions).  Prior to this, a $25 KB16 would be able to steal a good percentage of the small cabinet market from the $35 KeyWiz Max or the $39 I-PAC.  With the release of the non-solder KeyWiz Eco at $23, the KB16 really needs to be in the $5-$15 market price.

INPUT LABELING:  The input labeling on the KB16 is terrible.  I think the unit was designed to copy a 1-player version of the I-PAC 2 with an added Escape key, but there is no way an 8x2 matrix encoder can support a joystick and 8 buttons without diodes.  Even if it could, there are no eight button games, so it's just silly.  To me, it couldn't matter less (especially with a programmable encoder).  You can label the input Rumplestilsken and if I want I will connect P1 Button 4 to it and reprogram it to L Shift and all will be right with the world.  But I have seen BYOAC'ers recently picking the I-PAC/2 over the KeyWiz b/c the input labels seemed easier to hook up, so I can see the easily understood labels being attractive to inexperienced encoder purchasers, which is bad as you definitely do not want to wire the KB16 up as indicated without the use of diodes.