Curso ASMZ80 XV: Gráficos en Spectrum (IV): Fuentes de texto

[sromero]

Hola a todos,

Acabo de publicar en el Wiki de Speccy.org un nuevo capítulo del Curso de Ensamblador de Z80 de Compiler Software.

En esta entrega, el artículo trata sobre fuentes de texto.

El enlace directo al artículo es este:

Curso ASM Z80: Gráficos en el Spectrum (VI): Fuentes de texto

Cualquier comentario, sugerencia o corrección lo podéis hacer en este hilo. Si véis cualquier errata, queréis aportar cualquier modificación o sugerencia, será bienvenida. A este respecto, cualquier sugerencia de optimización de las rutinas que no la haga ilegible (recordad que es un artículo de aprendizaje y poner rutinas que el lector no pueda ni seguir no sería nada útil) es MUY bienvenida.

Espero que os resulte de interés.

Un saludo.

[Z80user]

error en el numero de '0'

Código: Seleccionar todo

Esta rutina es almacena en la cadena todos los valores '0' que obtiene, incluídos los de las unidades superiores al primer dígito del número (leading zeros). Así, la conversión del valor de 8 bits 17 generará una cadena “017” y la conversión del número de 16 bits 1034 generará la cadena “001034”.

------------------------------------------------------------------------------------------------------

Código: Seleccionar todo

Por defecto, CHARS contiene el valor $3D00 (el tipo de letra estándar) menos 256. El hecho de restar 256 al inicio real de la fuente es porque los caracteres definidos en la ROM empiezan en el 32 y restando 256, al igual que hicimos nosotros con nuestro charset personalizado, podemos hacer coincidir un ASCII > 32 con CHARS+(8*VALOR_ASCII).

El valor de 256 resulta de multiplicar el numero de caracteres (32) por el numero de bytes que ocupa cada caracter (8) 32*8=256

Algo asi seria una mejor explicacion de porque es ese valor.
------------------------------------------------------------------------------------------------------

Código: Seleccionar todo

El juego de caracteres estándar de la ROM

la foto adjunta, no es la normal de la rom, es una diseñada.
------------------------------------------------------------------------------------------------------

Código: Seleccionar todo

Font_Backspace:
; Decrementa la coordenada X, simultando un backspace. No

En esta linea sobra el NO, si no se lee como en la rutina anterior
------------------------------------------------------------------------------------------------------

Código: Seleccionar todo

SUB 8              ; Restando los 7 scanlines avanzados

7 u 8, son 8, o debe de serlo. Ya que hemos recorrido la rutina 8 veces
------------------------------------------------------------------------------------------------------
Creo que has puesto los comentarios al reves, en todas las rutinas

Código: Seleccionar todo

;;; Impresion de un caracter del nibble derecho en la fuente
;;; sobre una posicion de caracter del nibble derecho en pantalla
pchar4_r_on_r: 
   LD B, 8                   ; 8 scanlines / iteraciones
pchar4_rr_lp:
   LD A, (DE)                ; Leer byte de la pantalla
   AND %00001111             ; Nos quedamos con la parte derecha
   LD C, A                   ; Nos lo guardamos en C
   LD A, (HL)                ; Cogemos el byte de la fuente
   AND %11110000             ; Enmascarar la parte que no se usa
   OR C                      ; Lo combinamos con el fondo
   LD (DE), A                ; Y lo escribimos en pantalla

Con esto hemos descartado la parte izquierda de la pantalla y guardado el resultado en C (obtenemos la derecha) BIEN
A continuacion descartamos la parte izquierda del nible de la fuente (MAL, hemos indicado que se imprime la parte derecha de la fuente)

;;; Impresion de un caracter del nibble derecho / izquierdo en la fuente
;;; sobre una posicion de caracter del nibble derecho en pantalla

R en R
L en L
R en L
L en R creo que asi deberia ser la descripcion
------------------------------------------------------------------------------------------------------

Código: Seleccionar todo

   LD A, (HL)                ; Cogemos el byte de la fuente
   RLCA                      ; Lo desplazamos 4 veces << dejando
   RLCA                      ; los bits 0 al 3 vacios
   RLCA
   RLCA
   AND %00001111             ; Enmascarar la parte que no se usa

cambiandolos por ADD A,A, nos evitamos el AND, es mas rapida y tambien es facil de entender A<<4 = a*16, en cada ADD ya nos encargamos de dejar el bit menos significativo a 0
NOTA: a<<4 rotar los bits 4 veces a la izquierda
------------------------------------------------------------------------------------------------------
(aparte) Los ANDs no me cuadran mucho, creo que te has hecho un lio con los BITs, si quieres tomar la parte alta (bits 4 a 7) el AND deberia de ser %11110000
En la rutina que usa RRCA tambien ocurre lo mismo.

El caso es que da lo mismo 4 RRCA que 4 RLCA, solo varia el bit que dejamos en el CARRY.
Solo les falto, a los ingenieros del Z80 implementar el tratamiento de nibbles, rotando un registro 4 veces.

[sromero]

Hola, Z80user.

> error en el numero de '0'

Gazapo corregido.

> El valor de 256 resulta de multiplicar el numero de caracteres (32) por el
> numero de bytes que ocupa cada caracter (8) 32*8=256. Algo asi seria una
> mejor explicacion de porque es ese valor.

Añadida explicación al texto.

> la foto adjunta, no es la normal de la rom, es una diseñada.

Copy/paste de la anterior figura X-D. Gazapo corregido.

> ; Decrementa la coordenada X, simultando un backspace. No
> En esta linea sobra el NO, si no se lee como en la rutina anterior

Corregido.

> SUB 8 ; Restando los 7 scanlines avanzados
> 7 u 8, son 8, o debe de serlo. Ya que hemos recorrido la rutina 8 veces

Sí, es cierto, en la rutina PrintChar_8x8 sin estilos de fuente sólo se avanzan 7 scanlines (1 bucle de 7 + 1 iteración después para evitar los INC) pero en las que tienen estilos el bucle se realiza de 8, de ahí sale ese 7 famoso (no cambié el comentario). Cambiado y ejemplos resubidos en 2 minutos.

> (sobre las rutinas y los nibbles)
> Creo que has puesto los comentarios al reves, en todas las rutinas

Es posible, iba copiando y pegando las líneas y cambiando "derecho" e "izquierdo" en cada una. Puede ser que en alguna lo haya puesto al revés. Lo corrijo ahora mismo. De todas formas, lo estoy revisando y creo que está bien (además el código es de Andrew Owen y lo describe igual)

Sobre el otro comentario de la rutina, ahora lo miro, pero me extraña que esté mal porque 1.- las rutinas funcionan (con lo que el AND no puede estar mal) y 2.- las ha programado Andrew Owen, no yo X-D

[Metalbrain]

Un detallito, que no afecta al curso, sino solo a la presentación de los capítulos...

En esta entrega, el artículo trata sobre el cálculo de direcciones y coordenadas de pantalla.

Ya es la tercera vez que se trata este tema.

[sromero]

X-D

Cambiados los 2 "posts" anuncio X-D

[Z80user]

Hola, Z80user.

> (sobre las rutinas y los nibbles)
> Creo que has puesto los comentarios al reves, en todas las rutinas

Es posible, iba copiando y pegando las líneas y cambiando "derecho" e "izquierdo" en cada una. Puede ser que en alguna lo haya puesto al revés. Lo corrijo ahora mismo. De todas formas, lo estoy revisando y creo que está bien (además el código es de Andrew Owen y lo describe igual)

Sobre el otro comentario de la rutina, ahora lo miro, pero me extraña que esté mal porque 1.- las rutinas funcionan (con lo que el AND no puede estar mal) y 2.- las ha programado Andrew Owen, no yo X-D

No tengo la direccion suya a mano, para comentarle la errata, aunque si he visto referencias a la rutina

1-. Si rotamos a la derecha 4 veces con RRCA (o cualquier otro tipo de rotacion), lo normal es hacer AND A,#0F y no AND #F0. A no ser que necesitemos el bit de carry con cierto valor, que no viene siendo el caso
da menos dolor de cabeza
RRCA RRCA RRCA RRCA AND A,#0F
que
RLCA RLCA RLCA RLCA AND A,#0F
O al menos se entiende mejor.

2-. En el caso de la rutina que contiene la instruccion RRCA

Código: Seleccionar todo

;;; Impresion de un caracter del nibble izquierdo en la fuente
;;; sobre una posicion de caracter del nibble derecho en pantalla
pchar4_l_on_r: 
   LD B, 8                   ; 8 scanlines / iteraciones
pchar4_lr_lp: 
   LD A, (DE)                ; Leer byte de la pantalla
   AND %00001111             ; Nos quedamos con la parte derecha
   LD C, A                   ; Nos lo guardamos en C
   LD A, (HL)                ; Cogemos el byte de la fuente
   RRCA                      ; Lo desplazamos 4 veces >> dejando
   RRCA                      ; lo bits 4 al 7 vacios
   RRCA
   RRCA
   AND %11110000             ; Enmascarar la parte que no se usa
   OR C                      ; Lo combinamos con el fondo
   LD (DE), A                ; Y lo escribimos en pantalla
   INC D                     ; Siguiente scanline
   INC HL                    ; Siguiente dato del "sprite"
   DJNZ pchar4_lr_lp
   JR pchar4_continue        ; Volver tras impresion

Si atendemos al codigo y suponemos DE = direccion de pantalla, por ser donde escribe y HL la direccion del Sprite

;;; sobre una posicion de caracter del nibble derecho en pantalla
LD A, (DE) ; Leer byte de la pantalla
AND %00001111 ; Nos quedamos con la parte derecha
LD C, A ; Nos lo guardamos en C
Aqui estamos eliminando el contenido de la parte izquierda de la pantalla, conservando la parte derecha.

LD A, (HL) ; Cogemos el byte de la fuente
RRCA ; Lo desplazamos 4 veces >> dejando
RRCA ; lo bits 4 al 7 vaciosCuando en realidad son los que tienen algo importante
RRCA
RRCA
AND %11110000 ; Enmascarar la parte que no se usa
Rotamos los bits altos sobre los bajos, (es lo que he explicado antes).
Nos quedamos con la parte derecha de la fuente, situada en la parte izquierda.
;;; Impresion de un caracter del nibble izquierdo en la fuente
Es la impresion del nibble derecho de la fuente, sobre la parte izquierda.

OR C ; Lo combinamos con el fondo
LD (DE), A ; Y lo escribimos en pantalla
pero la rutina se llamapchar4_l_on_r:
"Left ON Right", que deberia ser "Right ON Left"

La rutina puede funcionar perfectamente, no digo que no. Pero no es el caso.

Código: Seleccionar todo

; left nibble on right hand side

l_on_r:   ld   c,$08      ; 8 bytes to write

El caso es que hasta hay "l_on_r" sigue autocontradiciendose, o es que Andrew Owen tiene buen sentido del humor ingles

En resumen
1-. intercambiar RRLC por RRCA y viceversa, aclaran el codigo, es mas facil de interpretarlo y no varian el funcionamiento normal de la rutina.
2-. Cambiar las explicaciones de las rutinas, asi como sus nombres, aun leyendolo de derecha a izquierda, no soluciona el problema con L_ON_L
3-. Ya aviso yo a "Andrew Owen" sobre los comentarios de la rutina.

[sromero]

3-. Ya aviso yo a "Andrew Owen" sobre los comentarios de la rutina.

Cítale esta URL:

http://chuntey.wordpress.com/2010/01/08 ... umn-print/

Y péganos por aquí lo que te diga... en cuanto confirme a qué se refiere en los comentarios, cambiamos (o mantenemos) la traducción.

Un saludo.

[mcleod_ideafix]

Cualquier comentario, sugerencia o corrección lo podéis hacer en este hilo.

Un comentario/reflexión: en las rutina de 64 caracteres, has optado por comprimir la tabla de caracteres metiendo dos caracteres en el mismo byte. Por supuesto, eso deja a la mitad el espacio necesario para guardar las definiciones, y por tanto se ahorra memoria.

Pero por otra parte, esta decisión ha hecho que tengas que tener en cuenta cuatro casos diferentes a la hora de imprimir un carácter. Cuatro casos que significa cuatro rutinas, que ocupan memoria.

Además, y según sea el caso, resulta que para imprimir un carácter hay que rotarlo 4 posiciones para ajustarlo a su lugar, lo que enlentece un poco más el asunto de imprimir.

Entonces, pregunto (no me he puesto a probarlo con código aún):
- ¿Ganaríamos tiempo si en lugar de usar cuatro RRCA se usa una instrucción RLD o RRD?
- ¿Compensa la memoria ahorrada juntando dos caracteres en un byte si por otra parte hay que tener cuatro "copias" de la rutina de vocado de carácter?
- ¿Se ganaría en velocidad de impresión si en cada byte tuviéramos el mismo carácter repetido a izquierda y derecha (evitando así las 4 rotaciones por scan, y seguramente evitando el necesitar 4 rutinas diferentes, como mucho 2)?

[sromero]

- ¿Se ganaría en velocidad de impresión si en cada byte tuviéramos el mismo carácter repetido a izquierda y derecha (evitando así las 4 rotaciones por scan, y seguramente evitando el necesitar 4 rutinas diferentes, como mucho 2)?

Pues es posible que a cambio de un total de 768 bytes en lugar de 384, compense en términos de velocidad el tener los caracteres como comentas.

Además haría la rutina más sencilla (sólo 2 posibilidades, según si hay que imprimir a derecha o a izquierda, evitaría las rotaciones y sólo haría falta un AND + OR).

Espero a ver la respuesta de Andrew Owen a Z80user y me replanteo la rutina para imprimir los caracteres como comentas...

Gracias

[Z80user]

Un comentario/reflexión: en las rutina de 64 caracteres, has optado por comprimir la tabla de caracteres metiendo dos caracteres en el mismo byte. Por supuesto, eso deja a la mitad el espacio necesario para guardar las definiciones, y por tanto se ahorra memoria.

Pero por otra parte, esta decisión ha hecho que tengas que tener en cuenta cuatro casos diferentes a la hora de imprimir un carácter. Cuatro casos que significa cuatro rutinas, que ocupan memoria.

Además, y según sea el caso, resulta que para imprimir un carácter hay que rotarlo 4 posiciones para ajustarlo a su lugar, lo que enlentece un poco más el asunto de imprimir.
Entonces, pregunto (no me he puesto a probarlo con código aún):
- ¿Ganaríamos tiempo si en lugar de usar cuatro RRCA se usa una instrucción RLD o RRD?

RLD el problema que tiene es que corrompe la memoria, y solo obtenemos el resultado en el nibble bajo, si lo capturamos en A
Si escribimos en pantalla, obtenemos una rotacion de la pantalla, lo que esta en el nible derecho pasa a estar en el izquierdo y el nible bajo de A, para a ocupar la parte derecha (y viceversa).

Código: Seleccionar todo

Rutina para imprimir en la parte derecha de la pantalla, la parte izquierda de la fuente
HL = Direccion de la fuente a imprimir
DE = Direccion en pantalla
LD C,[HL]
LD A,[DE]
RLD
LD [DE],A
LD [HL],C

Esto sera a la que se refiere mcleod_ideafix, para usarlo con las rutinas de Andrew Owen / sromero hay que hacer un EX HL,DE antes y despues de la rutina, para ajustar los registros.

Código: Seleccionar todo

LD   A,[DE]      ; A = Pantalla
      LD   C,[HL]      ; C = buffer
      RLD         ; A = parte izquierda
      LD   [DE],A      ; escribir 1 parte del caracter
      LD   A,[HL]      ; tomar dato rotado
      AND   A,#C0      ; tomar solo 2 bits
      LD   [HL],C      ; recuperar caracter

Esto es parte de la rutina de impresion de 42 columnas que diseñe, aqui si encontre ventaja al no tener que hacer las 4 rotaciones.

- ¿Compensa la memoria ahorrada juntando dos caracteres en un byte si por otra parte hay que tener cuatro "copias" de la rutina de vocado de carácter?
- ¿Se ganaría en velocidad de impresión si en cada byte tuviéramos el mismo carácter repetido a izquierda y derecha (evitando así las 4 rotaciones por scan, y seguramente evitando el necesitar 4 rutinas diferentes, como mucho 2)?

Mas que si se ahorra memoria, es si el aumento o disminucion de velocidad compensa. En ensamblador es una balanza con 2 valores a tener en cuenta, velocidad o espacio
Las rutinas que pone, se pueden reducir simplemente utilizando un par de registros (pero solo hay 1 disponible), para hacer los AND's correspondientes, o cambiar el codigo antes de entrar a una rutina con el consiguiente ahorro de tiempo, aunque LD [nn],A tampoco es demasiado rapida que digamos, para cambiar un byte del programa, si que ayudaria a que las rutinas fuesen menos y mas compactas (vale para ambos casos, el que comentas y el que ya esta implementado). En ambos casos se reduciria a la mitad el numero de rutinas de ambas versiones, y usando el RLD/RRD se pueden ahorrar las 4 rotaciones, aunque hay que ser consiente de que son destructivas con la posicion de memoria de HL.

Otra cosa es cuanta memoria necesitamos para los caracteres a imprimir, si 32 caracteres, 256-32 (para los codigos), etc. Yo en mi rutina he puesto solamente 32 caracteres imprimibles (solo 32 letras, aunque se puede variar el set), si usas los 256 caracteres, son muchos bytes los que ahorras. 256*8/2=1024 bytes de ahorro.
Tambien se podian eliminar la 1º y 8º linea a imprimir, la 1º siempre vacia, y la 8º dependiendo de si hay que subrayar o no, se pintaria completa = ahorro de 512 bytes
Si se usasen ambas tecnicas, se ahorrarian 1280 bytes.

Espero a ver la respuesta de Andrew Owen a Z80user y me replanteo la rutina para imprimir los caracteres como comentas...

"I think you might be right. However it's not possible to edit old posts any more"
traduccion googleana: "Creo que puede que tengas razón." Sin embargo, no se pueden editar post viejos.

El enlace que me dijistes que hiciese referencia no se lo he comentado, y le he ayudado a reflotar la rutina en el WOS, la pregunta es si la gente que esta interesada en la rutina, lea todos los mensajes o no, porque si hace un "copy and paste" del codigo sin leerlo le puede dar "dolor de cabeza" ya que el codigo y los comentarios se contradicen.

[sromero]

Pues a ver si saco un hueco para renombrar o los comentarios o los titulos de las "subrutinillas de impresión"...

[climacus]

Ante todo muchas gracias por esta colección de sabiduría del spectrum comprimida.

Quería aportar mi granito de arena.
Estoy desarrollando un juego (del que pronto tendréis noticias) y este artículo me ha venido muy bien para los marcadores.
A la hora de imprimir sin ceros delante, queda un poco raro, ya que no justifica a la derecha, a no ser de que vaya creciendo el número.

Para solucionarlo, habría que incrementar la coordenada Y tantas veces como ceros encontremos.

INC_HL_Remove_Leading_Zeros:

LD A, (HL) ; Leemos caracter de la cadena
OR A
RET Z ; Fin de cadena -> volver
CP '0'
RET NZ ; Distinto de '0', volver
INC HL ; '0', incrementar HL y repetir
LD A,(FONT_X) ;incrementa la coordenada X para justificar
INC A
LD (FONT_X), A
JR INC_HL_Remove_Leading_Zeros


Evidentemente, antes de llamar a esta rutina hay que cargar (FONT_X) con la coordenada donde se quiere imprimir.

Un saludo

[sromero]

Ante todo muchas gracias por esta colección de sabiduría del spectrum comprimida.

Quería aportar mi granito de arena.
Estoy desarrollando un juego (del que pronto tendréis noticias) y este artículo me ha venido muy bien para los marcadores.
A la hora de imprimir sin ceros delante, queda un poco raro, ya que no justifica a la derecha, a no ser de que vaya creciendo el número.

Para solucionarlo, habría que incrementar la coordenada Y tantas veces como ceros encontremos.

INC_HL_Remove_Leading_Zeros:

LD A, (HL) ; Leemos caracter de la cadena
OR A
RET Z ; Fin de cadena -> volver
CP '0'
RET NZ ; Distinto de '0', volver
INC HL ; '0', incrementar HL y repetir
LD A,(FONT_X) ;incrementa la coordenada X para justificar
INC A
LD (FONT_X), A
JR INC_HL_Remove_Leading_Zeros


Evidentemente, antes de llamar a esta rutina hay que cargar (FONT_X) con la coordenada donde se quiere imprimir.

Un saludo

Muy buena idea: impresión del valor numérico justificada

Voy a tratar también de incorporarlo al artículo

[sromero]

Muy buena idea: impresión del valor numérico justificada

Voy a tratar también de incorporarlo al artículo

Añadido al artículo con la obligatoria citación del autor. Está en la sección de conversión a valores numéricos. Además he ampliado la rutina de impresión con argumentos para que permita %z y %Z (imprimir un valor manteniendo los ceros) y %j y %J (justificar a derecha, cambiando en tu rutina el incremento de X por la impresión de un Blank).

Si quieres que cambie allí "climacus" por tu nombre real u otro nick, no dudes en decírmelo.

Un saludo!

[Z80user]

En http://z80user.zobyhost.com/foro/posting.php?mode=edit&f=14&sid=e3a108ba3d06965bce0e4ce2480ab7f3&t=5&p=18 tengo una rutina de impresion de texto de 42 columnas, que permite imprimir apartir de una posicion dada y apuntada por DE, empezando a imprimir en la parte izquierda de dicha direccion, para poder enmarcarla y estar justificada en la parte izquierda de dicha ventana, pudiendo colocarla en cualquier parte de la pantalla correctamente.

DE = direccion de pantalla donde empezar a imprimir
HL = apunta a la direccion de memoria en donde esta el texto a imprimir.
B = Numero de caracteres a imprimir

por si quieres hacer una referencia a la rutina, creo que puede ser util, ya que es mas facil de leer una fuente de 42 caracteres que una de 64.
Ademas he corregido la errata que puse al contar el numero de impresiones por unidad de tiempo 4.565 letras por segundo.

No creo que la legibilidad sea complicada en esceso, ya que el codigo esta suficientemente comentado.