Gamestation Pro

[bran479]

has anyone taken their apart i got the sd jammed in by accident.  took the two visible screws out but are there other under the footpads?

[Domeshtan]

2 hours ago, big_guitar said:

Yeah, different.  That one is for 2 controllers.  Mine is for a single controller using the left and right sticks (not a GSP controller).

I did another one for my PS Classic controller. Up/Down on pad for left tread, Triangle and X for right tread. I think I had the O button for fire. (Before I found out R2 could be mapped)

[xboxiso]

1 hour ago, Living Room Arcade said:

A while ago, people were discussing gamepads for GSP such as XBox 1 controller, but some said they didn't work.  What is the recommended gamepad for GSP so far?  

I use the Xbox One controller, (Microsoft version) wired with my GSP and it works great.

 

https://www.amazon.com/Xbox-Wireless-Controller-Black-one/dp/B01LPZM7VI/ref=pd_ci_mcx_mh_mcx_views_0?pd_rd_w=BknBc&content-id=amzn1.sym.225b4624-972d-4629-9040-f1bf9923dd95%3Aamzn1.symc.40e6a10e-cbc4-4fa5-81e3-4435ff64d03b&pf_rd_p=225b4624-972d-4629-9040-f1bf9923dd95&pf_rd_r=SVCC0KGZCJE3DTEN86KG&pd_rd_wg=uatph&pd_rd_r=0cedf8e2-96f2-4aee-b9b6-5db876b0583a&pd_rd_i=B01LPZM7VI

 

It's a wireless controller, but I connect it to the GSP with a mini usb to usb c cable.

[Riko]

I noticed this bit, which is in none of the 3d renders, there's these two black little buttons ( i think ) on the tops on left and right, i pray these are shoulder buttons, i cant tell though. Hoping.

Edited January 10 by Riko

[big_guitar]

3 hours ago, Living Room Arcade said:

A while ago, people were discussing gamepads for GSP such as XBox 1 controller, but some said they didn't work.  What is the recommended gamepad for GSP so far?  

I recall there were issues with some off brand Xbox compatible controllers, but my MS stellar shift model works fine.

[ComputerSpaceFan]

17 hours ago, xboxiso said:

From what I understand the new GSP joystick and gamepad are backwards compatible with the gen 1 GSP and will be sold separately for those of us that bought the gen 1 GSP. Also, they include rechargeable batteries which is a nice touch.

If so definitely Day One purchase from me.

[GB_Baker]

On 1/9/2024 at 6:09 AM, big_guitar said:

First you have to get it recognized in the retroarch cfg file passed with the "-c" parameter.  I don't believe any of the built-in cfg retroarch files have this defined as needed, since the GSP controllers only have a single stick.

Using xbox controller this includes these changes: 

 

[Right analog]: 

input_player1_r_y_plus_axis = "+4"
input_player1_r_y_minus_axis = "-4"
input_player1_r_x_minus_axis = "-3"

input_player1_r_x_plus_axis = "+3"

 

[left analog]: The left uses +0/-0 for "x axis" and +1/-1 for "y axis"

 

-- Then you use the Mame cfg file (bzone.cfg) created via mame-2003 (or retroarch after loading mame-2003 core) on your computer, where you configure the right analog with the left to work as navigation.  I haven't verified this since I last tested prior to getting the right-stick recognized, but it should now work so the left and right stick work together as navigation. Before that I made a bzone.cfg file that handled the navigation with the left-stick alone.  Elsewhere in this thread, I believe Domeshtan provided a mame cfg file to use 2 GSP controllers with bzone, but for a single controller, this should work, I'll try to verify this for xbox controller.  Also, if I make a version that works, I may want to have R3 act as a fire button (or as an additional fire button) so there would be no need to move your thumb.

 

Okay... I'm getting on board with the patched firmware. I have it installed and have the retroarch directory mirrored to the sdcard.  What exactly do you mean by passing the retroarch.cfg with - c? 

 

Can we change the autoconfig folder to read from the sdcard and copy all of the controller configs from the pc version of RA?  Is there a reason we can't change the joystick driver from udev to xinput or dinput?  Or is there a significant difference between Linux and Windows RA install. 

[big_guitar]

2 hours ago, GB_Baker said:

Is there a reason we can't change the joystick driver from udev to xinput or dinput?

For this linux implementation of retroarch on GSP, only "udev" is supported. 

More wordy detail:

Supposedly it's the most versatile option for linux, but I've read that some cores work better with "sdl2".

I believe the directory where the input drivers must be stored is on the firmware squash-fs partition that has no space available, and the only defined driver folder listed there is "udev".  Also, there is no 'autoconfig' folder where I think the controller configs would normally need to be.  I don't know of anyway to override where the controller config files would reside, although perhaps... if you copied the retroarch executable to SD, you could create an 'autoconfig' under where that resides, I haven't tried that, but I think it has to be under "/usr/share/libretro".

 

You can read about libretro linux driver details here, but as mentioned, only "udev" is listed on this GSP.  HOWEVER, you can establish Core Remap files or even Game Remap, which work well IF your primary retroarch configuration file has items defined properly.  If not, the remap references won't execute as expected.  I know, this may be a lot of things to consider, but if you believe your primary config file is good, then remapping might be helpful for specific cores or specific games.

2 hours ago, GB_Baker said:

What exactly do you mean by passing the retroarch.cfg with - c? 

The "-c" parameter allows you to pass a specific retroarch configuration file in the command line to execute retroarch.  This cfg replacement file can be defined on the sdcard.  This is where I have the plus/minus parameters update that allow the right analog stick to be recognized, although some non-mame cores do better since I don't have to map the right stick to buttons.  I decided I didn't need to fully mirror the retroarch source, as long as I have particular customizations accessible, plus I have those source folders extracted to my PC hard drive for reference.

 

So in the runme script, you could parse things out to trap the MAME or zip file so that you know which core you are working with.  I set a variable pointing to the config file I plan to use, based on other details (such as game location).  Here, the variable $activecfg is the file location of the custom retroarch config file to use.  From the retroarch folder, you might notice the file "zip_4_3.cfg", which I believe is the default for zip files using Mame, but the cfg file I posted previously is what I normally use for my xbox controller.  So below is the command line I normally use, but you don't have to write to a log file or have variables, I like to check all that happens that I can log especially if something does not execute as expected.

 

  /usr/bin/retroarch -y $y_param\
    -k "$1"\
    -c $activecfg\
    -L "$libPath" "$rom1" >$retrolog 2>&1;

 

It can be beneficial to see if the GSP recognizes different event values for your controller.  Here is a script attached that you can run (rename to runme.sh) just for the purposes of logging recognized device names.  You can use different folders to store the log data, you don't have to make ones like I have.

For example, if your controller ends up being recognized under "event1", you can run a separate script to pass that to record recognized event code values that could potentially be used in the configuration file, although the code values don't always match up with the description (mine has Event code 304 listed as South, but it really is my West button).  

 

A script to run if your controller is recognized with 'event1':   evtest --grab /dev/input/event1 >$evlog 2>&1;   

 

where $evlog is a variable for where to dump the results.  My xbox controller is reported as "Generic X-Box pad", but I imagine your PRO 2 controller will be listed as something else.

udevadm_runme.sh.txt

Edited January 10 by big_guitar

[big_guitar]

OK I take it back, I guess the autoconfig directory can be coded into the passed retroarch config file under joypad_autoconfig_dir... But I haven't tried this, will see if I can get it to recognize controllers. 

 

[update] I tested this, can't see any change so far, can't confirm it's identifying a controller file to work with.  No related controller info is spit out in my retroarch command line log.

I updated these settings: 

input_joypad_driver = "xinput"

 

This setting is where I have controller driver folders located on my sdcard, where there is a subfolder 'xinput'.

joypad_autoconfig_dir = "/mnt/sdcard/jlib/autoconfig/"

 

Edited January 10 by big_guitar

[8bitwidgets.com]

4 hours ago, ComputerSpaceFan said:

the new GSP joystick and gamepad

are there pictures of this new controllers?

[big_guitar]

4 minutes ago, 8bitwidgets.com said:

are there pictures of this new controllers?

In those genxgrownup youtube videos posted previously, you can see them in a glass case.

[8bitwidgets.com]

1 hour ago, big_guitar said:

genxgrownup youtube videos

cool, will find that video

[8bitwidgets.com]

yea i wonder if it's the same base size.  looks like i might be able to get away with not changing the coupler, but I'm sure someone with one will get the new one and we can find out for sure.  Depending on the improvements I might invest in one.  I'm a lefty so I'm not a huge fan of all of the buttons being on the left side, but I got used to playing on the 2600 so I'm sure I can adapt..  

[big_guitar]

5 minutes ago, 8bitwidgets.com said:

yea i wonder if it's the same base size.

Looks like it. 

I'm thinking they made the 'menu' button one of the top red buttons instead of having it on the back, and moved the a/b/c buttons to be all on the top face instead of B on the stick and C as a trigger.  Otherwise, I guess there's one extra button now, but I'm thinking not likely.

Edited January 10 by big_guitar

[big_guitar]

When reporting the 'features' from the retroarch command line, these are the only INPUT drivers recognized,

meaning a controller specific CFG file should likely also reference "udev" as the input driver (this is a parameter within the controller cfg file).

I made a "udev" subdirectory, and downloaded a matching "Generic_X-Box_pad.cfg" file associated with udev, but it made no difference.  It still works best if I verify that the retroarch cfg file passed in the "-c" parameter is as accurate as possible.  I could possibly pass a different CFG will more nul values, but I still doubt the controller cfg will be recognized.

 

Features:
  SDL:      SDL input/audio/video drivers: no
  SDL2:     SDL2 input/audio/video drivers: no
  X11:      X11 input/video drivers: no
  wayland:  Wayland input/video drivers: no
  UDEV:     UDEV/EVDEV input driver support: yes

Edited January 10 by big_guitar

[Atari8264]

28 minutes ago, 8bitwidgets.com said:

yea i wonder if it's the same base size.  looks like i might be able to get away with not changing the coupler, but I'm sure someone with one will get the new one and we can find out for sure.  Depending on the improvements I might invest in one.  I'm a lefty so I'm not a huge fan of all of the buttons being on the left side, but I got used to playing on the 2600 so I'm sure I can adapt..  

It will be hard pressing the fire button on the new joystick's base when playing Battlezone dual joysticks in the coupler.  The old sticks are better for that game and orobably others too.

[THX-1138]

22 hours ago, Riko said:

I noticed this bit, which is in none of the 3d renders, there's these two black little buttons ( i think ) on the tops on left and right, i pray these are shoulder buttons, i cant tell though. Hoping.

Looks like battery covers to me, exactly as they look on the pocket player.

 

[GB_Baker]

16 minutes ago, big_guitar said:

When reporting the 'features' from the retroarch command line, these are the only INPUT drivers recognized,

meaning a controller specific CFG file should likely also reference "udev" as the input driver (this is a parameter within the controller cfg file).

I made a "udev" subdirectory, and downloaded a matching "Generic_X-Box_pad.cfg" file associated with udev, but it made no difference.  It still works best if I verify that the retroarch cfg file passed in the "-c" parameter is as accurate as possible.  I could possibly pass a different CFG will more nul values, but I still doubt the controller cfg will be recognized.

 

Features:
  SDL:      SDL input/audio/video drivers: no
  SDL2:     SDL2 input/audio/video drivers: no
  X11:      X11 input/video drivers: no
  wayland:  Wayland input/video drivers: no
  UDEV:     UDEV/EVDEV input driver support: yes

Have you tried listing usb devices with keyboards and pads plugged in?  lsusb or usb-devices.  The custom controller cfg's are tied to specific device ID's.  

[8bitwidgets.com]

19 minutes ago, Atari8264 said:

The old sticks are better for that game

well good news is that i imagine the new systems will support the old controllers too so people won't have to abandon that option.. but yea it will put a crunch on some games that could really benefit from a top button press.  

[big_guitar]

50 minutes ago, GB_Baker said:

Have you tried listing usb devices with keyboards and pads plugged in?  lsusb or usb-devices.  The custom controller cfg's are tied to specific device ID's.  

I suppose I should add the vendor and product id to the cfg file (which was not in the generic file I downloaded) to see if it makes a difference (decimal version since HEX is reported with evtest).  Still, the only input driver has to be udev, I do see 8bitdo references only such as here  (from the same place I got my cfg).  Then again, there may already be a match in a different file name I could use.  From windows, found exact product match under "XBOX Series Controller", however, it's meant to be for "xinput" driver, not sure how it will respond since only udev can be assigned for input driver.

Edited January 10 by big_guitar

[big_guitar]

On the controller config files, I know the settings for the matching xinput product entry (from Windows) aren't correct for the Linux-udev environment given my previous testing, and the generic Xbox sample file is more accurate for using with GSP.  But so far I've not been able to verify that the file is even being recognized even with adding product id and vendor.  The runtime log has not otherwise provided evidence, and I've observed no obvious impact on controller behavior at this point. I believe even if there was an impact, the main Retroarch config files would still require updating, but there might be a few more tests I can try to see if the file is being seen at all. I have been able to verify that my core remap files have a definite impact for example, but so far not for the controller config files.

[big_guitar]

On 1/7/2024 at 5:33 PM, fluxit said:

I did manage to get MAME to display a menu via "mame2003_display_setup = "enabled"" that worked with the GsP stick,

This core option setting also worked for me using the xbox controller, but I wasn't able to exit the menu. I have not yet tried with a keyboard plugged in.

I think I unintentionally selected to generate dat xml, and it created a sizeable "mame2003.xml" file in my Games folder.

Ref:  [libretro INFO] [MAME 2003] Generating mame2003.xml

As the verbose parameter hasn't been working, the log_verbosity = "true" setting for the retroarch config file passed has yielded at least a little more data in the runtime log especially for Mame runs.  Sample retroarch runtime log data attached.

 

retro_log03.txt

Edited January 11 by big_guitar

[fluxit]

8 hours ago, big_guitar said:

This core option setting also worked for me using the xbox controller, but I wasn't able to exit the menu. I have not yet tried with a keyboard plugged in.

I think I unintentionally selected to generate dat xml, and it created a sizeable "mame2003.xml" file in my Games folder.

Ref:  [libretro INFO] [MAME 2003] Generating mame2003.xml

As the verbose parameter hasn't been working, the log_verbosity = "true" setting for the retroarch config file passed has yielded at least a little more data in the runtime log especially for Mame runs.  Sample retroarch runtime log data attached.

 

retro_log03.txt 4.29 kB · 1 download

Sorry I didn't respond to your previous posts.  I tend to grind away in my investigations, using up most of my mental energy, come up with a nugget, and then post it.  Here's another.  I have RA's menu mostly working.  It won't save to the current .cfg file, and I'm not sure why.  Per the /usr/bin/retroarch binary, there are hardcoded defaults to /data(mount point for the ext2 partition, the same as XDG_CONFIG_HOME environment variable,) /userdata(symlink to /data,) and HOME(set to /.)

 

This .cfg is based on the GsP's md_4_3.cfg.

 

Here's a diff of the changes for use and reference, not all are pertinent to getting the menu working.  I also enabled autoconfig, and was still trying to get xmb working, but I'm giving up on that.  I've tried colors, fonts, and languages.  Nothing seems to get me more than those dang black bars on xmb.

 

Oh, and no -k or -y on the command line.  Counter to what I stated previously(though -k 1 does enable saving,) -k seems to force RA into the save menu when the menu button is pressed, even if the save menu is disabled via the cfg file.  -y seems to subtly alter the behavior of the controller, though I'm not sure how, exactly.  Since the only "12" I saw in the cfg was the language setting, I'd previously assumed that it was language related.  The results from this do give some more insight into how MyArcade implemented plug and play for their controllers.

 

1c1
< all_users_control_menu = "true"
---
> all_users_control_menu = "false"
5c5
< assets_directory = "/sdcard/agsp/retroarch/"
---
> assets_directory = "/usr/lib/libretro/retroarch/"
2641c2641
< joypad_autoconfig_dir = "/sdcard/agsp/retroarch/autoconfig"
---
> joypad_autoconfig_dir = "~/userdata/retroarch/autoconfig"
2657,2658c2657,2658
< menu_core_enable = "true"
< menu_driver = "rgui"
---
> menu_core_enable = "false"
> menu_driver = "xmb"
2677,2678c2677,2678
< menu_show_advanced_settings = "true"
< menu_show_configurations = "true"
---
> menu_show_advanced_settings = "false"
> menu_show_configurations = "false"
2681c2681
< menu_show_information = "true"
---
> menu_show_information = "false"
2687c2687
< menu_show_quit_retroarch = "true"
---
> menu_show_quit_retroarch = "false"
2697,2698c2697,2698
< menu_wallpaper = ""
< menu_wallpaper_nosave  = ""
---
> menu_wallpaper = "/usr/lib/libretro/retroarch/xmb/bg_background_other.png"
> menu_wallpaper_nosave  = "/usr/lib/libretro/retroarch/xmb/bg_background_other_nosave.png"
2771c2771
< quick_menu_show_save_load_state = "false"
---
> quick_menu_show_save_load_state = "true"
2787c2787
< rgui_config_directory = "/sdcard/agsp/retroarch/config"
---
> rgui_config_directory = "~/data/retroarch/config"
2800c2800
< savestate_thumbnail_enable = "false"
---
> savestate_thumbnail_enable = "true"
2879c2879
< xmb_font = ""
---
> xmb_font = "~/usr/lib/libretro/retroarch/font.ttf"

ramenu.cfg

Edited January 11 by fluxit

[big_guitar]

32 minutes ago, fluxit said:

I have RA's menu mostly working.

Thank you for the differences and sample file, I tried using a keyboard with the menu, but that didn't work, have you tried that? 

I will try setting some of your differences that I haven't yet implemented when I get a chance, thank you!

[big_guitar]

41 minutes ago, fluxit said:

-k seems to force RA into the save menu when the menu button is pressed

Is that only when k is a specific value, or if k is passed at all? I have seen intermittent menu button not working, but not consistently.

Edited January 11 by big_guitar