Box86 0.2.6 / Box64 0.1.8 Released With Working Steam & Steam Play On Non-x86 CPUs

[Ladis]

AFAIK no. M1 doesn't support 32 bit ARM instructions. It's simply not implemented and SoC is only capable of running 64 bit ARM code. Even with 32 bit libraries it won't be able to execute 32 bit code. Apple completely dropped 32 bit support in their operating systems so it wouldn't make any sense for them to support it in their SoC.

Even last Cortexes (standard ARM SoCs) don't have 32bit support. Even in the small/efficient cores. Google requires 64bit support in all apps submitted to the store for years, so the switch will be invisible for majority of users.

[Ladis]

Btw another thing, I don't like that game streaming is somehow included into this steam blob especially on the client side, so first I would suggest that valve opensources a streaming client, I don't see a real reason / advantage to have a streaming client proprietary only, because you have to buy the games in the game "server" pc.

You don't need the full Steam client for the remote playing. You can use Steam Link app, which is available for Windows, macOS, Linux, iPhone, iPad, Apple TV, Android TVs/tablets/phones, Samsung Smart TV, and Raspberry Pi 3/3+/4. My opinion is, the streaming itself could be opensourced, but not the services offered to the game developers. SOme require running on the client machine.

[GreatLord]

I tried using box when I was on an m1 mac inside of parallels but apparently box86 only works if your cpu supports 32 bit arm instructions.

some arm 64 dose not support 32bits instructs, arm have remove 32bits instuction complete, i do not rember wich version it was in my head. so i guess basic all new design arm cpu does not longer support 32bits mode and instruction

[rene]

packaged - https://www.youtube.com/watch?v=M5MqDuLVWZw

[Developer12]

AFAIK no. M1 doesn't support 32 bit ARM instructions. It's simply not implemented and SoC is only capable of running 64 bit ARM code. Even with 32 bit libraries it won't be able to execute 32 bit code. Apple completely dropped 32 bit support in their operating systems so it wouldn't make any sense for them to support it in their SoC.

Dropping it in their OS is one thing, dropping it in the ARM core is quite another. Windows doesn't let me run 16-bit DOS games anymore, but lots of modern hardware still boots DOS just fine.

[Developer12]

Not all games / tools are there:
1. Here a Outer Wilds mod for VR:
https://awesomeopensource.com/projec...parta/nomai-vr

• Steam and SteamVR installed (even if you're using a non-Steam version of the game);

So you can get here the game outside of steam and the mod itself is installed in a mod manager also not inside of steam, yet it needs you to have steamvr installed to work.

2. https://git.dec05eba.com/vr-video-player/about/
Also requires steam(vr).
A small opensource tool that requires 1gb steam client to work... a abomination.

Is there even some sort of launcher VR tool, that is some sort of 3d desktop like a house or something that is available in Mixed reality launcher from MS or Steams house thing.

It would be nice to be able to use VR in linux without Steam I know there is some obscure tools with monado where you can use it professionally in blender and one other tool, but I talk more on the entertainment side.

VR is a poorly supported zeroth-world problem.

[smitty3268]

Dropping it in their OS is one thing, dropping it in the ARM core is quite another. Windows doesn't let me run 16-bit DOS games anymore, but lots of modern hardware still boots DOS just fine.

If apple cared about that, they'd have never switched from x86 to ARM in the first place.

Apple has never cared about long term compatibility. It's one of the primary things that makes them different from Microsoft.

[Developer12]

If apple cared about that, they'd have never switched from x86 to ARM in the first place.

Apple has never cared about long term compatibility. It's one of the primary things that makes them different from Microsoft.

I was making an example of the difference between operating vs processor support.

I'm not even sure it's legal under the ARM ISA spec to make a processor that can't run 32-bit instructions, being a subset of 64 bit. It's definitely not possible on x86.

[Ladis]

I was making an example of the difference between operating vs processor support.

I'm not even sure it's legal under the ARM ISA spec to make a processor that can't run 32-bit instructions, being a subset of 64 bit. It's definitely not possible on x86.

On ARM, 32bit instructions are not a subset of 64bit. And Apple has to follow the rules of the ARM ISA. E.g. they can't add own instructions (as that would add fragmentation what each ARM CPU can do).

[linuxgeex]

On ARM, 32bit instructions are not a subset of 64bit. And Apple has to follow the rules of the ARM ISA. E.g. they can't add own instructions (as that would add fragmentation what each ARM CPU can do).

To be clear, ARM themselves dropped 32-bit instructions in the ARM-V9 ISA, and their hundred-series Cortex product lineup. Having an unused instruction decoder eating up silicon floorplan becomes an increasingly hard sell, especially when one of ARM's USP's is supposed to be the relative efficiency of their instruction decoder, lol... it's what all their fanbois call out as their benefit vs x86!

M1 is an ARM-V9 ISA core, so dropping 32-bit would merely be following ARM's lead.

Apple has a license from ARM to add proprietary extensions to their cores. This was big news a little over a year ago. Also big news shortly after the M1 launch was the fact that M1 had specialised x86 / x86-64 emulation instructions and addressing modes. Which BTW they would have needed to license from Intel. Recall that Intel shut down NVidia's attempt to do the same with their Denver cores.