@GiraffeMan3125 @Emiliapol81 Can you try 2048 again from my iOS repo?
I compiled many other cores too! (On an older version of OSX, with an older developer SDK…) We have some chances they will work on iOS 5!
I tested the core 2048 with the ipa from this thread and also with the repo version. But neither of them worked. The application closes unexpectedly, with 2048 and with any other core.
@Emiliapol81 Ok, it may be RetroArch itself then…
@GiraffeMan3125 @Emiliapol81 Could you try updating RetroArch itself now? I made some changes to it, let’s hope this works now…
@Weedy_Weed_Smoker thank you very much for your help. I installed the new update from cydia and it worked perfect. So far I have tried the 2048 core and some nes and snes roms and I had no problems!
1 Like
At the moment the problem I have is that I cannot run n64 roms. The app crashes after loading the content. Can you help me with that?
I just tested it, and the new version works for me too.
1 Like
Thank you very much for compiling for iOS 5. This allowed me to dust off the iPad1Gen and run PS1 games on it, which to my surprise run at full speed! 
But there is a small problem:
The ReARMed core freezes spontaneously in some games and does not allow the application to be minimized - have to do a hard hardware reboot, the process simply not respond to SSH terminal commands. It also freezes when trying to load a game from a snapshot of the emulator. At the same time, on a PC, all these games work without problems on the this core.
I also tested Snes9x, PicoDrive, FBNeo - they work great and saved (if incompatibility with rom occurs ios does not die)
1 Like
@dagazik That may very well be because of the extremely small amount of RAM available on the first iPad (only 256MB!), which has to be shared between the system and apps…
I think the apps can use virtual memory up to 4GB on 32-bit devices, but you may not have enough space left on the device for that to happen efficiently, and I’m not even sure if iOS 5 allocates virtual memory… There might be a tweak that allows you to use virtual memory on early iOS but I don’t quite remember…
I also thought about RAM first and connected via “PuTTY” ssh by running “top” - the RetroArch with ReARMed and game takes 90 MB RAM in peak and about 60 MB more free! In addition, if there is a lack of memory, then in normal mode the system forcibly closes the process.
Here are some examples of why this is NOT RAM:
- Crash Bandicoot 2 randomly freezes in various places after a while and always on loading a save snapshot. This is what the process monitor looks like:
Demo in YouTube: https://www.youtube.com/watch?v=W3yJ9tax5-8 The video showed how it freezes at the moment of loading the save, but game can also freeze in any other place.
-
Metal Slug 5 on the FBNeo(NeoGeo) core occupying 140MB works without problems.
-
The core of the Beetle PSX runs good but is slow.
Problem is not in the save (this is an additional bug that I identified, but i can also use the memory card). The problem is that on the ReARMed core the games freeze in those places where they work on the PC version RetroArch/ReARMed, and also that the hang kills the entire system before a hard reboot.
@dagazik Ok, this seems to be a problem with PCSX ReARMed then, I’m not sure what I can do as I don’t have a device on iOS 5 to test…
I will try to compile a newer version hoping the bug has been fixed! (Not too confident though, sorry…)
Does this only happen with Crash Bandicoot 2?
If so you may want to try a disc from another source… I don’t know if you should compress it to chd or not but it might be worth a try too!
But as you said Beetle PSX handles it fine so I’m not sure if it’s going to change anything… Hope we can get this fixed somehow!
BTW, do you use a .bin/.cue image?
1 Like
@Weedy_Weed_Smoker Random freezes have occurred throughout the Crash Bandicoot(1,2,3 Race, Bash) series and so far I’ve only noticed this behavior in it.
In other games, freezes occur at specific points. In total, I tested about 20 games and mostly I used .bin/.cue images.
But Several hours ago, I experimented and slightly improved the situation by replacing the BIOS with scph7001.bin instead of 5500, 5501, 5502 from your build. I was very surprised that the BIOS version can affect the ReARMed so much and I tested all the bios. For example, with 1001, almost nothing works, but 7001 and 101 seem to show the best results!
Now Crash Bandicoot 2 does not freeze, other games also began to work better, for example:
- Disney’s Hercules Action Game now freezes when loading the third level, whereas previously it hung on the first :))
- Crash Bash no longer freezes on certain challenges, but still freezes randomly.
- Harry Potter and the Sorcerer’s Stone worked, and before that hung on the EA logo.
But this is still worse than the kernel version on my PC because everything works well there(I don’t know if it is correct to compare ReARMed in the ARM version with x64).
@Weedy_Weed_Smoker I think I understood why there is a hang when trying to load from a snapshot: most likely the code is written in such a way that the old core is terminated, and the new one should be loaded again with the state of the snapshot.
But the fact is that, as I said, ReARMed is the only core after loading which iOS is not able to complete the RetroArch process! 
This is how RetroArch reacts to commands in the terminal:
- If don’t load the core:
killall RetroArch-> exit the application.- If load the core of PicoDrive:
killall RetroArch-> exit the application.- If load the Beetle PSX core:
killall RetroArch-> exit the application.- If load the ReARMed core:
killall RetroArch-> the application freezes.- If load the ReARMed core:
killall -9 RetroArch-> command not work.
The only way to complete the process is to hold down the Home and Power buttons to power off the board in hardware.
I hope this information will help you when configuring compilation.
@dagazik Ok, if the BIOS can have any effect, you could then try to install the “RetroArch PSX BIOS from PSP 6.60” from my repo, it was specifically made by Sony for PSX emulation on the relatively low-powered PSP…
That information about how RA reacts to terminal commands should be shared with the PCSX ReARMed maintainer(s), I will try to file a bug report!
1 Like
@Weedy_Weed_Smoker I checked how the PSP BIOS works. Unfortunately, its work in my case is worse than in version scph7001.bin. Some games again began to freeze at random points. 
On GitHub, the latest version ReARMed r22 from 2015 - the build from your repository also has this number r22 d56340b. Therefore, just compiling the new version will hardly change something: i think I need to try changing the compilation parameters.
I read this document here: https://github.com/libretro/pcsx_rearmed/blob/master/readme.txt
It says something about graphics plugins when setting up compilation, as well as the fact that from version r21 support for 64-bit instructions has been added. I don’t really understand how to compile all this, but here’s an idea: maybe try to make a version with gpu_peops.so or compile old r20 where else the developers focused on 32-bit systems.
@dagazik I just uploaded a newly compiled version which only explicitly specifies which dynarec to use, as the CFLAGS were already set correctly…
You can try to update the core now!
1 Like
@Weedy_Weed_Smoker Ok, I tested your assembly ReARMed r22 b715d67: Hercules still hangs at the third level, and the application is still persistently sitting in memory RAM without the ability to unload it.
With regard to random freezes, a little more testing will be required.
With regards to the inability to complete the process: either this is a problem in the ReARMed core itself, or the core uses some kind of RetroArch component, which in turn does not use the Beetle PSX. Therefore, it seems to me that it would be interesting for the test to make a version with PEOp.S (gpu_peops.so or builtin_spu) instead of Neon, as well as an assembly of the old version.
@Weedy_Weed_Smoker In the archives of the Internet from 2015, one of the forum participants, as a solution for ReARMed compatibility with 64-bit systems, posted a link to the now old version r19 without a dynarec: http://www.mediafire.com/file/ey1dth9fyn6qubk/psx_for_A7.zip/file
I checked it and it works well in terms of stability (but bad in terms of speed) - saves are working without freezing the entire ios and the application are unloaded from RAM!
It is necessary to compile with the dynarec, but at least now it is clear that this is possible and the point is in the core.
@dagazik Ok, I just uploaded a newly compiled version which specifies the GPU plugin as peops instead of neon (but didn’t disable neon accelerations support completely)… Can you try that?
1 Like
@Weedy_Weed_Smoker Something doesn’t want to load the list of core from your repository. Writes: Failed to retrieve core list 
While we are testing, I can download core from the link.