LOS CARGADORES DE VIDAS INFINITAS
CUANDO HACER TRAMPA ERA UN TRABAJO SERIO
Nada más empezar te mataban. Una y otra vez. El juego no te daba ni un respiro, la segunda pantalla era una quimera inalcanzable, y ya estabas a punto de mandar el joystick a paseo. La desesperación era total. Y entonces, hojeando tu revista de cabecera, entre análisis y mapas, aparecía la solución. Escrita en negro sobre blanco. Sin rodeos.
Vidas infinitas.
Eso sí, lo que te esperaba en esa página no era exactamente lo que uno esperaría de un "truco". Era una columna interminable de números. Líneas y líneas de BASIC llenas de valores separados por comas que, si las mirabas por encima, parecían el delirio de alguien que llevaba demasiadas horas delante de la pantalla.
Pero ahí estaba. Y tú ibas a teclearlo entero aunque te llevara la tarde.
Lo que mucha gente no sabe es que esos listados no eran simples códigos mágicos. Eran programas reales que hacían algo muy concreto: meterse en la memoria del C64 antes de que lo hiciera el juego.
Los más sencillos funcionaban así: se instalaban en el bloque de memoria que el C64 reservaba para BASIC, hacían un POKE — escribían directamente en la dirección donde el juego guardaba el contador de vidas — y cuando el juego miraba cuántas te quedaban, encontraba siempre el mismo número. Como cambiarle el marcador a un árbitro antes de que salga al campo.
guarda las vidas
= ignorar instrucción
nunca baja
Los más avanzados eran otra historia. Se colaban en zonas de memoria que el juego no iba a tocar — a veces en la página cero, los primeros 256 bytes del sistema, reservados normalmente para el propio procesador — y desde ahí reemplazaban parte de la rutina de carga del C64. Pillaban el código del juego mientras llegaba desde la cinta y lo parcheaban al vuelo, antes incluso de que se ejecutara. Básicamente le cambiaban las entrañas en plena operación.
Por eso los listados tenían esas líneas interminables de DATA llenas de números. No eran datos cualquiera: eran instrucciones en código máquina, bytes de ensamblador traducidos a decimal para poder vivir dentro de un programa BASIC. Los autores — colaboradores de Micromanía, gente que se pasaba horas desensamblando juegos — localizaban en memoria exactamente dónde se guardaban las vidas y construían una rutina para congelarlas. Luego lo publicaban en la revista. Y tú lo tecleabas.
Carácter a carácter.
Un número mal puesto y el programa no funcionaba. O funcionaba a medias, que era peor: el juego arrancaba, la música sonaba, y en la primera muerte... las vidas seguían bajando. Como si nada. Ahí te quedabas, mirando la pantalla, sin saber si el error era tuyo, del listado, o si simplemente la vida era injusta.
Cuando todo salía bien, cuando el cargador funcionaba y las vidas se quedaban congeladas en pantalla, la sensación no era exactamente de haber hecho trampa. Era otra cosa. Habías tecleado código que no entendías del todo, habías corregido errores a ciegas, habías esperado la carga con los dedos cruzados... y el juego había cedido.
No era trampa. Era una negociación con la máquina.
Y esa vez, la máquina había perdido.
PARA NO TRABAJAR DENTRO DEL JUEGO
Nadie nos enseñó programación. Nadie nos explicó qué era el ensamblador. Pero copiábamos líneas de DATA de una revista, las poníamos en su sitio, ejecutábamos el programa y el juego hacía lo que queríamos.
Eso, aunque no lo supiéramos entonces, era hackear. Y lo aprendimos solos, número a número, con doce años y un joystick roto.
► LO QUE DABA
Vidas infinitas (cuando funcionaba)Primera lección de programación real
Satisfacción absoluta al conseguirlo
Sensación de control total sobre el juego
Estatus en el patio del colegio
► LO QUE COSTABA
Un error = todo para empezarA medias podía ser peor que sin él
El juego podía no funcionar en absoluto
La duda permanente: ¿fui yo o el listado?