Creando cartuchos IF2 con PASMO

[radastan]

Bien, aquí teneis un ejemplo de como crear cartuchos para Interface 2 con el ensamblador PASMO:

Código: Seleccionar todo

; -------------------------------------------
; Prueba de subrutinas usando sprites
;
; Radastan
; -------------------------------------------

        ORG 0      ; 32768 lo normal, 0 para crear una ROM
   
; -------------------------------------------
; Rutina principal
; -------------------------------------------

   ld a, 15   ; papel azul y tinta en blanco
   call sucls
   ld a, 1      ; borde azul, para actualización inmediata
   call borde

   ld d, 7      ; posición vertical del sprite
   ld e, 7      ; posición horizontal del sprite
   ld hl, cubo   ; sprite a usar
   call print
fin   nop
   jp fin

; -------------------------------------------
; SUBRUTINA PARA HACER UN CLS SIN USAR LA ROM
; ENTRADAS: a, es el color de tinta/papel
; SALIDAS: pone el mapa de pantalla a 0
; Ver tabla de color al final del programa
; -------------------------------------------

sucls   ld hl, 22528
   ld de, 22529
   ld bc, 767
   ld (hl),a
   ldir
   ld hl, 16384
   ld de, 16385
   ld bc, 6143
   ld (hl),l
   ldir
   ret

; -------------------------------------------
; SUBRUTINA PARA CAMBIAR EL BORDE DE PANTALLA
; ENTRADAS: a, es el color del borde
; SALIDAS: ninguna
; -------------------------------------------

borde   out (254), a
   ret

; -------------------------------------------
; RUTINA DE IMPRESION DE UN SPRITE 16x16 PIXELS
; CON ATRIBUTOS EN CUALQUIER POSICION DE CARACTER
; ENTRADAS:
; D será la posición del cursor vertical en caracteres
; E será la posición del cursor horizontal en caracteres
; HL es la posición de memoria donde tenemos el sprite
; SALIDAS: se escribe en el mapa de pantalla
; ADVERTENCIAS: no comprueba límites de pantalla
; -------------------------------------------

print   
   push de      ; salvamos los valores vertical y horizontal
   push de      ; salvamos los valores vertical y horizontal
   push de      ; salvamos los valores vertical y horizontal
   call cdrw   ; calculamos dirección de pantalla
   ld b, 8
   call draw
   pop de      ; recuperamos el valor horizontal
   inc d      ; incrementamos una línea
   call cdrw
   ld b, 8
   call draw
         ; Ahora imprimimos los atributos
   pop de      ; recuperamos el valor horizontal
   call cdrw
   call catr
   call colr
   pop de      ; recuperamos el valor horizontal
   inc d      ; incrementamos una línea
   call cdrw
   call catr
   call colr

   ret

draw   
   ld a,(hl)           ; hl indica la posición del sprite en memoria
   ld (de),a           ; de indica la posición de pantalla
   inc hl
   inc e
   ld a,(hl)           ; esta parte imprime el segundo byte
   ld (de),a
   inc hl
   dec e
   inc d
   djnz draw           ; decrementa B y si es cero deja de saltar a draw
   ret

colr
   ld a,(hl)
   ld (de),a
   inc e
   inc hl
   ld a,(hl)
   ld (de),a
   dec e
   inc hl
   ret

cdrw
   ld a, d      ; recuperamos el valor vertical
   and 7      ; nos quedamos con la posición en el tercio
   rrca
        rrca
        rrca      ; rotamos para dejar su valor en múltiplos de 32 (linea)
   and 224      ; borramos el resto de bits por si las moscas
   or e      ; sumamos el valor horizontal
   ld e, a      ; e preparado
   ld a, d
   and 24      ; modificamos según el tercio de pantalla
   or 64      ; nos posicionamos a partir de 16384 (16384=64+0 en dos bytes)
   ld d, a      ; d preparado
   ret

catr
   ld a,d
        rra
        rra
        rra      ; multiplicamos por 32
        and 3      ; nos quedamos con los tres bits bajos
        or 88      ; apuntamos al comienzo del mapa de atributos
        ld d,a          ; ya tenemos d listo, e no hay que cambiarlo
   ret

; -------------------------------------------
; sprite de un cubo
; los cuatro últimos bytes son el color
; se pueden usar sprites creados con SevenuP
; -------------------------------------------

cubo   defb 255,255,128,1,128,1,128,1,128,1,128,1,128,1,128,1
       defb 128,1,128,1,128,1,128,1,128,1,128,1,128,1,255,255
       defb 12,13,14,15

; - TINTA -
; 
; NEGRO      0   00000000
; AZUL      1   00000001
; ROJO      2   00000010
; MAGENTA   3   00000011
; VERDE      4   00000100
; AZULADO   5   00000101
; AMARILLO   6   00000110
; BLANCO   7   00000111
; 
; - PAPEL -
;
; NEGRO      0   00000000
; AZUL      8   00001000
; ROJO      16   00010000
; MAGENTA   24   00011000
; VERDE      32   00100000
; AZULADO   40   00101000
; AMARILLO   48   00110000
; BLANCO   56   00111000

; -------------------------------------------
; FIN DEL PROGRAMA
; -------------------------------------------

        ORG 16383      ; para crear una ROM 16K
   nop

Como podéis ver el único truco consiste en empezar a crear el código desde ORG 0, y finalizar con un NOP en 16383 para que se cree un fichero BIN de 16384 bytes (16 K exactamente) que podemos renombrar a .rom y ejecutar en el ZX Spectrum.

Lo que no me cuadra es que me funciona perfectamente en Spectaculator si simulo un 48K... pero en un 16K se me corrompe la pantalla. Curioso, porque no uso la RAM para nada, salvo el área de pantalla.

¿Hay que decirle algo al PASMO para que use otra RAMTOP en los saltos o algo así?

[Gandulf]

Es por la pila. Añade esta línea después del ORG 0 y ya te funciona en los modelos 16K

ld sp, 16384 + 6912 + 100 ; por ejemplo, que apunte a ram y deje sitio para los push/pop

[radastan]

Es por la pila. Añade esta línea después del ORG 0 y ya te funciona en los modelos 16K

ld sp, 16384 + 6912 + 100 ; por ejemplo, que apunte a ram y deje sitio para los push/pop

Efectivamente, eso era, ya sabía yo que era cosa de PASMO.

Eso si, yo usaré

Código: Seleccionar todo

   ORG 0
   ld sp, 30720

Dejar 2 K para la pila ya está bien... y con no usar por encima de 30000 ya te aseguras el suficiente espacio para push-pop.

Digo yo...

[na_th_an]

Yo estaba pensando poner la pila en la pantalla y todo, para ahorrar RAM Lo que pasa es que iba a quedar feo

[radastan]

Yo estaba pensando poner la pila en la pantalla y todo, para ahorrar RAM Lo que pasa es que iba a quedar feo

Depende... si usas dos tercios de pantalla para el juego y dejas uno con los atributos de color y tinta al msimo color... incluso un matamarcianos puede jugarse con sólo un tercio de pantalla, lo cual te deja dos para tus cosas.

Bueno voy a crear otro hilo para ayudar con la creación de cartuchos en IF 2.

[na_th_an]

Esa era la idea. Usar el tercio superior o el inferior para la pila y otras cosas. Son 2K demasiado preciosos como para desperdiciarlos con un marcador bonito o un logo.

[TrueVideo]

Hola,

permíteme un par de comentarios quisquillosos... es que es lunes por la mañana y estoy ocioso:

Efectivamente, eso era, ya sabía yo que era cosa de PASMO.

No creo que sea justo decir que es culpa de Pasmo. El inicializar los registros correctamente (y sobre todo uno tan sensible como el sp) es responsabilidad del programador. Ni el ensamblador ni el emulador pueden adivinar dónde queremos nuestra pila.

Eso si, yo usaré

Código: Seleccionar todo

   ORG 0
   ld sp, 30720

Dejar 2 K para la pila ya está bien... y con no usar por encima de 30000 ya te aseguras el suficiente espacio para push-pop.

Recuerda que la pila crece hacia abajo! Con ese valor estás situando la pila desde 30720 hacia atrás. Para reservar el área superior de memoria utiliza ld sp,32768.

Para terminar, me parece que 2K sólo para push y pop es una exageración... para llenarlas sería necesario hacer 1024 llamadas consecutivas sin retornar ni una sola vez (es decir, anidar 1024 subrutinas de un tirón, sin contar interrupciones). Yo suelo dejar unos pocos bytes.. con eso hay más que suficiente.

J

[Gandulf]

Por eso le puse yo el valor de ejemplo 16384 + 6912 + 100, así dejo 100 bytes para la pila y si por cualquier motivo (probablemente bug) se pasara hacia atrás, no machacaría código y vería cambios en los atributos, que me indicaría directamente lo que está pasando.

Una pregunta, en los modelos 16K toda la memoria es contenida? me imagino que sí, que putadilla por la velocidad, pero bueno. En un plataformas no influye demasiado pero mi intención es hacer un arcade con scroll y sprites sobre fondos, y probablemente correr todo en memoria contenida puede perjudicar mucho el rendimiento, a lo mejor me tengo que replantear el tipo de juego.

[Metalbrain]

Una pregunta, en los modelos 16K toda la memoria es contenida? me imagino que sí, que putadilla por la velocidad, pero bueno.

Bueno, la ROM no está en contienda, es solo la RAM.

[radastan]

No creo que sea justo decir que es culpa de Pasmo. El inicializar los registros correctamente (y sobre todo uno tan sensible como el sp) es responsabilidad del programador. Ni el ensamblador ni el emulador pueden adivinar dónde queremos nuestra pila.

Hombre, me refiero evidentemente a que había que poner algo para que PASMO supiera que queremos la pila más abajo...

Recuerda que la pila crece hacia abajo! Con ese valor estás situando la pila desde 30720 hacia atrás. Para reservar el área superior de memoria utiliza ld sp,32768.

Cierto, se me han cruzado los cables con RAMTOP (esto de usar BASIC y ASM a la vez te hace pasar estas cosas).

Para terminar, me parece que 2K sólo para push y pop es una exageración... para llenarlas sería necesario hacer 1024 llamadas consecutivas sin retornar ni una sola vez (es decir, anidar 1024 subrutinas de un tirón, sin contar interrupciones). Yo suelo dejar unos pocos bytes.. con eso hay más que suficiente.

Lo se, lo se, pero siempre dejo muuuuuuuuucho espacio para pila y así si necesito esos pocos bytes de última hora voy sobrado.

[Z80user]

en la rutina CATR hay un bug
AND 3, deberia ser AND 7, para recoger los 3 bits inferiores

Para el tema de la PILA, en los primeros listados de ASM de 80x86, se liaban a poner DB "PILA", o algo similar, para poder comprobar cuanta memoria se ha consumido.

Para usar la pila en la parte de la pantalla, un tercio, son 2048, pero se pueden utilizar lineas, lo que nos da una profundidad de 16 llamadas por linea utilizada, aunque esto es solo para usos ligeros de la PILA, y no consume tanta pantalla, si hace falta mas, se nota al introducir despues de un PUSH basura en la pantalla, pero el problema es que un CLS o un PRINT, se pueden cargar el contenido de la pila.
AYUDA: el resto de bytes que se usan para las lineas de push/pop, se pueden utilizar como variables, para no desperdiciar memoria.

P.D. la RAMTOM, no existe, la ROM del Spectrum no ha metido mano aun.

NOTA: se pueden utilizar compresores, para meter en ROM el codigo comprimido y descomprimirlo en RAM.

[radastan]

en la rutina CATR hay un bug
AND 3, deberia ser AND 7, para recoger los 3 bits inferiores

No, el BUG es el comentario, ya que la rutina funciona perfectamente, aunque la revisaré a ver porqué esa ida de olla.

NOTA: se pueden utilizar compresores, para meter en ROM el codigo comprimido y descomprimirlo en RAM.

Ten en cuenta que para el concurso se ha limitado la RAM total a 16K... y buena parte se va al mapa de pantalla.

[Z80user]

NOTA: se pueden utilizar compresores, para meter en ROM el codigo comprimido y descomprimirlo en RAM.

Ten en cuenta que para el concurso se ha limitado la RAM total a 16K... y buena parte se va al mapa de pantalla.

La cuestion es que son 16 KB mas de memoria, menos lo que ocupe la pantalla (que se puede usar para PUSH/POPs como se comenta), si por ejemplo, los mapas se comprimen, a una cierta posicion de memoria siempre, se puede tener por ejemplo, 8 KB de ROM de codigo puro, y lo que quede de los 16KB de RAM para los graficos descomprimidos y/o los mapas de pantalla.
8KB con memoria no contenida + 10.25KB de memoria contenida, y la pantalla.

Para los graficos pasarlos a RAM, puede ser buena idea, una rutina para rotar los graficos, y con la misma cantidad de memoria ponemos el doble de graficos para no tener que rotarlos sobre la marcha. <:-9 Consumo de memoria, lo que ocupe la rutina de rotado en ROM + lo que ocupen los graficos rotados en RAM (los no rotados se quedan en ROM)

Para tablas de datos, por ejemplo, pase de 8KB para 1024 nombres y apellidos a 4608 bytes, usando una tabla intermedia, algo mas lenta la rutina, pero son 3.4 KB de memoria extra.

Hay muchos casos para poder sacar memoria, como el de codigo automodificado, que no se puede implementar en ROM, y necesita el doble de memoria o mas en ROM, que implementarla en RAM, aunque sea mas lenta la rutina y encima en memoria contenida, puede ahorrar algunos bytes, el mayor problema son los graficos, mas que el codigo, que suele ocupar mayor cantidad de bytes, y existen menos maneras de redicur el consumo de memoria. Con la musica a las malas se puede reducir usando tablas intermedias, en vez de tener la partitura toda segida, aunque complica el player.

[radastan]

La cuestion es que son 16 KB mas de memoria, menos lo que ocupe la pantalla (que se puede usar para PUSH/POPs como se comenta), si por ejemplo, los mapas se comprimen, a una cierta posicion de memoria siempre, se puede tener por ejemplo, 8 KB de ROM de codigo puro, y lo que quede de los 16KB de RAM para los graficos descomprimidos y/o los mapas de pantalla.
8KB con memoria no contenida + 10.25KB de memoria contenida, y la pantalla.

Ojo, esos 16K de RAM son compartidos con el mapa de gráficos, LOS 16 K, eso significa que el acceso a memoria no es tan rápido como la RAM restante en un 48K porque la ULA limita su acceso a la hora de escribir el mapa de pantalla. Tenlo en cuenta.

[na_th_an]

Exacto, almacenar la mitad de los gráficos en ROM y la otra mitad en RAM puede ser una pesadilla a la hora de temporizar.