La nostalgia retro y la fiebre por la Inteligencia Artificial acaban de cruzarse en un experimento que, hace poco, habría sonado a ciencia ficción: un desarrollador ha logrado que un modelo de lenguaje escriba el esqueleto de un emulador de Nintendo Entertainment System (NES) y que, además, funcione lo bastante como para ejecutar Donkey Kong desde el navegador.

El protagonista es Rodrigo Delduca, creador del motor Carimbo 2D, que decidió convertir una idea recurrente entre programadores —“¿y si hiciera un emulador?”— en una prueba de estrés para la IA. En lugar de pasar semanas consultando documentación, implementando opcodes y depurando registros, Delduca optó por un enfoque distinto: trasladar buena parte del trabajo a Claude, el asistente de programación de Anthropic. El resultado se ha publicado como un conjunto de scripts en Lua que, coordinados con Carimbo 2D, consiguen levantar una consola virtual capaz de ejecutar una ROM y mostrarla en pantalla.

El experimento tiene dos méritos evidentes. El primero, el titular fácil: sí, se puede jugar. El segundo, más interesante: un emulador no es “un juego más”, ni siquiera un proyecto de gráficos con físicas. Un emulador obliga a reproducir el comportamiento de un hardware concreto con suficiente fidelidad como para que el software original —pensado para chips de los años 80— crea que está en casa. Y ahí es donde la IA se enfrenta a la parte ingrata del desarrollo: precisión, compatibilidad, tiempos, y un sinfín de detalles que no perdonan.

Por qué un emulador es una prueba dura para una IA

La NES es una de las consolas más emuladas de la historia, precisamente porque se ha convertido en terreno de aprendizaje y referencia. Es un sistema “viejo” en términos de informática moderna, pero no es simple. Emularla implica, como mínimo, reproducir:

• La CPU y su mapa de memoria, con sus zonas espejo (mirroring), registros de entrada/salida y comportamiento concreto al leer y escribir direcciones.
• La PPU (Picture Processing Unit), responsable de la salida gráfica, sus registros y su propia memoria dedicada.
• El bus y la coordinación entre componentes: CPU, vídeo, mandos y cartucho.

En una consola real, el software del juego se apoya en rutinas, timings y “trucos” que dan por hecho el comportamiento del hardware. En emulación, cualquier desviación puede traducirse en sprites corruptos, parpadeos, cuelgues o, simplemente, una pantalla negra.

Las referencias técnicas más usadas por la comunidad describen con detalle estas peculiaridades. Por ejemplo, el mapa de memoria de CPU de la NES incluye 2 KB de RAM interna que se refleja en varios rangos de direcciones, y los registros de la PPU aparecen mapeados y también repetidos en un rango más amplio debido a la decodificación incompleta de direcciones. Son matices de diseño que, para un emulador, dejan de ser curiosidades: son requisitos.

Lua, Carimbo 2D y la idea de “emulación portátil”

Una de las claves del proyecto es el “encaje” tecnológico. Carimbo 2D está concebido como un motor 2D moderno, escrito en C++ y apoyado en SDL, pero con una característica especialmente relevante para este caso: es scriptable en Lua y puede ejecutarse en múltiples plataformas, incluido el navegador mediante WebAssembly. Es decir, el motor actúa como una base portable y el emulador se expresa como lógica en scripts.

Eso encaja con la forma de trabajar de un LLM: generar módulos de código relativamente independientes (CPU, PPU, entrada…) que luego se integran en un sistema mayor. Según se explica en los materiales publicados, Claude generó scripts que imitan la ejecución de instrucciones de una CPU compatible con 6502 (la Ricoh 2A03 de la NES), emulan el funcionamiento de la PPU y gestionan la lectura de mandos, entre otras piezas esenciales. Dicho de otro modo: no se limitó a dibujar una ventana con píxeles, sino que intentó construir una arquitectura de consola en software.

La parte menos glamourosa: rendimiento lento y sin sonido

Quien espere encontrar un “nuevo emulador de referencia” se topará pronto con la realidad. Las primeras pruebas públicas describen una experiencia lenta, con quejas sobre la fluidez y, además, sin sonido. En comentarios citados sobre el proyecto, incluso se llega a mencionar una caída de rendimiento muy marcada frente a emuladores web ya consolidados.

No sorprende. Un emulador eficiente suele apoyarse en optimizaciones agresivas (incluido JIT en algunos casos), tablas precalculadas, y una implementación cuidada de ciclos y eventos. Un emulador que vive en scripts Lua, corriendo además en un entorno web, parte con desventaja: más capas, más overhead y menos margen para exprimir el hardware. Y, aun así, el simple hecho de que el conjunto arranque y ejecute Donkey Kong tiene valor como demostración.

A esto se suma una limitación típica en prototipos: compatibilidad parcial. Las propias observaciones públicas sobre la demo dejan en el aire si funciona con más juegos que el título mostrado. En emulación, pasar de “funciona con uno” a “funciona con muchos” suele ser el tramo más largo del camino, porque aparecen mappers distintos, casos límite de la PPU, timing de interrupciones y comportamientos que ciertos juegos explotan de forma particular.

Qué dice este experimento sobre el futuro del desarrollo con IA

El emulador de Delduca funciona también como metáfora de la etapa que vive el desarrollo software: la del “vibe coding” y la productividad aumentada por asistentes. La IA puede generar grandes volúmenes de código con estructura razonable, e incluso distribuir responsabilidades en módulos (CPU, PPU, entrada). Puede acelerar la fase de arranque, reducir la fricción inicial y ayudar a iterar.

Pero un emulador expone, sin maquillaje, las limitaciones del enfoque: la corrección y la fidelidad no se improvisan. En proyectos donde un bug es un “detalle visual”, la IA puede salir airosa más a menudo. En emulación, un bug puede ser una instrucción mal implementada o un registro escrito en el orden equivocado. Y entonces no hay atajo: toca leer documentación, comparar con referencias, ejecutar tests, depurar y validar.

En ese sentido, el experimento no deja una conclusión única, sino dos, casi complementarias:

1. La IA ya puede levantar prototipos funcionales de sistemas complejos si el entorno (motor + lenguaje scriptable) acompaña.
2. La ingeniería fina sigue siendo humana: pruebas, rendimiento, compatibilidad y decisiones de arquitectura siguen requiriendo criterio y paciencia.

Una nota inevitable: emuladores sí, ROMs con cuidado

El éxito mediático de la demo se apoya en una palabra: Donkey Kong. Eso tiene gancho, pero también obliga a una aclaración habitual en el mundo retro: el emulador es una cosa y las ROMs, otra. La emulación como técnica es legal en muchos contextos, pero distribuir o descargar ROMs sin derechos no lo es. Lo razonable —y lo que suele recomendar la comunidad— es usar copias obtenidas legalmente, por ejemplo mediante “dumping” de cartuchos propios, o recurrir a software con licencia o dominio público cuando exista.

Un paso pequeño para el “retro”, uno llamativo para la IA

No parece que este emulador vaya a destronar a los clásicos ni a convertirse en la forma preferida de jugar en 2026. Pero sí deja una imagen potente: una IA escribiendo la base de un sistema que, durante décadas, se consideró un rito de iniciación para programadores de bajo nivel. Con todas sus limitaciones, la demo sirve para recordar que la frontera no siempre avanza con productos perfectos, sino con experimentos que prueban lo que ayer parecía imposible… aunque hoy todavía vaya “a trompicones” y sin música.

---

Preguntas frecuentes

¿Qué hace falta para probar un emulador de NES en el navegador y por qué puede ir lento?
Normalmente basta con un navegador moderno, pero el rendimiento depende mucho de la implementación (lenguaje, optimizaciones) y del entorno de ejecución (por ejemplo, WebAssembly). Si el emulador está construido con scripts y sin optimizaciones específicas, es habitual notar bajadas de FPS o latencia en el control.

¿Por qué es tan difícil emular la NES con precisión si es una consola antigua?
Porque muchos juegos dependen de detalles del hardware: mapas de memoria con mirroring, registros de vídeo mapeados en direcciones concretas, tiempos de la PPU, interrupciones y comportamientos no evidentes. La “antigüedad” reduce potencia, pero no complejidad.

¿Es legal usar un emulador de NES? ¿Y qué pasa con las ROMs?
Un emulador, como software que reproduce un sistema, suele ser legal según el contexto. Las ROMs están sujetas a derechos de autor: usarlas sin licencia puede ser ilegal. La vía segura es usar copias obtenidas legalmente o software publicado con licencia compatible.

¿Qué ventajas tiene usar Lua y un motor 2D scriptable para un proyecto así?
Facilita portar el proyecto a varios sistemas y acelera la iteración: el motor ofrece la base (ventana, entrada, renderizado), y Lua permite modificar lógica rápidamente. Eso es especialmente útil cuando se experimenta o se integra código generado por IA.

Código fuente en GitHub y demo jugable online.