There are efforts to port pico8 to microcontrollers, but the real problem with lua is memory (easily requires 4MB of memory which is only available on high-end microcontrollers).
Ok, but which language feature(s) of Lua is it which inherently requires so much memory? I understand you wouldn't exactly get a 100% standards compliant implementation, but what are the hard parts?
With Lua's design, each bytecode operation requires a bunch of memory accesses, these microcontrollers only have a limited amount (~500KB) of SRAM, so you need to place this memory on PSRAM (RAM over SPI) which has "significant" latency for these microcontrollers.
It's definitely possible to use standard Lua and run _some_ of the Pico8 games, but not all.
Lua itself does not require a lot of memory, but PICO-8 guarantees 2MiB of usable RAM
A big difference I see between this Lua and PICO-8's is that the former is compiled, whereas the latter is interpreted.
How it manages to run Lua with such limitations, the documentation of Lua Flash Store (LFS) goes into detail.
> The ESP8266 has 96 Kb of data RAM, but half of this is used by the operating system, for stack and for device drivers such as for WiFi support; typically 44 Kb RAM is available as heap space for embedded applications. By contrast, the mapped flash ROM region can be up to 960 Kb, that is over twenty times larger. Even though flash ROM is read-only for normal execution, there is also a "back-door" file-like API for erasing flash pages and overwriting them..
> Lua's design goals of speed, portability, small kernel size, extensibility and ease-of-use make it a good choice for embedded use on an IoT platform, but with one major limitation: the standard Lua RTS assumes that both Lua data and code are stored in RAM, and this is a material constraint on a device with perhaps 44Kb free RAM and 512Kb free program ROM.
> The LFS feature modifies the Lua RTS to support a modified Harvard architecture by allowing the Lua code and its associated constant data to be executed directly out of flash ROM (just as the NoceMCU firmware is itself executed).
> This enables NodeMCU Lua developers to create Lua applications with a region of flash ROM allocated to Lua code and read-only constants. The entire RAM heap is then available for Lua read-write variables and data for applications where all Lua is executed from LFS.
That's still such a tiny amount of RAM, not nearly enough for PICO-8.
..Oh I see, the project PicoPico mentioned up-thread uses ESP32 Wrover with 4MB PSRAM - instead of Raspberry Pi Pico which it started with but didn't have enough RAM.
Well, having just seen the entrance of the rabbit hole, I can imagine the attraction of PICO-8 and working with such constrained systems - what a challenge!
The constraints fuel creativity, but it also pushed me to start writing a Lua compiler for PicoPico, which shows promise but is also a massive scope creep and mostly the reason I've not worked on PicoPico for a while
As much as I love Lua its very difficult to shoe-horn into an 8-bit CPU, especially with limited RAM... but there are other efforts to bring more modern languages to these platforms, and one that strikes me as interesting is dflat, from 6502Nerd:
The Pico8-inspired TIC-80 project can use WASM, although it’s a pretty heavy fantasy console too. The WASM-4 project might be another option to look into.
Would it necessarily be all that much slower than Basic? It's a very small and othogonal design.