Are there any plans to support the ARM64 architecture? 64-bit OSes for the Raspberry Pi and other boards are becoming more popular, and at present the only way to run PICO-8 on a 64-bit Pi OS is to install Raspbian in a chroot, use a hack in the .Xauthority file, and run PICO-8 from within the chroot.
That is not a satisfactory solution. No OSes exist for the Pi that have a mixed userland (Raspbian is 32-bit only) so the most practical solution is to put together an ARM64 build for PICO-8.
If you don't have easy access to a 64-bit image to build on, there is one based on Gentoo that comes with a desktop and toolchain out of the box: https://github.com/sakaki-/gentoo-on-rpi-64bit
Only you have the source code, @zep! What do you think? :P
+1, now that I know this is an issue anyway. There's also a usable image of Ubuntu Server here:
https://jamesachambers.com/raspberry-pi-4-ubuntu-server-desktop-18-04-3-image-unofficial/
I think the latest official distro of 19.10.x is fairly complete in its support for RPi4 in arm64 mode too, but I haven't tried it myself yet.
(Psst catatafish, if you really want to +1, that's what the star button on the right of each post is for.)
I did some digging. Distros that enable 32-bit support in the kernel for their ARM/RPi builds should be able to run a 32-bit static binary without a 32-bit userland.
I also noticed that both pico8 and pico8_dyn are dynamically linked in the pi download. The former is stripped, but not static. So the hardware may support it, but the binary wasn't built statically, so it looks for the 32-bit armhf loader, which won't work on an aarch64 userland without building a multilib system (of which nobody does at the time of writing due to 32-bit ARM arch fragmentation and the looming 2038 problem).
So, fixing it to be static can be a good interim solution while aarch64 is being looked into. It would at least give us a way to run it in a 64-bit userland.
While I did this I checked the x86_64 version of PICO-8 and both ./pico8 and ./pico8_dyn are dynamically linked there, too:
pico8
$ readelf -d ./pico8 Dynamic section at offset 0x24fa50 contains 28 entries: Tag Type Name/Value 0x0000000000000001 (NEEDED) Shared library: [libm.so.6] 0x0000000000000001 (NEEDED) Shared library: [libdl.so.2] 0x0000000000000001 (NEEDED) Shared library: [libpthread.so.0] 0x0000000000000001 (NEEDED) Shared library: [librt.so.1] 0x0000000000000001 (NEEDED) Shared library: [libc.so.6] 0x000000000000000c (INIT) 0x403680 0x000000000000000d (FINI) 0x5d9894 0x0000000000000019 (INIT_ARRAY) 0x84e150 0x000000000000001b (INIT_ARRAYSZ) 8 (bytes) 0x000000000000001a (FINI_ARRAY) 0x84e158 0x000000000000001c (FINI_ARRAYSZ) 8 (bytes) 0x000000006ffffef5 (GNU_HASH) 0x400298 0x0000000000000005 (STRTAB) 0x401720 0x0000000000000006 (SYMTAB) 0x4002e0 0x000000000000000a (STRSZ) 2113 (bytes) 0x000000000000000b (SYMENT) 24 (bytes) 0x0000000000000015 (DEBUG) 0x0 0x0000000000000003 (PLTGOT) 0x851000 0x0000000000000002 (PLTRELSZ) 4992 (bytes) 0x0000000000000014 (PLTREL) RELA 0x0000000000000017 (JMPREL) 0x402300 0x0000000000000007 (RELA) 0x402228 0x0000000000000008 (RELASZ) 216 (bytes) 0x0000000000000009 (RELAENT) 24 (bytes) 0x000000006ffffffe (VERNEED) 0x402118 0x000000006fffffff (VERNEEDNUM) 5 0x000000006ffffff0 (VERSYM) 0x401f62 0x0000000000000000 (NULL) 0x0 |
pico8_dyn
readelf -d ./pico8_dyn Dynamic section at offset 0x114dc8 contains 26 entries: Tag Type Name/Value 0x0000000000000001 (NEEDED) Shared library: [libSDL2-2.0.so.0] 0x0000000000000001 (NEEDED) Shared library: [libm.so.6] 0x0000000000000001 (NEEDED) Shared library: [libc.so.6] 0x000000000000000c (INIT) 0x4035f0 0x000000000000000d (FINI) 0x4dc454 0x0000000000000019 (INIT_ARRAY) 0x713fd0 0x000000000000001b (INIT_ARRAYSZ) 8 (bytes) 0x000000000000001a (FINI_ARRAY) 0x713fd8 0x000000000000001c (FINI_ARRAYSZ) 8 (bytes) 0x000000006ffffef5 (GNU_HASH) 0x400298 0x0000000000000005 (STRTAB) 0x401668 0x0000000000000006 (SYMTAB) 0x4002e8 0x000000000000000a (STRSZ) 2696 (bytes) 0x000000000000000b (SYMENT) 24 (bytes) 0x0000000000000015 (DEBUG) 0x0 0x0000000000000003 (PLTGOT) 0x715000 0x0000000000000002 (PLTRELSZ) 4680 (bytes) 0x0000000000000014 (PLTREL) RELA 0x0000000000000017 (JMPREL) 0x4023a8 0x0000000000000007 (RELA) 0x402330 0x0000000000000008 (RELASZ) 120 (bytes) 0x0000000000000009 (RELAENT) 24 (bytes) 0x000000006ffffffe (VERNEED) 0x402290 0x000000006fffffff (VERNEEDNUM) 2 0x000000006ffffff0 (VERSYM) 0x4020f0 0x0000000000000000 (NULL) 0x0 |
(Perhaps I'm misunderstanding the intended distinction between pico8 and pico8_dyn.. clarification would be appreciated)
Can't really comment on the ABI details as I don't know the arm platform at all, but (and I should really get off my butt and check this stuff for myself but I don't have much time at the moment) I remembered that Ubuntu 19 also supports KVM, if you can live with virtualization that may be another interim option.
Also thanks Felice, I wasn't thinking of stars as +1's (more like bookmarks), but I've clicked the appropriate places now.
@Catatafish: It should really only be an addition of a build target in whatever build system @zep uses to build PICO-8. AFAIK every major build system supports aarch64. Then (maybe) a change to how 'pico8' gets built so it produces a static binary. We'd run into fewer linking issues because customers could fall back to the static binary if there's an issue with their system.
The devil's in the details: it adds to the maintenance burden (if only a little) and it's another build target to test, another download link, etc. Maybe it's not a problem, since the PocketCHIP still gets PICO-8 builds and it's dead hardware. (not meant as a pejorative; they look fun and it's a shame it's not a thing anymore)
EDIT: I hear you on time constraints! So many things I want to do in PICO-8, never enough time. :)
Bumping to mention that Raspberry Pi recently announced a split from the Raspbian name (but still using the same base) and released an official 64-bit port, to give users access to the full 8GB (!) available on the brand-new Pi4B.
https://www.raspberrypi.org/blog/8gb-raspberry-pi-4-on-sale-now-at-75/
I also would really like to see ARM64 support, specifically for the pinebook pro and pinephone, as well as the pinetab.
Ditto I have a Pinebook Pro coming in the next couple of weeks and I'd dearly love to be able to run pico-8 on it!
I suppose you could do it with qemu but I'd expect it to be blisteringly slow.
When my pinebook pro comes in, I intend to try various experiments to see if I can get the stock x86 pico-8 binary running.
I'll try (in order of preference) Box86 and qemu.
I don't have particularly high hopes for Box86. I'm pretty sure I can get qemu to work but I expect the performance to be super abysmal. We'll see.
Can't blame @zap for not wanting to build binaries for all the new ARM devices, there are so many and they each require custom support for their various graphics chipsets (Kind of a design downside for the architecture IMO)but that won't stop me from trying :)
I'll report back here should I have any success, or if I end up giving up entirely :)
I tried figuring out how to set up a QEMU X86_64 VM to run the stock Linux binary, and it was so incredibly slow pico-8 wasn't in the offing.
My next strategy will be to try Remote Desktop-ing into my beefy Windows box :)
Another bump for a ARM64 for the same reason as micronaut, Odroid Go Advance Void Linux (Retro Roller).
I would also love to be able to use Pico-8 on my Pinebook Pro!
I'm bumping this because I now have Ubuntu Pi desktop. Specifically Ubuntu MATE on my Raspberry Pi 3 B+.
EDIT 2020-NOV-08 10:11pm: Never mind about the Ubuntu MATE. That one works better on RPi 4, but my point still stands.
Batocera is also moving to 64 bits for RPi, RK3326 (Odroid Go Advance, Super, Gameforce…). It’s too bad we can’t use the official pico-8 binary any more. I’m currently adapting Batocera to support it “out of the box” and it might be limited to PC x86_64 until then.
I ended up moving to ArkOS which now has an OGA version. Runs 32 and 64bit RetroArch side by side on 32bit debian for Pico8.
Just checking to see if there has been any movement on this? Have a Lenovo Duet Chromebook that would be ace to have pico8 on.
Same as chiz! I think this would be a great pico8 terminal for my son!
I launched PICO-8 on Raspberry PI 4 with 64 bit Ubuntu Mate 20.04 using such commands:
sudo dpkg --add-architecture armhf sudo apt-get update sudo apt install libudev1:armhf libsdl2-2.0-0:armhf sudo reboot now # After reboot $PATH_TO_PICO/pico8_dyn |
BRUH! That is awesome! I will have to try that this weekend! If it works, we have somewhat of a workaround. Not perfect, but workable!
What is the reboot for? Adding architectures and installing foreign packages are normal operations, the packages will work immediately after. Rebooting is only useful when updating the kernel or init system :)
I don't remember exactly why I needed a reboot)
But as far as I remember, there were some errors with display detection in SDL2.
Perhaps a simple logout or something else helps, but I decided to use a simpler solution.
If it concerns dependency hell or that sick looking DevTerm (how is that btw?), I'd also like to be in on this chat. Maybe a thread somewhere?
i'd love to start a DevTerm + pico 8 thread but my unit has yet to arrive. once it does i'll be all over it with yall <3
OK don't mind me - just saw the 0.2.3 update post: https://www.lexaloffle.com/bbs/?tid=44512
Quote: "Next up for PICO-8 is a 64-bit Raspberry Pi Build, and also a ...."
Bumping this. Wanna run Pico-8 on Void Linux aarch64 on a Raspberry Pi 4B but having little luck.
Not used to software where there's not even a list of dependencies (that I'm aware of).
Bumping this to confirm: as of version 0.2.4, PICO-8 has a 64-bit Raspberry Pi build available! We did it!
Huge thanks to @zep for considering it and delivering! Can't wait to finalize my retro-gaming system powered by a Pi, with PICO-8 in it!
[Please log in to post a comment]
