We just need to update our repo the same way @Awakened updated theirs. I don’t think we can PR directly from your repo, can we?
I’d like to request a feature for the 3ds citra cores. Being able to pull up a keyboard of some kind instead of the core autofilling every name-able thing with “CITRA” would be helpful please. I’ve attempted to include a screenshot of a text from the subreddit from someone else reporting the same issue since whoever posted it was able to put it into words better than I could.
Not sure. My repo is just me uploading the source files manually after unzipping them from the archive I can download from the mercurial repo. I know there are some changes in the libretro repo, like the retropad mapping.
yeah, I don’t think much of that is worth the trouble now that remapping is a thing. MoD was looking at reconciling the downstream changes, so hopefully we can ditch the actual forkiness and just mirror it to github/gitlab as-is moving forward.
2 Likes
Recently the PPSSPP emulator and RetroArch core got support for .chd files.
Wait, really? How? The core info page hasn’t yet been updated to show .chd as a viable extension and it didn’t work for me after pulling down the latest PPSSPP core v1.17.1-20-g539882086 from the RA online updater and converting one of my working PSP .iso files, either with the latest chdman v0.262 from mamedev.org or an older v0.233 I had to hand.
Please could I ask you to share the scripts you used? I tried the following createcd and createdvd ones but the PPSSPP core won’t recognise the resulting .chd when I try to load:
for %i in (*.iso) do chdman createcd -i "%i" -o "%~ni.chd"
for %i in (*.iso) do chdman createdvd -i "%i" -o "%~ni.chd"
As a side note, I’d previously used the createcd one to successfully convert PS2 .iso files for both CD and DVD based games, however the createdvd one resulted in a .chd which immediately force-close crashed my RA when loading them in PCSX2 core.
The documentation website did not update to include this information yet. But the actual core info files used by RetroArch has it already: https://github.com/libretro/libretro-super/blob/master/dist/info/ppsspp_libretro.info And I can confirm this to be working, as I converted my entire PSP collection into CHD and it plays fine. You need to update the .info files as well.
I use a self written Python application (call it script if you want), but it only works in Linux, so probably not useful for you on Windows: https://github.com/thingsiplay/tochd The conversion command itself is not very complicated, this is just for automation with naming and for unpacking archives.
For your PS2 issue, I don’t know what it can be that crashed RA on you. I converted all PS2 games to CHD as well, but it was createcd, as I did not know about doing this in DVD format back then. And I don’t have a PS2 .iso at hand right now, to test this with createdvd.
1 Like
Oh, I thought as mine was a new install of PPSSPP core (not used it before on Windows) it’d have pulled the most recent info files already but it seems that’s not the case; I followed your instructions which updated my ppsspp_libretro.info file and the .chd file generated by the createdvd script in my last post above worked; thank you!
MONSTER space saving, I went from a 542mb .iso to a 322mb .chd ! 
I tried doing similar with my PCSX2 .iso files, updated core and info files and then tried to follow the Windows instructions I found here. While the
for /r %%i in (*.chd) do chdman extractcd -i "%%i" -o "%%~ni.cue"
to convert back to .bin & .cue worked, the second
for /r %%i in (*.bin) do chdman createdvd -i "%%i" -o "%%~ni.chd"
.chd one didn’t, so I again tried the createdvd script in my last post above -and several variations thereof- but the resulting .chd still force-close crashed my RA every time; oh well. Maybe it’s a little early to expect the relatively new chdman createdvd script to play nicely with LRPS2, being as it is a core still in development 
1 Like
These are the two I used in my tests.
!BatchCSO2ISO.cmd
@echo off
@cls
set rompath=E:\Temp2\
set destpath=E:\Temp3\
for /R "%rompath%" %%G in (*.cso) do (
echo.
echo === Converting %%~nG to ISO ===
maxcso --decompress "%%G" --output-path="%destpath%
echo.
echo.
)
!Batch_PSP_ISO2CHD_All_CPU.cmd
@echo off
@cls
set rompath=E:\Temp2\
set destpath=E:\Temp3\
for /R "%rompath%" %%G in (*.iso) do (
echo.
echo === Converting "%%~nG" to CHD ===
chdman createdvd -i "%%G" -o "%destpath%\%%~nG.chd" -f
echo.
echo.
)
You could also limit the number of cores used during conversion…
!Batch_PSP_ISO2CHD.cmd
@echo off
@cls
set rompath=E:\Temp2\
set destpath=E:\Temp3\
for /R "%rompath%" %%G in (*.iso) do (
echo.
echo === Converting "%%~nG" to CHD ===
chdman createdvd -np 6 -i "%%G" -o "%destpath%\%%~nG.chd" -f
echo.
echo.
)
…using the -np 6 switch. (It needs to be an even number, at least on Intel multi-threaded systems.)
3 Likes
…and thank you also, I really don’t have that many PSP ROMs to need these batch scripts but may come in handy down the line (also, I don’t know how limiting the number of cores would help the re-encode but I’m on an AMD Ryzen anyway); appreciate it 
Not so much the re-encode, but if you want to do anything else while the batch is running it would free up some CPU resources.
Ok so I have tested this with PS2 games as well. As you discovered, the createdvd format does not work with PCSX2 in RetroArch. I’ts signal: 5 (SIGTRAP) (core dumped) for me. So the idea to determine this by filesize does not work reliably and I think createcd is a good default for most stuff. Use createdvd when you know its better, such as with PSP (maybe this is emulator/core dependent?).
2 Likes
Any support or contemplation for a Commdore 65 and mega65 cores? I see this one runs not so bad:
And is announced in the official mega65 page. Or is hard to add do?
Currently there are config files which:
a) are merged and saved to the main configuration at retroarch.cfg when closing RetroArch, and b) are just loaded in as settings without affecting the main configuration file
Let me explain. RetroArch has the ability to save the last made settings in the menu, like driver or other things, when closing the application. retroarch.cfg will be updated. There are also user defined configuration files that are only loaded in when using specific cores in example. They are located under ~/.config/retroarch/config/ on my system. These files are just read only and won’t affect the main retroarch.cfg file after closing RetroArch.
Alright then. RetroArch has commandline options to allow loading additional config options with
--appendconfig=FILE . This is great if you want have some special settings active under very
specific conditions. The problem is, that the .cfg file specified with --appendconfig will be
merged with the main configuration file retroarch.cfg when closing RetroArch. But I don’t want them
to be saved.
That’s my point. I want these additional configuration files that I can specify in the commandline
to act like the previously discussed Core-specific overrides. Maybe a new option called overrideconfig=FILE
could be introduced.
Edit: I completely rephrased my explanation.
Just add “config_save_on_exit = “false”” to your append-able fragments. That’s what I do.
I do that since years as well, but config_save_on_exit = "false" is not sufficient to me (for some cases). In those cases I would like RetroArch act like always, where I can make changes to the settings while playing. That has something to do with my setup, where I would like to have some additional settings associated without “infecting” the configuration, while retaining the normal behavior of saving all other settings. An workaround could be in example (with a script) to copy the retroarch/config/core/bsnes directory to a temporary folder and then edit the hell out of it how I want it to be. But as far as I know RetroArch does not allow us to set a core config directory, right?
Why am I even doing this? There was a few other cases in the past several years, but the recent one is Mega Bezel. Actually, this is one of the reasons why I never got into it. I would like to setup a script (or something else) that runs a specific game with this Shader --set-shader. Alongside I would “need” a specific configuration that deviates from my personal setup and should be active temporarily just for this Shader, while being able to save other configuration settings while playing.
But this was just one example. It would be nice to be able to use any configuration file like that. In example I would like to run RetroArch in window mode or with specific window sizes or other configuration. I could implement all sorts of commandline options myself, things RetroArch does not support.
You can’t save with an override either. Append-config + config_save_on_exit = false is functionally identical to an override.
But the core overrides or folder overrides in the config/bsnes/bsnes.cfg is loading automatically with each start of RetroArch. While being able to save the configuration on exit. In fact, I have bunch of automatic overrides for cores, some specific folders and other stuff. It is not identical to append-config + config_save_on_exit = false.
Hmm, no, I just tested it to be sure, and save-on-exit is indeed disabled while an override is active. You can manually save the config via main menu > configuration file, but you can do that with an appended config, as well.
The problem with manual menu > configuration file saving is, that all settings would be saved. Even those which are not intended to be. In example I have overrides for every single core that defines some basic settings, such as screenshot folder and which gamepad to use. When I run RetroArch, the overrides get loaded in with the custom settings and when I close RetroArch all settings I have done are saved without saving the screenshot folder. Because the overrides are read only.
Now imagine I had those settings as an append-config file + config_save_on_exit = false. I play around and then decide I need to make changes on live system, hit menu > configuration file save and whoops everything is from the append-config is saved to retroarch.cfg as well.
Having something like --overrides-config=FILE would also make it much easier to deploy some custom settings for others.
Yeah, this is the part i’m not following, since it doesn’t happen here. Once the override is active, no additional changes save unless I manually ‘save core override’ again, which replaces the original override with whatever settings currently differ from the main config.