fluxit

I hope that the RA Stella and ProSystem improvements make it from the 2600+ to the Game Station Pro.

Yeah. Still no keyboard. I've seen conversations elsewhere about disabled keyboards on RetroArch, not relating to the GsP. Nothing that helped though, unfortunately. The keyboard works, up until RetroArch loads, and then the kb is dead until RA exits. Apparently, the "menu" button issue is also more of a 'feature' of this version of RetroArch, than it is something that MyArcade added. Newer versions added the ability to completely disable the menu, so the button can be reused without interference. There is some nuance, people have claimed that remapping the "*menu_toggle" settings to particular button combinations will free that button, but I haven't had any real luck with that on the GsP. This may only apply to non-GsP controllers, due to the special handling of GsP controllers. I've not tried it with anything other than 0 or 1. I'm pretty sure it's just an enabled/disabled switch. IOW, "1" means - force save menu display, save states enabled, and "0" means - force save menu display, save states disabled. Omitting the switch entirely allows the cfg menu settings to take effect.

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

Barring MyArcade releasing an update that makes this possible, not very good. There are a couple of ways that we could make it happen, but it would involve a lot of work, a lot of testing, and risking bricking GsP(s). I'm not really interested in pursuing this, but there are a couple of ways it could happen. One could decompress the write-only root squashfs, carefully modify it, and produce a new firmware that allows the menu to draw from the SD card as well as the internal data partition. Another possibility, would be to 'liberate' /usr/bin/game to the SD card, produce a new environment for it, kill the old "game" menu, and start the new. Less risky, but again- a lot of work. More than I'm willing to do at the moment. Why is it difficult? Because the internal, writable data partition that contains the builtin games and graphics is almost completely full. The database for the menu is located in the non-writable squashfs. And our exFAT SD card does not support symlinks, making creating(and taking🙂) shortcuts more messy.

I was determined to figure out what the -k option was, since it varies among the included games. I've got it. If -k is 1, the save menu allows saving(this can also be disabled via the .cfgs,) if -k is 0, the option of saving state is not provided for a game. I tried always enabling saving, and it works(saving and loading was tested) for internal games that had it disabled, and external games. Possibly not all RetroArch cores support saving, though? In case the keyboard being disabled in RetroArch was due to "game" still running in the background, I "killall -s STOP game" the process(also tested, it *does* make the "game" process nonresponsive,) "CONT" the process after RetroArch exits. It makes no difference, still no keyboard in RetroArch. We need to find another compatible build of the RetroArch frontend. I did manage to get MAME to display a menu via "mame2003_display_setup = "enabled"" that worked with the GsP stick, except I wasn't able to successfully map a button to 'select,' so I couldn't configure anything.

@Velvis It definitely supports Warlords, both arcade and 2600 versions in 4 players. As for the rest, they should work, but I've not personally tested them. The GsP only supports 2 wireless controllers at a time, so at least 2 of the four GsP controller players need to be wired.

Gamestation Pro - Pictures of What's Inside Previous Cave games seem to run okay. Considering that "Muchi Muchi Pork" came out *after* the primary version of MAME on the GsP.... Does it have the power to handle the game, I don't know.

...

Not only do the cutouts allow for the label to be damaged, they expose label adhesive to potential dust and fuzz. Baffling, as you say.

That can be accomplished by the addition of an appropriate Galaga artwork set to /Games/artwork on your SD card. See

I'm not sure if you were looking for advice on technique, or not. Here are some tips for desoldering while avoiding causing damage: Clean the joints with 85% or better isopropyl alcohol(IPA) and a swab or toothbrush. Add a bit of new, preferably tin-lead solder to each of the affected joints, just enough to double or triple the size of the blob. Keep the joint heated for 4-6 seconds to allow the new solder(and flux) to mix with the old solder. If you have difficulty getting the new solder to mix with the old due to oxidation of the old solder, don't rush it. Adding a bit of extra flux to the joint may help as well. Worst case, you can carefully scratch the surface of the oxidized solder with the tip of a razor blade to expose workable solder. Once you have a nice shiny joint around each of the old leads, use a desoldering pump, or desoldering iron if you have one. If you don't have either of those, hold the lead to be removed with a pair of tweezers, and reheat the joint. Gently raise the lead, and it should come free with no effort. Be patient, and don't force the lead from the hole, or you may rip up a pad. It's a delicate balance. You need to heat the joint long enough that it can be easily worked with, but not so long that the board is damaged with excessive heating. Once the leads have been removed, use a solder sucker or desoldering wick to clear the holes. Personally, I recommend the sucker if you don't have a desoldering pump, but it's a matter of personal preference, really. Both methods have their own techniques that must be learned for consistent success. This step isn't necessary, but it's possible to lift pads while adding the new component if you haven't first cleared the holes.

The SQLite database for the built-in games is located at /usr/local/share/minigui/res/db.

I'd try a different rom for Road Runner. That doesn't happen here. The game plays fine on fw 1.30.

Did you see this thread? You can check both sides of the transformer for continuity, and you could also check it with an inductance meter, but so long as it has continuity, and isn't shorted you should be fine as far as the transformer is concerned.

It does. A keyboard even works as a controller. Selecting the Options menu consistently caused Stella to crash, though. I thought that this might be related to its inability to successfully read or write a config file, but I'm not sure. Strangely enough, RetroArch loses the keyboard on my Linux machine in mame2003 after I configure the GsP controller. Configuration seems to go smoothly, but then when I run Tempest with mame2003, the controller doesn't work at all, and I can only pause or exit with the keyboard. I can't even bring up the menu in MAME after configuring the controller(well technically I can with the cfg option, but the menu while properly rendered, is entirely unresponsive,) and AFAIK, I didn't even configure that key/button. Before I configure the controller, mame2003 works normally. Super annoying behavior. Unconfigured, the GsP stick and several buttons work in RetroArch on my Linux machine, including in mame2003, but it won't give me a button 1 or 2 and it won't recognize the paddle until the controller's been configured, so there's no point.

That's Stella's(the Atari 2600 emulator) menu. When you select a file from the "Atari 2600 Paddle" folder, it gets passed to the standalone stella binary(/usr/bin/stella.)

No need to dilute it. As long as you only leave the shield in for 30 minutes or so, no damage will be done. Cool.

The first thing that I would do, is to remove that shield, and let the rusty bits of the shield soak in a vinegar bath for 30 minutes. Then use a brass brush on the rust. The vinegar should allow all loose rust to be removed, and should blacken and stabilize any serious rust that remains(if any.) Then just rinse it in water a few times, and dry with a cloth. From your picture, it doesn't appear as though those resistors actually need replacing. After the shield is removed, take out the motherboard and give it a good going over with a lens blower, or canned air. Scrub the crusty bits with a toothbrush. I'll bet it looks a whole lot better after that's been done. You didn't actually mention if the system powers on, or plays games. I'm guessing that someone else will have suggestions for good switch relacements, as if it was me, I'd likely just bodge in what I have on hand, which is probably not what you have in mind.

Would you mind sharing your .cfg?

Did you check which NIC chipset drivers are compiled into the kernel? I keep forgetting to do that.

Yes, the GsP uses MAME for emulation of arcade games. Examining the updated firmware on the GsP shows that it should have the ability to update via SD card, but they aren't using it for some reason. Perhaps the shipped version of the firmware didn't include that function, or it isn't currently working. I don't know for sure.

Solder a short wire from one hole to the other. Or install a jumper block. The iffy solution is a bent paperclip.

No, not really. pcsx reloaded did about 8-12fps running Medal of Honor. In comparison Virtual Jaguar does about 1.5fps on Tempest 2000 with "fastblitter" enabled. 16bit is about as far as you'd want to go with the GsP.

From start_local_sd.sh: 12) GAME_LIB=a5200_libretro.so ;; 13) GAME_LIB=a5200_libretro_new.so From my allgames survey of the GsP: 0 12 /usr/lib/libretro/retroarch/a5200_4_3.cfg /data/Games/Atari_Games/Atari 5200/Centipede.a52 0 12 /usr/lib/libretro/retroarch/a5200_4_3.cfg /data/Games/Atari_Games/Atari 5200/Frisky Tom.a52 0 12 /usr/lib/libretro/retroarch/a5200_4_3.cfg /data/Games/Atari_Games/Atari 5200/Millipede.a52 0 12 /usr/lib/libretro/retroarch/a5200_Baseball_4_3.cfg /data/Games/Atari_Games/Atari 5200/RealSports Baseball.a52 0 12 /usr/lib/libretro/retroarch/a5200_Baseball_4_3.cfg /data/Games/Atari_Games/Atari 5200/RealSports Basketball.a52 0 12 /usr/lib/libretro/retroarch/a5200_MissileCommand_4_3.cfg /data/Games/Atari_Games/Atari 5200/Missile Command.a52 0 13 /usr/lib/libretro/retroarch/a5200_Meebzork_4_3.cfg /data/Games/Atari_Games/Atari 5200/Meebzork.a52 As you can see by the "12"s, all but one of the built-in 5200 games on the GsP use a5200_libretro. a5200_libretro is also used for 5200 games that are loaded from the SD card. I wanted to know why, so I had them all use a5200_libretro_new instead, and found that "new" has slightly better compatibility. I'm still not sure why they are primarily using the other. Here's my current "runme.sh" that always uses the "new" core for 5200 games. always-new.zip

Well, that's something. I've tried several different color combinations in the cfgs, and changed the various "opacity" settings, but the RetroArch menu always ends up being just black. The selection rectangle moves, but I can't see what the options are so it's useless. Have you had any better luck? RAMwise, the GsP has twice the RAM of the Retron 77, and the same as the 2600+ at 256MB. On another note, I may have found a way to survey controllers that are connected, in order to know exactly which button or control is seen as what by RetroArch, I've been going through each binary and script on the GsP, one by one. I'm convinced that evtest is the ticket, if it runs. I've not actually tried it yet on the GsP.