[RetroPie] ipf and porblems with automounts from usb devices

[ZzackKbin]

You closed little bit too fast my topic :(

Files ipf not working for me and why:

[libretro INFO] Opening cfgfile '/home/pi/RetroPie/roms/amiga//puae_libretro.uae' [libretro INFO] Known ROM 'KS ROM v1.3 (A500,A1000,A2000)' loaded [libretro INFO] DLOPEN: /home/pi/RetroPie/BIOS/capsimg.so: failed to map segment from shared object [libretro INFO] DLOPEN: Failed to open /home/pi/RetroPie/BIOS/capsimg.so [libretro INFO] Unable to open capsimg.so [libretro INFO] Failed to load CAPS plug-in. [libretro INFO] This disk image needs the C.A.P.S. plugin which is available from http://www.softpres.org/download [libretro INFO] No disk in drive 0.

When I run games from microcards with retropie system is ok but if I use auto-mount method* for USB external devices core cant find capsimg plugin ( I manual copy caps plugin to usb folder bios and microcard).

---

Automatic Mount (Easiest Method)

Before proceeding, make sure the usbromservice (Optional packages section) is installed and enabled, especially if you have installed RetroPie manually.

Create a folder called retropie-mount on the USB drive
Plug into Raspberry Pi
It will proceed to automatically copy the RetroPie folder AND all of its contents (you may need to reboot to start the copying)

[sonninnos]

And I will close again, because there is nothing to be done here on this end. Something is wrong with your file, not the code.

This repo is not affiliated with RetroPie in any way, so having RetroPie issues anywhere else except their repos leads nowhere. Replying is still possible even if it is closed.

[ZzackKbin]

I checked all: Game file and plugin are ok. -microcard with retropie and plugin in bios working normal and game mount in df0 and start. -microcard with retropie and game in extrenal usb device make problems with bios folder for core.

RPi4 with retropie 4.7 plus fuction auto-mount for external usb devices.

Folder retropie-mount on external usb device change bios folder for external usb bios folder and core cant find capsimg.so.

[sonninnos]

Maybe it is worth a shot to move capsimg.so to the same directory where RetroArch executable is. First the core checks if it exists in the directory where all BIOS files are, and then without path, because Android does not have permissions to load dynamic libraries from any directory.

[ZzackKbin]

I did it. I copy plugin for two directories and core can't find plugin but without pendrive works perfect. It looks like core cant load plugin from bios folder on usb.

[ZzackKbin]

lr-hatari core doesn't have problems with ipf and external usb devices.

[sonninnos]

In that case it should be looked at what it does differently.

[crystalct]

There is an altenative. CAPSIMG library is free for non commercial purposes or even better (open source, i should check nowadays) and tiny as bytes size. So why dont link statically it directly inside core?

[crystalct]

https://kryoflux.com/?page=download

This licence is based on the MAME licence and is intended for use in all non-commercial projects and environments. Other licensing options are available. Don't hesitate - please contact us at licensing@kryoflux.com.

PREAMBLE

The purpose ("Purpose") of the SPS DECODER LIBRARY ("CLL", "CAPSImage", "CAPSImg", etc.) is to enable third party software to use The Software Preservation Society Interchangeable Preservation Format ("IPF"), Software Preservation Society Capture Tool RAW ("CT RAW", "RAW") and KryoFlux STREAM ("KF STREAM", "RAW") format files as produced by e.g. The Software Preservation Analyser, KryoFlux - High Definition Flux Sampler for USB or KryoFlux FREE.

LICENCE

Redistribution and use of the SPS DECODER LIBRARY code is permitted provided that the following conditions are met:

- Redistributions may not be sold, nor may they be used in a commercial product or activity.

- Redistributions that are modified from the original source must include the complete source code, including the source code for all components used by a binary built from the modified sources. However, as a special exception, the source code distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable.

- Aforementioned modifications to the code can be made to enhance the code or to make it compile on other platforms than originally supported. Modifications must still satisfy the Purpose. Any file formats other than those listed under Purpose must not be enabled through the SPS DECODER LIBRARY.  

- Redistributions must reproduce the following copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.

THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

COPYRIGHT

SPS DECODER LIBRARY Copyright (c) 2001-2014 by István Fábián under exclusive licence to KryoFlux Products & Services Ltd, 80 Allington Way, Maidstone, ME16 0HN, United Kingdom. All rights reserved.

COMMON QUESTIONS

Q. Can I include the SPS DECODER LIBRARY with my commercial product?
A. No. The SPS DECODER LIBRARY is not licensed for commercial use. Using SPS DECODER LIBRARY as a "freebie" or including it at "no cost" with your product still constitutes commerical usage and is forbidden by the licence.

Q. Can I sell my product with the SPS DECODER LIBRARY or associated logos (e.g. SPS, KryoFlux) on it?
A. No. Putting the name or logo on your product makes it appear that the product is something officially endorsed.

Q. Can I use the SPS DECODER LIBRARY or the SPS logo to advertise my product?
A. No. Using the name or logo in your advertising makes it appear that the product is something officially endorsed.

Q. Can I use the term "SPS DECODER LIBRARY" in the name of my software?
A. Generally, no, especially if it is something that is sold. However, if you are producing a free SPS DECODER LIBRARY-related piece of software, it is common that permission is granted. Send a query to double-check first, please.

Q. Can I ask for donations for the work I did on my port of SPS DECODER LIBRARY to platform X?
A. No. You would be earning money from the SPS DECODER LIBRARY trademark and copyrights, and that would be a commercial use, which is prohibited by the licence. It is our wish that SPS DECODER LIBRARY remains free.

v1.02
2014-05-20

[rsn8887]

The license is not compatible AFAIK. This has been discussed numerous times on Discord. But it is good to do a new discussion here and figure this out once and for all.

[crystalct]

It's a gray zone, surely. IPS functions aren't part of this project but recalled from an external library. This doesn't break GPL 2 licence. At end of compilation, when you link objects, if you link statically a free library, but not GPL 2, you break GPL2 licence of your project, even if all your sources are GPL2 compliant... Final exe/ELF/DLL must be GPL2 or sources must be GPL2? It's seems that who break rules is who make final product.

[sonninnos]

But apparently hatari can somehow do it without dlopen shenanigans..?

I was rather hoping only for the option for self-building, and leave buildbot as it is.

[sepecat]

I'm trying to make a RetroArch build that installs capsimg.so so that the buildbot builds of the puae core can load it. I got as far as the library being included in the libs/\<arch> dir in the APK, but the core still can't find it because it only looks in the appliction root and /mnt/expand dirs. I don't have root on the Android device and cannot easily root it (would reformat which means ages of recopying and reconfiguring).

I've since removed the library from the RetroArch system dir but this error shows what paths it searches in:

12-06 01:37:49.868 17527 17555 E linker  : library "/storage/emulated/0/RetroArch/system/capsimg.so" ("/storage/emulated/0/RetroArch/system/capsimg.so") needed or dlopened by "/data/user/0/com.retroarch.ra32/cores/puae_libretro_android.so" is not accessible for the namespace: [name="classloader-namespace", ld_library_paths="", default_library_paths="/data/app/~~_bRxJI9YLlAjB6bxUFWOJA==/com.retroarch.ra32-sA8B2zA8YFsRUxKP_BVaoA==/lib/arm:/data/app/~~_bRxJI9YLlAjB6bxUFWOJA==/com.retroarch.ra32-sA8B2zA8YFsRUxKP_BVaoA==/base.apk!/lib/armeabi-v7a", permitted_paths="/data:/mnt/expand:/data/user/0/com.retroarch.ra32"

Could anyone point me on how to either install lib to application dir in the RetroArch Gradle / ndkbuild project or maybe specify additional paths for permitted_paths ?

[crystalct]

In a windows system, putting capsimg.so inside RetroArch/system, does it work?

[sonninnos]

Yes, desktops allow loading dlls out of executable dirs, therefore the code first checks the file from system, and if not found, then from the executable directory. Not much to be done core-wise to allow reading it from any other place.

The libretro hack currently only notifies about the nonexistence of the file, and not if it is being opened correctly, which only goes to the log.

    snprintf(CAPSLIB_PATH, RETRO_PATH_MAX, "%s%c%s", retro_system_directory, DIR_SEP_CHR, CAPSLIB_NAME);
    if (!path_is_valid(CAPSLIB_PATH))
        snprintf(CAPSLIB_PATH, RETRO_PATH_MAX, "%s", CAPSLIB_NAME);
    if (!path_is_valid(CAPSLIB_PATH))
    {
        snprintf(retro_message_msg, sizeof(retro_message_msg), "CAPS library '%s' not found!", CAPSLIB_NAME);
        retro_message = true;
    }

It has been suggested that maybe the core could copy the file to a permitted path when using Android, but that might bring another set of problems when for example the file is the wrong version the first time. Always overwriting would be stupid too, and how could deleting be allowed.. That is if even the running instance has enough permissions to do any of that.

Would be so much nicer to just have the library baked in..

[vadosnaprimer]

Would be so much nicer to just have the library baked in..

There is a couple actual open source re-implementations of it. https://github.com/mamedev/mame/blob/master/src/lib/formats/ipf_dsk.cpp (amusingly made 4 days before SPS released their code) https://github.com/Tom1975/CPCCore/blob/master/CPCCoreEmu/CAPSFile.cpp

API is different in them, so it'd involve a bit of reworking to integrate either of them. But it's always nice to be self-contained (for example WHDLoad support is now integrated, which is a huge plus).