Proposición de gráfica externa para ZX Spectrum

Sinclair QL, ZX81, +2, +3, 128K ...
ZX-81
Commodore 128
Commodore 128
Mensajes: 102
Registrado: 04 Ene 2013, 16:43
Sistema Favorito: Spectrum +2
primer_sistema: ZX81
consola_favorita: Nintendo DS/3DS
Primera consola: Sega Genesis/Megadrive
Ubicación: La orilla del mar Mediterráneo
Gracias dadas: 11 veces
Gracias recibidas: 19 veces
Contactar:

Re: Proposición de gráfica externa para ZX Spectrum

Mensajepor ZX-81 » 02 May 2014, 11:48

mcleod_ideafix escribió:Dado que ya no estamos hablando de una tarjeta que se le pincha a un Spectrum, sino de un modo nativo del ZX-Uno, ya no tiene sentido hablar de conectar el ZX-Uno a nada. El ZX-Uno ES el ordenador. El ZX-Uno es un ordenador de 128K que además implementa los modos nativos Timex. Si JSpeccy no emula Timex, no tienes que preocuparte para nada del puerto $FF. Simplemente no estará implementado. Dudo mucho que Radastan necesite siquiera más de una página de video para sus juegos, mucho menos cuatro.


Juas!, como no había seguido el hilo desde el principio, y te ví en la RM con media docena de Spectrums con las tripillas al aire, pensaba que era algo que se pinchaba al Spectrum y no una alternativa a la máquina física,que es lo que realmente es. Lo que pasa es que esto cambia bastante también la manera de ponerlo en el emulador porque, más que un modo ZX-Uno, estaríamos hablando de una máquina ZX-Uno, con todo lo que supone: añadir entradas en los menús correspondientes, actualización del XML de configuración, soporte para grabación y carga de snapshots en SZX (en los otros ni pensarlo, y si alguien cree que es fácil añadir cosas al formato SZX que pruebe a hablar con el autor de Spectaculator, que es el "dueño" del formato). Hacerlo bien, tiene su miga.

mcleod_ideafix escribió:
ZX-81 escribió:[*]Cuando se dice que el Z80 no tiene contención se refiere tanto a la memoria como a la I/O, incluido el puerto de ULAplus que normalmente la tiene y que en este caso tampoco la tendría.

Exacto. Nada de contención. Ni mijita. A ningún puerto. A ninguna zona de memoria.


Huelga decir que tampoco tiene bus flotante y que cualquier lectura de puerto que no exista da como resultado 0xff.

mcleod_ideafix escribió:Por supuesto, cuando termino una línea de exploración, la siguiente se pinta usando exactamente la misma información, con lo que sí, es posible cambiar la paleta o el contenido de esa línea y tendrías más resolución vertical.


Exacto, de modo que no se pueden dibujar los 4 pixeles a piñon fijo, sino dos a dos para cada línea de scan.

mcleod_ideafix escribió:
ZX-81 escribió:1.- que los colores de las líneas pares salgan de la paleta 0 y las impares de la 1 (posibilidad de doble resolución de color, por llamarlo de algún modo), o bien
2.- que los colores salgan de la paleta seleccionada vía un out a algún registro de ULAplus. Con un solo OUT entre líneas podemos sacar los colores de cualquiera de las 4 paletas y conseguir efectos de color más chulos.
[/list]

Este modo se ha pensado fundamentalmente para crear juegos sin attribute-clash y que tengan, digamos, un look nuevo en el Spectrum, sin gastar CPU. Se pueden realizar virguerías del estilo que comentas, pero precisamente propuse a Radastan cosas como un modo de 128x192 y lo rechazó, precisamente porque ya no sería algo "simple" y además ocuparía más memoria. Cambiar el hardware para que en cada línea use direcciones diferentes y así tener una resolución real de 128x192 es trivialísimo. Las cosas que propones, en hardware, no son tan triviales, ya que cada multiplexor añadido en la ruta de datos "cuesta" espacio en la FPGA y se come tiempo de propagación de los datos.


No es necesario decir que solo yo solo puedo proponer ideas, con independencia de que luego sean realizables en HW, del que no entiendo casi nada en absoluto. Pero la propuesta de coger la paleta del contenido de un registro, da una flexibilidad tremenda. Si cuesta mucho o poco de hacer solo lo sabes tú... ;)
Todo espacio de dimensión finita distinta de cero con producto interno tiene una base ortonormal. Tiene sentido, cuando no piensas sobre ello.
Profesor de Matemáticas U.C. Berkeley

Empieza a jugar sin tener que compilar: JSpeccy
Emulador bare-metal para la Raspberry PI 2/3: ZXBaremulator

Avatar de Usuario
mcleod_ideafix
Amiga 2500
Amiga 2500
Mensajes: 5310
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: 46 veces
Contactar:

Re: Proposición de gráfica externa para ZX Spectrum

Mensajepor mcleod_ideafix » 02 May 2014, 12:29

ZX-81 escribió:Huelga decir que tampoco tiene bus flotante y que cualquier lectura de puerto que no exista da como resultado 0xff.

Sí, sí que tiene bus flotante. Esa característica es indpendiente de que exista o no contención. De hecho el bus flotante existe precisamente porque lees a un puerto no contenido mientras la ULA va a lo suyo. La verdad es que no he hecho pruebas en este sentido en el modo radastaniano, más que nada porque siempre he pensado que este modo está precisamente para no tener que andar con trucos en la CPU para tener multicolor: ya te lo dan hecho :D
Recuerda: cada vez que se implementa un sistema clásico en FPGA, Dios mata a un purista

Avatar de Usuario
Hark0
Amiga 1200
Amiga 1200
Mensajes: 1695
Registrado: 11 Jul 2012, 23:44
Sistema Favorito: Spectrum 16Kb/48Kb
primer_sistema: Spectrum 16Kb/48Kb
consola_favorita: (Otro)
Primera consola: (Otro)
Ubicación: Cornellà de Llobregat - Barcelona
Contactar:

Re: Proposición de gráfica externa para ZX Spectrum

Mensajepor Hark0 » 02 May 2014, 12:35

radastan escribió:
Hark0 escribió:olvida la pregunta, es un out... el asm para el border me vale


Tranquilo que habrá soporte nativo en mis rutinas, de echo se llamará motorzxuno.h
La semana que viene me pongo a ello, que quiero tomarme lo que queda de semana de descanso (ahora vienen las risas... porque no paro de prepararlo de todas formas).



Jejejeje... creo que me estabas leyendo la mente... :-P


De momento estoy escribiendo mi bucle mainloop del juego bien sincronizado con los wait_cpu(); que quiero que este todo bien ajustadete...
http://www.zxuno.com
ZX-Uno · Clon de ordenador ZX Spectrum basado en FPGA.

Avatar de Usuario
mcleod_ideafix
Amiga 2500
Amiga 2500
Mensajes: 5310
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: 46 veces
Contactar:

Re: Proposición de gráfica externa para ZX Spectrum

Mensajepor mcleod_ideafix » 11 May 2014, 04:48

Yo como hacer gráficos para juegos no se me da nada bien, he optado por escribir de algo en lo que ya tengo experiencia, y que me sirve de demo y testeo de velocidad al mismo tiempo: un reproductor de videos para el modo radastaniano :D

Imagen

Pues la idea es escribir un programa que se ejecutará como comando de ESXDOS (los comandos que comienzan por un puntito), y que leerá el video a reproducir desde un fichero guardado en la tarjeta SD, en un directorio cualquiera.
Para ello he pedido acceso a la API de ESXDOS 0.8.5 . Esta API aún no se ha publicado porque está pendiente de varios cambios. Su autor, Miguel Ângelo Guerreiro me ha pedido que no distribuya la documentación o la API de ESXDOS para evitar entre otras cosas que lo "no oficial" tenga que convertirse por huevos en "oficial" si empieza a escribirse software a mansalva usando esta API de prueba. También me ha pedido que especifique que esta utilidad sólo podrá funcionar con ESXDOS 0.8.x

Pues bien, explicado este punto, me puse manos a la obra. El resultado lo podeis obtener del repositorio, carpeta "modo_radastan". Vereis una nueva carpeta: "videos_radastanianos".

En esa carpeta hay varias cosillas, pero las que interesan para un vistazo rápido son: el fichero PLAYRMOV que debereis copiar al directorio BIN de la tarjeta SD que useis con ESXDOS, y luego los videos, que son ficheros con la extensión .RDM (RaDastan Movie). Para que no ocupen demasiado, los he comprimido en un ZIP. Los descomprimis y los poneis en la tarjeta SD, donde querais.

Para ver cualquiera de los videos, os vais desde ESXDOS al directorio donde está el video y haceis: .playrmov nombre_del_video.rdm (más detalles sobre la ejecución a continuación)

Ahora, si alguien quiere contribuir con más videos, éste es el proceso que he seguido para hacerlos. Uso Windows 7, y los programas VirtualDub e IrfanView (que funcionan con practicamente cualquier Windows, creo que desde el 98 para adelante). Ambos son gratuitos y harto conocidos (eso creo).

PASO 1.
Cargo la película con Virtual Dub. Voy a Video -> Filters y escojo el filtro "resize". Con él, pongo como resolución de salida 128x96. Si vuestro video no es formato 4:3, teneis dos opciones: o lo escalais entero y luego añadis con el mismo filtro las bandas negras arriba y abajo, o bien escalais a 96 pixeles de alto y lo que dé de sí de ancho, y luego usais el filtro "none" para recortar el video y quedaros con la parte central, para acabar a 128x96.
Imagen

PASO 2.
Desde el menú File, uso la opción de grabar la película como una secuencia de imágenes. La idea es conseguir un montón de ficheros en formato BMP
Imagen

PASO 3.
Así que me aseguro de usar este formato, BMP, escoger un nombre base (que después usaremos como prefijo en una utilidad que comentaré más adelante) y en el número mínimo de dígitos, escoger 5. También escoger un directorio vacío, donde se grabarán todos los ficheros. Se grabará un fichero BMP por cada fotograma del video, así que si es un video muy largo, podeis encontraros con decenas de miles de ficheros.
Imagen

PASO 4.
Mientras se realiza la grabación, VirtualDub te muestra el progreso de la misma...
Imagen

PASO 5.
El resultado debe ser una carpeta llena de ficheros con el mismo nombre y a continuacion 00001, 00002, etc.
Imagen

PASO 6.
Abro uno cualquiera de los ficheros (el primero, por ejemplo) con Irfanview, y me voy al menú File, opción batch conversion / rename
Imagen

PASO 7.
Allí veo dos ventanas: una con mis ficheros BMP (si no los ves, asegurarse de que en "Tipo" se ha seleccionado BMP). Debajo una ventana vacía donde aparecerán los ficheros convertidos. Vamos a usar Irfanviwe para convertir todos nuestos fotogramas a un formato muy parecido al del ZX-Uno modo radastaniano: BMPs con paleta de 16 colores. Para añadir todos los BMPs, pulsar el botón Add All.
Imagen

PASO 8.
El resultado es que los ficheros aparecen en orden en la ventana de abajo
Imagen

PASO 9.
Ahora pulsamos el botón Advanced y accedemos a esta otra ventana. Desde aquí se puede modificar cada uno de los ficheros a medida que se va convirtiendo. En nuestro caso la única conversión que vamos a hacer es especificar que los ficheros serán de 16 colores con paleta. Lo de usar la opción de dithering con Floyd-Steimberg queda a juicio de cada uno. En los dos videos que he puesto en el repositorio no lo he usado.
Imagen

PASO 10.
De vuelta en la ventana de conversión masiva, elegid un "Output directory" donde se almacenarán estos nuevos BMPs a 16 colores. Una vez hecho esto, pulsar en Start Batch y comenzarán a generarse a velocidad de vértigo
Imagen

PASO 11.
Cuando termine, id al directorio donde se han creado estos BMPs y comprobad que tienen la misma longitud, 6262 bytes.
Imagen

PASO 12.
Copiad el fichero makevideoradas.exe del repositorio al directorio donde tengais estos BMPs de 16 colores. Desde el símbolo del sistema, tecleais:

Código: Seleccionar todo

makevideoradas prefijo

Donde "prefijo" es el usado en el PASO 3, y que no es más que el nombre con el que comienzan todos los ficheros. Opcionalmente se puede establecer un paso, para que no procese todos los ficheros, sino que lo haga de 2 en 2, de 3 en 3, etc. Si no se dice nada, los procesa todos.
Imagen

PASO 13.
El resultado es un fichero con el prefijo como nombre, y la extensión RDM. Habitualmente ocupará varios megas. No pasa nada. ESXDOS permite trabajar con ficheros de hasta 2GB.
Imagen

Copiamos nuestro RDM a la tarjeta SD, el programa PLAYRMOV a la carpeta BIN de la tarjeta SD también, insertamos dicha tarjeta en el ZX-Uno y nos aseguramos de arrancar con soporte de DIVMMC. La ROM puede ser la del +3, la del 48K o la SE Basic IV de Andrew Owen.

En /BIN/ debe estar PLAYRMOV
Imagen

Los videos, pues por ejemplo en un directorio "Videos", si quereis:
Imagen

Desde el directorio videos, emitimos la orden .playrmov javi.rdm, y ya podemos disfrutar del video. Aquí dejo unas cuántas tomas de "javi.rdm". Probablemente ya habreis averiguado qué es :D

Imagen

Imagen

Imagen

Imagen
Recuerda: cada vez que se implementa un sistema clásico en FPGA, Dios mata a un purista

Avatar de Usuario
Setne
Amstrad PCW 8256
Amstrad PCW 8256
Mensajes: 150
Registrado: 28 Dic 2013, 15:40
Sistema Favorito: Spectrum 16Kb/48Kb
primer_sistema: Spectrum 16Kb/48Kb
Primera consola: Sony PlayStation 3
Ubicación: Logroño... Vitoria, Vitoria... Logroño.
Gracias dadas: 1 vez

Re: Proposición de gráfica externa para ZX Spectrum

Mensajepor Setne » 11 May 2014, 10:19

¡Está genial, vaya pasada! En la RetroMadrid ya me pareció una chulada la intro de Mazinger-Z, pero esto ya tiene una pinta tremenda :shock:

Avatar de Usuario
mcleod_ideafix
Amiga 2500
Amiga 2500
Mensajes: 5310
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: 46 veces
Contactar:

Re: Proposición de gráfica externa para ZX Spectrum

Mensajepor mcleod_ideafix » 11 May 2014, 11:17

Setne escribió:¡Está genial, vaya pasada! En la RetroMadrid ya me pareció una chulada la intro de Mazinger-Z, pero esto ya tiene una pinta tremenda :shock:

¡Huy! Pues la demo del Mazinger tiene ya tiempo. La escribí hace ahora casi 5 años (aunque la fecha de subida al Youtube es de más tarde), cuando monté mi primera placa ZXMMC...




Decir que como ese programa usa la API del +3DOS, funcionará en cualquier +2E/+3E, con cualquier interface compatible con el proyecto +3E. No te hace falta que sea ZX-Uno, aunque claro, con el ZX-Uno tienes más "juego" ;)

Los cortos de Javi y Luci también se usaron para mi primer experimento con video, antes del +3E, mucho antes del ZX-Uno, cuando todo lo que tenía era un DivIDE. El player por tanto era exclusivo para el DivIDE, aunque eso sí: mucho más rápido al poder leer directamente sectores y no pasar por un sistema de ficheros...

http://www.zxprojects.com/index.php/mov ... x-spectrum
Recuerda: cada vez que se implementa un sistema clásico en FPGA, Dios mata a un purista

Avatar de Usuario
Setne
Amstrad PCW 8256
Amstrad PCW 8256
Mensajes: 150
Registrado: 28 Dic 2013, 15:40
Sistema Favorito: Spectrum 16Kb/48Kb
primer_sistema: Spectrum 16Kb/48Kb
Primera consola: Sony PlayStation 3
Ubicación: Logroño... Vitoria, Vitoria... Logroño.
Gracias dadas: 1 vez

Re: Proposición de gráfica externa para ZX Spectrum

Mensajepor Setne » 11 May 2014, 16:14

mcleod_ideafix escribió:¡Huy! Pues la demo del Mazinger tiene ya tiempo. La escribí hace ahora casi 5 años (aunque la fecha de subida al Youtube es de más tarde), cuando monté mi primera placa ZXMMC...




Decir que como ese programa usa la API del +3DOS, funcionará en cualquier +2E/+3E, con cualquier interface compatible con el proyecto +3E. No te hace falta que sea ZX-Uno, aunque claro, con el ZX-Uno tienes más "juego" ;)

Los cortos de Javi y Luci también se usaron para mi primer experimento con video, antes del +3E, mucho antes del ZX-Uno, cuando todo lo que tenía era un DivIDE. El player por tanto era exclusivo para el DivIDE, aunque eso sí: mucho más rápido al poder leer directamente sectores y no pasar por un sistema de ficheros...

http://www.zxprojects.com/index.php/mov ... x-spectrum


Pensaba que era algo del propio ZX-Uno, no tenía ni idea de esto... ¡las cosas nueva (aunque ya tengan sus años) qué nos hacéis descubrir! :mrgreen:

Al menos a mí, claro :roll:

Avatar de Usuario
mcleod_ideafix
Amiga 2500
Amiga 2500
Mensajes: 5310
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: 46 veces
Contactar:

Re: Proposición de gráfica externa para ZX Spectrum

Mensajepor mcleod_ideafix » 12 May 2014, 03:11

Setne escribió:Pensaba que era algo del propio ZX-Uno, no tenía ni idea de esto... ¡las cosas nueva (aunque ya tengan sus años) qué nos hacéis descubrir! :mrgreen:

Al menos a mí, claro :roll:


Lo del reproductor con el nuevo modo de video "radastaniano", por supuesto que es nuevo y propio del ZX-Uno. Lo demás, ya existía ;) Es más, existe incluso un estándar de video, llamado DIVIDEo que soporta videos con sonido, pero basa su velocidad en leer directamente y a bajo nivel del sistema de almacenamiento, con lo que no funciona con nada que no sea un DIVIDE pata negra (no funciona por ejemplo con DIVMMC, y por ende, no funciona con ZX-Uno)

Por cierto, aprovecho para comentar que después de un apunte por parte de Miguel Ângelo, he eliminado la necesidad de tener que ajustar el stack con el comando CLEAR. He mocdificado el post anterior con la guía de uso eliminando esa parte ;) En el repositorio están el fuente y el binario ya actualizados.
Recuerda: cada vez que se implementa un sistema clásico en FPGA, Dios mata a un purista

Avatar de Usuario
antoniovillena
Amiga 1200
Amiga 1200
Mensajes: 2013
Registrado: 16 Abr 2012, 21:22
Gracias recibidas: 7 veces

Re: Proposición de gráfica externa para ZX Spectrum

Mensajepor antoniovillena » 12 May 2014, 20:30

He probado los 2 vídeos y están chulísimos. Haciendo cuentas y suponiendo que ESXDOS lee de la SD mediante INIs desenrollados, siendo la transferencia máxima de 1 byte cada 16 ciclos, me sale que un frame tarda como mínimo 98304 ciclos. Esto quiere decir que si se optimiza a tope con acceso directo a SD se pueden conseguir holgadamente 25fps, sobrando el 60% del segundo frame (un montón).

Más que suficiente para el overhead que pueda tener el sistema de ficheros (de vez en cuando tiene que leer alguna entrada en la FAT) y para cargar la paleta. He leído el código fuente y es super sencillo, hay que ver lo que puede dar de sí el DivMMC con el modo radastaniano. Si te planteas mejorarlo aquí tienes algunas sujerencias (aunque supongo que ya te has dado cuenta).

  • El borde parpadea mucho y es molesto. Supongo que es por efecto colateral de actualizar la paleta, se podría evitar dejando el negro fijo (que coincida con el borde) y recalculando los otros 15 colores.
  • En el video de los gatos se nota mucho que la paleta cambia en cada frame, y se ven cosas feas como degradados variables cuando las condiciones de luz cambian. Esto se podría arreglar poniendo un tope máximo, por ejemplo 5 segundos, en los cuales si no hay ningún cambio de escena la paleta no cambia.

Avatar de Usuario
mcleod_ideafix
Amiga 2500
Amiga 2500
Mensajes: 5310
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: 46 veces
Contactar:

Re: Proposición de gráfica externa para ZX Spectrum

Mensajepor mcleod_ideafix » 12 May 2014, 21:44

antoniovillena escribió:Si te planteas mejorarlo aquí tienes algunas sujerencias (aunque supongo que ya te has dado cuenta).

Bueno, es sólamente un "proof of concept". No pensaba hacer nada especial para acelerarlo, al menos no de momento. Con lo que me cuente Miguel Ângelo, podré usar acceso directo y esas cosas. Una versión chula del programa es aquella que muestre una imagen en modo radastaniano pero conserve las dos últimas líneas en modo normal, para mostrar subtítulos (cambiando el modo de video "on the fly")

antoniovillena escribió:[*]El borde parpadea mucho y es molesto. Supongo que es por efecto colateral de actualizar la paleta, se podría evitar dejando el negro fijo (que coincida con el borde) y recalculando los otros 15 colores.

En el modo radastaniano el color del borde es uno de los colores de las entradas 0 a 7. Hacer esto que comentas significa escribir algún programa que sea el que haga la traslación a la paleta de 16 colores. Yo no he usado programas "custom", sino el propio Irfanview. No me quería complicar la vida. Lo que hago es que durante la reproducción, busco de los 8 primeros colores el más oscuro, y ese es el que pongo como borde. Cutre, pero hace el avío.

antoniovillena escribió:[*]En el video de los gatos se nota mucho que la paleta cambia en cada frame, y se ven cosas feas como degradados variables cuando las condiciones de luz cambian. Esto se podría arreglar poniendo un tope máximo, por ejemplo 5 segundos, en los cuales si no hay ningún cambio de escena la paleta no cambia.[/list]

Son 16 colores.... no más.... los degradados se van a ver exageraos sí o sí. Si hubiera usado dithering en la traslación a 16 colores igual no hubieras notado ese efecto en el degradado.

Como ves, la API para leer ficheros desde ESXDOS es muy muy sencilla. Quizás te convenga escribir alguna utilidad que permita actualizar BIOS, core o ROMs que corra desde ESXDOS. No tiene por qué ser un comando de ESXDOS, puede ser un programa normal y corriente (un TAP, vamos) que use la API de ESXDOS para leer y escribir en ficheros FAT.
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 3 invitados