Proposición de gráfica externa para ZX Spectrum

[mcleod_ideafix]

La lógica impone que sea el de 128x96, ya que todo se moverá con mucha más soltura. Ya he realizado pruebas en ese modo y sale cojonudísimo a nivel gráfico:

Pues hala. 128x96 será pues.

[antoniovillena]

128x96 ó 128x192. ¿Y porqué no las 2 cosas a la vez? A nivel de accesos a memoria 128x96 no es "más lento" que 128x192. Lo que propongo son 2 modos casi idénticos. En el modo pixeles rectangulares (128x192) en las filas pares (empezando en cero) se accede al nibble bajo y en las impares al nibble alto. En el modo pixeles cuadrados podemos bypassear la paleta ULAplus y directamente sacar 256 colores, como de todas formas se accede al mismo byte, pues simplemente se pinta dos veces. Si te das cuenta el hardware que implementa los dos modos es mínimo, ya que en ambos el acceso a RAM es exactamente el mismo.

Supongo que te habrás dado cuenta pero con un buffer de una línea (128 bytes) te ahorras la mitad de accesos a RAM por parte de la ULA.

-- Actualizado 28 Feb 2014, 01:50 --

Sería como la diferencia entre modo 1 y modo 0 del Amstrad CPC sólo que los pixeles se alargan verticalmente (en lugar de horizontalmente) y pasamos de 8 a 4 bits por pixel (en lugar de 4 a 2 bits).

-- Actualizado 28 Feb 2014, 01:59 --

• Modo 0: 128x96x8.
  
  • Línea 0: $4000..$407F.
  • Línea 1: $4080..$40FF.
  • Línea 2: $4100..$417F.
  • ...
  • Línea 95: $6F80..$6FFF.
• Modo 1: 128x192x4.
  
  • Línea 0: $4000..$407F nibble bajo.
  • Línea 1: $4000..$407F nibble alto.
  • Línea 2: $4080..$40FF nibble bajo.
  • ...
  • Línea 191: $6F80..$6FFF nibble alto.

[mcleod_ideafix]

128x96 ó 128x192. ¿Y porqué no las 2 cosas a la vez? A nivel de accesos a memoria 128x96 no es "más lento" que 128x192.

No. Se hacen de hecho el mismo número de accesos. ¿Por qué no las dos cosas a la vez? Pues porque esto no es más que un experimento para llevar a RM2014, y que si acaso, tendrá un juego de demostración, el único que probablemente exista para ese modo, que ni siquiera estará en el core final del ZX-Uno (porque empezamos a acercanos poco a poco al 100% de ocupación de slices en la FPGA y quiero tener espacio holgado para implementar el SPI para la flash, y el de la SD)

Supongo que te habrás dado cuenta pero con un buffer de una línea (128 bytes) te ahorras la mitad de accesos a RAM por parte de la ULA.

Pero la lógica de manejar ese buffer (que no sería un buffer sino dos: se pinta uno mientras se rellena el siguiente) es más costosa que leer directamente desde memoria (que hay tiempo suficiente para hacerlo siempre y cuando sigan siendo dos pixeles por byte leido). No me voy a meter en nada más complejo.

[antoniovillena]

Pero la lógica de manejar ese buffer (que no sería un buffer sino dos: se pinta uno mientras se rellena el siguiente) es más costosa que leer directamente desde memoria (que hay tiempo suficiente para hacerlo siempre y cuando sigan siendo dos pixeles por byte leido). No me voy a meter en nada más complejo.

Hombre si no va a ver contención no te merece la pena implementar el buffer.

-- Actualizado 28 Feb 2014, 02:53 --

Para modo único el 128x96x8 es más sencillo que el 128x96x4 ya que no tienes porqué implementar la paleta. Inconvenientes: el doble de memoria de video y por tanto rutinas gráficas más lentas.

[Zardoz]

• Línea 0: $4000..$407F nibble bajo.
• Línea 1: $4000..$407F nibble alto.
• Línea 2: $4080..$40FF nibble bajo.
• ...
• Línea 191: $6F80..$6FFF nibble alto.

Por curiosidad, por que así? Por que no se usar el nibble bajo para el pixel X y el nibble alto para el pixel X+1.

[antoniovillena]

Por curiosidad, por que así? Por que no se usar el nibble bajo para el pixel X y el nibble alto para el pixel X+1.

Por ninguna razón, supongo que intuitivamente he intentado hacer algo parecido a Little Endian. De todas formas era una propuesta, al final habrá sólo un modo único de 128x96x4 (6Kb de memoria de video).

[mcleod_ideafix]

Para modo único el 128x96x8 es más sencillo que el 128x96x4 ya que no tienes porqué implementar la paleta. Inconvenientes: el doble de memoria de video y por tanto rutinas gráficas más lentas.

Eso es cierto si no estuviera implementada ya la ULAplus, pero es que lo está, así que puedo usarla. El modo que estoy implementando, 128x96x4 bits, lo he diseñado de forma que afecte lo menos posible a la ruta de datos existente. Así, para habilitarlo, hay que habilitar también ULAplus (es decir, para habilitar el modo radastaniano hay que hacer):

Código: Seleccionar todo

OUT 48955,64 : OUT 65339,3

El bit 0 del registro 64 activa la ULAplus, como siempre, y el bit 1 activa el modo radastaniano.

Cuando el modo radastaniano se activa (para ver esto es conveniente tener el dibujo de la ruta de datos al lado), sólo se usa como registro de entrada desde la VRAM el registro AttrData. Este es cargado con los contenidos de la memoria una vez cada cuatro ciclos de pixel original (es decir, el reloj de pixel de 7MHz que nos da los 256 pixeles originales). El byte (dos píxeles) viaja hasta la LUT de la paleta, donde un nuevo multiplexor (que se ha añadido para este modo) redirige 4 bits del pixel hacia un bus de direcciones de la paleta, y los otro 4 bits al otro.

La señal AttrOutpuLoad ahora en este modo se actualiza también mucho más deprisa: en el ciclo de reloj siguiente a que se hayan cargado los bytes de la VRAM. Eso da tiempo al que el byte cargado se propague por la ruta de datos hasta la salida de la LUT. La LUT da dos salidas de 8 bits, que son dos colores. Originalmente son los colores de paper y tinta, pero ahora son los colores del pixel izquierdo y derecho del byte.

El multiplexor que elige un color u otro, en este modo no está gobernado por la señal Pixel, sino que está gobernado por el bit 1 del contador de líneas horizontales: esto hace que se seleccionen alternativamente uno u otro color, a una cadencia de 1 cambio por cada dos ciclos de reloj de pixel original.

La salida va como en la ULAplus al multiplexor final, que lo saca hacia afuera. Para que dicho multiplexor elija este modo, ULAPlusEnabled debe ser igual a 1, o lo que es lo mismo, el bit 0 del registro de configuración de la ULAplus debe ser 1.

Así es a grandes rasgos. Estoy terminando de hacer pruebas. De momento no pinta bien (en el sentido literal de la palabra ) ya que debo haber liado bits por algún sitio, y cuando pokeo en memoria.... ¡se pinta el borde!

-- Actualizado 01 Mar 2014, 04:52 --

¡Ea! Ya pinta bien. Esta es la pantalla que Radastan hizo como moco de un posible juego basado en este modo, vista en el ZX-Uno (video compuesto):



En el repositorio del ZX-Uno vereis un nuevo core, test9_radastan, que contiene los aditamentos al core del test9 que se le han hecho a la ULA para este modo. No se ha tocado el resto de módulos Dentro de este directorio hay otro "software" que contiene un visor simple de ficheros BMP. Para usarlo, simplemente coge una imagen, escálala a 128x96, reduce el número de colores a 16, y grábala como fichero BMP de 4 bpp sin comprimir. El fichero debe tener 6262 bytes. Vereis un fichero ASM para ensamblar con PASMO. Al final del todo, en la línea con el incbin, pon el nombre del fichero convertido. Ensambla para obtener un TAP y cárgalo en el ZX-Uno

El modo "radastaniano" tiene las siguientes características:
- Resolución de 128x96 píxeles cuadrados, aspect ratio de la pantalla: 4:3
- Direccionamiento lineal en memoria en el rango 16384-22527
- Dentro de cada byte, los bits 4 a 7 contienen el color del pixel más a la izquierda, y 0 a 3, el color del pixel de más a la derecha
- Los colores se toman de las 16 primeras entradas (0 a 15) de la paleta de ULAplus
- El color del borde se toma de las entradas 0 a 7 de la paleta. (¿se prefiere así, o que tome el color de otras entradas distintas, tales como desde la 16 a la 23 para que el color del borde pueda hacerse independiente del de la pantalla?)
- No hay contención del Z80 en ningún momento.
- 4 páginas de pantalla disponibles: 4000h, 6000h, C000h, E000h. Estas dos últimas, en el banco 7 de memoria. Para cambiar de pantalla, por ejemplo de la 4000h a la 6000h, o de la C000h a la E000h, hay que poner un 1 en el bit 0 del puerto $FF (ya que esta característica está heredada de los modos de Timex implementados)
Como se usa:
- Establece los colores que vayas a usar en las entradas 0-15 de la paleta de ULAplus
- Activa el modo radastaniano junto con el de ULAplus, metiendo el valor 3 en el registro 64 de ULAplus

Efectos secundarios: si se activa únicamente el modo radastaniano sin activar ULAplus (es decir, poniendo un 2 en el registro 64 de ULAplus), la ULA se comportará de una forma no prevista, y que viene a ser lo siguiente:
- Resolución de 64x96 píxeles (pixeles el doble de largos que altos)
- Cada pixel se corresponde con un byte de memoria en el rango 16384-22527, direccionamiento lineal.
- El color de un pixel viene dado por el valor leido de memoria, interpretando los colores como en los atributos estándar (flash, brillo, paper, ink)
- Dado que el serializador de píxeles no está funcionando durante el modo radastaniano, el único valor que saca es 0, por lo que el color que siempre se escoge para el pixel es el que esté establecido como paper. Dicho de otra forma: los 3 bits menos significativos del byte leído no se usan para nada. El brillo y el flash se usan como de costumbre.
- El color del borde... bueno, el efecto colateral éste que comento hace que el borde presente como color el codificado en el atributo 0 B2 B1 B0 0 0 0 0. Es decir, que si pones OUT 254,7 el color que aparece es amarillo brillante. Como la componente de azul siempre es 0, los colores disponibles son negro, rojo, verde, y amarillo; con y sin brillo.

-- Actualizado 01 Mar 2014, 05:08 --

Otro ejemplito. Esta vez es un fotograma de la película Gravity.

[na_th_an]

Queda genial. ¿No habría entonces espacio para que este modo formase parte del core del ZX-Uno estándar? Es bastante atractivo.

[mcleod_ideafix]

Queda genial. ¿No habría entonces espacio para que este modo formase parte del core del ZX-Uno estándar? Es bastante atractivo.

Hasta que no se terminen de añadir el resto de características "base" no podré saberlo.

-- Actualizado 02 Mar 2014, 13:24 --

Como referencia para futuras ampliaciones o versiones, ésta es la ruta de datos de la ULA, una vez incorporado a la misma el modo "radastaniano"
Los nuevos elementos están en rosita chicle, color radastaniano por excelencia

Este esquemático es la versión gráfica de lo que hay descrito en las 237 líneas de código Verilog que comprende la parte de ULA que describe la ruta de datos. Pa que luego vengan con que si esto es emulación, que si la FPGA no es electrónica de verdad, etc etc.

He aprovechado para clarificar un poco más el significado de algunas señales, sobre todo aquellas que se activan por parte de la CPU. Ahora se ve qué puertos de E/S actúan sobre cada registro.

Siguiendo esta ruta de datos se puede adivinar qué pasa si se activa el modo radastaniano pero no se activa la ULAplus

(clic para ampliar y poner como poster en tu dormitorio, o fondo de escritorio hi-tech)

[mcleod_ideafix]

Añadido otro fichero BMP para ver con el visor de 128x96: un pixel-art de Padre de Familia. Foto hecha a un monitor TFT donde la imagen se ve mediante una tarjeta de captura por video compuesto.



Pixel art original disponible aquí: http://garotasgeeks.omelete.uol.com.br/ ... no-moraes/

-- Actualizado 02 Mar 2014, 20:43 --

Y otro más que me ha hecho gracia... una imagen de Bob Esponja. Estaba con el editor gráfico simulando a ver cómo se vería en 128x192x16 colores, y al compararlo con la versión a 128x96, vi que ésta última quedaba mona, así que la he incorporado.



PD: añadir el modo de 128x192 es bestialmente trivial. Eso sí: son 12288 bytes por pantalla, todos seguiditos, con lo que no sería compatible con nada hecho en BASIC, por ejemplo (a menos que uses el banco 7 de VRAM y tu bitmap comience a partir de 49152 en lugar de 16384). Bueno, allá va Bob Esponja a 128x96...