ZX-Uno - kit de programación modo Radastaniano

Sinclair QL, ZX81, +2, +3, 128K ...
Avatar de Usuario
na_th_an
Amiga 1200
Amiga 1200
Mensajes: 1273
Registrado: 10 Oct 2012, 11:17
Sistema Favorito: (Otro)
primer_sistema: Spectrum +2
consola_favorita: Sony PlayStation 1
Primera consola: Sega Master System
Gracias dadas: 18 veces
Gracias recibidas: 15 veces

Re: ZX-Uno - kit de programación modo Radastaniano

Mensajepor na_th_an » 09 Jun 2015, 12:14

Para eso necesitáis rutinas de impresión con máscaras, mucho más rápidas para modos en los que vayan varios píxeles en el mismo byte.

Avatar de Usuario
Haplo
MSX Turbo R
MSX Turbo R
Mensajes: 278
Registrado: 14 Abr 2014, 22:24
Sistema Favorito: PC
primer_sistema: Spectrum +2
consola_favorita: Sony PlayStation 1
Primera consola: Nintendo NES/Clónica
Ubicación: Ciudad Real
Gracias dadas: 33 veces
Gracias recibidas: 5 veces

Re: ZX-Uno - kit de programación modo Radastaniano

Mensajepor Haplo » 09 Jun 2015, 12:23

Ya, si lo sé, lo que preguntaba es la posibilidad de hacer algo así un "croma" por hardware. La memoria que ocupan los gráficos no cambia, pero el manejo de sprites sería más rápido al no tener que mezclar el fondo con el sprite por software.

Avatar de Usuario
na_th_an
Amiga 1200
Amiga 1200
Mensajes: 1273
Registrado: 10 Oct 2012, 11:17
Sistema Favorito: (Otro)
primer_sistema: Spectrum +2
consola_favorita: Sony PlayStation 1
Primera consola: Sega Master System
Gracias dadas: 18 veces
Gracias recibidas: 15 veces

Re: ZX-Uno - kit de programación modo Radastaniano

Mensajepor na_th_an » 09 Jun 2015, 13:10

Sin saber de hardware lo suficiente, me aventuraría a decirte que lo que pides es imposible. La memoria gráfica no es más que RAM que la ULA interpreta de cierta manera y construye una imagen. Imprimir un sprite no es más que una escritura en RAM. ¿Cómo distinguir una escritura de otra? Me refiero a ¿cómo saber que el LD (HL), A es para imprimir un sprite y que debe hacerse una mezcla auto-enmascarada con lo que hay en (HL) y lo que viene en A? Ten en cuenta que no hay un chip dedicado al video, sino que es la CPU quien se encarga de leer y escribir de RAM. Para el Z80, cualquier escritura en memoria es igual que las demás. No está preparado para distinguir.

Otra cosa es que se implementen sprites por hardware, pero me temo que eso se sale ya por todos los lados de la concepción del ZX-Uno, donde el modo radastaniano no era más que un apaño más o menos sencillo usando los recursos que había.

Avatar de Usuario
Haplo
MSX Turbo R
MSX Turbo R
Mensajes: 278
Registrado: 14 Abr 2014, 22:24
Sistema Favorito: PC
primer_sistema: Spectrum +2
consola_favorita: Sony PlayStation 1
Primera consola: Nintendo NES/Clónica
Ubicación: Ciudad Real
Gracias dadas: 33 veces
Gracias recibidas: 5 veces

Re: ZX-Uno - kit de programación modo Radastaniano

Mensajepor Haplo » 09 Jun 2015, 13:21

Ahí está, es que partiendo de la base de que el modo radastaniano es como un "bypass" de la ula normal, igual se podría hacer la "pirula" que digo sin hacer nada megacomplicado. Ya digo que no estoy puesto en hardware, pero por pedir que no quede :mrgreen:
A ver si McLeod nos puede decir algo sobre este tema.

Avatar de Usuario
scooter
Amiga 1200
Amiga 1200
Mensajes: 1031
Registrado: 17 Jul 2012, 09:25
primer_sistema: C64
Ubicación: Alicante

Re: ZX-Uno - kit de programación modo Radastaniano

Mensajepor scooter » 10 Jun 2015, 19:05

Lo del color transparente significa casi casi hacer sprites por hardware, creo yo.

Avatar de Usuario
mcleod_ideafix
Amiga 2500
Amiga 2500
Mensajes: 5316
Registrado: 06 Oct 2009, 04:12
Sistema Favorito: Spectrum 16Kb/48Kb
primer_sistema: Spectrum 16Kb/48Kb
consola_favorita: Vectrex
Primera consola: TV Games/Pong Clone
Ubicación: Jerez de la Frontera
Gracias dadas: 12 veces
Gracias recibidas: 53 veces
Contactar:

Re: ZX-Uno - kit de programación modo Radastaniano

Mensajepor mcleod_ideafix » 10 Jun 2015, 20:09

Poder se puede, pero no es trivial. Como apunta scooter, manejar un color transparente para sprites implica que el pintado completo del sprite lo haga el hardware.

La otra opción sería implementar una nueva instrucción en el Z80 algo así:
OR (HL),A ; 10 ciclos

Que toma el valor de la posición de memoria apuntada por HL, le hace un OR con lo que haya en A y el resultado lo vuelve a escribir en la posición de memoria apuntada por HL. Es decir, una instrucción que equivaldría a esta secuencia:
OR (HL) ; 7 ciclos
LD (HL),A ; 7 ciclos

De esa forma, defines el color transparente como el color de índice 0 y ya está. Pero como puedes ver, el ahorro no es escandaloso, sólo 4 ciclos de reloj.

En la práctica, y con los recursos que tenemos ahora, creo que se pueden pintar sprites con máscaras con suficiente rapidez sin necesidad de recurrir al pintado por hardware (aunque mole más). Y si quieres más rapidez, siempre puedes implementar una rutina de impresión de sprites compilados.
Recuerda: cada vez que se implementa un sistema clásico en FPGA, Dios mata a un purista

Avatar de Usuario
Haplo
MSX Turbo R
MSX Turbo R
Mensajes: 278
Registrado: 14 Abr 2014, 22:24
Sistema Favorito: PC
primer_sistema: Spectrum +2
consola_favorita: Sony PlayStation 1
Primera consola: Nintendo NES/Clónica
Ubicación: Ciudad Real
Gracias dadas: 33 veces
Gracias recibidas: 5 veces

Re: ZX-Uno - kit de programación modo Radastaniano

Mensajepor Haplo » 10 Jun 2015, 20:43

Vale, ya dije que no tenía ni idea de la complejidad del tema, por poco me empeño en añadirle instrucciones MMX al z80 :mrgreen:

mcleod_ideafix escribió:Y si quieres más rapidez, siempre puedes implementar una rutina de impresión de sprites compilados


No sé exactamente qué significa ese término ¿datos de sprites organizados de cierta manera para optimizar su lectura?

Avatar de Usuario
mcleod_ideafix
Amiga 2500
Amiga 2500
Mensajes: 5316
Registrado: 06 Oct 2009, 04:12
Sistema Favorito: Spectrum 16Kb/48Kb
primer_sistema: Spectrum 16Kb/48Kb
consola_favorita: Vectrex
Primera consola: TV Games/Pong Clone
Ubicación: Jerez de la Frontera
Gracias dadas: 12 veces
Gracias recibidas: 53 veces
Contactar:

Re: ZX-Uno - kit de programación modo Radastaniano

Mensajepor mcleod_ideafix » 10 Jun 2015, 23:20

Haplo escribió:No sé exactamente qué significa ese término ¿datos de sprites organizados de cierta manera para optimizar su lectura?

No: es una técnica para dibujar sprites que consiste en que la rutina que dibuja los sprites, en lugar de dibujarlos, lo que hace es crear una ristra de secuencias de código máquina, por ejemplo del tipo:

Código: Seleccionar todo

LD HL,dirpantalla
LD A,(HL)
OR dato
LD (HL),A


Y así con cada byte que haya que dibujar en pantalla (o bien cualquier otra secuencia más optimizada si procede). Este "sprite compilado" se genera mientras la pantalla está siendo actualizada, con lo que tienes unos 68000 estados para hacerlo para todos los sprites. Luego, cuando has terminado y se inicia el refresco vertical lo que haces es llamar a la rutina que tú mismo has creado, para que ésta pinte los sprites.

Mejor lo ves en esta pequeña demo que hice. Muestra 60 pequeñas bolitas de 2x2 píxeles en pantalla a full frame rate. Mira el código fuente y te harás una mejor idea, espero. Ensambla con PASMO.
http://www.atc.us.es/~rodriguj/demo_sim ... ilados.zip

-- Actualizado 10 Jun 2015, 22:28 --

mcleod_ideafix escribió:Poder se puede, pero no es trivial. Como apunta scooter, manejar un color transparente para sprites implica que el pintado completo del sprite lo haga el hardware.

Hay otra opción. Acabo de acordarme de una cosa que hacen las tarjetas VGA y es el poder enmascarar las escrituras a memoria de pantalla. La idea, aplicada al ZX Spectrum sería la siguiente: tener un puerto de E/S que permita o no el enmascaramiento.

Si no se permite, todas las escrituras al rango de memoria de pantalla funcionan como siempre.

Si se permite, entonces el enmascaramiento funciona de la siguiente forma: el dato en binario a escribir se puede representar como ABCD EFGH donde cada letra es un bit. El mecanismo de máscara comprueba qué grupos de bits son 0000, y los que tengan ese valor no se escriben a memoria, sino que se deja el valor de los cuatro bits que ya hubiera en memoria.

Para implementar esto en hardware sin necesidad de tener que realizar dos operaciones de memoria, se puede hacer usando como backbuffer memoria interna de la FPGA (sólo harían falta 6144 bytes). Cada vez que se haga una escritura, se hace también en ese backbuffer, y cuando haya que leer el valor actual de una posición de memoria para aplicar o no la máscara, se lee de ese backbuffer, que es muy rápido.

Los implementadores de juegos: ¿creeis que merece la pena añadir esto al modo radastaniano? Como está aún en fase de definición, podemos quitar y poner lo que nos dé la gana, y esta es una característica que puede ser completamente ignorada si alguien quiere usar "CPUpower" para su juego. Yo particularmente no le veo mucho beneficio, pero tampoco soy el más indicado para opinar en este aspecto.
Recuerda: cada vez que se implementa un sistema clásico en FPGA, Dios mata a un purista

Avatar de Usuario
scooter
Amiga 1200
Amiga 1200
Mensajes: 1031
Registrado: 17 Jul 2012, 09:25
primer_sistema: C64
Ubicación: Alicante

Re: ZX-Uno - kit de programación modo Radastaniano

Mensajepor scooter » 10 Jun 2015, 23:52

Se me ocurre añadir otro modo (que hay pocos) en el cual se superponga el contenido de la pantalla shadow por hardware; es decir , si no hay nada se ve la pantalla 0 pero si hay algo en la 1 lo que se ve es la 1.
Claro que me imagino que "esta feliz idea" conllevaría el doble de contención, o no, no lo se.
Esto vadría para cualquier modo gráfico.

Avatar de Usuario
mcleod_ideafix
Amiga 2500
Amiga 2500
Mensajes: 5316
Registrado: 06 Oct 2009, 04:12
Sistema Favorito: Spectrum 16Kb/48Kb
primer_sistema: Spectrum 16Kb/48Kb
consola_favorita: Vectrex
Primera consola: TV Games/Pong Clone
Ubicación: Jerez de la Frontera
Gracias dadas: 12 veces
Gracias recibidas: 53 veces
Contactar:

Re: ZX-Uno - kit de programación modo Radastaniano

Mensajepor mcleod_ideafix » 11 Jun 2015, 00:03

scooter escribió:Se me ocurre añadir otro modo (que hay pocos) en el cual se superponga el contenido de la pantalla shadow por hardware; es decir , si no hay nada se ve la pantalla 0 pero si hay algo en la 1 lo que se ve es la 1.
Claro que me imagino que "esta feliz idea" conllevaría el doble de contención, o no, no lo se.
Esto vadría para cualquier modo gráfico.

Demasiada contención. Para leer uno de los bancos se necesitan 6 de cada 8 ciclos de CPU. Leer los dos bancos requeriría 10 o 12 ciclos de CPU por cada 8 ciclos de CPU, así que, simplemente no hay tiempo suficiente. En el modo radastaniano, aunque no hay contención, hay una restricción similar en cuanto al tiempo disponible.
Recuerda: cada vez que se implementa un sistema clásico en FPGA, Dios mata a un purista


Volver a “Sinclair/Spectrum”

¿Quién está conectado?

Usuarios navegando por este Foro: No hay usuarios registrados visitando el Foro y 12 invitados