Shannon
-
Posts
8,376 -
Joined
-
Last visited
-
Days Won
1
Content Type
Profiles
Forums
Blogs
Gallery
Events
Store
Community Map
Posts posted by Shannon
-
-
I'm just curious. Where did you get the newer build?
-
FBNEO's Colecovision emulation is decent.. and it's the only emulator that supports a good many SGM games as well. The key is to making sure you have the ROM images with the correct CRC.
It might be hard to get running, though, because you have to use the retroarch sub-menu to load content for the coleco. Which is hard to do if the retroarch menu is not showing up properly. I'm not sure if it is possible to load a "sub-system" game through the command line. Although it is possible to do so through playlists if you have them set up properly.
-
1 hour ago, big_guitar said:
OK I had copied somewhere that the a800 library core was used for A5200, but I see it's not there, thanks. Would have to manually reference it in a script then and include related BIOS.
It's possible I said earlier on based on my sisters test that it was there. But it turned out she was skipping games that did not show up on the menu ( hence I thought she was saying it was ok ).
I did retract that statement later once I realized what she did. But the released firmware update images definitely confirm that it is not used. Although I think I did see signs that they at least tried it.
-
1
-
-
2 hours ago, big_guitar said:
The core library used for Atari 5200 should support Atari 800 content extensions, so theoretically yes, although I'm not sure if any built-in extension traps will work outside of .a52, but keyboards seem to be completely disabled with the build of retroarch that is used on the GSP.
A5200 can only handle Atari 5200 games.. and more specifically ones that its internal database has CRC's for.
https://github.com/libretro/a5200/blob/14dedb7cab91379e5ef01c39cb884a4f83ed91d0/emu/cartridge.cIt also has a horrendous color palette ( colors are way to saturated ) and it uses the old pokey sound core by Ron Fries which has a ringing sound with higher noise frequencies ( why Pacman sounds like sh*t ).
They do have A800 on the buildbot which would probably be the better alternative for Atari 800 computer games. It has an onscreen keyboard ( ugly but it works ) for inputting keyboard commands. I would recommend un-assigning whatever button brings up the A800 internal menu. Cartridges need to be in .CAR format ( cartridge with a header ). Most .ATR/.ATX images should work as well as Cassette ( although the game's config file needs to be set to load a tape image ). I forget where exactly it looks for the Atari BIOS files for unix based systems. On other systems it is the retroarch system folder. If I remember correctly the GS Pro already has the BIOS files on there. It's Atari 5200 support is not that good, but it is there. I fixed a lot of the issues last year in Retroarch but the builds on the GS PRO are over two years old.
From what I understand they are no longer on the buildbot and have yet to be added back. I suspect this is due to the retroarch github being hacked a couple years back and they never rebuilt all of the buildbots. In theory one could setup an environment to compile the current retroarch sources for the GSP.
-
What they did for TheC64 was nice and all... but it was slow as molassess.
-
1
-
-
Microprose and Accolade?
Lot's of goodies there! I'll have to look up games done by them.Definitely could use Hardball... great baseball game!
-
2 hours ago, captcapcom said:
I tried Pac-Man 5200 on the Gamestation pro, and there is a high pitched whine when starting the game. Game is playable but that high whine is really bad on the ears. happens sometimes with the intermissions too. Do I have a Bad ROM or is this an emulator issue?. No other 5200 game I tried does this.
It's an emulator issue. It affect a couple of other games as well. I forget which.
-
Here are my notes on the different retroarch "mame" versions and which version of MAME they correspond to.
MAME 2010 -> 0.139 ( CHD v4 or less? )
MAME 2015 -> 0.160 ( CHD v5-v3 )
MAME 2016 -> 0.174 ( CHD v5-v3 )
-
1
-
-
Oh wow.. It'd be nice if the CoolCV retroarch version was available in some other version. Did the guy release the source? Retroarch only has one emulator that can handle SGM games and ones that have VDP issues on other emulators. ( FBNeo ) but it is limited to games the add in their database. I would think that adding CoolCV into retroarch for other platforms would be fairly easy.
-
Yep.. a handful of new games.
In other news.. I finally went through and did the 100% to get Grand Prix.. Uhh I mean Racer 500.. or whatever the heck the called it.
It's real easy. If you pay attention to the "icon" when an entry is selected you can tell whether it has been viewed or not. Plus it does a little animation and sound if you view a non-viewed item.
-
Windows can be a real pain when trying to rename a directory by changing letters to caps or lower case. It won't work. You may have to rename it to something like "ame" and then rename it to "Game" to get it to properly take. Also make sure your filesystem is FAT32?
-
Weird.. I looked back through the stable builds and didn't see it either. If someone has a build environment they could go to the author's site and possibly manually build it.
Also those nightlies are 2020... which is kind of odd. A5200 is not there either. So I suspect they are not sourcing that particular version.
Might be best to get the checksum of the existing emulators and do some comparison to figure out which build of retroarch they are pulling from.
-
1 hour ago, NE146 said:
Oh I just thought it was neat someone deep dived into it finally, so found the excuse to post it.
Thanks for that... It was very interesting.. although he started loosing me a little towards the end there.
-
3 hours ago, NE146 said:
Yeah I was referring to Yar's Revenge re-imagined..
-
12 minutes ago, fluxit said:
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.
Well your efforts have shown that what I thought was possible is. Probably easier than I initially suspected cause I figured there was some sort of hash check on the img files. But I guess not. This method is the best as far as I'm concerned cause it is non intrusive for the most part.
I almost regret telling my sister to return the thing when she picked it up for me back in November.
-
1
-
-
25 minutes ago, big_guitar said:
Nice, so your xd3 patch file is the editing of the start_local_sd.sh file with the wrapped if-then-else, is that right? And that edit was primarily for targeting the included games?
His edit was to allow the running of a script called runme.sh if said script is located on the SD card. Thus reducing the number of times that the partition that contains start_local_sd.sh has to be written to the Gamestation Pro's internal SRAM ( or whatever it is.. ).
-
3 hours ago, fluxit said:
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.😁
It would probably be simpler to modify runme.sh so it just looks at the file extension and then calls whichever retroarch or standalone emu you want. Rather than relying on the binaries to determine which core to run. Even more important if we are running cores not included with the official gamestation pro.
-
Wow.. well this creates A LOT of possibilities now. Might be good to create a "backup" script at some point to backup all of a persons GSP like is usually done. Luckily this stuff can be done in a non destructive way with the mirror command.
Anywho.. it should now be possible to swap out the retroarch cores with better or more current ones.. as well as adding new ones for other systems. Which opens up a whole world of emu goodness.
Just hop over to the buildbot site and grab some ARM cores. Should also be able to run standalone emulator compiles. Although that one may take some more work.
I would also suggest considering going with just one retroarch.cfg file and just remap the retroarch folders so that the controller remap folder points to the SD card. Then remaps can be created specific to each game the proper way. Also a global emu "remap" for each emu could be made that way to accommodate the extra unassigned buttons. Now a way needs to be figured out to bypass the menu button interfering.. or possibly a way to remap that as well ( as a combo maybe? ).
I'm just curious. Which stella core does it call if you pick an internal paddle game or a game in the "paddle game" directory?
-
2 hours ago, fluxit said:
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.
Doi. Don't know how I missed that one.
-
4 hours ago, Mocotechprfl said:
It's too bad that the SNES and TG games don't appear to utilize cfg files. If they did, it would make it so much easier!
If they modified their kornshell script to call a retroarch.cfg file in the SD folder based on the game selected that would be great. In fact the script could be modified to use the default ones they have setup if no such file exists on the SD card. Also they never created a retroarch.cfg specifically for the SNES. I guess an oversight on their part.
-
I'll leave that for the people who start hacking the IMG file to figure that one out....
That being said.. in the "game" executable which I was incorrectly referring to as the "menu" executable in the earlier post. That script file is referenced.. (three times)
/data/start_local_sd.sh 0 %d "%s" "%s"
Plus the first to parameters are numbers 0 and "%d" stands for decimal. The last two are strings. The first points to the retroarch config file ( based on the start_local_sd.sh" script. The 2nd points to the ROM selected itself.
-
1
-
-
22 minutes ago, big_guitar said:
Which table shows 17 slots? Under tbl_game I only see the 11 used types for their 201 game entries.
I see the 14 core libraries under the libretro directory.start_local_sd.sh ... the script that is run for SD games has 17 values that it checks for. Well actually 18... but I wasn't really counting 0..
#!/bin/sh #FC fceumm_libretro.so #GB/GBA/GBC mgba_libretro.so/gpsp_libretro.so #MD genesisplusgx_libretro.so #SFC snes9x_libretro.so #XC_ATARI2600 stella_libretro.so #XC_ATARI7800 prosystem_libretro.so #FB Jungle_libretro.so #M3 Jungle2003_libretro.so #M16 Jungle2016_libretro.so #usr/lib/libretro export XDG_CONFIG_HOME=/data export XDG_RUNTIME_DIR=/data GAME_PATH= GAME_LIB= export LC_ALL='zh_CN.utf8' case "$2" in 0) GAME_LIB= ;; 1) #GAME_LIB=nestopia_libretro.so GAME_LIB=fceumm_libretro.so ;; 2) GAME_LIB=genesisplusgx_libretro.so ;; 3) GAME_LIB=snes9x_libretro.so ;; 4) GAME_LIB=mgba_libretro.so ;; 5) GAME_LIB=stella2014_libretro.so ;; 6) GAME_LIB=prosystem_libretro.so ;; 7) GAME_LIB= ;; 8) GAME_LIB= ;; 9) GAME_LIB=Jungle2014_libretro.so ;; 10) GAME_LIB=Jungle2003_libretro.so ;; 11) GAME_LIB=Jungle2016_libretro.so ;; 12) GAME_LIB=a5200_libretro.so #GAME_LIB=atari800_libretro.so ;; 13) GAME_LIB=a5200_libretro_new.so #GAME_LIB=handy_libretro.so ;; 14) GAME_LIB=virtualjaguar_libretro.so ;; 15) GAME_LIB=stella ;; 16) GAME_LIB=mednafen_pce_fast_libretro.so ;; 17) GAME_LIB=vice_xpet_libretro.so ;; *) echo "Have not game resources" return ;; esac 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
As I stated in an earlier post.. not all of them are used in the database and 3 of them are actually empty ( no setting of GAME_LIB ).
The thing I cannot figure out from looking at 'menu' is how it determines what values to assign games based on extensions. There are also references in 'menu' to N64 and Playstation games and some of the extensions that seem to be associated with PC-Engine don't make sense. But this is looking at it through a hex editor.
-
33 minutes ago, Domeshtan said:
I tried it before and it didn't work. Maybe it was looking for some checksum or something as well as the name of the rom. From what I remember you had NO control for movement if you tried it on the old firmware.
One weird thing I noticed testing Kaboom! just now. It plays fine for 1 player but there is no control for the second player. Just the button to start dropping bombs. Another weird thing was that for player 1 you could use either of the paddle controllers. (I have mine wired to both ports right now).
I don't have the original partition files to look at so I don't know how the "menu" executable changed between versions. But I did notice that the "menu" executable has all of the paddle games names "hard code" into it. So it is likely two things.
1) If a match is found for the hard coded name it will use the standalone stella.
2) If the game is a type 15 ( in the games.db file ) then it will use the standalone stella.
I'm assuming it only looks in the games.db file when running games internal to the system.
-
I think the GSP uses retroarch.cfg when loading from the SD card it does have individual configs, though, for a2600, a5200, a7800, arcade, gba, md and nes. But none for SNES.
Here is the file it uses.
I did retract that statement later once I realized what she did. But the released firmware update images definitely confirm that it is not used. Although I think I did see signs that they at least tried it.
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
Gamestation Pro
in Atari General
Posted · Edited by Shannon
Thanks for the link. Looking at the dates you all might want to consider using these. If the dates are based on the corresponding source codes then the A5200 and A800 cores should be updates which means the A5200 core has more CRC's ( I added a bunch of A800 conversions ) as well as the ability to use the mzpokey sound core which does not have the ringing issues that the Ron Fries Pokey core has.
Plus A800 has some improvements.. especially in relation to the A5200 support.... I added CRC's for all A5200 and A800 carts that I knew of as well as a couple of fixes ( Bounty Bob), ETC. Lots of fixes for Hatari. Although I don't think the unix build had issues that I knew of. I'm sure other cores have benefited from updates as well. Quite a few things added in the last couple years for all cores.