I think it’s mainly retroarch cores that are being built into Kodi and early days at that. So you’d still need Retropie for anything standalone, like:
Amiberry (Amiga),
PPPSSPP (PSP),
Reicast (Dreamcast),
ScummVM (various point-and-click adventures),
Mupen64Plus (N64).
But that’s ok because you can still have it installed along side.
I’m sticking with Retropie to keep everything in one place and because I use all of the above.
And because quite frankly I’ve invested a significant amount of time getting it working on the Vero4K
Surprised it hasn’t had more takeup to be honest. 9 months. Perhaps I should have advertised!
I have both installed too, retroplayer for instant play(5 mins short play) then when I have time/urge to play a few hours or want some N64 action I use RetrOSMC
Isn’t working, must have been some update to the source, if i knew what magic you did i would do it myself. But I don’t know and now it fails at what i see is the same place. Here is the build log: https://paste.osmc.tv/makikepupu
#addresses segfault from "Add support for 64 Disk Drive. #446" in mupen64plus-core master
isPlatform "vero4k" && commit=("master b75fdfb")
local repos=(
"mupen64plus core ${commit[0]}"
'mupen64plus ui-console'
Into this:
#addresses segfault from "Add support for 64 Disk Drive. #446" in mupen64plus-core master
isPlatform "vero4k" && commit=("master b75fdfb" "master 838d4d4")
local repos=(
"mupen64plus core ${commit[0]}"
"mupen64plus ui-console ${commit[1]}"
See how the output for cloning the core features a wind back to circumvent the bug:
Looking at the source the sed script should still work as before.
If you run update on the Retropie menu it will overwrite “mupen64plus.sh” with the stock version and undo these changes, so you’d need to run the sed line again to put it back. Oh, and then restart the Retropie script, otherwise the old version will be cached.
Will try again, this time i will stop the retropiescript and restart it, seems it was cached, doing the same install twice not stopping the script in between.
Edit: I should have known about the cache issue, worked like charm after restarting the setup script.
I’ve had no luck getting this fixed upstream in the past year so if I can’t get a patch accepted there I will have to make these changes more permanent in Retropie instead.
Just means having to keep track of breakages and sending PRs to Retropie every time, which I’d sooner not do.
PPSSPP - black screen at startup (working controls and audio)
Reicast - crash at startup
I’ve bisected the faults of both and am working to get them back up.
As a workaround on PPSSPP you can run fbset -fb /dev/fb0 -g 1920 1080 1920 2160 16 beforehand and fbset -fb /dev/fb0 -g 1920 1080 1920 2160 32 when you’re finished.
I have a full Retropie installation on a Pi 2 that is working nicely, and my main emulators of interest are amiberry, vice and mupen64plus.
They work well but of course the horsepower on the PI 2 is limited - for example in amiberry demos that make heavy use of the copper slow right down unless fast copper is enabled, but that then causes graphical glitches…
I noticed that there seemed to be vero4k support in Retropie now so I thought I’d give it a try for increased emulation performance since the Vero4k is a lot faster than a Pi 2.
Unfortunately I didn’t see this thread first so I ran into a large number of problems, and after a quick read through this thread I’m not sure how many are known expected problems and how many can be solved.
When I first (naively) tried to compile all the core emulators I found mame4all will not compile and in fact breaks the entire compile process due to the following function trying to indirectly import rbp-userland-osmc, which leaves apt in a messed up state:
function depends_mame4all() {
getDepends libasound2-dev libsdl1.2-dev libraspberrypi-dev
}
All the other emulators I checked seem to have special casing for the vero4k except this one ?
So I started again and only tried to compile the emulators I wanted to use - amiberry, vice and mupen64plus.
Amiberry and vice compiled OK however mupen64plus does not either as a standalone app or as a retroarch library, although the errors differ. I don’t understand the errors at all. I see there is a possible patch in this thread which I have not tried yet.
The next problem I had is that I use an xbox 360 wireless controller with the official microsoft usb wireless receiver - this works great on the Pi but is problematic on the Vero4k.
Specifically when I try to set up the button mappings on first launch of emulation station I get as far as the left and right triggers at which point it skips past several of the mappings forcing me to continue with an incomplete mapping as there is no way to go backwards to redo any mapping.
I see discussion above from last year about the two different xbox drivers but I was under the impression that @sam_nazarko had already changed the xbox driver in osmc since then ?
The next problems I ran into is that both amiberry and vice run very slowly - much slower than they do on the Pi 2. I’d guess about 10 fps, so my hunch is that the build process has created executables that are using software rendered open gl es instead of making use of mali acceleration ?
A little bit underwhelming when the whole reason for trying to set it up on the vero4k was to hopefully get a big performance boost over the Pi 2.
Finally I can’t get any sound (via HDMI) from either amiberry or vice despite the sound settings appearing to be correct. I didn’t try any other emulators.
With so many different problems to solve I’m at a bit of a loss about what to do or whether vero4k support is still just very experimental at the moment ?
I’m happy to start again if you have any suggestions on what I’ve done wrong, and I have a known good parallel installation of Retropie on the Pi 2 that I can use to do direct comparisons of performance, configuration etc.
Thanks for for the interest! There’s a lot to cover there and so little time, but let’s make a start.
I think “experimental” is fair when you compare the 1st post to the number of emulators in Retropie.
I’ve had very little uptake since I started this (49 posts in 11 months), so very little feedback to work from. It’s worked solidly for me because I’ve only had my feedback for the emulators I wanted to use!
LOL, yeah.
With respect to Mali acceleration, GLES2 is supported in the Mali driver on the Vero4k and if you try PPSSPP you’ll see it’s doing an admirable job. I originally got SDL2 working with Mali support from some development that had been done on the ODROID C2. All of this would have been impossible without it. This has since become part of the retropie SDL2 builds.
I don’t think anything has worked out-of-the-box for me and has at least required changes to the Retropie scripts, if not occasional upstream patches to the emulators themselves in the case of Mupen64Plus, PPSSPP and Reicast (see recent posts).
MAME4all as you quoted wants libsdl1.2-dev - a frequent issue. SDL1.2 does not have a build for Mali that I can find (would open a lot of doors for some outdated emulators), so anything absolutely tied to it is out. If there’s any demand for MAME4all, or anything else not working, I can look into it, as the Retropie builds may not be taking advantage of an SDL2 option, or there may be a bug I can track down.
For MAME you should find lr-mame-2003 and lr-mame-2003-plus work. Is there a specific need to use mame4all? (I respect there may be, as emulation is a broad church).
Interesting you got VICE working. I didn’t have any luck the last time I gave that a cursory run. Was that standalone or a libreto-core?
Mupen64plus has a fix I’ve PR’d upstream, but they’ve not responded yet. The local patch you mentioned from earlier still works so please give that a go.
Amiberry I’ve not shown much love as I need to spend some time setting up controllers and Kickstarts etc (that’s a point - what kickstarts are you using? I think that can be an issue with compatibility etc). Which games have seen performance problems there? Or was it all hardcore demoscene stuff?
Try copying /opt/retropie/configs/all/emulationstation/es_input.cfg from your RPi2 to the Vero4k as a workaround. I used to use a Chinese USB wireless reciever with 360 controllers and that was not a problem I encountered. There was an issue with a delay, but that is another long story for which I found there was a patch/fix.
That’s a new one! I wonder if this is going to turn into one of those AV receiver issues or something? Or a setting in Kodi that’s affected thing globally?
Try something simple like lr-genesis-plus-gx and “Sonic The Hedgehog” and see what happens. Or get Mupen64plus standalone going with my patch?
Indeed. As I say though I didn’t find this thread until I’d already spent a few hours compiling and trying to get it working myself the hard way…
I’m happy to help with testing to see if the vero4k support can be improved - in theory for the emulators that will work on it should run much faster than a Pi 2/3 - although the mail OpenGL ES performance is not quite as good as the Pi AFAIK (it’s designed more for video decoding than 3d performance) the CPU performance is dramatically better, and it’s CPU performance that is hurting the Pi 2 for emulation not GPU…
I did (again probably naively and lazily) run marcobit’s OSMC installer for retropie (which is intended for Pi) and while it seemed to work it may have installed packages/libraries that are not suitable for the vero4k causing the executables to be linked against the wrong OpenGL libraries for instance…
I think I need to manually undo everything the install script did and try to get a clean start following the advice in this thread and see what results I get before going too much further.
I have no specific need for mame4all - it just happened to be the one emulator which was destroying the entire build process and trying to install rbp-userland-dev-osmc, which was leaving apt in an inconsistent state with unmet dependencies. This was before I was aware that trying to run the basic install was a bad idea. Perhaps a patch that just causes it to refuse to build on vero4k would be worthwhile as installing rbp-userland-dev-osmc on a vero4k causes bad things to happen and needs to be manually removed…
Standalone. I didn’t test it for long. I tested amiberry first - found the frame rate was very poor and there was no sound and that I couldn’t get the sound working, I then tried vice on one image - it ran bit it too had very poor frame rate and no sound. That’s what got me wondering if there was a problem with the executable building against the wrong libraries. Potentially a sound problem could cause very slow graphics frame rate too.
Amiga and C64 emulation are my main focus of Retropie as I have a large rom collection for both and am also an ex C64 and Amiga user from years ago…
Emulating other systems like n64 is more out of curiosity and looking at the games of systems I did not have at the time…
Ok - I think I’ll remove everything, start again using advice in this thread and try the mupen64plus patch to see how that goes.
Last time I played with Retropie about a year ago I don’t think Amiberry existed - I was using uae4arm and while it worked it was very rough around the edges, the UI was difficult to use and the emulation just not up to scratch. Performance was a bit stuttery even in a non demanding game.
I tried uae4arm briefly again this time on the Pi 2 but then switched to Amiberry and I’m pleasantly surprised - it works very well on most things. On a game like Superfrog on my Pi 2 OC’ed to 1000Mhz and 500Mhz sdram and core it is smooth and flawless with the display mode set to 50Hz…
Where it struggles is with games/demos that make heavy uses of copper list effects - like the animated horizontal coloured bars you see in a lot of demos. In some demos like that it slows down to about 5 fps as soon as the copper effects appear. If you enable “fast copper” in the settings (which does not fully emulate the copper) some games/demos with those effects run at full speed, some still do not, and some start showing glitching. In short more CPU horsepower is needed to emulate complex copper effects.
However when I run amiberry on the vero4k I’m getting at most 10fps on anything at all regardless of copper effects, and performance is dramatically worse than the Pi 2 on everything. I’m hoping it’s just a problem with the way it was built.
For kickstarts most games will work with kickstart 1.3 - so that’s all I’m using at the moment. I spent some time creating a custom version of the a500 configuration that has useful button mappings. Amiberry seems to use retroarch config for the basic movement controls but you can then assign additional custom controls inside the app itself.
This is very useful because a lot of amiga demos/games require you to press the mouse button to continue into the main game which is then played with a joystick. So you need to map some buttons to a mouse.
So I have the Amiga joystick mapped to the left thumb stick, A for the fire button and then the left and right shoulder buttons send left and right mouse clicks and I can also move the mouse pointer using the d-pad, although it’s not often required, normally you just need a left click. Other things mapped are select goes back to the emulator config screen (and Y back to the game) and the start button pauses/resumes the game.
Here’s my a500 config with custom joystick config if you want to try it:
Save this over the top of the default rp-a500.uae profile and tell retropie to use that profile by default in the options where you hold a button before the emulator launches.
Then pretty much any older single disk game will launch correctly into the emulator and run just by selecting it from the emulation station list.
For games that require more than one disk you can load the first disc initially the same way then go back into the settings after it starts to boot, enable additional drives, specify those additional discs then choose the option “save config for disk”, and that will create a profile based on the file name of the first (DF0) disk image.
Next time you launch the emulator just select the first disk from emulation station and amiberry will automatically load the configuration profile and add the additional disks - no extra work. You can also customise emulation settings such as memory, chipset etc on a per game basis using save config for disk both for single disc games and multi-disk games meaning that custom configuration per game once set doesn’t require any extra work above just selecting the first disk image for the game in emulation station…
Very nice. For games to test amiberry with I’d suggest Superfrog is a good one.
I’ll give that a try after I reinstall. It does seem like cheating though and I suspect the controller is going to misbehave in actual games as well…
I don’t have an AV receiver - just a Samsung TV. Sound from both emulators works fine on the Pi 2 on the same TV and sound from Kodi also works fine from the Vero4k naturally. I’ll look into this a bit further after reinstalling.
After spending several hours compiling, fiddling with configuration files and studying build scripts I was kinda fed up so had given up by then!
Sorry you’ve had so much wasted effort so far. I needed a better PR campaign for this! It sounds like you’ve been very hands on building things, so glad to have you on board.
I didn’t think the reputation for the RPi GPU was very good (my misunderstanding?), so I’m surprised you weren’t expecting much from the Vero/Mali, it being a competitively clocked GPU and multi-core for those applications that will make use (PPSSPP again). If you want “underwhelming” you should try the Tinkerboard! By rights it should outperform the Vero4k but the GPU drivers seem to be immature and it gets 50% of the Vero4K framerate. I’ve shelved that for the forseeable…
I’ve just successfully built VICE-standalone (I guess something must have changed upstream, nice one) and run Turrican II. I only got as far as the demo screen but even that had HDMI sound, so I think you’ve contaminated something on your box. Definitely don’t run mcobit’s installer. Definitely try a fresh start.
Speaking of contamination I couldn’t get past the Turrican demo screen and I find that my Retroarch hotkey for escaping to Emulationstation etc isn’t working all of a sudden. I’ve been guilty of quick and dirty folder backups to try and keep this box in service for family, whilst trying to use it for kernel, emulator, Hyperion builds. I too could use a fresh reinstall.
Thanks for the Amiberry tutorial. I’ll give that a go. A big hold up control wise was the system expectation for a keyboard, mouse and joystick, just to get through the demo screens before I could even try and test games. I’d done some research into the required setting to do it all through a gamepad but I’ll take your shortcut with much thanks!
There’s plenty to be done still. Retropie should put up a menu in the console when launching emulators so a default can be selected etc. That isn’t happening here. I recall Sam said something about them “unbinding the console” when Kodi starts and I think that is likely to do with it.
You are right about cheating with the copying the controllers setup from the RPi (and after a clean reinstall you may find that isn’t necessary I hope), but as I’ve worked to have so much of this work out of the box for people it’s very disappointing. I want to get something positively working on your box - boost morale for all concerned.
Not your fault - I didn’t check the forum first and didn’t know about this thread I just went straight to the retropie git, noticed that there seemed to be support for the vero4k now and not knowing anything about the state of that support used mcobit’s script to install it and naturally, it didn’t work as expected.
Don’t get me wrong - OpenGL ES performance of the mali chip in the vero4k is still very good, but it’s not quite as good as the Videocore in the Pi in a couple of areas - I think fill rate is one of them, at least if you compare it to an overclocked Pi.
However both have more than enough OpenGL performance for emulators, its the CPU performance where the vero4k dramatically pulls ahead. (Also I think memory and disk performance, and the vero4k+ has even faster internal storage than the vero4k)
Vice is a bit of a pig to set up and use to be honest. On windows I much prefer ccs64, however there doesn’t seem to be a build of that included in Retropie and I did manage to get vice working. Actual emulation performance of vice seems decent on the Pi although sound can stutter slightly unless you don’t use the default “exact” option for audio, and the sid emulation quality isn’t that great as it doesn’t use resid2 like ccs64 so the sound on some games sounds a bit “clipped”.
The trick I’ve found to trying to use it is press B to enter the menus and use the left thumb stick to go up and down the menus, however you have to be careful to not go left or right at all or you’ll drop out of the menus. D-Pad doesn’t seem to work for me for menus. You can’t exit using hotkey start since it’s not a retroarch emulator - so you have to press B to go to the menus then up on the left stick to jump to the bottom and chose quit from there by pressing A. I’m used to doing it now.
Its nearly impossible to play C64 games without a keyboard because most disk images these days have trainers/cracktros on the front that need various key presses to get through (including space, letters, escape, and enter) and even some uncracked games need the space bar pressed or a key pressed to choose one or two players etc.
So I have a tiny bluetooth keyboard that I use with Retropie along with the xbox 360 controller.
Another hassle is that some games expect the joystick in port 1 and some in port 2 - so you’re forever changing joystick ports when changing games as the joystick port settings are global preferences, although I think Alt-J is a shortcut to do this.
This is all normal for those of us used to using C64 emulators though.
Yeah needing to press the mouse button is a real pain - i’d forgotten so many amiga cracktro’s need this done, they never use the joystick. Although I have the bluetooth keyboard I don’t have any mouse attached and don’t really want to as mouse games like lemmings are not really a good lean back experience on a living room TV…
So I was pleased when i discovered a way to map spare controller buttons to functions like mouse button clicks - it makes playing amiga games with only the controller a breeze - unlike C64 games that need the keyboard almost no Amiga games need the keyboard so the controller with the additional mouse button mappings is sufficient to do everything from the controller, and the menus in amiberry are quite navigable with the controller too, at least with the configuration I posted above.
I suspect what Sam is referring to is this line:
When Kodi launches we unbind the console - we do it on Pi as well but on the Vero4k (and vero2) it’s 100% necessary because on v4k unlike the Pi Kodi shares the exact same output framebuffer as the text based virtual console, so if you don’t unbind it, new text appearing on the last displayed virtual console like kernel messages, systemd messages etc write over the top of the Kodi display and stay there for a few seconds until Kodi refreshes the screen fully.
So we unbind it then rebind it on Kodi exit. However this is done automatically when the mediacenter service is stopped so it shouldn’t pose a problem.
I see mcobit’s script performs a few steps to attach emulation stations session to one of the virtual consoles:
That script obviously works on Pi but it doesn’t work on the vero4k - it causes emulation station to crash, my assumption is that because Kodi is being shut down after launching emulation station rather than before. You can get away with that on the Pi because they are not both trying to use the same framebuffer but on the v4k they share the same framebuffer so Kodi must definitely be shut down (and wait for it to finish shutting down) before emulation station is started.
So that script needs a complete rewrite to work on the vero4k, but can be rewritten in a way that would still be compatible with the Pi. As most of the mediacenter watchdog script is mine I’m fairly familiar with what would need to be done, so I could look at that later after the actual emulation is working.
To be honest I’m not super keen on the way that script and it’s companion watchdog script is implemented:
A better way to do it would be to implement it as a systemd service. A problem with the way it is done now is that the Kodi addon launches the script and it is then the job of that script to shut down Kodi but without killing itself, so lots of backgrounding is used…
A cleaner way would be to have a retropie systemd service with a single script - then the addon in Kodi starts the systemd service when the user wants to play retropie, the first thing that newly started service does is stops the mediacenter service and waits for that to finish stopping before proceeding - being a systemd service means it is completely isolated from the Kodi context (Kodi is not its parent) so it is not terminated by Kodi stopping and doesn’t have to play any backgrounding tricks, then at the end when emulation station is exited it can restart Kodi with systemctl start mediacenter and terminate itself by exiting the script.
We do something very similar with the manual-update service:
When the script gets to systemctl stop mediacenter it will wait at that point until mediacenter has completely exited - which means that the mediacenter watchdog has performed all the shutdown actions necessary including rebinding the console. (Stopping the mediacenter service calls the watchdog with the ‘stop’ action which runs fb_restore to restore the virtual consoles) Then emulation station can be set up and started, then when it exits you simply restart the mediacenter service.
Clean and reliable, and you see it working every time you get the blue update screen… That’s how I’d do it anyway.
So you don’t have any trouble configuring the initial emulation station keymap with a 360 controller when you get to the triggers ?
How can I check that the correct xbox drivers are being used ? I’m not very familiar with how 360 controller drivers work on Linux.
I’d been looking at some of those files this morning, but you’ve cut straight to the meat of the problem. Insider knowledge. That’s going to be very helpful!
I’m all for starting afresh with a systemd unit. I was going to go my own way but didn’t want to fork away from RetrOSMC as it was such a great name! That’s why I’ve tried to fix everything in Retropie proper. Also mcobits addon hasn’t worked for sometime. I posted a fix above about that. It would generate a lot more interest if we had a dedicated installer though. More user friendly that way.
C64 sounds tricky then. I found last night that 2 different buttons would open that menu, but I couldn’t seem to get anywhere with it. I was content to have found a system that could prove HDMI should be working on your box.
Could you not use xboxdrv configs there on a per game basis? Back in my RPi2 days I wrote scripts that were launched from Retropie’s runcommand.sh to launch xboxdrv using ROM specific configs as required. Was a lot of hassle but it worked. Ditched it when I got the Vero4k and just bought myself a Giotech VX-2… I’ll have to see if these are still languishing on my server.
I’m not too invested in C64 personally as I was Spectrum 48k and then Amiga 500/1200 growing up. For me it’s all about some nostalgia, and then catching up with all the consoles and titles that everyone else had and I didn’t.
I’ll give my 360 controllers a whirl tonight for you and see what the state of play is there.
Possibly, but as I just used the scripts as provided I wonder why they would work for others and not me ? I presume it inherits the current working directory of Kodi, which should be the same for Pi and Vero4k…
I think combining and rewriting both of these scripts into one script attached to a systemd service that works properly on both Pi and Vero4k is ultimately the way to go, and I’m happy to work with mcobit to do this, or just write it from scratch.
Just rebuilding my installation from scratch and it’s time to apply this patch but where and when ?
Do I try to build first (so that it downloads and extracts the source) and let it fail, then run the sed command in the root of the source dir then build again, or… ?
Where: It uses the full home path so run it anywhere you like, as long as you’re logged in as user osmc.
When: before you run retropie_setup.
All it does is have Retropie checkout the last known good commits before building, rather than bleeding edge, which doesn’t work for us since they added 64 Disk Drive support.
