Con el blog y el libro “Programación Retro del Commodore 64” hemos aprendido:

• Herramientas modernas para trabajar con el C64 (VICE y CBM prg Studio).
• Los sistemas de numeración decimal, hexadecimal y binario.
• El hardware del C64.
• El mapa de memoria.
• La programación en ensamblador del 6510.
• Las rutinas del Kernal.
• La programación de gráficos con el VIC.
• La programación de música y sonido con el SID.
• La programación de entrada/salida con los CIAs.

Todo ello con muchos ejemplos de código en ensamblador descargables del blog.

Pues bien, la continuación natural de este trabajo sería desarrollar uno o varios proyectos en ensamblador. Y, lógicamente, cuando hablamos de “proyectos” para el C64 esto viene a ser sinónimo de “juegos”, aunque Commodore vendía el C64 como una máquina de propósito general para el hogar.

Así pues, nos disponemos a desarrollar uno o varios juegos en ensamblador. Hasta que el cuerpo aguante. No sé si llegaremos a uno, dos, tres, o los que sean. Lógicamente, deberían tener enfoques diferentes y complejidades crecientes.

Y no sólo desarrollarlos; sobre todo explicarlos. Ese quiero que sea el elemento diferenciador: explicar cómo se desarrollan y cómo funcionan.

Por tanto, el objetivo no va a ser desarrollar el mejor juego. Ya hay muchísimos juegos para el C64 y no veo posible superar eso. Tampoco hacer unos gráficos o una música estupendos; no creo que lo consiguiera. Ni migrar aquel juego de Spectrum que me encantaba y que nunca llego a salir para Commodore.

El objetivo será triple: explicar, explicar y explicar.

Por ello, cuando tengamos que elegir entre optimización o claridad, salvo que no quede otra alternativa, la cuestión está zanjada: claridad.

A ello vamos…