Sobre color border en modo radastan

Avatar de Usuario
chernandezba
Mensajes: 841
Registrado: 02 Oct 2015, 23:35

Sobre color border en modo radastan

Mensaje por chernandezba » 16 Abr 2016, 23:15

Hola.

Aprovechando que he conocido al genial haplo en retroparla hoy, hemos visto una diferencia en el color del border en el zxuno y en ZEsarUX, probando su juego 'tolo'

Resumiendo, en la especificación ulaplus, el color del border se obtiene de la misma manera que el color del paper, que son los colores 8-15 de la paleta ulaplus.

En cambio, en el modo radastan en zxuno hemos comprobado que el color del border sale de los primeros 0-7 colores de la paleta... No sé si esto sucede para todos los modos ulaplus o solo el modo radastan...

Mientras que yo en ZEsarUX sigo la especificación ulaplus que dice que el border sigue los colores 8-15 de ulaplus.

Mi pregunta es... Esto es un error en el zxuno o está hecho expresamente?

Saludos
César
----

ZEsarUX
ZX Second-Emulator And Released for UniX
https://github.com/chernandezba/zesarux

Avatar de Usuario
mcleod_ideafix
Mensajes: 831
Registrado: 27 Sep 2015, 00:14
Ubicación: Jerez de la Frontera
Contactar:

Re: Sobre color border en modo radastan

Mensaje por mcleod_ideafix » 18 Abr 2016, 14:51

La respuesta la tienes en este diagrama, de la wiki del ZX-UNO:
http://www.zxuno.com/wiki/images/c/cb/U ... dastan.png

En él se puede ver que el color del borde, en el modo radastaniano (y sólo en él) se obtiene añadiendo por la izquierda un 0 al color del borde del puerto 254, dando así una entrada de paleta comprendida entre 0 y 7. Es perfectamente discutible si esto debería ser así o bien homogeneizarlo para que sea en el rango de 8 a 15. No hay ninguna razón, que yo recuerde ahora, por la cual tenga que ser en el rango de 0 a 7. Fue una decisión mía completamente arbitraria. Por otra parte, cambiarlo para que esté en el rango 8 a 15 es trivial.

PD: ahora recuerdo vagamente que la idea de ponerlo en el rango de 0 a 7 era por lo siguiente: lo habitual en los juegos es que el borde sea negro. Por otra parte, lo habitual también en los juegos es que un pixel con el valor 0 se considere "negro" o "transparente" (transparente porque al hacer cálculos lógicos a nivel de bits, un pixel con el valor 0000 permite ser usado con AND u OR para indicar si deja pasar el valor del pixel que tiene detrás o no, evitando tener que hacer una máscara aparte), así que el programador normalmente asociará la entrada 0 de la paleta al color negro. Poniendo el rango del borde en las entradas 0 a 7 conseguimos ambas cosas. Si lo pongo en 8 a 15, corro el riesgo de obligar al programador a asignar a dos entradas de paleta el mismo color, malgastando una de ellas.

¿Te convence? ;)
http://www.zxuno.com
ZX-Uno · Clon de ordenador ZX Spectrum basado en FPGA

Avatar de Usuario
chernandezba
Mensajes: 841
Registrado: 02 Oct 2015, 23:35

Re: Sobre color border en modo radastan

Mensaje por chernandezba » 18 Abr 2016, 15:24

Jejee si, me convence, dado que seguramente como dices el color 0 será usado como negro/transparente, un border 0 también dejará el border en negro. Sino con ulaplus estandard deberías definir también el color de paleta 8 para que fuese negro también

Por cierto mirando el diagrama, arriba del todo, donde sale el color del border dice:

Si radastanenabled=1, border es 0 b2 b1 b0 0 b2 b1 b0. Porque esa repetición de bits? Qué significa eso?

Gracias
----

ZEsarUX
ZX Second-Emulator And Released for UniX
https://github.com/chernandezba/zesarux

Avatar de Usuario
antoniovillena
Mensajes: 2621
Registrado: 27 Sep 2015, 20:41

Re: Sobre color border en modo radastan

Mensaje por antoniovillena » 18 Abr 2016, 16:09

A mí me convence más tener un color para el borde distinto del de la paleta principal de 16 colores. Si para el modo radastaniano tenemos 16 de los 64 disponibles de ULAplus (del 0 al 15), lo lógico sería tener el color 16 para el borde (y tener así 17 colores).

Por 2 razones: primero, es una invención nuestra (de radastán y de McLeod) y no hay apenas software que compatibilizar, por lo que podemos hacer lo que queramos. Segundo, para cualquier demo tipo plasma donde se rote la paleta es muy desagradable ver cómo cambia el color del borde. Y tampoco necesita más recursos, porque no sería añadir un registro más, sino emplear uno de los que ya tenemos en ULAplus y no se usan en modo radastaniano.

Avatar de Usuario
Manu
Mensajes: 83
Registrado: 26 Oct 2015, 08:21

Re: Sobre color border en modo radastan

Mensaje por Manu » 18 Abr 2016, 16:52

Me parece muy interesante el comentario de Antonio. De hecho, yo me estuve volviendo un poco loco cuando hice pruebas de paletas y veía el efecto en el color del borde. Si se puede tener un color dedicado, simplificaría el desarrollo y encima añadiría algo de "alegría" :)

Avatar de Usuario
Haplo
Mensajes: 368
Registrado: 05 Oct 2015, 13:51
Ubicación: Ciudad Real

Re: Sobre color border en modo radastan

Mensaje por Haplo » 18 Abr 2016, 18:27

A mí me parece también acertado lo que dice Antonio, si no supone nada complejo de implementar y simplifica algunas cosas, yo lo firmo.

Avatar de Usuario
chernandezba
Mensajes: 841
Registrado: 02 Oct 2015, 23:35

Re: Sobre color border en modo radastan

Mensaje por chernandezba » 18 Abr 2016, 19:08

Bueno de momento lo he dejado como ha dicho mcleod, en modos ulaplus radastan el color sale de los primeros 8 colores de paleta. Si vais a cambiar de nuevo la especificación ya diréis cuando lo tengáis definitivo, que no quiero tocar mas el código, grrrrrrrr

Saludos
----

ZEsarUX
ZX Second-Emulator And Released for UniX
https://github.com/chernandezba/zesarux

Avatar de Usuario
mcleod_ideafix
Mensajes: 831
Registrado: 27 Sep 2015, 00:14
Ubicación: Jerez de la Frontera
Contactar:

Re: Sobre color border en modo radastan

Mensaje por mcleod_ideafix » 19 Abr 2016, 00:15

chernandezba escribió:Si radastanenabled=1, border es 0 b2 b1 b0 0 b2 b1 b0. Porque esa repetición de bits? Qué significa eso?
Eso se averigua recorriendo el datapath. Vamos a ello, pero primero tienes que recordar que en el modo radastaniano, un byte contiene dos píxeles: el izquierdo y el derecho, ok? Lo digo porque es una información que usaremos en un ratito.
  • Partimos del registro de BORDER, arriba a la izquierda del esquema. Allí se guardan los 3 únicos bits que definen el borde. Si el modo radastaniano está activo, esos tres bits se combinan de la forma que has visto para formar un dato de 8 bits.
  • El borde se pinta cuando VideoEnable = 0, si no, lo que se pinta es lo que provenga de AttrData.
  • HR es una señal que viene del módulo de modos de pantalla Timex. Si HR vale 1, el color del borde se define de una forma completamente diferente. Si es 0, como nuestro caso, entonces toma lo que venga del multiplexor anterior
  • Desde el multiplexor gobernado por HR, el dato de 8 bits puede tomar dos caminos diferentes, y de hecho, los hace en paralelo. Sólo al final, se toma el resultado de un camino o de otro dependiendo de si ULAplus está activada o no. En nuestro caso, el modo radastaniano está ligado a que la ULAplus esté activa, así que nos fijaremos en el camino inferior.
  • El dato de 8 bits, que se llama A, pasa por una pequeña transformación que depende de si el modo radastaniano está activado o no. En nuestro caso lo está, así que es dato de 8 bits se descompone en dos datos de 6 bits: pixel izquierdo y pixel derecho. Cada uno de estos dos datos de 6 bits se compone de los 4 bits que corresponden al color del pixel, y a ellos se antepone un prefijo que es 0 0, para indicar el primer cuarto de paleta (los colores 0 a 15). Estos dos valores "atacan" de forma simultánea a la RAM de la paleta, de la cual se obtienen dos valores de 8 bits: el color real del pixel izquierdo, y el del derecho. En el esquema aparecen como color de Ink y color de Paper.
  • El multiplexor que está encima del registro AttrPlusOutput es quien inyecta los pixeles (encendido o ink, apagado o paper) y decide cuál de los dos colores se mostrará. Pero cuando el modo radastaniano está activo, el multiplexor deja pasar una señal llamada H1, que es una señal cuadrada que vale 1 durante el tiempo de pintado de un pixel en modo radastaniano, y 0 durante el tiempo de pintado del segundo pixel. Así, los dos colores se muestran uno detrás del otro. En tiempo de border, los colores izquierdo y derecho deben ser iguales, para que así dé igual si el pixel está encendido o apagado. De ahí que la información del borde esté repetida cuando sale de su registro.
  • El color final a mostrar (PixelColour) pasa por un circuitillo que transforma la representación 332 (3 bits de rojo, 3 de verde, 2 de azul) en notación 333 (3 bits para cada color primario), porque eso es lo que se mostrará en el ZX-UNO.
  • El color de 9 bits va a un último multiplexor que, si ULAplus estáactivo, lo deja pasar, ya hacia los tres DACs exteriores a la FPGA.
Si alguien está pensando que entonces es posible activar el modo radastaniano pero no el ULAplus, y/o ademá activar el modo HR de Timex, la respuesta es SI, se puede. Los resultados, pues recorriendo el datapath lo puedes averiguar. No son modos oficiales, sino simplemente consecuencias de activar modos no pensados para funcionar a la vez. Llámalos "modos indocumentados" si quieres :D

Por ejemplo, si se activa el modo radastaniano, ULAplus, y además el bit HR del puerto $FF del Timex, el resultado es un modo radastaniano normal y corriente en el paper, pero en el border lo que hay es otra cosa diferente: el valor {0 1 !HRInk HRInk}. HRInk es un valor de 3 bits que se guarda en el mismo puerto $FF, y que define el valor de tinta (en el formato habitual de Spectrum) en el modo de superalta resolución Times, de 512x192. Por ejemplo, pongamos que este registro tiene el valor "rojo" (010). El valor de 8 bits que es presentado a los multiplexores durante el tiempo de border es 01 101 010 . Siguiendo el datapath, tenemos que el pixel izquierdo tendría como entrada de paleta la 000110 (6) y el pixel derecho, 001010 (10). El resultado sería un borde con un rayado vertical consistente en dos colores: aquel que corresponda a la entrada de paleta 6, y la entrada de paleta 10. Esto no lo he probado. Lo estoy deduciendo únicamente de lo que pasa en el datapath al activar esos modos.

Dejo como ejercicio ver qué pasa si se activa el modo radastaniano, pero no se activa ULAplus :shock: El efecto es más raro aún, tanto en borde como en paper.

Cambiar el diseño para que el borde venga de una paleta distinta a la de los pixeles de paper implica que en el multiplexor que ataca a las entradas de la RAM de la paleta, al formarse los dos índices de 6 bits a partir del dato de 8 bits, los dos ceros que se anteponen a cada índice deben cambiar (por ejemplo por 0 1 para que el color del borde lo coja de los colores 16 a 31). Esto creo que es posible si sustituyo uno de los ceros por la versión negada de la señal VideoEnable. Así, si uso como prefijo la secuencia {0 , !VideoEnable}, tengo que vale 0 0 cuando estoy en paper, y 0 1 cuando estoy en borde.

Otra cosa que se puede hacer (y aquí va mi propuesta) es que el prefijo, lo que ahora son dos ceros, sea un valor programable desde un puerto de E/S. Me explico: pongamos que en un puerto de E/S propio del ZX-UNO tengo un registro de 4 bits. Dos de ellos indican que cuarto de paleta usaré para paper, y los otros dos para el borde. Si no toco ese registro, el comportamiento por defecto es usar tanto para el borde como para el paper el rango de colores de 0 a 15. Si en el registro pongo el valor, pongamos 1001, estoy diciendo que quiero que el color del paper se tome del rango de paleta 01 (de 16 a 31) y el borde del rango de paleta 10 (de 32 a 47). Los rangos serían:
00 : 0 a 15
01 : 16 a 31
10 : 32 a 47
11 : 48 a 63

Aviso que el multiplexor donde habría que hacer estos cambios está en un lugar un tanto crítico para lo que es la temporización, así que igual el meter un multiplexor en medio (para elegir un rango u otro dependiendo de si estamos en paper o en borde) afecta tanto a la temporización que podrían aparecer glitches, pero creo que merece la pena probarlo. ¿Que os parece?

Ah! aprovecho para recordar que en el ZX-UNO existe interrupción ráster. Esto significa que, de funcionar este invento, puedes definir los 64 colores de la paleta de ULAplus, y en una interrupción ráster, cambiar de golpe el rango de paleta que usarán los píxeles de borde o paper, o ambos, desde cierta línea en adelante, permitiéndote, con poco gasto de CPU, romper la barrera de 16 colores simultáneos en pantalla.
http://www.zxuno.com
ZX-Uno · Clon de ordenador ZX Spectrum basado en FPGA

Avatar de Usuario
chernandezba
Mensajes: 841
Registrado: 02 Oct 2015, 23:35

Re: Sobre color border en modo radastan

Mensaje por chernandezba » 19 Abr 2016, 08:39

Gracias por tu explicación tan extensa :) me he perdido un poco en detalles técnicos pero al menos ya queda satisfecha mi curiosidad ;)
En cuanto a la nueva manera de decidir el border, yo como dije dejare el mismo método que está haciendo el zxuno ahora y en cuanto haya una decisión definitiva sobre el nuevo formato lo modificaré en emulador

Saludos
César
----

ZEsarUX
ZX Second-Emulator And Released for UniX
https://github.com/chernandezba/zesarux

Avatar de Usuario
Hark0
Mensajes: 683
Registrado: 27 Sep 2015, 00:31
Ubicación: Cornellà de Llobregat - BCN
Contactar:

Re: Sobre color border en modo radastan

Mensaje por Hark0 » 19 Abr 2016, 11:43

Digo lo mismo que el amigo @chernandezba ;)
http://www.zxuno.com
ZX-Uno · Clon de ordenador ZX Spectrum basado en FPGA.

Responder