fluxit

I believe that what you are experiencing is video lag due to your display device.

Here's the working RAM info for the GsP: MemTotal: 249668 kB MemFree: 170372 kB MemAvailable: 175672 kB

This text from the ordering information page makes me not want to order, even though there are a few products I am interested in. It would seem to give them license to send you what ever they like, and keep your money if they don't send you what you ordered.

Okay. The included file fixes the TG16/PCE button mapping, and also may improve the SNES button mapping. It requires my patched 1.30 firmware to be installed first. Then the file should be unzipped to your SD card, preserving directories. "runme.sh" should end up in a folder called "agsp," that is located at the root of the SD card, replacing the existing runme.sh, if one exists. It may be the case that the TG16 buttons should be swapped. If you decide to try this out, and agree that they should be swapped, let me know and I will release a version with the buttons swapped. For anyone who previously installed my vector games fixes, this will not affect those fixes, but it also doesn't include them if you haven't already installed them. fix-snes-tg16.zip

Is TG16 just 2 buttons, plus "select" and "run" for a total of 4? It seems to be using the default configuration at the moment. Perhaps the current NES .cfg would work well with it. AFAIK, the NES mapping is fine. I'll do some testing.

How about this? Your other options include- pressing reset at exactly the right time when emulation starts, which may not even be possible, or an updated firmware that makes this possible. I don't know if anyone has plans for a new R77 community build release.

From what I've seen, the retroarch front-end that is included with the GsP almost always attempts to write to the read only squashfs root, and complains when it fails. It does appear to be a custom build, based on the strings in the binary. I can't imagine why you'd ever want to be arbitrarily creating directories in a Linux system's root. This must be a bug.

My recommendation would be to not use "Sold Out" to indicate "Temporarily Out of Stock." Sold out is too ambiguous. Atari.com apparently uses it to mean both "Temporarily Out of Stock," and "Permanently Out of Stock," depending on the listing. Various different stores have taught me that "Sold Out" *can* mean any of the following: 1. We don't have any more for sale, and we don't anticipate having any in the future. 2. Temporarily out of stock. 3. They are still being produced, and sold, but we aren't selling them anymore. 4. This listing has been superceded by another, but we aren't going to help you by letting you know.

Nicely done! I guess I should have suggested using a new copy of runme.sh. I considered it briefly. Doh!

I wouldn't worry about bricking your GsP with the update. Not that it couldn't happen, but we've not seen many reports of this happening. Your odds are pretty good for a successful update. That having been said, if you're not sure you want to update, there's no reason you have to do it now. You can give it some time, to see how you feel about it in the future. Regarding the value of the update: The new SD card handling that was added is nice, in addition to the game instructions for those who need them. Overall, I'd have to say that the update is worth the effort, and the risk.

Check your TV's picture settings. Some of them can apparently cause that effect if turned on.

It looks like "Millenium Ecommerce" is scalping them on Amazon. I find the fact that they are sold out on the Atari.com store to be a bit of a head-scratcher. Was it not a popular product? Was it an unprofitable product? It isn't "limited edition," so if it's sold out, I'd think that that would mean that it *was,* in fact- popular. Atari just wants to leave some money on the table for someone else, I guess. I too, would like to purchase a set. I'm curious how they compare to the AtGames paddles. The game selection on the multi-cart isn't exactly what I would have chosen, but they're not bad games, either.

I have a suspicion that the GsP has to boot twice with a newly formatted(or new out of the package) SD card before the GsP will display the "Select internal or Micro SD" selection dialog. This is after adding the proper "Game" directory including roms. I say this, because so many think that only exFAT formatted cards will work. But I have two, otherwise identical cards here, one formatted FAT32, the other exFAT, and both work fine on my GsP. It may be that people try a particular card once, it doesn't work, and so they reformat or try another card, when in fact all they needed to do is to shut down the GsP and turn it back on again. That isn't to say that if you think that reformatting a card to the alternate format, whichever it is for you, won't help. It might. If there's an actual incompatibility, it might lie in the particular format of that particular card, and reformatting or switching formats might fix it.

I see. Well, the answer is that you can create modified configs for the NES emulator, but it requires a modified firmware. Unlike the MAME games which can use different configs on the stock GsP.

The second difference that I can see from what you provided, is that I've not added any of the GsP's included RetroArch cores to my SD card, but I don't see why that would matter. On the other hand, RetroArch does seem to like to touch every file in a directory that you point it at, Try deleting all of your cores except the handy core. My only other thought is that Linux sometimes doesn't like text files created by Windows apps. Linux uses only line-feeds(0Ah) to end lines. Windows uses carriage-returns(0Dh,) instead- sometimes with the addition of line-feeds. Did you perhaps open your runme.sh with notepad.exe or something similar?

My wheels don't seem to be in contact with the ground, Michael.

When browsing the GsP's binaries and scripts, there seem to be some 'bugs,' where sometimes "Games" was used, and sometimes "games" was used. As a result, there may be cases where "games" works with the release software, but "Games" typically works better, in my experience. It's also recommended by MyArcade that the "Games" directory be capitalized.

I would expect a dual stick NES game to just work on the GsP without needing configurations altered. I checked the controller settings, they seem correct.

@Riko Did you click on the empty box in the right-most "..." column, on the "Loader" row, and select the Loader.bin? And then do the same with the "firmware" right-most empty box, but select your desired Firmware.img?

That should be \Games\lynx. It's the GsP's regular Games directory.

I'm making copies of the .cfg files so that they are available to the user for alterations. Otherwise they are only located on the squashfs, which is read-only. Did you copy an arm version of handy_libretro.so into /agsp/libretro/ on your SD card, and a copy of the rom called "Chip's Challenge (1989) [o1].lnx" into /Games/lynx/ on your SD card, in addition to copying the runme.sh from lynx-chip-test.zip into your /agsp/ directory? Note that *that* runme.sh only runs the test, and doesn't use a .cfg file, so it can only run the game, and does not configure any controllers, so if you get *any* working controls, it is only a result of the RetroArch defaults. You should also end up with a log file named "lrlnx.log" in the root of your SD card after running the test on your GsP.

Finally, I'm making real progress. I noticed initially but then forgot, that the GsP uses busybox ash as it's shell. I'd been(partially accidentally) targeting dash with my scripts, and so my results had been hit and miss. Now I know that I have to "busybox ash testscriptname.sh" when testing, in order to see similar results to what happens on the GsP. I improved the vectors on the included arcade vector games, and also the performance of those games. The vectors were not all displaying with MyArcade's settings, Vector width is increased, which I'm sure some folks won't like, but you can tweak the included configs in "arcade-vector1.zip" to your liking. The performance improvement is due to decreasing the audio sample rate to 22050. Alsa likely resamples to a default output rate for the audio device, but if so, it's performance in doing so is better than RetroArch's 48000. 1.To gain these improvements, you must first install the patched v1.30 firmware: 2. Then you must download and unzip the below agsp.zip file to the root of your SD card(preserving directories) 3. Put the SD card in your Atari Gamestation Pro's slot. 4. Boot the GsP, and load any game. 5. Turn off the GsP, and with the SD card connected to your computer, unzip the /agsp/arcade-vector1.zip file(again preserving directories.) You should be asked if you want to replace two files at this point, say yes. 6. You are done. Put the SD card back in your GsP's card slot and enjoy better vector game play. agsp.zip

I've not had enough time this past week to do much testing or coding. Most of it is fully fleshed out in my head, I just need to comit 3-6 hours or so to complete the script. Here's my Lynx test. No .cfg, was used- just the defaults. It might actually have better performance with a specified video driver, but I've not had a chance to run further tests yet. This script also creates copies of the GsP's included RetroArch configs. lynx-chips-test.zip

This is actually a somewhat complicated subject, because the "game" bin only recognizes certain file types by extension, and RetroArch cores also only recognize certain file extensions. Some have support for zipped files, and some don't. In order to see files using the GsP's file browser, we have to use file names that it knows. What we can do with those types that it doesn't know, is to put them in .zip files, which "game" shows. Then all we have to do is leverage the GsP's busybox unzip to peek inside the .zip, and our script can take it from there.

Fire button? Have you tried a different joystick or set of paddles?