RA: PCSX ReARMed crashing on Final Fantasy 7 - ios 9.35

I’d do it but I think I don’t have that forum priviledge yet!

There should be a pen icon next to the title if you have the privilege…

That’s the issue, no pen icon. I guess it’s because I’m still a basic member and need to be a regular one. Guess I have to play around in this forum for a while!

I have compiled several dozen versions to pinpoint the commit: d148d26 (September 19, 2016) At this point, the approach with clearing cache changed, as well as some other changes to dynamic recompilation.

@AfonsoH Please check these versions on your iPadMini with iOS 9.3.5:

All of these versions are not signed with a developer certificate, but on a device with Jailbreak and AppSync they should work(in my case it works). For test use version WITHOUT _interpreter :slightly_smiling_face:

If the behavior is similar to that I assumed, then the problem appeared on September 19 2016 and persists on any 32-bit version of iOS. In the near future I will create a post on the GitHub and this will be required in order to accurately understand the scale of the problem.

Please report your experience!

1 Like

Thanks for all the efforts. Will try them today as soon as I can :wink:

1 Like

@dagazik just tested them with the usual suspect (FF VII, starting a new game, FMV intro then play for about 5min, 2/3 battles and several rooms which trigger cd loading) and the results were:

running without problems

Did crash right after the first battle ended.

Loaded but seems like the input is not working at all (couldnt skip the intro credits by pressing start); tested other roms as well and same behaviour: input does not work (tried both onscreen buttons and external controller which I use (gamevice for iPad mini)).

1 Like

@AfonsoH Yesterday i posted the results of our investigation on GitHub here:
[iOS5 - iOS9] BIG BUG in 80% games / application random crashes when using dynarec x32 :sweat_smile:

Please check a few more modified versions on your iPadMini with iOS 9.3.5:

These versions are not signed with a developer certificate, but on a device with Jailbreak and AppSync they should work(in my case it works). For test use version WITHOUT _interpreter :slightly_smiling_face:

This test will allow to accurately determine what exactly broke the input on your device - and in the future support iOS5 without breaking iOS9.

1 Like

nice :slight_smile: a bit more of Sherlock then:

input not working on this one :point_up_2:

input also not working in this one :point_up_2:

and finally … input not working too in this one :point_up_2:

Are these good or bad news?

1 Like

@AfonsoH This is good news because we have the test results - thank you! :smile:

Now it is clear that these lines of code in " frontend/libretro.c":

#ifdef __MACH__
    // magic sauce to make the dynarec work on iOS
    syscall(SYS_ptrace, 0 /*PTRACE_TRACEME*/, 0, 0, 0);
#endif
  • Helping to work with input on ios9, and that for its work, in addition to the obvious “syscall”, “unistd” library is also needed(regardless of the fact that it is not explicitly called).
  • However, the presence of this code in ios5 causes retention in RAM, and its absence does not interfere with the input.

A good solution: isolating the code into a logical construct - i will propose such a solution on GitHub and open this topic again.

But all these thoughts will be correct only if the original version has no input error. So I want to ask you to test these NON MODIFIED versions one last time:

These versions are not signed with a developer certificate, but on a device with Jailbreak and AppSync they should work(in my case it works). For test use version WITHOUT _interpreter :slightly_smiling_face:

You have already tested build number d56340b, (because you indicated it in the first post of this thread forum) - in current test we will check if there is an error in my compilation settings (source code has NOT been changed).

As for the build number c2d67cd, I added it in case an input error in the build number b715d67 - we can understand whether this was fixed in the latest version.

great! Now for the new tests (testing again with FFVII, starting new game):

This one :point_up_2: : input is working, but did crash before the first fight began (i.e. right AFTER the battle swirl); tried 2 times, same outcome;

and this one :point_up_2: : input is not working, did not get past intro screen;

and this last one :point_up_2: input is working, but crashed as well, this time BEFORE the battle swirl); tried again and it got past the battle swirl but then crashed suddenly when moving around in map mode (i.e. without changing to/from a battle or to another scenario).

1 Like

Well, it looks like the original b715d67 had problems with the input - it means that the conclusions of the old test were not correct. :pensive: Sorry… I should have included the original b715d67 in the test package from the beginning.

If you are still not tired, I want to ask you to check these MODIFIED versions based on the notoriously working c2d67cd:

These versions are not signed with a developer certificate, but on a device with Jailbreak and AppSync they should work(in my case it works). For test use version WITHOUT _interpreter :slightly_smiling_face:

This time it’s really the last test :sweat_smile:

no worries, retroarch is making me feel nostalgic by allowing me to replay some childhood games so this is an opoortunity to give back! I’ll do as many tests as needed. Later today I’ll test those.

I tried to change the way of clearing the cache, but this approach will not work on iOS5 - I don’t know whether it worked or not for ios9: pcsx_rearmed-2016-09-19_r22_d148d26_FIX_CACHE

Here we go again!

This one :point_up_2: input working, crashed after first battle ended;

This one :point_up_2: input working but very sensitive, crashed 2 times after the intro credits, then before first battle even started;

This one :point_up_2: input working, crashed like the one above, right after intro credits;

This one :point_up_2: crashes right after clicking the rom file to load, before loading anything at all.

1 Like

@AfonsoH Thank you - then we’ll finish with the tests for now. :slightly_smiling_face:

What is the region of your version of FF7, are there modifications like translation or hacks in and what BIOS do you use? I want to check this version on my device.

Interested effect presence of “magic sauce” on stability in the case of iOS5.

Great! I am using European version (SCES-00867, SCES-10867, SCES-20867), no mods nor hacks. For BIOS I realized that for all the past tests I was using SCPH-101. I thought I was using the default ones but I tried so many and forgot about it. Do you think this is problematic? I can repeat all the tests in this weekend with a default BIOS (like 5500/5501/5502) if that is important to fix the core.

@AfonsoH No, this is not a problem - i will try several BIOS :slightly_smiling_face:

@AfonsoH I tested your version FF7(SCES-00867):
Used BIOS scph101 + RetroArch 1.9.0 + iOS5.1.1 and ran each variant at least five times.

  • 2021-02-17_r22_c2d67cd_YES_SAUCE / intro video not crash, crashes at end of first battle.
  • 2021-02-17_r22_c2d67cd_NO_SAUCE / intro video not crash, crashes in middle of first battle.

…and in both cases sometimes before start of battle. :confused:

Note: I have not indicated additional libraries in name because the result does not depend on them.

It looks like the “magic sauce” has some minor effect in the case of iOS5.

How many times can you boot from a save snapshot? (i can do this only once, subsequent download gives the app crash)

I remember that with some cores the load state function crashed as well, didn’t realize it was at the second time (though it was random crash). I will test today. Are you asking this for these two cores? :point_down:

@AfonsoH For a complete understanding, you can test these versions:

These versions are not signed with a developer certificate, but on a device with Jailbreak and AppSync they should work(in my case it works). For test use version WITHOUT _interpreter :slightly_smiling_face: