CDBlue

hmm not sure on that error. In LB for your emulator setup for Demul do you have this as a default command line? -run=dc -image= I don't think that error is related to a missing command line parameter, but it might be. Also, just an FYI, if you're using Retroarch, the Flycast core is an excellent Sega Dreamcast emulator/core. You can use that one as your secondary emulator if you can't get Demul to work. Demul is a little outdated, but still a good emulator. However, the retroarch flycast core and the redream emulators are updated much more frequently and are just as good, or better in some cases (IMO).

Those settings look fine to me, should make n64 games look as good as you can likely get anyway. The only setting I would recommend is disabling the Enable Threaded Video on the video tab on M64P. Unless you have a slower GPU, or your video card has poor OpenGL support (like ATI/AMD cards), it's usually recommended to not enable that feature. If for some reason you need to, then by all means you can do so though. Not all systems are the same, so it's hard to look at settings and say what is or not good

I'm not certain. When i downloaded my naomi/atomiswave set it was just for those two systems (ie. not bundled with other mame games). So, I was able to import those games into their own systems in LB/BB and tell each to use Flycast via retroarch. If you imported the entire system as Mame, then the only thing I can think of is maybe run a filter to just show the Naomi games (source = naomi.cpp maybe might work?), select those games then edit the emulator for those games in LB to tell them to use Retroarch/Flycast if that's possible. Or, if needed select those games then select the export/copy rom files to new folder. Then import that new folder as Sega Naomi (and have retroarch/Flycast associated to that Sega Naomi system).

Also, if you do decide to go with Project64, which as I mentioned is a decent emulator, don't worry about setting it up. That info you mentioned is for 1.6, which is a really old version. The more recent versions can be found at emucr.com (https://www.emucr.com/2020/04/project64-git-20200413.html) or on project64's website. I usually go with the versions on emucr.com since it tends to include the 64-bit builds, which the project64 website doesn't yet. But, as I mentioned in my previous post, I would still recommend M64P over project64 at this time. Also, FYI, if you do decide to run project64, at some point it's going to start nagging you to contribute to their emulator. Just click on enter code and type in "thank you from project64" (without the quotes) and that nag screen will no longer pop up

Project64 is an ok N64 emulator. It's actually been getting decent updates lately that is making it much better (IMO). However, I still suggest going with M64P (https://m64p.github.io/) as the best N64 emulator out of the box. There's very little setting up needed, and it runs really, really well out of the box. M64P that I mentioned here is not M64py that you mentioned. That is just a UI for Mupen64. M64P is Mupen64 + GlideN64 + GUI all in one package, already pre-configured for the most part, and working out of the box.

Glad you're making progress. As for the satellaview questions, unfortunately that is one console I never played with, so I have no experience with it in order to give any recommendations. But, if I do recall correctly when Byuu (the developper) unveiled his plans for Byuu (the emulator) he did mention that not all consoles would be supported right away. It's possible that Byuu (the emulator) does not yet support satellaview properly. Also, not sure if you noticed this or not, but in Byuu (the emulator) you need to actually tell it where your bios are stored for some of the consoles it does support, to work properly. Here's a screenshsot of mine (I didn't bother with the Neo Geo bios files as those are consoles I don't currently emulate... but if you do you'll have to point that to the correct location of your bios files as well) As for the --fullscreen command line, many emulators do support that. But, not all. The best place to look is when setting up a new emulator in LB, if it doesn't prefill the settings (ie. it's not a well known emulator) then it's a good idea to check the thread on the forums here for recommended command line's for different emulators. It's a little outdated, but for the most part it's still very relevant, and worth looking at (again only if LB doesn't recognize the emulator and prefill all the options/command lines, etc.)

I would suggest to map q (lower case) not Q (upper case) in the emulator. I'm not sure if it will matter or not in this instance, but I have seen cases where case does matter with AHK scripts. When it comes to coding, case does usually matter It might show as a Q in the hotkey even if you press q, but that's fine as long as q is what's mapped. If you do map it, and it doesn't work, try changing the script I posted to a Q. But, that is the script I use and it works 100% for me when mapped to "q".

Pause menu doesn't actually pass on a pause option to an emulator, as far as I know. The better thing to do in byuu's video options, set the emulator to pause on loss of focus. That way, when you press your key combo to go to the pause screen in LB/BB, the emulator "should" pause. To be honest, I'm not 100% sure if that works or not, as I don't really use the pause screens that much, and I haven't tested it with many emulators.

Yep, i figured with his emulators, since it had issues once before, it's safer to map an exit key in the emulator's hotkey scripts and then use an AHK script... just in case haha

Since that whole higan not saving properly when not closed properly, with any of his emulators I always map a hotkey to the exit command within the emulator and then use an AHK script to call the exit function properly in the emulator. And yes, this is the script I currently use for byuu, and what i used for bsnes before that.

Set the exit hotkey in byuu to something else. For example, I use q as a hotkey in byuu to quit the eumulator. Then in LB put this in your running autohotkey script: $Esc:: Send {q down} Sleep 50 Send {q up} Now when using the controller automation, or esc key in LB, it will pass on the q key to byuu, which will trigger the emulator to exit. I'm not sure about the byuu emulator, but I know his previous emulators such as Higan did not save properly if you used alt-f4 to close the emulator. Better off binding a hotkey and using ahk scripts, just in case this one is similar with that quirk

Thought it would be worth mentioning this again, as not doing this would prevent hiscores from submitting properly. For the hiscores to be submitted properly you need to do the following two steps: 1) be logged into a Launchbox Games Database/cloud account (via Cloud/Connect to Launchbox Games Database via the main menu 2) have submit hiscores enabled in the Mame option setting in LB. I'm sure you already followed the instructions to get it to work properly, but just in case I thought it would be worth repeating, if not for you, then for others who are trying out the beta's at a later stage in the process Hopefully, it's just something you missed there, and not an issue with the code.

Forgot to mention, but you need to setup the controller automation etc. in both launchbox and bigbox. They both have their own controller automation, and setting it up in one will not make it work in the other... it needs to be setup in both. Note, that in BB you don't map to the exit command section, rather to the Close The Active Window command instead.

Hmm, not sure why it would not be going into fullscreen, as long as you re-added all the command line parameters you removed, it should automatically go into fullscreen. If I recall correctly, the latest version of Higan doesn't play well with command line driven frontends (if at all). If you're looking for a good Super Nintendo Entertainment System stand alone emulator, I would suggest using either BSNES or Byuu (both by the same author who created Higan). Personally, I'd go with Byuu because it has nearly all the accuracy that Higan has, but it's a much more simplified version, that is still 100% command line compatible, which means it works very well with frontends like LB/BB. https://byuu.org/byuu#download With Byuu, and Higan if you want to keep using that, you can edit hotkeys within the emulator. You simply map a hotkey for exit to whatever you want to use (for example I use the q key on the keyboard). Then, in your exit script you then tell LB to use the q key to exit the emulator, for example: $Esc:: Send {q down} Sleep 50 Send {q up} Now when you use your controller automated button to trigger an exit, it will pass on the q key to the emulator as per the script, and then the emulator will quit correctly.

I'm not sure if it's possible to convert lst/bin format to be compatible with flycast, but I doubt it is (or if it is, if it's easy to do). I don't recall how hard it was to find naomi roms in the mame-style .zip format. I don't think it was super difficult, but it's been a long time since i looked for those types of roms, so it might be harder than I recall.

Not sure why NES would not show your box art/screenshots/videos etc. for that view. Try selecting a different theme maybe and see if that works, or a different view. As for the fullscreen issue with Kega Fusion, you should not remove those entries in the LB emulator settings, and I would suggest putting them back in, as they are the recommended command line settings to pass on to Kega for it to work properly with each console. Rather, I would check your setting within Kega Fusion. For example, under the Video section/Full Screen Resolution, make sure the correct resolution of your monitor is selected (in my example below, I used 1920x1080 as that's what my monitor/desktop is using). Also check the settings to make sure Fixed Aspect (Fit) is selected. It might be set to Zoom, or you might not have the correct resolution to match your desktop in the Full Screen Resolution section.

Yeah I just tested by trying to load a .bin file directly in retroarch while having the beetle_psx_hw core loaded, and it would not allow me to do so. So, unfortunately at this point I think you have 3 choices. 1 - Create .cue files for the games that you have that are missing those, and the edit the games in LB to point to those cue files (and use the beetle_psx_hw) core 2 - Download a newer rom file for those games that come with the correct files needed (bin/cue or iso will work) 3 - continue to use the rearmed core you were using (remember to edit the emulator/retroarch settings in LB again to use that core instead)

My guess at this point is likely the psx_hw core might not be able to load the bin file and needs to be loaded via the cue file (like we mentioned earlier). Try following the video I linked above and manually create a cue file for that one game, then edit the game in LB to point to the cue file (leave the core in LB's emulator settings to psx_hw). LB will tell retroarch to use that core, no matter what... and that's why it's not working right now via LB I suppose.

Assume you have the core actually downloaded in retroarch, and the associated bios files needed, I would suggest trying the beetal psx HW core, as that's generally considered the best for modern PC's (assuming you want to use modern features like upscalling, perspective correcting, etc.)... if you're looking for as much as a natural PSX renderer and not looking to upscale etc., then the regular beetle psx core is good for that. Edit: Mednafen = Beetle... for some reason they refer themselves as Mednafen in some places and Beetle in others.

If it works, then go ahead and use it I guess... but as neil9000 mentioned the reamred core is not the best when it comes to PSX emulation on the PC. But if it works then by all means continue to use it I guess. That core might explain the crash you mentioned earlier though. IMO the Mednafen_PSX_HW is the best core to use for PC emulation of PS1 games via retroarch.

@Headrush69 is correct. Forgot to notice that in the video. Flycast no longer support lst/bin formats I believe... just the .zip/CHD formats (aka Mame version of the roms)

Yes, those are two completely different cores. You want to edit your retroarch settings in LB and where it lists your Sony Playstation select the dropdown for the core and pick pcsx_rearmed_libretro.dll from the list.

Note: At the time he did this video the core was called Reicast... now it's called Flycast. Same core, just renamed.

hmm not sure why it would launch in retroarch, but not via LB... assuming you've correctly extracted the .bin and actually linked the file in LB to the .bin file instead of the .zip. However, as neil9000 mentioned, you seem to have an unusual format as normally PS1 games are in bin/cue, and you're missing the cue file for that rom. A cue file is a text file that tells emulators how what kind of .bin file is associated, and how to open it. Maybe check out an older ETAPrime video below where he walks through how to create a .cue file from scratch: Once you do have a .cue file, link LB to that file instead of the .bin, and hopefully it will launch correctly now.

There is hope, as he did mention that the game launches fine in retroarch... so presumably the .bin alone will work when passed on to retroarch from LB