@NicoD I download and extract the Wine-Proton prebuilt binaries, then let Box64 do the rest. This is the script I used (You might want to change the directories)

There was a commit 4 days ago on that repo metioned above: https://github.com/joilg/x88pro/commit/a6630814a98b39ec39dc22108c01e35f5d456395 Anyone noticed? Anyone tried it? Any change?

This is putting some sort of warning flag for myself. 'pretty sure', 'chatGPT', a Rockchip board v.s. Allwinner board.

OK, so it actually was cold in FL for a couple weeks and I did a power hack. I ported Java UIO to Java UIO 2. Java UIO (HawtJNI) This was the "Old School" high-performance approach. It relied on a custom C wrapper and JNI to bridge the gap. How it works: You have to write a C helper file, compile it into a shared library (.so) for on ARM architecture (armv7l, aarch64), and bundle it in your JAR. The Overhead: Every call from Java to C has a "JNI transition cost." To minimize this, you used moveJavaToNative to bulk-transfer buffers, which added complexity to the Java code. Java UIO 2 (FFM / Project Panama) The "Modern" approach. It treats native memory and functions as first-class citizens in Java. I now cross compile on x86_64 for arm32 and arm64. How it works: Java uses Linker and SymbolLookup to find functions in u8g2 or libc directly. No custom C wrapper is strictly required unless you want to simplify complex macros. The Overhead: Transitions are heavily optimized by the JVM (often inlined). By using MemorySegment, you can point Java directly at the UIO hardware registers or the U8g2 tile buffer. The Armbian Advantage: It is "Write Once, Run Anywhere" for native code. As long as the system library (like libSDL2.so) exists on the Armbian filesystem, the same JAR will work on an Orange Pi 5, a Pine64, or even a Raspberry Pi without re-compiling C code.

It is possible but I think it is currently broken / unfinished / does not work (properly) yet.