Where We Go Next
It started with Slug

The Slug Algorithm poster from my March 22 article. Image: Slug / Eric Lengyel / Terathon Software.
In March 2026, Slug got me thinking about what else we could bring to small boards. On March 17, Eric Lengyel released Slug's reference vertex and pixel shaders, and I wrote about it on March 22. There was working rendering code to study, with an open-source license. The reference shaders are available separately from the commercial Slug Library.
Our Impossible Type experiment took a smaller step: prepare font masks on the computer, then use a native compositor to animate them on a Feather RP2040 DVI. You saw its recorded output on Real Device Demos. It uses prepared masks rather than running Slug's GPU shaders or rendering font curves directly on the board.
That's open source doing useful work: an implementation you can read gives you a place to begin. Find a piece the hardware can handle, try it, and share what you learn.
MicroPython already has useful tools
MicroPython has Native and Viper emitters for supported targets. It can also import native .mpy modules built from C. Another route is to compile C modules into the firmware itself. Each route has its own build and runtime requirements.
Turbo brings selected pieces into a CircuitPython workflow. The example in this guide uses mpy-cross, matching firmware, readable source, and a benchmark. Start with a working program, compile one function, and check the result.
PyMCU opens another compiler path

Project artwork from pymcu.org. Image: PyMCU project. This represents the compiler project; it is not a photograph of a hardware test.
PyMCU compiles a statically typed subset of Python. Its ARM backend uses LLVM to produce code for the target processor.
An earlier Feather RP2040 DVI prototype combined PyMCU output with a handwritten C adapter and CircuitPython's native-module linker. Recorded demos included brightness and Mandelbrot, with removable native modules and Python fallbacks. It showed that this separate compiler route could run selected work on the board. The Metro 19.71× result in this guide comes from the later mpy-cross workflow.
There is useful work ahead here: make the adapter easier to produce, check types and target compatibility, and compare complete outputs. A compiler can do more of the repetitive preparation while the person writing the project keeps control of the program.
Bao: give the loop a few helpers
The Baochip BIO has four small RISC-V cores. Our recorded Dabao evaluation-board tests used all four, with CircuitPython on the main CPU sending parameters and collecting results through queues. The BIO programs were handwritten RISC-V, assembled on the computer. This was an explicit dispatch path, not automatic Python-to-BIO compilation.
Two recorded comparisons show what that arrangement can do. Each ran Python first, then BIO on the same board. These are September 4, 2026 results from CircuitPython 10.3.0-alpha.4-bao-turbo.1, reviewed from saved records for this guide. They were not rerun for the guide.
Read the recorded numbers
| Recorded workload | Main-CPU CircuitPython compute | Four BIO cores, including coordination | Compute speedup |
|---|---|---|---|
| Integer Monte Carlo, 1,048,576 darts | 94.888732858 s | 0.102630589 s | 924.6× |
| Fixed-point Mandelbrot, 128 × 96, up to 64 iterations | 2.796966554 s | 0.150634769 s | 18.6× |
The Monte Carlo run added the compute times of 32 batches per mode. Both modes returned 823,567 hits; all returned counts, previews, and final states matched. This check covered the returned records, not a stored list of every dart. For Mandelbrot, all 12,288 output bytes matched. Each row describes one final paired run, not a median of repeated trials.
Four cores, so why more than four times?
We changed two things: where the work ran and how it ran. The baseline executed the integer loops through CircuitPython. The BIO path ran small machine-code loops across four cores. This comparison does not isolate the benefit of parallelism, and it does not compare BIO with optimized C on the main CPU.
Monte Carlo gives each core a long batch of repetitive work with relatively few results to send back. Mandelbrot sends a whole image's pixel counts back through the queues, and the main CPU must receive and unpack them. Those different costs help explain why each workload gets its own ratio.
The stopwatch boundary matters. The compute measurements include BIO startup, parameters, and receiving results. They exclude one-time program loading and USB reporting. In the same recorded Mandelbrot run, the wider host stage that includes USB reporting took 5.140444959 s for Python and 2.487102917 s for BIO, about 2.07×. The faster loop helped, and moving the results became a larger part of the wait. That stage is not a DVI display frame rate.
Inspect the recorded data
The download below contains the exact timing records, Monte Carlo results, all Mandelbrot output bytes, source hashes, and an offline verification script. The script checks the saved data without connecting to hardware. Recording nanoseconds preserves the timer values; it does not imply nanosecond measurement accuracy.
What we'd like to try next
Pixel transforms, small simulations, audio-buffer math, sensor-data filtering, and repeated searches through buffers are useful candidates. First find a loop that takes time. Then ask whether a built-in operation, a better data layout, native CPU code, PIO, or a coprocessor is the right tool for that particular job.
For Turbo, we want easier builds, clearer target checks, reusable adapters, and more examples with complete output comparisons. On Bao, the next experiments could explore better batching and less time moving results. Other processors and compiler backends will need their own working paths and measurements.
Keep the part of Python that makes a project easy to change. Give the busy part a well-defined job, and measure the whole project afterward. The reward might be smoother type, another animation layer, or enough time to read the next input.
Hardware behind these experiments
The Feather RP2040 DVI below is the board used for the earlier PyMCU and Impossible Type experiments, with their separate custom builds. The Bao results came from a Dabao evaluation board with Baochip-1x; see the Baochip hardware project for that platform. They do not qualify a different Bao board or establish a ready-to-install Turbo package for it.
Page last edited September 11, 2026
Text editor powered by tinymce.