I apologize for missing this for a while. Unfortunately I’m not sure why you’d be getting that segfault since you seem to have the NOBANNER environment variable set up correctly.
As an aside (that may help with your issue,) newer versions of box86 are improving rapidly when building from source from the box86 github. I recommend trying them out, they’ve fixed a lot of issues for me.
And, the SteamCMD tip is a great idea that I’m looking forward to trying out!
If you installed with the armbian gaming script first, did you just do builds of box86 from the latest source on github and then replace the binaries? I have to admit, I never looked into the details of what that script was doing and just assumed it was a grabbing the latest code and never even considered how to update it later. Is the best thing to start from scratch from a clean OS image and set it up manually, ignoring the script entirely, or were you successful in updating (after manually building) on top of the script install?
I may at least reinstall winetricks and/or try to reinstall the wine component too. Clearly something is wrong with my install since winetricks is broken.
I initially installed from the script above, but have had no issues updating each of its components individually over time. A new box86/64 install just overwrites the previous one. (ptitseb provides compile instructions for the A06’s RK3399, it’s super easy to do.)
I had some issues with wine at first when following the exact procedure of the tutorial, and have had more success with the newest version from the same sourceforge above.
I installed using the armbian-gaming script, but I am not familiar with how to actually run programs that have the ‘.x86_64’ file extension. Is this possible?
I built box86 and box64 and installed them over the previous version, and I replaced my wine components with the ones from the latest (7.0 RC4). Unfortunately, I still got the segfault when I ran winetricks. I even grabbed a new copy of winetricks (in case the other was somehow corrupt), but that didn’t help. I took a closer look at the winetricks script and it mentioned near the top that there were dependencies to install, so I did that manually in case I was missing something, but it didn’t affect the segfault.
sudo apt install aria2 binutils cabextract fuseiso p7zip-full policykit-1 tor unrar unzip wine xdg-utils xz-utils zenity
Not sure I should be installing wine like that, but it and a few other things were missing and got installed.
But I realized I CAN run winetricks if I go to ~/wine and run
./winetricks
I also managed to install the windows components mentioned above by running
BOX86_NOBANNER=1 ./winetricks -q corefonts vcrun2010 dotnet20sp1
Though it did hang several times with a warning, saying it would hang until all wine processes in prefix=/home/cpi/.wine terminated. So to get past that (after waiting a bit), I manually killed the wineserver -w process and the script continued.
Speaking of scripts, I think the segfault problem was caused by the contents of the wineserver script in /usr/local/bin:
#!/bin/bash
env BOX86_NOBANNER=1 box86 $HOME/wine/winetricks “$@”
I’m guessing that was created by the armbian-gaming script, but I think there’s an error there. I don’t think it should have “box86” on that line since it would be trying to run the script through box86, which doesn’t make any sense. If I remove that, it would just function as a wrapper that would include that environment variable, which I think is what we want.
I didn’t really see any differences with the newer box86/64 binaries, with the exception of one game that used to run and now doesn’t. I haven’t done much testing yet though. And I’m curious to see if the winetricks script changed anything for the better. Seems weird to me that I’m having to kill the wineserver every time the script runs it, but that’s moving things along, so hopefully this will work.
Hello.
I followed the instruction from top post.
DevTerm A06.
I successfully (or so it seemed) finished steps 1 to 5.
I fail at step 6:
wine wineboot fails.
Actually any call to wine fails
6.b:~> wine wineboot
Box86 with Dynarec v0.2.5 bd5c8fd4 built on Jan 8 2022 12:58:44
Error: loading needed libs in elf /home/b/wine/bin/wine
6.b:~> ls -l /home/b/wine/bin/wine
-rwxr-xr-x 1 b b 9708 Jan 8 13:33 /home/b/wine/bin/wine
6.b:~>
As seen above /home/b/wine/bin/wine that is complained above does exist but something wrong.
Yes, on my system ~ is /home/b because I changed my username and home folder since beginning.
I don’t know how to continue.
Edited to add:
I also noticed that after doing this the sound output no longer works. I don’t hear anything.
I had to revert to a previous state from the SD card backup image I made before this.
Doare you able to play games with the integrated gamepad? I’ve succesfully run some games and in the logs the devterm controller appears but is not functional in game
Is Diablo possible? I think there is a Linux native binary available?
Only thing I tried so far with box86/box64 installed was Zachtronics superb TS-100, which runs, but is scaled weirdly (I think down to 800x480?) making text unreadable and thus the game is unplayable sadly.
Someone made a Gameshell port of Diablo a few years ago, and I’m guessing it will run fine on Devterm too. Looks like the build process is pretty easy, but I haven’t tried it yet.
Oh I played the ps1 version on the Gameshell, I have to try that project
Forget about PiKISS for the A04 and A06 cores. It refuses to run on anything else other than a Pi. However, you can still take a look at the PiKISS git in the scripts folder, there are a lot of interesting things to install (x86/x64 and otherwise)
PiKISS is a nice collection of scripts accessible through a menu to install various things. It includes the install script for Diablo, I believe.
I am not sure if PiKISS works out of the box on the A04 and A06 cores, but worth a try.
Anyone have this working on DevTerm A04?
Installing box64 works fine, the only change from the script being defining ARM_DYNAREC instead of RK3399, when calling cmake, that is:
sudo apt install cmake
git clone https://github.com/ptitSeb/box64
cd box64
mkdir build
cd build
cmake .. -DARM_DYNAREC=ON -DCMAKE_BUILD_TYPE=RelWithDebInfo
make -j4 # assuming all 4 cores are enabled
sudo make install
However, I’ve been unable to get box86 to build. The compiler complains about the -marm option, the -mfpu=neon option, and the -march=armv7-a+simd option. The last one worries me the most, since isn’t the point to compile armv7 code (for 32-bit)? And the error suggests that the compiler can only deal with arm64 architectures:
cc1: note: valid arguments are: armv8-a armv8.1-a armv8.2-a armv8.3-a armv8.4-a armv8.5-a armv8.6-a native
Anyone have this working on DevTerm A04?
Using the armbian-gaming.sh I was able to install both box86 and box64 without any additional changes on my A04 DevTerm
Hm, I’ll try that. But the script compiles against RK3399, that is, the A06 SOC. With A04 we are running Allwinner H6. (See A04 potential X performance problems + potential solution - #5 by annathyst)
Do box86/box64 work for you?
Do box86/box64 work for you?
They seem to work, but I haven’t been able to test this thoroughly, since my screen keeps dying a few minutes after boot. I guess, I will have to contact @AlexDuan by mail to get a replacement after all.
Zachtronics TIS-100 started, which I think is x86
Zoom conference client x64 started aswell and seems to work well, even with UVC webcam plugged in, except for a few graphical glitches and the screen being to small to actually be useful (might have to experiment with screen scaling for this)
Ok, based on your comment, I also used the armbian-gaming.sh script to build box86 only, and it seems to work! I also tried TIS-100, which is indeed x86. It seems fully functional, although, just as you say, it’s going to be challenging play on the tiny screen. Great tip, thanks.
./steamcmd.sh +@sSteamCmdForcePlatformType windows +force_install_dir /home/cpi/steam/ yourgame / +login username password +app_update steamid validate +quit
So I have an issue that this gets stuck on Logging in user '*****' to Steam Public.... It seems to be stuck in that condition permanently. Have you encountered that before?
Hmm, I don’t remember getting that. It’s been a while since I tried running something this way. Many of the Steam (and other Windows games) I tried to run ended up throwing that GLXBadFBConfig error. And since the display and controls on the DevTerm aren’t exactly gaming-friendly, I haven’t been using it for that lately.
The only thing I might suggest is making sure steamcmd is up to date. Maybe delete, download, and set it up again? I vaguely remember having trouble with an out of date version of it at one point, but I don’t remember it getting stuck like that (I seem to remember it just exiting and failing with an error).
These days I’ve been using my DevTerm as a small private Valheim game server. I was kind of surprised that even worked. I’ve also recently set it up with qFlipper to connect to my Flipper device. While I can update the Flipper firmware that way, I think it’s most interesting as a way to make a serial connection to the Flipper and then send messages wirelessly over the sub 1GHz range, etc.
Also, you may want to make sure you’re not running (or are signed out of) Steam on other machines. Maybe it’s not letting you log in multiple times? Before it would log me out on another machine when I tried to log in again, but maybe something changed.
This is a weird problem that I can’t nail down. I also have installed full Steam app in both Manjaro and standard Ubuntu install, and both of them just hang on the monent when I click “login” button. The issue is that I’ve been trying to solve that for months.
I’m not sure if it’s related to other Steam instances on other machines, I’ve been able to download a linux version of one game using steamcmd on Mac, then transferring it to DevTerm.
The only comment that I can give now is that Half-Life 2 Linux x86 runs pretty slow even with forced DirectX 6.1 and all low-power optimizations. Only A72 are enabled on 1.8 GHz, and Mali is set to 800 MHz. Maybe I can overclock them…