Advantages of keyboard encoder vs hacking gamepads

[RandyT]

why do the leds have to be connected to a common +5 (or shared with a button input?) ?

 why can't they be connected to a common ground and the routine only pulses the +5 to the p1/p2 leds when coin 1 or 2 is triggered, and only pulse +5 until p1 start or p2 start is triggered?

the  cpu is not expecting to sense input from p1/p2start (therefore is not wasting cycles deciding whether or not to pulse the leds) until after coins are triggered...  the key whiz has to sense for coins at all times anyways (whether by coin switch, or by coin button), why not make it go into the pulse subroutine when it does sense them? (and exit pulse subroutine when the starts are triggered)

you loose 2 buttons (for p1/p2 start leds ) with this setup, right? (Cause the coin buttons are already part of the setup in a mame config..)

You are on the right track.  My reason for not doing this is because it would essentially make the KeyWiz a MAME specific device.  There are also other cool things that can be done along those lines, but are better served by something dedicated.

btw, how much is the max going to be (approx)? and how many days before
 I can click the cart button on the website and it takes my Visa Number? )

Check your messages!

RandyT

[OSCAR]

You guys are going to make me buy one of these aren't you

see this post:
http://www.ultimarc.com/messages/1599.html

From what I see and according to the documentation, there is only one place to hook the LEDs and that is the 10-pin port.  Where is the other one that keeps being mentioned?

Nope, there are two places.  It's the button inputs that are bi-directional, not the pin header.  I've only had LED's connected to the pin header, and they definitely do not flash when the bi-directional player buttons are pressed.  Now when connecting LED's to the bi-directional button inputs, that is a totally different story...

See this thread:  http://www.arcadecontrols.org/yabbse/index.php?board=1;action=display;threadid=4371.

Okay, I just verified it.  On the I-PAC, I connected one LED to the P1B7 bi-directional button input (P1 Start), and one to the Caps Lock (P2 Start) on the 10-pin header.  The LED connected to the bi-directional button input flashes when the corresponding button is pressed, and the LED connected to the 10-pin header is not affected when its corresponding button is pressed.  This all jives with the info on Andy's site.

The thread you linked referred to LED's connected the bi-directionals, not the 10-pin header.

[RandyT]

You guys are going to make me buy one of these aren't you

see this post:
http://www.ultimarc.com/messages/1599.html

From what I see and according to the documentation, there is only one place to hook the LEDs and that is the 10-pin port.  Where is the other one that keeps being mentioned?

Nope, there are two places.  It's the button inputs that are bi-directional, not the pin header.  I've only had LED's connected to the pin header, and they definitely do not flash when the bi-directional player buttons are pressed.  Now when connecting LED's to the bi-directional button inputs, that is a totally different story...

See this thread:  http://www.arcadecontrols.org/yabbse/index.php?board=1;action=display;threadid=4371.

Okay, I just verified it.  On the I-PAC, I connected one LED to the P1B7 bi-directional button input (P1 Start), and one to the Caps Lock (P2 Start) on the 10-pin header.  The LED connected to the bi-directional button input flashes when the corresponding button is pressed, and the LED connected to the 10-pin header is not affected when its corresponding button is pressed.  This all jives with the info on Andy's site.

The thread you linked referred to LED's connected the bi-directionals, not the 10-pin header.

Oscar, thanks for going to the trouble.

I can't argue with you because I don't actually have one of these in front of me as you obviously do.

I can only say that I am intrigued as heck about how this is being pulled off.  Purely from an academic standpoint, as I have no intentions of implementing this on the KeyWiz.  

Someone was just kind enough to send me a very high-res photo of the bottom of the I-PAC.  The pins on the 10-pin header that you say are different are very clearly connected to the terminal block inputs with no other circuitry connected in-between or elsewhere, as is the +5v line.  Electrically, they are absolutely identical.

If what you say is accurate, kudos to AW!  He must have some tricks up his sleeve that I haven't seen before

RandyT

[Tiger-Heli]

....one other feature which the I-PAC has and the KeyWhiz lacks:

The I-PAC can load an alternate key definition file from a batch file.  I understand the KeyWhiz supports alternate character sets, but you have to use the "shazam" key to load them.

If KeyWhiz could load alternate character sets from a batch file, I would definitely be interested.

Not sure where you heard this one, but I assure you that this is not the case.  

The Shazaaam! Key offers a fast and simple way to switch between code sets, but you don't need it to switch.  If you have a custom set that you want to be active after programming, the software has a setting that lets you do that.  Rest assured that command line programming is available in the software.  I have some plans for added functionality as well, but I don't want to talk about that until I make sure it will work

Actually, I just ASS-umed this from your website as you mention switching code sets with the Shazaam key, but don't mention switching code sets from the command line or batch file.  You might want to make mention of this feature on your page.

Three new questions:

First, will the KeyWhiz work as a USB device using a PS/2-USB adapter?

Second, Eightbit said that the KeyWhiz can switch codesets without reprogramming the chip.  This would speed the process up.  Is this a true statement.

Finally, like other posters, I would like to know when the product will be officially available, what pricing is for the standard and max version (I assume $26.95 is for the ECO versions) and pricing and EDA of the LED driver option.

Thanks

[RandyT]

Actually, I just ASS-umed this from your website as you mention switching code sets with the Shazaam key, but don't mention switching code sets from the command line or batch file.  You might want to make mention of this feature on your page.

Actually, this is from the page...

- Full-featured Custom Codeset Management Software.  Completely mouse/trackball driven.  One-click selection of any of 15 user definable codesets (32 normal and 24 Shazaaam! codes per).  Codeset to be active after programming is user-selectable.  Command line options for autoprogramming / batch file operation.

but there is a lot of stuff on there so I understand how easy it is to miss.  I'll add it to the FAQ

Three new questions:

First, will the KeyWhiz work as a USB device using a PS/2-USB adapter?

Which one?  A straight cable?  Then no.  An active converter?  Yes, but it would cripple the performance.  The FAQ for details talks about this somewhat, but that question will be added to address it more completely.

Second, Eightbit said that the KeyWhiz can switch codesets without reprogramming the chip.  This would speed the process up.  Is this a true statement.

Yes, but this requires the use of the Shazaaam! Key.

Finally, like other posters, I would like to know when the product will be officially available, what pricing is for the standard and max version (I assume $26.95 is for the ECO versions) and pricing and EDA of the LED driver option.

The LED option is in the development stage.  It is currently too early to be talking about dates for this product, but I will estimate 45 to 60 days before it could be a polished product like the KeyWiz.

As for the KeyWiz, that all depends on whether you think it's prudent to release the hardware before the software is finalized.  I have the software functionally tested on 98SE and Win2K.  It hasn't been tried yet on XP, but should work.  This of course is only an issue if you want to program the unit.

In my mind, and barring any unforseen problems with the web store, less than 1 week until it goes live.  We also need to build stock so people won't be waiting after their orders are placed.

Prices will be as follows:

KeyWiz Eco: $26.95
KeyWiz Standard: $33.95
KeyWiz Max: $36.95
Priority Mail (2-3 day) shipping anywhere in the US: $6.50

RandyT

[OSCAR]

Oscar, thanks for going to the trouble.

I can't argue with you because I don't actually have one of these in front of me as you obviously do.

I can only say that I am intrigued as heck about how this is being pulled off.  Purely from an academic standpoint, as I have no intentions of implementing this on the KeyWiz.  

Someone was just kind enough to send me a very high-res photo of the bottom of the I-PAC.  The pins on the 10-pin header that you say are different are very clearly connected to the terminal block inputs with no other circuitry connected in-between or elsewhere, as is the +5v line.  Electrically, they are absolutely identical.

If what you say is accurate, kudos to AW!  He must have some tricks up his sleeve that I haven't seen before

RandyT

LOL!  Now you are seriously making me second-guess myself!  

I was pretty tired last night when I slapped it together, and I could have messed something up.  On my first try I got the results I was expecting, so I didn't test it anymore.  I'll try it again later today a little more thoroughly and double check everything to make sure I'm connecting the LED's to the proper places.

Well, sure, we could just ask the designer, but it is so much more fun to experiment and speculate....

[OSCAR]

Yes, Randy, you are correct.  It doesn't matter if the LED's are connected to the 10-pin header or the button inputs, they make the LED's flash either way.

This is how I got it screwed up....  I've previously only had LED's connected to the 10-pin header, which are labeled as Num/Caps/Scroll lock so I didn't have to worry about what button inputs flash which LED's.  Since I have only 6 buttons per player, I've never noticed any flashing before, either.  Based on posts in this thread, I connected buttons and LED's as follows:

P1 B7 - Num Lock
P1 B8 - Caps Lock
P2 B7 - Scroll Lock

As it turns out, this is incorrect.  By following the traces on the board, I see now that the correct button inputs are:

P1 B8 - Num Lock
P1 B7 - Caps Lock
P2 B7 - Scroll Lock

So that's why I couldn't get the buttons to flash the LED's, I had them hooked up incorrectly!  Sorry for the confusion to anyone following this thread, I guess Randy knows what he is talking about after all.  

[Tiger-Heli]

Yes, Randy, you are correct.  It doesn't matter if the LED's are connected to the 10-pin header or the button inputs, they make the LED's flash either way.

This is how I got it screwed up....  I've previously only had LED's connected to the 10-pin header, which are labeled as Num/Caps/Scroll lock so I didn't have to worry about what button inputs flash which LED's.  Since I have only 6 buttons per player, I've never noticed any flashing before, either.  Based on posts in this thread, I connected buttons and LED's as follows:

P1 B7 - Num Lock
P1 B8 - Caps Lock
P2 B7 - Scroll Lock

As it turns out, this is incorrect.  By following the traces on the board, I see now that the correct button inputs are:

P1 B8 - Num Lock
P1 B7 - Caps Lock
P2 B7 - Scroll Lock

So that's why I couldn't get the buttons to flash the LED's, I had them hooked up incorrectly!  Sorry for the confusion to anyone following this thread, I guess Randy knows what he is talking about after all.  

Doggone it OSCAR, I had my panels all planned out and had to reaarrange them based on that other thread that you mentioned.  Now, I have to swap the P1 and P2 LED's,  at least it's just the LED's and not the other inputs that are affected now.

Thanks for the info!!!

Grrrrrrrrrrrrrrrr!!!!!