This worked for me, thx!
I’m curious, when building libretro-super, did you need to increase your swap file size? I got well into the build and then at some point (in the full mame build, I think?) the build got unbearably slow, the system became unresponsive, and when I checked it had blown through the 4GB of RAM and the 2GB of default swap. I’ve since rebooted and will try again, but I’m wondering what the environment of successful builds looked like. (One thing I know for sure – it’s not my sd card running out of space, as I’ve got a 400GB card in the thing.)
Also, which CPU settings/gear were you using? (I’m on an A06.) I went with CPUs #4 and #5 at 1Ghz, but wondering if having #1-4 on instead would have been better.
A lot of the libretro cores actually got built, but I’d like to be able to build them all so I have a full set to try. Thanks
For me, I didn’t change the swap size. The build has frozen the machine a couple times, so it’s very likely that it’s running out of memory (2 GB RAM, 1 GB swap).
I’m in gear 5, the top gear on A04, which enables all 4 cores.
I’m also trying for a full set of cores, but I’m planning to babysitting the build through multiple passes. I don’t think I can easily do a full build in one go.
2 Likes
I am seeing some fatal errors, so I don’t think all cores will build out of the box.
For example:
../../wifi.cpp:75:10: fatal error: pcap/pcap.h: No such file or directory
75 | #include <pcap/pcap.h>
| ^~~~~~~~~~~~~
compilation terminated.
gmake[1]: *** [Makefile.libretro:624: ../../wifi.o] Error 1
gmake[1]: *** Waiting for unfinished jobs....
gmake[1]: Leaving directory '/home/cpi/code/libretro-super/libretro-desmume/desmume/src/frontend/libretro'
I just checked the status of mine and it had stopped in the same place. I haven’t (yet) modified the makefile, but so far it seems to have produced 53 libraries:
I haven’t actually tested any of them yet, but I guess I’ll start surgically removing problem targets from the makefile and see if I can get it to the end. I don’t currently have a build of retroarch on this card – I was using a smaller card before, and had built a few individual cores.
Given how long it takes to build this stuff, it might be nice to eventually upload working cores somewhere for others to use. Might be a potential security risk or whatever, but it would certainly save a lot of time and duplicated effort! (Though I guess there would need to be separate versions for A04 and A06 models.)
I’ve gotten everything built that I can out of the box for A04. I’d be happy to upload the .so/.info files for the cores somewhere.
1 Like
The easiest thing might be to make a github project for it. And then link it here and/or the wiki? Mine is still cranking away at the moment but I could do something similar for the A06. I’m not sure if the builds would be different or not, but I’m assuming some of the libraries might be different or the build options may have picked up different things? I didn’t look closely enough to see if the Makefiles were detecting hardware and doing any optimizations, but I’m guessing some might.
I’ve only restarted my build once. And I haven’t modified the Makefile yet. But I did notice that it syncs with git every time to pull the latest versions of the projects, and I guess libretro cores are active enough that it picked up changes on my restart so it decided to rebuild some libraries that had already completed.
Were you just commenting out or replacing your Makefile as you went, to avoid previously built stuff, or did you do something more sophisticated? I’m more interested in just coaxing it through a complete build than in doing it cleanly (since I don’t plan on returning to this process anytime soon, ha!) When it fails again I figured I’d scan through the Makefile and figure out where it got to and then comment out most of the stuff before so it doesn’t have to backtrack. And since it appears to pull everything from git at the start I’m definitely removing that to save time and unnecessary rebuilds. It does make me wonder if any of the really active projects might be broken if we just happened to catch them in the middle of a code update though.
To disable a core from being built, either because it was already complete and installed in /usr/local/lib/libretro/, or because it had failed due to a compile error and not, say, running out of disk space or something else recoverable, I did the following:
- Commented it out in
build-config.sh - Removed the directory under
libretro-super
As far as I can tell, build-config.sh controls what repos are fetched. Any directory it sees, it tries to build.
1 Like
Ok, mine ended up hanging again (memory issue) on libretro-mame. Glad I asked what you did, as your way is much cleaner than I was going to attempt. 
Thanks!
On a positive note, I had already built mame separately (not using libretro-super), and it somehow completed that build. So no great loss here. Kicking it off again to see where it fails next… I also noticed there were 200+ libraries in the list, so I guess I’m only about a quarter of the way through, though I imagine some of those are pretty small and quick to build.
Also, I learned something to avoid… In my first build that hung due to being out of memory, I was connected via ssh and although it was very, slow, I was able to kill the build and resume using the device. For the rebuild I’d foolishly kicked it off in a terminal on the device, so when it eventually hung, the keyboard and mouse were so unresponsive I couldn’t actually kill the process, nor connect via SSH. I ended up having to force powering down, which I regret. Lesson learned – potentially sketchy builds that might hang are better done from ssh!
Does this mostly match up with your results, @poulsbo? The only modification I had to make so far to build-config.sh was to remove libretro-mame. So it looks like 55 cores were successfully built via the libretro-super project on A06, with 21 cores failing (mame not shown in screenshot since it was removed).
Thinking I’ll do one more pass after removing the cores that failed, just to get through the build process (hopefully) successfully. Of course I haven’t tested any of these yet so there’s no telling how many of these cores will actually work and run well, but at least they built.
The only failed core I wish wasn’t on that list is ppsspp. Trying to build it separately will be a future project. Desmume might be an interesting one to try to get working too.
Yes, matches exactly, except for the bsnes_* cores. I did manage to get the bsnes cores to build, all varieties, including mercury. The makefiles have typo errors when they call g++ to do the final link – wrong .so filename. Easy to fix.
However, now that I have them, I don’t use any of them, so it’s wasted effort. They either crash or have awful performance. The various snes9x cores work much better.
1 Like
I decided to start uploading some stuff I’ve built and tested to github. The mame core wouldn’t build as part of the super repo, but it did build from the main libretro repo. It’s huge and had to be split up to be uploaded to github, but it’s here:
It goes in the same place as the rest (/usr/lib/aarch64-linux-gnu/libretro).
The DevTerm really shines for MAME games that required multiple monitors. Darius is gorgeous (even with some dead space at the top and bottom), and the XMen 6 player game fits perfectly! Unfortunately, I didn’t get XMen to run full speed, but I only had CPU4 and CPU5 set to 1GHz. It might run full speed if you crank it up more. I’m not convinced my build is taking full advantage of GL hardware acceleration though. Maybe someone else will have better luck with that.
These screenshots were taken direct from RetroArch. I guess it trims dead space, but Darius was centered with black bars on the top and bottom, while XMen fit the screen perfectly. That black line between the screens is apparently something in the MAME driver for that game.
This probably won’t interest anyone but me, but I was also excited to find that Space Lords runs very nearly at full speed too. It was one of my favorites back in the day and while it’s unplayable on any keyboard regardless of size, it’s great to see the DevTerm has the power to run it. At some point I’ll see how a bluetooth controller works with it. 
1 Like
I am on A0402 here, and I cannot for the life of me get the audio to stop stuttering, what settings are you using to get clean audio?
Oh boy, audio stuttering. This is the main problem I’m having with the A04.
Audio stuttering varies a lot depending on which core I am using. The most demanding core I’ve been trying to get working is snes. There are several snes cores. I had the best luck with the snes9x variants, such as snes9x2010. The bsnes ones are all unusable.
I built the cores using libretro-super as originally suggested here.
Also, I only get smooth performance in windowed mode for snes. I haven’t tried less demanding emulations like gba yet. Those might work better.
I tried enabling GLES for compilation, as suggested here, but I didn’t see any difference.
The next thing I might try is installing RetroArch using snapd.
I also tried fine tuning the audio settings in RetroArch – that didn’t help. My best result was with stock settings and the compiled cores.
I have noticed what you said as well, that the audio and video runs fine when not in full screen, so I do not think it’s an issue with the performance of the A04 so much as it is something that we may have to fiddle with to get it running properly. I also get good performance out of GBA when in windowed mode, and not in fullscreen. I would try snapd again but I don’t want to lose printing functionality!
This might be a fix for snapd. I haven’t tried it myself but it sounds promising. Didn’t notice it until today, but it was posted last month and I guess got missed on the forums, as sometimes happens.
1 Like
I will try this out today on my second microSD card so that in the event that it doesn’t work, I don’t have to ruin my main OS lol.
So I installed snapd on my spare drive and then utilized the fix in the thread you linked, and it worked! But installing RetroArch using snapd did not solve the fullscreen issue in my case as far as I can tell.