ESTRUCTURA DEL CODIGO FUENTE Y ENSAMBLADOR

Las herramientas principales con las que trabajo son el editor de texto de Windows, el emulador Spectaculator, el ensamblador PASMO y para los gráficos, el editor SevenuP de Metalbrain.

Antes de seguir, te puedes descargar el PRIMER EJEMPLO que he realizado para el curso. De momento sólo vale para que entiendas PASMO y cómo organizo el código fuente.

Voy a explicar un poco cómo funciona PASMO.
Los archivos que pertenecen al ensamblador dentro de la carpeta BUFFER VOLCADO CON LDI, son: bin2tap.exe, pasmo.exe y AENSAMBLA.BAT.

Si editas AENSAMBLA.BAT verás la siguiente línea de comandos:


pasmo APRINCIPAL.ASM APRINCIPAL.bin  APRINCIPAL.TXT pause

Cuando lo ejecutas, ensambla el código existente en  APRINCIPAL.ASM creando el código binario APRINCIPAL.bin y el fichero de texto APRINCIPAL.TXT que contiene las etiquetas usadas y su dirección correspondiente. Esto último nos será muy útil para depurar.

Prueba a borrar APRINCIPAL.bin y APRINCIPAL.TXT, y ejecuta  AENSAMBLA.BAT.

Si no ha habido ningún error, podrás ejecutar APRINCIPAL.bin en el emulador. En este caso debes poner la dirección de inicio de ejecución en 24000 que es donde empieza el programa.

En el directorio descargado ves que además hay distintos tipos de ficheros:

Ficheros *.ASM: Son los que ensambla PASMO

• APRINCIPAL.ASM: Es el bucle principal. Dentro de él se pueden incluir otros *.ASM para que no resulte tan largo y se vea todo más claro. Para ello se usa la instrucción INCLUDE "*.ASM" donde se quiera meter el código. Por ejemplo al principio aparece INCLUDE "CONTENIDA.ASM".

• CONTENIDA.ASM: Es el código que se va a incluir en la memoria contenida. Yo uso desde 24000 hasta 32768 que es donde acaba. El código contenido en estas direcciones va más lento, por lo que todo lo que se tenga que ejecutar con rapidez o a una velocidad constante se debe ensamblar por encima de 32768 (8000h). En CONTENIDA yo meto los menús, tablas de records, rutinas de preparación de tablas, borrado de pantalla...

• ARUTINAS.ASM: En este fichero meto las rutinas y subrutinas que van fuera del bucle principal. Así el código está más claro y no me lío buscando dónde ponerlas.

• ASPRITES.ASM: Aquí meto los gráficos de los Sprites

• ATABLAS.ASM: Donde van las tablas para controlar los distintos Sprites, que ya explicaré más adelante

                   

Ficheros *.BIN: Son ficheros binarios que se incluyen en una determinada dirección del código.

     Se introducen en el código con la instrucción INCBIN   "*.BIN".

     En ASPRITES.ASM  aparecen unos cuantos metiendo los gráficos.

Bueno, pues si ejecutas APRINCIPAL.bin desde la dirección 24000, te aparecerá algo así como esto:

En las siguientes entradas veremos cómo funciona

INTRODUCCION

Mi intención al crear este blog es mostrar cómo se pueden hacer juegos en el ZX Spectrum. Quiero dejar bien claro desde el principio que voy a intentar explicar cómo los programo yo. Evidentemente, existen múltiples formas mejores y peores de hacerlo. Por eso me interesaría mucho que si encuentras cómo mejorar algo (que seguro lo encontrarás), lo compartas y así todos iremos aprendiendo más.

Otra cosa que me gustaría aclarar es que no pretendo hacer un "creador de juegos para Spectrum". Ya hay varios por ahí y algunos muy buenos como la Churrera de los Mojon Twins. Lo que me gustaría es que si te interesa este mundo APRENDAS a hacer juegos y a partir de ahí, crees tus propias rutinas. Sólo puedo decirte que esto engancha... y mucho.

En este blog no voy a entrar en cuestiones teóricas muy profundas. Primero porque no soy el más indicado para explicarlas, y segundo porque hay mucha información sobre ello en la web. Yo siempre uso como referencia el curso El wiki de speccy.org de Santiago Romero. Una verdadera joya para todo aquel interesado en saber cómo programar en el Spectrum. Muchas veces me remitiré a él. Si no tienes muchos conocimientos sobre lenguaje ensamblador del Z80 y el Spectrum échale un vistazo.

Mi filosofía a la hora de hacer juegos es que me interesa mucho la velocidad y fluidez de los mismos. Una buena idea y unos gráficos estupendos se pueden ir al traste si el juego va muy lento. En el Spectrum la memoria es escasa, pero yo creo que la velocidad lo es más. Por eso verás que uso técnicas como crear todo el programa lo más lineal posible sin saltos y con muy pocas subrutinas, nunca uso saltos relativos (JR n) ya que los absolutos (JP nn) son más rápidos aunque ocupen más memoria y me gusta depurar mucho las rutinas para conseguir velocidad. La experiencia me ha enseñado que llenar toda la memoria del Spectrum para un juego es complicado y  conseguir un poco más de velocidad lo es aún más. Osea, que programo usando mucha memoria pero con unos niveles de velocidad aceptables y si al final me faltan bytes, es cuando empiezo a recortar.

Algo muy interesante es ver cómo otros hacen los juegos. Cógete un emulador con un buen depurador (yo uso Spectaculator y me va muy bien) y destripa tus juegos favoritos. 

Espero que este blog te sea de utilidad y lo pases al menos tan bien como lo paso yo programando.