I find myself rather bemused by all this...
Reads more like someone threatened or upset rather than "bemused", but I'll take your word for it.
Don't get me wrong, I'm not knocking the Keywhiz at all, there is room in this market for both of us. But just mulling over what I would need to do to the I-PAC if (perish the thought!) I wanted to mutate it into a Keywhiz clone.
Well, first of all you'd have to know that it's
KeyWiz, not Keywhiz. If you don't even know that (and can't see it in the subject line), it's hard to take the rest of your post very seriously. The apparently intentional mis-spelling alone appears to be a "knock" and based on the rest of your message, I reject your claim that it isn't.
BTW, if there is another competing product called "Keywhiz" and you were referring to that one, please disregard this entire post and accept my apologies in advance
OK firstly, in the microcontroller code, the state-based shift function would have to go, even though this allows any button to be the shift button and also have it's own function as well, or be dedicated as shift (total flexibility?). That's replaced by a simple selection of codesets based on the state of one specific input..a much simpler programming task!
You should give your mis-information supplier a raise. He's been working overtime. The KeyWiz has 32 direct inputs
plus a shift input that doesn't keep any of the microcontrollers available inputs from being used for hi-speed game controls. It is not handled anywhere near as simplistically as you have stated.
When one places a frame around how the functions of a product need to be implemented, the number of options dwindle. This is the anti-thesis of "total flexibility". (refer to "KISS" design philosophy)
IMHO, you now appear to be in the realm of speaking about things, as they apply to the KeyWiz, that you either do not understand, or have inadequately researched.
Then out goes the nice interrupt-based pass-thru code, which uses nested bit and byte-level state machines (for the nerds) to handle the bitstream from the keyboard, a design which uses no clock cycles when the keyboard is idle.
As long as you are talking "technical", does the IPAC-4 use this method? Are the second 28 inputs viewed by the main controller as an "attached keyboard"? How much data has to be sent by the secondary controller to the primary one whenever 1 button is pressed on the secondary set? How about 20? Which one has precedence? How does this affect the performance of either set of inputs given the very specific timing requirements needed to speak in "PS/2"?
Remember, a microcontroller can only do
one thing at a time, and
everything uses clock-cycles. Even if it is only to evaluate the status of a single bit of data. The microcontroller you are using is only capable of generating an interrupt when activity is sensed on any of the I/O pins as a group. This is a hardware limitation. It
cannot generate an interrupt based on
which of the pins or even which port (group of up to 8 pins) generated it. This means that anytime
any input activity is sensed, it is up to your program (using many clock cycles) to decide what caused the interrupt, including checking the pin attached to the clock-line of the keyboard to see if it was the culprit. It would check this bit, even if it was a pushbutton that caused the interrupt.
I expected that a guru like yourself would already know this, so I have to say that I am a little perplexed by the above "no clock cycles" statement and other such statements regarding interrupts.
BTW, your pass-through method also uses 2 inputs, which effectively negates the possibility of a workable 4-player panel. But there are consideraby more expensive 4-player controllers that need to have a market as well, so no loss there....I guess.
Delete the routines which allow the I-PAC to be programmed or tested by the device "typing" characters into a text editor on the PC.
The limited functionality of such things as opposed to what can be done with dedicated software on the PC side, make these extraneous for the large majority of users. They wouldn't be missed.
Delete the interface to the EEPROM chip which saves codes from the MCU RAM into the EEPROM.
Save it to the EEPROM or save it to the PC's hard drive and lose 5-10 seconds at boot time. Very little difference, other than the EEPROM adds cost and subtracts 2 more inputs. File this under "just because you can, doesn't mean you should."
Delete LED support.
A few people out there like the LEDs....but seemingly, just a few.
Delete all the USB support.
The Mac people need something too.
Now to the hardware:
Replace European made screw-terminals with Far East ones with tiny phillips screws which I don't personally like (OK that's probably just me, there's probably nothing wrong with them really). Four more connections.
You are again showing how little you know about the product you are bashing. The KeyWiz uses expensive GERMAN MADE (aren't they European too or did you kick them out
?) 5mm spaced connectors. Essentially as good or better than the type used on your product, but with easier to use Phillips-head screws (that don't need a jeweler's screwdriver). Just an FYI, for any future bashing sessions you might like to embark on, the KeyWiz circuitboard is U.S. manufactured, assembled by U.S. workers, and shipped through the U.S. Postal Service.
BTW, it looks like a good number of your products come from the "Far East". Are you inferring that they are of poor quality or is there an anti-Asian thing we don't know about?
Delete EEPROM chip.
Little need for it anyway, so you might as well save the 50 cents.
Delete LED header connector.
But won't that keep you from selling the harnesses?
Delete pass-through connector (there's no way I would put that switch on the board, have to draw the line somewhere!)
Oh, so a hidden extra switch on a panel with 30 other switches is the end of the world, eh? Heh.
How about that annoying buddy that beats on the keyboard while you are playing and screws up your game? Not with the KeyWiz!
Add 5 volt connection, something I conciously avoided adding before (except on a header) owing to the risk of accidentally connecting a switch to it and damaging the motherboard.
That's why you make it abundantly clear in your printed documentation where it is and why to avoid doing that. You do provide printed instructions, don't you?
Shrink the board and therefore by necessity the labelling on the connections.
The spacing of the terminals is the same 5mm on both products, so that has no bearing on board size. What does have a bearing, however, is the use of a cheaper single-layer board as opposed to a more expensive double layer board. I seriously doubt you could shrink your board much without going to a 2-layer design, thereby reducing your profit margins.
It would be a mere shadow of it's former self! Maybe I should not rule this out though. It seems that the advanced features are not really needed, going by Tiger-Heli's opinion at least (and yes I actually do genuinely respect his long-standing interest and enthusiasm for this kind of product)...Based on the fact that deleting stuff is much easier than adding it, I should have this done by tonight...
Don't forget to add more features to the software...(you do personally, as I do, write the software so crucial to supporting your product, don't you?). And while you are at it, you should start using high-quality 2-sided boards, start supplying printed documentation, and get rid of those jumpers. You might also want to start your own shipping company and get a job as head of U.S. Customs, so that the occasional elevated alert level doesn't hold some of your packages up for long periods of time and you can send things for only $6.50 to the U.S.
Every KeyWiz that goes out the door is inspected and tested by me personally, so add that to your list as well. Your customers are worth it, aren't they?
RE: "advanced features"
"Advanced" is in the eye of the beholder. If you had an electric toothbrush that had a radio built into the handle that made it twice as heavy and the batteries last half as long, would you consider that to be "advanced"? If you like to listen to the radio while brushing your teeth, then maybe. And maybe that product
should exist for those people that are willing to make those sacrifices. But it doesn't mean that it is better than any other electric toothbrush just because it has a radio in it.
To be perfectly honest I would not be unhappy about doing this, because all that clever code has not been wasted, having been incorporated into several non-gaming consumer USB/PS2 products from US corporations (the income from which far exceeds what I have made from the I-PAC!). Or would I risk a consumer revolt "Bring back the old-taste I-PAC"??
So the logic here goes "if it's good enough for a consumer keyboard/GPS/PS2 splitter/ etc.., it must be good enough for a gaming controller"?
If other products in this market were making a significant dent in my sales, I'm not sure I would infer to potential customers that their needs were less important to me because I make more selling to "corporations", or threaten to change my product in spite of the fact that they may like it the way it is. But your strategy appears to be heading in that direction. Hope it works for you
.
BTW, Merry Christmas!
RandyT
Home
Help
Search
Login
Register
Send this topic
Print
Topic: KeyWiz vs. IPAC? (Read 13101 times)
