DONKEY.BAS on the Edge: Cómo revivimos el juego de Bill Gates de 1981 con Cloudflare Workers y Pages (Just For Fun!)

Hace unos días hablando con Chema Alonso me topé otra vez con uno de esos pequeños tesoros que la historia de la informática guarda en un cajón. DONKEY.BAS. Cuatro mil quinientos bytes de BASIC que vienen de 1981 y que, sin embargo, dan para hablar de muchas cosas. De cómo se hacía software cuando un PC tenía 16KB de RAM, de una de las polémicas más divertidas de la historia de Microsoft y, sobre todo, de algo que veo todos los días en mi trabajo, que es lo fácil que es hoy modernizar y desplegar cualquier aplicación gracias a la plataforma de Cloudflare.

Figura 1: DONKEY.BAS on the Edge: Cómo revivimos el juego de

Bill Gates de 1981 con Cloudflare Workers y Pages (Just For Fun!)  

Así que cogí el código original, lo migré a la web y lo puse a correr en producción en Cloudflare Pages en cuestión de minutos. Os cuento la historia completa, que tiene su miga. De la historia de este juego, por lo visto, se habla en el libro de  "Microhistorias: anécdotas y curiosiades de la historia de la informática (y los hackers)" de Fran Ramírez y Rafel Troncoso en 0xWord, que os dejo por aquí.

Figura 2: Libro de "Microhistorias: anécdotas y curiosiades de la historia
de la informática (y los hackers)" de Fran Ramírez y Rafel Troncoso 0xWord.

Por cierto, antes de entrar en materia con DONKEY.BAS, os recuerdo que ya os publiqué un caso parecido con la migración del mítico Arkanoid en el artículo titulado: "Cómo migrar Arkanoid de C++ a TypeScript con OpenCode y desplegarlo en Workers de Cloudflare".

La historia: el juego que Bill Gates escribió... y por el que le pincharon durante años

DONKEY.BAS lo escribieron en 1981 Bill Gates y Neil Konzen para demostrar las capacidades gráficas (el flamante modo CGA) y de sonido (el mítico PC speaker) del IBM PC, junto con la potencia del intérprete de BASIC que Microsoft había desarrollado para IBM. Venía incluido en las primeras versiones de PC-DOS, así que millones de personas lo tuvieron delante.

Figura 3: El juego de Donkey.BAS Version 2.0 (Fixed Version)

¿El juego? Sencillísimo: conduces un coche por una carretera de dos carriles y solo puedes hacer una cosa, cambiar de carril con la barra espaciadora para esquivar a los burros que van apareciendo. Si chocas, ¡BOOM! y punto para el burro. Si lo esquivas, "Donkey loses!" y punto para ti. No hay más objetivo. No hay final.

Y aquí viene lo "polémico".

Que uno de los fundadores de Microsoft hubiera firmado un juego tan primitivo —con gráficos que parpadeaban y una jugabilidad de quince segundos— se convirtió con los años en una especie de chiste recurrente en la industria.

Cuando salió el Macintosh en 1984, desde el mundo Apple se usó DONKEY.BAS como ejemplo de lo tosco que era el software del bando IBM/Microsoft frente a la elegancia gráfica del Macintosh. Bill Gates, lejos de esconderlo, siempre lo defendió con orgullo: era una demo técnica de lo que se podía hacer, no una obra maestra del diseño de videojuegos.

Figura 4: Pantalla de título original de DONKEY.BAS con el famoso "Version 1.1O"

Hay un detalle que a mí me encanta y que demuestra que las prisas de 1981 eran las mismas que las de hoy: si miráis el código original, en la pantalla de título pone Version 1.1O... con una letra "O mayúscula" en lugar de un cero - tal vez por no mostrar a los usuarios el famoso 0 de las tipografías de los ordenadores con la raya cruzada que los no técnicos quizá nunca entendieron -. Usas una O en lugar de un 0 con la raya cruzada, era igual que en algunas máquinas de escribir donde en lugar de usar el 1 se hacía con la "l" minúscula.

O quizá es un typo que lleva más de cuarenta años viajando por copias y copias del fichero. Quien diga que nunca ha subido a producción con una errata, que tire la primera piedra. El código fuente original que usé como referencia está perfectamente conservado aquí:

Figura 5: DONKEY.BAS en GitHub

Merece la pena abrir el .BAS y leer esos GOTO, esos POKE 106,0 y esos SOUND 37+RND*200,4. Es arqueología pura, y para los amantes del BASIC, un placer visual. 

La migración: de GOTO y POKE a HTML5, Canvas y Web Audio

Lo bonito de un código tan pequeño es que se puede entender entero y replicar su lógica con fidelidad. El programa en BASIC original hace, en esencia, esto:

• Pinta la carretera con dos líneas verticales y una línea central discontinua que se desplaza para dar sensación de avance:
• (`LINE`, `STEP 20`).

• El coche solo tiene dos posiciones X. El truco de cambiar de carril es maravillosamente simple:
• `CX = 252 - CX` (línea 1730).

• El burro aparece en un carril al azar: 
• `DX = 105 + 42*INT(RND*2)` (línea 1700).

• La colisión esta en la línea 1750 con IF que dispara el BOOM! y la animación de fragmentos volando a las esquinas en las líneas 2060-2200.
•  `IF CX=DX AND Y+25>=CY` (línea 1750) 

• Y el sonido, esos pitidos monofónicos del PC speaker, salen de las instrucciones `SOUND`.

Para esta prueba lo reescribí desde cero en HTML5 + CSS + JavaScript puro (Vanilla JS), sin frameworks ni motores de juego pesados, porque la gracia era mantener el espíritu minimalista del original:

• Gráficos: con la API de Canvas, respetando la resolución y la paleta CGA (negro, cian, magenta, blanco), pero con escalado nítido (`image-rendering: pixelated`) para que se vea bien en una pantalla 4K de hoy.

• Sonido: con la Web Audio API, generando ondas cuadradas para emular el PC speaker, un pitido corto al cambiar de carril y una ráfaga aleatoria de tonos para la explosión, calcada del `SOUND 37+RND*200,4`.

• Controles: barra espaciadora para cambiar de carril y Esc para salir, tal cual el original... y, ya puestos a modernizar, soporte táctil para jugar desde el móvil.

Comenté cada bloque del JavaScript indicando qué línea del BASIC original estaba replicando, porque me parecía la mejor forma de honrar el código de Gates y Konzen: no reinventarlo, sino traducirlo.

Figura 6: DONKEY.BAS migrado a Cloudflare Pages

con la estética CGA intacta.

El despliegue: de cero a producción con Cloudflare Pages en minutos

Y aquí es donde, como Account Executive en Cloudflare, no puedo evitar ponerme un poco pesado, porque es justo lo que me enamoró de esta plataforma. Tenía tres ficheros (`index.html`, `style.css`, `game.js`) y quería ponerlos en internet, con HTTPS, en una red global y sin montar ni un solo servidor. Pues bien:

```bash

wrangler login

wrangler pages deploy .

```

Figura 7: Desplegando con Wrangler

Y ya está. Literalmente. Wrangler (el CLI de Cloudflare) subió los ficheros, creó el proyecto y me devolvió una URL de producción servida desde más de 330 ciudades repartidas por el mundo. Sin aprovisionar máquinas, sin configurar un balanceador, sin pelearme con certificados TLS. El juego de Bill Gates de 1981 corriendo en la red perimetral más grande del planeta, gratis y en edge.

Figura 8: DONKEY.BAS  migrado corriendo en la nube de Cloudflare.

Dale al Play y juega.

Para quien prefiera no tocar la terminal, Cloudflare Pages también permite el despliegue por Direct Upload: arrastras la carpeta al panel y listo. O lo conectas a tu repositorio de Git y cada Push despliega solo, con Preview Deployments por cada rama para revisar cambios antes de pasarlos a producción.

¿Y qué tiene esto que ver con modernizar de verdad?

DONKEY.BAS es un juguete, claro. Pero la historia que cuenta es exactamente la misma que vivo con empresas que arrastran aplicaciones de hace veinte o treinta años: hay un core de lógica de negocio valioso atrapado en una tecnología que ya nadie quiere mantener, y el reto no es reescribirlo todo de golpe, sino modernizar la capa de entrega y de ejecución para llevarlo donde están hoy los usuarios.

Y ahí la propuesta de Cloudflare es potentísima, porque no se queda en servir ficheros estáticos:

• Cloudflare Workers: ejecuta tu lógica de backend en JavaScript, TypeScript, Python o Rust (vía WebAssembly) directamente en el edge, con arranques en frío de milisegundos. Olvídate de pensar en servidores o en regiones; tu código corre cerca del usuario, donde esté.

• Cloudlfare Pages + Functions: para frontends modernos con su API integrada, sin coser dos plataformas distintas.

• Almacenamiento y estado en el edge: Workers KV, D1 (SQL), R2 (objetos, sin tarifas de salida) y Durable Objects para coordinación y estado en tiempo real. Tu aplicación heredada puede ir migrando piezas a estos servicios sin un Big Bang.

• Seguridad de serie: WAF, mitigación de DDoS, *bot management* y Zero Trust delante de todo. Modernizar también es poner la seguridad por delante, no como un parche posterior.

• IA en el edge con Workers AI y AI Gateway: por si a ese DONKEY.BAS del futuro queréis ponerle un rival que conduzca solo con IA.

La clave es que puedes hacerlo incremental. Pones Cloudflare delante de tu aplicación actual, empiezas a mover funcionalidad a Workers poco a poco (el patrón strangler fig de toda la vida) y, sin pararlo todo, acabas con una arquitectura distribuida, segura y rápida. Igual que yo no reescribí la lógica de DONKEY.BAS, sino que la trasladé a una plataforma moderna.

Conclusión: cuarenta años después, el burro sigue cruzando

Me hace especial ilusión que un trozo de código de 1981, escrito por dos genios con un IBM PC y muchísimo ingenio, pueda estar hoy en producción en una red global sin tocar un servidor. Es la mejor metáfora que se me ocurre de para qué sirve todo esto: 

La tecnología cambia, pero las buenas ideas —y los buenos cores de negocio— merecen viajar bien.

Si tenéis una aplicación heredada que os da miedo tocar, hablemos. A lo mejor vuestro "DONKEY.BAS" particular está a un `wrangler pages deploy` de tener una segunda vida. Y si solo queréis jugar y esquivar burros como en 1981, también os entiendo perfectamente. Puedes jugar a DONKEY.BAS en Cloudflare aquí.

Que gane el mejor conductor.

Autor: Carlos Luengo,  Senior Account Executive en Cloudflare. 

Contactar con Carlos Luengo

Cómo crear con Víbe Coding código ASM para AMSTRAD CPC 6128. Por si te animas a "sufrir" conmigo el Retro Vibe-Coding.

No, no se me había olvidado postear, ni iba a dejar de lado al "demonio cabrón", solo es que me ha tomado mucho más tiempo de lo que pensaba. Estos días atrás se me ocurrió la idea de hacerme con Vibe-Coding, o mejor dicho, con SPEC-Coding, una serie de utilidades y herramientas a bajo nivel para el AMSTRAD CPC 6128. Quería hacerlas en lenguaje ensamblador para tener más posibilidades de controlar el equipo, y al mismo tiempo más velocidad de ejecución que los programas interpretados por BASIC.

Figura 1: Cómo crear con Víbe Coding código ASM para AMSTRAD CPC 6128.

Por si te animas a "sufrir" conmigo el Retro Vibe-Coding.

Como idea inicial parecía muy sencilla, pero no ha sido así. Ya os dije que cuando estuve probando a hacerme el juego de Light-Cycles de Tron tuve que pelear bastante. Me dio bastantes errores y costó sacarlo adelante, pero después de varias horas, el programa salió. Eso sí, con un poco más de coste que saldría con los lenguajes más comunes como Python, o Rust, o Javascript. 

Figura 2: El Light-Cycles en BASIC

para el AMSTRAD CPC 464/664/6128

En este caso, viendo el tamaño del MS-DOS de 1981 del que os hablé hace poco, quería trabajarlo en ASM, y comenzar con hacer un Diskcopy a bajo nivel, que era una herramienta que todos los amantes del AMSTRAD CPC6128 teníamos siempre a mano. La idea es sencilla, se trataba de construir un analizador de disquetes, y un duplicador que no falle incluso si un sector está defectuoso, añadiendo re-intentos, copiado a bajo nivel, y además incluso, con IA, generar reparaciones de sectores.  Pero primero, con poder duplicar un disquete me daba por satisfecho.

Creando un proceso para hacer Vibe-Coding/Spec-Coding en ASM Z80 para AMSTRAD CPC

Pues no ha sido fácil. Un autentico dolor. Tanto que, después de más de treinta intentos he tenido todos los problemas de especificaciones que pudierais imaginar. Conseguir que se quedará centrado en ASM para el Z80 de AMSTRAD CPC no ha sido fácil, en cada dos o tres iteraciones añadía funciones en ensamblador de otros microprocesadores.  Tampoco ha sido fácil que cuando escribía el código se ciñera al AMSTRAD, y de repente los cargadores los llevaba al BASIC de Sinclair e incluso de Spectrum, haciendo que la compilación fuera un dolor. 

Figura 3: Tutoriales de Z80 Amstrad CPC de Chubiakumas

He estado tentado de leerme los fantásticos tutoriales de Chubiakumas que son una pasada y hacérmelo yo a mano como antaño. Al final, después de varias horas probando una y otra cosa, he conseguido que me funcione bien el proceso, aunque el código aún lo tengo al 1% de lo que quiero construir. Pero si te animas a probarlo tú, y quieres sufrir un rato conmigo, te lo dejo por aquí.

1.- El Prompt para pedir el código

No he utilizado ningún sistema de Spec-Coding todavía, así que sólo conseguir un programa Stand-Alone usando Gemini 3.5 Thinking y DeepSeek v3 DeepThink me ha dado bastantes problemas. Al final, he utilizado un Prompt que acote bien que el código se genere para ese entorno concreto.

Eres un experto programador en Z80 para el ordenador Amstrad CPC6128.

Necesito que generes código ensamblador (Z80) que cumpla estrictamente con las siguientes reglas:

1. **Solo instrucciones estándar Z80** (no usar códigos de operación no documentados ni instrucciones de terceros).

2. **El código debe ejecutarse sin fallos en un Amstrad CPC6128 real** (o emulador fiable como WinAPE, JavaCPC, Caprice).

3. **El programa debe arrancar en ORG &4000**

4. **No debe asumir nada sobre el estado previo del sistema** (inicializar todo lo necesario: modo de pantalla, colores, interrupciones, etc.).

5. **Uso del firmware** – se permite, pero solo llamadas bien documentadas (por ejemplo SCR_SET_MODE &BC0E, TXT_OUTPUT &BB5A, etc.). Si se usa acceso directo a hardware (VRAM, puertos), debe ser correcto para el CPC.

6. **Gestión de errores** – el programa no debe colgar el sistema. Si termina, debe retornar limpiamente (RET) o quedar en un bucle seguro.

7. **Comentarios claros** – cada sección debe explicar qué hace en relación al hardware del CPC (pantalla, memoria de vídeo en &C000, etc.).

8. **Ejemplos de código** – si se pide una tarea concreta (por ejemplo, mostrar texto centrado, dibujar gráficos, leer teclado), el código debe ser autocontenido y funcionar al cargarlo con LOAD y ejecutarlo con CALL &4000.

Antes de escribir el código, comprueba mentalmente:

- Las direcciones de firmware son correctas para el CPC6128.

- La memoria de vídeo en modo 1 es de 16000 bytes, desde &C000 hasta &amd;FE7F.

- El tamaño de la pila es suficiente.

- No se desborda la VRAM (escribir más allá de &FE7F corrompe el sistema).

[TAREA A REALIZAR]

No es un Prompt "perfecto", pero es el que mejores resultados me ha dado en todo el proceso para conseguir que no se me fuera a otros equipos, a otros lenguajes o a otros ensambladores.

2.- Compilación con pasmo

Hay otras alternativas, pero una vez tenía el código ASM generado por Gemini o por DeepSeek, lo he compilado con pasmo en formato BIN usando la cabecera AMSDOS, tal y como podéis ver en la siguiente captura. Nada complicada esta parte.

Figura 4: Compilando con pasmo

Pasmo lo puedes descargar desde la web del proyecto. Yo me he descargado la última versión, la he instalado y ha funcionado a la perfección en mi MacOS última versión, así que no debería darte ningún problema en ningún sitio.

Figura 5: Web del proyecto pasmo

De este proceso te deberá salir el código .BIN de tu programa, que es lo que deberemos llevar al disquete en la fase siguiente.

3.- Creación del disquete

Esta es una fase sencilla, ya que puedes hacer la creación de un disco virtual, usando Amstrad DSK Filesystem Manager. Para ello, crea primero un disquete con "New Disk Image" y luego el código .BIN que tienes que tener comprimido como FICHERO.BIN.ZIP lo arrastras a la parte de arriba a la derecha donde pone "Import to DSK".

Figura 6: Amstrad DSK Filesystem Manager

Cuando tengas el fichero en la lista de archivos de tu DSK, entonces puedes descargarlo con Download DSK file y tendrás tu disquete virtual listo para utilizar en tu emulador.

4.- CPCBOX

Como ya os conté en el otro artículo, yo utilizo CPCBOX para probar estas cosas, así que solo tienes que arrancar el emulador, y seleccionar la imagen de tu disquete virtual en la disquetera, como puedes ver en la captura siguiente.

Figura 7: Cargando el disquete virtual en CPCBOX

Una vez cargado, puedes ver el contenido desde tu AMSTRAD usando CAT - como siempre -, y ver todos tus ficheros y pruebas ahí listados.

Figura 8: Disquete con las pruebas de Vibe-Coding en el emulador

En mi caso, como podéis ver, he estado haciendo bastantes pruebas, y muchas han fallado, pero bueno, al final casi he conseguido tener un método de trabajo que funcione. Para cargar el programa, pidiéndole que cargue el programa a partir de la dirección &4000 (puedes probar a partir de la &1000 que es también típica para códigos binarios en AMSTRAD CPC), pues debes cargarlo en memoria.

Figura 9: Reserva de memoria, carga del binario y ejecuición

Para eso, reservamos memoria, cargamos el binario y mandamos el contador de programa del AMSTRAD a la dirección de carga del código BIN que hemos cargado. Si este no funciona bien, y no hace el RET en el código final, el resultado será que se te cuelga el equipo y hay que apagar y encender. 

Figura 10: El programa en AMS corriendo en el emulador

Esto es otro tipo de equipo al que tenemos hoy en día con la memoria protegida y arquitecturas preemptivas. Aquí el programa puede quedarse con el flujo de programa.

Conclusión

La gracia de todo este proceso, para mí, era poder programar en AMSTRAD CPC haciendo uso del ASM del Z80 porque este era el lenguaje más potente y la forma de hacer los juegos más bonitos de este equipo, pero por desgracia el Vibe-Coding (Spec-Coding) para el Z80 de AMSTRAD CPC aún no está muy logrado, así que hay que remar mucho. Veremos en siguientes versiones, u otros modelos. Si lo pruebas en algún modelo o versión que te funcione a la primera... ¡házmelo saber!

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)  

Vibe Coding en BASIC para AMSTRAD CPC sale (un poco) más caro

¿Qué otra cosa mejor que estar probando Vibe Coding en un sábado por la tarde en las oficinas de Cloudflare en Lisboa para comprobar cuánto de bueno es un modelo programando en BASIC? Sí, eso es lo que quería comprobar. Veréis, hace unos días publiqué el artículo de "Cuánto dinero cuesta hacerte el juego de Light-Cycles de TRON en Workers de Cloudflare usando IA" donde usaba como modelo LLM a Cloud Opus 4.5 para construir el juego de las motos de TRON en TypeScript y poderlo correr en Workers de Cloudflare, y el coste que tuvo hacer ese proyecto fue de 0.5 USD. Regalado.

Figura 1: Vibe Coding en BASIC para AMSTRAD

CPC sale (un poco) más caro

Pero, la pregunta que me rondaba era... ¿sería igual de barato hacerlo en lenguajes menos populares que Python o TypeScript? Ya me he pegado varias veces con el Vibe Coding, y supongo que muchos de vosotros habéis pasado por esa fase donde el código no funciona como quieres, da errores, o directamente una modificación te cuesta la vida. Así que en lenguajes menos "mainsteam" la cosa será peor. Esa era la pregunta con la que me puse a echar un rato ayer sábado. 

Figura 2: El Light Cycles creado en TypeScript con Vibe Coding

Basta con preguntar en cualquier sitio y se ve que Claude programa mejor en Python, JavaScript, TypeScript, y frameworks para tecnologías web, que en el resto de los lenguajes, lo que hace que le cueste un poco más, ¿pero cuánto de más?

Figura 3: Con qué lenguajes programan mejor los modelos de Claude

Para hacer la prueba, quise hacer el mismo juego de Light-Cycles - no está mal como Benchmark - pero en BASIC, así que le pedí un Pormpt, que optimizado por Gemini, es éste que tenéis aquí. Así que, una vez Prompted, se supone que el resto es probar y ver resultados. Primero hice las pruebas con el propio Gemini, así, ligeras, a ver si el código funcionaba bien a la primera, y la verdad es que no hubo suerte.

Figura 4: Prompt par hacer el Light Cycles en AMSTRAD

Además de TypeScript, había hecho una versión pequeña del mismo juego de Tron Light-Cycles con Bash usando Gemini para mi MacOS y me lo había hecho bastante bien y de forma rápida, pero con BASIC le estaba costando.

View this post on Instagram

A post shared by Chema Alonso (@chemaalonso)

Además, cada prueba que quería hacer la tendía que hacer en el emulador, así que el proceso incluía la creación de un disco virtual, usando Amstrad DSK Filesystem Manager.

Figura 6: Amstrad DSK Filesystem Manager

La verdad es que la herramienta funciona de maravilla, pero hay que asegurarse de que el código que subas tenga el formato CRLF para que no se trunque, y que el formato del DSK que crees sea compatible con AMSTRAD, así que hay que hacerlos de, por ejemplo, 40 pistas, 9 sectores, y 512 bytes por sector.  Una vez hecho esto, ya puedes subir el programa al disco, y descargarte una copia del fichero .DSK que luego vamos a poder meter en el emulador. El proceso no es complicado.

Figura 7: Los disquettes de AMSTRAD

Eso sí, por cada cambio que hagas tienes que repetirlo, así que si el Vibe Coding no funciona bien a la primera, pues hay que hacerlo muchas veces. 

Figura 8: Probando, probando, probando en CPCBox

Esto nos lo sabemos ya de cuando con el equipo de Ideas Locas hicimos el BASIC 1.0 Copilot para AMSTRAD CPC 6128 que os conté hace un par de años en la RootedCON.

Figura 9: BASIC 1.0 Copilot para AMSTRAD CPC 6128

En mi caso, una vez construido el DSK, el emulador que utilicé fue el de CPCBox que está online, y puedes cargarle el DSK fácilmente. Además, esta versión la tienes con muchos juegos. Aquí os dejo un vídeo de cómo funciona con los juegos clásicos con los que estuve enredando un rato.

Figura 10: Emulador Online de AMSTRAD CPC 464/664/6128

También con juegos clásicos como el Bombjack o el Ikari Warriors

Pero volviendo a la prueba. Haces el código con OpenCode/Gemini/ChatGPT, generas el DSK usando Amstrad DSK Filesystem Manager y luego cargas el disco en CPCBOX. Una vez allí, CAT para ver el contenido del disco, LOAD para cargar el programa, y RUN para ejecutarlo. Y a jugar. El resultado completo lo tenéis aquí.

Figura 11: El resultado final. El Light-Cycles en BASIC

para el AMSTRAD CPC 464/664/6128

En este caso, después de que Gemini me fallara varias veces, decidí ir a por OpenCode y así podría comparar bien los precios que me costaba hacerlo funcionar. Y el proceso tomó su tiempo. Si os digo que me tiré un par de horas para hacerlo funcionara, os podéis hacer una idea.

Figura 12: Los costes después de 2 horas

Al final dejé algo bastante digno, como podéis ver en el código, pero si miramos los costes que me llevó hacerlo con OpenCode a través del AI Gateway de Cloudflare, podéis ver que en comparación con TypeScript, el coste fue mucho más alto. 

Si he de ser justo, he de decir que también se lo puse difícil, porque Locomotive BASIC y para emuladores, no debe ser lo que más líneas de código tira y lo que más tokens consume. De hecho, creo que debería ser yo de los pocos que estuvieran con eso un sábado por la tarde.

Figura 13: OpenCode con Claude Opus 4.6 "sufriendo"

Eso sí, poder crear juegos para AMSTRAD CPC a golpe de Vibe Coding es mejor que tener que copiar los códigos de la MicroMania como hacíamos en la niñez, que os aseguro que eso sí que tomaba tiempo, hasta que lo tenías fino completo.

Figura 14:"Hacking IA: Jailbreak, Prompt Injection, Hallucinations & Unalignment"

escrito por Chema Alonso con la colaboración de Pablo González, Fran Ramírez, Amador Aparicio, Manuel S. Lemos y José Palanco en 0xWord

Si te interesa la IA y la Ciberseguridad, tienes en este enlace todos los posts, papers y charlas que se han  escrito, citado o publicado en este blog sobre este tema: +300 referencias a papers, posts y talks de Hacking & Security con Inteligencia Artificial.

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)  

BASIC 1.0 Copilot para AMSTRAD CPC 6128

El viernes, a última hora de la tarde, di mi charla en RootedCON que había titulado "Laife gets better", que es un juego de palabras con life + ai, porque cada vez se mete en más partes de nuestra vida. En este caso, quería contar, a través del cine y de proyectos que hemos ido haciendo este año en el equipo de Ideas Locas, cómo la Inteligencia Artificial puede transformar todo, y comencé por mis principios de desarrollador, con 12 años, cuando programaba en BASIC.

Figura 1: BASIC 1.0 Copilot para AMSTRAD CPC 6128

En este caso, la película por la que hay que comenzar es TRON, la película donde los protagonistas son programas que viven aventuras dentro de una CPU de 8 bits, y donde los programadores son sus creadores, sus dioses. Los que les dan vida. Hay que ver eso con los ojos de un niño y no querer ser programador.

Figura 2: Tron

A partir de ahí, me apunté a la academia de mi barrio llamada RUS, y me puse a estudiar informática. Y creo que no he dejado de estudiar informática ni un sólo día, así que fijaos si tuvo impacto en mí esa película. 

Figura 3: Libros para Makers en 0xWord que deberías tener:

Arduino para Hackes: PoCs & Hacks Just For Fun,

Hacking con Drones: Love is in the air &

Raspberry Pi para Hackers & Makers: PoCs & Hacks Just for Fun.

Un día, leyendo el proyecto de un hacker que había conectado una calculadora científica a ChatGPT para aprobar todos los exámenes - os lo dejé en el artículo "Cómo hacerte una calculadora conectada a ChatGPT y aprobar todos los exámenes #Makers", me animé a hacer lo mismo para nuestros Retro-Computers. Al final, en el equipo tenemos grandes makers, y estos proyectos siempre son de los que nos molan. Ya hace años habíamos hecho un proyecto similar, para dotar a Macintosh de almacenamiento infinito en la nube que tenéis en la presentación siguiente, así que porque no hacerlo con ChatGPT.

Figura 4: Presentación "Crazy Ideas: From Brain to Hack"

Pero no íbamos a repetir el experimento, así de sencillo. Había que hacerlo más complejo, que mis chicos makers están acostumbrados a hacer cosas difíciles como "Chucky Alonso", y como yo tenía el recuerdo de mi AMSTRAD CPC 6128, les pedí que lo hiciéramos con él, para tener un BASIC 1.0 Copilot para AMSTRAD CPC 6128.

BASIC 1.0 Copilot para AMSTRAD CPC 6128

Para construirlo, primero hay que conectar a Internet nuestro querido AMSTRAD CPC 6128, y una forma sencilla es cambiarle la disquetera y ponerle un EMULADOR de disquetera de 3" que tiene conexión vía USB. Este gadget lo puedes comprar en Amazon por menos de 40 €. 

Figura 5: Emulador de disquetera de 3" a USB

Una vez que lo tengas ya lo puedes conectar a la Raspberry Pi y darle conexión a Internet para hacer las conexiones a ChatGPT con los prompts que desees. Por ejemplo, que haga un programa que dibuje una espiral gaussiana por pantalla.

Figura 6: Prompt a ChatGPT para pintar una espiral gaussiana

Así que el resto es ajustar todo. Para hacer todas las pruebas y demos, usamos el Emulador de AMSTRAD CPC 6128 de Retro Virtual Machine de Juan Carlos González Amestoy, que era perfecto para esta prueba. Y se creo el siguiente código en BASIC 1.0 como interfaz de BASIC 1.0 Copilot.

Figura 7: BASIC 1.0 Copilot

Como podéis ver, es tan sencillo como pedir un prompt y guardarlo en un fichero de preguntas QSTN.TXT, que se quedará en el disquete. Cuando ejecutamos este programa tenemos un interfaz para escribir los prompts por pantalla, como podéis ver:

Figura 8: Pidiéndole un programa para una espiral de colores

En el emulador no tenemos la conexión directa USB a la Raspberry Pi para hacer el proceso automáticamente con nuestro script en Python, así que hay que sacar el disquete manualmente y volver a cargarlo. Esto es porque el emulador, una vez que carga el disquete hace una copia de su contenido en memoria, por lo que no hay actualizaciones en disco hasta que no se fuerzan con una extracción virtual del mismo.

Figura 9: Emulación de disquetes de 3"

Pero cuando se saca, el script lee el fichero QSTN.TXT, se hace la pregunta a ChatGPT, se obtiene la respuesta y se lee el fichero de respuesta que se llama RSPT.BAS para que sea ejecutable directamente. Así que cuando se carga el disquete de nuevo, continua el programa y podemos listar la respuesta.

Figura 10: BASIC 1.0 Copilot carga la respuesta

Una vez que tenemos la respuesta, podemos ver el código que nos ha generado, y lo siguiente es tan sencillo como ejecutar con nuestro querido RUN, para poder ver la magia en acción.

Figura 11: Espiral en ejecución

Tenéis el proceso completo en este vídeo que os he subido a mi canal Youtube para que podáis verlo funcionar en un par de minutos completo, que es una chulada.

Figura 12: BASIC 1.0 Copilot para AMSTRAD CPC 6128

La inteligencia artificial va a cambiar todo, y hacer estas pruebas con sistemas de nuestra infancia, donde estas cosas eran ciencia-ficción, nos ayuda a comprender un poco mejor el impacto que tiene hoy en todo. Así que más vale que te pongas las pilas porque el nuevo mundo es por aquí.

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)  

¿Me ayudas a buscar a mi profesor de informática? Se llamaba Teo.

Hace ya muchos años, en Agosto de 2013, os conté cómo fueron mis inicios en el mundo de la informática, cuando siendo en niño de solo doce años me apunté a una academia de mi barrio de La Loma en Móstoles que estaba sita en la Calle Barcelona - donde me he criado - y que decía "La informática es el futuro". 

Figura 1: ¿Me ayudas a buscar a mi profesor de informática? Se llamaba Teo.

Como os contaba en ese artículo que llamé "Una aventura de switches, acumuladores y contadores", yo me lo creí y me apunté a programación con es temprana edad. Y allí me encontré con mi  profesor a Teo, del que hace siete años os hablaba de esta forma que os dejo aquí:

"Allí tuve a Teo, un profesor curioso que venía todos los días a clase con un libro de lectura y nos contaba historias, no solo de informática, sino también de ciencia ficción. Entre otras cosas, en los descansos, nos contaba cosas de "IT" de Stephen King - uno de los libros que trajo muchas veces mientras se lo terminaba -, "Caballo de Troya" de J.J. Benitez y de RoboCop, una película que acabaríamos yendo a ver a su estreno en el Cine Capitol de Gran Vía y que me llevaría a conocer el universo Paul Verhoeven en todo su esplendor. Todo eso cuando yo era un niño.

 

Creo que mi paso por esa academia con 12 años me marcó mucho más de lo que yo iba a imaginar en mi vida. Allí comencé programando en BASIC, en ordenadores de los 80, donde había cosas como el Dragon Computer con el que tiré mis primeros programas, o equipos Sinclair, Atari, y por supuesto los famosos AMSTRAD CPC 464. Daría oro por volver atrás en el tiempo y entrar en aquella sala llena de joyas de la historia de la informática hoy en día.

Teo, mi profesor, me sentó conmigo, y se dedicó a explicarme los conceptos básicos de la programación iterativa donde todo se resolvía con tres estructuras básicas de control de flujo: La secuencia, la repetición y la alternativa. Todo era sencillo y divertido y bastaba con poner números de orden a las instrucciones, hacer bucles y aplicar sentencias IF-THEN-ELSE. Por supuesto, teníamos la posibilidad de romper el flujo con las instrucciones GOTO - algo que como cuentan en Microhistorias quedaría muy mal visto por los desarrolladores - y por eso nos recomendaba hacer uso de subrutinas y utilizar GOSUB y RETURN o de las llamadas a funciones."

Teo fue mi primer profesor, el que me dio la bienvenida a la informática, justo un poco antes de que conociera a Rodol, mi amigo, socio y compañeros de aventuras en la informática durante años. Pero fue gracias a Teo que mi primera experiencia con la programación y los ordenadores fuera buena y siguiera enganchado a la tecnología. Tal vez, si me hubiera tocado un mal profesor con esos doce años hubiera generado rechazo a la tecnología y hubiera acabado de pintor, de barnizador o haciendo cualquier otra cosa, que es lo que había en mi barrio. Elegir profesión en la construcción. 

Pero Teo me transmitió buenas cosas. A él le gustaba la tecnología y la ciencia ficción, leer y programar, y siendo tan joven yo aprendí sin querer esas cosas de él. Así que seguí con esa senda. Luego Teo se fue al cabo de un par de años o así, y yo seguí con Beatriz, una profesora que tuve también durante varios años y con la que tuve buena relación siempre. Pero nunca más supe de Teo, y me gustaría poder volverlo a ver y charlar con él un rato.

Así que si conoces a algún Teo que haya vivido en Madrid, que diera clases de informática en una academia de barrio en Móstoles llamada RUS y que tenga alrededor de 50 años años, delgado y con gafas lo recuerdo, ayúdame a buscarlo. Y si no, a ver si hay suerte y la corriente de Internet lleva este mensaje a alguien que sepa quién es Teo y dónde está.

Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)

¿Sabes quién es el culpable de que no tengamos claro cuál fue el primer ordenador personal de la historia? Steve Jobs, pero ésta es toda la historia (Primera Parte)

La controversia de quién fue realmente el primero en diseñar y fabricar el ordenador personal siempre es un debate que está a la orden del día y existen varios candidatos a ese puesto de honor. Pero como la historia la escriben los vencedores, lo cierto es que tenemos una distorsión absoluta de la realidad. De hecho, el culpable es nada más y nada menos que Steve Jobs. Y todo comienza con un artículo escrito en 1980 en el Wall Street Journal.

Figura 1: ¿Sabes quién es el culpable de que no tengamos claro cuál fue el primer
ordenador personal de la historia? Steve Jobs, pero esta es toda la historia
(Primera Parte)

En ese artículo publicado el 13 de agosto de 1980, en el titular aparece con letras grandes “Cuando nosotros inventamos el ordenador personal, creamos un nuevo tipo de bicicleta” (haciendo un símil entre lo común que serán los ordenadores para todo el mundo y que cualquiera los podrá utilizar).

El artículo que confunde la historia

Pero, además, en letra un poco más pequeña, aparecía el texto “Steve Jobs inventó el primer ordenador en 1976 con su socio Steve Wozniak …”, así, sin despeinarse. No nos sorprende la frase ya que conocemos la actitud un poco egoísta de Jobs desde que engañó a Wozniak pagándole menos dinero del que le habían ofrecido a él en Atari para crear un prototipo del juego Breakout, cuando Wozniak fue quién lo fabricó desde cero.

Figura 2: Artículo del WSJ de 1980 con la entrevista a Steve Jobs

Dejando de lado que todo el diseño e implementación del Apple I y el Apple II fue tarea casi exclusiva de Steve Wozniak, y que el periodista parece que no contrastó (¿o sí?) esta información, este artículo apareció justo en el momento adecuado. En 1980 Apple estaba arrasando en todo el mundo con su fantástico Apple II por lo que eran el claro ganador en la carrera por ser el primero en poner un ordenador en la mesa de todos los hogares.

En aquella época no había Internet por lo que el artículo caló mucho más en el gran público debido a la importancia del medio que lo publicó. Pero además este no fue el único, durante la promoción del Apple II y más tarde el Macintosh de Steve Jobs forjó la leyenda de ser el creador del ordenador personal. Y así es como hoy día aún pensamos que Apple (e incluso hay personas que de verdad creen que fue Steve Jobs) inventó el ordenador personal, pero ahora veremos que esto no es así del todo y es más complejo de lo que parece.

Altair 880

Siempre que se habla de cual fue el primer ordenador doméstico aparece a la palestra el famoso Altair 8800. Este kit creado por la empresa MITS apareció en el mercado en enero de 1975. Había que soldar (aunque se vendía también ya montado por un poco más de dólares) los componentes y luego no tenía ni teclado ni ratón. Los datos se introducían en bloques en código binario para configurar las instrucciones código máquina utilizando varios interruptores.

El microprocesador que integraba era el mítico Intel 8080 de 8 bits, y el Altair tenía como configuración base 64KB de memoria RAM y 16KB de ROM y se ejecutaba a una velocidad de reloj de 2MHz.

Figura 3: Altair 8800

Pero lo que lo hizo más popular (aparte de su precio como ahora veremos) fueron los dos puertos de entrada y salida que tenía lo que le permitía conectar cualquier tipo de dispositivo externo. Es más, casi podríamos considerarlo el primer dispositivo IoT doméstico.

El precio era asequible para la época, unos 439$ sin montar y otros 621$ ya montado. Además, Bill Gates desarrolló el programa BASIC para este ordenador dándole aún más popularidad. Como curiosidad, el nombre Altair lo puso la hija de Les Solomon, uno de los editores de la revista Popular Electronics, que le dijo “¿Por qué no le llamas Altair? Es donde irá esta noche la nave Enterprise (Star Trek)”.

Figura 4: Portada de la revista Popular Electronics con el Altair 8800

No vamos a quitarle mérito al Altair ya que fue una gran ayuda para impulsar el concepto de los ordenadores dentro de los hogares. Pero no era un ordenador del todo revolucionario teniendo en cuenta otras máquinas que ya estaban a la venta por esa misma época o incluso antes que tenían mejores características técnicas.

Datapoint

Y el mejor ejemplo lo tenemos en el ordenador creado por la empresa Datapoint. Esta compañía fue creada en julio de 1968 por un par de ingenieros tejanos que trabajaban para la NASA. En 1970 sacaron al mercado el que posiblemente sea el primer ordenador personal de la historia y el abuelo de todos los que vendrían después: el Datapoint 2200.

Este ordenador incluía monitor, teclado e incluso impresora. Pero lo revolucionario estaba en su interior, en su diseño electrónico. Y es justo en este punto donde Datapoint se cruza con otro grande de la industria, que hasta ese momento no era más que una startup, nada menos que la empresa Intel.

El ordenador Datapoint 2200 se basaba principalmente en registros de desplazamientos creados con biestables y por lo tanto necesitaban encontrar una empresa que fabricara los chips que pudieran contener estos elementos usando un diseño propio. Hay que tener en cuenta que por aquella época no existía el microprocesador como tal ni los chips de memoria RAM (ambos llegaron dos años después).

Así que se pusieron en contacto con esa pequeña empresa llamada Intel para ver si les podrían fabricar los chips que necesitaban. Pero además le entregaron un diseño un tanto revolucionario el cual incluía en un solo chip todos los registros de desplazamiento además de conceptos de diseño como pila, saltos condicionales, operaciones lógicas y aritméticas … sí, un microprocesador en toda regla, dos años antes de salir al mercado (casualmente, fabricado por Intel).

Figura 5: Datapoint 2200

Intel comenzó a crear un prototipo de este microprocesador que finalmente tendría el nombre de 1201 pero tuvieron muchos problemas para implementarlo ya que la tecnología utilizada, PMOS, aún no estaba perfeccionada del todo. Los tiempos de entrega se retrasaban una y otra vez hasta que finalmente Datapoint optó por no esperar más. Directamente fabricaron ellos su propio procesador utilizando chips tipo TTL, 120 en total. Y es aquí donde aparece una gran proeza de la ingeniería ya que los ingenieros Poor, Schmidt y Pyle de Datapoint crearon una CPU desde cero sentando las bases de los futuros microprocesadores que aparecerían más adelante.

Pero ¿qué paso con Intel? Pues ellos antes de conocer a Datapoint estaban trabajando en una especie de microprocesador llamado 4004 aunque su diseño estaba orientado más bien para calculadoras (no permitía utilizar por ejemplo caracteres alfanuméricos).

Figura 6: El chip Intel 4004

Cuando desde Datapoint ya no contactaron con ellos para que fabricaran el microprocesador que les habían solicitado, ellos siguieron adelante con el proyecto utilizando parte de las ideas aportadas por los ingenieros de Datapoint y finalmente fabricaron el que sería el padre de todos los microprocesadores: el Intel 8008. El siguiente modelo de este chip fue el Intel 8080 ¿os suena el nombre? pues sí, es el mismo que más tarde utilizaría la empresa MITS para fabricar el Altair.

Por lo tanto, la empresa Datapoint no sólo creó el primer ordenador, sino que también influenciaron aportando las bases de lo que sería el microprocesador que luego daría potencia al resto de ordenadores de la época. Como curiosidad, para que veáis el gran diseño creado por los ingenieros de Datapoint a la hora de crear su microprocesador, este era compatible a nivel de código hasta el Intel 8080.

Figura 7: Placa "procesador" del Datapoint 2200, base del futuro 8080 de Intel

Es decir, los programas para el 8080 se podían ejecutar en el Datapoint 2200 y los modelos superiores. Pero ¿cómo pudo Intel “copiar” el diseño de Datapoint en sus futuros microprocesadores? Realmente no fue una copia sino un acuerdo que mezclaba ideas de ambas compañías. Intel ya tenía experiencia creando el 4004 y Datapoint contribuyó añadiendo componentes de diseño como el concepto de registro y otros que hemos comentando antes. En este enlace tienes más datos sobre Datapoint y su diseño.

Pero aún queda más que decir en esta historia, que veremos en la segunda parte....

Autor: Fran Ramírez, (@cyberhadesblog) miembro del equipo de Crazy Ideas en CDO en Telefónica, autor del libro "Microhistorias: Anécdotas y Curiosidades de la historia de la informática (y los hackers)", del libro "Docker: SecDevOps" y del blog Cyberhades.