A developer building a modern interpretation of an 1980s home computer has demonstrated a just-in-time compilation technique for rendering proportional bitmap text on the RP2350 microcontroller. The work is part of the vic-2350 project and targets a problem that is easy to underestimate: producing flexible typography while software is also responsible for feeding a video signal on schedule.
The RP2350 can output DVI video through its HSTX peripheral, but the application still has to create the pixels. Rather than reserve much of the chip's 520kB of SRAM for a full framebuffer, the project uses a race-the-beam design that assembles a buffer one scanline at a time. That conserves memory and can reduce latency, but it gives the renderer a budget of roughly six processor cycles for each pixel, according to the developer's technical account.
Fixed-width character cells are a common answer on constrained systems because they make text drawing predictable. Vic-2350 instead aims for the proportional spacing and kerning associated with early graphical computers. Its text display object stores the string, a font pointer and foreground and background colors. When the object becomes active, the renderer allocates temporary space and compiles that particular string into Cortex-M33 instructions. The generated code fills a one-bit-per-pixel intermediate buffer; a second pass expands those bits into 16-bit RGB565 pixels.
This shifts preparation work away from the most timing-sensitive part of display generation. The project maintains a double-buffered display list, sorting objects by their vertical position and tracking only those that intersect the current scanline. Setup methods can allocate scratch memory, while the per-scanline render method calls the already generated code. The developer reports that the color-expansion stage sustains 1.75 cycles per pixel, though the supplied evidence does not include independent benchmark replication.
Memory layout receives similarly close attention. Glyph pixels are packed into a wide bitmap whose height matches the font, and glyphs are arranged so that no character crosses a 32-pixel chunk boundary. That lets the renderer fetch a row with one 32-bit load. Spacing is kept in glyph metadata rather than stored as blank pixels, and overlapping bitmap regions can be reused. For the font described in the project, those measures reduced bitmap storage from 1,140 bytes to 960 bytes.
The technique is specialized rather than a general replacement for text libraries. It depends on executable scratch memory, architecture-specific generated code and a rendering pipeline designed around predictable scanline work. Its significance is as an engineering example: on a microcontroller where both RAM and cycles are scarce, compiling a known string at display-object startup can make richer bitmap typography compatible with real-time video output.
