Proposición de gráfica externa para ZX Spectrum

[mcleod_ideafix]

Los gráficos que me has pasado, con la paleta corregida:

paleta_experimento.png (300 Bytes) Visto 7760 veces

work.png (1.24 KiB) Visto 7760 veces

sprites.png (1.37 KiB) Visto 7760 veces

test.png (1.86 KiB) Visto 7760 veces

[radastan]

Estupendo, me pongo entonces a preparar los gráficos buenos, estos los modifiqué de los originales en media hora. Aparte que no voy a usar la churrera y usaré un motor propio.

[Zardoz]

Al final que resolución vais a usar ?

[radastan]

Al final que resolución vais a usar ?

256x128 y 16 colores por pixel, panorámico para que se ve nativo en las teles de hoy día.

Con un par.

[Zardoz]

Echadle un vistazo a esto : http://fingswotidun.com/dcpu16/GraphicsMode1.png

[mcleod_ideafix]

No lo veo adecuado para gráficos en movimiento. Se basa en tiles de 3x3 píxeles, que comparten dos colores. El último pixel del tile siempre aparece como apagado. Actualizar parte de la pantalla con un sprite conservando el fondo, teniendo en cuenta esta distribución, se me antoja muy lento para el Z80 (salvo quizás que tus sprites estén compuestos siempre de ladrillitos de píxeles de 3x3 píxeles). Cuando había propuesto la distribución entrelazada de píxeles ya estaba pensando en cómo mover eso con un Z80, para que fuera rápido.

Por otra parte, el modo de pantalla ideado por Radas puede sacar exactamente los mismos gráficos que se ven ahí, e incluso mejores. Tenemos también 16 colores, pero en nuestro caso no están compartidos por tiles de 3x3, o de 8x8 (como es el caso del Spectrum), sino que cada pixel tiene su propio color independiente del vecino. Hay dos píxeles por byte, que pueden manejarse de forma más o menos eficiente con las instrucciones RLD / RRD . Como los 16 colores son programables en paleta, podemos remedar esa misma paleta que se ve en el dibujo.

Por supuesto, es un modo que ocupa más memoria que el propuesto en el gráfico, pero es que si quieres mover sprites con soltura y no tienes hardware específico para sprites, tienes que tener una disposición de pantalla que ayude lo máximo posible al procesador.

[Zardoz]

Es una forma ingeniosa de compactar los graficos. Para cambiarlo de un color a otro, solo tienes que conmutar el color de apagado/encendido de la celda y invertir los bits de activo/inactivo.

De todas formas, me refería más a la paleta que al modo gráfico (que imagino que sera un dolor de implementar en hardware.), ya que es más agradable que la típica paleta de 16 colores

[mcleod_ideafix]

De todas formas, me refería más a la paleta que al modo gráfico (que imagino que sera un dolor de implementar en hardware.), ya que es más agradable que la típica paleta de 16 colores

No, estas cosas no son complicadas de implementar en hardware. El dolor está cuando quieras usarlo desde el procesador. Piensa que ese modo gráfico está optimizado para un procesador didáctico de 16 bits, y que además tiene instrucciones de almacenamiento directo en memoria (sin pasar por registros), no de 8 bits como el Z80.

La paleta no es problema: dentro de los límites del formato 3:3:2 que se va a usar, puede redefinirse para obtener 256 colores diferentes. Algunos de ellos probablemente sean iguales o parecidos a los que aparecen en esa paleta.
Como referencia, ésta es la paleta completa de ULAplus, que coincide con la paleta completa del modo de Radas:

[mcleod_ideafix]

Te contesto por aquí, para no desvirtuar el hilo del ZX-Uno:

Hagamos números así de pronto:

La ULA, en su diseño actual, puede direccionar un máximo de 16KB de memoria. Por otra parte, la velocidad máxima con la que se puede acceder a memoria es a razón de 1 byte cada 285ns aproximadamente (dos ciclos de pixel, tomando como ciclo de pixel el periodo de un reloj de 7MHz). Este es nuestro principal cuello de botella, y está causando por el acceso entrelazado que necesito para la ULA y el Z80, y por la velocidad máxima de la memoria que usamos.

Con 16K de memoria, y a razón de 4 bits por pixel, se pueden tener un máximo de 32768 pixeles, y dado que puedo leer un byte (dos píxeles) cada dos ciclos de píxeles, tengo el tiempo (en teoría) justito justito para entregar píxeles. Si tuviera que luchar con la CPU, este modo serial brutal en contención, pero resulta que no, que no tengo que luchar contra nadie, así que hasta me podría permitir el lujo de deshabilitar la contención del Z80 en tu modo de video.

Volvemos a esos 32768 píxeles máximo. Sin tocar (mucho) los timmings, efectivamente podemos tener un modo de 128x96, que se llevaría lo mismo que una pantalla monocromática del Spectrum, 6144 bytes.

O podríamos tener un modo de pantalla de píxeles rectangulares de 128x192 píxeles, a 12288 bytes. ¿Cómo verías éste? Ten en cuenta que el de 128x96 se implementaría en realidad como uno de 128x192, en el que dos scans consecutivos de pantalla se leerían desde las mismas posiciones.

Los 16 colores de cada uno de los píxeles serían paletizados, aprovechando la lógica de paleta de la ULAplus.

[radastan]

Volvemos a esos 32768 píxeles máximo. Sin tocar (mucho) los timmings, efectivamente podemos tener un modo de 128x96, que se llevaría lo mismo que una pantalla monocromática del Spectrum, 6144 bytes.

O podríamos tener un modo de pantalla de píxeles rectangulares de 128x192 píxeles, a 12288 bytes. ¿Cómo verías éste? Ten en cuenta que el de 128x96 se implementaría en realidad como uno de 128x192, en el que dos scans consecutivos de pantalla se leerían desde las mismas posiciones.

Los 16 colores de cada uno de los píxeles serían paletizados, aprovechando la lógica de paleta de la ULAplus.

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: