Box86 - Linux Userspace x86 Emulator


Yes, agreed. This thread's not being used for anything else apart from the odd video of people using it successfully. In between those posts you're welcome to use it as long as you remain as polite and well balanced as you've already proved you can be.
 
Update: after all that debugging and tracing ptitSeb noticed that the issue is with the '__builtin___clear_cache' section of the dynarec code, we then tested it again by changing it to '__clear_cache' and that didn't work either. ptitSeb then wondered whether or not other JIT environments such as the JRE and Mono would even work on a 32-bit OS running in a systemd-nspawn container on a 64-bit host. As always a very valid question by ptitSeb because as it turns out -> no they don't. Any JIT running on the aforementioned setup on the current generation of Debian based OS's will segfault. I then tested installing a JRE and Mono on a 64-bit OS running in a systemd-nspawn container. Lo and behold - no issues. The issue then becomes clear: systemd-nspawn is fine with JIT as long as the host and and guest OS's are running in the same mode - in this case 64-bit.

Long story short: Box86 is fantastic and the issue I pointed out had nothing to do with Box86 but with trying to run software with a JIT in systemd-nspawn when the host and guest operating systems have different architectures - at least in the versions of the kernel and systemd-nspawn in the 'Buster' generation of Debian based operating systems.

Personal lessons learned:

1. When a developer happily posts that their project now includes a JIT - then consider testing said software with and without JIT enabled before asking questions.

2. If the software does run without issue when the JIT is disabled - then check if other JIT environments are able to run before asking questions.

3. Always consider upgrading graphics drivers to the latest and greatest available for the OS before making any assumptions about performance and / or compatibility.

(Box86 on a chroot with Mesa 20.2 is so very very fast, smooth and scrumptious).

4. Live debugging does not mean remote debugging.

5. Consider how many instructions per second a modern-(ish) CPU can run before thinking 'Hey - I'll go through them one by one in the debugger! It's a good way to equate what would normally (at most) be a few seconds of runtime - with hours and hours of pressing return on my keyboard! Let's see if my keyboard manufacturer was telling the truth about how many key-presses the keyboard can handle!'.

(In other words: I should think a little harder before painting a mental picture about the road ahead and look up ways to navigate the task at hand properly / speed up the process - in the user manual.)

6. I thought I had a lot to learn still. Turns out I've only made it past the foreword in the 'great book of computery things' - 'a lot to learn still' doesn't quite cover it.

7. I thought ptitSeb was a genius. I was wrong. He is the guru that geniuses run to when they're confused.

Post automatically merged:


----------

@levi - thank you, much appreciated - I shall :)
 
Last edited:
Update 2: So there we are a day later - and poof - issue fixed. Things work out so very differently when one posts an issue backed by the solid knowledge and experience of one who well and truly knows what he's doing.

Thanks to ptitSeb for hitting the nail exactly on the head and not accidentally slightly to the side like I would have - the systemd team presented the solution within 24 hours - and the fix will now go upstream for future versions. A single variable added to some code followed by hours of compiling on the pi and presto - box86 can now be boxed, or containerised, or chroot++ed. This does expand Box86's usage scenario's - direct on the host? - obviously no problem. chroot? - go ahead. container? yup-yup.

A happy ending to this issue :)

Now back to happier posts of getting cool things to run in boxed-box86 and the like :)

Merci beaucoup @ptitSeb - vous êtes un géant parmi les programmeurs!

(Hope that is correct and Google translate isn't setting me up to look silly).

Addendum 1: -- Just in case anyone stumbles onto this with a similar issue: it can be fixed by getting systemd 246.6 (or later) from buster-backports (or upcoming bullseye) and patched according to the links above.

Addendum 2: - Proof :) (and while watching a YouTube video (from the Pyra forum) on the host as well :cool:):

Screenshot_2020-10-05_23-10-02.png

Addendum 3: - In case someone does apply this fix as well - don't forget to 'sudo apt-mark hold systemd systemd-container systemd-sysv systemd-timesyncd' as the fix will not find its way into Debian immediately, so it would be best to stick with the manually fixed version for a while.
 
Last edited:
In the spirit of tinkering, testing and tickling as well as the fact that my installation has mutated to the point of nearly being able to join the X-men (with its modded and recompiled Mesa, systemd and as of this morning its kernel), I decided to give the new experimental Vulkan driver for the Pi a go.

Screenshot_2020-10-06_10-27-25.pngScreenshot_2020-10-06_10-29-13.pngScreenshot_2020-10-06_10-30-10.pngScreenshot_2020-10-06_10-33-47.pngScreenshot_2020-10-06_10-28-32.pngScreenshot_2020-10-06_10-41-20.png

Fan-freakin'-tastic. (Pyra forum in the background to prove that it's really happening on my box)

This would pave the way to theoretical inclusion of DXVK and D9VK support in Box86 someday perhaps. (And with it....support for System Shock 2. --- ( Hmmm... System Shock 2.... )

At the very least it should boost compatibility and / or performance with Retroarch / Libretro, PPSSPP, dhewm3 and others quite nicely.

This will no doubt also open the door to having Vulkan supported on a host of other ARM chips in the future (outside of the Qualcomm, Exynos, ... mobile phone space).

Awesome. Vulkan.

Live long and prosper \\//,

----

P.S. Click here if you'd like to give it a go yourself :)
 
Last edited:
I don't know if this is news or not - if it isn't then apologies and no need to read on. If it is however:

Ladies, gentlemen - pyries and pyrettes as well as pandorean citizens:

Box86 can now run Quake 4 and and Prey (2006).

Original (closed source) Id software SDL ports for Linux. Both are fully functional (with GL4ES) - both windowed and full-screen (but I decided to take windowed screenshots to again provide proof)

Quake 4:

quake4_1.pngquake4_2.pngquake4_3.pngquake4_4.png

Prey:

prey1_1.pngprey1_2.pngprey1_3.png


Id Tech 4 Engine: You've been Box86'ed.

If it can run these then for sure it can also run Doom 3 and Doom 3 RoE - but then I didn't really see the point in testing those as they can be played directly using 'dhewm3'.

--------------------------

Timeline:

Id software (before Bethesda came in): Here you go boys and girls - the Id tech 4 source. Have fun.
Community: Yay! Thanks Id.
Community: Wait... Quake 4 doesn't work... darn it Raven Software did something to the engine and it isn't Foss'ed...
Community: What about Prey? Same deal.. Human Head Studios did some closed source tweaking...
Community: Hey Activision / Raven / Human Head - how about giving us those source mods...? So we can update and port?
Activision/Raven/Human Head: No.
Community: Please?
Activision/Raven/Human Head: No.
Community: Oh......Guess we'll have to wait and see what we can do about it later then....
ptitSeb: I present Box86.
Community: Yeaaaahh woohoo! (and there was much rejoicing).

Box86.
(Where x86 belongs).

----------------------------

EDIT: To avoid any and all confusion - this post has nothing to do with my earlier post about the experimental Vulkan driver for the Raspberry Pi. Quake 4 and Prey were both tested using nothing but regular Mesa 20.2 and the latest revisions of both Box86 and GL4ES. Meaning both Quake 4 and Prey should be able to run on the Pyra as well. That said - they're fully functional as in - they start up and they are playable - but not great to play. It's smooth when walking around in confined spaces with few enemies around, but once the games really get going with increased battle arena sizes while sending multitudes of enemies to fight - game performance and with it game enjoyment will go out the window (the hardware simply doesn't have enough muscle). Try playing Quake 4 or Prey on a low to mid-range laptop from 2006 - that won't go all that well either. (I had a reasonable laptop at the time - with an AMD Athlon 64 and a discreet ATI graphics chip, but playing Doom 3, Quake 4 or Prey on the thing made me want to toss it out the nearest airlock).

This post was mainly intended to showcase yet another of Box86' feats and what previously utterly unthinkable software and games can now either be played or at the very least booted up on our favourite ARM devices. Realistically - if Quake 4 and Prey would ever be truly playable on the current generation of ARM SBC's and pocket devices - they'd have to be fully open sourced and put on a revised version of the game engine that allows for a lot more tweaking than the original version from 2006 (which hasn't been updated in a very very long time). Like Doom 3 - playing the original is actually more demanding than the revised open source version (dhewm3).
 
Last edited:
Thanks!
Yeah, I was aware quake4 and Prey works. I played a few level of Prey on my Pi4, just to be sure it worked :p already. You can run Postal2 and Unreal Tournament 2003/2004 also on the Pi4, and with pretty good speed ! Games like Portal and HalfLife 2 also run, but are too slow to be enjoyable.

Vulkan is not supported yet in box86 (so not wrapped like opengl), but it's on my todo (I plan to work on that in not too long), and that would enable then things like DXVK on Pi and later Panfrost probably, wich would make Wine even more usable under box86.
 
Last edited:
He's using the 'experimental vulkan driver' for his Pi. Assuming it exposes an API the programme can talk to, it shouldn't need any shimming/wrapping as I understand it. Doesn't really help us waiting for a Pyra, but it's still cool that the code can do this.
 
levi said:
He's using the 'experimental vulkan driver' for his Pi. Assuming it exposes an API the programme can talk to, it shouldn't need any shimming/wrapping as I understand it. Doesn't really help us waiting for a Pyra, but it's still cool that the code can do this.
Click to expand...
No vulkan on current pyra indeed, but next maybe?

For vulkan: yes, I know he is using the experiemental vulkan driver, but like OpenGL, if box86 doesn't wrap the libs, you need to provide an x86 version of the lib to use it. When using wine, you have this kind of layer:

MYPROG.exe (x86) ===> Wine (x86) ==> Box86 ==> ARM
For graphics, if using opengl you have:
MYPROG.exe (d3d) ===> Wine(opengl) ===> Box86 (opengl) ==> ARM openGL driver...
with vulkan, if box86 doesn't wrap it, you get:
MYPROG.exe (d3d) ===> Wine(vk) ===> x86 Vk driver ==> Kernel

That's not super clear, but that's basicaly the process
 
@ptitSeb Ah I wasn't sure if you had as I didn't see any mention of Quake 4 and Prey - but of course I should have guessed xD . Awesome though - I was so happy a year ago when I found out that Doom 3 could be played on the Pi via the dhewm3 project - and now even the rest of the Id tech 4 family thanks to Box86. I haven't actually tried any Steam games yet - until now its mostly been Gog games (as they're standalone); except for the Id tech 4 family - as they've had Linux ports available almost from the get-go. Its awesome how Box86 expands the realm of playable games on ARM-Linux. Fan-freakin'-tastic.

I'm so happy to hear you've got Vulkan support on the roadmap - its its... beyond words to describe how awesome that's going to be. Just awesome I guess. With a cherry on top.

@levi - actually I wasn't using the experimental Vulkan driver for the Quake and Prey stuff. I ran the Vulkan tech demo stuff directly on the host OS (64-bit) - using a static build of Mesa 20.3 and the Vulkan driver - and then pointed the Vulkan demos to said driver statically. The experimental driver is not yet capable of running any actual production level software (as its not entirely conform the Vulkan 1.0 spec yet). Not that I didn't try of course, but PPSSPP, RetroArch all told me to pack my bag and go away when trying to run them using Vulkan.

Aside from that, I knew that Quake and Prey were pure OpenGL games (even on Windows) and as I was running them in native Linux x86 mode (using the original Id software SDL ports) with Box86 - there'd be no place for Vulkan either way. But in the future though... Directx(9) games running through D9VK/DXVK with Box86' upcoming Vulkan support and Mesa 20.x (whichever one will feature the finished Vulkan driver) - now that will be a turning point in history we geeks will tell our virtual grandchildren about.

Personally though - I don't consider these developments hardware package specific - more platform specific; ARM Linux (or rather RISC-Linux). Being a non-profit platform that has been embraced by educational institutions (and therefore also garnishing the attention of many a corporation) has helped the Pi get a lot of attention and forefront development - sure - but it will all without a doubt find its way into the platform at large. The great strengths of the Pyra are both its value as an integrated solution (after all the Pi is just a board, it needs quite a bit of copper to become a fully fledged solution (see my profile picture)) as well as being a user-serviceable and upgradable platform. Once the Pyra team has their initial delivery taken care of - they will surely start working on an upgraded CPU board that will at the very least put it on par with the Pi and open the Pyra up to all this experimental, educational and entertainment-related goodness. Who knows - they might even meet in the middle and make a Pyra-edition Pi4 CM(-style) board. That'd definitely be a design and production cost saver.

From my perspective it's all about making it increasingly viable to have RISC-Linux becoming the future of computing - with ARM being the catalyst and the upcoming RISC-V architecture being the future. Box86 is becoming the bridge between the old and the new. Between Super Mario and Doom Guy; Metal Slug and Metal Gear; Pokemon and Prey.

So even though not all of the past 3 pages of this thread necessarily apply to the Pyra directly, - a lot of it does in the short term - and I truly believe that near all of it will in the long term.
Post automatically merged:

@Rockthesmurf - I'll have to use a phone or camcorder to do so as direct screen recording would surely kill the smoothness, but I'll see what I can do.. be warned though.. that probably means pointing either my phone or my camcorder at the screen... I'll do my best and see what I can do :)

EDIT: @Rockthesmurf - I just ordered a USB 3.1 - HDMI capture card which should be arriving soon - that'll help me make some proper recordings without any performance penalties :)
 
Last edited:
So if i want to go full Pyra in a few weeks, but i want to make some Playlist for Apple Music, i could put Box86 on my Pyra, and run Itunes via WINE??
Seems like i have to read this thread a bit more..
 
@matzesu - I doubt that Apple Music will run at the current level of Wine support in Box86, I reckon development will have to continue a while longer before that's possible. It's mainly older games and utilities that are able to run at present. But I could be totally wrong as I haven't tested it myself (don't have anything Apple and never will). I've tried running WeChat for WIndows in Box86-Wine and that's a way more basic app to run compared to Apple Music (and it doesn't work yet either in Box86-Wine at present).

For the moment Box86 is most suitable for running x86 Linux applications on an ARM Linux device.

You could always use the Apple Music Web Player though.
 
No problem, and dont make yourself to many issues because of me.. , its just that im now to deep in the Apple Swamp..
Also i only would need Itunes for these "Intelligent Playlist" (Put the Songs in this List that are from Year 2020), normal Playlist can also made whit the IOS Device itself, or whit the Android App from Apple Music..

So i could even get full Pyra if Itunes dosnt work ^^
 
matzesu said:
No problem, and dont make yourself to many issues because of me.. , its just that im now to deep in the Apple Swamp..
Also i only would need Itunes for these "Intelligent Playlist" (Put the Songs in this List that are from Year 2020), normal Playlist can also made whit the IOS Device itself, or whit the Android App from Apple Music..

So i could even get full Pyra if Itunes dosnt work ^^
Click to expand...
Rhythmbox does intelligent playlists too, and I'm pretty sure it's in the Debian ARM repos already.
 
The Problem is that im too deep in the Apple Swamp, so the most of the Music is from the Apple Music Streaming Service, and this means Rythmbox has to write on my Mediathek.. , i know that per exemple Win Amp can copy Music to Ipods, but i dont know if this is also possible on the Streaming..

But no Problem, i still have my Lenovo Notebook as Backup for these things..
 
You could also try to run Anbox on your Pyra (should work as Anbox is fully supported on ARMHF) - and then run the official Apple Music android app from there. (in case the Apple Music app doesn't work (yet) on Box86-Wine).

Anbox functions as a container (not unlike how I run 32-bit Linux and Box86 in a container) on your Linux installation - and offers a full Android OS to work with. It runs on the same kernel as your device so there's no emulation involved. It can help you bridge the gaps (together with Box86) if you want to go full-Pyra. It should run pretty fast on the Pyra too as there's plenty of ram on the one you ordered.

@matzesu
 
Last edited:
Thanks for the Answers, but the Android App is also just a Music Player, i allready run this on my Android Tablett, and its plays the Stream, but the Software i want is more like a Music Manager Programm,
Whit Full Pyra, i meant my whole Computers, i still want to use the Smartphone even if the Pyra can make Phone Calls..
Im not sure yet if i want to use the Pyra 4G Modem, or just Connect to my Phone..

Ok, but now whe should keep this Thread One Topic, ptitSeb `s Box86 Thread deserves this ^^
 
You must log in or register to reply here.

Similar threads

P
Box86 Error (loading libs) on rasp 4
Replies
13
Views
4K
pgroessw
P
Z
problems with box86 using direct path on raspberry pi
Replies
9
Views
6K
FBnil
FBnil
ptitSeb
Release Airline Tycoon Deluxe
Replies
13
Views
6K
Farox
Farox
ptitSeb
Release Eric's Ultimate Solitaire Demo
Replies
1
Views
3K
FBnil
FBnil
ptitSeb
Using Box86 on the Pyra
Replies
16
Views
3K
matzesu
matzesu
Back
Top