Raph Levien acelera el texto en microcontroladores con un JIT que compila fuentes bitmap al vuelo
JIT bitmap text rendering for microcontrollers
Raph Levien presenta una técnica de renderizado de texto bitmap extremadamente rápida para el RP2350, basada en un JIT que genera código ARM optimizado para cada cadena. El sistema logra un presupuesto de 6 ciclos por píxel y un segundo pase a 1.75 ciclos por píxel, gracias a una fuente empaquetada en 960 bytes y un renderizado que compite con el haz. La técnica se implementa en su renderizador race-the-beam y permite espaciado proporcional y kerning en un microcontrolador con solo 520 kB de SRAM.
Cualquier glifo contenido dentro de otro no necesita empaquetarse por separado; por ejemplo, la 'l' es el lado izquierdo de la 'U', y el '0' es idéntico a '()' sin el espacio intermedio.
- drfuchs
Para trabajo previo relacionado, echa un vistazo a la patente US-6377261-B1 "Compiling glyphs into instructions for imaging for execution on a general purpose computer" presentada en 1996. La idea básica es que cada carácter se convierte en una secuencia de instrucciones "Load Immediate" / "Shift" / "OR to Memory"; así que ya no hay que buscar en un bitmap almacenado de la fuente, ya que los píxeles están implícitos en los datos Immediate del código máquina generado. Luego puedes ponerte creativo cuando una fila de píxeles es igual a la fila anterior en el carácter, de modo que ni siquiera necesitas hacer el Load Immediate. Etc. Este esquema se usó en FrameMaker para Macintosh en su día, implementado por Gus Fernandez (quien se desató con optimizaciones adicionales).
- karmakaze
Este es un proyecto realmente genial. Muchas computadoras retro son OP y pueden usar framebuffers grandes, y programarlas no se siente como estar cerca del metal como antes, que era más íntimo.
Esta implementación me recuerda dos de mis primeras experiencias: programar display lists en el Atari 8-bit y un intérprete HP PCL 5e (con un búfer de banda ráster corto). No me metí realmente en el beam racing de 128 bytes del VCS/2600, pero sí hice bastante codificación en vivo con interrupciones de display-list para juegos caseros y demos. Realmente pensé que el sistema de display list Antic del Atari era formidable —gracias a Jay Miner, quien también hizo el Amiga— y no vi nada parecido hasta OS/2 Presentation Manager o Java FX.
El intérprete PCL probablemente tenía la forma más cercana usando un búfer cíclico de unos pocos cientos de líneas. 'Renderizaba' en objetos ordenados por y que luego necesitaban ser renderizados/rasterizados. Cada objeto se cortaba para tener como máximo 255 píxeles (0.85") de alto y usaba orden inverso de max-y ya que no se podía dibujar hasta que el haz pasara la línea de barrido de envolvente que aún renderizaba Y - buffer_height.
- codazoda
He estado construyendo BASIC32, un intérprete BASIC retro para microcontroladores para poder flashearlo una vez y crear fácilmente muchos proyectos nuevos.
Lo que sacrificas con el enfoque del autor es la "lectura". La pantalla se vuelve de solo escritura. Solo hay unas pocas funciones que requieren lecturas: obtener el color actual de un píxel y hacer operaciones como rellenos por inundación o pintados.
Como buscaba la sensación retro de BASIC, quería soportar estas, así que opté por un framebuffer. No es tan técnicamente cool. En el RP2350, sí requiere baja resolución y bajas tasas de bits porque a menudo tienen RAM limitada a KB.
Si subes a las variantes ESP32-S3 con 4MB u 8MB de RAM, el framebuffer se vuelve mucho más fácil.