Programando como si fuera 1982. Parte I - Los 80, el Commodore 64 y por qué importa

Cuando entré en la industria tecnológica, en la segunda mitad de los años 2010, los lenguajes de alto nivel ya eran el estándar. Cuando estudié Ingeniería Informática, incluso los sistemas embebidos se escribían en C++, y eso era considerado el nivel más bajo. En el mundo del software y los videojuegos, la abstracción iba todavía más lejos. Java dominaba la industria, y Unity estaba en pleno proceso de democratizar el desarrollo de juegos hasta el punto en que cualquier persona con un fin de semana libre podía publicar algo jugable.

Pero hubo una época en la que los programadores no tenían ese lujo. Sin capas, sin redes de seguridad. Trabajabas directamente sobre el hardware, al nivel más bajo posible, eligiendo la dirección exacta de memoria donde escribir y la instrucción exacta que el procesador debía ejecutar.

Como alguien nacido a principios de los 90, en la cola de la generación Millennial, crecí con PCs, que ya eran el estándar establecido cuando llegué. No sabía nada de lo que había antes. Nombres como Atari ST, Apple II, Commodore Amiga, ZX Spectrum eran cosas que podía situar vagamente en los años 80, pero no habría podido distinguirlos si los hubieran puesto en fila delante de mí. Mi primer ordenador fue una máquina de principios de los 2000 con Windows 98 y un asombroso disco duro de 512 MB. No recuerdo todas las especificaciones, pero sé que ya era obsoleto en aquella época, una donación, máquinas descartadas por el club de fútbol local. Esa fue mi infancia tecnológica. Durante mucho tiempo, eso era la retrocomputación para mí.

No fue hasta 2021, a través del podcast brasileño “Primeiro Contato”, que descubrí el viejo nuevo mundo de la retrocomputación y los microsistemas. El podcast, producido y narrado magistralmente por Henrique Sampaio, cuenta la historia de cómo llegaron los ordenadores y el internet a Brasil. Dejando de lado el contexto específicamente brasileño, no podía dejar de imaginar lo que debía sentirse vivir los años 80 como programador. Esa mezcla particular de curiosidad y programación byte a byte, sin ninguna abstracción que te protegiera si resbalabas, me fascinó de verdad.

Con ese humilde bagaje, propongo una serie de posts llamada “Programando como si fuera 1982”, para explicarle a los rezagados como yo cómo funcionaba la programación hace 44 años.

El estado de la informática en 1982

Los primeros años 80 fueron el momento en que los ordenadores salieron de los centros de investigación y llegaron a los salones. Cajas de plástico conectadas al televisor familiar, vendidas en tiendas de electrónica junto a radios y electrodomésticos. Los que estuvieron allí lo describen como estar en medio de algo completamente nuevo, sin ninguna certeza de adónde iba todo aquello.

El mercado explotó, pero estaba completamente fragmentado. Decenas de fabricantes lanzaron máquinas incompatibles entre sí. Atari, Apple II, ZX Spectrum, TRS-80. Cada uno con su propio procesador, su propia arquitectura, su propio ecosistema. El IBM PC acababa de lanzarse, pero todavía era un sistema empresarial que tardaría años en alcanzar la adopción masiva a través de sus clones. Esa es una historia para otro momento.

El software llegaba en cintas de casete o disquetes, comprados en tiendas o copiados en casa de un amigo. Y luego estaban las revistas. Las publicaciones de microordenadores eran los centros neurálgicos de los entusiastas de la época, y era completamente normal que sus páginas estuvieran llenas de nada más que código fuente, impreso para que el lector lo copiara línea por línea en casa. Ese tipo de ejercicio, que hoy suena tedioso y dolorosamente manual, es uno de los ingredientes clave de la nostalgia que llevan consigo las personas que vivieron aquel período. Soy un poco envidioso de eso, honestamente.

El Commodore 64

En ese escenario, en agosto de 1982, Commodore Business Machines lanzó el ordenador que se convertiría en el modelo más vendido de la historia. El nombre lo decía todo. Commodore 64, sí, 64 kilobytes de RAM. En una época en la que los competidores vendían máquinas con 16 o 48 KB, ese número significaba algo. El precio de lanzamiento era de 595 dólares, caro para el consumidor medio, pero barato para un ordenador personal. En pocos meses, Commodore recortó los precios de forma agresiva y sacó del mercado a gran parte de la competencia. Se estima que entre 12 y 17 millones de unidades se vendieron a lo largo de su vida útil, un récord que se mantiene hasta hoy para un único modelo de ordenador.

Pero lo que hacía especial al C64 no era solo el precio o la memoria. Era el hardware de su interior. Mientras los competidores ofrecían vídeo y sonido básicos, el C64 venía con tres chips desarrollados internamente en Commodore, cada uno excepcional para su época.

El MOS 6510 era el procesador, una evolución del legendario 6502, funcionando a 1 MHz, simple y documentado hasta el último bit. El VIC-II era el chip de vídeo, capaz de mostrar 16 colores, mover hasta 8 sprites independientes en pantalla, producir scroll suave y generar efectos que otros ordenadores de la época simplemente no podían replicar. Y el SID era el chip de sonido, un sintetizador completo con 3 voces independientes, formas de onda programables, filtros y envolventes de amplitud. Tan sofisticado que décadas después los músicos seguían buscando chips originales para hacer música. El SID no sonaba como un ordenador de 8 bits. Sonaba como un instrumento de verdad.

No había ningún sistema operativo protegiéndolo todo. Sin excepciones, sin mensajes de error amigables. Si escribías en la dirección equivocada, el ordenador se colgaba o se comportaba de forma impredecible, y tú mismo tenías que encontrar el problema. A cambio de eso, tenías control total. Ninguna capa entre tu código y la máquina.

BASIC y Assembly

Cuando el C64 arrancaba, lo primero que veías era un cursor parpadeante y el mensaje READY. Era el prompt de BASIC, el lenguaje grabado en la ROM del ordenador, listo para usar sin instalar nada.

BASIC son las siglas de Beginner’s All-purpose Symbolic Instruction Code. Fue diseñado para ser lo suficientemente sencillo para cualquier persona, sin formación técnica necesaria. Escribías directamente en el teclado y veías el resultado al instante. Los niños lo aprendían en los colegios. Las revistas publicaban programas para que los lectores los copiaran. Padres e hijos lo exploraban juntos. El BASIC fue el responsable de democratizar la programación en los años 80, y muchos de los que más tarde dominaron el assembly y C empezaron escribiendo PRINT "HELLO" en un teclado de goma en el salón de su casa.

El problema era exactamente uno, y era la velocidad. El BASIC del C64 era interpretado, lo que significa que cada vez que se ejecutaba un programa, cada línea era leída, traducida y ejecutada en el momento, una a una. Esa traducción en tiempo real consumía la mayor parte de la potencia del procesador. Un bucle simple en BASIC se ejecutaba unas 1.000 veces por segundo. El mismo bucle en assembly se ejecutaba 1.000.000 de veces por segundo. Una diferencia de 1.000x.

Para un juego que necesitaba mover sprites, detectar colisiones, reproducir música y responder al joystick, todo dentro de 1/50 de segundo por fotograma (en las máquinas europeas con estándar PAL), el BASIC no era suficientemente rápido. Era válido para cálculos simples, utilidades y para aprender los fundamentos. Para juegos y demos, era un callejón sin salida.

El assembly era lo opuesto al BASIC en casi todo. Donde el BASIC se traducía en tiempo de ejecución, el assembly se traducía previamente mediante un programa llamado ensamblador. El resultado era código máquina puro, bytes que el procesador ejecutaba directamente, sin intermediario. Sin capa de interpretación. Cada instrucción que escribías se convertía en exactamente uno o pocos bytes en memoria, ejecutados sin ningún overhead.

La ganancia era obvia pero el coste era real. Obtenías toda la velocidad de la máquina, y renunciabas a toda la comodidad que ofrecía el BASIC. Sin PRINT automático, sin variables con nombre, sin FOR o IF listos para usar. Controlabas cada registro, cada byte de memoria, cada ciclo de reloj. Tedioso y granular. Pero era la única forma de hacer que el hardware entregara todo lo que era capaz.

En la práctica, los dos mundos coexistían. Muchos programadores escribían la estructura principal en BASIC y llamaban a rutinas en assembly solo en las partes que exigían velocidad. Pragmático, no ideológico.

No había Stack Overflow. Ningún tutorial en YouTube. Ningún curso online. Había revistas. Las publicaciones imprimían código en sus páginas, y el lector tecleaba cada línea a mano en el teclado del C64, rezando para no equivocarse ni un solo carácter. Los manuales de hardware eran los textos sagrados. El Commodore 64 Programmer’s Reference Guide, un ladrillo de 493 páginas, describía cada registro de cada chip, cada dirección de memoria, cada opcode del procesador. Dominar ese libro era dominar la máquina. Completamente.

Por qué estudiar esto hoy

Puedes pasar toda una carrera en Python o JavaScript sin pensar ni una vez en registros, y está perfectamente bien. Ese es el objetivo de las abstracciones modernas. Funcionan, y te dejan concentrarte en construir cosas en lugar de gestionar memoria manualmente.

Pero hay momentos en que el suelo desaparece y necesitas entender qué hay debajo. Cuando un sistema debe responder en microsegundos, ya sea en trading de alta frecuencia, procesamiento de señales o juegos con física compleja, saber cómo funciona realmente el hardware deja de ser opcional. Los microcontroladores en electrodomésticos, coches y equipos médicos todavía se programan cerca del metal, y la lógica de un Arduino es descendiente directo de lo que cubriremos en esta serie. Las vulnerabilidades como el buffer overflow existen porque el código de alto nivel eventualmente se convierte en bytes en memoria, y la memoria no tiene opinión sobre lo que haces con ella. Las personas que entienden este nivel comprenden por qué existen estas vulnerabilidades, no solo cómo parchearlas.

También hay algo más difícil de cuantificar. Hay una diferencia entre saber usar una herramienta y entender cómo funciona. Un compilador no es magia, es una transformación sistemática de texto en instrucciones máquina. Un sistema operativo no es un misterio, es un programa que gestiona memoria, tiempo de CPU y acceso al hardware. Las personas que han programado cerca del metal lo ven con claridad, porque un día hicieron ese trabajo a mano.

El C64 es un punto de partida ideal precisamente porque su procesador tiene un conjunto de instrucciones pequeño, aproximadamente 56 instrucciones en total, frente a las cientos de un x86 moderno. Puedes aprender toda la arquitectura en pocas semanas. El hardware está mapeado directamente en memoria, así que la relación entre código y efecto es inmediata. Escribe un byte y la pantalla cambia, un sonido suena, un sprite se mueve. No hay nada escondido. Y existen emuladores precisos y gratuitos disponibles hoy, como VICE, que permiten ejecutar y depurar código del C64 en cualquier ordenador moderno.

En los próximos posts descenderemos por esta pila de abstracciones. No para descartar lo que ya sabes, sino para entender de dónde vino. Aprenderemos cómo el procesador almacena datos, cómo se organiza la memoria, cómo se ejecutan las instrucciones, cómo se toman decisiones y cómo escribir en una dirección puede hacer sonar una nota musical o mover un sprite por la pantalla. En el lenguaje de alguien que programa de verdad, sin misticismos.

Edit, 9 de mayo de 2026. Esta serie asume una familiaridad mínima con la programación. Variables, bucles, condicionales, alguna estructura de datos básica. Si tienes más experiencia, algunos posts te parecerán demasiado básicos. Es intencional. El objetivo siempre fue hacer el contenido accesible para quien tenga curiosidad, no solo para quienes tienen formación en ciencias de la computación.