Tiempos de retrazo vertical y horizontal

[wilco2009]

He estado revisando la parte del core de spectrum donde describe los contadores de visualización y me han llamado la atención un par de cosas.

1ª - ¿Porqué es diferente el tiempo del contador horizontal y el vertical en un 48Kb que en un 128Kb o el pentagon?.

2º - ¿No deberían coincidir las interrupciones de retrazo horizontal y vertical con el momento del blanking?

Mi conocimiento sobre el video del spectrum no es muy profundo y desconocía estos detalles.

[mcleod_ideafix]

He estado revisando la parte del core de spectrum donde describe los contadores de visualización y me han llamado la atención un par de cosas.

1ª - ¿Porqué es diferente el tiempo del contador horizontal y el vertical en un 48Kb que en un 128Kb o el pentagon?.

Por diseño: el 128K emplea un reloj base de 17.7345MHz, y de ahí, dividiendo entre 2.5 obtienes el reloj de pixel (el que alimenta los contadores) que es de 7.0938 MHz. En el 48K se emplea un reloj base de 14 MHz, y de él, dividiendo entre 2 tienes el reloj de pixel: 7 MHz. Ahora bien: el contador horizontal debe llegar a 64us. Para lograr eso, con el reloj de 7MHz del 48K, eso son exactamente 448 cuentas. En binario, 448 es 111000000, así que para detectar cuando hay que resetear el contador hay que detectar el momento en que éste pasa de valer 110111111 a valer 111000000. Esto equivale a mirar cuándo los bits 6, 7 y 8 valen los tres 111. En ese momento se produce un reset asíncrono y el contador vuelve a valer 0. Es decir: sólo hay que comprobar tres bits, y eso desde el punto de vista hardware es muy económico.

En el 128K, cuyo reloj de pixel es 7.0938 MHz, hacen falta 454.0032 cuentas, así que una buena aproximación sería escoger como valor de reset cuando el contador llegue a 454, pero este valor es muy malo para comprobar en hardware, ya que es 111000110. Es decir, hay que comprobar cuándo se pasa de 111000101 a 111000110, y esto supone chequear muchos bits (cinco bits), lo que es costoso en hardware. El "apaño" que hicieron fue escoger el valor más cercano a 454, que se parezca a 448 en cuanto a facilidad de decodificación, y ese valor es 456, que en binario es 111001000. Aquí hay que comprobar cuatro bits: uno más que en el caso del 48K.

En este momento pensarás que no es para tanto, que sólo se han ahorrado un bit en la decodificación. Bueno: hay un par de cosas a tener en cuenta, y son: el pintado del borde, y el mecanismo de contienda. Este mecanismo se basa en tramos de 16 ciclos de reloj de pixel. Durante 12 de esos ciclos hay peligro de contienda. En los 4 restantes, Cuando no se pinta el paper, se pinta el borde, y se hace siempre de 8 en 8 píxeles. Es decir, la circuitería "mira" el valor del puerto 254 cada 8 píxeles y repite ese color durante los 8 siguientes píxeles. El pintado del borde por tanto siempre termina en un número de ciclos múltiplo de 8, así que la cuenta total de píxeles por línea debe ser múltiplo de 8. 448 y 456 lo son, pero 454 no.

Lo malo es que 456 cuentas nos dan una frecuencia de línea de 65.1428 microsegundos. Es 1.14 microsegundos más de lo necesario, y se sale de norma PAL, pero parece que los televisores (casi todos) pueden con esta tolerancia. Algunos no, y de ahí que el 128K y el +2A/B/3, que tienen los mismos timings, dé más problemas con las teles modernas que el 48K.

Por otra parte tenemos el contador vertical: en el 48K este contador cuenta 312 líneas. En rigor, debería contar 313 o 312 según estuviéramos en campo par o impar, pero una vez más, la simplificación entra en juego y se usa siempre el valor 312. Esto hace que la frecuencia de campo no sean los 50Hz justitos de PAL, sino un poco más: 7000000 / (312*448) = 50.08Hz. Una vez más, las teles parecen no tener problemas con esta frecuencia vertical ligeramente fuera de norma.

Pero en el 128K, si mantenemos la cuenta de 312 líneas verticales nos saldría una frecuencia de campo de 7093800 / (456*312) = 49.86Hz, que se alejaría de los 50Hz nominales, así que la ULA del 128K sólo cuenta hasta 311, dando una frecuencia de campo de 7093800 / (456*311) = 50.0211Hz, que es un valor incluso más cercano a 50Hz que en el 48K.

Llegados a este punto, te aconsejo el libro de la ULA de Chris Smith, donde se discuten estas y otras muchas cosas

En el caso del Pentagon, no conozco su circuito eléctrico (se puede conseguir en la red, pero las nomenclaturas que usa para los integrados no son las usuales para mi, y me cuesta leerlo, además que nunca he encontrado una versión clara del esquema: las que encuentro son escaneados a baja resolución). Para los timings me he basado en una FAQ donde se explican los timings del Pentagon y el Scorpion. Yo soy el primero que se extraño un montón al ver, por ejemplo, que el Pentagon usa 320 líneas por campo y 448 puntos por línea, con un reloj de pixel de 7MHz, dando una frecuencia de campo muy baja, del orden de 7000000 / (448*320) = 48.828 Hz. No sé por qué usaron esa cantidad de líneas en lugar de 312.

2º - ¿No deberían coincidir las interrupciones de retrazo horizontal y vertical con el momento del blanking?

La interrupción del retrazo vertical de hecho coincide con el comienzo del pulso de sincronismo vertical, al menos en 48K y 128K. No recuerdo en el Pentagon.

La interrupción de retrazo horizontal es exclusiva del ZX-Uno. No existe en ninguno de los otros tres modelos, y para implementarla simplemente me fijé en cómo la implementa el SAM Coupé. En él (y en el ZX-Uno) la interrupción ráster se dispara al comienzo del borde derecho de la línea anterior a aquella que hemos fijado, con el objetivo de que cuando de verdad se vaya a ejecutar la rutina de servicio, aún le dé tiempo a ésta de hacer cambios en el borde o en los atributos o en la paleta antes de que la ULA comience a dibujar el comienzo del borde izquierdo de la línea donde se ha fijado la interrupción.

[wilco2009]

Muchas gracias, ahora creo que me queda bastante claro.

Para ayudarme a entender la implementación hardware, he estado comparando la descripción hardware del zx-uno con el esquema del Harlequin, ayudado por el libro de la ULA de Crish Smith.

No se si es muy importante a la hora de la compatibilidad, pero he visto que los valores que se usan en el Harlequin para el pulso de sincronismo horizontal son de 336 a 337 que según el libro de la ULA corresponden a las ULAs anteriores a la 5C, mientras que en el ZX-UNO se utiliza el valor correspondiente a la ULA-6C (344 - 375). ¿Has seleccionado ese por algún motivo?.

Por otro lado, y esto quizás es un poco off-topic, he estado viendo como se controla el tema del flash y el brillo. Mientras que en la descripción hardware del ZX-UNO me queda totalmente claro, en el esquema del Harlequin se me escapa algo.

En el Harlequin, la señal RGB sale de 4 multiplexores de entradas, 3 para las señales RGB y 1 para la señal de brillo. Esta señal de brillo la combina con cada componente mediante unas resistencias.
De las 4 señales de entrada utiliza 3 para los valores de Paper, ink y border generando la salida que toque en cada momento

El problema viene de como genera esta señal, ya que viene combinada de la manera que explico abajo.

La salida de U29B contiene el atributo de flash actualizándose cada 16 frames. Dicha señal se combina con XOR valor de pixel (0/1).

Este valor de pixel combinado con el flash se utiliza como primer bit de selección del ultimo multiplexor, mientras que el segundo bit corresponde a la señal VOUT que marca cuando estamos pintando dentro de la pantalla.

Las dos primeras entradas del multiplexor están conectadas a DD6 que es el atributo de brillo mientras que las dos segundas están a masa. Por lo tanto me parece entender que cuando toca pintar seleccionamos como salida el valor de brillo y cuando no seleccionamos 0 (masa).

O sea que no entiendo como funciona el tema del brillo. Aparentemente está pintando solo cuando el brillo está a 1, pero evidentemente esto no puede ser así por razones obvias.

¿Se me está escapando algo?

Perdona el asalto y muchas gracias por tu paciencia.

[mcleod_ideafix]

según el libro de la ULA corresponden a las ULAs anteriores a la 5C, mientras que en el ZX-UNO se utiliza el valor correspondiente a la ULA-6C (344 - 375). ¿Has seleccionado ese por algún motivo?.

Sí. Por ser unos valores más cercanos a lo que dice la norma PAL. Además, se fabricaron más ulas 6C que 5C, así que el ZX-Uno implementa la ULA más popular, por decirlo de alguna forma.

Por otro lado, y esto quizás es un poco off-topic, he estado viendo como se controla el tema del flash y el brillo. Mientras que en la descripción hardware del ZX-UNO me queda totalmente claro, en el esquema del Harlequin se me escapa algo.

En el Harlequin, la señal RGB sale de 4 multiplexores de entradas, 3 para las señales RGB y 1 para la señal de brillo. Esta señal de brillo la combina con cada componente mediante unas resistencias...
...
...
¿Se me está escapando algo?

Creo que los tiros van por lo siguiente: el Harlequin no es una reproducción 100% del comportamiento de la ULA, y de hecho hay algo en lo que se diferencia de una ULA original (o del ZX-UNO), y eso es precisamente lo que ocurre en la etapa final, cuando hay que elegir entre border, paper o negro (blanking). En la ULA original el color del borde se inyecta en el segundo latch cuando toca pintar el borde. En el Harlequin, el color del borde se inyecta al final del todo. Esto tiene como efecto el que en el Harlequin, y a diferencia de lo que ocurre en el ZX Spectrum, en el Harlequin el color del borde puede cambiarse teóricamente a nivel de pixel. En el ZX Spectrum, si tú cambias el color del borde en un determinado T-State, este cambio no se refleja en el borde hasta el siguiente múltiplo de 8 píxeles. Este video te lo muestra (lo que ocurre en él no funcionará igual en un Spectrum original, o en el ZX-Uno)

phpBB [media]

El multiplexor que muestras en la imagen es un multiplexor de 3 bits y 4 entradas. Las entradas de control son A y B, y las entradas son (de menos a más significativa): paper, ink, border y border. Paper e ink comparten el bit de brillo, así que en uno de los multiplexores (U32, mux 2), el bit de brillo está conectado a las entradas 0 y 1. El borde no tiene brillo así que en ese multiplexor el brillo siempre vale 0.

Cuando estamos en intervalo de blanking, lo que se hace es inhibir todos los multiplexores a través de su entrada /G, de forma que cuando se inhiben, la salida es 0, el color negro.

Este valor de pixel combinado con el flash se utiliza como primer bit de selección del ultimo multiplexor, mientras que el segundo bit corresponde a la señal VOUT que marca cuando estamos pintando dentro de la pantalla.

VOUT, que es la señal B de control del multiplexor, vale 0 cuando estamos pintando paper. Cuando vale 1, estamos pintando border. Así, los valores de A y B se corresponden con:

Código: Seleccionar todo

G A B | Y
------+------------------
0 0 0 | Pixel de paper
0 1 0 | Pixel de ink
0 0 1 | Borde
0 1 1 | Borde
1 x x | Negro (blanking)

Repito: no es así como está implementado en la ULA (y en el ZX-Uno). De hecho, no existe tal multiplexor de 4 entradas en la ULA, sino que cuando llega el momento de pintar el borde, el registro de desplazamiento de 8 bits carga siempre ceros, en lugar de cagar un valor de memoria, y el latch de atributos se carga cada 8 pixeles con el color del borde, estando el bit de brillo y el de flash a 0. Lo que sí hay es un multiplexor para indicar si se pinta ink, o paper/border (el borde se trata como si fuera paper, ya que durante el borde, el registro de desplazamiento que "escupe" los píxeles vale 0)

Hay un documento de la patente del sistema de video, de Richard Altwasser, que te muestra el esquema con mucha claridad. Es éste:

[wilco2009]

Qué curioso lo del border, la verdad es que no había pensado en ese efecto colateral.

Creo que más o menos es lo que yo había interpretado, pero me había bailado una conexión cuando miraba el esquema. Y mira que lo he mirado y remirado veces.

El pixel mezclado con el flash es el que se conecta con la señal de control A para los cuatro multiplexores, mientras que la señal de sincronismo habilitado (VSyncEn) es la que va conectada a B, de tal forma que si A=1 (hay pixel) se pinta del color del pixel, si A=0 (no hay pixel) se pinta del color del paper y si B=1 se pinta del color del borde haya lo que haya en el bit de pixel.

Por otro lado el cuarto multiplexor se asigna con el bit de brigth (DD6) siempre que B=0 (o sea que estemos dentro de la pantalla) en caso contrario asigna 0.

El esquema del funcionamiento de Altwasser queda bastante claro. Entiendo que falta representar la suma analógica con el brillo que quedaría fuera del esquema.

Lo dicho, gracias por la respuesta.

[mcleod_ideafix]

El esquema del funcionamiento de Altwasser queda bastante claro. Entiendo que falta representar la suma analógica con el brillo que quedaría fuera del esquema.

Si, pero si mal no recuerdo, en otra parte de la patente aparece esa parte del esquema. Y si no, aparecer aparece seguro en el libro de la ULA de Chris.