really interesting discussion. I vote for the controller port too! For (E)Uzeboxers with enclosures it is the easiest way - otherwise it is diffcult and tricky to add the module and of course WLAN modules in a aluminum case won't work (Greetings from Mr. Faraday...)
I am curious how the controller port method might be possible? The only pin unique to P2 port is data, is it ok to clock out 16 bits from pad 1, then use clock and P2data for a serial type interface? If P1 pad isn't latched again it shouldn't hurt the next pad state to clock it more right?
DaveyPocket wrote:Uzebox JAMMA doesn't have any controller ports
I forgot about that. All games get recompiled with some changes to work on Uzebox Jamma correct? If we have an interface/protocol with a little mcu using a couple pins, we could easily have which pins are used configurable at compile time. In that way, both solutions could be work the same.
D3thAdd3r wrote:I am curious how the controller port method might be possible? The only pin unique to P2 port is data, is it ok to clock out 16 bits from pad 1, then use clock and P2data for a serial type interface? If P1 pad isn't latched again it shouldn't hurt the next pad state to clock it more right?
The way I see it is to latch and clock P1 port as usual. The module on P2 port could be signaled by say leaving the latch line down while pulsing the clock once. Then sending a command or receiving data. I must admit I didn't gave it a lot of thought, just a gut feeling it would work. So that question is very pertinent!
If we have an interface/protocol with a little mcu using a couple pins, we could easily have which pins are used configurable at compile time. In that way, both solutions could be work the same.
Exactly.Better yet, could even be dynamic using a flag in the eeprom...
(Greetings from Mr. Faraday...)
btw, redpine also have a version with an external u.fl antenna.
DaveyPocket wrote:Uzebox JAMMA doesn't have any controller ports
I forgot about that. All games get recompiled with some changes to work on Uzebox Jamma correct? If we have an interface/protocol with a little mcu using a couple pins, we could easily have which pins are used configurable at compile time. In that way, both solutions could be work the same.
There's an idea. From the beginning I never really expected people to be playing console based Uzebox games on the Uzebox JAMMA, thought people would be writing games oriented around the Uzebox JAMMA hardware (maybe that hasn't happened yet). Kind of like the UJ would go it's own small path. So it was meant to have games compiled specifically for the device. Not saying it HAS to be like that, just something previously intended to be.
uze6666 wrote:
Exactly.Better yet, could even be dynamic using a flag in the eeprom...
That's definitely a good idea.
What if we do this. Make the wireless module have BOTH a spot for a controller adapter AND an expansion header so it's all one board but people can choose between expansion header and second player controller connector. EEPROM flag will determine which to use.