A BASIC-style virtual machine that runs scripts on the ESP32

Oct 21, 2026 Last reply: 10 hours ago 4 Replies
Jump to replies (4)

When everything is up and running, the flow looks remarkably smooth. The firmware gets flashed to a board once, and after that a program is nothing more than a file sent over WiFi that starts immediately. RIBASIC, the interpreter interface, runs a blink script on GPIO 10 with 1000 millisecond pauses between LED states. The script is typed in, a green RUN button gets pressed, and a green arrow marks whichever line is running while a virtual LED flips each second before execution stops back at the ready state.



The way it is put together stands out. The maker wrote a custom virtual machine with a BASIC-like language, and scripts compile to bytecode right on the board. Heavy multimedia work lives in C inside the firmware, covering the decoder, camera and graphics, and shows up in scripts as simple commands. Each script starts with a config block declaring what is wired where, and for popular boards stock presets cover PSRAM, display pins, camera and audio. With just that block edited, one script works across any ESP32 board.



Around the core sits what the maker calls a whole ecosystem: an editor that works from a browser or phone, tools for images, fonts and audio, an AI helper, and a cloud service. The claimed payoff is concrete. A radio that took a week to play without stuttering or crashing, and whose board rebooted after a day from memory leaks, supposedly takes a single evening now. The maker also says a complex project or business idea can launch in an hour with the whole set of tools.



Two things remain open. Whether code executes directly from the screen has not been answered, and the post text actually cuts off mid-sentence right after saying the firmware is debugged once. How the RIBASIC interface relates to the wider ecosystem is also left unexplained.


How does a new script actually reach the board once the firmware is in place? Does the maker push files over the network from the editor, or is there some other transfer step involved?

Keeping the heavy multimedia work in C inside the firmware, exposed to scripts as plain commands, seems a smart call to me. Under Arduino, three audio libraries kept separate buffers and clashed with WiFi and the display. Centralizing that in one tested C layer looks like a sensible answer to exactly that kind of mess. The trade-off is that scripts can only do what the firmware exposes.

Since only the config block needs editing to move a script between boards, I would love to see a shared library of configs for boards beyond the popular presets. It would let people reuse existing scripts on less common hardware without hunting down pin mappings themselves.

The maker covered that part: after flashing the firmware a single time, a program is simply a file sent over WiFi, and it starts running right away. Nothing about any extra transfer step has come up.

Join the Discussion

Have something to add? Share your thoughts — no account required.

Didn't find your answer?

Ask the community — no account required