CDBlue

From what I read they deprecated LST files, but you "should" be able to open the BIN file directly in Flycast still. Try to load a bin file directly via retroarch and the latest flycast core to see if it work. If it does, you will need to re-point your games in LB from the LST file to the correct BIN file for each game... or just remove and reimport the BIN files

Actually, Cemu with OpenGL on an nVidia card is actually quite a bit faster than Vulkan on nVidia at this time... provided you tweak some nVidia control panel settings to enable/disable certain features for Cemu. Here's a link to a good video about what settings to tweak in the control panel to give you max performance out of your nVidia card: FYI, although I agree with how BSOD setup the above, the one part I would suggest maybe not doing is the custom timings. I would suggest leaving those to default cemu and not QPC/1MS as he suggests. Although it's working now, in the past when you use those settings and try to launch games via command line it would prevent the emulator from loading properly. Once you set those settings back to the cemu default settings, you could load games properly again via command line. There's very little (if any) performance difference with those settings in particular, and my toughts are if they broke it once they might break it again... so why bother changing those settings heh

Sorry, someone else will have to assist with that part. I've never done a mame set as I usually just download an already built non-merged set for the version of mame that I'm running.... so no need to rebuilt, etc.

Correct. If you use the latest dat file. with a full romset of FBNeo, it will rebuilt only the roms (parents and clones) that are working with the latest version of FBNeo. You can them import the newly created roms and they should all be working at that point in time. FYI, I usually also use the option to merge the bios into each file... they will work without that, but then you need to make sure that you have the bios files in your rom directory. Since it doesn't add much space, and it's the recommended way for the retroarch core to use the rom files, that's how I always rebuild my FBNeo romsets.

This isn't a direct answer to your question, but I'll cover the way I've been doing FBNeo roms is to use ClrMamePro to rebuild the rom set, based on the latest dat files, which will give you a working-only romset for FBNeo. Once you have that romset rebuilt, you can them import all those roms into LB and not worry about LB's db trying to determine which roms are working at this time or not. I'm not 100% sure if LB/BB knows which roms are working or not for FBA, as I think it uses Mame dat files to determine working/non-working, and Mame working roms are not the same as FBA working roms (ie. FBA might have roms that work, and those don't in Mame, and vice versa). The following URL is a good source of info on how to re-built a current FBNeo rom set using ClrMamePro. https://github.com/RetroPie/RetroPie-Setup/wiki/Validating,-Rebuilding,-and-Filtering-ROM-Collections Luckilly a complete FBNeo romset is quite tiny compared to a full Mame rom set, so doing this doesn't take up tons of space. I know this doesn't directly answer your question, and maybe someone else will post that answer for your direct question... but maybe this will help you anyway

Hmm not sure, it works for me as I mentioned Are you trying this all the time with the same rom/game? If so, maybe try another rom/game or two to at least rule out that it's not an incompatible game that you're trying. Changing the machine to 5200 is what got me past the menu system as well, FYI... if I have it set to anything other than 5200 I get that menu screen.

Ok... I'm stubborn so I wanted to get it working again on the atari800 core for me. Here's what I had to do. I had to load a game, then go into the options and set the Atarti System listing to Atari5200 then set the internal resolution to 336x240 for it to work/display properly. I also needed to set my Controler input to Atari joystick for my controller to work. After that was done, all seems to work fine for me now.... although I am still going to continue using Altirra because (IMO) it's a better emulator for that console. This may work for you, or may not... but worth a try

Hmm, not sure at this point. I gave up using the atrari800 core a long time ago in favor of the stand alone emulator Altirra, which I always suggest to people as it just works (http://www.virtualdub.org/altirra.html). I did just try my roms to load using the atarti800 core in retroach, and while they do load for me, the display is all messed up for some reason. Not going to bother trying to fix it, as like I mentioned above, I use Altirra for that core all the time now. But, maybe there's something going on with the latest version of that core which is cause your issues and nothing to do with the config?

I don't believe the rom path/location is listed in the .atari800.cfg... at least it's not listed in mine. I believe the primary key to get it working is to make sure that the location of the bios rom files, that are in your system folder, are listed in that cfg file using in full path to where they are (ie. C:\ not just ..\). If they are not listed, or not listed using full paths, then that's likely the issue preventing it from working. Once those are listed correctly you should be able to load the core and load the content from wherever you have your rom files. Typically, retroarch doesn't really care where your rom files are stored, just where the bios files are when/if needed. For example, I have the following lines that are showing the location of my bios rom files, if you have an .atari800cfg file, then it shoudl be all populated with the line you need to edit: ROM_OS_A_PAL=C:\Games\RetroArch\system\ATARIOSA.ROM ROM_OS_BB01R2=C:\Games\RetroArch\system\ATARIXL.ROM ROM_5200=C:\Games\RetroArch\system\5200.rom ROM_BASIC_C=C:\Games\RetroArch\system\ATARIBAS.ROM ROM_400/800_CUSTOM=C:\Games\RetroArch\system\ATARIOSB.ROM Hope this helps, CDBlue

More than likely all you need to do is turn off the press twice to escape option in retroarch. Then pressing escape should just exit the emulator and not bring you to the Mame menu system.

Seems to be related to the video driver perhaps. I see errors about opengl not being found and it trying to revert to software, and that's when the error occurs. What driver (video) do you have Retroarch set to use? Perhaps try changing the video driver in Retroarch to GL, GL Core, D3D, or Vulkan to see if any of those fixes the issue on exit. Also, although I'm pretty sure it's not related to this, but your video card drivers for your nVidia card are quite old. You're using 432.00 and they're now up to 442.59. Likely wouldn't hurt to also upgrade your video card drivers as well.

RPCS3 is as easy to setup as any other emulator. My biggest problem with it, at least from the last time I used it anyway, it uses up high CPU usage... near 100% on all cores if I recall. So, unless you have a really good after-market cooler on your CPU it might get super hot and shut down your system or potentially cause damage if you're not careful/monitor temps on your CPU. Here's a good setup guide on youtube for RPCS3:

Not sure of this is the same thing you're referring to, but it looks like this person wrote a full screen launcher for a streets of rage remake (windows port). If this is the same game you're referring to, then it looks like this might what you want. You would simply point your game file in LB to the launch I assume, and then the launcher would then open the game and put it into full screen mode. (there's a link to download on the reddit page I found this on:

Excellent, happy to hear you got it working

Thx @Retro808 for the comment about Control + Q for exiting Citra. I forgot about that. @Nocta try using the following simple script: $Esc:: Send, ^q Note: take out the part about F11 to make it full screen. It seems that having to press F11 to go full screen, that I was using before, was just a side affect of my forcing it closed. If you're in full screen and close it properly with Control + Q it retains the fullscreen on next launch. So, for the first time, just press F11 if you're not in full screen, then next time you exit properly it will retain that. FYI, I also could not get the Send ^Q exit script that Retro808 posted above to work either, but the Send, ^q that I just put here works fine for me. Hope this helps, CDBlue

FYI, I just tried pause screen and it seems to work fine for what I have mapped, which is just resume, view achievments and exit lol. I don't have anything mapped in there for save states, etc. but I would assume if you know what the keypress is to get save states, etc. to work in Citra it should work fine via the pause screen, because the pausing and resuming seems to work fine for me.

I don't have any issues getting Citra to close via my button mappings, but I don't really use the Pause menus so not sure if they work or not with Citra (also FYI, I tend to use Citra Canary rather than Nightly). I also use an AHK script to make it go into full screen automatically as well. Here's my AHK script in case you want to try it: Sleep, 5000 SetKeyDelay, -1, 110 Send {F11} Return $Esc:: { Process, Close, {{{StartupEXE}}} }

3DS, PSP and DS all have standalone emulators and libretro cores: 3DS - Standalone - Citra (https://citra-emu.org/), 3DS - Libretro core - Citra (https://docs.libretro.com/library/citra/) My recommendation - At this time the standalone as it's being actively (almost daily) updated, while the libretro core hasn't been touched/changed since Dec. 2019. PSP - Standalone - PPSSPP (https://www.ppsspp.org/) PSP - Libretro core - PPSSPP (https://docs.libretro.com/library/ppsspp/) My recommendation - Standalone as it seems to upscale better (for me at least) than the libretro core does DS - Standalone - There are several, but DesMuMe is usually my goto (https://desmume.org/) DS - Libretro core - Again, there are several, but DesMuMe is my goto https://docs.libretro.com/library/desmume/ My recommendation - The libretro core seems to work better for my liking, and doesn't have the graphical glitches that you can sometimes get with the standalone emulation when using fullscreen.

As itchyRobot mentioned, the BezelProject for Windows is your easiest bet. These bezels are installed within Mame iteself, so it doesn't matter what front end (ie. BigBox) you're using. Most of the bezels you can find on EmuMovies are to be used with RocketLauncher, which is a completely different process/file type than what you need to use within Mame directly. The video above explains it well, and the direct link to the github page for it is https://github.com/thebezelproject/BezelProject-Windows. It's really easy to use though. Essentially when you run the installer/wizard it will ask you what you want to download items for. You select Mame from the list, point to the location where you installed mame, and it will download/install the bezels in the proper location etc. within Mame.

Correct. If you have access to the power strip and can turn it off (effectively turning off AC power to the PC), and the PC you are using does have the option in the BIOS to enable it to turn on after AC Power Loss (not all bios have that feature), then it will work as you want. FYI, I just tested this with one of my PC's by turning on that feature in the bios and simply shut windows down. It did not come on again until I pressed the power button on the PC. However, when I shut it down, turned off the power bar, waited a few mins, then turned that power bar back on, the PC booted up within 15 seconds due to it seeing that it had AC power loss, but then it saw it was back and the bios told the PC to power on.

I believe the power on feature in a bios will only kick in when the PC loses power, and it's then restored... in your case when you turn off the power strip and turn it on again it would be the same as a power loss/failure as far as the PC is concerned. if you have that power on after power loss feature enabled in your bios, and you simply shut down the PC but it still has power, that feature should't kick in and the PC shouldn't just turn on again. It should only do that if there's then a power loss/failure (ie. flip the power off on the strip, then back on). Until then, you would only be able to turn it back on by pressing the power button on the PC... hope that makes sense

Not sure about steam, but I would not be surprised that in Retroarch you might need to change the input driver to something particular to get the Xinmo buttons to bind properly. Try going in the driver/input section in the settings in retroarch and see if another one will allow you to bind. For example, it might be set to dinput, and you might need to change it to sdl2... or it might be set to sdl2 and you might need to change it to udev, raw, etc. My guess is that the fact that there are a few different controllers detected by retroarch when you open it, it might be picking what it thinks you want to use as an input type/driver, and it might not be what you need to use for the one you want to use. Not sure if this is the issue or not, but it won't hurt to try. Just keep track what the input driver was set to before you change anything, so you know what to set it back to in case this is not the resolution.

A heads up for all you emlator junkies (like myself). I just noticed that it appears that the main contributor for m64p has decided to move back to public releases for his version of Mupen64plus, m64p. This is one of the (if not the) best emulators out there for Nintendo 64 emulation, as it runs most games great out of the box. In the recent past he had decided to go patreon-only for releases, but it looks like he's back to his older model of publicly making the emulator available. Anyway, pick it up at https://github.com/loganmc10/m64p/releases while it's available

I know you mentioned you don't want to shorten the file name, but that is likely the easiest way to make it work. Simply rename it to whatever you want, make sure to edit the .cue file so that it's also looking for the correctly/newly renamed bin (I assume) file. Once you import it into LB, it will likely not know what game it is, you can then rename the game from within LB by editing it, and having it search the gamedb. In other words, the file name for any rom can be whatever it wants, as long as LB eventually knows what the game is (by renaming it in the edit title field in LB) then it will find the game in the DB, pull up the artwork properly, etc.... and most importantly, launch the game correctly

In order for an emuluator to work properly and launch a game directly via LB/BB, the emulator must allow command line functionality. From what I've seen VCC does not appear to allow any command line functionality, and it's all driven by its GUI. The only emulator I'm aware of that might work, and does support command line functionality, is MAME/MESS. However, I believe it's not straight forward to setup MAME to work with Color Computer roms. I would say do some google searches on how to setup CoCo emulation in Mame (or any of it's variants such as MAMEUI, which might be easier to setup due to it's more intuitive inferface). Good luck, the CoCo emulation scene is not very strong, but the emulators that do exist do a fairly good job of emulating the real hardware... just not great when it comes to integrating with a frontend like LB/BB that is