Gotcha.
I thought at first you were patching the downloaded source code in situ but I see now that you’re patching the build script that downloads the source… 
I’m building everything remotely from work so I won’t actually be able to try the emulators until I’m home…
Edit: successful compile of Muppen64plus this time.
Delighted to hear it.
To paraphrase myself: I usually use the mupen64plus-video-n64.so (gles2n64) for the likes of MarioKart. I prefer full screen stretch.
In gles2n64.conf make the following changes:
#Window Settings:
window width=1920
window height=1080
#VI Settings:
video stretch=1
NOTE: I don’t think the file is actually created until you launch with that plugin for the first time.
When I run muppen64plus on the Pi, one of the 6 or so options for emulator choice (I can’t remember which one off hand) you get if you hold a button before the emulator loads automatically runs in full screen at high resolution, although I don’t like to stretch the aspect ratio.
I run all my C64 and Amiga games in their original 4:3 aspect ratio too…
You, sir, are hardcore.
I just can’t bear the wasted screen real-estate up on the wall. Except for Tetris. Looks weird with rectangular blocks that stay landscape even when they rotate…
Of course the menu you speak of is the console based runcommand.sh one that we can’t see on the Vero4k… 
I also watch old 4:3 TV programs in 4:3 … 
Ah but we will be able to soon. That’s easy to fix - all we have to do is redirect stdin/stdout/stderr for the script running emulation station to a tty so that any command line programs emulation station spawns will be connected to the tty instead of the ssh session.
We have the same situation to deal with in the manual-update script - it runs as a background headless service but we want to display its output on a tty. In that case we just redirect it to /dev/tty1 for each command that needs to display output like this:
You can redirect stdin if you need to take input for example from the controller which probably appears as keyboard input to those dialog scripts.
You can also redirect stdin/out for the entire script at the beginning of the script which is what I’ll probably do, then everything that runs in it will automatically use the on screen tty.
I’ll write a simple script to do that which also stops Kodi and starts it up again afterwards which can be used as the basis of the systemd service later which could be triggered by the Kodi addon.
Just wanted to say I’m thrilled this is back alive again! 
@DBMandrake: you might benefit from boosting the freq of the Mali via sysfs.
You can also increase the number of pp.
Sam
LOL. It never went away. I’ve been gaming on it weekly since August last year! But never mind…
“Welcome back”! 
Guess I missed alot, but the loads of love the past few posts is nice to see 
Oh yeah, just realized my Reicast fixes have been accepted upstream, so that’s back again too.
As promised I’ve tested the XBox360 pad with Emulationstation.
I’ve tried:
The pre-installed “it just works” kernel xpad driver ;
Installed xboxdrv via apt, running with sudo xboxdrv -d.
-d,--detach-kernel-driver
Detaches the kernel driver that is currently associated with the given device. This is useful when you have the xpad module loaded and want to use xboxdrv without unloading it.
Both methods are recognised by the input configuration tool in ES and both exhibit the problem you described. It seems like the one way axis nature of the analog triggers causes an issue as you release them? Not too many gamepads are blessed with genuine analog triggers it seems.
No matter. Just keep configuring what you can. When you get to the bottom of the list you will have the basic navigation (?D-pad) and select (?A) buttons configured. So now you can just scroll back up to the triggers and assign them. Scroll back down when you’re finished and hit OK. Job done.
Fast tap on the trigger buttons often goes by without triggering next button config, but if you slow push the trigger buttons it trigger two mapping one for - and one for + axis.
I spent some time on this last night and managed to solve many problems but found a couple of others along the way… 
I’ve fixed the sound issue - that was entirely my fault.
A long time ago I installed the alsa loopback driver as I was trying to get AlmusVCU and Brutefir to do multi-channel down mixing with 3d surround to stereo, the idea was to send Kodi multi-channel PCM output to the loopback device, process it and then output via the normal alsa HDMI sound device - I never did get that to work but forgot it was installed. So emulation station and emulators were trying to send to the alsa loopback device, (which was configured as the default alsa sound device) and since nothing was connected on the other side of it it failed. Whoops! Sorry for adding confusion to this thread…
For the performance issue, one of my suspicions turned out to be true - the issue with sound output was causing Amiberry video to stutter badly, as it wouldn’t have been able to sync video with the audio.
Once I fixed the sound problem performance of Amiberry is normal! Performance is at least as good as on the Pi in all tests I tried, in some cases dramatically better.
Amiga games that play smoothly on the Pi 2 also play smoothly on the Vero4k and there are no sound glitches. Demos with heavy copper effects that were slowing down to a crawl - probably 5-10fps on the Pi 2 (from a normal 50fps) are still slowing down but to more like 25-30 fps, so based on a rough estimate of fps by eye the CPU performance of the Vero4k during emulation is about 2x to 4x faster than the Pi 2 clocked at 1000Mhz, which seems about right. So there is definitely a significant performance edge for any emulator/game that might perform marginally on a Pi 2.
I managed to get the controller working properly - sort of. It turns out that both the Pi 2 (official Retropie image) and OSMC are using the xpad driver with default kernel module options, and neither uses xboxdrv by default. In fact in the Retropie docs it specifically says since Retropie 4.1 “With the recent kernel issues of xboxdrv rendering images unusable, there is an updated xpad driver which will work just as well for Xbox controllers, it’s possible it may also support Xbox One controllers.”
Why does it work properly on the Pi 2 then and not the Vero 4k ? The reason is obvious in hindsight. The Pi 2 Retropie image is running a fairly recent 4.x kernel while the Vero4k is still back on 3.14. Presumably the xpad driver in 3.14 has issues that were not fixed until later.
I tried installing the xpad driver from source in Retropie config but it didn’t seem to make any difference, (I’m not sure that it actually built anything from source to be honest - possibly not compatible with such an old 3.14 kernel)
I then tried building xboxdrv from source in Retropie config which it then installs in rc.local and that works! It installs the following line:
"/opt/retropie/supplementary/xboxdrv/bin/xboxdrv" --daemon --detach --dbus disabled --detach-kernel-driver --id 0 --led 2 --deadzone 4000 --silent --trigger-as-button --next-controller --id 1 --led 3 --deadzone 4000 --silent --trigger-as-button
I then configured the controller in emulation station without any problems - no jumping when pressing triggers etc. I also use the swap A and B options for emulation station in Retropie settings. Interestingly I can navigate emulation station using both the d-pad AND the left stick with xboxdrv, whereas xpad on the Pi 2 I have to use the d-pad to navigate emulation station.
I then went to copy my Amiberry config profiles across from my Pi 2 install and of course they didn’t work because the name of the joystick device is now different. 
Instead of something like “Xbox 360 wireless receiver” it’s now “Xbox Gamepad (userspace driver)”.
So I reconfigured the joystick settings in the profile and saved it and ran a couple of games and it seems to work perfectly in amiberry…
EXCEPT… every time I quit Amiberry and reload the same profile the Joystick changes back to “None” in the configuration in the emulator and I have to reconfigure the joystick settings every time I load the emulator. 
And I can’t figure out why. I spent over an hour trying to figure out this one problem and even went as far as renaming the device to a simpler name without parentheses in case it was choking on those but no improvement.
The joystick settings are retained correctly in the Pi 2 installation using xpad but there just seems to be something about the xboxdrv joystick device that the emulator sees that it doesn’t like when it loads the configuration profile which causes it to drop back to joystick none. It might be a bug in Amiberry but not sure how to prove that or what to do about it. In short, I’m stumped.
As the Amiga emulator is the main one I use and my joystick configuration is quite complex this is a deal breaker so I really need to figure out why it won’t keep the joystick settings that are in the profile. When I look in the profile the settings are there as they should be but seem to be ignored:
config_description=UAE default configuration
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_friendlyname=Xbox Gamepad (userspace driver)
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_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=true
;
; *** Common / Paths
;
use_gui=yes
kickstart_rom_file=$(FILE_PATH)/Kick13.rom
kickstart_ext_rom_file=
flash_file=
cart_file=
;
; *** Floppy Drives
;
floppy0=
floppy1=
floppy2=
floppy3=
nr_floppies=2
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=60
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
Anyone else seen a problem like this with Amiberry ?
Vice seems to work fine. I didn’t get a chance to try muppen64plus apart from briefly loading Mario 64 (which appeared very small in the bottom left corner instead of fullscreen like the Pi 2) as I wanted to look at the runcommand issue next.
I tried what I suggested with the stdin/stdout redirection and it didn’t solve the issue, I also tried the openvt command method used in mcobit’s scripts and that also did not work, so this needs more investigation. I’ll have a look at how emulation station is launched in official retropie images - I suspect it’s a systemd service with special options to attach it to the console.
So a couple of setbacks but a lot of progress overall.
This is more like the experience I wanted for new users! And I’m sure none of this is insurmountable.
I noticed you’ve opened a github issue re: mame4all. It looks like they are pulling a dedicated RPi fork mame4all-pi. That is tied not only to dispmanx but to SDL1.2 as well. It’s definitely off the table! Do you want me to respond on github for completeness? And see how you get on with lr-mame-2003-plus. We can always try going back upstream if there proves to be a need.
Yes please - unfortunately I opened that Git issue before I found this thread so I wasn’t aware that not all emulators were expected to compile, so the git issue is kind of redundant now, especially when it’s not possible for that emulator to build.
Although if there is an easy way to modify the build script to detect vero4k and skip building the emulator so that doing a “basic install” doesn’t end up installing Pi packages and breaking apt it might be worth doing.
I can’t be the only person who blindly did a basic install and ended up with Pi packages installed on my Vero4k that I had to manually remove.
You are certainly not the only user to have performed a BIOD (bulk install of death) and I did mention this in the 1st post, but in real life that never works!
Every module has flags to control their viability, and ours is vero4k (I came up with that ). So including rp_module_flags="!vero4k" in every scriptmodule that is incompatible would remove the unwanted builds problem. That is the longer term goal.
The problem with that is it makes for a very limited selection at this time as we all have our platform priorities and I’ve only tested those listed. Users wont know what’s on offer to at least be attempted, so they can feedback issues here (like that actually happened 
) as they won’t appear in the menus at all…
It would be nice if we could work through them all in time. I didn’t want to be plaguing Joolswills with changes to these flags either, but perhaps for the greater good then? With more hands on deck I think this could happen.
I wasn’t suggesting to blacklist all emulators that aren’t verified working yet. Only obvious ones like mame4all where it absolutely 100% cannot build due to a requirement like sdl1.2 or where it will attempt to install raspberry pi specific packages like rbp-userland-dev-osmc onto a vero4k, which takes some manual fixing to undo.
Perhaps only mame4all needs this doing - I seem to remember that when I grepped the build scripts that was the only one that was attempting to install the raspberry pi dev package ? It’s mainly preventing it installing that incorrect dev package that I’m concerned about not the failure to build.
A fair compromise I think. Avoid system breakage without hindering experimentation. I shall get on that.
I decided to have another look at the custom patched xpad driver which Retropie-Setup can install from source so I checked the log files to see why it didn’t seem to be working and sure enough, it’s failing to compile from source:
Log started at: Tue Jun 18 22:45:44 BST 2019
RetroPie-Setup version: 4.4.14 (a86bd9e)
System: Linux vero3 3.14.29-143-osmc #1 SMP osmc-ccachefix aarch64 GNU/Linux
= = = = = = = = = = = = = = = = = = = = =
Installing dependencies for 'xpad' : Updated Xpad Linux Kernel driver
= = = = = = = = = = = = = = = = = = = = =
/home/osmc/RetroPie-Setup/tmp/build/xpad /home/osmc/RetroPie-Setup
= = = = = = = = = = = = = = = = = = = = =
Getting sources for 'xpad' : Updated Xpad Linux Kernel driver
= = = = = = = = = = = = = = = = = = = = =
git clone --recursive --depth 1 "https://github.com/paroj/xpad.git" "/opt/retropie/supplementary/xpad"
Cloning into '/opt/retropie/supplementary/xpad'...
HEAD is now in branch 'master' at commit 'a66c53c008572db516a60a8d38ef4f823b3d3980'
patching file xpad.c
Hunk #2 succeeded at 1785 (offset 1 line).
Successfully applied patch: /home/osmc/RetroPie-Setup/scriptmodules/supplementary/xpad/01_enable_leds_and_trigmapping.diff
/home/osmc/RetroPie-Setup
= = = = = = = = = = = = = = = = = = = = =
Building 'xpad' : Updated Xpad Linux Kernel driver
= = = = = = = = = = = = = = = = = = = = =
Creating symlink /var/lib/dkms/xpad/0.4/source ->
/usr/src/xpad-0.4
DKMS: add completed.
Error! Your kernel headers for kernel 3.14.29-143-osmc cannot be found.
Please install the linux-headers-3.14.29-143-osmc package,
or use the --kernelsourcedir option to tell DKMS where it's located
/opt/retropie/supplementary/xpad /home/osmc/RetroPie-Setup
= = = = = = = = = = = = = = = = = = = = =
Configuring 'xpad' : Updated Xpad Linux Kernel driver
= = = = = = = = = = = = = = = = = = = = =
/home/osmc/RetroPie-Setup
Log ended at: Tue Jun 18 22:45:48 BST 2019
Total running time: 0 hours, 0 mins, 4 secs
I have what I believe is the correct kernel headers package installed - on osmc the package names are different to regular debian as we package our own kernels:
ii vero364-headers-3.14.29-143-osmc:arm64 143 arm64 Header files related to Linux kernel, specifically,
As a result of this failing to compile it adds the kernel module option to map the triggers as buttons, on the existing in-kernel module, but does not apply the patched build of xpad, hence why it probably isn’t working properly…
I’m hopefully if I can get this to compile that it will let me use xpad instead of xboxdrv and avoid the problem with amiberry rejecting the joystick configuration on load.
Ok I have runcommand support working properly using a systemd service. 
This could still do with a bit of refinement but I’ll pass it on as is for people to try in the meantime. Two files:
-rw-r--r-- 1 root root 297 Jun 19 00:37 /etc/systemd/system/emulationstation.service
[Unit]
Description=Emulation Station
After=systemd-vconsole-setup.service
[Service]
Type=simple
WorkingDirectory=/home/osmc/RetroPie/scripts
ExecStart=/home/osmc/RetroPie/scripts/launch.sh
StandardInput=tty-force
StandardOutput=tty-force
TTYPath=/dev/tty1
[Install]
WantedBy = multi-user.target
and
-rwxr-xr-x 1 root root 268 Jun 19 00:42 /home/osmc/RetroPie/scripts/launch.sh
#!/bin/bash
function cleanup()
{
clear
systemctl start mediacenter
}
systemctl stop mediacenter
chvt 1
trap cleanup EXIT
sudo -u osmc /usr/bin/emulationstation
cleanup
After installing the systemd service file make sure you run sudo systemctl daemon-reload before first use.
On my system I actually have it configured to stop and restart a whole list of services - mediacenter sickrage couchpotato apache2 deluge-web deluged you can just list them all space separated on the two start and stop lines.
In use sudo systemctl start emulationstation will stop Kodi then start emulation station. Exiting from emulation station via the menu or running sudo systemctl stop emulationstation will stop emulation station then restart Kodi.
Now that the runcommand function is working I’ve noticed that there isn’t an option to specify a custom screen resolution and refresh rate like there is on the Pi ? Since many emulators need to run in 50Hz and most OSMC systems will boot in 60Hz this is a bit of a limitation - hopefully it’s not too difficult to add support for this.
I presume that on the Pi tvservice is used to set the mode ? If so, there is a different method used on the Vero4k but I can demonstrate how that’s done.
Edit: As a quick hack for lack of mode setting support, to change display mode to 1080p50Hz before starting emulation station just add the following line after the systemctl stop line:
echo 1080p50hz >/sys/class/display/mode
Of course setting mode here will apply globally to all emulators.
Edit 2: If you want to integrate the initial version of this systemd service with mcobit’s existing Retrosmc Kodi addon simply create and make executable the following script which the launcher addon is trying to run:
-rwxr-xr-x 1 root root 50 Jun 19 01:20 /home/osmc/RetroPie/scripts/retropie.sh
#!/bin/bash
sudo systemctl start emulationstation
Now running the Retrosmc addon will launch the new service and start emulation station. Easy!
(Of course this relies on the passwordless use of sudo in osmc which will eventually go away, so we will switch to another method then)