fluxit

You are correct. It was being detected as 3F. The type of the previous demo Turbo-Arcade_demo_v1_NTSC was detected correctly, Or was it in the included database?

The cores need to be arm. Try http://buildbot.libretro.com/nightly/linux/armhf/latest/ . That's where I got the handy lib that worked. I note that gearcoleco isn't in there. A build may be available elsewhere. My method for logging is to just add >/sdcard/logfilename to the tail end of my command line. Of course verbosity may produce more useful messages.

What are you using to run Stella?

I'm not sure if MyArcade has actually changed their boot loader. I'd recommend following their instructions on that, unless you know that you already have that particular boot loader on your GsP. From where did you source your gearcoleco core? I tried bluemsx, which created .ini files in my game directory, and threw an error that I haven't been able to identify. It may be the case that in order to load new cores, we will have to use a different retroarch binary. The GsP definitely *can* load libraries from the SD card. I'm still investigating. Did you log the output of your experiment to the SD card? I've successfully run "Chip's Challenge" using the handy core.

New nomination for worst sound: When a rat bites you in Tomarc the Barbarian. Best worst(the one you don't want to hear, and painful to the ear, but is awesome) is the player death sound in Berzerk.

No E.T. in E.T.. That must be after E.T. has died and been dissected.😟 Guide Elliot through the maze of pits. Collect and eat as many Reese's Pieces as you want. Poor E.T. doesn't need them anymore.

On the one hand, I also have plenty of 'chargers' here, most of them in use. I also intentionally purchased around half of them, to meet particular amperage, or other device compatibility requirements. And most corporations are not excluding them from their products packages to protect buyers from having too many, or trying to save the planet, they are saving themselves the <$2 per unit, basically penny pinching. That said, the gimmick of having an Atari branded 'brick' that was a model of a proper a scaled down version of the old wall-warts with modern internals would actually make the 2600+ a more appealing purchase for me. I understand however, that this would actually have a development cost attached to it.

Not a proper answer to your question, but have you tried this control scheme, controller rotated 45° clockwise?:

That makes sense. IIRC, when plugged into my computer, the GsP 'stick" is identified as an analog 2 axis "hat," returning the values 1, 0, and -1.

Running "certutil -hashfile .\Firmware.img MD5" in the "3. Firmware" directory of my Windows 10 stick computer, I get the result "4de3c6da30ef2b63db0d87a5dcf3d992" the same as recorded with my patch. Firmware.img has a size of 225968128, and the creation date is Dec 7 21:57. I redownloaded the firmware update linked to on https://www.myarcadegaming.com/pages/atari-gamestation-firmware-upgrade-to-v-1-3-only today, and it is identical to the copy that I downloaded on the 9th, upon which the patch is based. You might want to try downloading the firmware update again.

For a bit of (slight)weirdness, try creating a file named "GBX107_test.txt" , and place it in a directory named "game" on the SD card root. This causes "game-test" to run at startup, instead of "game." Make sure to remove the file afterward.

Correct. As for the why, well- the sky's the limit. We have what is essentially a root shell for our script. The hurdle I had to jump was the fact that by default, Linux doesn't want to run anything natively from fat32 or exfat, because they don't support the e(x)ecute file attribute. That's why I used "source." The system basically treats runme.sh as if it was actually a part of /data/start_local_sd.sh, so it doesn't care that it really shouldn't be allowed to run it. I'm not sure if the same issue will cause a problem with retroarch cores or not, some flavors of Linux need libraries to be marked as 'binaries,' and some don't. This is something I've not yet tested. Without further firmware modifications, it's very doubtful that stand alone programs will run from the SD card. They could, however be copied to the ext2 partition. Sadly, that doesn't have much free space, without deleting some games.

Agreed. I largely posted that list for those who were interested in what is running on what. As you say, we really need to replace the game discriminator functionality of "game" in our script in order to easily use external .cfgs and cores.

It actually uses /usr/bin/stella for those. This explains why they are playable, but feel just slightly sluggish. It isn't the paddle, or the HDMI lag. I can also confirm what I expected to be the case when browsing the binaries for the retroarch cores- .bin(unzipped) extension files are loaded by the Megadrive core. I haven't tested to see if any of the included systems actually work as .bin after the 1.30 update. Backups shouldn't be a problem, as you can just reflash the update. Unless someone goes whole-hog on replacing the included stuff, and that would likely require a more extensive modification. I like the base software and games, so I'm not really into that at this point. Here's a complete list of all included games, the config that they use, and the selected core(the numbers in the second column.) The result of about 12 minutes of pressing the button, then stick-right.😁 allgames.zip

That looks very similar to the Gemstick controller.

I hope you don't get any splinters But, seriously though- that's a cool pattern. If I didn't already have too many NES type controllers kicking around, I'd have to consider one of those.

Here are a couple of example runme.sh files and the results of an info dump(info-runme.sh). Omitted txts contained no data. The runme's have been renamed so someone doesn't just plop them into their agsp directory, thinking that they will improve their games, only to find that they have reduced(or no) game playing functionality with their SD card inserted. example-runme.zip

Using the patched firmware, we will now be able to fully reconfigure(non-destructively) the buttons for all supported systems. It may even be possible to get previously unsupported controllers working, with a bit of investigation. Fixing the SNES misconfiguration should be a breeze, though improving its performance is another matter.

My little hack worked. After the overwhelming show of support😋 for this endeavor, I decided to simply make it possible for the GsP to run scripts from its SD card, rather than trying to test my more extended edits while having to reflash the firmware after each little change. Here is the tested working, edited script fragment: if [ -f /mnt/sdcard/agsp/runme.sh ]; then source /mnt/sdcard/agsp/runme.sh else if [ "$2" == 15 ]; then #/usr/bin/stella "$3" /usr/bin/stella $3 "$4" else /usr/bin/retroarch -y "12"\ -k "$1"\ -c "$3"\ -L /usr/lib/libretro/$GAME_LIB "$4" #/usr/lib/libretro/$GAME_LIB "$3" fi fi The patched firmware will allow any commands that you wish, to be executed by placing a file named runme.sh in a directory named agsp at the SD card's root directory. If the file runme.sh doesn't exist, the Gamestation Pro goes on its merry way as though it had not been modified. So far, this has allowed me to answer a couple of our questions about "start_local_sd.sh". The first is that yes, the GsP uses this script for games played from the SD card, as well as games played from the main menu of included games. The second, is that "/usr/bin/stella" is not used for 2600 games that are played from the SD card. At least not 2600 games that have simply been placed within the "Games" directory. The performance of /usr/bin/stella is not very good, relative to the libretro core of the GsP. -------------------------- Here is the xdelta3 patch to be applied to the 1.30 update Firmware.img if anyone wants to try it. Use at your own risk. Any time the firmware is rewritten there is a possibility, however small, that it will fail, potentially bricking the device. In addition, it may be possible to do damage to the GsP via unrestricted use of runme.sh(using it to delete or add files to the GsP's internal file systems, for example,) as well, though the supplied patch should not be capable of causing any damage on its own. Unzip and apply the patch to the 1.30 firmware before flashing. Instructions for applying the patch are in readme-patch.txt. A Windows version of xdelta3 is available here. A Windows version of md5sum is available here. shell-patch-v2.zip

I agree game play wise. There are a couple of edge(literally) case jumps on the arcade version that should work, but don't. 2600 Frogger also largely retains the difficulty level of the arcade. My favorite version is probably still the Sega Genesis version, though.

It must be those cable swapping gremlins. You've got to sleep with your sticks under your pillow.

Oops, can't break continued(\) lines with comments. The line is not continued, and the comment is no longer treated as a comment.

Here's my preliminary edit to the end of start_local_sd.sh to allow for the modification or replacement of retroarch configs. It is untested, and I am asking for critiques, requests and comments: if [ -d /mnt/sdcard/Games ]; then if [ ! -d /mnt/sdcard/retroarch ]; then #create cfgs mirror, should only happen once per card mkdir /mnt/sdcard/retroarch cp -r /usr/lib/libretro/retroarch/* /mnt/sdcard/retroarch else if [ "$2" == 15 ]; then #my preference, we can test for and add other options per stella rom here /usr/bin/stella -tv.phosphor always -tv.phosblend 50 $3 "$4" else #anyone know what -k and -y are for? No help in the --help /usr/bin/retroarch -y "12"\ -k "$1"\ #-c "$3"\ -c /mnt/sdcard/retroarch \ #we could load alternate libs from sdcard here -L /usr/lib/libretro/$GAME_LIB "$4" fi fi else #no sdcard, or card not prepared/readable(no Games folder) #on the first run, should simply return to menu without starting game after creating mirror if [ "$2" == 15 ]; then /usr/bin/stella $3 "$4" else /usr/bin/retroarch -y "12"\ -k "$1"\ -c "$3"\ -L /usr/lib/libretro/$GAME_LIB "$4" fi fi Don't be afraid to offend me if I've made (m)any obvious errors. I've not written a proper script in years. If this works, it can be made into a tiny firmware patch to be applied to v1.30 update.

I was thinking something similar. There's no reason why we can't mirror the contents of /usr/lib/libretro/retroarch to the SD card in, say /retroarch, and then edit start_local_sd.sh to have it check for that directory, then use those config files instead of the ones in the squashfs if the directory exists on the SD card. sfc.cfg is the config file for the SNES.

Seeing as how you can get copyright violating cart only repros, for other systems at consistent prices as low as 4-$5, and full packages for $10, I don't see how a single Atari cart "needs" to be $30> when mass produced in order to break even. Don't get me wrong, I don't think the price of Atari's new carts is bad, by any means, I just don't see how the production needs to be that expensive.