yukky37x
Posts: 3
Joined: Tue Oct 30, 2018 4:26 am

Re: Multi-console gamepad driver for GPIO

Mon Nov 05, 2018 1:26 am

I appreciate your reply. I succeeded in changing the GPIO number of CLOCK and LATCH.

Code: Select all

450,451c450,451
< #define GC_NES_CLOCK	0x400
< #define GC_NES_LATCH	0x800
---
> #define GC_NES_CLOCK	(1<<22)
> #define GC_NES_LATCH	(1<<23)
1164,1165c1164,1165
< 		*(gpio+1) &= ~0x3f;
< 		*(gpio+1) |= 0x09;
---
> 		*(gpio+2) &= ~0xfc0;
> 		*(gpio+2) |= 0x240;
However, the pad-specific GPIO change has not been successful. I made the following changes, but it does not work with GPIO 27, and it is still working with GPIO 3 (Only button 0 is working)

Code: Select all

129c129
< 	PAD6_GPIO = 3
---
> 	PAD6_GPIO = 27
If there are other places I have to change, would you please tell me?
marqs wrote:
Sat Nov 03, 2018 11:01 pm
yukky37x wrote: Hello. I use RetroPie 4.4 and output video to 15 Khz Arcade Cabinet with VGA 666. I tried changing GPIO pins using the source code previously written in this forum , But it was not able to work with the current version gamecon_gpio_rpi-1.3. I would like to use 3 SNES controllers, and available GPIOs are 22-27.
Please tell me where to modify the current version source?
You need to change both common (clk, latch) and pad-specific GPIO assignments. The latter one should be simple, search "enum pad_gpios" from gamecon_gpio_rpi.c. For the former, you'll need to modify GC_NES_CLOCK and GC_NES_LATCH defines to (1<<TARGET_GPIO) and the 2 lines under /* set clk & latch pins to OUTPUT */ comment to match those target gpios. For example, if you reserve GPIO22 for clock and GPIO23 for latch, change them as follows:

Code: Select all

#define GC_NES_CLOCK	(1<<22)
#define GC_NES_LATCH	(1<<23)
...
/* set clk & latch pins to OUTPUT */
*(gpio+2) &= ~0xfc0;
*(gpio+2) |= 0x240;

marqs
Posts: 212
Joined: Sat Jun 09, 2012 11:34 am

Re: Multi-console gamepad driver for GPIO

Mon Nov 05, 2018 9:12 pm

On closer inspection a few other changes are also needed. I replaced hard-coded values on the functions and uploaded the code to a test branch. With that it should be enough to just change the IDs inside "enum pad_gpios" and "enum common_gpios". The code compiles OK but it'll take a while until I can test it - feel free to try if you like. N64 & GC still need a few changes but for other pads it should be now possible to freely select GPIOs between 0 and 31.

yukky37x
Posts: 3
Joined: Tue Oct 30, 2018 4:26 am

Re: Multi-console gamepad driver for GPIO

Wed Nov 07, 2018 12:25 am

Great! The controllers worked even if the GPIO numbers are changed!

Thank you for your quick response. It is very much appreciated.
marqs wrote:
Mon Nov 05, 2018 9:12 pm
On closer inspection a few other changes are also needed. I replaced hard-coded values on the functions and uploaded the code to a test branch. With that it should be enough to just change the IDs inside "enum pad_gpios" and "enum common_gpios". The code compiles OK but it'll take a while until I can test it - feel free to try if you like. N64 & GC still need a few changes but for other pads it should be now possible to freely select GPIOs between 0 and 31.

carlj
Posts: 3
Joined: Sun Dec 02, 2018 12:13 pm

Re: Multi-console gamepad driver for GPIO

Sun Dec 02, 2018 12:30 pm

Hi folks,

i have a problem with gamecon_gpio_rpi driver and original snes pad SNSP-005 connected to gpio in my raspberry pi 3b+.

In jstest, when i press B button on my snes pad, all button become in on state and when I release the B button on my snes pad all return to off state. When I press any other button on the snes pad nothing appen.

I've connected two snes controller to my rpi gpio, and i have the same result with both; all is connected as described in wiki.

this is my configuration
option gamecon_gpio_rpi map=0,0,0,0,1,1

snespad 1 is connected to rpi gpio2
snespad 2 is connected to rpi gpio3

wiring
3v3 ---> snes pin1
rpi gpio 10 ---> snes pin2 -- Data Clock
rpi gpio 11 ---> snes pin3 -- Data Latch
rpi pin n.39 --> snes pin7 -- Ground

Can you help me?

marqs
Posts: 212
Joined: Sat Jun 09, 2012 11:34 am

Re: Multi-console gamepad driver for GPIO

Sun Dec 02, 2018 10:25 pm

carlj wrote:In jstest, when i press B button on my snes pad, all button become in on state and when I release the B button on my snes pad all return to off state. When I press any other button on the snes pad nothing appen.
I recall some people had similar issue until they added 3.3V->5V level shifters on clock and data pins AND/OR powered SNES pad from 5V and added 3.3V clamp on data output pin.

carlj
Posts: 3
Joined: Sun Dec 02, 2018 12:13 pm

Re: Multi-console gamepad driver for GPIO

Mon Dec 03, 2018 11:42 am

marqs wrote:
Sun Dec 02, 2018 10:25 pm
carlj wrote:In jstest, when i press B button on my snes pad, all button become in on state and when I release the B button on my snes pad all return to off state. When I press any other button on the snes pad nothing appen.
I recall some people had similar issue until they added 3.3V->5V level shifters on clock and data pins AND/OR powered SNES pad from 5V and added 3.3V clamp on data output pin.
Thank you for the reply!

Can you explain me with a detailed schematic and components to use in order to obtain this result?

Sorry but i am not an Expert with Electronics and components!

EDIT: I have made two test using a bidirectional logic level converter 5v to 3v:
- In the first test i have connected the snespad to 5v from raspberry and used the level converter to connect data pin from snes pad to gpio.
- In the second test i have connected also the latch and clock pin from snespad using the level convert to raspberry gpio.

In both tests i got the same result as the initial situation..

Any suggestion??

ps: this is the level converter https://www.aliexpress.com/item/Free-sh ... 50778.html

marqs
Posts: 212
Joined: Sat Jun 09, 2012 11:34 am

Re: Multi-console gamepad driver for GPIO

Mon Dec 10, 2018 9:09 pm

Have you double-checked that clock and latch lines are connected the right way? If they are reversed, the end result could be something like your initial description.

carlj
Posts: 3
Joined: Sun Dec 02, 2018 12:13 pm

Re: Multi-console gamepad driver for GPIO

Tue Dec 11, 2018 1:27 pm

marqs wrote:
Mon Dec 10, 2018 9:09 pm
Have you double-checked that clock and latch lines are connected the right way? If they are reversed, the end result could be something like your initial description.
Yes, i have also tryed to switch clock and latch Lines with no result..

Currypaul
Posts: 5
Joined: Tue Oct 31, 2017 8:39 pm

Re: Multi-console gamepad driver for GPIO

Wed Feb 20, 2019 10:41 am

Hi at all again,

I've experienced some problems lately with my SEGA Megadrive/Genesis 3+1 Button Controllers.
When plugging the controller correctly to my raspberry Pi 2B I cannot use all buttons as expected.

I've mounted the controller with modprobe and then tried with jstest.
The X and Y-Axis are working as expected, but the buttons A, B, C and Start won't work correctly.
When pressing A, nothing happens. Same for C and Start. When pressing B, Button 0 and 1 are checked as "on".

I'm owning in total 4 Megadrive controllers and checked them all, the problem is everytime the same, regardless of on which port I'm connecting my controller.
So this got me thinking, that either something in the driver is wrong or something in my wiring is systematically wrong.

Which infos do you need to help me here?

Here I provide you an "screenshot" of my bug:
https://drive.google.com/file/d/10sHZeT ... sp=sharing

jackal123uk
Posts: 1
Joined: Wed Jul 06, 2016 8:59 pm

Re: Multi-console gamepad driver for GPIO

Sat Mar 09, 2019 9:01 pm

Hi all,

I've just read through this entire thread looking for more info on configuring GameCube controllers but appear to have drawn a blank - is there a definitive guide anywhere?

I've successfully used the gamecon driver in the past for attaching SNES controller with no problems whatsoever but I'm having a harder time with the GameCube controller. It looks to be connected and working but I'm getting odd phantom inputs - see attached grab from the test, the bounded inputs from the c-stick weren't done by me.
Controller_Test_Annotated .jpg
Controller_Test_Annotated .jpg (161.33 KiB) Viewed 519 times


Reading around (chiefly https://wiki.teria.org/howto/index.php? ... d_glitches and http://www.davesblog.com/blog/2013/12/2 ... pberry-pi/) I see there's potentially several issues but some of the solutions are conflicting. I've implemented some of the proposed fixes with little affect, however, I am using a 3rd party controller. Unless anyone advises different I'm going to source an original controller before doing any more testing to save potentially wasting any time.

Hopefully someone has some pointers on this one, if not I'll keep plugging away (once my new controller arrives) and if I have any joy I'll be sure to pop back to share.

marqs
Posts: 212
Joined: Sat Jun 09, 2012 11:34 am

Re: Multi-console gamepad driver for GPIO

Thu Mar 14, 2019 10:40 pm

Currypaul wrote:
Wed Feb 20, 2019 10:41 am
I've mounted the controller with modprobe and then tried with jstest.
The X and Y-Axis are working as expected, but the buttons A, B, C and Start won't work correctly.
When pressing A, nothing happens. Same for C and Start. When pressing B, Button 0 and 1 are checked as "on".
That sounds like a wiring problem. If button 0 and 1 (supposedly corresponding A and B) get identical events from pressing 'B', it indicates that the select line could be stuck at 1.
jackal123uk wrote: Reading around (chiefly https://wiki.teria.org/howto/index.php? ... d_glitches and http://www.davesblog.com/blog/2013/12/2 ... pberry-pi/) I see there's potentially several issues but some of the solutions are conflicting. I've implemented some of the proposed fixes with little affect, however, I am using a 3rd party controller. Unless anyone advises different I'm going to source an original controller before doing any more testing to save potentially wasting any time.
GC and N64 controllers are most problematic due to their async protocol so even small tweaks can make a difference. Getting an official controller is a good idea, it's more likely people have used that when testing/improving the driver.

Return to “Gaming”