[BOUNTY] Update Core to Fuse 1.5.0 or greater

[Gazdaman]

Bounty created in an effort to incentivize someone to update the fuse-libretro core to use Fuse source code 1.5.0 or greater. No other expectations are included in the bounty.

Bounty Link: https://www.bountysource.com/issues/96019983-bounty-update-core-to-fuse-1-5-0-or-greater

Nice to haves would be to fix the mapping issues with inverted retropad controls and also fix the issue where remapping the fire button causes the keyboard not to work. These are not required to be completed in order to claim the bounty,

Bounty goal: Core updated and working with Fuse source code 1.5.0 or higher version

[fadedreamz]

@Gazdaman would like to give it a shot, kindly assign it to me.

[Gazdaman]

@fadedreamz I don't have write privilege's to this repo to assign it to you. I suggest you visit the Libretro discord and ask there for someone to assign it to you. In the meantime, there is nothing stopping you from downloading the source codes and trying to update and compile the source yourself.

[fadedreamz]

@Gazdaman sorry I don't have discord. I managed to update the fuse (1.5.7) and libspectrum (1.4.4) to the latest version and was able to build the fuse_libretro.so file. But I am not sure how to test it. I tried putting it in the cores of the RetroArch, but it seems rather broken as I can't download any cores. Do you have any step by step procedure to setup RetroArch so that I can test it? Using Ubuntu 20.04, TIA

[Gazdaman]

Assuming you have forked the repo, you can upload your changes to your fork on github for others to test. If you don't want to do that until you prove your code works then you will need to find a way to test the core yourself. Youtube is probably the best bet for guides on how to setup RetroArch.

Other than that, maybe the previous core maintainer @leiradel could give you some direction.

[leiradel]

@Gazdaman you can try to run the core directly from the command line:

retroarch -L fuse_libretro.so some_game.tzx

[fadedreamz]

@Gazdaman I have uploaded the commit. But using @leiradel 's command it crashed. I am going to continue working on this in my free time as the work is much bigger than just updating and fixing the library. I believe a little porting is also needed.

So, the first issue is a segfault while running - settings_command_line( settings_info *settings, int *first_arg, int argc, char **argv ) from src/fuse/settings.c the getopt is causing the crash. So my question is to the experts, is it safe to return 0 from the settings_command_line ?

For those who want to help here is the stack trace -

#0  0x00007ffff72e51a7 in _getopt_internal_r (argc=1, argv=0x7fffffff5178, optstring=0x7ffff5a1672a "d:hm:o:p:f:r:s:t:v:g:j:V", longopts=0x7fffffff28a0, longind=0x0, long_only=long_only@entry=0, 
    d=0x7ffff73cf260 <getopt_data>, posixly_correct=0) at getopt.c:527
#1  0x00007ffff72e56d5 in _getopt_internal (argc=<optimized out>, argv=<optimized out>, optstring=<optimized out>, longopts=<optimized out>, longind=<optimized out>, long_only=long_only@entry=0, 
    posixly_correct=0) at getopt.c:711
#2  0x00007ffff72e5762 in getopt_long (argc=<optimized out>, argv=<optimized out>, options=<optimized out>, long_options=<optimized out>, opt_index=<optimized out>) at getopt1.c:31
#3  0x00007ffff593427f in settings_command_line (settings=0x7ffff5d585e0 <settings_current>, first_arg=0x7fffffff5010, argc=1, argv=0x7fffffff5178) at ./settings.pl:623
#4  0x00007ffff592983a in fuse_settings_init (first_arg=0x7fffffff5010, argc=1, argv=0x7fffffff5178) at ./settings.pl:150
#5  0x00007ffff59394a0 in settings_init (first_arg=0x7fffffff5010, argc=1, argv=0x7fffffff5178) at src/fuse/settings.c:13
#6  0x00007ffff591c91b in fuse_init_static (argc=1, argv=0x7fffffff5178) at ./fuse/fuse.c:374
#7  0x00007ffff591dda7 in fuse_init (argc=1, argv=0x7fffffff5178) at src/fuse/fuse.c:13
#8  0x00007ffff5844c30 in retro_load_game (info=0x5555561ed3a0) at src/libretro.c:641
#9  0x000055555560159c in core_load_game ()
#10 0x000055555562b392 in content_file_load ()
#11 0x000055555562de31 in content_init ()
#12 0x00005555556050fb in command_event ()
#13 0x0000555555614141 in retroarch_main_init ()
#14 0x000055555562b7cc in content_load.isra ()
#15 0x000055555562c1a5 in task_load_content_internal.constprop ()
#16 0x000055555561c70f in rarch_main ()
#17 0x00007ffff72070b3 in __libc_start_main (main=0x5555555d7860 <main>, argc=4, argv=0x7fffffffdef8, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7fffffffdee8)
    at ../csu/libc-start.c:308
#18 0x00005555555d7b8e in _start (

As it is hard to believe that there is a bug in getopt, I think we might be missing some initialization of data in the src/fuse/settings.c.

[leiradel]

@fadedreamz FWIW the proper way to port Fuse to Libretro (or any other platform for that matter) is to create a subfolder in the ui folder and implement the required functions. That's where I'd start the update if I could do it myself.

[tomconte]

Hi everyone, I have managed to update the core to 1.6.0 and compile/test it on my machine (macOS). However I am pretty new to libretro in general, what is the best way now to check that it compiles/works on all/most of the required targets?

If you are curious: https://github.com/tomconte/fuse-libretro/tree/update-1.6.0

[tomconte]

Travis build looks good: https://travis-ci.com/github/tomconte/fuse-libretro/builds/221901290

[zzedmore]

@tomconte Hi, I tried to build this on the Pi 400, i'm not sure if i'm doing it correctly. I directed the Retropie lr-fuse script to your lr-fuse update-1.6.0 but when building it said memory_pages.h was missing ?

[tomconte]

Thanks for testing this @zzedmore ! I tried building from scratch after cloning my repo, and sure thing some header files had been ignored... I have added them now and was able to compile. Could you give it another try?

[zzedmore]

It builds now but nothing runs, it just exits out. The log says -

/opt/retropie/supplementary/runcommand/runcommand.sh: line 1285: 8867 Segmentation fault

[fadedreamz]

@zzedmore see my earlier comment for a possible bt. Although it is libretro-1.5.7 with libspectrum 1.4.4, it builds but fails to run. I think because of the changes in fuse-libretro and libspectrum a little porting is required. Maybe the wrapper functions needs to be updated (e,g - fuse/settings.c), to properly integrate with libretro?

[zzedmore]

Yeah, shame the original porter @leiradel can't help on this.

[tomconte]

@zzedmore I have tested builds on both macOS and iOS using the latest stable version of RetroArch so maybe this is something specific to the RPi... I will try to do some testing on a Pi Zero I have lying around.

[tomconte]

OK, I am now testing with RetroPie on a Zero W... I pushed a change to use the built-in getopt_long implementation and I got past the seg fault. Unfortunately I now get:

fuse: error: out of memory at fuse/sound.c:138

Hopefully this is only due to the Pi Zero minuscule amount of RAM... 😅 @zzedmore could you give it another try? I appreciate your help!

[zzedmore]

I get the same error i'm afraid -

fuse: error: out of memory at fuse/sound.c:138
[libretro ERROR] out of memory at fuse/sound.c:138

Black screen and complete lockup. Had to power off/on.

[tomconte]

@zzedmore Appreciate your patience! I have removed a setting to increase the "blip buffer accuracy" and now I managed to run my favourite game on my Pi Zero. It sounded odd to me indeed that emulating the poor Spectrum bleeper required more than 512MB of RAM 😅

[zzedmore]

Confirmed, it's now working ! Good job @tomconte I wonder if you might be able to fix something and add a new core option ?

1) The tape fast load option. Even when it's set to off it still Turbo loads the first block or two.

2) When loading SCL or TRD files (TR-DOS) it would be nice to have a core option to set which machine will run them. I think the default is 'Scorpion'. It would be good if we could choose Pentagon 128K and Pentagon 512K as they have different timing to the Scorpion.

Thanks for your hard work!

[snoofly]

Confirmed, it's now working ! Good job @tomconte I wonder if you might be able to fix something and add a new core option ?

1. The tape fast load option. Even when it's set to off it still Turbo loads the first block or two.
2. When loading SCL or TRD files (TR-DOS) it would be nice to have a core option to set which machine will run them. I think the default is 'Scorpion'. It would be good if we could choose Pentagon 128K and Pentagon 512K as they have different timing to the Scorpion.

Thanks for your hard work!

Yes great job on the upgrade. I managed to build the core for switch/libnx fine with the memory_pages.h fix but get some retroarch dependency issue with hid stuff building the actual nro to test. But I mainly want to endorse a fix for point 1 above. I hoped these updates fixed it but I guess not. https://github.com/libretro/fuse-libretro/issues/62 has some findings I made a while back that may help.

[tomconte]

Thanks all for your help. I am happy to look at the other issues with the core but I would prefer to work on separate pull requests once #89 gets merged!

[zzedmore]

@tomconte When this does finally get merged (which is weird because the maintainer was on here the day you made the pull request), would you have any ideas about the two points I mentioned ? The loading speed toggle has been partially broken since day 1. The first post in https://github.com/libretro/fuse-libretro/issues/62 sounds good to have as the three options. Thanks for your work on this !

[snoofly]

Sweet. Built my own switch fuse retroarch nro based on this update with the tape slow load fix and it all works great. Many thanks for your work on this @tomconte.

[tomconte]

I am going to close this, now that the changes have been merged for a while.