New xBox encoder project-hopefully low cost

[sharpfork]

I have been helping Degenatrons and Bootsector put together what is looking like a very flexible and inexpensive arcade encoder.  The initial focus is the xBox1 for CoinOPs and the purpose of this post is to find out what y'all think about the proposed mapping:


notes
- Connecting pin 20 to ground disables the ability to hit back+start to exit. With this set, you will need a dedicated button on pin 15 to exit games. My kids and guests tend to mash buttons trying to add credits to continue which too often leads to an accident exit of the game.

- shift/Exit to Dash = back+start+white+black+LT+RT

other ideas
Save/Load save
-Is there a set of buttons that is common across all (or most cores) that would be used for a save/load state?  I'd love to be able to save my 150,000+ point 4 lives left galaga games and jump back into them to practice at higher levels without having to push a bunch of buttons.  I'd like the same for consoles as well.

+5v time delay
- Degenatorns uses this with a relay to hid the flubber visuals and sounds, delaying the start up of the monitor and audio amp.

While the initial builds are focused on an inexpensive xBox1 build, support for PC, Mac, Linux & Andorid keyboard/HID and PS3 are quite likely.  The hardware has taken a few forms ranging from off the shelf AVR boards to custom PCBs and has not been finalized yet.  We are at least a few weeks out from starting beta testing which will likely take a while as we are spread across the UK, US, and Brazil and sending hardware around.  We don't have a name for it yet and we don't know what it is going to cost.

Any ideas and feedback will be appreciated.

[degenatrons]

With the shift function, can I lock it back and forth on the fly?

Click click moves and locks from D-Pad to Analog
Click click unlocks and moves it back to D-Pad?

That sounds neat but I'd note that the only reason you'd want Analog controls out of a joystick is for use on Xbox games.  In shifted mode you're losing Black/White/LT/RT.  I'm not sure what a good compromise would be....

Hey,

The shift function can be locked back and forth on the fly with double-click.

A possible solution,  for those who want to play xbox games with analog and regular controls,  is to have another jumper setting...

Jumper setting would be named something like: Retain buttons in shift-lock
You would then get analog, LT, RT, black white when shift locked.

This setting would not apply to a combo keypress,  so you could still get left thumb by using shift+LT combo when not shift locked.

I think this would be a neat feature.  To activate this way of working you would need to bridge a wire between a given pin and ground.
Hopefully I explained this sufficiently well.  Let me know what you think?

[sharpfork]

With the shift function, can I lock it back and forth on the fly?

Click click moves and locks from D-Pad to Analog
Click click unlocks and moves it back to D-Pad?

That sounds neat but I'd note that the only reason you'd want Analog controls out of a joystick is for use on Xbox games.  In shifted mode you're losing Black/White/LT/RT.  I'm not sure what a good compromise would be....

Hey,

The shift function can be locked back and forth on the fly with double-click.

A possible solution,  for those who want to play xbox games with analog and regular controls,  is to have another jumper setting...

Jumper setting would be named something like: Retain buttons in shift-lock
You would then get analog, LT, RT, black white when shift locked.

This setting would not apply to a combo keypress,  so you could still get left thumb by using shift+LT combo when not shift locked.

I think this would be a neat feature.  To activate this way of working you would need to bridge a wire between a given pin and ground.
Hopefully I explained this sufficiently well.  Let me know what you think?

So setting the jumper defines if shift is used primarily for admin stuff or for xBox games.  I like it.

[bootsector]

Another alternative to grounding pins is to retain the selected "profile" in eeprom. We could then select the profile by double pressing a button. Led flashes could be a visual way to show the selected profile, i.e., blink once for profile 1, blink twice for profile 2, etc...

Sent from my GT-P7510 using Tapatalk 2

[sharpfork]

Another alternative to grounding pins is to retain the selected "profile" in eeprom. We could then select the profile by double pressing a button. Led flashes could be a visual way to show the selected profile, i.e., blink once for profile 1, blink twice for profile 2, etc...

How many profiles could be held in the current hardware?

[bootsector]

Another alternative to grounding pins is to retain the selected "profile" in eeprom. We could then select the profile by double pressing a button. Led flashes could be a visual way to show the selected profile, i.e., blink once for profile 1, blink twice for profile 2, etc...

How many profiles could be held in the current hardware?

Virtually there's no limit: profiles should be programmed as separated polling routines and eeprom setting would cost a single byte.

Sent from my Nexus One using Tapatalk 2

[rablack97]

Another alternative to grounding pins is to retain the selected "profile" in eeprom. We could then select the profile by double pressing a button. Led flashes could be a visual way to show the selected profile, i.e., blink once for profile 1, blink twice for profile 2, etc...

How many profiles could be held in the current hardware?

Virtually there's no limit: profiles should be programmed as separated polling routines and eeprom setting would cost a single byte.

Sent from my Nexus One using Tapatalk 2

It's getting to the point where a small readout screen is going to have to be implemented or additional leds to actually show what mode your in....Blinking leds, double clicks, multiple profiles ....

A new user could get lost in that maze and get frustrated......

[bootsector]

Great feedback, rablack97! Thanks!

So let's keep it simple by using jumpers then!

bootsector

[rablack97]

Great feedback, rablack97! Thanks!

So let's keep it simple by using jumpers then!

bootsector

To clarify, I like the idea of the profiles and the extra features....I just think there needs to be a better way to visually show the user what mode the encoder is in....You dont want to scare away the novice user due to complexity....The first thing they look for is ease of use, if it's too complex they will go elsewhere just for the fact of convenience.

The hardcore hobbyists like us can and will identify the complexity and work with it, cause its a challenge.  I would think you would want to accomodate both demands if possible.

[johnm]

Could a simple gui be made that allowed the user to pick his/her own setup and then flash to the encder? Would save all the hassle of people wanting shift to this or that.

[bootsector]

Yep! Encoder firmware will be upgradable via a GUI application.

Sent from my Nexus One using Tapatalk 2

[johnm]

I should have been clearer, would the GUI allow the firmware to be customisable for each user. Say i want shift to switch to  anolog sticks but keep the triggers instead of thumb buttons.  Rather than have mode 1,2,3,4 etc confusing people, if the user could have a simple 'check box' system to choose features then the program  would build and flash the firmware.

[bootsector]

Gotcha. That's a neat feature that we may consider, but not for day 1 for sure.

Sent from my Nexus One using Tapatalk 2

[degenatrons]

Price = Cheap
Timeline  = Soon

[destronger]

interesting sharpfork... i'll keep an eye on this post. oh, and thanks for the info on the cp. 

[degenatrons]

Some improvements and features added.  The device (KADE) is working like an absolute charm.

We are doing some beta testing and should have a release date for the xbox soon.

Updated pin mapping sheet below and PDF version also attached.

[krimpsok]

Any update on this yet?

[sharpfork]

We are working on this thing more than I ever expected (a whole bunch) and are aiming for a "Octoberish" launch.  We need to determine which features and supported devices will be in place for launch and which ones will be in beta.  We also have a ton of testing of new features to complete. 

This thing is much much more than just the simple xBox encoder we started with.  We will release more details as decisions are made and the release date gets closer.   While it is close enough to done that I am using it in my cabs and playing on it every day, I'm not going to be completely surprised if release gets pushed into November so we can have the support materials in place.

Here is the simplified version of the logo:

[floriske.nl]

Really looking forward to this!

I have just posted a topic about interfacing with an xbox on a budget: http://forum.arcadecontrols.com/index.php/topic,122991.0.html

And the Kade seems to be just what I need, just as long as the following is indeed true

Price = Cheap
Timeline  = Soon

Starting my build soon, so I hope the octoberish release is more accurate than novemberish 

[destronger]

@sharpfork: i know you've tried this with coinops but have you tried it with other emu's, ie madmab emu's, final burn legends, etc?

thanks.

[rablack97]

@sharpfork: i know you've tried this with coinops but have you tried it with other emu's, ie madmab emu's, final burn legends, etc?

thanks.

Hello Destronger....I'm beta testing Kade, so i'll check out a few for you and give you some feedback.....

I'm sure it will work though, if an XBOX jstik works with it, KADE will too....

[degenatrons]

Hey everyone,

KADE is coming along well and is tested and working on various consoles and computers.

A utility has been developed for configuring the KADE,  it enables you to pick from a large selection of encoder firmwares for your device. 
KADE currently supports xbox, ps1/ps2, ps3, mame, pinball, usb keyboard, usb/hid joystick and there are many other systems that will come online as the product develops. 
To update the KADE to work with a system, you plug it in to USB port, select the firmware you want and program it.  Simples.

Advanced KADE configuration is made possible via the Loader utility too.  You can customise the specific functions that you want to use with your KADE device and your control panel.
e.g. for xbox,  we currently have 35 mappable functions,  made up from the regular xbox inputs (dpad, button, L/R analog sticks, thumb buttons, triggers etc) and lots of other neat stuff like auto-fire, restrict dpad to 4-way operation, Invert Y axis, drive external LED's and timing the powering up of external devices. Other features are being added too. 

In the custom mapping builder, you pick the functions that you want and assign them to pins on the KADE.

KADE = Kick Ass Dynamic Encoder

I included some screenshots of the loader.  The first 2 images show Xbox the encoder and customisation. The 3rd image shows MAME configuration.
Hopefully this gives you a little taste of things to come.

[destronger]

@sharpfork: i know you've tried this with coinops but have you tried it with other emu's, ie madmab emu's, final burn legends, etc?

thanks.

Hello Destronger....I'm beta testing Kade, so i'll check out a few for you and give you some feedback.....

I'm sure it will work though, if an XBOX jstik works with it, KADE will too....

thank you... it never hurts to try other emu's. this way you will absolutely know it's operational.

[Gray_Area]

This initially being XBOX, I skipped it. Has come along very nicely. I'll look for it in BST.

[floriske.nl]

That's some promising news 

Now I really hope Kade will be released on short notice and within my budget

Looking good!

[MTPPC]

I'm sorry if I missed it, but what device specifically is this program used for? Is this for the minimus 32 USB AVR?

[ark_ader]

Looks cool.  Nice work! 

[degenatrons]

Thanks for the feedback. 

MTPPC - The device will be compatible with Minimus 32K and other AVR's.  We shall release more specific details about the hardware soon.  KADE will have a PCB and this will make it super easy for you to connect arcade controls.

This project covers more than just consoles,  so will be publishing information in the "project announcements" section soon.

[zorg]

will it be possible to have a function usefull on mame cabinets. have some button input whose  signal depends on the time presss ?
eg I would like to set up my mame cab to use "player one"  for "player one" as expected plus send "escape" if long pressed
so it will ends to have one button controling game exit  while in game, plus frontend exit and then shutdown while activated on frontend.

not sure I'm really clear ;-)

[degenatrons]

will it be possible to have a function usefull on mame cabinets. have some button input whose  signal depends on the time presss ?
eg I would like to set up my mame cab to use "player one"  for "player one" as expected plus send "escape" if long pressed
so it will ends to have one button controling game exit  while in game, plus frontend exit and then shutdown while activated on frontend.

not sure I'm really clear ;-)

Perfectly clear zorg.  I was already looking at alternative ways to take input from buttons.  "long press" and "double-click" are already supported in some of the firmwares but have not yet been added to the custom mapping builder.  I will aim to get these added so you can assign these to whatever actions you want.

I will add validation too,  so you won't be able to assign a secondary long press function to a gameplay input e.g.  it would not be wise to assign long press to a direction input.

As well as "long press", "double-click" and momentary.  There is already support for switches - so inputs are always on or off,  this is useful for functions like auto-fire.   Another way to control a switch is with a "toggle" so a momentary press is used to move the switch.

In summary.  These are the methods which we will aim to support:

Momentary
Long Press (and maybe very long press)
Double-Click
Dedicated Switch
Toggle

[PL1]

I will add validation too,  so you won't be able to assign a secondary long press function to a gameplay input e.g.  it would not be wise to assign long press to a direction input.

Not sure if it's a good idea to add validation based on which input is used.

Part of the reason for making the encoder user programmable is to allow users flexibility, right? 

As long as there is a way to clear/reset assigned functions, there shouldn't be a problem.

There is already support for switches - so inputs are always on or off,  this is useful for functions like auto-fire.

Not quite following the logic here -- I'm assuming that "Dedicated Switch" from your list of methods is what this quote references.    

It sounds like this function would output a continuous keypress for as long as the encoder has power applied.   

Did you mean that it would work like the "Normally Closed" tab on a microswitch - on until pressed?

Autofire makes me think of the NES Advantage "turbo" buttons.

Wouldn't autofire normally be a toggle function that controls whether a button outputs a single press or a pulse train that simulates pressing the button many times?

If you add the pulse train function, consider having the option of setting the speed like the grey knobs allow on the Advantage.




Scott

[degenatrons]

Hey Scott,  thanks for your thoughts.

Not sure if it's a good idea to add validation based on which input is used.

Part of the reason for making the encoder user programmable is to allow users flexibility, right? 

As long as there is a way to clear/reset assigned functions, there shouldn't be a problem.

I get your point about allowing complete flexibility with the programming.  The restrictions can be completely relaxed. 
Do you think I should present the user with a warning in the GUI if I suspect they're doing something odd - like assigning a long press to a direction?  I won't stop them from doing that if they want.

Regarding the switches.  The dedicated switch is allowing for people to attach on/off switches rather than momentary push buttons.  I should refer to this as on/off switch. 
An on/off  toggle would be possible by using a single press, a double click or long press of a momentary switch.

Regarding auto-fire. When auto-fire is set,  the device will send pulses to simulate rapid button presses. 
I currently have a delay setting of 25ms between pulses.
I like your suggestion to adjust the speed:
It would be possible to add configuration for the auto-fire speed (delay between pulses).
This auto-fire config could be set in the GUI and assigned as a function to buttons.  So you could select a default delay of 50ms and then assign button inputs to speed up or slow down the auto-fire rate.

[PL1]

Do you think I should present the user with a warning in the GUI if I suspect they're doing something odd - like assigning a long press to a direction?

Sounds like extra work for you on something that won't give much, if any, payoff.   

As long as there is a way to reset back to default and/or clear the input you should be good IMHO.  Picture MAME's "Input (this Game)" menu -- enter/escape clears the highlighted button, enter/escape again resets it back to default.

Regarding the switches.  The dedicated switch is allowing for people to attach on/off switches rather than momentary push buttons.  I should refer to this as on/off switch. 
An on/off  toggle would be possible by using a single press, a double click or long press of a momentary switch.

Regarding auto-fire. When auto-fire is set,  the device will send pulses to simulate rapid button presses. 
I currently have a delay setting of 25ms between pulses.
I like your suggestion to adjust the speed:
It would be possible to add configuration for the auto-fire speed (delay between pulses).
This auto-fire config could be set in the GUI and assigned as a function to buttons.  So you could select a default delay of 50ms and then assign button inputs to speed up or slow down the auto-fire rate.

OK, this makes more sense.

I think the word you're looking for instead of "dedicated" or "on/off" is "continuous", since that is the industry standard term.

Sounds like your Customizing GUI will have 8 columns and 3 radio buttons/checkboxes.
-- Based on your earlier screencap since you haven't sent a link to the beta version yet.
Nudge. Nudge. Wink. Wink. Know-what-I-mean?   

This would give you the following list of columns, functions and associated switch types:
1 - Pin (A1-A10, B1-B10)
2 - Momentary - Momentary pushbutton (Default function)
3 - Long Press (and maybe very long press) - Momentary pushbutton
4 - Double-Click - Momentary pushbutton
5 - **Toggle - Momentary pushbutton
6 - Autofire - Momentary pushbutton sends pulse train. 
7 - Autofire Speed - Pull-down box with the numbers 1-9 (9 is fastest/default)
8 - ***Continuous - Light switch or latching pushbutton

**=Should this cell be greyed out until you select a radio button/checkbox after Momentary, Long Press, or Double-Click cells?  May need two columns to define toggle "on" and toggle"off" states.
***=Will this be a continuous "press" which might interfere with bootup , a momentary pulse on state change, or a recurring pulse at regular intervals?

I'll play around with that online metronome later to find a decent range for autofire speeds.


Scott

[sharpfork]

spectacular feedback PL1, thanks!

[degenatrons]

Great feedback - as usual - PL1. 
I send you a message with information about the beta version. 

Anything you can contribute on the auto-fire speeds would be very much appreciated.  Would be good to have a low/high and a default,  all customisable of course

Right, will refer to those switches as "continuous" from now on.  Thanks for putting me straight. 
That sure is a lot of columns for the switch types.
We need to think of a way to make this easy to manage in the UI.   I was thinking of having one or two additional functions per pin - on top of the 2 that we already have (normal & shifted),  each of the pins could be assigned a switch type from the list. 
...but maybe it would be better to allow everything in customisation.  Maybe an "advanced" screen for the switch config.
I will give this some more thought.

Jon

[404]

Glad to hear its at the beta phase already. Definitely looking forward to this. 

[degenatrons]

A new project announcement for KADE at http://forum.arcadecontrols.com/index.php/topic,128745.msg1316035.html#msg1316035

KADE has evolved into general arcade interface solution and is not console specific.   For that reason we are moving the KADE topic to the project announcement section and subsequent posts will be posted there.

Hope to see you in projects section.