I decided to turn my Pi upside down to find out why the heck PPSSPP wasn't recognizing my gamepad. Below is a little journal of my journey, describing what I had to do to fix things. Please, bear in mind that I'm a Linux newbie, and this is a tutorial of sorts intended to those just as new to it as me.

So, a little background information: I use a PS3 Logitech ChillStream (identified as a “PS3/USB Corded Gamepad”) with my RPi. This nice little gamepad works perfectly with everything EmulationStation throws at me... Except for ppsspp (not to be confused with lr-ppsspp: it DOES work with that core). It wasn't an in-emulator mapping problem, the damn thing didn't even recognize button pressing when I tried binding stuff.

I've read elsewhere that controller recognition was a hardcoded part of PPSSPP, and that you couldn't do much to make it see a controller it isn't seeing. But after two months of trying to find documentation and workarounds for this, I decided that I had enough. I would look under the hood and see how PPSSPP detected controllers myself.

By navigating to /opt/retropie/emulators/ppsspp/assets, I was pleasantly surprised to see that there is actually a list of recognized controllers inside gamecontrollerdb.txt, presented in a very readable way. For sure, my gamepad wasn't listed there, under either of its names. I had at last pinpointed the source of my problems.

Searching around the web, I found out that the file originates from a tool in SDL2 , a development library that provides low level access to audio, keyboard, mouse, joystick and graphics hardware via OpenGL. That tool is called controllermap. Luckily, if you originally set up your RPi using NOOBS to install a full Raspbian OS, you'll already have the required SDL2 library lying around (in my case, libsdl2-dev-2.0.6). If you don't have that library, just find and install it. The library won't come with controllermap, though, so you'll have to compile and install it yourself.

If you're a newbie like me, that will sound more complicated than it really is. I followed the guide found here, but in easier terms (remember to substitute the version number for the version of the SDL2 library you have):

Compile controllermap
1.1. wget https://www.libsdl.org/release/SDL2-2.0.6.tar.gz
1.2. tar -zxvf SDL2-2.0.6.tar.gz
1.3. cd SDL2-2.0.6/test
1.4. ./configure
1.5. make controllermap
1.6. mv controllermap ../..
1.7. cd ../.. Connect the gamepad. ./controllermap Does it output anything? If yes, great, you can keep going! For the next step, you'll have to drop out to CLI (that is, you can't be running a terminal in an x environment) ./controllermap 0 > out.txt You should see an illustration of a gamepad on the screen now. IF YOU DON'T, JUST PRESS ESC. Check the error log, you must be missing some image files. In my case, they were axis.bmp, button.bmp and controllermap.bmp. Just fetch those files in SDL2-2.0.6's /test/ folder and put them right next to controllermap, at /home/pi, and try again. Press your controller's equivalent of the highlighted buttons. If you want to skip a button, press the spacebar. The results will be saved to out.txt. You may now remove the SDL2 source and object files:
7.1. rm -r SDL2-2.0.6
7.2. rm SDL2-2.0.6.tar.gz

If you run into any problems, please refer to the guide linked above. Anyways, you can now check the output file in /home/pi and see that it has the same syntax as the PPSSPP's gamecontrollerdb.txt. Now all you have to do is copy the line in out.txt and paste it at the end of gamecontrollerdb.txt, and ppsspp should now see your controller! Bear in mind that you need to have root privileges to edit gamecontrollerdb.txt, so just sudo leafpad and browse for the file. You will probably need to rebind the controls in the emulator, but that is extremely straightforward!

Well hope this can be of use to someone who was just as lost as I was. For reference, the following is the output line from my controllermap. If you happen to use the same gamepad that I do, just go ahead and paste it in your gamecontrollerdb.txt and ignore everything else I said! =D

030000006d040000d1ca000011010000,PS3/USB Corded Gamepad,platform:Linux,a:b1,b:b2,x:b0,y:b3,back:b8,start:b9,leftstick:b10,rightstick:b11,leftshoulder:b4,rightshoulder:b5,dpup:h0.1,dpdown:h0.4,dpleft:h0.8,dpright:h0.2,leftx:a0,lefty:a1,rightx:a2,righty:a3,lefttrigger:b6,righttrigger:b7,

@rsn8887: To answer your first question, @meleu has a great script that you can use to change which controllers are used for player 1/2/3, etc.

@pkg04011979 Please do not post a support request without first reading and following the advice in https://retropie.org.uk/forum/topic/3/read-this-first

i don't know the reason some shaders work and others don't, can't help you there sorry. but my best guess would be they are too powerful for the pi/ARM architecture and fail silently. with regard to this particular shader set, you might want to try using the files from the repo as they were just updated yesterday to "fix dumb typo" https://github.com/libretro/glsl-shaders/tree/master/ntsc

well I guess running 2010 core on the pi with an old game like that might not be too bad..I'll try it thanks. :)

@cookingissues the keyboard IS a retropad, but that's not your problem.

as i said, i think your problem is that you deleted all the retroarch.cfgs. you can probably restore them by reinstalling retroarch and mame2003 and then running emulationstation's input configuration again.

@dankcushions said in Memory Split Does What? Increase or leave alone?:

oh sure, but i would hope they would also upgrade the bus before slapping in faster memory, otherwise it would just have to be downclocked :)

It was more of a compatibility thought when I read that DDR3 would definitely help or maybe it was just a quick wishful thinking of faster memory and a better gaming experience! :)

Is the memory DDR3 (LPDDR3?) compatible with the ARM8 and they used slower memory to keep a price point. Basically is it possible to upgrade the RAM architecture only.

I would assume if the ARM8 supports faster memory (DDR3) and it was a pricing decision then no "bus" modifications would be needed or even downclocking the RAM as the CPU is able to waste clock cycles (idle time) waiting for slower RAM or another way to look at it is the CPU will dictate the clock speed it receives data regardless of RAM clock speed be it faster or slower but not the other way around.

My thought keeps going back to the SoC also. It seems like it's the "traffic cop" (component communication) and would dictate speed/type or at least need to sync the speed between components. Maybe it's just a bridge and works at backplane speeds (thinking like a switch here) leaving clock speeds to the components themselves.

Some CPU's can use both memory types (DDR3 or DDR4) but it's the chipset (i.e.-motherboard) that forces you to use one or the other.

You don't see memory overclocked as frequently it seems. In most cases but not all the returns are minimal vs. saying a quick tweak to the FSB multiplier but some squeeze every percent they can out of their PC and that includes memory.

When you buy a new mobo most times you're also buying a new CPU & memory due to the socket type and memory architecture differences. Your basically forklifting your PC. Possibly reusing the power supply and few peripherals like the CR-ROM & maybe your case, fans, possibly the graphics card, etc. I build all mine from scratch.

BUT when doing large compiles you can easily max out the system ram, and then it uses slower, SD card-killing swap. this is why people shouldn't raise the GPU split. helpful for nothing.. unhelpful for something!

Good point! That seems like a very solid reason for keeping the default allocation split as it will be helpful in certain compiles of some of the emulators or most? I know some apps will leverage every single byte you give it.

@edmaul69 Thanks for the response.

Yes, multiple times. Also performed update several times. And reset the config files and roms.

Following other suggestions, I reset the PS3 controller, changed controllers, and removed/reinstalled the PS3 driver. Also, I deleted the retroarch joypad directory. No change to the controller problem yet.

For more details; the joysticks work when configuring the controller. That is, they register properly and have an axis movement identified as the input. But when controller configuration is over, they still do not work.

Here's another good link along with Bakers to MAME setup. It covers pretty much every supported version on the Pi. The 'Arcade' drop down on the left shows the different sections even how to build and validate sets.

https://retropie.org.uk/docs/MAME/

I do keep most of the supported version sets non-merged (ROM set type not emulator) zipped and just extract the ROMs as needed. There is a lot of crossover between version sets if you plan to implement them all it's pretty redundant. Some emulators run certain games better than others so it's usually is a mix-and-match of MAME emulators and ROM/game subsets.

@stelario

Have you transferred any ROMs to your Pi. If you have not transferred any ROMs you won't see the emulators. Check out transferring ROMs in the wiki.

@xsportseeker well i guess i read that all for nothing!! :) yeah im glad i read your second post because i was about to point you to that file. Glad you got it working. If you are interested in making .sh files to have all dos games show up in the gamelist or any other configuring help in dosbox feel free to ask.

@retroprogrammer How do you select "Exit: save for all games"?

@psyke83 Cheers!

@com_gunner said in Conflicting joysticks?:

https://k60.kn3.net/taringa/C/7/6/C/F/8/comgunner/08F.jpg

Hi every one.

I used command line in Terminal

lsusb

and I got this information:

Bus 001 Device 004: ID 0810:e001 Personal Communication Systems, Inc. Bus 001 Device 005: ID 0424:7800 Standard Microsystems Corp. Bus 001 Device 003: ID 0424:2514 Standard Microsystems Corp. USB 2.0 Hub Bus 001 Device 002: ID 0424:2514 Standard Microsystems Corp. USB 2.0 Hub Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

How to know where is mine?
I use this one oncoder:
alt text

@zerojay

Perfect, if there is a pull request for it I can wait for it to be incorporated into a future update and I can update. For now, lr-reicast seems to actually be working pretty well for the couple of games i've tested.

I will have a look for the pre-compiled binary though and perhaps give it a try.

Cheers