lr-vecx, lr-stella and dosbox-sdl2 is compiling and working.
lr-desmume-2015 compile and works, some games more then other lags alot.
lr-freeitv and lr-blueMSX (colecovison) is compiling and sort of works, not getting controller to work. Probably need to get the Retro-arch documentation and read up on them I guess.
ES changes have been cherry-picked to the regular stable branch, so it’s now acceptable and safer to install emulationstation from the “Manage Core packages” page.
Guys hope someone can help me here…im interested in running some arcade roms I already have, I just wanted to know if installing emulation station is necessary to do this on my vero4k+, I’m slightly confused as I thought kodi18 had all this built in?
Any help is appreciated, cheers.
If your game is supported by one of the currently working emulators (see link below) then yes you don’t need retropie and everything is in Kodi 18.
Thanks for clarifying.
im honestly not sure what emulator was used by the roms, I last played them ages ago on a Pi via emulation station.
One quick question:
In the Kodi repository, in game addons, game providers, the only add-on there is ‘Advanced MAME Launcher’, so I’ve installed that.
In the settings for that add-on, there’s a ‘Mandatory executable path’ which is empty…that doesn’t seem right? Do I need an executable from somewhere?
well you don’t need that since it uses an external executable, to get this to work you have to go:
Setting->Add-on Browser->My Add-ons->Game add-ons->Emulators and enable the emulator you want.
After that you add a source, by navigating to you roms folder. From there you can click the rom and it should open in the emulator of you choice. If you are going for Mame-rom read the instructions in First post about File association and libarchive.
Uninstall the Advanced MAME launcher, since it’s not needed.
Ah ok thanks…
Only problem is in Setting->Add-on Browser->My Add-ons->Game add-ons
I have no Emulator section, just Controller profiles, Game providers, and Standalone games…
Im running the latest stable OSMC btw, is that the problem?
Are you sure you are looking in “My Add-ons” not kodi repository?
Ahaa! I knew id be doing something stupid, thanks!
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
The sed script basically just turns this:
#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:
git clone --recursive “GitHub - mupen64plus/mupen64plus-core: Core module of the Mupen64Plus project” “/home/osmc/RetroPie-Setup/tmp/build/mupen64plus/mupen64plus-core”
Cloning into ‘/home/osmc/RetroPie-Setup/tmp/build/mupen64plus/mupen64plus-core’…
Winding back https://github.com/mupen64plus/mupen64plus-core->master to commit: #b75fdfb
Switched to a new branch ‘b75fdfb’
HEAD is now in branch 'b75fdfb’ at commit ‘b75fdfbbe4c006e68ae9bf9ddaaef907d2dc8d08’
The same should be happening for ui-console:
git clone --recursive --depth 1 “GitHub - mupen64plus/mupen64plus-ui-console: Console (command-line) front-end user interface for Mupen64Plus v2.0 project” “/home/osmc/RetroPie-Setup/tmp/build/mupen64plus/mupen64plus-ui-console”
Cloning into ‘/home/osmc/RetroPie-Setup/tmp/build/mupen64plus/mupen64plus-ui-console’…
HEAD is now in branch ‘master’ at commit ‘b8fa2dea54b98a8a4f8a6ce7bb67ad93a306d843’
But it is not.
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.
Any chance you’ve done this?
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.
Excellent. Glad you’re up and running again.
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.
FYI - 2 emulators are presently down.
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.
PPSSPP is back on the Vero4K!
Fixes are applied upstream, so it’s safe to install/update from the latest source.
I have fixes in place for Reicast and Mupen64Plus, just awaiting acceptance from their respective developers.
Wish I’d discovered this thread earlier! 
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?
Happy to help here if I can.
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:
config_description=RetroPie A500, 68000, OCS, 512KB Chip + 512KB Slow Fast
config_hardware=true
config_host=true
config_version=4.1.0
amiberry.rom_path=/opt/retropie/emulators/amiberry/kickstarts/
amiberry.floppy_path=/opt/retropie/emulators/amiberry/disks/
amiberry.hardfile_path=/opt/retropie/emulators/amiberry/
amiberry.cd_path=/opt/retropie/emulators/amiberry/cd32/
;
; *** Controller/Input Configuration
;
joyport0=mouse
joyport0_autofire=none
joyport0_mode=mousenowheel
joyport0_friendlyname=Mouse
joyport0_name=MOUSE0
;
joyport1=joy1
joyport1_autofire=none
joyport1_mode=djoy
joyport1_mousemap=right
joyport1_friendlyname=Xbox 360 Wireless Receiver
joyport1_name=JOY1
joyport1_amiberry_custom_none_dpad_up=Mouse1 Up
joyport1_amiberry_custom_none_dpad_down=Mouse1 Down
joyport1_amiberry_custom_none_dpad_left=Mouse1 Left
joyport1_amiberry_custom_none_dpad_right=Mouse1 Right
joyport1_amiberry_custom_none_select=Enter GUI
joyport1_amiberry_custom_none_left_shoulder=Joy1 Fire/Mouse1 Left Button
joyport1_amiberry_custom_none_start=Pause emulation
joyport1_amiberry_custom_none_right_shoulder=Joy1 2nd Button/Mouse1 Right Button
joyport1_amiberry_custom_hotkey_left_shoulder=Quit emulator
joyport1_amiberry_custom_hotkey_right_shoulder=Hard reset emulation
;
;
;
absolute_mouse=mousehack
input.joymouse_speed_analog=2
input.joymouse_speed_digital=10
input.joymouse_deadzone=33
input.joystick_deadzone=33
input.analog_joystick_multiplier=15
input.analog_joystick_offset=-1
input.mouse_speed=100
input.autofire_speed=0
kbd_lang=us
;
; *** Host-Specific
;
amiberry.vertical_offset=-5
amiberry.hide_idle_led=0
amiberry.gfx_correct_aspect=1
amiberry.kbd_led_num=-1
amiberry.kbd_led_scr=-1
amiberry.scaling_method=-1
amiberry.use_analogue_remap=false
amiberry.use_retroarch_quit=true
amiberry.use_retroarch_menu=true
amiberry.use_retroarch_reset=false
;
; *** Common / Paths
;
use_gui=no
kickstart_rom_file=$(FILE_PATH)/Kick13.rom
kickstart_ext_rom_file=
flash_file=
cart_file=
;
; *** Floppy Drives
;
floppy0=
floppy1=
floppy1type=-1
floppy2=
floppy3=
nr_floppies=1
floppy_speed=100
;
; *** Hard Drives
;
;
; *** CD / CD32
;
cd_speed=100
;
; *** Display / Screen Setup
;
gfx_framerate=0
gfx_width=704
gfx_height=262
gfx_refreshrate=50
gfx_refreshrate_rtg=50
gfx_lores=false
gfx_resolution=hires
gfx_lores_mode=normal
gfx_linemode=none
gfx_fullscreen_amiga=false
gfx_fullscreen_picasso=false
ntsc=false
;
; *** CPU options
;
cpu_speed=real
cpu_type=68000
cpu_model=68000
cpu_compatible=true
cpu_24bit_addressing=true
fpu_no_unimplemented=true
fpu_strict=false
compfpu=false
cachesize=0
;
; *** Memory
;
chipmem_size=1
z3mapping=real
fastmem_size=0
a3000mem_size=0
mbresmem_size=0
z3mem_size=0
z3mem_start=0x40000000
bogomem_size=2
gfxcard_hardware_vblank=false
gfxcard_hardware_sprite=false
gfxcard_multithread=false
rtg_modes=0x112
;
; *** Chipset
;
chipset=ecs_agnus
chipset_refreshrate=50.000000
collision_level=playfields
chipset_compatible=A500
rtc=MSM6242B
cia_todbug=true
immediate_blits=false
waiting_blits=automatic
fast_copper=false
;
; *** Sound Options
;
sound_output=exact
sound_channels=stereo
sound_stereo_separation=7
sound_stereo_mixing_delay=0
sound_frequency=44100
sound_interpol=none
sound_filter=off
sound_filter_type=standard
sound_volume_cd=0
;
; *** Misc. Options
;
bsdsocket_emu=false
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!
Will do.