Gamestation Pro

[big_guitar]

Really, having no issues with RA 1.17.0 so far (outside of general GSP hardware limitations as might be expected)! 

 

I guess I thought that the rgui_config_directory setting was related to the menu_driver, but it appears not since even with 'ozone' it still finds the option files (.opt) I had defined previously under rgui_config_directory... 

 

Still controller funkiness with GB's gearcoleco build under RA 1.17.0.  FBNeo with cv subsystem is still the best option there. 

So far not noticing anything different from other recent linux-arm core builds, but I haven't gotten to all of them yet.   🙂

Edited February 13 by big_guitar

[Brad_from_the_80s]

Custom firmware just dropped, for those interested:

 

 

It's complex enough (but not too bad) I felt it would need its own thread.  This achieves pretty much the same customization capability as my cfw for Atari Flashbacks.

[Vic20Ian]

12 hours ago, Brad_from_the_80s said:

Custom firmware just dropped, for those interested:

 

 

It's complex enough (but not too bad) I felt it would need its own thread.  This achieves pretty much the same customization capability as my cfw for Atari Flashbacks.

What I like about this is the safe approach, replicate the firmware on the SD and then adjust it and experiment. 

 

Remove the SD card or delete the files and it is back to stock.

 

If you rebuild it can take a few minutes on an old SD card....time to buy a faster one

[donjn]

high-end LCD monitor for gaming; it has 2ms and is fine-tunedI've asked for this before but can't quite get a solid answer.

 

I am curious about input lag. I might start a new thread on this. Can anyone who has played this (wired, not wireless) tell me if there is any input delay? I need someone sensitive to this like me, and has played Atari etc on a CRT and possibly also has the Atari 2600+ which has almost no lag at all.

 

I know there were issues with paddles but I am talking about regular games using the joystick.

 

Please do not respond with "game mode" or it "depends on my tv" etc.

I have a high end LCD monitor for gaming, it has 2ms and is fine tuned for no lag at all. If there is any, I will notice.

 

 

Edited February 14 by donjn

[GB_Baker]

So close to being able to configure the paddle in the for the GSP controller to run in Mame2003 and Stella2014 when running from the menu of Retroarch 1.17.0.  Initiating with the runme.sh to launch retroarch from a paddle game like Breakout in the GSP UI keeps the paddle axis active.  I've been using evtest, jstest and evdev-joystick through the UART USB Serial Interface as described by @4096kb.  The paddle axis is +0.  Absolute rotation range is kind of weird -801 to 21894.  You can make changes to the range, deadzone, and fuzz with evdev-joystick but they disappear  when you unplug the usb cable and reconnect.  Not sure if we can modify the edev or udev rules.  I did create a custom configuration for the GSP joystick if you use autoconfig.  Just place in your autoconfig/udev folder.   I set the r2 trigger as the +0 axis and renamed it paddle.  Home gets the main menu and the menu button on the back of the controller gets the config menu in mame2003.

 

Also attached the jstest and evdev-joystick that I have been using.  I have been able to get breakout to run pretty well in stella2014 using the stellapaddle input in the core options and input remap.  Maybe someone smarter than me can get the paddle calibrated.  Currently the r2 does not engage until about 3/4 turn to the right in remote retropad.

jstest evdev-joystick ShanWan Twin USB Joystick with Paddle.cfg

[Shannon]

I think some cores have a default "deadzone" for analog input.  Usually it is 4% or 5%.  On top of that Retroarch has it's own default "deadzone" as well.

 

I usually set all of my emulator deadzones to 0 and then set Retroarch to the "global" deadzone that I prefer.

[xboxiso]

I have not yet had a chance to check out your custom firmware @Brad_from_the_80s but intend to and am very excited about this. Thank you for making it for the GSP. I have really enjoyed your custom firware for the flashback units. Does this allow us to add additional RetroArch cores to the GSP? I really would like to have Intellivision and Colecovision running on this system.

[Vic20Ian]

17 minutes ago, xboxiso said:

I have not yet had a chance to check out your custom firmware @Brad_from_the_80s but intend to and am very excited about this. Thank you for making it for the GSP. I have really enjoyed your custom firware for the flashback units. Does this allow us to add additional RetroArch cores to the GSP? I really would like to have Intellivision and Colecovision running on this system.

I think you can pretty much launch anything you want that compiles.

 

It all runs from the SD so you can change the startup script or mod the exisiting firmware.

[+Mocotechprfl]

Jon from GenXGrownup, aka @jonreddick just posted a quick preview video on @Brad_from_the_80s custom firmware update. Jon said he would follow up soon with a more detailed video.

Brad, congrats for the recognition!
 

 

[jonreddick]

1 hour ago, Mocotechprfl said:

Jon from GenXGrownup, aka @jonreddick just posted a quick preview video on @Brad_from_the_80s custom firmware update. Jon said he would follow up soon with a more detailed video.

Brad, congrats for the recognition!
 

 

I love shouting out the generous efforts of talented people! 😁

[big_guitar]

18 hours ago, xboxiso said:

I have not yet had a chance to check out your custom firmware @Brad_from_the_80s but intend to and am very excited about this. Thank you for making it for the GSP. I have really enjoyed your custom firware for the flashback units. Does this allow us to add additional RetroArch cores to the GSP? I really would like to have Intellivision and Colecovision running on this system.

Of course Brad's work allows for the runme scripts to run as with what was established previously with @fluxit, which already allows for the means to run Intellivision and CV cores, as I've demonstrated.  What needs to be tested is adding them to the GUI, but I've not had the time to test as I'm still trying to get some RA 1.17.0 controller remappings corrected currently.

[big_guitar]

On 2/15/2024 at 1:32 AM, GB_Baker said:

Home gets the main menu and the menu button on the back of the controller gets the config menu in mame2003.

So if "16" is home, is "8" the value associated with the "y_btn" for mame?  I will test that cfg later.  Although I think I'm using x as 8 and y as 4.

For my generic xbox cfg, I comment out/remove the menu toggle to free up any button on the controller for other purposes.

 

Also, in my RA cfg, I set   remap_save_on_exit = "false",  because I like to save comments in my remapping files. 

Those comments in remap files get wiped out when this is set to 'true'.  Of course I try to back things up beforehand if I am going to update anything via GSP.

Edited February 16 by big_guitar

[GB_Baker]

On 2/15/2024 at 1:51 AM, Shannon said:

I think some cores have a default "deadzone" for analog input.  Usually it is 4% or 5%.  On top of that Retroarch has it's own default "deadzone" as well.

 

I usually set all of my emulator deadzones to 0 and then set Retroarch to the "global" deadzone that I prefer.

I didn't realize my analog engagement was set to 0.5 in RA.  Now the rotation registers from the start.  Thanks. 

[WaverBoy]

So, do the controllers suffer from input lag, or not? Gen X Grownup shows himself playing a round of Kaboom with the firmware update, with paddle sensitivity set to low, and he gobbles up all the bombs with ease and says it works really well.

[GB_Baker]

4 hours ago, big_guitar said:

So if "16" is home, is "8" the value associated with the "y_btn" for mame?  I will test that cfg later.  Although I think I'm using x as 8 and y as 4.

For my generic xbox cfg, I comment out/remove the menu toggle to free up any button on the controller for other purposes.

 

Also, in my RA cfg, I set   remap_save_on_exit = "false",  because I like to save comments in my remapping files. 

Those comments in remap files get wiped out when this is set to 'true'.  Of course I try to back things up beforehand if I am going to update anything via GSP.

Yeah I might remove the home since I switched to using the select+start combo for menu.  Then I would probably make the home button Y.  Still not sure what to do about the button that registers as 316 on the GSP controller. 

[donjn]

8 minutes ago, WaverBoy said:

So, do the controllers suffer from input lag, or not? Gen X Grownup shows himself playing a round of Kaboom with the firmware update, with paddle sensitivity set to low, and he gobbles up all the bombs with ease and says it works really well.

I asked this a few questions up, these guys are into their own thing right now.

 

[big_guitar]

1 hour ago, GB_Baker said:

Still not sure what to do about the button that registers as 316 on the GSP controller. 

Is that the event code for the menu button with GSP controllers?  When I press it for retropad assignment, it seems to be the equivalent of keyboard "q" 

 

1 hour ago, GB_Baker said:

I didn't realize my analog engagement was set to 0.5 in RA.

So did you set your input_axis_threshold to 0 then? 

[GB_Baker]

27 minutes ago, big_guitar said:

Is that the event code for the menu button with GSP controllers?  When I press it for retropad assignment, it seems to be the equivalent of keyboard "q" 

 

So did you set your input_axis_threshold to 0 then? 

Yes and yes. 

[Shannon]

13 hours ago, GB_Baker said:

Yeah I might remove the home since I switched to using the select+start combo for menu.  Then I would probably make the home button Y.  Still not sure what to do about the button that registers as 316 on the GSP controller. 

 

I never liked the select+start combo because it messes with the Start and Select buttons in the retroarch stella core which can be bad when in the middle of a game. 

 

[GB_Baker]

13 hours ago, donjn said:

I asked this a few questions up, these guys are into their own thing right now.

 

Honestly.  They feel pretty responsive to me, but I'm not that sensitive to it.  You always have the option to plug them in with your own usb-c cables if wireless is an issue.   I also use an 8bitdo Pro 2 which works very well, but must be plugged in. 

[big_guitar]

On the RA 1.17.0 build, when using the 2 wireless GSP controllers at the same time, I've been unable to disassociate the joystick/dpad activities from the 2 controllers.

I'm not encountering this issue with the other buttons, only the stick/dpad. So any unique remap actions I define for stick1 are duplicated on stick2, and vice-versa.  So if I move the stick on controller2, that action is also performed on the first controller (in a combined fashion for any dpad actions).

 

I can define particulars for the buttons that are unique, no issues there (a/b/c for example when unique on 2nd controller are not duplicated on the first controller).

But no matter what I define for player1 up/down/left/right, those actions are duplicated on the player2 controller.

Same thing for player2 up/down/left/right, whatever settings I define are performed against both p1 and p2 controllers regardless of which stick is used to perform the action.

I've not had the issue under the funky MA RA build, haven't been able to determine the cause as to what's causing this with the 1.17.0 version.

 

The joypad indexes are unique, and even with unique remap port numbers, the actions are combined and duplicated on both controllers.  But the fact that the buttons are not duplicated, only the dpad, is quite an oddity.

[GB_Baker]

4 hours ago, big_guitar said:

On the RA 1.17.0 build, when using the 2 wireless GSP controllers at the same time, I've been unable to disassociate the joystick/dpad activities from the 2 controllers.

I'm not encountering this issue with the other buttons, only the stick/dpad. So any unique remap actions I define for stick1 are duplicated on stick2, and vice-versa.  So if I move the stick on controller2, that action is also performed on the first controller (in a combined fashion for any dpad actions).

 

I can define particulars for the buttons that are unique, no issues there (a/b/c for example when unique on 2nd controller are not duplicated on the first controller).

But no matter what I define for player1 up/down/left/right, those actions are duplicated on the player2 controller.

Same thing for player2 up/down/left/right, whatever settings I define are performed against both p1 and p2 controllers regardless of which stick is used to perform the action.

I've not had the issue under the funky MA RA build, haven't been able to determine the cause as to what's causing this with the 1.17.0 version.

 

The joypad indexes are unique, and even with unique remap port numbers, the actions are combined and duplicated on both controllers.  But the fact that the buttons are not duplicated, only the dpad, is quite an oddity.

Does this happen while playing games on all cores or just while navigating RA menus?  RA can be set up to use all controllers for navigation. 

[big_guitar]

15 hours ago, GB_Baker said:

Does this happen while playing games on all cores or just while navigating RA menus?  RA can be set up to use all controllers for navigation. 

It's not about the menus, I'll see how this goes on other cores, but having some other issues with  1.17.0...

 

With FBNeo, the older linux MA-RA would state...

[libretro INFO] [FBNeo] Searching all possible locations for romset [romname]

..

[libretro INFO] [FBNeo] Romset found at [location]

 

The Windows version of 1.17.0 also reports this log detail exactly as above as well...

 

The linux-arm RA 1.17.0 does not report the romset load process like above, and is not spitting out as much [libretro INFO] despite setting the libretro log level to info or debug, but it also seems to not be 'searching' other locations.  I think much of the related libretro documentation is a bit outdated and unclear at times, but it's odd to wonder what this build of RA must be expecting. 

Edited February 18 by big_guitar

[big_guitar]

So unfortunately, using a second core, and feeding the exact same config file, same core library, and same rom file into the different RA builds...

 

-the 1.17.0 build still duplicates the GSP stick actions on both GSP controllers (other buttons are not duplicated)

 

-the older MA-RA build does not duplicate actions to both controllers even with the same files used with 1.17.0 above 

 

This image shows both controllers pointing "west" when only the first controller is performing the action.  This does not happen with the MA-RA build.  With MA-RA, the action is only reported on the first controller.

 

[GB_Baker]

On 2/18/2024 at 7:01 AM, big_guitar said:

So unfortunately, using a second core, and feeding the exact same config file, same core library, and same rom file into the different RA builds...

 

-the 1.17.0 build still duplicates the GSP stick actions on both GSP controllers (other buttons are not duplicated)

 

-the older MA-RA build does not duplicate actions to both controllers even with the same files used with 1.17.0 above 

 

This image shows both controllers pointing "west" when only the first controller is performing the action.  This does not happen with the MA-RA build.  With MA-RA, the action is only reported on the first controller.

 

I am able to replicate with the NES controller rom.  I'm a bit stumped.  I haven't tested yet with 1.7.4, but the directions from the GSP controllers are fed as keyboard directions in the autoconfig.  Maybe I need to build without keyboard support (--disable-kbxcommon).  SDL2 libraries are in the GSP /usr/lib folder.  Might spend more time trying to get SDL2 working to see if that would be a better controller driver over udev.