TOKN KB16 (Tiger-Heli's Testing Complete)

[Tiger-Heli]

FINAL TESTING COMPLETE (unless I get bored . . . )

PROGRAMMING REVISITED:  I figured out how to program the unit, and it works well once you get the hang of it.  Mattp

[SirPeale]

Now who's improperly using the <me> tag. 

That's because that's not the <me> tag, that's just a symbol of the gesture I'm making.

[Tiger-Heli]

Now who's improperly using the <me> tag. 

That's because that's not the <me> tag, that's just a symbol of the gesture I'm making.

Yes, but shouldn't the tag have been used so it said:

* Peale raises hand!

?  Mainly I'm just razzing you back, though!

[SirPeale]

Yes, but I didn't speak of myself in the third like you did.  I just gestured. 

[saint]

Now now, this is a family forum - mind those gestures!

Yes, but I didn't speak of myself in the third like you did.  I just gestured. 

[timsteward]

First time posting here.
I just wanted to put in my 2 cents worth.
The tokn 16 encoder I use has never messed up once.
The program on the fly option is the formost reason I started buying them.
I use them on classic arcade machine that the boards have went out and it cost so much to repair them, it just makes it easier to replace a computer power supply or hard drive if it goes bad than try and replace the old PCB on the arcade machine.
I have gotten nothing but great customer service from the folks at tokn.
The price is awesome with the flat rate shipping on multiple items.
I have used the I-Pac as well and like it.
But for the money and the program option I am sticking with the tokn16.
Thanks for listenting.
Tim

[monkeybomb]

Tim - What exactly is the application you are using them for, and how many buttons are simultaneously pressed?

[Tiger-Heli]

The tokn 16 encoder I use has never messed up once.

I appreciate your input, but I would like to speculate for everyone else.  Most likely - You have never NOTICED that the KB16 messed up once.  There is a difference.  Let's say you put this in a GunSmoke cab.  You mash Button 1, Button 2, and Button 3.  The TOKN also sends a Button 4 keypress.  No Problem - GunSmoke only uses 3 buttons.  Or in a 1942 cab, your only potential problems would be if Button 1 and Button 2 were pressed at the same time, and the game will rarely require this (if ever).

The program on the fly option is the formost reason I started buying them.

This seems hard to believe.  When would you use it?  If it truly works as advertised like you say and you are using it for MAME, you should be able to just wire it up and not program it at all.  If you are doing what I suggested and re-assigning inputs to avoid ghosting, than it is necessary, but you can do the same exact thing with an I-PAC.  (And programming a KeyWiz is pretty easy, but you will need to launch the KeyWiz software at start-up if you use a non-default codeset.

[Tiger-Heli]

Some more thoughts:

I have actually enjoyed testing the KB16 encoder.  It is basically somewhat less than half of a keyboard hack, but programmable so you can select the default MAME keys.  Since I am familiar with keyboard hacks, it is interesting seeing how the device works and what its limitations are.  (After all, anyone can wire up an I-PAC to the default keys and plug it in and play with no thought whatsoever, how is that fun?).  As far as design of a matrix based keyboard encoder, on a scale of 1 to 10, 10 being the best, I would give the KB16 about a 2.0 on the maturity and robustness scale.  Details on that below, first some definitions:

Ghosting:  When three keys that form a rectangle on the matrix are depressed, the input that completes the matrix may also be triggered.  The KB16 demonstrates this in that if you depress Buttons 1, 2, and 3, the Button 4 output is also generated.

Blocking:  Blocking is a firmware fix for the ghosting problem.  It is very common in modern keyboards.  It is not incorporated on the KB16.  Were it incorporated, then if you depressed and held Button 1 then Button 2, then Button 3, Button 3 would not register as it would generate a ghost Button 4.  Blocking can be either your friend or enemy in a matrix encoder, as I will explain later.

Now these are basically the steps in laying out a well-planned matrix mode encoder (and how I came up with the 2/10 rating) -

Step 1 is determining what keys you can support.  As I have said, an 8x2 matrix works for 1 joystick and six buttons.  Mattp has buttons numbered from 1-8, so either he failed to take this into account or he figured he would allow Buttons 7 and 8 to be included, knowing that they would produce ghosting.  Judging by the rest of the board, my guess is he failed to take this into account.

Step 2 is laying out the matrix to place opposite joystick directionals in the same column on different rows.  Mattp does this, but given his other choices, I think he just took the inputs order from the I-PAC and just added them to the matrix in order.  In other words, I suspect he lucked into this rather than it being a conscious decision.

Step 3 is to assign primary keys to the matrix so that they will not generate ghost inputs when used.  Mattp did not do this, but I have posted before how it can be fixed on the KB16.

Step 4 is to determine whether or not you want the encoder to use blocking.  Mattp chose not to.  Given his choice of layout, this was a good decision, as blocking would have prevented the third button from being pressed with buttons 1 and 2, which would be more annoying than a phantom Button 4.  Had he laid out the matrix more logically, I would recommend blocking.  The reason is the admin keys.  If you are using Esc as one of your admin keys, without blocking, there is a possibility that a coin press, and two action buttons will generate a phantom Escape and end your game.  OTOH, if blocking were incorporated, then the only drawback would be that your admin keys might not register if one particular action key and some other key were depressed at the same time.

Step 5 is to use diodes to prevent all of the ghosting and masking problems altogether.  Mattp did not do this.  It might have been a cost-savings measure, or more likely, he did not understand it well enough to implement it.

Having said all this, I also need to point out that it is much easier to Monday-morning quarterback the finished design than it is to develop it, and I can

[Tiger-Heli]

Just thought that as I point of contrast, I would mention an E-mail exchange I had with the KeyDog support team before adding it to the review, quoting here:

***

TH:  Most matrix-mode encoders will exhibit some form of ghosting, blocking,
or masking if multiple keys are pressed, unless diodes are employed on
the input lines (see http://www.dribin.org/dave/keyboard/ for a
technical explanation of this process).  This would rarely be a problem
for a flight sim, but could be a big deal for an arcade controller,
where it is theoretically possible to activate 16 keys at the same time.
Does the KeyDog prevent ghosting, or is it up to the user to utilize
diodes in their wiring to prevent this?

KD:  In the matrix mode, you need external diodes to implement multi-key rollover.  If the keys pressed use 2 common lines then the diodes are needed.  However if use of the keys is selected so that keys only have common rows, or common columns but cannot have common rows and columns multi key rollover does not require diodes.

***

They meant inhibit rather than implement, but the answers were clear and concise.  Mattp would have done well to follow there example, rather than claiming the unit did not exhibit ghosting, and then claiming it did not use a matrix. . .

[KevSteele]

Just an FYI:

I've revised my review, thanks to another TOKN16 donated by Monkeybomb(thanks, dude!)

http://www.retroblast.com/reviews/tokn16.html

I encountered the same exact problems as Tiger-Heli with this encoder. It's basically useless for MAME (or at least, for any game other than Pac-Man).

Don't have any real excuses, unfortunately: I tried to rush out a couple of reviews and royally screwed up this one. 

Thanks, Tiger - I appreciate the perseverance and testing.

Kevin

[CheffoJeffo]

Was just looking at the TOKN website after reading Kevin's revised review ... is this document new (I don't recall seeing it when I looked before)?

http://toknmedia.com/downloads/toknkb16_readme.pdf

There is a pretty big disclaimer that states the the Ctrl key can not be used in conjunction with any other key and that the P1B1 should be remapped to something other than Ctrl. The document suggests that future revisions to the firmware may correct this problem.

Hmmm.

Cheers.

[KevSteele]

Was just looking at the TOKN website after reading Kevin's revised review ... is this document new (I don't recall seeing it when I looked before)?

http://toknmedia.com/downloads/toknkb16_readme.pdf

There is a pretty big disclaimer that states the the Ctrl key can not be used in conjunction with any other key and that the P1B1 should be remapped to something other than Ctrl. The document suggests that future revisions to the firmware may correct this problem.

Hmmm.

Cheers.

I guess I need to revise my revision to include this detail: I tested with and without the Ctrl key mapped to button 1, and was able to easily reproduce the ghosting with or without the Ctrl key. It made absolutely no difference in the ghosting problem in my testing.

It's amazing to me how many 3-key combos will cause ghosting on this device - I tried all sorts of combos, and I'd guess 75-80% of the three-key combos I used cause ghost keys.

Kevin

[JMDickson]

At this point, I removed all the jumpers, closed KeyScan, and repeated the test, this time using GhostKey.  I only ran down to about Button 6 and stopped because I was getting IDENTICAL results.

Wow, someone is still using that old thing?  If a key counter would be a useful addition, I'm sure I could scrape up the source and add one.  In fact GhostKey is long overdue for a transition to windows... one more project to add to my list.

[KevSteele]

At this point, I removed all the jumpers, closed KeyScan, and repeated the test, this time using GhostKey.

[Tiger-Heli]

Just an FYI:
I've revised my review, thanks to another TOKN16 donated by Monkeybomb(thanks, dude!)
http://www.retroblast.com/reviews/tokn16.html

Kev,

Thanks for updating the review.  It's much more accurate now (IMHO).  One downside is I think you only updated the testing and conclusions, so the intro stuff sounds pretty positive until you get to the end.

I will be formally writing up my conclusions on the unit and adding them to my encoder comparison.

I encountered the same exact problems as Tiger-Heli with this encoder. It's basically useless for MAME (or at least, for any game other than Pac-Man).

Actually, I think that's a little bit harsh, but maybe not uncalled for given the IMHO poor design and deceptive marketing of the unit.

The unit is only supposed to suppport one joystick and 3-4 buttons or 2 joysticks and 2 buttons each.  It CAN do this if you don't wire it up as labelled and if you then re-program it.

My main problem with the unit is that it costs more than some true 32-input encoders, and it is marketed like it will never exhibit ghosting, which it definitely will if you don't use diodes.

(And yes, it does seem ironic to me that I'm here defending the device after Retroblast basically trashed it !!!!) 

[CheffoJeffo]

Thanks for the update (re: Ctrl), Kev.

Cheers.

[Tiger-Heli]

Was just looking at the TOKN website after reading Kevin's revised review ... is this document new (I don't recall seeing it when I looked before)?

http://toknmedia.com/downloads/toknkb16_readme.pdf

There is a pretty big disclaimer that states the the Ctrl key can not be used in conjunction with any other key and that the P1B1 should be remapped to something other than Ctrl. The document suggests that future revisions to the firmware may correct this problem.

Hmmm.

Cheers.

Whoa!!! That's scary in a number of ways.  Mattp sent me a copy of toknkb16_readme.pdf, circa 01 Dec 2004, and it doesn't mention this at all.

It did mention this, which is NOT in the new document:

------------------------------------------------------------------------------
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 didn't verify the above, but if MattP mentioned it, it is probably accurate (I don't think he would make up faults to document), and unfortunately, probably still applies to current units.

Anyone who understands a matrix encoder could confirm (as KevSteele has) that the ghosting has nothing to do with the P1B1 assignment.  You can press Button 3, Button4 and Button5 and you will get a phantom Button 6 keypress, so how could P1B1 being assigned to L Ctrl have anything to do with it.

It sounds like Mattp has either read these posts or gotten feedback from customers about the ghosting problems and is trying to put something out to address it.

The part I don't understand is:  Does he REALLY not understand his own product well enough to think that this might be helpful?  Or does he know that it won't make a difference, but figure that people will assume that that is what is causing the ghosting and therefore continue to buy KB16's?

What really frustrates me, as I said earlier, is that all he really needs to do is the same as most other matrix encoder manufacturers do and say that the unit uses an 8x2 matrix and will exhibit ghosting if you don't choose inputs carefully or use diodes.

[Tiger-Heli]

It's amazing to me how many 3-key combos will cause ghosting on this device - I tried all sorts of combos, and I'd guess 75-80% of the three-key combos I used cause ghost keys.

Kevin

Kevin,

It's an 8x2 matrix encoder, which means it can support 1 joystick and six buttons.  Want to have some fun with it?

Wire up the joystick as indicated, and wire a button to Button 1, Button 3, Button 5, Button 7, 1P Start, and Coin 1.  You should be able to press any button in any combination with no ghosting or problems whatsoever.

The downside:  Wire up a button to Escape, and a button to one of the remaining inputs, say Button 2.  Pressing Button 2 (now an admin button), Button 1, and Coin 1 (now action keys) will result in a phantom Esc and end your game.

[Tiger-Heli]

Wow, someone is still using that old thing?  If a key counter would be a useful addition, I'm sure I could scrape up the source and add one.  In fact GhostKey is long overdue for a transition to windows... one more project to add to my list.

Yep, I still like Ghostkey.

BTW, we now have the same problems on 3 units (counting jjd's KB32) using at least 4 software packages, so I think we have a consensus.

[Chris]

The part I don't understand is:

[KevSteele]

Thanks for updating the review.

[Chris]

BTW, you'll all get a kick out of this: check out the "AME Keyboard Encoder" labeling (the missing M is scratched off!)

ROFL!!! MAMEDev(tm) strikes again!   

[Chris]

Hey, didja see this appended to his current eBay auctions?

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

[Tiger-Heli]

Well, it's an accurate record of my experience: it was positive until I actually tried multiple keypresses, whereupon it all went downhill fast. 

Well okay, if you look at it that way.  My point is I think most visitors to RetroBlast will not realize it was updated and will expect the whole review to have been written after evaluating the product completely.

Interesting we both came to the same conclusion from opposite ends.  You originally like the encoder, and now think it sucks.  If you read through this from the beginning, after initial testing, I thought the unit sucked, and now think it can work for limited applications, but is way over-priced and deceptively marketed.

I realize you can, by jumping through hoops and ignoring the layout, get the joystick + six buttons. But in my mind you shouldn't have to do that: it either works as advertised or it doesn't. I wouldn't recommend this encoder to anyone planning a MAME project when there are better options that are actually cheaper, such as the KeyWiz Ecos.

Agreed, the matrix should be layed out so inputs labelled as action keys don't produce ghosting, or MattP should say you have to use diodes with the encoder.  And in any case, it should be more competitively priced.

If you're going to label outputs "Buttons 1,2,3,4,5,6,7,8" on a MAME encoder, I expect to be able to use those buttons.

Agreed.

BTW, you'll all get a kick out of this: check out the "AME Keyboard Encoder" labeling (the missing M is scratched off!)

Now THAT's funny.

[Tiger-Heli]

Hey, didja see this appended to his current eBay auctions?

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

Un-f'ing believable.  I hadn't seen that.

Technically he's correct, though -    (You can get 16 simultaneous keypresses.)  Of course you get this whenever you press 15 or sometimes 14 keys.  And no one else claims to sell a 16-input encoder without ghosting.  They all claim to (and do) sell 28 or 32 or 56 input encoders that don't do this!!!!

[KevSteele]

Gotta love "the big lie" - the bigger and more absolute you say something, the more likely people will believe it. 

No ghosting? To quote Tiger, Unfrikin' believeable...

Mattp has sent me several emails saying that there is absolutely no ghosting. I've replied that I was able to reproduce Tiger's findings, and that we had three different units showing the same exact behavior.

To quote Mattp:

Kevin,
You can rest assured that we have test fixtures and data to back our claims.
You can also rest assured that there are unqualified individuals out
there creating
their own test fixtures and publishing their own test data without
consent nor the
simplest courtesy of sending an email to Tokn Media addressing their
concerns.
If you personally have developed a test fixture this would be your
starting point.
If you have a simple sketch or drawing, we will gladly inspect it to see
that the wiring
complies with the design concepts behind Tokn Media's encoders.
Any path other than this taken by any parties outside of Tokn Media are
being treated
as wreckless behavior on the part of those individuals.
Best regards,
Mattp
Tokn Media

He's sent me some pretty strange emails recently - weird and kind of frightening rambling, actually.

Kevin

[NoOne=NBA=]

What kind of "test fixture" do you need?

If you hook up Button 1-6, as labelled, you should NOT, under ANY circumstance be able to produce ANY keypress other than a button that is pressed MANUALLY.

This product doesn't do that.
I don't know what they call it at TOKN, but everyone else I know calls it ghosting.
The only way they can claim that there encoders don't ghost is if they developed another, proprietary name for it--like interpolating.

If you press buttons 1/2/3 simultaneously, the encoder will "interpolate" that you really wanted to send a button 4 press as well, and will automatically do it for you.

Randy and Andy really need to get some of their encoders up on ebay, to keep the people that don't know any better from getting worked by this guy.

[jjd]

Gotta love "the big lie" - the bigger and more absolute you say something, the more likely people will believe it. 

No ghosting? To quote Tiger, Unfrikin' believeable...

Mattp has sent me several emails saying that there is absolutely no ghosting. I've replied that I was able to reproduce Tiger's findings, and that we had three different units showing the same exact behavior.

To quote Mattp:

Kevin,
You can rest assured that we have test fixtures and data to back our claims.
You can also rest assured that there are unqualified individuals out
there creating
their own test fixtures and publishing their own test data without
consent nor the
simplest courtesy of sending an email to Tokn Media addressing their
concerns.
If you personally have developed a test fixture this would be your
starting point.
If you have a simple sketch or drawing, we will gladly inspect it to see
that the wiring
complies with the design concepts behind Tokn Media's encoders.
Any path other than this taken by any parties outside of Tokn Media are
being treated
as wreckless behavior on the part of those individuals.
Best regards,
Mattp
Tokn Media

He's sent me some pretty strange emails recently - weird and kind of frightening rambling, actually.

Kevin

Well that tourques me off a bit.  I DID give him the courtesy of sending Mattp an email prior to my testing.  He actually replied and encouraged me to publish my results. 

I guess that is wreckless and unauthorized?? Since when does someone need authorization to review thier experiences with a product anyway?  Wreckless?  I noted very clearly that I wired the encoder exactly as shown and received perfect results when only 1 or 2 inputs were used at the same time. 

I hope that my refund is in my mailbox when I get home next week...

[jjd]

In fact, here is the email that I recieved.  Please note that the email says to feel free to cut and paste to the message board.

Joseph,
>>Thanks for the digging. As a representative for
>>TOKN, I can say clearly
>>state that my intentions are not to misrepresent the
>>product.
>>The alt-key passthru issue and the LED behaviour are
>>described in the release notes readme.txt. These
>>were known and documented from day 1.
>>The scroll lock programming needs a better
>>description, I agree.
>>Once in programming mode via scroll lock, you're in
>>until the next power cycle
>>or replug of the encoder. Not ideal but we're
>>looking at that for the next release. We're also
>>beta-testing the latest code release with a transmit
>>FIFO resize for the KB32 which is something that the
>>KB16 will benefit from.
>>Time to dot the Is and cross the Ts!
>>Here lies the growing pains. The eBay ad description
>>evolved as more users
>>inquired about its capabilities. I will review you
>>findings and see
>>if I agree. I'm open and looking for a better
>>product design in the long run.
>>If it warrants a diode, I'll document as such and
>>likely add it to the respin.
>>Phew! This has been quite a fiasco. Let me take a
>>look.
>>Your input is greatly appreciated and will result in
>>a better product in the
>>long run. Please encourage any other users to chime
>>in on the message board as TOKN has become a target
>>of much scrutiny in the past week.
>>Feel free to cut and paste to the message boards.
>>We're on it, checking it
>>all out. Thank you so much for your assessment. Lil
>>TOKN KB16 is growing
>>and is going to have to tighten up!
>>Cheers,
>>Mattp
>>Tokn Media
>>P.S. ReleaseManagement.pdf coming soon to the
>>website!

[Tiger-Heli]

Well that tourques me off a bit.  I DID give him the courtesy of sending Mattp an email prior to my testing.  He actually replied and encouraged me to publish my results. 

Um, I'm pretty sure he is referring to me - Tiger-Heli here.  FWIW, I probably would have sent him an E-mail, but I wasn't testing the unit until Mattp had basically accused me of purposely trying to denigrate the unit, and had tried to get Saint to pull all info about the units from the message board.  So at that point, I figured I would just help out the BYOAC and if Mattp cared, KevSteele had alerted him to this thread, and he could read it here as easily as in an E-mail from me.

I guess that is wreckless and unauthorized?? Since when does someone need authorization to review thier experiences with a product anyway?  Wreckless?  I noted very clearly that I wired the encoder exactly as shown and received perfect results when only 1 or 2 inputs were used at the same time. 

Again, I think he is referring to the fact that I used jumpers instead of switches to test the unit.  The problem here is that attaching a jumper is IDENTICAL to closing a switch, so if my test fails, then pressing and holding a switch connected in the same way would fail also.

The fact that he's condemning the testing methods rather than trying to address the ghosting concerns in his E-bay ads speaks volumes to me.

I hope that my refund is in my mailbox when I get home next week...

I hope you get a speedy refund also.

[Tiger-Heli]

Summary review of my testing with the KB16 is posted at http://www.mameworld.net/tigerheli/encoder/tokn16/index.htm.  Not much new ground for those who have been following this thread (I did verify that Print Screen and L Ctrl DO WORK with the KB16, despite what Mattp says. . .), but hopefully it's laid out a little more coherently.

Comments welcome!

[KevSteele]

Summary review of my testing with the KB16 is posted at http://www.mameworld.net/tigerheli/encoder/tokn16/index.htm.

[Tiger-Heli]

A very extensive review!

One suggestion - you can change the "pics I stole from RetroBlast" to "pictures compliments of RetroBlast". 

Kevin

Done!  Thanks Kevin - and thanks for allowing me to test the unit.

BTW, something to consider regarding Crazy Cooter's comments in the Ultracade Review thread (I almost posted there, but decided to wait):

Promoting (via review) a persons product supports that person in the industry.

<snip>

Since reviews are essentially commercial advertisements (that's why the stuff is mostly given for free), just stop being a commercial for a company (Ultracade) that is trying everything it can to run the people that actually care about the hobby out of it.

I would like to look at my review in light of the above comments:

I don't feel that I posted anything non-factual about either the product or Mattp in my review.  In fact, the review goes out of it's way to tell people how to get the most out of the KB16.

Is my review a commercial advertisement?  (Well, do you really think people will read my review and be knocking down the doors to buy the TOKN KB16.?)

Does my review support Mattp in the industry - Maybe, maybe not - It does give him a certain level of legitimacy and exposure that he would not otherwise have.  It also provides a lot of insight into things that could change on the KB16 Revision II (if there is one).  OTOH, it also exposes a lot of misleading statements that he probably would prefer were not exposed.

So why write it?

Three reasons - First, if it is not written, people have one less piece of information and will rely on Mattp's advertising statements and E-bay feedback and may get a product that does less than they expected.  Second - the information in the review may help someone at least make a workable panel using the KB16.  Third - Hopefully the information may help change the marketing strategy of Mattp and maybe even the design of the product.

None of this is meant to apply directly to your Ultracade review, but it is something to think about.

[KevSteele]

I agree with your comments, Tiger - I think that a review, good or bad, is more publicly-available information about a product. The more info the better, IMHO.

You've certainly provided a great deal of useful info about the TOKN16. and it would have been a real shame if you had "boycotted" the product because of Mattp's actions.

Kevin

[Tiger-Heli]

The more info the better, IMHO.

The more accurate info the better.  I would not be surprised if TOKN "supporters" don't pop up saying my info is totally inaccurate and the encoder works flawlessly.  This can only muddy the waters and make the situation worse.  I hope I'm wrong, but I doubt it.

it would have been a real shame if you had "boycotted" the product because of Mattp's actions.

Conditionally I agree.  I got the product for free from you, as did you from Mattp, I presume.  I would feel bad if I had paid for it, (even if I wrote the review), if my purchase was helping to sell the product to others, unless I could get my money-back.  (And I'm waiting to see how that plays out for jjd.)

And while I wouldn't have accepted the encoder to review from Mattp unless there was an understanding that anything I discovered (good or bad) would be fair game to include in my review, I would still feel bad about writing negative findings about a product the developer gave me for free.  I would still do it, but I'd feel bad about it.

Also, a certain level of distance is helpful.  I got the unit second-hand and after you had previously reviewed it and after it had been hashed out on the BYOAC forum.  Had I got it directly, there would have probably been a lot more back-and-forth between Mattp and myself - "Matt, my unit is producing ghosting, are they all supposed to, or did I get a bad sample?" - and that interchange usually turns the review more positive.  In fact, as I said, you can kindof see the pendulum in this thread.  My opinions basically went from:

1)  It really doesn't work, to:
2)  It is actually workable for a 1-player 6-button or 2-player, 2 buttons each panel (as long as you change the default inputs and re-program the unit), to:
3)  Okay, you can make it work, but it's a big hassle to do so and even after that it's more expensive than more capable competing products, so why would you bother.)

[KevSteele]

The urge to "soften" a review because of getting a unit for free is an issue I have had to deal with. Some feel my reviews are too soft, but quite often I'm just trying to be fair and point out the good and the bad.

As you yourself know, I have been known to stick to my opinions of a product, even when confronted by the product's creator (or an online rebuttal  )

Most of the time, companies don't submit products unless they're confident of a good review (i.e., they know their product works as advertised). That's why this whole situation with Mattp is such a mystery...

Kevin

[Tiger-Heli]

The urge to "soften" a review because of getting a unit for free is an issue I have had to deal with. Some feel my reviews are too soft, but quite often I'm just trying to be fair and point out the good and the bad.

There is that, but it's not always just that the unit is free.  See this page: http://www.mameworld.net/tigerheli/encoder/nocodeload.htm  I hated  this feature of the KeyWiz, asked for a way to disable it, asked for a version without it, and posted a page about why it was a terrible idea, and how it could (should) be disabled.  RandyT (correctly, I now believe) pointed out that it was realistically only a problem in a 4-player setup, and I never bothered to disable it on my KeyWiz, and have never had a problem with it.

My point is that you always have that dynamic - You don't like something, the developer points out why it's a good idea, and then you have to re-evaluate whether you missed something, or you were correct and he is just trying to put a positive spin on your negative comment.

As you yourself know, I have been known to stick to my opinions of a product, even when confronted by the product's creator (or an online rebuttal  )

I know, not always a good thing.  j/k    BTW, I recently reviewed my re-buttal for SirPoonga, and I stand by it as well, although there are some areas in there where I mis-understood what you were talking about.  My point here is that you need to write carefully and re-read what you have written so it can only be interpreted the way you intended (not that I'm 100 fool-proof on that.  Yes, I know they keep coming out with smarter fools ).

For example, I took "Program via attached keyboard" to mean that you thought it was a feature that the software used a keyboard rather than a mouse for programming the unit.  Andy Warne also thought this was a "feature".

In talking to SirP, I realized you were probably referring to an obscure method of programming the encoder without using software.  This would really only be useful on the I-PAC if you were running it under BEOS or Solaris, as otherwise, you would just use the Mac or Linux programming software.  On the KeyWiz, it would be pretty pointless, because unless you had a dual-boot system, custom settings would not be retained anyways, and with a dual boot system, you could program it through software in Windows and then boot into Solaris.

I think the main problem with your KeyWiz review was you didn't take the time to fully evaluate the product and the implications of some of the design decisions.  That's something I struggled with on the KB16.  For example, I know that, on the KB16, you can choose inputs carefully and avoid ghosting on the action keys.  But I didn't want to unwire my CP and wire in the KB16, so I can't really say whether the response time with multiple keypresses is acceptable for arcade gaming or not.  I think it is, but I don't have hard testing to back it up.

Most of the time, companies don't submit products unless they're confident of a good review (i.e., they know their product works as advertised). That's why this whole situation with Mattp is such a mystery...

Agreed.  I never thought about testing my KeyWiz for ghosting, but I'm pretty sure I wouldn't see any.

Did Mattp think that if he said it didn't produce ghosting, everyone would take it at face value and not do any real world testing?  Odd and unknown.

[KevSteele]

I think the main problem with your KeyWiz review was you didn't take the time to fully evaluate the product and the implications of some of the design decisions.

[Tiger-Heli]

I think the main problem with your KeyWiz review was you didn't take the time to fully evaluate the product and the implications of some of the design decisions.

Well, in the end it really boils down to this: compared to the IPAC, Randy's design adds 4 inputs and drops NVRAM, keyboard LEDs, USB, and keyboard passthrough (and no, the switchable input doesn't count, as it's useless IMO). It also has a "hot-swap" ability to change between a user-set key assignment and the MAME set, something you hated but I kinda found to be a nice "trick".

You and Randy feel that the 4 extra inputs are more useful than the NV memory and passthrough. I feel the other way around. At this point it's primarily a difference of opinion, and both encoders are still great for MAME and both work exactly as advertised (unlike the TOKN16, sigh...)

Okay, that's basically it.  There are some subleties and some not so subtleties -

KeyWiz has 32 action inputs, I-PAC has 27 b/c of a difference in shift key implementation.  But this is really only a factor for a four player panel.

Steath shifted keys involve two diodes for the KeyWiz, and an RC circuit for the I-PAC.

Shift operates on keypress on the KeyWiz and key release on the I-PAC.  Without a lot of configuration, Shift requires an extra CP button on the KeyWiz, and can be hidden on the I-PAC.

I-PAC software is available for Linux, Windows, and Mac and I-PAC can be custom programmed and used in any OS that recognizes a PS/2 or USB keyboard.  KeyWiz is pretty much limited to Windows, although you can use it with the default codeset in Linux.

I have been told (by Andy Warne) the I-PAC programming software is faster, but have not verified this.  I-PAC supports some macro assignments in programming, KeyWiz does not.   KeyWiz software uses a mouse/trackball, I-PAC requires a keyboard (although I think in NT,2K,XP, there is a "virtual keyboard" you can use.

I'm sure I left something out, since we're way off topic.

I did soften my Keywiz review a while back and removed the last sentence which did seem like a "cheap shot" upon review.

I missed that.  (Not the cheap shot, but that you removed it).  Good decision, IMHO.