blueMSX-libretro
blueMSX-libretro copied to clipboard
libretro
Add extended disk control API support + m3u fixes
- Implement RETRO_ENVIRONMENT_SET_DISK_CONTROL_EXT_INTERFACE support
- Add set_initial_image/get_image_path/get_image_label callbacks
- Fix disk image count initialization for single disk loads
- Add proper disk index validation and path matching
- Improve disk swapping stability with frontend coordination
- Fix M3U loading array boundary checks (it was hardcoded to two disks)
- Add disk path/type validation during insertion
- Update disk handling to support modern frontend features
@rtomasa Hello, i have cloned your master and compiled it on pi5 arm64 os. It crashes. any idea please
I have tried
make -f Makefile.libretro
and
make -f Makefile.libretro platform=unix
Could you confirm the system and version that you are using (whether it is Lakka, Retropie, Recalbox... etc.) and provide the Retroarch logs?
Actually I'm only testing the core with my own frontend, so not sure if there is something that Retroarch does not like.
Probably I wrongly presumed that it would be also working fine.
I'm simply using make to compile in Pi5 64bits too.
@rtomasa first of all thank you for trying to update/fix the disc control Im only trying to provide feedback. Im testing and compiling on pi5 Linux 6.6.74-current-bcm2711 aarch64 GNU/Linux - Armbian_community 25.5.0-trunk.4 noble
let me try simple make
Ohh OK so your problem is compiling, and not when executing the core right?
tested make . same fails to start the core from within RA i get just black screen. from retropie script of msx just goes back to ES i ll have a look tomorrow . going home :-) have a good night friend
It compiles ok. it does not load/run
OK I need to check the same in Retropie (Retroarch) since it is probably using a different method or execution order than my frontend for loading disks.
I have even compiled your master by replacing the git line to yours https://github.com/RetroPie/RetroPie-Setup/blob/master/scriptmodules/libretrocores/lr-bluemsx.sh
It uses an emulators.cfg file that calls retroarch to load the core from the installed path and load the selected rom Nothing crazy ;-)
Here is an example
lr-bluemsx = "/opt/retropie/emulators/retroarch/bin/retroarch -L /opt/retropie/libretrocores/lr-bluemsx/bluemsx_libretro.so --config /opt/retropie/configs/max/retroarch.cfg %ROM%"
default = "lr-bluemsx"
Sorry for taking so long to merge this.
Sorry but not sure if the changes really work in RetroArch because I only tested in my own frontend and the user above reported a crash when compiling my changes. Maybe it is better to wait for confirmation.
@rtomasa @LibretroAdmin at least for me it appears this change does break disk controls on Windows x64. It compiled fine for me, but when I try to Eject any disk it crashes RetroArch completely. Rolled back to 572c918 and disk control works as expected there.
Tested this on a clean install of RetroArch nightly from 4/14, with both a locally compiled version as well as the buildbot version of the core.
I will test first chance and report back if integrating is ok. As advised to @rtomasa compiling his own fork doesn't work on pi5 when tested
Thanks for confirming. We'll need to revert the PR temporarily until we've confirmed that the changes also work correctly in Retroarch. Sorry for the inconvenience.
@LibretroAdmin @rtomasa good day to all. finally bck to the office and tested it Wanted to say that this change needs to be reverted. The core crashes and wont load if I try to open .m3u Also another problem stated above. Im testing and compiling on pi5 Linux 6.6.74-current-bcm2711 aarch64 GNU/Linux - Armbian_community 25.5.0-trunk.4 noble
Rest extensions ex .zip .dsk core starts ok
I had some time today for testing and was planning to debug and fix, but I downloaded and compiled RetroArch v1.21.0 in RPi5 64bit and the core was working fine. I was able to load Snatcher.m3u with no crashes and chenge disks.