Installing lr-stella (upstream) on Raspberry Pi 4B?

[ChaosEffect]

Hello,

I am using a Raspberry Pi 4B with RetroPie 4.7.20 and recently learned of the existence of lr-stella built from the upstream code.

This topic has a mention of the core seemingly working fine on a Raspberry Pi, but the script from that post does not seem to do anything for me. I made that lr-stella sh file and adjusted some permissions, but when I cd to the scriptmodules folder where I put it (with the other libretro cores) and attempt

./lr-stella.sh

nothing happens. I just go to an empty terminal line with no errors. It's as if I didn't input any commands at all.

I do not know much about installing things manually, so I may be missing something obvious. There is also the fact that that post is over 2 years old.

I did notice that the /src/libretro/ folder on the Stella GitHub page does not contain the "stella_libretro.so" that is referenced in the "lr-stella" sh file. EDIT: this particular part seems to be something I misunderstood.

I'd be very grateful if someone could help me get this installed! There are some features in the newer versions of Stella that I wanted to try out in the RetroArch environment.

[mitu]

@chaoseffect said in Installing lr-stella (upstream) on Raspberry Pi 4B?:

made that lr-stella sh file and adjusted some permissions, but when I cd to the scriptmodules folder where I put it (with the other libretro cores) and attempt

As with any emulators, installation can be done from the RetroPie-Setup. The script cannot be run standalone - it's not meant to do that.

[ChaosEffect]

@mitu Ah, thank you for the clarification! lr-stella did indeed appear in the "main" section of the RetroPie packages within the setup script. I should have seen that originally.

I noticed a typo in the "addEmulator" section in the script that that other user posted. The .so it referenced was incorrect. The below script should install the emulator properly. I have it up and running.

#!/usr/bin/env bash
 
# This file is part of The RetroPie Project
#
# The RetroPie Project is the legal property of its developers, whose names are
# too numerous to list here. Please refer to the COPYRIGHT.md file distributed with this source.
#
# See the LICENSE.md file at the top-level directory of this distribution and
# at https://raw.githubusercontent.com/RetroPie/RetroPie-Setup/master/LICENSE.md
#
 
rp_module_id="lr-stella"
rp_module_desc="Atari 2600 emulator - Stella port for libretro"
rp_module_help="ROM Extensions: .a26 .bin .rom .zip .gz\n\nCopy your Atari 2600 roms to $romdir/atari2600"
rp_module_licence="GPL2 https://github.com/stella-emu/stella/blob/master/License.txt"
rp_module_section="main"
 
 
function sources_lr-stella() {
    gitPullOrClone "$md_build" https://github.com/stella-emu/stella.git
}
 
function build_lr-stella() {
    cd src/libretro
    make clean
    make
    md_ret_require="$md_build/src/libretro/stella_libretro.so"
}
 
function install_lr-stella() {
    md_ret_files=(
        'README.md'
        'src/libretro/stella_libretro.so'
        'License.txt'
    )
}
 
function configure_lr-stella() {
    mkRomDir "atari2600"
    ensureSystemretroconfig "atari2600"
 
    addEmulator 1 "$md_id" "atari2600" "$md_inst/stella_libretro.so"
    addSystem "atari2600"
}

[roslof]

@chaoseffect this gives me great joy.

I just tested this with a set of important games (ZIP format now works, probably due to changes with EmulationStation + RetroPie since 2019)...

This was the last major emulator that I was hoping to see. I missed that earlier thread from 2019. Reason this is important to me: There are a number of new technologies added to the upstream Stella project that are lacking in Stella-2014. Most notably CDFJ Banking, Save Key support, better video settings and stereo audio (where supported). Lastly better analog control support. EDIT: Analog with Libretro is still not supported well.

Here is a small list of extremely impressive games that don't work with Stella-2014, and no longer require the stand-alone Stella to run*:

• Draconian
• Galagon (*controller issue with lr, though)
• Mappy (CDFJ and Save Key Support)
• Space Duel (Flashback) (same visual issues as stand-alone)
• Super Cobra Arcade (not the Parker Bros version) (CDFJ and Save Key support)
• Wizard of Wor Arcade (not the CBS version) (CDFJ and Save Key support) (*controller issue with lr-though)
• Yars Return (Flashback)
• Zookeeper (CDFJ and Save Key Support)

These modern games are insanely impressive for the system (most/all required special hardware in the manufactured carts to run on real hardware).

Glad this is here and I confirm it's working and working well. Still, with some lr-stella specific issues (control issues I mentioned above), might want to change rp_module_section="main" to "exp" should this ever get added to RetroPie.

[ChaosEffect]

@roslof Awesome!

My main interest in the newer standalone versions is lightgun support. Lightgun support works well with mice in the standalone version on Pi, but using my Sinden Lightgun in the RetroArch framework is typically easiest. Lightgun support hasn't yet been ported over to the libretro version from the standalone version, but here's hoping that and analog improvements come soon!

[mitu]

Glad this is here and I confirm it's working and working well

Is this still on a Pi4 ? We might include the upstream core by default if it's working well, I'm interested if you've run it on a Pi3 instead.

[roslof]

@mitu I exclusively test on a Pi4.

There is still merit to lr-stella-2014, as it's extremely stable.

Most games run and run fine with lr-stella, but I did see a few problems:

Issues with lr-stella:

1. Some issues with controls failing. Not on any commercial games, mind you, but homebrew popular to the niche market.
2. No analog support
   3. Some games are crashing for me, and I'm not sure why yet. Seems to be some, but not all, of the paddle games. They recently tinkered with the driving controller (emulating special analog paddles with never-ending rotation) so this could be related.
3. Audio issues: Example: Pitfall II music is choppy. Music on Draconian (homebrew) intro is off key and not mixed properly.

I'll play around more, and inform if I learn anything new.

[roslof]

@roslof FWIW, Issue above (games crashing) no longer occurs since a recent update. It was indeed related to driving controller changes, and paddle games such as Breakout, Super Breakout and Kaboom were failing to load.

[ChaosEffect]

I figured this would be a good place to post this:

The Stella dev team accepts contributions to the Libretro port via their GitHub page.

They are seeking help with porting their lightgun feature from the standalone version to lr-stella.

@roslof Perhaps someone who sees this and is able to contribute would be able to help out with the analog controls.

[ChaosEffect]

@roslof Analog support now exists in lr-stella in basic form. It's not finalized yet! I am helping them test but do not know of a good way to map the 2600daptor + paddles in EmulationStation/RetroArch so that they are recognized easily.

2600daptor + one set of paddles is seen by ES/RA as a single entity with two analog axes and two buttons. The issue is how those get separated between two players.

Do you have any suggestions? In its current state, lr-stella allows analog control on a one-player-per-controller basis by using the right analog stick's y-axis. I have one paddle working great, but I am at somewhat of a loss on suggestions for splitting the second paddle to a second player because of the shared device ID.

[roslof]

@chaoseffect said in Installing lr-stella (upstream) on Raspberry Pi 4B?:

@roslof Analog support now exists in lr-stella in basic form. It's not finalized yet! I am helping them test but do not know of a good way to map the 2600daptor + paddles in EmulationStation/RetroArch so that they are recognized easily.

2600daptor + one set of paddles is seen by ES/RA as a single entity with two analog axes and two buttons. The issue is how those get separated between two players.

Do you have any suggestions? In its current state, lr-stella allows analog control on a one-player-per-controller basis by using the right analog stick's y-axis. I have one paddle working great, but I am at somewhat of a loss on suggestions for splitting the second paddle to a second player because of the shared device ID.

Some thoughts, although I'm not a developer, but more of a UX type.

For Retroarch Controls, might be ideal to consider a structure like this:

Controls / Port 1 Device Type
None
Joystick
Paddle
Driving
Lightgun
2600daptor (P1/P2)

Controls / Port 2 Device Type
None
Atari
Paddle
Driving
2600daptor (P3/P4)

Controls / Port 3 Device Type
None
Paddle Controller

Controls / Port 4 Device Type
None
Paddle Controller

This should accommodate any legal configuration, with Paddle Controller emulation being available for all four ports, but 2600daptor in Ports 1 and 2 only, covering two (2) players per port. The "(P1/P2)" and "(P3/P4)" callouts exist so end-users will understand this Device Type covers two (2) analog configurations. Note also Joystick & Driving Controller are also only for Ports 1 and 2. Lightgun only for Port 1.

Paddle emulation and 2600dapter support would feature different options in each device type.

Would this structure work?

[ChaosEffect]

@roslof Thanks! That may work. They'd just have to disable the port 3 and port 4 inputs if the 2600daptor selection were picked for the second port I guess. The suggestion I had was similar: have a core option "Paddle Type" for port 1 and port 2 that switches between unique controllers and 2600daptors. That's essentially how lr-vice handles inputs for Commodore 64.

An issue that is not yet resolved is the presence of one fire button per paddle. A single port would need an additional fire button in order for the 2600daptor to fully work.

You can update from source to test the latest if you'd like. It doesn't seem to affect anything else. Currently, the control types listed in the RetroArch Controls menu don't have any bearing on what happens in game. Stella's auto-detection still overrides that completely.

Speaking of the 2600daptors, have you tried mapping those in EmulationStation? I still need to go back and mark which paddle is which, but one moves the X-axis and the other the Y-axis of an analog stick according to ES. The two buttons are read as buttons 0 and 1. I am having trouble mapping via the EmulationStation GUI because of how the analog movements are read. I'm thinking I'll just have to manually map those in a config file. The lack of ES configuration means that the paddles don't get auto-configured when RetroArch launches. You can still map them in the RA menu while in game, and they'll work (very well), but we still need to figure out how to bridge that gap.