Toda esto surge por la colaboración con Juntelart y su ZX-Game Maker para modificar la rutina de reproducción que genera BeepFX, y así evitar que los juegos que queden parados.

Una vez terminada esta rutina, me encontré con la circunstancia de que diseñaba efectos un tanto aleatoriamente, pero sin tener muy claro lo que hacía. Como no sé si alguien más se encuentra en esta situación, he decidido escribir este artículo; espero que os sea de provecho.

Antes de comenzar quiero agradecer los acertados comentarios que me han hecho mis compañeros del grupo Ensamblador Z80 de Telegram: Conrado Badenas Mengod y Pedro Picapiedra.

Tabla de contenidos

• Cómo configurar los sonidos con BeepFX
  • Parámetros del tono
  • Parámetros del ruido
  • Parámetros de la pausa
• Ejemplo de un efecto generado con BeepFX
• Modificación del reproductor de BeepFX
• Cómo usar el reproductor
• Conclusión

Cómo configurar los sonidos con BeepFX

Cada sonido se configura de manera distinta, aunque semejante, por lo que os muestro por separado tanto sus parámetros como su uso.

Parámetros del tono

• Frames: número de fracciones, no confundir con los típicos cincuenta frames por segundo (o sesenta) del ZX-Spectrum. Admite valores de 1 a 65536.
• Frame length: longitud de cada uno de los frames. Admite valores de 1 a 65536. 1 segundo es aproximadamente 32768.
• Pitch: frecuencia, este valor indica la nota. Admite valores de 1 a 65536.
• Pitch slide: deslizamiento de la frecuencia. Se aplica a cada frame, por lo que no tiene efecto si sólo hay un frame; es el valor que se suma a la frecuencia en cada frame. Admite valores de -32767 a 32768.
• Duty: ciclo de trabajo. En base a este valor se va a activar o desactivar el EAR y el altavoz interno. El valor medio es 128, valor con el que las notas suenan más claras. Cambiando este valor se distorsiona el sonido. Admite valores de 0 a 255. Con 0 no se escucha nada.
• Duty slide: igual que Pitch Slide pero para Duty. Admite valores de -127 a 128.

Ahora veamos como funcionan estos parámetros.

Si configuras un bloque con 1 frame, 32768 de longitud, 440 de pitch, 0 de pitch slide, 128 de duty y 0 de duty slide, oirás el LA siguiente a DO central. Si ahora pones 10 frames con una longitud de 3276 y pitch slide de 100, verás como el efecto dura el mismo tiempo, pero se escuchan diez tonos distintos. El primer frame empieza en la frecuencia 440 y va sumando 100 a la frecuencia en los siguientes, resultando 540, 640, 740, etc.

Las frecuencias del DO central y los once semitonos siguientes son:

Aunque las frecuencias tienen decimales, tú siempre especificarás los valores enteros. Para subir una octava debes multiplicar el valor de la frecuencia por dos y para bajar una octava dividirlo entre dos, de ahí que se reflejen los valores decimales. Si subes tres octavas (2^3), al multiplicar por ocho el SI sin tener en cuenta los decimales da tres mil novecientos cuarenta y cuatro, pero teniendo en cuenta los decimales da tres mil novecientos cincuenta y uno sin tener en cuenta los decimales del resultado, una diferencia de siete, aunque no creo que se aprecie en demasía.

Si te interesa saber más sobre esta frecuencias, Conrado me ha proporcionado este enlace.

Parámetros del ruido

• Frames: igual que Frames en los parámetros del tono.
• Frame length: igual que Frame length en los parámetros del tono.
• Pitch: parecido a Pitch en los parámetros del tono, pero admite valores de 1 a 256. Usa los valores que hay en los primeros 8Kb de la ROM para generar el ruido.
• Pitch slide: igual que Pitch slide en los parámetros del tono.

Fijaos que en Pitch indico que es semejante a Pitch en los parámetros del tono. Probad a configurar un ruido con Frames = 10, Frame length = 30000, Pitch = 128 y Pitch slide = 128. Al reproducir este bloque apreciaréis que hay una variación de sonido, digamos, entre los frames pares y los impares. Esto se debe a que en los ruidos, Pith y Pitch Slide son bytes, resultando que los valores de Pitch en cada frame son:

Y así hasta llegar al décimo frame.

Para conseguir mayor variación de tonos pon un valor más bajo en Pitch Slide, por ejemplo treinta y dos.

Parámetros de la pausa

• Frames: igual que Frames en los parámetros del tono.
• Frame length: igual que Frame length en los parámetros del tono.

Si te fijas en el código ensamblador que genera BeepFX, la pausa es idéntica al tono (incluso se identifica como tal), pero con los parámetros Pitch, Pitch slide, Duty y Duty slide a cero.

Esto es algo que tienes que tener muy en cuenta. Si tu sonido (o quizá música) va a reproducir un bloque en cada interrupción, pero para conseguir el compás correcto necesitas incluir pausas (notas que no suenan), estas pausas debes configurarlas con Frames = 1 y Frame length = 1. Durante esa interrupción, o en el bucle del programa, lo único que interesa es que la nota que suena no suene, así que cuánto menos dure mucho mejor.

Ejemplo de un efecto generado con BeepFX

A continuación, un ejemplo de un efecto generado con BeepFX que contiene los tres tipos de bloques especificados anteriormente (se muestra el código ensamblador que genera el programa).

SoundEffectsData:
  defw SoundEffect0Data

SoundEffect0Data:
  defb 1 ;tone
  defw 1,500,440,0,128
  defb 1 ;tone
  defw 1,500,440,0,128
  defb 1 ;pause
  defw 1,500,0,0,0
  defb 1 ;pause
  defw 1,500,0,0,0
  defb 2 ;noise
  defw 1,500,100
  defb 2 ;noise
  defw 1,500,100
  defb 0

En los bloques de tono y pausa, en las líneas que empiezan por defw, los valores son los siguientes (son valores de 16 bits):

En los bloques de ruido, en las líneas que empiezan por defw, los valores son los siguientes (vuelven a ser valores de 16 bits):

Los bloques de Tono y Pausa tienen una longitud de once bytes, desde el byte que indica el tipo de bloque, hasta el último byte del bloque. Los bloques de Ruido tienen una longitud de siete bytes desde el byte que indica el tipo de bloque hasta el último byte del bloque.

En ensamblador, los valores separados por coma que se encuentran después de defb o db son de tipo byte (8 bits). Por el contrario, los valores que se encuentran después de defw o dw son de tipo word (palabra) o dos bytes (16 bits).

Cada bloque está compuesto por una primera línea defb en la que se indica el tipo de bloque, y una segunda línea defw en la que se indican los parámetros del bloque.

Modificación del reproductor de BeepFX

Con BeepFX puedes crear efectos realmente sorprendentes, incluso proporciona un reproductor para que no tengas que preocuparte de nada, pero aquí hay un gran problema: el reproductor reproduce todo el efecto, lo cual puede provocar, y provoca, que tus juegos se paren. En cuanto quieras tener un efecto elaborado, seguro que tu juego se detiene mientras se reproduce.

Ya comenté al principio que este artículo surge a consecuencia de una conversación que tuve con Junterlart. He realizado una modificación sobre el reproductor de Shiru, para que se pueda reducir bloque a bloque en lugar de reproducir el efecto completo.

Para comprender lo que hace la rutina de Shiru la he comentado línea a línea, lo cual me ha ayudado también a entender como funciona BeepFX. Esta es la rutina tal y como ha quedado.

; BeepFX player by Shiru
; You are free to do whatever you want with this code
; Modificado por Juan Antonio Rubio García

; Si se va a usar desde fuera de ASM, antes de Play poner ORG Dirección para que calcule las
; direcciones al ensamblar
; Cambios realizados para su uso en ZX-Game Maker

; Primero: en la dirección Play+$01 cargar el sonido a reproducir
;     LD   Play+$01,$03   POKE Play+1,3           Indica cargar el sonido 3
; Segundo: llamar a Play
;     CALL Play           RANDOMIZE USR Play      Pone en memoria la dirección del sonido 3
; Tercero: llamar a NextNote cuando sea preciso
;     CALL NextNote       RANDOMIZE USR Play+17   Reproduce un bloque del efecto y sale
;                                                 Si no hay ningún efecto cargado sale
Play:
  ld   c, $00           ; En $00 se indicará el sonido a reproducir
  ld   b, $00           ; BC = A, efecto a reproducir
  ld   hl,FXAddress     ; Dirección en la que están las direcciones de los efectos
  add  hl,bc
  add  hl,bc            ; HL = dirección donde está la dirección del sonido a reproducir
  ld   c, (hl)
  inc  hl
  ld   b, (hl)          ; BC = dirección del sonido a reproducir
  ld   (FX),bc          ; Guarda en memoria la dirección del sonido a reproducir
  ret

NextNote:
  ld   hl,(FX)          ; HL = dirección del siguiente bloque a reproducir
  ld   a, (hl)          ; Carga el tipo de efecto en A (es el primer byte del bloque)
  or   a                ; Comprueba si es 0
  ret  z                ; Si es 0 sale, nada que reproducir

  di                    ; Desactiva las interrupciones
  push ix
  push iy               ; Preserva los registros índice
  push hl
  pop  ix               ; Carga en IX el valor de HL (dirección del efecto/bloque), ver línea 29

  ld   a, ($5C48)       ; Obtiene los atributos del borde
  rra
  rra
  rra                   ; Los pone en los bits 0 a 2
  and  $07              ; Se queda con los atributos del borde
  ld (sfxRoutineToneBorder  +$01),a
  ld (sfxRoutineNoiseBorder +$01),a ; Modifica las rutinas con el valor del borde
                                    ; OR $00, sustituye 0 por el valor de A, en líneas 102 y 150

readData:
  ld   a, (ix+$00)      ; A = tipo de bloque
  ld   c, (ix+$01)
  ld   b, (ix+$02)      ; BC = Frames
  ld   e, (ix+$03)
  ld   d, (ix+$04)      ; DE = Frame lenght, estos tres parámetros son comunes en tono y ruido
  push de
  pop  iy               ; Carga en IY el valor de DE, Frame lenght

  dec  a                ; Decrementa A (Tipo de bloque)
  jr   z,sfxRoutineTone ; Si es 0, es tono, salta
  dec  a                ; Decrementa A
  jr   z,sfxRoutineNoise; Si es 0, es ruido, salta
endData:
  pop  iy
  pop  ix               ; Recupera los registros índice
  ei                    ; Reactiva las interrupciones
  ret                   ; Sale de la rutina
   
nextData:
  add  ix,bc            ; Apunta IX al bloque siguiente, ver líneas 129 y 183 para BC, líneas 37 y 38 para IX
  ld   (FX),ix          ; Guarda en memoria la dirección del siguiente bloque 
  jr   endData          ; Salta para salir de la rutina

; Genera tono con seis parámetros, 11 bytes por bloque. Frame length 32768 = 1 segundo aprox.
; Tono
;       0
;	      Type = Tone
;  defb 1
;       1 - 2 	3 - 4 	      5 - 6           7 - 8 	  9 - 10
;	Frames	Frame lenght  Pitch	      Pith slide  Duty y Duty slide
;                             Frecuencia
;  defw 65536,	65536,	      65535,	      32768,	  33023
sfxRoutineTone:
  ld   e, (ix+$05)      ; IX = dirección el bloque, ver líneas 37 y 38
  ld   d, (ix+$06)      ; DE = Pitch
  ld   a, (ix+$09)      ; A = Duty
  ld   (sfxRoutineToneDuty+1),a ; Modifica la rutina con el valor de Duty
                                ; CP $00, sustituye 0 por el valor de A, ver línea 98
  ld   hl,$00           ; HL = 0. Para reproducir el sonido va sumando Pitch (frecuencia)
                        ; y usa el byte alto para activar/desactivar EAR y altavoz interno
sfxRT0:
  push bc               ; Preserva BC (Frames), ver líneas 51 y 52
  push iy
  pop  bc               ; Carga en BC el valor de IY (Frame lenght), ver líneas 55 y 58
sfxRT1: ; Desde aquí la rutina tarda 88 t-sates hasta la línea 108 (sincronización).
  add  hl,de            ; Suma DE (Pitch) a HL (11 t-states)
  ld   a, h             ; Carga el byte alto en A (4 t-sates)
sfxRoutineToneDuty:
  cp   $00              ; Lo compara con el valor de Duty ($00 se modifica en las líneas 110 a 112, se carga la primera vez en línea 86) (7 t-sates) 
  sbc  a, a             ; Resta A - A teniendo en cuenta el acarreo (4 t-states)
  and  $10              ; Se queda con el bit 4, EAR y altavoz interno activado/desactivado (7 t-states)
sfxRoutineToneBorder:
  or   $00              ; Añade el color del borde (se modificó en las línea 45) (7 t-states)
  out  ($fe),a          ; Manda el valor al puerto 254 para activar/desactivar EAR y altavoz interno (11 t-sates)
  ld   a,(0)            ; (13 t-states)
  dec  bc               ; Decrementa BC (6 t-sates)
  ld   a, b             ; (4 t-states)
  or   c                ; Comprueba si BC = 0 (4 t-sates)
  jp  nz, sfxRT1        ; Si no es 0, bucle hasta que Frame lenght = 0 (10 t-states, Total 88 t-states)

  ld   a,(sfxRoutineToneDuty+1) ; Cambio de Duty en línea 98
  add  a,(ix+$0a)               ; Añade el valor de Duty slide
  ld   (sfxRoutineToneDuty+1),a ; Cambia el valor de la línea 98

  ld   c, (ix+$07)
  ld   b, (ix+$08)      ; BC = Pitch slide
  ex   de,hl            ; Intercambia los valores de DE y HL
  add  hl,bc            ; Suma Pitch slide a Pitch, Pitch se carga en líneas 83 y 84
  ex   de,hl            ; Intercambia los valores de DE y HL (DE = Pitch + Pitch slide)

  pop  bc               ; Recupera BC (Frames)
  dec  bc               ; Decrementa BC
  ld   a, b
  or   c                ; Comprueba si BC = 0
  jr   nz,sfxRT0        ; Si no es 0, bucle hasta que Frames = 0

  ld   c, $0b           ; C = bytes a los que está el siguiente bloque, BC viene a 0
  jp   nextData

; Genera ruido con dos parámetros, 7 bytes por bloque. Frame length 32768 = 1 segundo +/-.
;       0
;       Type = Noise
; defb  2 ;noise
;       1 - 2   3 - 4         5 - 6
;       Frames  Frame lenght  Pitch y Pitch slide
; defw  65535,  65535,        33023
sfxRoutineNoise:
  ld   e, (ix+$05)      ; E = Pitch, IX = dirección el bloque, ver líneas 37 y 38
  ld   d, $01
  ld   h, d
  ld   l, d             ; HL = $11 (Dirección 17 de la ROM)
sfxRN0:
  push bc               ; Preserva BC (Frames)
  push iy
  pop  bc               ; Carga en BC el valor de IY (Frame lenght), ver líneas 55 y 56
sfxRN1: 
; Desde aquí, la rutina tarda 112 t-states hasta la línea 168 si en la línea 153 D=0 y 88 si D<>0
  ld   a, (hl)          ; A = Valor de la dirección a la que apunta HL (en los primeros 8Kb de la ROM) (7 t-states)
  and  $10              ; Se queda con el bit 4, activa o desactiva EAR y altavoz interno (7 t-states)
sfxRoutineNoiseBorder:
  or   $00              ; Añade el color del borde ($00 se modificó en la línea 46) (7 t-states)
  out  ($fe),a          ; Manda el valor al puerto 254 para activar/desactivar EAR y altavoz interno (11 t-sates)
  dec  d                ; Decrementa D (4 t-states)
  jp   z, sfxRN2        ; Si es 0 salta (10 t-states)
  nop                   ; (4 t-states)
  jp   sfxRN3           ; Salta (10 t-states)
sfxRN2:
  ld   d, e             ; D = Pitch (4 t-states)
  inc  hl               ; HL += 1 (6 t-states)
  ld   a, h             ; A = H (4 t-states)
  and  $1F              ; Se queda con el valor de los bits 0 a 4 (7 t-states)
  ld   h, a             ; H = A, dejando HL apuntando a alguna dirección de los primeros 8Kb de la ROM (4 t-states)
  ld   a, ($00)         ; (13 t-sates)
sfxRN3:
  nop                   ; (4 t-states)
  dec  bc               ; Decrementa BC (6 t-states)
  ld   a, b             ; (4 t-states)
  or   c                ; Comprueba si BC = 0 (4 t-states)
  jp   nz, sfxRN1       ; Si no es 0, bucle hasta que Frame lenght = 0 (10 t-states, Total 88 o 112 t-states)

  ld   a, e             ; A = Pitch
  add  a, (ix+$06)      ; A += Pitch slide
  ld   e, a             ; Actualiza Pitch

  pop  bc               ; Recupera BC (Frames)
  dec  bc               ; BC -= 1
  ld   a, b
  or   c                ; Comprueba si BC = 0
  jr   nz,sfxRN0        ; Si no es 0, bucle hasta que Frame = 0

  ld   c, $07           ; C = bytes a los que está el siguiente bloque, BC viene a 0
  jp   nextData

FX:
  dw   $001E            ; Se inicializa a $001E para que desde la primera vez salga de NextNote
                        ; si no tiene que reproducir nada (líneas 29 a 32)

FXAddress:
; Archivo asm generado por BeepFX sin reproductor
include "fx.asm"

Cómo usar el reproductor

El reproductor tiene dos puntos de entrada, Play y NextNote. Lo primero que tienes que hacer es poner en la dirección de memoria Play+1 el número de efecto que quieres reproducir, y acto seguido llamar a Play. Posteriormente, cada vez que quieras reproducir un bloque, en cada interrupción, en cada iteración del bucle de tu juego, debes llamar a NextNote.

En ensamblador sería algo así:

ld   (Play+$01), $01
call Play
...
...
...
call NextNote

En BASIC se haría de la siguiente manera, suponiendo que cargas el reproductor y los efectos a partir de la línea 50000:

POKE 50001,1
RANDOMIZE USR 50000:REM Llama a PLAY
...
...
...

RANDOMIZE USR 50017

No obstante, próximamente voy a publicar en El taller de Juanan en la web de Play On Retro, una variación de la rutina que creo que simplifica su uso desde BASIC.

Ten en cuenta que los efectos que diseñes en BeepFX no van a sonar igual en tus juegos. La explicación a esto es que en tu juego vas a reproducir un bloque, por ejemplo, por cada interrupción, mientras que en BeepFX se reproduce todo el efecto completo. Para simular esto en BeepFX debes meter pausas ficticias de una interrupción; hay cincuenta interrupciones por segundo, por lo que una aproximación sería entre cada tono o ruido poner una pausa de un frame con una longitud de seiscientos cincuenta y cinco. Estas pausas ficticias se verán fácilmente identificadas como:

defb 1
defw 1,655,0,0,0

No olvides borrarlas del archivo generado por BeepFX.

También es posible que tu efecto tenga pausas necesarias, es decir, no quieres que suene un bloque en cada interrupción, si no que quieres que haya más espacio. Para esto último incluye pausas de un frame y una longitud de uno, así las podrás distinguir fácilmente de las pausas para simular el modo de reproducción y no entorpecerán el flujo del juego.

Una vez que tengas todos los efectos diseñados, en el menú File, haz clic sobre Compile y en la ventana emergente selecciona Assembly, quita el check a Include player code (no vamos a usar el reproductor de BeepFX) y haz clic sobre Compile (el resto de parámetros no son importantes en nuestro caso). En el diálogo Save compiled data, graba el archivo como fx.asm en el directorio dónde tengas los fuentes para que el ensamblador que uses pueda localizarlo en la línea include que hay al final del reproductor.

Conclusión

Espero que todo lo aquí descrito os sirva para que vuestros juegos no se paren cuándo se reproduce algún efecto de sonido creado con BeepFX y en consecuencia fluyan mejor.

La idea de esta modificación surgió cuándo Juntelart me comentó el problema al reproducir los efectos de sonido, que paraban los juegos, y creo que hemos dado con una solución decente.

La colaboración hace la fuerza.

Puedes descargar el proyecto de pruebas, con el código fuente desde aquí.

The entry will be updated in the future.

Translated with DeepL.

Table of contents

• ZX Spectrum model
• PAL vs NTSC
  • What is the difference?
  • How does it affect us?
  • How do we find out the system?
• Downloads

ZX Spectrum model

On more than one occasion we will need to know which model of ZX Spectrum our program is going to run on, 16K, 48K or 128K, and in the latter case if it is in 48K or 128K mode.

The way to get the ZX Spectrum model I’m going to show is based on what Sergio thEpOpE exposed in the Basic ZX Course group on Telegram.

Depending on the value that we find in the memory position 0x4B (75), we can know if it is a 128K model or on the contrary if it is a 16/48K model. If when reading the value of this memory position we get 0x6E (110), the program is running in a 128K model, otherwise it is running in a 16/48K model.

If you are running on a 16/48K ZX Spectrum model, it is interesting to know which one it is, information that can be found at locations 0x5CB4 (23,732) and 0x5CB5 (23,733). In these addresses we will find the total amount of memory: 0x7FFF (32,767) in 16K models or 0xFFFFFF (65,535) in 48K models. As we can see, the second byte (the least significant one) has the same value, changing only the most significant one, which is located at memory location 0x5CB5 (23,733).

If we read the value of this position and get 0x7F (127) we are executing in a 16K model, if we get 0xFF (255) we are executing in a 48K model. For 128K models the value is the same as for 48K models.

If it is running on a 128K ZX Spectrum model, it is possible that it is running in 48K or 128K mode, which we can also find out. First we get the value of the memory location 0x5C3B (23,611), we divide by 16 and the result is divided by 2. If the result of this operation is equal to the integer division of the value of the memory location by 16 and the result is divided by 2, it is running in 48K mode, otherwise in 128K mode.

IF INT(PEEK(23611)/16)/2 = INT(INT(PEEK(32611)/16/2)
    48K model
ELSE
    128K model
END IF

In other words, if the result of the integer division between the value of memory location 0x5C3B (23,611) and 16 is even, it is in 48K mode, otherwise it is in 128K mode.

In ZX Spectrum assembly we are allowed, with right-hand rotations, to make divisions by powers of 2 (16 = 2^4), so we would have to make four rotations to make the division by 16 and then check if the result is even, bit 0 is zero.

ld   a, $cc                   ; A = 1100 1100
; We use displacements to perform the division by 16
sra  a                        ; A = A/2 =  0110 0110
sra  a                        ; A = A/4 =  0011 0011
sra  a                        ; A = A/8 =  0001 1001
sra  a                        ; A = A/16 = 0000 1100
; Check if A is even
bit  $00, a
jr   z, isEven                ; If bit 0 is 0, it is even, it skips
isOdd:
; isOdd code
isEven:
; isEven code

If you notice, we have shifted bits 4 to 7 to bits 0 to 3 and bits 4 to 7 have been set to zero, finally checking if bit 0, formerly bit 4, is 0 if it is even or 1 if it is odd. We can save displacements and check bit 4 directly.

Based on what we have seen, the routine to find out on which ZX Spectrum model we are running a program could be the following:

; ZXModel
;
; Gets the ZX model
;
; Entry:  nothing
;
; Output: BC = ZX model
;              0 = 16K
;              1 = 48K
;              2 = 128K
;              3 = 128K in 48K mode
; Alters the value of the BC and AF registers.
ZXModel:
ld   bc, $00			; BC is used to return the value to BASIC

ld   a, ($4b)           ; A = model address
cp   $6e
jr   z, is128           ; $6E, 128, jump

is16or48:
ld   a, ($5cb5)         ; A = amount of memory, upper part
rla                     ; Rotate to the right to check if it is $BF or $FF
ret  nc                 ; NC = 16K, jump ($BF)
inc  c                  ; C+=1
ret                     ; 48K, jump

is128:
ld   c, $02             ; C = 128K
ld   a, ($5c3b)         ; A = mode address
; IF INT(PEEK 23611/16)/2 = INT(INT(PEEK 23611/16)/2) = 48K.
; Dividing by 16 is like shifting 4 times to the right,
; bit 4 is set to bit 0
; Knowing if it is divisible by two is like knowing if it is even, bit 0 = 0
; It all boils down to evaluating bit 4, if it is 0 it is 48K mode, if it is 1 it is 128K mode
bit  $04, a             ; Bit 4?
ret  nz                 ; !0, 128K mode, exit
inc  c                  ; C+=1
ret                     ; 48K mode

To test this routine, you must compile it and load it, for example, at memory address 0x7D00 (32,000), so that it will run on any ZX Spectrum model or clone. Once the routine is loaded, if you type PRINT USR 32000, the value corresponding to the ZX Spectrum model on which it is running will be printed on the screen.

The value returned by an assembly program to the ZX Spectrum BASIC is done through the BC register.

PAL vs NTSC

Sometimes, we may be interested in knowing if the ZX Spectrum on which our program is running is PAL or NTSC system.

What is the difference?

In PAL system there are 50 interruptions per second, while in NTSC system the number of interruptions per second is 60.

How does it affect us?

It can affect us a lot. If our program relies on interrupts for timing, for example by executing the enemy movement routine every five interrupts, on a PAL system the enemy will move five times per second, while on NTSC it will move six times per second, resulting in faster enemy movement on NTSC than on PAL, which can affect gameplay.

How do we find out the system?

In this case I have relied on Habisoft’s Es.pectrum emulator, which you can download from here.

This wonderful emulator emulates a wide variety of ZX Spectrum models and their clones, so it’s ideal for testing the program I’ve implemented to detect if it’s PAL or NTSC, and it’s also free.

The program is simple, activate the ZX Spectrum interrupts in mode 2 and the first time the interrupt routine is executed it sets swCount to one to indicate that the counter variable in the main loop is being incremented. The second time the interrupt routine is executed it sets swCount to two to indicate that the program should exit. The value of counter is loaded into BC so that it can be obtained from Basic.

In short, the program counts the number of times the main loop is executed between two interrupts. Based on the test results, we could say that NTSC yields values below 100, while PAL yields values above 100.

All this has to be treated with great care, if you look at the results you can see values that are at the limit.

; Program to find out if it's NTSC or PAL
; Compile: pasmo --name PAL_NTSC --tapbas PAL_NTSC.asm PAL_NTSC.tap
; Once loaded, run PRINT USR 32000 to see the result
; Not compatible with 16K model

; Results of PRINT USR 32768 using emulator Es.pectrum
;
; https://habisoft.com/espectrum/
;
; Sinclair ZX Spectrum:
;       48/48+                  216
;       48 NTSC                  64
;       128                     230
;       48 ar                   ¿?
;       48 se                   215
; Timex:
;       TS 2068                  64
;       TC 2068                 216
;       TC 2048                 216
;       Komputer 2086           216
; Investrónica:
;       48+ es                  215
;       128+ es                 230
;       Inves+                  230
; Amstrad:
;       +2                      230
;       +2 es                   230
;       +2 fr                   230
;       +2 ar                   ¿?
;       +2A 4.0                 230
;       +2A 4.1                 230
;       +2A 4.0 es              230
;       +2A 4.1 es              230
;       +2A ar                  ¿?
;       +3 4.0                  230
;       +3 4.1                  230
;       +3 4.0 es               230
;       +3 4.1 es               230
; Pentagon:
;       Pentagon 128            241
;       Pentagon 512            241
;       Pentagon 1024 SL        227
; ZS Rechearch:
;       Leningrad               184
;       Scorpion ZS-256         151
;       Scorpion ZS-256 Turbo+  215
; Microdigital:
;       Tk90x pt-BR              73
;       Tk90x es-AR             233
;       Tk95  pt-BR              72
;       Tk95  es-AR             233
; ATM:
;       ATM-Turbo               215
;       ATM-Turbo 2+            176
; Otros:
;       Orel BK-08               ¿?
;       Dubna 48K                15
;       HC-91                   230
;       BK-001                  105
;       Foton-Ik03               ¿?
;       Alf TV Game (Elf)        ¿?
;       Vesta IK-30             184
; Mods:
;       +3e                     230
;       +3e es                  230
;       +2e                     230
;       +2e es                  230
;       Pentagon es             241
; Virtuales:
;       Spec256 48K             216
;       Spect256 128K           230
org  $8000

; Input: prepare for interruptions
main:
ld   hl, isr            ; HL = interrupt routine address
ld   ($feff), hl        ; Store in $feff the address
ld   a, $fe             ; of routine isr
ld   i, a               ; I = $fe
im   2                  ; Go to interrupt mode 2

; Loop, waits for swCount to be 1 to start counting
; When swCount is 2, exit loop and end of program
loop:
ld   a, (swCount)       ; A = indicator to know whether to count
or   a                  ; A = 0?
jr   z, loop            ; Z = yes, jump
cp   $02                ; A = 2?
jr   z, exit            ; Z = yes, jump

ld   hl, counter        ; HL = counter address
inc  (hl)               ; Counter+=1

jr   loop               ; Loop

; Exit from the programme
; Sets interrupts to mode 1
; Sets the counter to BC so that it can be retrieved
; from BASIC
exit:
im   1                  ; Go to interrupt mode 1
ld   b, $00
ld   a, (counter)
ld   c, a               ; BC = counter, to return the result
ret                     ; Back to BASIC

; Interruptions routine
; At each interrupt it increments swCount
isr:
push hl                 ; Preserves HL

ld   hl, swCount
inc  (hl)               ; Increases the indicator to know if counting

pop  hl                 ; Retrieves HL

ei                      ; Enables interruptions
ret                     ; Exit

; Vars
swCount:                ; Indicator to know whether to count
db $00
counter:                ; Counter
db $00

Downloads

• ZX Spectrum model
• PAL vs NTSC

La entrada irá recibiendo actualizaciones.

Tabla de contenidos

• Modelo de ZX Spectrum
• PAL o NTSC
  • ¿Qué diferencia hay?
  • ¿Cómo nos afecta?
  • ¿Cómo averiguamos el sistema?
• Descargas

Modelo de ZX Spectrum

En más de una ocasión necesitaremos saber en que modelo de ZX Spectrum se va a ejecutar nuestro programa, 16K, 48K o 128K, y en éste último caso si está en modo 48K o 128K.

La manera de obtener el modelo de ZX Spectrum que voy a mostrar se basa en lo expuesto por Sergio thEpOpE en el grupo de Curso Basic ZX de Telegram.

Según el valor que encontremos en la posición de memoria 0x4B (75), podemos saber si se trata de un modelo 128K o por el contrario si es un modelo de 16/48K. Si al leer el valor de esta posición de memoria obtenemos 0x6E (110), el programa se está ejecutando en un modelo de 128K, de lo contrario lo hace en un modelo 16/48K.

Si se está ejecutando en un modelo de ZX Spectrum de 16/48K, es interesante saber en cuál de ellos es, información que encontramos en las posiciones 0x5CB4 (23.732) y 0x5CB5 (23.733). En estas direcciones encontraremos la cantidad total de memoria: 0x7FFF (32.767) en modelos de 16K o 0xFFFF (65.535) en modelos de 48K. Como vemos, el segundo byte (el menos significativo) tiene el mismo valor, cambiando solo el más significativo, que se encuentra en la posición de memoria 0x5CB5 (23.733). Si leemos el valor de esta posición y obtenemos 0x7F (127) estamos ejecutando en un modelo de 16K, si obtenemos 0xFF (255) lo estamos haciendo en uno de 48K.

En los modelos de 128K el valor es el mismo que en los modelos de 48K.

Si se está ejecutando en un modelo de ZX Spectrum de 128K, es posible que se esté ejecutando en modo 48K o 128K, lo cual también podemos saber. Primero obtenemos el valor de la posición de memoria 0x5C3B (23.611), hacemos la división entre 16 y el resultado lo dividimos entre 2. Si el resultado de esta operación es igual a hacer la división entera del valor de la posición de memoria entre 16 y al resultado hacerle la división entera entre 2, se estaría ejecutando en modo 48K, de lo contrario en modo 128K.

SI INT(PEEK(23611)/16)/2 = INT(INT(PEEK(32611)/16/2)
    modo 48K
SI NO
    modo 128K
FIN SI

O lo que es lo mismo, si el resultado de la división entera entre el valor de la posición de memoria 0x5C3B (23.611) y 16 es par está en modo 48K, de lo contrario está en modo 128K.

En ensamblador para ZX Spectrum se nos permite, con rotaciones hacia la derecha, hacer divisiones entre potencias de 2 (16 = 2^4), por lo que tendríamos que hacer cuatro rotaciones para realizar la división entre 16 y luego comprobar si es resultado es par, el bit 0 está a cero.

ld   a, $cc                   ; A = 1100 1100
; Usamos desplazamientos para realizar la división entre 16
sra  a                        ; A = A/2 =  0110 0110
sra  a                        ; A = A/4 =  0011 0011
sra  a                        ; A = A/8 =  0001 1001
sra  a                        ; A = A/16 = 0000 1100
; Comprueba si A es par
bit  $00, a
jr   z, EsPar                 ; Si el bit 0 es 0, es par, salta
EsImpar:
; Código de EsImpar
EsPar:
; Código de EsPar

Si os fijáis, hemos desplazado los bits 4 a 7 hasta los bits 0 a 3 y los 4 a 7 se han puesto a cero, comprobando finalmente si el bit 0, anteriormente bit 4, es 0 en el caso de ser par o 1 en el caso de ser impar. Nos podemos ahorrar desplazamientos y comprobar directamente el bit 4.

En base a lo que hemos visto, la rutina para averiguar en qué modelo de ZX Spectrum estamos ejecutando un programa podría ser la siguiente:

; ZXModel
;
; Obtiene el modelo de ZX
;
; Entrada: nada
;
; Salida:  BC = modelo de ZX
;              0 = 16K
;              1 = 48K
;              2 = 128K
;              3 = 128K en modo 48K
; Altera el valor de los registros BC y AF.
ZXModel:
ld   bc, $00			; BC se utiliza para devolver el valor a BASIC

ld   a, ($4b)           ; A = dirección modelo
cp   $6e
jr   z, is128           ; $6E, 128, salta

is16or48:
ld   a, ($5cb5)         ; A = cantidad memoria, parte alta
rla                     ; Rota a la derecha para comprobar si es $BF o $FF
ret  nc                 ; NC = 16K, sale ($BF)
inc  c                  ; C+=1
ret                     ; 48K, sale

is128:
ld   c, $02             ; C = 128K
ld   a, ($5c3b)         ; A = dirección de modo
; Sí INT(PEEK 23611/16)/2 = INT(INT(PEEK 23611/16)/2) = 48K.
; Dividir ente 16 es como desplazar 4 veces hacia de derecha,
; el bit 4 pasa al bit 0. 
; Saber si es divisible entre dos es como saber si es par, el bit 0 = 0
; Todo se resume en evaluar el bit 4, si es 0 es modo 48K, si es 1 es modo 128K.
bit  $04, a             ; ¿Bit 4?
ret  nz                 ; !0, modo 128K, sale
inc  c                  ; C+=1
ret                     ; Modo 48K

Para probar esta rutina, deberéis compilarla y cargarla, por ejemplo, en la dirección de memoria 0x7D00 (32.000), para que corra en cualquier modelo o clon de ZX Spectrum. Una vez cargada la rutina, si tecleáis PRINT USR 32000 saldrá impreso en pantalla el valor correspondiente al modelo de ZX Spectrum en el que se está ejecutando.

El valor devuelto por un programa ensamblador al BASIC del ZX Spectrum se hace a través del registro BC.

PAL o NTSC

En ocasiones, nos puede interesar saber si el ZX Spectrum en el que se está ejecutando nuestro programa es sistema PAL o NTSC.

¿Qué diferencia hay?

En sistema PAL se producen 50 interrupciones por segundo, mientras que en sistema NTSC el número de interrupciones por segundo asciende a 60.

¿Cómo nos afecta?

Nos puede llegar a afectar y mucho. Si nuestro programa se apoya en las interrupciones para temporizar, por ejemplo ejecutando la rutina de movimiento del enemigo cada cinco interrupciones, en un sistema PAL el enemigo se moverá cinco veces por segundo, mientras que en NTSC se moverá seis veces por segundo, resultando el movimiento del enemigo más rápido en NTSC que en PAL, pudiendo influir en la jugabilidad.

¿Cómo averiguamos el sistema?

En este caso me he apoyado en el emulador Es.pectrum de Habisoft, que podéis descargar desde aquí.

Este maravilloso emulador emula una vasta variedad de modelos de ZX Spectrum y sus clones, por lo que es ideal para probar el programa que he implementado para detectar si es PAL o NTSC, y además es gratuito.

El programa es sencillo, activa la interrupciones del ZX Spectrum en modo 2 y la primera vez que se ejecuta la rutina de interrupciones pone swCount a uno para indicar que se vaya incrementando la variable counter en el bucle principal. La segunda vez que se ejecuta la rutina de interrupciones pone swCount a dos para indicar que se debe salir el programa. El valor de counter se carga en BC para que se pueda obtener desde Basic.

En resumen, el programa cuenta las veces que se ejecuta el bucle principal entre dos interrupciones. En base a los resultados arrojados por la pruebas, podríamos decir que NTSC arroja valores inferiores a 100, mientras que PAL los arroja superiores.

Todo esto hay que tratarlo con mucho cuidado, si observáis los resultados podéis ver valores que están al límite.

; Programa para averiguar si es NTSC o PAL
; Compilar: pasmo --name PAL_NTSC --tapbas PAL_NTSC.asm PAL_NTSC.tap
; Una vez cargado, ejecutar PRINT USR 32000 para ver el resultado
; No compatible con modelo de 16K

; Resultados de PRINT USR 32000 usando emulador Es.pectrum
;
; https://habisoft.com/espectrum/
;
; Sinclair:
;       48/48+                  216
;       48 NTSC                  64
;       128                     230
;       48 ar                   ¿?
;       48 se                   215
; Timex:
;       TS 2068                  64
;       TC 2068                 216
;       TC 2048                 216
;       Komputer 2086           216
; Investrónica:
;       48+ es                  215
;       128+ es                 230
;       Inves+                  230
; Amstrad:
;       +2                      230
;       +2 es                   230
;       +2 fr                   230
;       +2 ar                   ¿?
;       +2A 4.0                 230
;       +2A 4.1                 230
;       +2A 4.0 es              230
;       +2A 4.1 es              230
;       +2A ar                  ¿?
;       +3 4.0                  230
;       +3 4.1                  230
;       +3 4.0 es               230
;       +3 4.1 es               230
; Pentagon:
;       Pentagon 128            241
;       Pentagon 512            241
;       Pentagon 1024 SL        227
; ZS Rechearch:
;       Leningrad               184
;       Scorpion ZS-256         151
;       Scorpion ZS-256 Turbo+  215
; Microdigital:
;       Tk90x pt-BR              73
;       Tk90x es-AR             233
;       Tk95  pt-BR              72
;       Tk95  es-AR             233
; ATM:
;       ATM-Turbo               215
;       ATM-Turbo 2+            176
; Otros:
;       Orel BK-08               ¿?
;       Dubna 48K                15
;       HC-91                   230
;       BK-001                  105
;       Foton-Ik03               ¿?
;       Alf TV Game (Elf)        ¿?
;       Vesta IK-30             184
; Mods:
;       +3e                     230
;       +3e es                  230
;       +2e                     230
;       +2e es                  230
;       Pentagon es             241
; Virtuales:
;       Spec256 48K             216
;       Spect256 128K           230
org  $8000

; Entrada: prepara las interrupciones
main:
ld   hl, isr            ; HL = dirección rutina interrupciones
ld   ($feff), hl        ; Guarda en $feff la dirección
ld   a, $fe             ; de la rutina isr
ld   i, a               ; I = $fe
im   2                  ; Pasa a modo 2 de interrupciones

; Bucle, espera a que swCount sea 1 para empezar a contar
; Cuando swCount es 2, sale del bucle y fin de programa
loop:
ld   a, (swCount)       ; A = indicador para saber si contar
or   a                  ; ¿A = 0?
jr   z, loop            ; Z = sí, salta
cp   $02                ; ¿A = 2?
jr   z, exit            ; Z = sí, salta

ld   hl, counter        ; HL = dirección contador
inc  (hl)               ; Contador+=1

jr   loop               ; Bucle

; Salida del programa
; Pone las interrupciones en modo 1
; Pone el contador en BC para que pueda ser recuperado
; desde BASIC
exit:
im   1                  ; Pasa a modo 1 de interrupciones
ld   b, $00
ld   a, (counter)
ld   c, a               ; BC = contador, para devolver el resultado
ret                     ; Vuelta al BASIC

; Rutina de interrupciones
; En cada interrupción incrementa swCount
isr:
push hl                 ; Preserva HL

ld   hl, swCount
inc  (hl)               ; Incrementa el indicador para saber si contar

pop  hl                 ; Recupera HL

ei                      ; Habilita interrupciones
ret                     ; Sale

; Variables
swCount:                ; Indicador para saber si contar
db $00
counter:                ; Contador
db $00

Descargas

• Modelo ZX Spectrum
• PAL o NTSC

A través de quince capítulos y cinco anexos, nos guía en el aprendizaje de este potente lenguaje basado en el Basic de Sinclair, pero que, a diferencia de éste, vuela, de manera que la consabida lentitud del Basic parece más una leyenda urbana que una triste realidad.

Tabla de contenidos

• ¿Qué es Boriel Basic?
• ¿Cómo está distribuido el libro?
  • 1. Introducción
  • 2. Calentando motores
  • 3. El compilador Boriel Basic
  • 4. Variables y tipos
  • 5. El lenguaje Boriel Basic
  • 6. La memoria
  • 7. La pantalla en el ZX Spectrum
  • 8. La pantalla en el Next / N-GO
  • 9. Colisiones
  • 10. Controlando el Spectrum
  • 11. Las interrupciones
  • 12. El Beeper
  • 13. El chip AY-3-8912
  • 14. Arquitectura
  • 15. Creando el producto final
• Anexos
• Recursos
• ¿Cómo obtengo el libro?
• El autor
• Conclusión

¿Qué es Boriel Basic?

Boriel Basic es lo que se denomina un Basic compilado, desarrollado por José Rodríguez (aka Boriel), pero que no se limita a traducir el Basic de Sinclair a código máquina. José Rodríguez ha reescrito gran parte de las instrucciones del Basic de Sinclair en código máquina, por lo que el comando PRINT hace lo que pensaron los ingenieros de Sinclair, pero no de la misma manera, con Boriel Basic es mucho más rápido y óptimo. Además, ha modernizado la sintaxis para incorporar mecanismos de lenguajes modernos, lo que permite al programador estructurar y reutilizar su código de forma sencilla.

Boriel Basic tiene un compilador propio que traduce el código fuente a código ensamblador y de éste a código máquina. Además, dispone de muchas librerías; cabe destacar las de scroll al carácter y al píxel, e impresión de sprites acelerada, por lo que no tenemos que inventar la rueda, solo usarla.

Así mismo, y dado que la capacidad de memoria en los equipos a los que van a ir dirigidos nuestros programas es muy limitada, el compilador incluye un optimizador que, aparte de acelerar ciertas partes, solo incluye las rutinas a las que se llama, no toda la librería.

Todo esto lo puedes aprender leyendo el libro que nos ocupa.

¿Cómo está distribuido el libro?

El libro consta de quince capítulos y cinco anexos a través de los cuales se va desgranando Boriel Basic, de tal manera que al finalizar la lectura del mismo serás capaz de realizar tus propios desarrollos para ZX Spectrum, e incluso librerías para ampliar las posibilidades de Boriel.

También consta de cuatro prólogos a cargo de: Juan Antonio Rubio García «Juanan Homospectrum», José Rodríguez «Boriel», Javier Ortíz Carrasco «El Spectrumero» y Juan Segura Durán «Duefectu».

En cada uno de los capítulos encontrarás un código QR y una URL para poder descargar todo el código fuente desarrollado en el mismo.

A continuación, una pequeña descripción sobre lo que vais a encontrar en cada capítulo.

1. Introducción

En este capítulo encontramos los agradecimientos, cuáles son los objetivos del libro, tipo de lector al qué va dirigido y una serie de conceptos que se dan por asumidos por parte del lector; conocimientos que son necesarios que tenga para poder aprovechar en su totalidad la lectura del libro.

2. Calentando motores

En este capítulo se detallan las herramientas necesarias para seguir el libro: distintos IDE que podemos usar, emuladores, herramientas gráficas, para sonido y otras utilidades.

De cada una de las herramientas se proporciona la URL para su descarga y/o uso en el caso de las herramientas online.

3. El compilador Boriel Basic

Entramos en materia.

Empezamos a conocer más a fondo el compilador de Boriel Basic, compilamos nuestros primeros programas desde la línea de comandos, vemos los posibles parámetros de la misma, el mapa de memoria, alguna forma de como optimizar nuestro código  y algún concepto más que nos será de gran utilidad más adelante.

4. Variables y tipos

Es fundamental, en el aprendizaje de un lenguaje de programación, conocer de qué tipo de variables disponemos.

En este capítulo se nos muestran las reglas a tener en cuenta a la hora de poner nombre a las variables, los tipos numéricos y las variables alfanuméricas, así como las matrices (arrays) de una o más dimensiones y como trabajar con ellas. El uso de tipos en las variables puede sonar trivial, pero es una de las claves para que nuestros programas sean más rápidos y ocupen menos memoria.

Empezamos a prepararnos para lo que viene luego.

5. El lenguaje Boriel Basic

Como ya he comentado, Boriel Basic se basa en el Basic de Sinclair, pero lo redefine y extiende, por lo que tendremos instrucciones del Basic de Sinclair optimizadas para que funcionen mejor y más rápido, y otras que no existen en el Basic de Sinclair y que nos hacen la vida mucho más fácil, como DO…LOOP o ELSEIF, ELSE y END IF. Seguro que estas últimas las has echado mucho de menos si has programado en Basic de Sinclair.

En Boriel Basic no son necesarios los números de líneas, podemos programar funciones y subrutinas, tal y como hacemos en cualquier lenguaje de alto nivel que podamos usar en la actualidad. Disponemos de librerías que nos permiten usar la rueda sin necesidad de inventarla; no necesitamos saber de qué está compuesta, sólo debemos saber para qué sirve y la forma de usarla.

Una de las cosas que diferencian a Boriel Basic de otros Basic, y que es lo que más me llama la atención, es la posibilidad de incluir código ensamblador «inline», como si de C se tratara. ¿Una pasada, verdad?

6. La memoria

Pese a ser un lenguaje de alto nivel, dado el tipo de plataforma con el que estamos trabajando, se hace imposible abstraerse del hardware, al contrario de los que nos pasa con lenguajes actuales como JAVA o C#.

Cierto conocimiento del hardware, y en este caso concreto de la memoria, es fundamental para que nuestros desarrollos lleguen a buen puerto y funcionen con unos tiempos de ejecución aceptables.

En este capítulo se nos describe la memoria de cada uno de los modelos de ZX Spectrum, como podemos conmutar los bancos de memoria en los modelos de 128K y cómo hacerlo en el ZX Spectrum Next. Sí, ya dije que este libro también va a enseñar aspectos necesarios para programar para el ZX Spectrum Next.

7. La pantalla en el ZX Spectrum

Gráficos, gráficos, gráficos.

Lo que más nos gusta es lo que vemos en pantalla. Este capítulo nos enseña cómo trabajar con la pantalla del ZX Spectrum, definir UDG, fuentes y sprites y como dibujarlos, tiles y mapas y el sueño que todos hemos tenido, cuando con muy poquitos años empezamos en esto: scroll, scroll al pixel y al carácter. Todo esto lo conseguiremos usando la rueda, sin necesidad de inventarla.

Este capítulo es uno de los más jugosos, en él empezamos a ver resultados asombrosos que nos van a dar una idea más clara de lo que podremos lograr; sólo nuestra imaginación es el límite, y los 48K o 128K de los que disponemos, no nos olvidemos.

8. La pantalla en el Next / N-GO

Siempre hemos tenido la limitación de ocho colores y hemos debido luchar contra el Color Clash, buscando la manera en la que menos se note. Bien, con el ZX Spectrum Next nos podemos olvidar de todo esto. Usa un buen número de colores distintos y olvídate del Color Clash.

En este capítulo, al igual que en el anterior, se nos enseña cómo trabajar con sprites, tiles, mapas y scroll, pero con el hermano mayor de la familia.

Consigue hacer todo lo que soñabas cuando eras pequeño.

9. Colisiones

Seamos sinceros. Muy pocos de nosotros soñábamos con hacer un programa que nos ayudara a supervisar los gastos del hogar, ¿verdad? Soñábamos con hacer juegos como los que jugábamos, salir en la MicroHobby o Micromanía, y comprarnos ese cochazo que prometía cierta empresa si programabas para ella.

En casi todo juego hay un protagonista, unos obstáculos y algún enemigo, y para saber por dónde puede o no pasar el protagonista, o cuando nos mata o matamos algún enemigo, tenemos que controlar lo que denominamos colisiones. En este capítulo se nos muestran distintas técnicas para ello, empieza a pensar en serio en tu próximo juego.

10. Controlando el Spectrum

¿Qué necesita todo juego? Un jugador. ¿Qué necesita el jugador para jugar? Un teclado, un joystick o cualquier otro dispositivo que le permita interaccionar con el ZX Spectrum y, en el caso de los juegos, controlar al personaje y alcanzar la meta con él. Además también veremos como controlar un ratón en el ZX Spectrum Next.

En este capítulo aprendemos cómo controlar cada uno de estos dispositivos para que la experiencia del usuario sea satisfactoria.

11. Las interrupciones

Las interrupciones nos permiten ejecutar rutinas cada X tiempo (50 veces por segundo en sistemas PAL, 60 en sistemas NTSC), y de esta forma temporizar el movimiento de los enemigos, controlar el tiempo que queda para poder pasar un nivel, ralentizar el movimiento del personaje, etc. Este tipo de comportamiento lo hemos visto en múltiples juegos comerciales de la época. ¿Os acordáis de Manic Miner y su música ingame?

El contenido de este capítulo es para usuarios avanzados, ya que se hará uso de ensamblador para la implementación necesaria. Además, nos muestra los entresijos de la librería IM2, desarrollada por el autor del libro, que ha sido añadida a Boriel Basic recientemente, y que nos permite gestionar las interrupciones de forma muy sencilla. Nos lo podemos saltar y volver más adelante, cuando estemos más preparados.

12. El Beeper

¿Os acordáis de él, de la instrucción BEEP, de su característico sonido?

En este capítulo veremos maneras de llevarlo al próximo nivel, consiguiendo resultados que nunca creímos posibles, eso sí, dentro de las limitaciones que tiene.

Léelo detenidamente y da rienda suelta a tu creatividad.

13. El chip AY-3-8912

Los que pudimos disfrutar de un Amstrad CPC, pudimos disfrutar de música en multitud de juegos que en la versiones de ZX Spectrum no la tenían, caso de Commando o Ikari Warriors, por poner solo algún ejemplo.

Por desgracia, este chip solo está presente en los modelos de 128K si hablamos de ZX Spectrum clásicos, y no fueron muchos los juegos que aprovecharon los 128K de estos modelos y el chip AY, siendo mayoría los juegos adaptados para que funcionaran en 48K, en parte debido al gran parque existente de estos equipos.

Afortunadamente, hoy en día el homebrew existente sí que aprovecha estas características, y si bien se siguen haciendo juegos para 48K, la mayoría de las veces tienen su versión correspondiente para 128K, aunque solo sea para poder meter música, dicho sea de paso, de gran calidad en la mayoría de la ocasiones.

En este capítulo aprenderemos como usar el chip AY para que nuestros juegos dispongan de música y sonido de calidad, y no solo en el menú, cosa habitual en el pasado.

14. Arquitectura

Capítulo muy importante donde se nos muestra la arquitectura que debe tener nuestro juego, como organizarlo, módulos que debe tener, etc. Para leer con mucha atención y volver a él cuando sea necesario.

En este capítulo se propone una estructura para poder aprovechar los 128K de nuestro Spectrum +128/2/3, o los hasta 2Mb de nuestro ZX Spectrum Next.

También nos mostrará como cargar desde la SD del ZX Spectrum Next.

15. Creando el producto final

Ya tenemos nuestro juego, ¿y ahora qué? Hemos hecho un juego y lo lógico es distribuirlo para que los usuarios puedan disfrutarlo, ¿cómo lo hago?

En este capítulo veremos cómo crear los archivos de cinta (.tap), de disco (.dsk) o para la SD del ZX Spectrum Next.

Por último nos muestra varias opciones para su distribución, ya sea edición online o edición física. ¿Te imaginas tu juego grabado en una cinta, como en los años 80, y en la estantería de los jugones? En este capítulo verás cómo hacerlo.

Estaría bien tener una edición física de nuestro juego tan cuidada como las de Play On Retro.

Anexos

El libro dispone de cinco anexos que enumero a continuación:

• Anexo A: librerías incluidas en Boriel Basic.
• Anexo B: directivas predefinidas.
• Anexo C: códigos de las teclas.
• Anexo D: decimal, binario y hexadecimal.
• Anexo E: operaciones binarias.

Recursos

Finalmente, se muestra una lista de recursos ya vistos a lo largo del libro, pero agrupados en una sola sección, que nos harán la vida más fácil en nuestro viaje a través de la programación en Boriel Basic.

¿Cómo obtengo el libro?

El libro está a la venta en Amazon, por lo que se puede obtener desde distintas partes del planeta. Consta de tres ediciones: Kindle, tapa blanda y dura. Aunque el número de páginas varía entre una edición y otra, debido al formato y tamaño de página, el contenido es exactamente el mismo, por lo que compra la que más se ajuste a tus gustos. Actualmente se está trabajando en la edición en lengua inglesa.

A continuación, el enlace de compra. ¡Hazte con tu ejemplar!

El autor

Puedes seguir a Juan Segura Durán (aka Duefectu) a través de sus redes sociales, y así mantenerte al día de todos sus proyectos.

• X / Twiter
• Facebook
• Telegram
• GitHub
• Patreon
• Web oficial DuefectuCorp

Si quieres ver lo se puede llegar a desarrollar con Boriel Basic, y más concretamente para ZX Spectrum Next, visita la web del proyecto Cuadragon The Next Generation.

Conclusión

Ya sabéis, el límite lo pones tú. Hazte con el libro, aprende y da rienda suelta a tu creatividad.

¡Disfrútalo!

P.D.: quizá también te interese el libro que un tal Juanan ha escrito sobre Ensamblador para ZX Spectrum.

In this chapter we are going to talk about the screen layout of the ZX Spectrum.

Translated with DeepL.

Table of contents

• Screen layout
• ZX Spectrum graphic area
• ZX Spectrum attributes area
• Routines
• Memory address from character coordinates
• Character coordinate from memory address
• Next row memory address
• Previous row memory address
• Next scanline
• Previous Scanline
• Attribute address from character coordinates
• Character coordinates from attribute address
• Attribute address from graphic area address
• Graphic area address from attribute address
• Conclusion

ZX Spectrum graphic area

The screen of the ZX Spectrum has a resolution of 256*192 pixels, or what is the same 32 columns and 192 scanlines. With each byte we can configure 8 pixels, those at one will have the color of the ink (INK) and those at zero the color of the background (PAPER); 256 pixels / 8 pixels per byte = 32 columns. The graphic area occupies 6,144 bytes ($1800) and starts at memory address 16,384 ($4000).

One of the peculiarities of the ZX Spectrum is the way the graphic area is distributed. Each character consists of 64 pixels, or 8×8 pixels. Each line of the character is called a scanline. If we paint on the first scanline of a character and then add 32 to the memory position, the logic tells us that we are on the next scanline of the character, but it is not so because we are actually on the first scanline of the character just below the one we are on.

If we paint position $4000, the first byte of the screen, and then we want to paint in the first scanline of row 8 of the screen, the logic says that we would only have to add 8 times 32 ($20) to position $4000, so the first scanline of the first character of row 8 would be in position $4100. But this is not the case since position $4100 corresponds to the second scanline of the first character on the screen.

This behavior is due to the fact that the ZX Spectrum screen is divided into thirds. Each of the thirds has 8 rows and each of the rows has 8 scanlines. The first third goes from memory location $4000 to $47FF, the second third from $4800 to $4FFF and the third third third from $5000 to $57FF.

Although this may seem strange at first, when you see the composition that the bytes take when making up a memory location, it all makes sense. The composition of the bytes is as follows:

010T TSSS RRRC CCCC

Where 010 is always fixed, TT represents the third (from 0 to 2), SSS represents the scanline within the character (from 0 to 7), RRR represents the row within the third (from 0 to 7) and CCCCCC represents the column (from 0 to 31).

If we look at the row, from 0 to 23, bits 0, 1 and 3 always indicate the row within the third, and bits 4 and 5 the third, so TTRRR is equivalent to the line in character coordinates (from 0 to 23).

Row 0:  0000 0000 Row 0 of third 0
Row 7:  0000 0111 Row 7 of third 0
Row 8:  0000 1000 Row 0 of third 1
Row 15: 0000 1111 Row 7 of third 1
Row 16: 0001 0000 Row 0 of third 2
Row 23: 0001 0111 Row 7 of third 2

To see all of the above, let’s perform a simple example that fills the bytes of the first column with a simple $AA pattern (1001 1001).

org  $8000
ld   hl, $4000    ; HL = VideoRAM start address
ld   bc, $20      ; BC = value to be added to move to the next character
ld   a, $08       ; A = to draw the first scanline of the first third of the first third
loop:
ld   (hl), $aa    ; Load on screen the pattern 10011001
add  hl, bc       ; Advances HL to the next row
dec  a            ; Decrease A
jr   nz, loop     ; Loop until A reaches 0
ret               ; Back to Basic
end  $8000

If we run the program, it draws the pattern $AA (10101010) in the first scanline of the first 8 rows.

To see the ZX Spectrum screen layout, just change the LD A line, $08 and load multiples of $08; $08, $10, $18, $20, $28, $30, $38, $40, $40, $48….

Until we reach $48, we will not see how the first scanline of the 8 rows of the second third is painted.

ZX Spectrum attributes area

Following the graphic area (pixels) is the attribute area, which runs from address 22,528 ($5800) to address 23,295 ($5AFF), with a length of 768 ($300) bytes.

Each byte in the attribute area sets the attributes of a character (8×8 pixels), which is the reason for the famous attribute clash.

The format of each byte of the attribute area is as follows:

FBPPPIII

Where F is FLASH, B = BRIGHT, P = PAPER and I = INK.

In the case of the attributes area the distribution is linear, so if we are in the byte of the attributes of column 0, row 0 of the screen and add 32 we are in the attributes of column 0, row 1.

The composition of the memory addresses of the attribute area is as follows:

0101 10TT RRRC CCCC

Where 0101 10 is always fixed, TT represents the third (from 0 to 2), RRR represents the row within the third (from 0 to 7) and CCCCC represents the column (from 0 to 31). Again TTRRR is equivalent to the row in character coordinates (from 0 to 23).

Routines

From here, we are going to see routines that can help you when working with the ZX Spectrum screen. Keep in mind that these routines do not control if the coordinates are outside the screen area.

Memory address from character coordinates

The CharCoord2PointerHR routine takes character coordinates and returns the corresponding memory address.

; ----------------------------------------------------------------
; CharCoord2PointerHR: Gets the memory address
; corresponding to the specified character coordinates. 
; 
; Entrada: B -> Y-coordinate (0 a 23).
;          C -> X-coordinate (0 a 31).
; 
; Salida: HL -> Memory address corresponding to the
;               coordinates (010T TSSS RRRC CCCC). 
;
; Alters the value of AF and HL registers.
; ----------------------------------------------------------------- 
CharCoord2PointerHR:
ld	a, b      ; A = row. Bits 0, 1 and 2 row. Bits 3 and 4 third.
and $18       ; It stays with the third, 0001 1000. 
              ; Scanline always 0.
or 	$40       ; Add fixed part, 0100 0000.
ld 	h, a      ; H = A. High part of calculated direction.
ld 	a, b      ; A = row.
and $07       ; It stays with the row inside the third.
rrca
rrca
rrca          ; Rotate three times to pass value to bits 5, 6 and 7.Rotate three times to pass value to bits 5, 6 and 7.
or 	c         ; Add column.
ld 	l, a      ; L = A. Lower part of calculated direction.
ret

To test this routine we can pass it positions and then load a pattern at the returned address to see where it draws.

org $8000

ld b, $10                     ; Load in B the row.
ld c, $10                     ; Load in C the column.
call CharCoord2PointerHR      ; Calculates memory location.
ld (hl), $ff                  ; Activates all pixels in the
                              ; memory location.

inc b                         ; Increases row.
inc c                         ; Increases column.
call CharCoord2PointerHR      ; Calculates memory location.
ld (hl), $ff                  ; Activates all pixels in the
                              ; memory location.

inc b                         ; Increases row.
dec c                         ; Increases column.
call CharCoord2PointerHR      ; Calculates memory location.
ld (hl), $ff                  ; Activates all pixels in the
                              ; memory location.

ret

end	 $8000

Character coordinate from memory address

The PointerHR2CharCoord routine takes a memory address and returns the corresponding character coordinates.

; ---------------------------------------------------------------- 
; PointerHR2CharCoord: Obtiene las coordenadas de carácter
; correspondientes a la dirección de memoria especificada.
;
; Entrada: HL -> Memory pointer. 010T TSSS RRRC CCCC.
;
; Salida: B -> Y-coordinate (0 a 23).
;         C -> X-coordinate (0 a 31).
;
; Alters the value of AF and BC registers.  
; ---------------------------------------------------------------- 
PointerHR2CharCoord: 
ld a, h     ; A = upper part of memory address. 010T TSSS.
and $18     ; Keeps the third. Bits 4 and 5 of the Y coordinate.
            ; Scanline always at 0, they are character coordinates.
ld b, a     ; B = A.

ld a, l     ; A = lower part of the memory address. RRRC CCCC.
and $e0     ; It stays with the row inside the third.
rrca
rrca
rrca        ; Rotate three times to pass value to bits 0, 1 and 3.
or b        ; Add bits 4 and 5.
ld b, a     ; B = A. Calculated Y-coordinate.

ld a, l     ; A = lower part of the memory address. RRRC CCCC.
and $1f     ; It keeps the column.
ld c, a     ; C = A. Calculated X-coordinate.

ret

Next row memory address

The PointerHRNextLine routine takes a memory address and returns the memory address corresponding to the next row.

; ----------------------------------------------------------------
; PointerHRNextLine: gets the memory address
; corresponding to the next row.
;
; Entrada: HL -> Current address. 010T TSSS RRRC CCCC.
;
; Salida: HL -> Dirección de la fila siguiente.
;               010T TSSS RRRC CCCC.
;
; Alters the value of AF and HL registers.
; ---------------------------------------------------------------- 
PointerHRNextLine:
ld a, l     ; A = lower part of the address. RRRC CCCC.
add a, $20  ; Add one line (RRRC CCCC + 0010 0000).
ld l, a     ; L = A.
ret nc      ; If there is no carry, the row follows between 0 
            ; and 7, it exits.

; There is carry-over, the third of the screen has to be changed.
ld a, h     ; A = upper part of memory address. 010T TSSS.
add a, $08  ; Add one third (010T TSSS + 0000 1000).
ld h, a     ; H = A.

ret

Previous row memory address

The PointerHRPreviousLine routine takes a memory address and returns the memory address corresponding to the previous row.

; ----------------------------------------------------------------
; PointerHRPreviousLine: gets the memory address
; corresponding to the previous row.
;
; Entrada: HL -> Current address. 010T TSSS RRRC CCCC.
;
; Salida: HL -> Dirección de la fila anterior.
;               010T TSSS RRRC CCCC.
;
; Alters the value of AF and HL registers.
; ---------------------------------------------------------------- 
PointerHRPreviousLine:
ld a, l     ; A = lower part of the address. RRRC CCCC.
and $e0     ; It keeps the row part (1110 0000).
jr z, PointerHRPreviousLine_continue   ; If line is 0,
                                       ; change of third.

; No change of third.
ld a, l     ; A = lower part of the address, RRRC CCCC.
sub $20     ; Subtract one row (RRRC CCCC - 0010 0000).
ld l, a     ; L = A. Calculated address.

ret

PointerHRPreviousLine_continue:
; It is necessary to change the third party.
ld a, l     ; A = lower part of the address. RRRC CCCC.
or $e0      ; Set the row to 7 (RRRC CCCC or 1110 0000).
ld l, a     ; L = A. Lower part of the calculated address.

ld a, h     ; A = upper part of the address. 010T TSSS.
sub $08     ; Subtract one third (010T TSSS - 0000 1000).
ld h, a     ; H = A. Upper part of the calculated address.

ret

Next scanline

The PointerHRNextScanLine routine takes a memory address and returns the address of the next scanline.

; ----------------------------------------------------------------
; PointerHRNextScanLine: gets the memory address
; corresponding to the next scanline.
;
; Entrada: HL -> current address. 010T TSSS RRRC CCCC.
;
; Salida: HL -> address of the next scanline.
;               010T TSSS RRRC CCCC.
;
; Alters the value of AF and HL registers.
; ---------------------------------------------------------------- 
PointerHRNextScanLine:
ld a, h     ; A = upper part of the address. 010T TSSS.
and $07     ; Keeps the scanline.
cp $07      ; Check if scanline is 7.
jr z, PointerHRNextScanLine_continue     ; Yes, change of line.

; Scanline is not 7.
inc h       ; Increases the scanline by 1 and exits.

ret

PointerHRNextScanLine_continue:
; The row must be changed.
ld a, l     ; A = lower part of the address. RRRC CCCC.
add a, $20  ; Add one line (RRRC CCCC + 0010 0000).
ld l, a     ; L = A.
ld a, h     ; A = upper part of the address. 010T TSSS.
jr nc, PointerHRNextScanLine_end  ; If there is no carriage, skip
                                  ; to finish the calculation.

; There is carriage, it is necessary to change the third party.
add a, $08  ; Add one to the third (010T TSSS + 0000 1000).

PointerHRNextScanLine_end:
and $f8     ; Keeps the fixed part and the third part.
            ; Set the scanline to 0.
ld h, a     ; H = A. Calculated address.

ret

To test the routine, let’s use a small program to see how it draws. Contrary to what we saw in the first example, now we paint a scanline followed by the one right behind it.

org $8000

ld hl, $4000    ; HL = VideoRAM start address.
ld b, $08       ; B = to draw 8 scanlines.

loop:
ld (hl), $aa    ; Loads the $AA pattern on screen.
call PointerHRNextScanLine  ; Advances to next scanline.
djnz loop       ; Loop until B reaches 0.

ret

end	 $8000

If we run the program, it draws the $AA pattern on the first character. The first example did it on the first scanline of the first 8 rows.

As we did in the first example, we can load multiples of $08 in B to see how the program is drawing; $08, $10, $18, $20, $28, $30, $38, $40, $48….

Previous Scanline

The PointerHRPreviousScanLine routine takes a memory address and returns the memory address corresponding to the previous scanline.

; ----------------------------------------------------------------
; PointerHRPreviousScanLine: gets the memory address
; corresponding to the previous scanline.
;
; Entrada: HL -> current address. 010T TSSS RRRC CCCC.
;
; Salida: HL -> address of previous scanline.
;               010T TSSS RRRC CCCC.
;
; Alters the value of AF and HL registers.
; ---------------------------------------------------------------- 
PointerHRPreviousScanLine:
ld a, h     ; A = upper part of the address. 010T TSSS.
and $07     ; Keeps the scanline.
or a        ; Check if it is at 0.
jr z, PointerHRPreviousScanLine_continue  ; Yes, change line.

; No change of line.
dec h       ; Decrements the scanline and exits.

ret

PointerHRPreviousScanLine_continue:
ld a, l     ; A = lower part of the address. RRRC CCCC.
and $e0     ; Keeps the row part.
or a        ; Check if it is at 0.
jr z, PointerHRPreviousScanLine_change  ; Yes, change third.

; No need to change third.
ld a, l     ; A = lower part of the address. RRRC CCCC.
sub $20     ; Subtract one row, (RRRC CCCC - 0010 0000).
ld l, a     ; L = A.
jr PointerHRPreviousScanLine_end  ; Skip to end of calculation.

PointerHRPreviousScanLine_change:
; Need to change third.
ld a, l     ; A = lower part of the address. RRRC CCCC.
or $e0      ; Sets the line to 7.
ld l, a     ; L = A.

ld a, h     ; A = upper part of the address. 010T TSSS.
sub $08     ; Subtract one to the third.
ld h, a     ; H = A.

PointerHRPreviousScanLine_end:
ld a, h     ; A = upper part of the address. 010T TSSS.
and $F8     ; Keeps the fixed part and the third part.
or $07      ; Set the scanline to 7.
ld h, a     ; H = A.

ret

And in order to test the routine, another simple program.

org $8000

ld hl, $57ff    ; HL = VideoRAM end address.
ld b, $08       ; B = to draw 8 scanlines.

loop:
ld (hl), $aa    ; Loads the $AA pattern on the screen.
call PointerHRPreviousScanLine  ; Back to previous scanline.
djnz loop       ; Loop until B reaches 0.

ret

end	 $8000

Attribute address from character coordinates

The CharCoord2PointerAttr routine takes character coordinates and gets the corresponding attribute memory address.

; ----------------------------------------------------------------
; CharCoord2PointerAttr: takes character coordinates and obtains
; the memory address of the corresponding attribute.
;
; Entrada: B -> Y-coordinate
;          C -> X-coordinate
;
; Salida: HL -> Attribute memory address.
;               0101 10TT RRRC CCCC.
;
; Alters the value of AF and HL registers.
; ---------------------------------------------------------------- 
CharCoord2PointerAttr:
ld   a, b    ; Load row in A
and  $18     ; Keeps the third bits
rrca
rrca
rrca         ; Pass them to bits 0 and 1
or   $58     ; Adds the fixed bits of the high part of the address
ld   h, a    ; H = 0101 10TT
ld   a, b    ; Load row in A
and  $07     ; Keeps the bits of the row
rrca
rrca
rrca         ; Pass them to bits 5, 6, and 7
or   c       ; Adds the bits of the column
ld   l, a    ; L = RRRC CCCC

ret          ; HL = 0101 10TT RRRC CCCC (attribute address)

Social networks can be wonderful; NathanielSalis made me see that in this routine we can save bytes and clock cycles by dispensing with three rotations. The code would look like this:

; ----------------------------------------------------------------
; CharCoord2PointerAttr: takes character coordinates and obtains
; the memory address of the corresponding attribute.
;
; Entrada: B -> Y-coordinate
;          C -> X-coordinate
;
; Salida: HL -> Attribute memory address.
;               0101 10TT RRRC CCCC.
;
; Alters the value of AF and HL registers.
; ---------------------------------------------------------------- 
CharCoord2PointerAttr:
ld   a, b    ; Load row in A
; Before keeping the bits of the third, we carry out the rotations
rrca
rrca         ; Passes the bits of the third to bits 0 and 1
rrca         ; and those of the row to bits 5, 6 and 7
ld   l, a    ; Load the result in L
and  $03     ; A = bits of the third
or   $58     ; Adds the fixed bits of the high part of the address
ld   h, a    ; H = 0101 10TT
ld   a, l    ; A = row in bits 5, 6 and 7 and third in bits 0 and 1
and  $e0     ; Keeps the bits of the line
or   c       ; Adds the bits of the column
ld   l, a    ; L = RRRC CCCC

ret          ; HL = 0101 10TT RRRC CCCC (attribute address)

The first version of the routine occupies 18 bytes and takes 75 cycles to execute, while the second occupies 16 bytes and takes 67 cycles to execute, so we save two bytes and 8 cycles.

Character coordinates from attribute address

The PointerAttr2CharCoord routine takes a memory address of an attribute and returns the corresponding character coordinates.

; ----------------------------------------------------------------
; PointerAttr2CharCoord: takes an attribute memory address 
; and returns the corresponding character coordinates.
;
; Entrada: HL -> Attribute memory address.
;                0101 10TT RRRC CCCC.
;
; Salida:   B -> Y-coordinate
;           C -> X-coordinate
;
; Alters the value of AF and HL registers.
; ---------------------------------------------------------------- 
PointerAttr2CharCoord:
ld   a, h    ; Loads the upper part of the address in A
and  $03     ; Keeps the bits of the third
rlca
rlca
rlca         ; Passes them to bits 3 and 4
ld   b, a    ; B = 000TT000
ld   a, l    ; Load the lower part of the address in A
and  $e0     ; Keeps the bits in the row
rlca
rlca
rlca         ; Passes them to bits 0, 1 and 2
or   b       ; Add the third
ld   b, a    ; B = TTCCC (Y-coordinate)
ld   a, l    ; Load the lower part of the address in A
and  $1f     ; It keeps the bits of the column
ld   c, a    ; C = 000CCCCC (X-coordinate)

ret          ; BC = character coordinates

Attribute address from graphic area address

The PointerHR2PointerAttr routine takes a memory address from the graphic area and returns the corresponding attribute memory address.

; ----------------------------------------------------------------
; PointerHR2PointerAttr: takes a memory address of the graphic area 
; and returns the memory address of the corresponding attribute.
;
; Entrada: HL -> Memory address of the graphic area.
;                010T TSSS RRRC CCCC.
;
; Salida:  HL -> Attribute memory address.
;                0101 10TT RRRC CCCC.
;
; Alters the value of AF and HL registers.
; ---------------------------------------------------------------- 
PointerHR2PointerAttr:
ld   a, h    ; Loads the upper part of the address in A
and  $18     ; Keeps the bits of the third
rrca
rrca
rrca         ; Passes them to bits 0 and 1
or   $58     ; Add the fixed part
ld   h, a    ; A = 010110TT

ret          ; HL = attribute memory address

Graphic area address from attribute address

The PointerAttr2PointerHR routine takes an attribute memory address and returns the memory address of the graphic area corresponding to scanline 0.

; ----------------------------------------------------------------
; PointerAttr2PointerHR: takes a memory address of attribute
; and returns the memory address of the corresponding graphic area
; to the first scanline.
;
; Entrada: HL -> Attribute memory address.
;                0101 10TT RRRC CCCC.
;
; Salida:  HL -> Memory address of the graphic area.
;                010T TSSS RRRC CCCC.
;
; Alters the value of AF and HL registers.
; ---------------------------------------------------------------- 
PointerAttr2PointerHR:
ld   a, h    ; Loads the upper part of the address in A
and  $03     ; Keeps the bits of the third
rlca
rlca
rlca         ; Passes them to bits 0 and 1
or   $40     ; Add the fixed part
ld   h, a    ; A = 010TT000

ret          ; HL = address of the first scanline

Conclusion

Everything I have put here, I have learned by following the assembler course found at speccy.org and reading the book Código Máquina del ZX-Spectrum by Jesús Alonso Cano.

The routines shown here are the exercises I have done to practice what I have learned.

Translated with DeepL.

Table of contents

• What are BCD numbers?
• How to use them?
• How do you paint them?
• Conclusion

What are BCD numbers?

BCD numbers are represented in a natural way, as we would see them; the hexadecimal 99 represents the decimal 99.

To achieve this, a byte can represent numbers from 0 to 99 by dividing the byte into two nibbles (4 bits). Each nibble can represent numbers from 0 to 9.

In this way, the hexadecimal 10, which in decimal is 16, in BCD represents the decimal 10. In other words, we see hexadecimal numbers as if they were decimal numbers.

How to use them?

To represent a 10-digit number, 5 bytes are needed. An extra byte can be used to indicate the position of the decimal point, in order to work with decimals. BCD numbers are used to operate with numbers of more than 16 bits.

When operating with BCD numbers, the DAA (Decimal Adjust Accumulator) instruction must be taken into account. DAA makes adjustments to the results of operations with BCD numbers, and works as follows:

• Check bits 0, 1, 2 and 3. If they contain a non-BCD digit (greater than 9) or the H flag is set, add or subtract, depending on the operation, 06h (0000 0110b) to the byte.
• Check bits 4, 5, 6 and 7. If they contain a non-BCD digit (greater than 9) or the C flag is set, add or subtract, depending on the operation, 60h (0110 0000b) to the byte.

Thus, if we have $09 and add $01, the result is $0A. After executing DAA, the result is $10. After each arithmetic instruction, increment or decrement, DAA must be executed.

ld  a, $09    ; A = $09
inc a         ; A = $0A
daa           ; A = $10

dec a         ; A = $0F
daa           ; A = $09

add a, $03    ; A = $0C
daa           ; A = $12

sub $03       ; A = $0F
daa           ; A = $09

How do you paint them?

The way to obtain the ASCII code of each nibble (four bits) is relatively simple.

The routine shown below receives a BCD number in register B and displays it on the screen.

; -----------------------------------------------------
; Prints a BCD number on the screen.
; Input: B -> BCD number to be printed.
; Alters the value of the AF register.
; ----------------------------------------------------- 
PrintBCD:
ld   a, b   ; Loads in A the number to print
and  $f0    ; Keeps the upper nibble
rrca
rrca
rrca
rrca        ; Rotates it four times to move it to the lower nibble
add  a, '0' ; Adds the ASCII of the 0 to get the ASCII of the number
rst  $10    ; Display the number on the screen (ZX Spectrum)
; call $bb5a  ; Display the number on the screen (Amstrad CPC)

ld   a, b   ; Reloads the number to be printed in A
and  $0f    ; Keeps the bottom nibble
add  a, '0' ; Adds the ASCII of the 0 to get the ASCII of the number
rst  $10    ; Display the number on the screen (ZX Spectrum)
; call $bb5a  ; Displays the number on the screen (Amstrad CPC)
 
ret         ; Exits

RST $10, in ZX Spectrum, prints on screen the character corresponding to the Ascii code loaded in register A. CALL $BB5A does the same in Amstrad CPC.

Conclusion

Working with this type of encoding is relatively simple and allows us to work with large numbers. In exchange, we need more bytes and more processing time.

We have reached the last chapter. We are going to make a couple of tweaks that, while not entirely necessary, I think might be of interest.

We will add an option in the menu to allow players to select the maximum number of tables they can have.

As for the tables, currently it is necessary to make all possible moves (occupy all the cells) to complete the point, although sometimes we already know that it is not possible to win and it is a table. We are going to implement the detection of tables to detect when it is no longer possible to win and end the point.

We will propose some modifications that can save some bytes and clock cycles.

We will modify the Spectrum’s moves to make it harder to beat.

Finally, we’ll add the loading screen.

Translation by Felipe Monge Corbalán

Table of contents

• Tables menu
• Table detection
• We save bytes and clock cycles
  • Same tile for both players
• Spectrum movement
• Difficulty
• Loading screen
• ZX Spectrum Assembly, Tic-Tac-Toe
• Useful links

Tables menu

Currently, the maximum number of tables is declared in the MAXTIES constant in var.asm; we delete it.

Locate MaxPoints and add the new variable for the tables below it:

MaxTies:     db $05        ; Maximum tables

Locate TitleEspamatica and add the Tables menu option just above it:

TitleOptionTies:   db $10, INK7, $16, $10, $08, "4. ", $10, INK6
                   defm "Tables"

To make it more symmetrical, we locate Title3InStripe and replace $16, $02, $09 at the end of the line with $16, $04, $09.

In Main.asm, let’s add the handling of the new menu item. Locate menu_Time and replace JR NZ, menu_op two lines down:

jr   nz, menu_Ties         ; No, skip

Locate menu_TimeDo and three lines down, after JR menu_op, add the handling of the new menu item:

menu_Ties:  
cp   KEY4                  ; Pushed 4?
jr   nz, menu_op           ; No, loop
ld   a, (MaxTies)          ; A = tables
add  a, $02                ; A += 2
cp   $0a                   ; A < 10?
jr   c, menu_TiesDo        ; Yes, skip
ld   a, $03                ; A = 3
menu_TiesDo:
ld   (MaxTies), a          ; Update tables
jr   menu_op               ; Loop

If the four key has been pressed, the maximum number of tables is increased by two, if it is greater than nine, it is reduced to three and loaded into memory.

Both this range of values and the difference between one value and the other can be modified as required. You can also change it in points and time.

Once we have the maximum number of tables in memory, we need to use them. Find the loop_reset tag, the LD B, MAXTIES line and replace it with the following:

ld   a, (MaxTies)          ; A = maximum tables
ld   b, a                  ; B = A

All that remains is to print the selected value. In screen.asm, locate PrintOptions and add the following lines just above JP PrintBCD:

call PrintBCD              ; Paints it
ld   b, INI_TOP-$10        ; B = coord Y
call AT                    ; Position cursor
ld   hl, MaxTies           ; HL = time value

We compile, load the emulator and check that we can now define the number of tables and that the game ends when the number of tables is reached.

Table detection

Currently, in order for boards to be detected, all cells must be occupied and there must be no tic-tac-toe. In reality, it is possible to know if the point will end in a board before the board is full.

We go to game.asm and implement table detection.

To know if there is a possibility of a move, we just need to know if there is any combination left in which the cells are occupied by only one player or by no player at all.

; -------------------------------------------------------------------
; Check for tables.
; In order to check if there are tables.
;
; Output: Z  -> No tables.
;         NZ -> There are tables.
;
; Alters the value of the AF, BC, DE, HL and IX registers.
; -------------------------------------------------------------------
CheckTies:
ld   b, $f0                ; B = single-player cell mask
ld   c, $0f                ; B = cell mask another player

We load in B the mask to keep the cells occupied by one player, and in C the mask for the other player.

checkTies_check123:
ld   hl, Grid              ; HL = grid address
ld   a, (hl)               ; A = cell value 1
inc  hl                    ; HL = cell address 2
add  a, (hl)               ; A+= cell value 2
inc  hl                    ; HL = cell address 3
add  a, (hl)               ; A+= cell value 2
ld   d, a                  ; Preserve A in D
and  b                     ; A = cells occupied by a player
ret  z                     ; None, exits
ld   a, d                  ; Retrieves A from D
and  c                     ; A = cells occupied by another player
ret  z                     ; None, exits

We place HL on the grid, add the value of the three cells in A and increment HL to move from one cell to another. We check if there are any cells occupied by a player, and if not, we leave. If so, we check if there are any cells occupied by the other player, and if not, we leave.

The next two checks have the same structure.

checkTies_check456:
inc  hl                    ; A = cell address 4
ld   a, (hl)               ; A = cell value 4
inc  hl                    ; HL = cell address 5
add  a, (hl)               ; A+= cell value 5
inc  hl                    ; HL = cell address 6
add  a, (hl)               ; A+= cell value 6
ld   d, a                  ; Preserve A in D
and  b                     ; A = cells occupied by a player
ret  z                     ; None, exits
ld   a, d                  ; Retrieves A from D
and  c                     ; A = cells occupied by another player
ret  z                     ; None, exits

checkTies_check789:
inc  hl                    ; A = cell address 7
ld   a, (hl)               ; A = cell value 7
inc  hl                    ; HL = cell address 8
add  a, (hl)               ; A+= cell value 8
inc  hl                    ; HL = cell address 9
add  a, (hl)               ; A+= cell value 9
ld   d, a                  ; Preserve A in D
and  b                     ; A = cells occupied by a player
ret  z                     ; None, exits
ld   a, d                  ; Retrieves A from D
and  c                     ; A = cells occupied by another player
ret  z                     ; None, exits

Look closely at how we go through the cells with HL, this helps us to save a few bytes in an implementation we did earlier.

The following checks cannot be done by changing cells with HL, as they are not numerically contiguous; we use IX.

checkTies_check147:
ld   ix, Grid-$01          ; IX = address Grid - 1
ld   a, (ix+$01)           ; A = cell value 1
add  a, (ix+$04)           ; A+= cell value 4
add  a, (ix+$07)           ; A+= cell value 7
ld   d, a                  ; Preserve A in D
and  b                     ; A = cells occupied by a player
ret  z                     ; None, exits
ld   a, d                  ; Retrieves A from D
and  c                     ; A = cells occupied by another player
ret  z                     ; None, exits

The rest of the checks follow the same structure.

checkTies_check258:
ld   a, (ix+$02)           ; A = cell value 2
add  a, (ix+$05)           ; A+= cell value 5
add  a, (ix+$08)           ; A+= cell value 8
ld   d, a                  ; Preserve A in D
and  b                     ; A = cells occupied by a player
ret  z                     ; None, exits
ld   a, d                  ; Retrieves A from D
and  c                     ; A = cells occupied by another player
ret  z                     ; None, exits

checkTies_check369:
ld   a, (ix+$03)           ; A = cell value 3
add  a, (ix+$06)           ; A+= cell value 6
add  a, (ix+$09)           ; A+= cell value 9
ld   d, a                  ; Preserve A in D
and  b                     ; A = cells occupied by a player
ret  z                     ; None, exits
ld   a, d                  ; Retrieves A from D
and  c                     ; A = cells occupied by another player
ret  z                     ; None, exits

checkTies_check159:
ld   a, (ix+$01)           ; A = cell value 1
add  a, (ix+$05)           ; A+= cell value 5
add  a, (ix+$09)           ; A+= cell value 9
ld   d, a                  ; Preserve A in D
and  b                     ; A = cells occupied by a player
ret  z                     ; None, exits
ld   a, d                  ; Retrieves A from D
and  c                     ; A = cells occupied by another player
ret  z                     ; None, exits

checkTies_check357:
ld   a, (ix+$03)           ; A = cell value 3
add  a, (ix+$05)           ; A+= cell value 5
add  a, (ix+$07)           ; A+= cell value 7
ld   d, a                  ; Preserve A in D
and  b                     ; A = cells occupied by a player
ret  z                     ; None, exits
ld   a, d                  ; Retrieves A from D
and  c                     ; A = cells occupied by another player
ret                        ; Exits with Z in correct state

With this we now have the prediction of whether there will be tables, all that remains is to go to main.asm and use it.

Find loop_tie and three lines down substitute:

ld   a, $09                ; A = 9
cp   (hl)                  ; Counter = 9?
jr   nz, loop_cont         ; No, skip

By:

call CheckTies             ; Any possible movement?
jr   z, loop_cont          ; No, skip

We no longer have to wait until the board is full to know if there are checkers or not. We call CheckTies and if there are no boards we continue with the point.

We compile, load the emulator and see the results.

You may see some behaviour that makes you think something is wrong. You see rows one, two, three free, but you know that the Spectrum will occupy one cell, then you another, and so it should mark tables.

The system is predicting, not guessing. Imagine that there are two free cells in a row and it is the turn of the player whose cell is not occupied to move. Well, he will occupy one of the cells, so we already know it is a draw, but imagine that the player rests on his laurels and loses his turn, the other player occupies another cell and there is only one free cell, and it is still not possible to predict draws, if the other player falls asleep again, he loses his turn again and the first player gets three in a row.

We save bytes and clock cycles

We will implement several modifications to save bytes and clock cycles.

The first of these will be in game.asm, on the set of CheckWinner and ZxMove routines, applying the way we have implemented CheckTies to the horizontal lines, the numerically contiguous ones.

Go to the CheckWinner_check tag and find the following lines:

ld   a, (ix+1)             ; A = cell 1
add  a, (ix+2)             ; A+= cell 2
add  a, (ix+3)             ; A+= cell 3

And we replace them with:

ld   hl, Grid              ; HL = cell address 1
ld   a, (hl)               ; A = cell value 1
inc  hl                    ; HL = cell address 2
add  a, (hl)               ; A+= cell value 2
inc  hl                    ; HL = cell address 3
add  a, (hl)               ; A+= cell value 3

We locate the lines:

ld   a, (ix+4)             ; A = cell 4
add  a, (ix+5)             ; A+= cell 5
add  a, (ix+6)             ; A+= cell 6

And we replace them with:

inc  hl                    ; HL = cell address 4
ld   a, (hl)               ; A = cell value 4
inc  hl                    ; HL = cell address 5
add  a, (hl)               ; A+= cell value 5
inc  hl                    ; HL = cell address 6
add  a, (hl)               ; A+= cell value 6

We locate the lines:

ld   a, (ix+7)             ; A = cell 7
add  a, (ix+8)             ; A+= cell 8
add  a, (ix+9)             ; A+= cell 9

And we replace them with:

inc  hl                    ; HL = cell address 7
ld   a, (hl)               ; A = cell value 7
inc  hl                    ; HL = cell address 8
add  a, (hl)               ; A+= cell value 8
inc  hl                    ; HL = cell address 9
add  a, (hl)               ; A+= cell value 9

This part is ready, add the comments of the routine to HL as the affected register.

This is the comparison between the two versions:

As you can see, we save fifty clock cycles and seven bytes. We compile, load into the emulator and see that it still works.

We continue to modify ZxMove, specifically two parts of this routine set. We locate zxMoveToWin_123 and replace it:

ld   a, (ix+$01)           ; A = cell value 1
add  a, (ix+$02)           ; A+= cell value 2
add  a, (ix+$03)           ; A+= cell value 3

By:

ld   hl, Grid              ; HL = cell address 1
ld   a, (hl)               ; A = cell value 1
inc  hl                    ; HL = cell address 2
add  a, (hl)               ; A+= cell value 2
inc  hl                    ; HL = cell address 3
add  a, (hl)               ; A+= cell value 3

Locate zxMoveToWin_456 and replace it:

ld   a, (ix+$04)           ; A = cell value 4
add  a, (ix+$05)           ; A+= cell value 5
add  a, (ix+$06)           ; A+= cell value 6

By:

ld   hl, Grid+$03          ; HL = cell address 4
ld   a, (hl)               ; A = cell value 4
inc  hl                    ; HL = cell address 5
add  a, (hl)               ; A+= cell value 5
inc  hl                    ; HL = cell address 6
add  a, (hl)               ; A+= cell value 6

Locate zxMoveToWin_789 and replace it:

ld   a, (ix+$07)           ; A = cell value 7
add  a, (ix+$08)           ; A+= cell value 8
add  a, (ix+$09)           ; A+= cell value 9

By:

ld   hl, Grid+$06          ; HL = cell address 7
ld   a, (hl)               ; A = cell value 7
inc  hl                    ; HL = cell address 8
add  a, (hl)               ; A+= cell value 8
inc  hl                    ; HL = cell address 9
add  a, (hl)               ; A+= cell value 9

We have now completed the first part. The main difference with CheckTies and CheckWinner is that although they are numerically contiguous cells, the move from cell three to cell four and from cell six to cell seven is not with INC HL, as ToMove changes the value of HL.

Locate zxMoveAttack_123 and replace it:

ld   a, (ix+$01)           ; A = cell value 1
add  a, (ix+$02)           ; A+= cell value 2
add  a, (ix+$03)           ; A+= cell value 3

By:

ld   hl, Grid              ; HL = cell address 1
ld   a, (hl)               ; A = cell value 1
inc  hl                    ; HL = cell address 2
add  a, (hl)               ; A+= cell value 2
inc  hl                    ; HL = cell address 3
add  a, (hl)               ; A+= cell value 3

Locate zxMoveAttack_456 and replace it:

ld   a, (ix+$04)           ; A = cell value 4
add  a, (ix+$05)           ; A+= cell value 5
add  a, (ix+$06)           ; A+= cell value 6

By:

ld   hl, Grid+$03          ; HL = cell address 4
ld   a, (hl)               ; A = cell value 4
inc  hl                    ; HL = cell address 5
add  a, (hl)               ; A+= cell value 5
inc  hl                    ; HL = cell address 6
add  a, (hl)               ; A+= cell value 6

Locate zxMoveAttack_789 and replace it:

ld   a, (ix+$07)           ; A = cell value 7
add  a, (ix+$08)           ; A+= cell value 8
add  a, (ix+$09)           ; A+= cell value 9

By:

ld   hl, Grid+$06          ; HL = cell address 7
ld   a, (hl)               ; A = cell value 7
inc  hl                    ; HL = cell address 8
add  a, (hl)               ; A+= cell value 8
inc  hl                    ; HL = cell address 9
add  a, (hl)               ; A+= cell value 9

We make another modification in zxMoveDefence_cornerBlock34 and zxMoveDefence_cornerBlock67 that saves clock cycles but no bytes.

Replacement in zxMoveDefence_cornerBlock34:

ld   a, (ix+$03)           ; A = cell value 3
add  a, (ix+$04)           ; A+= cell value 4

By:

ld   hl, Grid+$02          ; A = cell address 3
ld   a, (hl)               ; A = cell value 3
inc  hl                    ; HL = cell address 4
add  a, (hl)               ; A+= cell value 4

In zxMoveDefence_cornerBlock67 we replace:

ld   a, (ix+$06)           ; A = cell value 6
add  a, (ix+$07)           ; A+= cell value 7

By:

ld   hl, Grid+$05          ; A = cell address 6
ld   a, (hl)               ; A = cell value 6
inc  hl                    ; HL = cell address 7
add  a, (hl)               ; A+= cell value 7

The changes in game.asm are done. As I said, add HL as affected registry in the comments of the routine, we forgot it before because the HL registry was already affected by the zxMoveGeneric routine.

This is the comparison between the two versions of ZxMove:

Version two occupies six bytes less and takes a hundred cycles less than version one, which seems small when we compare it with the bytes saved by CheckWinner with fewer modifications. Remember that there the transition from cell three to cell four and from cell six to cell seven is done with INC HL, which we cannot do here.

The difference between INC HL and LD HL, Grid is four clock cycles and two bytes, and that limits our savings.

Same tile for both players

If we have capacity problems, which we don’t, we can save another handful of bytes by painting the same tile in a different colour for both players.

We go to sprite.asm, comment out the Sprite_P2 definition and put the Sprite_CROSS, Sprite_SLASH and Sprite_MINUS definitions at the top of the file, like this:

; -------------------------------------------------------------------
; File: sprite.asm
;
; Definition of graphs.
; -------------------------------------------------------------------
; Crosshead Sprite
Sprite_CROSS:
db $18, $18, $18, $ff, $ff, $18, $18, $18 ; $90

; Sprite of the vertical line
Sprite_SLASH:
db $18, $18, $18, $18, $18, $18, $18, $18 ; $91

; Sprite of the horizontal line
Sprite_MINUS:
db $00, $00, $00, $ff, $ff, $00, $00, $00 ; $92

; Player 1 Sprite
Sprite_P1:
db $c0, $e0, $70, $38, $1c, $0e, $07, $03 ; $93
db $03, $07, $0e, $1c, $38, $70, $e0, $c0 ; $94

; ; Player Sprite 2
; Sprite_P2:
; db $03, $0f, $1c, $30, $60, $60, $c0, $c0 ; $95 Up/Left
; db $c0, $f0, $38, $0c, $06, $06, $03, $03 ; $96 Top/Right
; db $c0, $c0, $60, $60, $30, $1c, $0f, $03 ; $97 Down/Left
; db $03, $03, $06, $06, $0c, $38, $f0, $c0 ; $98 Down/Right

Commenting on player two’s sprite not only forces us to change the routine that paints the tiles, it also forces us to change the routine that paints the board as the UDGs change. We have uploaded the board sprites above so that we can only change the board painting routine once, and so that if we decide to repaint the two tiles later, it won’t be affected.

By commenting out Sprite_P2, we save thirty-two bytes. It doesn’t sound like much, but in certain situations it can save us.

We go to var.asm and change the definition of Board_1 and _2 and leave them as they are:

; Vertical lines of the board.
Board_1:
db $12, $00, $13, $00        
db $20, $20, $20, $20, $91, $20, $20, $20, $20, $91, $20, $20, $20
db $20, $ff

; Horizontal lines of the board.
Board_2:        
db $92, $92, $92, $92, $90, $92, $92, $92, $92, $90, $92, $92, $92
db $92, $ff

We compile, load into the emulator and see the result, which is the mess we made.

That player two’s tile is painted wrong is to be expected, but what about the board? We have changed the position of the sprite definition, but UDG is still pointing to Sprite_P1.

We go to main.asm and under the Main tag we replace:

ld   hl, Sprite_P1         ; HL = address Sprite_P1

By:

ld   hl, Sprite_CROSS      ; HL = address Sprite_CROSS

Also change the comment in the line below.

We compile, load it into the emulator and see that the board looks good, but the parts don’t. Don’t worry, this is to be expected.

We are going to modify the routine that paints the tiles so that it does it well, or not, you can leave it as it is; three in a bloody line.

We locate printOXO_X in screen.asm and the lines where the UDG is loaded in A. We add three to the value it loads:

ld a, $90 becomes ld a, $93
ld a, $91 becomes ld a, $94

We locate printOXO_Y and the lines on which the UDG is loaded in A. We add three to the value it loads:

ld a, $92 becomes ld a, $95
ld a, $93 becomes ld a, $96
ld a, $94 becomes ld a, $97
ld a, $95 becomes ld a, $98

So if we decided to paint two different tiles, the circle would be painted.

As we are now in the situation of painting a single tile, we comment on the lines:

ld   a, $95                ; A = 1st sprite
ld   a, $98                ; A = 4th sprite

And below that we add the line:

ld   a, $93                ; A = 1st sprite

We comment on the lines:

ld   a, $96                ; A = 2nd sprite
ld   a, $97                ; A = 3rd sprite

            And below that we add the line:

ld   a, $94                ; A = 2nd sprite

A bit of a mess, isn’t it? Here’s what it looks like:

printOXO_X:
ld   a, INKPLAYER1         ; A = ink player 1
call INK                   ; Change ink
ld   a, $93                ; A = 1st sprite
rst  $10                   ; Paints it
ld   a, $94                ; A = 2nd sprite
rst  $10                   ; Paints it
dec  b                     ; B = bottom line
call AT                    ; Position cursor
ld   a, $94                ; A = 2nd sprite
rst  $10                   ; Paints it
ld   a, $93                ; A = 2nd sprite
rst  $10                   ; Paints it
ret                        ; Exits

printOXO_Y:
ld   a, INKPLAYER2         ; A = ink player 2
call INK                   ; Change ink
; ld   a, $95                ; A = 1st sprite
ld   a, $93                ; A = 1st sprite
rst  $10                   ; Paints it
; ld   a, $96                ; A = 2nd sprite
ld   a, $94                ; A = 2nd sprite
rst  $10                   ; Paints it
dec  b                     ; B = bottom line
call AT                    ; Position cursor
; ld   a, $97                ; A = 3rd sprite
ld   a, $94                ; A = 2nd sprite
rst  $10                   ; Paints it
; ld   a, $98                ; A = 4th sprite
ld   a, $93                ; A = 1st sprite
rst  $10                   ; Paints it
ret                        ; Exits

So, if we want to redraw the two pieces, in sprite.asm we uncomment Sprite_P2, and in printOXO_Y we alternate the comments on the LD A, … lines.

This will paint the pieces on the board, but not in the information part of the game.

We go back to var.asm and modify player1_figure to look like this:

player1_figure:   db $16, $04, $00, $90, $91, $0d, $91, $90

And we leave it at that:

player1_figure:   db $16, $04, $00, $93, $94, $0d, $94, $93

We modify player2_figure so that it now looks like this:

player2_figure:   db $16, $04, $1b, $92, $93, $16, $05, $1b
                  db $94, $95, $ff

And we leave it at that:

player2_figure:   db $16, $04, $1b, $93, $94, $16, $05, $1b
                  db $94, $93, $ff

Finally, we add the annotated definition for painting different tiles.

; player2_figure:   db $16, $04, $1b, $95, $96, $16, $05, $1b
;                   db $97, $98, $ff

We compile, load in the emulator and see the results.

You can paint the same tile in a different colour for both players, or you can paint a different colour for each player. If we were using a black and white TV, there would be no doubt.

If you keep all the changes, we have saved forty-five bytes and one hundred and fifty clock cycles. If you decide to paint different tiles for each player, the byte saving is thirteen bytes.

Spectrum movement

If you have played several games against the Spectrum, you will have worked out how to beat it every time you start the game, because there is at least one move that the Spectrum does not know how to defend, we have not programmed it.

The specific move is to occupy two corner cells: two and six or six and eight. If we occupy cell two, the Spectrum occupies cell five, we move to cell six and the Spectrum moves to cell seven, we move to cell three and we have two tic-tac-toe moves: cells one, two and three and cells three, six and nine.

In game.asm we locate zxMoveAttack_123 and above it we implement the lines that make it impossible to beat the Spectrum with this move.

; -------------------------------------------------------------------
; Defensive corner movement.
; -------------------------------------------------------------------
zxMoveDefence_corner24:
ld   a, (ix+$02)           ; A = cell value 2
add  a, (ix+$04)           ; A+= cell value 4
cp   b                     ; A = B?
jr   nz, zxMoveDefence_corner26 ; No, skip
ld   c, KEY1               ; C = key 1
call ToMove                ; Move to cell 1
ret  z                     ; If correct, exits

We check if player one has occupied squares two and four, in which case we move to square one if possible.

The rest of the checks follow the same structure.

zxMoveDefence_corner26:
ld   a, (ix+$02)           ; A = cell value 2
add  a, (ix+$06)           ; A+= cell value 6
cp   b                     ; A = B?
jr   nz, zxMoveDefence_corner84 ; No, skip
ld   c, KEY3               ; C = key 3
call ToMove                ; Move to cell 3
ret  z                     ; If correct, exits
zxMoveDefence_corner84:
ld   a, (ix+$08)           ; A = cell value 8
add  a, (ix+$04)           ; A+= cell value 4
cp   b                     ; A = B?
jr   nz, zxMoveDefence_corner86 ; No, skip
ld   c, KEY7               ; C = key 7
call ToMove                ; Move to cell 3
ret  z                     ; If correct, exits
zxMoveDefence_corner86:
ld   a, (ix+$08)           ; A = cell value 8
add  a, (ix+$06)           ; A+= cell value 6
cp   b                     ; A = B?
jr   nz, zxMoveAttack_123  ; No, skip
ld   c, KEY9               ; C = key 9
call ToMove                ; Move to cell nine
ret  z                     ; If correct, exits

Although the play is in two corners, we cover all four.

Just above zxMoveDefence_cornerBlock2938Cont is the JR NZ line, zxMoveAttack_123, we modify it and leave it as it is:

jr   nz, zxMoveDefence_corner24 ; No, no mov cross, skip

If you compile and play some games against Spectrum, you will see that it is no longer possible to beat him with this move, but it is still possible to beat him, there are still moves that he does not know how to defend.

Difficulty

Now it is more difficult to beat the Spectrum, we have to wait for him to start the game and depending on the move he makes, we can beat him.

We will add another option to the menu to be able to choose the level of difficulty: one to not cover the play in the corner, two to cover the play in the corner.

In var.asm, after MaxTies, we add the variable for the level of difficulty:

Level:       db $02        ; Difficulty level

When a new menu item is added, it is appended to the Spamatica line. We move all the menu items up one line, like this:

TitleOptionStart:  db $10, INK1, $13, $01, $16, $07, $08, "0. "
                   db $10, INK5
                   defm "Start"
TitleOptionPlayer: db $10, INK7, $13, $01, $16, $09, $08, "1. "
                   db $10, INK6
                   defm "Players"
TitleOptionPoint:  db $10, INK7, $16, $0b, $08, "2. ", $10, INK6
                   defm "Points"
TitleOptionTime:   db $10, INK7, $16, $0d, $08, "3. ", $10, INK6
                   defm "Time"
TitleOptionTies:   db $10, INK7, $16, $0f, $08, "4. ", $10, INK6
                   defm "Tables"

After the definition of TitleOptionTies, we add the definition of Difficulty:

TitleOptionLevel:  db $10, INK7, $16, $11, $08, "5. ", $10, INK6
                   defm "Difficulty"

In screen.asm we find PrintOptions and subtract one from all Y coordinate assignments:

LD B, INI_TOP-$0A go to LD B,INI_TOP-$09
LD B, INI_TOP-$0C go to LD B,INI_TOP-$0B
LD B, INI_TOP-$0E go to LD B,INI_TOP-$0D
LD B, INI_TOP-$10 go to LD B,INI_TOP-$0F

Above JP PrintBCD we add the following lines:

call PrintBCD              ; Paints it
ld   b, INI_TOP-$11        ; B = coord Y
call AT                    ; Position cursor
ld   hl, Level             ; HL = difficulty value

The final aspect of the routine is as follows:

; -------------------------------------------------------------------
; Paint the values of the options.
;
; Alters the value of the AF, BC and HL registers.
; -------------------------------------------------------------------
PrintOptions:
ld   a, INK4               ; A = green ink
call INK                   ; Change ink
ld   b, INI_TOP-$09        ; B = coord Y
ld   c, INI_LEFT-$15       ; C = coord X
call AT                    ; Position cursor
ld   hl, MaxPlayers        ; HL = value players
call PrintBCD              ; Paints it
ld   b, INI_TOP-$0b        ; B = coord Y
call AT                    ; Position cursor
ld   hl, MaxPoints         ; HL = points value
call PrintBCD              ; Paints it
ld   b, INI_TOP-$0d        ; B = coord Y
call AT                    ; Position cursor
ld   hl, seconds           ; HL = time value
call PrintBCD              ; Paints it
ld   b, INI_TOP-$0f        ; B = coord Y
call AT                    ; Position cursor
ld   hl, MaxTies           ; HL = time value
call PrintBCD              ; Paints it
ld   b, INI_TOP-$11        ; B = coord Y
call AT                    ; Position cursor
ld   hl, Level             ; HL = difficulty value
jp   PrintBCD              ; Paints it in and exits

In main.asm find menu_Ties and then the line CP KEY4. After this line, replace JR NZ, menu_op with:

jr   nz, menu_Level        ; No, skip

After menu_TiesDo, after the JR line menu_op, we add the processing lines of the new menu item:

menu_Level:
cp   KEY5                  ; Pushed 5?
jr   nz, menu_op           ; No, loop
ld   a, (Level)            ; A = difficulty
xor  $03                   ; Alternates between 1 and 2
ld   (Level), a            ; Refresh in memory
jr   menu_op               ; Loop

Finally, in game.asm we locate zxMoveDefence_corner24, and just below it we add:

ld   a, (Level)            ; A = difficulty
cp   $01                   ; Difficulty = 1?
jr   z, zxMoveAttack_123   ; Yes, jumps

These lines do not check for corner play when the difficulty level is one. Compile and test.

Loading screen

Finally, we’re going to add the loading screen, but what’s the difference when we’ve already seen how it’s done in ZX-Pong and Space Battle? Well, this time we’re going to do it differently, because we’re not going to load the screen into VideoRAM, we’re going to load it into a different memory address and then make it appear all at once.

This is the loading screen you can download from here.

Please be kind, art has never been my thing. I will be happy if you design your own loading screen, which I am sure will be better than this one; it shouldn’t be difficult.

In order to load the loading screen into a memory area and then dump it all at once into VideoRAM, we need to implement the routine to do this in a separate file and compile it separately.

The loading process will do the following:

• Load the loader.
• Load the routine that dumps the loading screen into memory address 24200.
• Load the loading screen at address 24250.
• Runs the routine that dumps the loading screen into VideoRAM.
• Load the tic-tac-toe routine at address 24200.
• Load the interrupt routine at address 32348.
• Run the tic-tac-toe program.

The first thing we are going to look at is the loader we developed in Basic to do all of the above.

 10 CLEAR 24200
 20 INK 0: PAPER 4: BORDER 4: CLS
 30 POKE 23610,255: POKE 23739,111
 40 LOAD ""CODE 24200
 50 LOAD ""CODE 24250
 60 RANDOMIZE USR 24200
 70 LOAD ""CODE 24200
 80 LOAD ""CODE 32348
 90 CLS
100 RANDOMIZE USR 24200

Don’t forget to save it with SAVE «OXO» LINE 10.

The next step is to implement the routine that dumps the loading screen into the VideoRAM. We create the file loadScr.asm and add the following lines:

; -------------------------------------------------------------------
; LoadScr.asm
;
; The loading screen will be loaded in $5eba, and this routine will 
; be passed by the VideoRAM to appear all at once and will then 
; clear the area.
; Where it was initially loaded.
; The cleaning of this memory area is not necessary, but we do it.
; in case we need to debug, not to find code that actually are 
; remnants of the loading screen.
; -------------------------------------------------------------------
org  $5e88                 ; Loading address

ld   hl, $5eba             ; HL = address where the screen is located
ld   de, $4000             ; DE = VideoRAM address
ld   bc, $1b00             ; Screen length
ldir                       ; Flip the screen

ld   hl, $5eba             ; HL = address where the screen is located
ld   de, $5ebb             ; Next address
ld   bc, $1aff             ; Screen length - 1
ld   (hl), $00             ; Clear the first position
ldir                       ; Clean up the rest

ret

The loading screen is loaded at $5eba. This routine copies $1B00 positions (6912 bytes), the entire area of pixels and attributes, from this address into VideoRAM.

Once copied, we clean up the memory area where the screen was loaded; it is not necessary, but if we have to debug, we will avoid residual code that could confuse us.

Now we just need to modify the script we need to compile and generate the final .tap. The Windows version looks like this:

echo off
cls
echo Compiling oxo
pasmo --name OXO --tap main.asm oxo.tap oxo.log
echo Compiling int
pasmo --name INT --tap int.asm int.tap int.log
echo Compiling loadscr
pasmo --name LoadScr --tap loadScr.asm loadscr.tap loadscr.log
echo Generating Tic-Tac-Toe
copy /b /y loader.tap+loadscr.tap+TresEnRayaScr.tap+oxo.tap+int.tap TicTacToe.tap

The Linux version would look like this:

clear
echo Compiling oxo
pasmo --name OXO --tap main.asm oxo.tap oxo.log
echo Compiling int
pasmo --name INT --tap int.asm int.tap int.log
echo Compiling loadscr
pasmo --name LoadScr --tap loadScr.asm loadscr.tap loadscr.log
echo Generating Tic-Tac-Toe
cat loader.tap loadscr.tap TresEnRayaScr.Tap oxo.tap int.tap > TicTacToe.tap

And that is it.

ZX Spectrum Assembly, Tic-Tac-Toe

Thank you very much for joining me on this journey, I hope this is just the beginning, that it has helped you to learn and become passionate about assembly programming for the ZX Spectrum. I will continue to study and learn, and if I can gather more material in the future, I may write another tutorial.

Download the source code from here.

ZX Spectrum Assembly, Tic-Tac-Toe by Juan Antonio Rubio García.
Translation by Felipe Monge Corbalán.
This work is licensed to Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International (CC BY-NC-SA 4.0).
Any comments are always welcome.

Translation by Felipe Monge Corbalán

Table of contents

• Me versus the Spectrum
• ZX Spectrum Assembly, Tic-Tac-Toe
• Useful links

Me versus the Spectrum

Once we can play against friends and family, the possibility remains that we may not have anyone to play with, hence the need to be able to play against the Spectrum.

We wrote the bulk of this implementation in game.asm, starting with a routine that generates semi-random numbers between one and nine, so that when the Spectrum starts the game, it does so in a different way.

; -------------------------------------------------------------------
; Gets a semi-random number between 1 and 9.
;
; Return: A -> Number obtained.
; -------------------------------------------------------------------
GetRandomN:
ld   a, r                  ; A = R
and  $0f                   ; Leave bits 0 to 3
inc  a                     ; A+=1
cp   $0a                   ; A > 9?
ret  c                     ; No, exit
rra                        ; A/=2, because Carry = 0, otherwise SRL A
ret                        ; Exits

GetRandomN gets a semi-random number between one and nine, using register R. In the RRA line, as seen in the comments, we divide A by two because the carry is zero and because we only do it once, otherwise we would have to do it with SRL A. RRA is one byte and takes four clock cycles, SRL A is only twice as long. It is only divided by two if the number obtained is greater than 9.

The part that carries out the movements of the spectrum is very long, as there are several combinations that are evaluated, so we will see it in blocks. However, as there are many similarities between the different blocks, we will only explain the most important ones.

; -------------------------------------------------------------------
; Moves ZX Spectrum.
;
; Alters the value of the AF, BC and IX registers.
; -------------------------------------------------------------------
ZxMove:
ld   a, (MoveCounter)      ; A = moves
or   a                     ; Movements = 0?
jr   nz, zxMove_center     ; No, skip
call GetRandomN            ; A = number between 1 and 9
add  a, '0'                ; A = ascii code
ld   c, a                  ; C = A
call ToMove                ; Move to cell
ret                        ; Exits
zxMove_center:
cp   $01                   ; Moves > 1?
jr   nz, zxMove_cont       ; Yes, skip
ld   c, KEY5               ; C = key 5
call ToMove                ; Move to cell 5
ret  z                     ; If correct, exits

In this first part we decide if it is the first move of the game, and if so we take a random number between one and nine and move to that cell. If it is the second move, we try to move to cell five (middle). If these conditions are not met, we continue with the checks to see if the spectrum can win or lose.

zxMove_cont:
ld   ix, Grid-$01          ; IX = dir Grid-1
ld   b, $20                ; B = Spectrum value can earn
call zxMoveToWin_123       ; Move to gain Spectrum
ret  z                     ; If valid, exits
ld   b, $02                ; B = value player 1 can win
call zxMoveToWin_123       ; Move to avoid it
ret  z                     ; If valid, exits
jp   zxMoveDefence_diagonally ; Defensive movements

Remember that the moves of player two, in this case the Spectrum, are signalled in bit four of the cells, so we load $20 into B, which would be the value if there were two cells occupied by the Spectrum in a row.

We call zxMoveToWin_123 so that if Spectrum wins, it makes the move.

If the Spectrum has not won, we load two into B to check if player one has the move to win. We call zxMoveToWin_123 a second time to prevent it from winning.

If none of the above has happened, we go on the defensive.

; -------------------------------------------------------------------
; Evaluates whether the Spectrum has the movement to win.
; -------------------------------------------------------------------
zxMoveToWin_123:
ld   a, (ix+$01)           ; A = cell value 1
add  a, (ix+$02)           ; A+= cell value 2
add  a, (ix+$03)           ; A+= cell value 3
cp   b                     ; A = B?
jp   nz, zxMoveToWin_456   ; No, skip
; Spectrum can win
ld   c, KEY1               ; C = key 1
call ToMove                ; Move to cell 1
ret  z                     ; If correct, exits
inc  c                     ; C = key 2
call ToMove                ; Move to cell 2
ret  z                     ; If correct, exits
inc  c                     ; C = key 3
call ToMove                ; Move to cell 3
ret                        ; Exits

If the Spectrum occupies two squares, we try to move to square one, if not, to square two and if not, to square three. To go from one square to the next, we increment C, numerically they are contiguous.

The checks for the combinations four, five, six and seven, eight, nine are the same as above.

zxMoveToWin_456:
ld   a, (ix+$04)           ; A = cell value 4
add  a, (ix+$05)           ; A+= cell value 5
add  a, (ix+$06)           ; A+= cell value 6
cp   b                     ; A = B?
jr   nz, zxMoveToWin_789   ; No, skip
; Spectrum can win
ld   c, KEY4               ; C = key 4
call ToMove                ; Move to cell 4
ret  z                     ; If correct, exits
inc  c                     ; C = key 5
call ToMove                ; Move to cell 5
ret  z                     ; If correct, exits
inc  c                     ; C = key 6
call ToMove                ; Move to cell 6
ret                        ; Sale

zxMoveToWin_789:
ld   a, (ix+$07)           ; A = cell value 7
add  a, (ix+$08)           ; A+= cell value 8
add  a, (ix+$09)           ; A+= cell value 9
cp   b                     ; A = B?
jr   nz, zxMoveToWin_147   ; No, skip
; Spectrum can win
Ld   c, KEY7               ; C = key 7
call ToMove                ; Move to cell 7
ret  z                     ; If correct, exits
inc  c                     ; C = key 8
call ToMove                ; Move to cell 8
ret  z                     ; If correct, exits
inc  c                     ; C = key 9
call ToMove                ; Move to cell 9
ret                        ; Exits

The rest of the tests change slightly.

zxMoveToWin_147:
ld   a, (ix+$01)           ; A = cell value 1
add  a, (ix+$04)           ; A+= cell value 4
add  a, (ix+$07)           ; A+= cell value 7
cp   b                     ; A=B?
jr   nz, zxMoveToWin_258   ; No, skip
ld   c, KEY1               ; C = key 1
call ToMove                ; Move to cell 1
ret  z                     ; If correct, exits
ld   c, KEY4               ; C = key 4
call ToMove                ; Move to cell 4
ret  z                     ; If correct, exits
ld   c, KEY7               ; C = key 7
call ToMove                ; Move to cell 7
ret                        ; Exits

As the squares are not numerically contiguous, at the end we load each key instead of incrementing C. From here on, all the checks to see if the Spectrum can win or lose are the same.

zxMoveToWin_258:
ld   a, (ix+$02)           ; A = cell value 2
add  a, (ix+$05)           ; A+= cell value 5
add  a, (ix+$08)           ; A+= cell value 8
cp   b                     ; A=B?
jr   nz, zxMoveToWin_369   ; No, skip
ld   c, KEY2               ; C = key 2
call ToMove                ; Move to cell 2
ret  z                     ; If correct, exits
ld   c, KEY5               ; C = key 5
call ToMove                ; Move to cell 5
ret  z                     ; If correct, exits
ld   c, KEY8               ; C = key 8
call ToMove                ; Move to cell 8
ret                        ; Exits
    
zxMoveToWin_369:
ld   a, (ix+$03)           ; A = cell value 3
add  a, (ix+$06)           ; A+= cell value 6
add  a, (ix+$09)           ; A+= cell value 9
cp   b                     ; A=B?
jr   nz, zxMoveToWin_159   ; No, skip
ld   c, KEY3               ; C = key 3
call ToMove                ; Move to cell 3
ret  z                     ; If correct, exits
ld   c, KEY6               ; C = key 6
call ToMove                ; Move to cell 6
ret  z                     ; If correct, exits
ld   c, KEY9               ; C = key 9
call ToMove                ; Move to cell 9
ret                        ; Exits
    
zxMoveToWin_159:
ld   a, (ix+$01)           ; A = cell value 1
add  a, (ix+$05)           ; A+= cell value 5
add  a, (ix+$09)           ; A+= cell value 9
cp   b                     ; A=B?
jr   nz, zxMoveToWin_357   ; No, skip
ld   c, KEY1               ; C = key 1
call ToMove                ; Move to cell 1
ret  z                     ; If correct, exits
ld   c, KEY5               ; C = key 5
call ToMove                ; Move to cell 5
ret  z                     ; If correct, exits
ld   c, KEY9               ; C = key 9
call ToMove                ; Move to cell 9
ret                        ; Exits

zxMoveToWin_357:
ld   a, (ix+$03)           ; A = cell value 3
add  a, (ix+$05)           ; A+= cell value 5
add  a, (ix+$07)           ; A+= cell value 7
cp   b                     ; A = B?
ret  nz
ld   c, KEY3               ; C = key 3
call ToMove                ; Move to cell 3
ret  z                     ; If correct, exits
ld   c, KEY5               ; C = key 5
call ToMove                ; Move to cell 5
ret  z                     ; If correct, exits
ld   c, KEY7               ; C = key 7
call ToMove                ; Move to cell 7
ret                        ; Exits

The set of routines zxMoveToWin is used both to know if Spectrum can win and make the move to do so, and to know if Spectrum can lose and make the move to avoid it.

If both player one and Spectrum have no chance of winning, we try to anticipate player one’s move. First we check if the player makes a diagonal move that occupies both vertices, and if so we make a cross block.

; -------------------------------------------------------------------
; Diagonal defensive movement.
; -------------------------------------------------------------------
zxMoveDefence_diagonally:
; Checks if player 1 has diagonal checkers
ld   a, (ix+$01)           ; A = cell value 1
add  a, (ix+$09)           ; A+= cell value 9
cp   b                     ; A = B?
jr   z, zxMoveDefence_crossBlock ; Yes, mov diagonal, skip
ld   a, (ix+$03)           ; A = cell value 3
add  a, (ix+$07)           ; A+= cell value 7
cp   b                     ; A = B?
jr   nz, zxMoveDefence_crossBlock1 ; No, skip

zxMoveDefence_crossBlock:
; Cross locking
ld   c, KEY4               ; C = key 4
call ToMove                ; Move to cell 4
ret  z                     ; If correct, exits
ld   c, KEY6               ; C = key 6
call ToMove                ; Move to cell 6
ret  z                     ; If correct, exits
ld   c, KEY2               ; C = key 2
call ToMove                ; Move to cell 2
ret  z                     ; If correct, exits
ld   c, KEY8               ; C = key 8
call ToMove                ; Move to cell 8
ret  z                     ; If correct, exits

Then we check if he has tried a diagonal move with the centre occupied, and if so, depending on which vertex is occupied, we block the vertical.

; -------------------------------------------------------------------
; Defensive diagonal movement with the centre occupied.
; -------------------------------------------------------------------
zxMoveDefence_crossBlock1:
ld   a, (ix+$05)           ; A = cell value 5
and  $0f                   ; A = player value 1
jr   z, zxMoveDefence_cornerBlock16 ; Z = not occupied, skip
ld   a, (ix+$01)           ; A = cell value 1
and  $0f                   ; A = player value 1
jr   z, zxMoveDefence_crossBlock3 ; Z = not occupied, skip
ld   c, KEY7               ; C = key 7
call ToMove                ; Move to cell 7
ret  z                     ; If correct, exits

zxMoveDefence_crossBlock3:
ld   a, (ix+$03)           ; A = cell value 3
and  $0f                   ; A = player value 1
jr   z, zxMoveDefence_crossBlock7 ; Z = not occupied, skip
ld   c, KEY9               ; C = key 9
call ToMove                ; Move to cell 9
ret  z                     ; If correct, exits

zxMoveDefence_crossBlock7:
ld   a, (ix+$07)           ; A = cell value 7
and  $0f                   ; A = player value 1
jr   z, zxMoveDefence_crossBlock9 ; Z = not occupied, skip
ld   c, KEY1               ; C = key 1
call ToMove                ; Move to cell 1
ret  z                     ; If correct, exits

zxMoveDefence_crossBlock9:
ld   a, (ix+$09)           ; A = cell value 9
and  $0f                   ; A = player value 1
jr   z, zxMoveDefence_cornerBlock16 ; Z = not occupied, skip
ld   c, KEY3               ; C = key 3
call ToMove                ; Move to cell 3
ret  z                     ; If correct, exits

If player one has not attempted a diagonal move, we will see if he has attempted a cross move and try to block it.

; -------------------------------------------------------------------
; Defensive cross movement.
; -------------------------------------------------------------------
zxMoveDefence_cornerBlock16:
ld   a, (ix+$01)           ; A = cell value 1
add  a, (ix+$06)           ; A+= cell value 6
cp   b                     ; A = B?
jr   nz, zxMoveDefence_cornerBlock34 ; No, no mov cross, skip
ld   c, KEY3               ; C = key 3
call ToMove                ; Move to cell 3
ret  z                     ; If correct, exits

zxMoveDefence_cornerBlock34:
ld   a, (ix+$03)           ; A = cell value 3
add  a, (ix+$04)           ; A+= cell value 4
cp   b                     ; A = B?
jr   nz, zxMoveDefence_cornerBlock67 ; No, no mov cross, skip
ld   c, KEY1               ; C = key 1
call ToMove                ; Move to cell 1
ret  z                     ; If correct, exits

zxMoveDefence_cornerBlock67:
ld   a, (ix+$06)           ; A = cell value 6
add  a, (ix+$07)           ; A+= cell value 7
cp   b                     ; A = B?
jr   nz, zxMoveDefence_cornerBlock49 ; No, no mov cross, skip
ld   c, KEY9               ; C = key 9
call ToMove                ; Move to cell 9
ret  z                     ; If correct, exits

zxMoveDefence_cornerBlock49:
ld   a, (ix+$04)           ; A = cell value 4
add  a, (ix+$09)           ; A+= cell value 9
cp   b                     ; A = B?
jr   nz, zxMoveDefence_cornerBlock1827 ; No, no mov cross, skip
ld   c, KEY7               ; C = key 7
call ToMove                ; Move to cell 7
ret  z                     ; If correct, exits

zxMoveDefence_cornerBlock1827:
ld   a, (ix+$01)           ; A = cell value 1
add  a, (ix+$08)           ; A+= cell value 8
cp   b                     ; A = B?
jr   z, zxMoveDefence_cornerBlock1827Cont ; Yes, mov cross, block
ld   a, (ix+$02)           ; A = cell value 2
add  a, (ix+$07)           ; A+= Value cell 7
cp   b                     ; A = B?
jr   nz, zxMoveDefence_cornerBlock2938 ; No, no mov cross, skip

zxMoveDefence_cornerBlock1827Cont:
ld   c, KEY4               ; C = key 4
call ToMove                ; Move to cell 4
ret  z                     ; If correct, exits

zxMoveDefence_cornerBlock2938:
ld   a, (ix+$02)           ; A = cell value 2
add  a, (ix+$09)           ; A+= cell value 9
cp   b                     ; A = B?
jr   z, zxMoveDefence_cornerBlock2938Cont ; Yes, mov cross, block
ld   a, (ix+$03)           ; A = cell value 3
add  a, (ix+$08)           ; A+= cell value 8
cp   b                     ; A = B?
jr   nz, zxMoveAttack_123  ; No, no mov cross, skip

zxMoveDefence_cornerBlock2938Cont:
ld   c, KEY6               ; C = key 6
call ToMove                ; Move to cell 6
ret  z                     ; If correct, exits

If we’ve got this far, we’ve established that Spectrum has no move to win, that player one has no move to win, that player one is in no danger from player one’s diagonal or cross moves; it’s time for Spectrum to go on the attack.

This last part will only be done in the first few moves, as the board fills up we will be more concerned with defending than attacking.

; -------------------------------------------------------------------
; Horizontal, vertical and diagonal offensive movement.
; -------------------------------------------------------------------
zxMoveAttack_123:
ld   b, $20                ; B = Spectrum value with two boxes
ld   a, (ix+$01)           ; A = cell value 1
add  a, (ix+$02)           ; A+= cell value 2
add  a, (ix+$03)           ; A+= cell value 3
ld   c, a                  ; Preserve A in C
and  $03                   ; A = player 1 cells
jr   nz, zxMoveAttack_456  ; Any? Yes, jump
ld   a, c                  ; Retrieves A
and  $30                   ; A = Spectrum boxes
cp   b                     ; Two busy?
Jr   z, zxMoveAttack_456   ; Yes, jumps
ld   c, KEY1               ; C = key 1
call ToMove                ; Move to cell 1
ret  z                     ; If correct, exits
inc  c                     ; C = key 2
call ToMove                ; Move to cell 2
ret  z                     ; If correct, exits
inc  c                     ; C = key 3
call ToMove                ; Move to cell 3
ret  z                     ; If correct, exits

For the attack, we look for combinations where player one has no cells occupied and the Spectrum has only one.

The rest of the checks are very similar to the previous one.

zxMoveAttack_456:
ld   a, (ix+$04)           ; A = cell value 4
add  a, (ix+$05)           ; A+= cell value 5
add  a, (ix+$06)           ; A+= cell value 6
ld   c, a                  ; Preserve A in C
and  $03                   ; A = player 1 cells
jr   nz, zxMoveAttack_789  ; Any? Yes, jump
ld   a, c                  ; Retrieves A
and  $30                   ; A = Spectrum boxes
cp   b                     ; Two busy?
jr   z, zxMoveAttack_789   ; Yes, jumps
ld   c, KEY4               ; C = key 4
call ToMove                ; Move to cell 4
ret  z                     ; If correct, exits
inc  c                     ; C = key 5
call ToMove                ; Move to cell 5
ret  z                     ; If correct, exits
inc  c                     ; C = key 6
call ToMove                ; Move to cell 6
ret  z                     ; If correct, exits

zxMoveAttack_789:
ld   a, (ix+$07)           ; A = cell value 7
add  a, (ix+$08)           ; A+= cell value 8
add  a, (ix+$09)           ; A+= cell value 9
ld   c, a                  ; Preserve A in C
and  $03                   ; A = player 1 cells
jr   nz, zxMoveAttack_147  ; Any? Yes, jump
ld   a, c                  ; Retrieves A
and  $30                   ; A = Spectrum boxes
cp   b                     ; Two busy?
jr   z, zxMoveAttack_147   ; Yes, jumps
ld   c, KEY7               ; C = key 7
call ToMove                ; Move to cell 7
ret  z                     ; If correct, exits
inc  c                     ; C = key 8
call ToMove                ; Move to cell 8
ret  z                     ; If correct, exits
inc  c                     ; C = key 9
call ToMove                ; Move to cell 9
ret  z                     ; If correct, exits

zxMoveAttack_147:
ld   a, (ix+$01)           ; A = cell value 1
add  a, (ix+$04)           ; A+= cell value 4
add  a, (ix+$07)           ; A+= cell value 7
ld   c, a                  ; Preserve A in C
and  $03                   ; A = player 1 boxes
jr   nz, zxMoveAttack_258  ; Any? Yes, jump
ld   a, c                  ; Retrieves A
and  $30                   ; A = Spectrum boxes
cp   b                     ; Two busy?
jr   z, zxMoveAttack_258   ; Yes, jumps
ld   c, KEY1               ; C = key 1
call ToMove                ; Move to cell 1
ret  z                     ; If correct, exits
ld   c, KEY4               ; C = key 4
call ToMove                ; Move to cell 4
ret  z                     ; If correct, exits
ld   c, KEY7               ; C = key 7
call ToMove                ; Move to cell 7
ret   z                    ; If correct, exits

zxMoveAttack_258:
ld   a, (ix+$02)           ; A = cell value 2
add  a, (ix+$05)           ; A+= cell value 5
add  a, (ix+$08)           ; A+= cell value 8
ld   c, a                  ; Preserve A in C
and  $03                   ; A = player 1 cells
jr   nz, zxMoveAttack_369  ; Any? Yes, jump
ld   a, c                  ; Retrieves A
and  $30                   ; A = Spectrum boxes
cp   b                     ; Two busy?
jr   z, zxMoveAttack_369   ; Yes, jumps
ld   c, KEY2               ; C = key 2
call ToMove                ; Move to cell 2
ret  z                     ; If correct, exits
ld   c, KEY5               ; C = key 5
call ToMove                ; Move to cell 5
ret  z                     ; If correct, exits
ld   c, KEY8               ; C = key 8
call ToMove                ; Move to cell 8
ret  z                     ; If correct, exits

zxMoveAttack_369:
ld   a, (ix+$03)           ; A = cell value 3
add  a, (ix+$06)           ; A+= cell value 6
add  a, (ix+$09)           ; A+= cell value 9
ld   c, a                  ; Preserve A in C
and  $03                   ; A = player 1 cells
jr   nz, zxMoveAttack_159  ; Any? Yes, jump
ld   a, c                  ; Retrieves A
and  $30                   ; A = Spectrum boxes
cp   b                     ; Two busy?
Jr   z, zxMoveAttack_159   ; Yes, jumps
ld   c, KEY3               ; C = key 3
call ToMove                ; Move to cell 3
ret  z                     ; If correct, exits
ld   c, KEY6               ; C = key 6
call ToMove                ; Move to cell 6
ret  z                     ; If correct, exits
ld   c, KEY9               ; C = key 9
call ToMove                ; Move to cell 9
ret  z                     ; If correct, exits

zxMoveAttack_159:
ld   a, (ix+$01)           ; A = cell value 1
add  a, (ix+$05)           ; A+= cell value 5
add  a, (ix+$09)           ; A+= cell value 9
ld   c, a                  ; Preserve A in C
and  $03                   ; A = player 1 cells
jr   nz, zxMoveAttack_357  ; Any? Yes, jump
ld   a, c                  ; Retrieves A
and  $30                   ; A = Spectrum boxes
cp   b                     ; Two busy?
Jr   z, zxMoveAttack_357   ; Yes, jumps
Ld   c, KEY1               ; C = key 1
call ToMove                ; Move to cell 1
ret  z                     ; If correct, exits
ld   c, KEY5               ; C = key 5
call ToMove                ; Move to cell 5
ret  z                     ; If correct, exits
ld   c, KEY9               ; C = key 9
call ToMove                ; Move to cell 9
ret  z                     ; If correct, exits

zxMoveAttack_357:
ld   a, (ix+$03)           ; A = cell value 3
add  a, (ix+$05)           ; A+= cell value 5
add  a, (ix+$07)           ; A+= cell value 7
ld   c, a                  ; Preserve A in C
and  $03                   ; A = player 1 cells
jr   nz, zxMoveGeneric     ; Any? Yes, jump
ld   a, c                  ; Retrieves A
and  $30                   ; A = Spectrum boxes
cp   b                     ; Two busy?
jr   z, zxMoveGeneric      ; Yes, skip
ld   c, KEY3               ; C = key 3
call ToMove                ; Move to cell 3
ret  z                     ; If correct, exits
ld   c, KEY5               ; C = key 5
call ToMove                ; Move to cell 5
ret  z                     ; If correct, exits
ld   c, KEY7               ; C = key 7	
call ToMove                ; Move to cell 7
ret  z                     ; If correct, exits