Search results

Yes. Only a "few" library are wrapped (I didn't count, but more than 50). The others are still emulated. Also c++ library are not wrapped, as it would be too messy to handle in a reasonable way.

It's not designed to run OS/full System, but userspace programs. That's why.

New release of box86 & box64 https://box86.org/2024/05/new-version-of-box64-v0-2-8-and-box86-v0-3-6/ (compared to previous release, using callret & bigblock option can give more than 10% speedup in cpu bottleneck scenario, tested on the Pandora)

Mmmm, that shader will probably not work with the draw instanced, even when removing that line. I guess I would have to try those latest love engine myself and see if I can workaround / add support for that, but I'm unsure when I will be able to take a look...

aTc have just updated the deb package, so update and you are good to go!

New release of Box64 and Box86! https://box86.org/2023/12/new-version-of-box64-v0-2-6-and-box86-v0-3-4/

Yep!

Oh yes, of course I do :D! Yeah, I have seen that video. Box86 is not available on RiSC-V, because it's a 32bits only app, and thoses board are 64bits only (there might be 32bits core but it's not for user space). Steam for now is still complicated to get running on 64bits only system. The...

Maybe the data file evolved since when I build this stuff. Not sure I can do an update of the source because Rockstar was savage against those R.E. sources.

Yes, that expected, there will be more SIGBUS. But is still at the same code or is it farther?

Yes. Issue is that that origin.y is a float (origin is a vec3_t), and loading it directly with a get_i32, the compiler optimise all that by just reading an int from a pointer to a float, using VFPv3... But the address is unaligned... and so segbus. Chnage the line 59 by my block and try again...

@Farox that's exactly what I was talking about: at src/wipeout/object.c:59 59 object->origin.y = get_i32(bytes, &p); that's were the SEGBUS is happening. Not sure if get_i32 is a function or a macro, and what type is origin.y... I can imagine maybe something like int volatile tmp =...

I don't think it's enough, but feel free to try.

BUSERROR is typical from this old software: memory were scarse, so all data were tightly packed. But ARMv7 have strict alignment constraint for everything float and double. Some helper, using memcpy or similar method, might be needed: run under gdb, what for the SEGBUS, look at the code...

Port what @Farox DBGL or Dosbox (there is a dosbox pnd already IIRC)

New release on the repo with a fresh build and some repackaging to hopefully make it more compatible with future version of the OS Build 03 ---------- fresh build repacked for better compatibility

New version of the repo with a fresh build and some repackaging to hopefully make it more compatible with future version of the OS. Build 03 ---------- fresh build repacked for better compatibility

New release on the repo, with a fresh build and some repackaging to hopeuflly make it more compatible with future version of the OS Build 03 ---------- fresh build repacked for better compatibility

New build on the repo, with a fresh build and some repackaging to hopefully make it more compatible with future version of the OS. Build 03 ---------- fresh build repacked for better compatibility

Yes, I have seen. And it's awesome :D !