Nuevo libro: Programación Retro del Commodore 64 Volumen II

Como os anunciaba hace unos días, acaba de publicarse en Amazon el nuevo libro “Programación Retro del Commodore 64 Volumen II”:

Portada ppal Volumen II

Son 230 páginas con el contenido que hemos tratado en el blog durante los últimos meses (de agosto a noviembre), es decir:

  • El enfoque de desarrollo incremental.
  • El uso de herramientas y librerías de desarrollo actuales.
  • La estructura del proyecto.
  • El diseño y movimiento de sprites.
  • Los caracteres personalizados.
  • Los bitmaps.
  • La lectura del joystick y el teclado.
  • El bucle de juego, con sus inicializaciones y actualizaciones.
  • La nave, los asteroides y los disparos.
  • La detección de colisiones y la animación de explosiones.
  • Los niveles de dificultad progresivos.
  • Las pantallas de inicio, de juego, y de fin.
  • El sonido con el SID.
  • La presentación de números en decimal.

Y todo con la idea de inspirar y ayudar a quien quiera animarse a hacer sus propios proyectos con esa maravillosa máquina que es el C64.

El libro está disponible en los principales portales de Amazon:

Espero que al menos guste tanto como el primer volumen 🙂 .

Un par de películas interesantes

Me pregunta un lector cómo hacían los chavales de los 80 para aprender a programar el C64 y desarrollar aquellos juegos.

Ya comentaba al comienzo del blog que, al menos en la España de los 80, circulaba poca información. Había algunos libros y algunas revistas. De los primeros, me gustaban los libros blancos y rojos de Data Becker, y de las segundas “Commodore World” y “Commodore Magazine”. Por supuesto, no existía Internet, aunque empezaba a haber algunos servicios en línea (las famosas BBS’s).

Información 80.PNG

En Estados Unidos, Reino Unido y Alemania sí había más información. Si buscáis en Archive.org encontraréis bastantes libros en inglés de aquella época. Aun así, la informática, o al menos la informática personal, estaba en sus comienzos también allí.

Entonces… ¿cómo aprendían los chavales? Pues básicamente eran autodidactas. Suplían la falta de formación e información con muchas ganas, mucho ingenio y muchas horas de dedicación.

Hay un documental que describe este proceso en el caso del Reino Unido: “From bedrooms to billions” (2014). No he conseguido localizarla en las plataformas de streaming habituales (Netflix, Amazon, Movistar, etc.), pero sí he localizado una página web que parece específica de la película:

https://frombedroomstobillions.com/

También relacionada con el C64, aunque no específicamente con el tema de los jóvenes programadores, hay otra película que me gusta: “The Commodore Story” (2018). Se trata de otro documental que revisa la historia de Commodore en general. Incluye muchas entrevistas a los protagonistas de aquella época, incluyendo al hijo de Jack Tramiel y los ingenieros que diseñaron muchos de sus equipos.

Nuevamente, no la he encontrado en las plataformas de streaming habituales, pero sí he localizado esta página:

https://thecommodorestory.com/

¡¡Que las disfrutéis!!

Documentales.PNG

Futuro

En su momento hablamos de desarrollar varios juegos con enfoques diferentes, complejidades crecientes, etc. Pero después de más de 50 entradas, 23 versiones del proyecto, y 200 páginas de contenido, se hacen aconsejables una parada y reflexión.

Hay un autor canadiense llamado Alexander K. Dewdney que en los 80 escribía en Scientific American sobre informática y matemáticas. Sus artículos me gustaban mucho, porque tenían un planteamiento abstracto y, en general, no acababa de resolver completamente los problemas que planteaba, dejando ese reto al lector.

En su día –y habrán pasado más de 30 años– leí un artículo suyo sobre cómo desarrollar un juego de damas, o juegos de tablero en general, que me dejó muy prendado. Quién sabe, quizás me anime con el reto 30 años después y con un C64…

HVSW.

Asteroids: conclusiones

A lo largo de unas 50 entradas y 23 versiones del proyecto, hemos desarrollado paso a paso un juego clásico en ensamblador.

Las principales conclusiones que saco del proceso son:

  • No es suficiente con saber ensamblador del 6510. Además, hay que dominar el mapa de memoria y el hardware del C64. Un buen conocimiento de los chips especiales (VIC, SID y CIAs) es fundamental. Y también del Kernal, aunque no tanto.
  • Es muy importante que el proceso de desarrollo sea paso a paso o incremental. Hay que empezar por lo más sencillo y nuclear, e ir completándolo poco a poco. No parece viable obtener un producto completo de forma directa, especialmente si es complejo.
  • Interesa usar herramientas modernas como CMB prg Studio y VICE. Ni me quiero imaginar cómo podría ser la tarea si se intentara directamente sobre un C64.
  • Disponer de unas librerías de programación para sprites, sonido, entrada / salida, etc., también es muy importante para ser eficientes. Si el programador no dispone de ellas, siempre puede desarrollarlas y mejorarlas con cada juego.
  • Hay que plantearse retos asumibles. Y luego ir subiendo el listón. No vamos a sacar “Uridium” a la primera.
  • El código tiene que estar debidamente estructurado. No podemos tener un único fichero “asm”. Tiene que haber varios ficheros, y estos tiene que ser autocontenidos. Como decían los clásicos “alta cohesión y bajo acomplamiento”.
  • Los juegos suelen tener una inicialización y una actualización. La inicialización es el código que prepara el juego; por tanto, se ejecuta una vez. La actualización es el código que se ejecuta en cada ciclo del bucle de juego. Se utiliza para leer joystick y/o teclado, actualizar posiciones, disparar, detectar colisiones, hacer animaciones, reproducir sonido, etc.
  • El concepto de bucle de juego es muy importante también. El bucle de juego es la ejecución de las actualizaciones. Se ejecuta repetitivamente hasta que el juego termina. Hay tareas que se pueden ejecutar completas en cada ciclo, y otras tareas que hay que ejecutarlas a lo largo de varios ciclos porque, si las ejecutáramos en un único ciclo, serían imperceptibles o para hacerlas perceptibles dejarían el juego “enganchado”.
  • El ensamblador es tan rápido que hay tareas que, para que se puedan hacer bajo control, tienen que ser ralentizadas. Algunos ejemplos son los movimientos de la nave o los disparos. Esta ralentización se suele hacer mediante un “retardo”.
  • Es mejor hacer las cosas bien desde el principio, que corregir los errores en una fase tardía del proyecto, cuando el diseño ya está muy avanzado. No obstante, somos humanos y nos equivocaremos. Al menos, aprendamos de los errores.
  • Salvo que venga muy a cuento, no pongáis información en la zona derecha de la pantalla. Dejad que los sprites se muevan en libertad.
  • Tenemos sprites, caracteres personalizados y bitmaps. Cada cosa tiene su uso. Los sprites son limitados, sólo tenemos ocho. Hay que hacer un uso razonable de los recursos.
  • Las fórmulas matemáticas son un horror en ensamblador. Es mucho más sencillo usar tablas de datos. Y CBM prg Studio tiene un “data generator”.
  • Os encontraréis situaciones imprevistas como letras que desaparecen de la pantalla, asteroides que siempre se expanden, programas que se cuelgan, explosiones inesperadas, etc. Hay que estar preparado para ellas e investigarlas. Esto os consumirá mucho tiempo y esfuerzo.
  • Con frecuencia lo perfecto es enemigo de lo bueno. Quizás los disparos podrían estar más centrados respecto a la nave, pero, ¿cuánto me costaría hacerlo perfecto? Si la nave mirara siempre en la misma dirección podría resolverlo con relativa facilidad, pero admite ocho direcciones. ¿Estoy dispuesto a asumir el coste de hacerlo perfecto? ¿Hay alguna solución subóptima?
  • Es importante reutilizar ideas e intentar ser coherentes en los diseños. Si los asteroides son una mezcla entre la nave y los disparos, porque son sprites como la nave, pero los hay activos e inactivos como los disparos, pues no reinventemos la rueda.
  • Es interesante meter niveles de dificultad progresivos. Hay recursos para generar información pseudoaletoria (relojes del sistema).
  • La detección de colisiones, ya sea sprite – sprite o sprite – texto no es sencilla. Con frecuencia implicará el uso de las posiciones para averiguar con precisión quién choca con qué.
  • La animación de explosiones, igual que la reproducción del sonido, son ejemplos típicos de tareas que interesa extender a lo largo de varios ciclos del bucle de juego.
  • Los juegos no sólo tienen la pantalla de juego (la obvia). También tienen pantallas de carga, pantallas finales, pantallas de puntuación y records, etc. Diseñar las diferentes pantallas es fácil, pero la correcta transición entre ellas puede tener algo más de miga.
  • Lo normal es que los juegos se puedan jugar varias veces seguidas en una “sesión de partidas”. Cuidado con las inicializaciones en este caso, especialmente si confías en la inicialización implícita de las variables mediante directivas “byte” y similares.
  • El SID es complejillo. El manejo de librerías simplifica mucho. Y el uso de tablas para separar música o sonido de programación también.
  • A los humanos nos gustan los números en base diez. La solución obvia, que sería usar codificación y aritmética BCD, no siempre es viable. Siempre está la opción de usar codificación y aritmética binarias, y convertir a BCD antes de imprimir los datos.
  • A programar se aprende programando, y sufriendo en tus carnes los errores. Y disfrutando mucho con el proceso y el resultado, claro.

Así que, lo dicho, espero que hayáis disfrutado mucho del proceso y, sobre todo, que os sirva de inspiración para vuestros propios proyectos.

Asteroids: mapa de memoria y librerías mejoradas

La versión final del proyecto, que es la versión 23, tiene esta distribución en memoria. Nos la da CBM prg Studio al ensamblar:

Asteroids - Asteroids mapa memoria.PNG

Es decir, el juego consta de cinco segmentos de memoria:

  • $0801 – $080c, 12 bytes: Este es el cargador BASIC.
  • $0810 – $1be2, 5.075 bytes: Este es el grueso del juego, librerías incluidas.
  • $3000 – $32ff, 768 bytes: Es la definición de los 12 “frames” para los sprites.
  • $3800 – $4fcf, 6.096 bytes: Son los caracteres personalizados (4 KB) y las pantallas (2 x 1 KB).
  • $c000 – $c094, 149 bytes: Es un programa de prueba para probar la conversión de codificación binaria a BCD. Se podría quitar del proyecto.

En definitiva, vemos como un juego sencillo ya casi ocupa 12 KB. Por supuesto, se podría reducir un poco, por ejemplo, sustituyendo la pantalla de juego (1 KB) por la impresión de una simple línea, quitando librerías o rutinas de librería que no se utilizan, o replanteando el uso de los caracteres personalizados (4 KB).

Pero la idea subyacente es la misma: el C64 tiene muy poca memoria (64 KB, con partes de RAM y ROM solapadas), y para hacer virguerías hay que echarle mucho ingenio, y jugar con los diferentes mapas de memoria posibles. Aquí hemos utilizado el mapa estándar.

Por lo demás, durante el proceso no sólo hemos desarrollado un juego. También hemos mejorado unas librerías. Partíamos de las librerías disponibles aquí. Y, como parte del proceso, hemos mejorado las siguientes librerías:

Librería Rutina / variable Mejora
LibChars.asm configuraColores Admite color del borde
LibSprites.asm posicionaSprite Admite coordenada X de 9 bits
  configuraAvanzada Permite expandir y “desexpandir”
LibText.asm pintaHex2 Permite pintar un número hexadecimal en una posición de pantalla concreta
  pintaCadena3 Permite pintar una cadena de caracteres en una posición de pantalla concreta
  biteToBCD Permite convertir un byte en binario a su codificación BCD
  bitesToBCD Idem con dos bytes
LibSonido.asm offsetVoces Renumera las voces como 0, 1 y 2
LibMath.asm maximo Nueva rutina para calcular el máximo de dos números
  minimo Nueva rutina para calcular el mínimo de dos numeros

Las nuevas librerías quedan disponibles aquí.

Como se habrá podido ver, el uso de unas librerías de rutinas (o macros) simplifica mucho el desarrollo de aplicaciones. Hacerlo desde cero hubiera sido mucho más complejo. Cada programador debe buscar las librerías que sean de su agrado, o desarrollar unas propias.


Nuevas librerías: Lib – V2