Port del AGD de Z-80 a 6809

jltursan
Mensajes: 5619
Registrado: 20 Sep 2011 13:59
Ubicación: Madrid
Agradecido : 990 veces
Agradecimiento recibido: 2040 veces
Contactar:

Re: Port del AGD de Z-80 a 6809

Mensajepor jltursan » 16 Nov 2018 17:42

Último mensaje de la página anterior:

Pues es verdad que te lo he comentado un par de veces y por ahí andan todavía. Últimamente tengo poco tiempo y sólo esporádicamente me conecto y hago cosillas. Miro a ver si consigo desatrancar el tema y hacerte el envío.

Me muero por ver una versión "casi" definitiva :-)

Avatar de Usuario
pser1
Mensajes: 4094
Registrado: 08 Dic 2012 18:34
Agradecido : 1352 veces
Agradecimiento recibido: 1118 veces

Re: Port del AGD de Z-80 a 6809

Mensajepor pser1 » 16 Nov 2018 21:51

jltursan escribió:Pues es verdad que te lo he comentado un par de veces y por ahí andan todavía. Últimamente tengo poco tiempo y sólo esporádicamente me conecto y hago cosillas. Miro a ver si consigo desatrancar el tema y hacerte el envío.
Me muero por ver una versión "casi" definitiva :-)

Hola José Luis,
con tus gráficos será la *definitiva* ya que los posibles retoques que le haga al motor no van a afectarle puesto que estamos probando
funciones no utilizadas en Foggy ...
saludos
pere

Avatar de Usuario
pser1
Mensajes: 4094
Registrado: 08 Dic 2012 18:34
Agradecido : 1352 veces
Agradecimiento recibido: 1118 veces

Re: Port del AGD de Z-80 a 6809

Mensajepor pser1 » 14 Dic 2018 16:34

Hola,
ya han pasado casi seis meses desde que empecé a convertir rutinas del motor AGD para ZX-Spectrum, cosa que arrancó a finales de Junio.
Ahora que todo el código ZX-Spectrum ha sido convertido, a excepción de las rutinas dedicadas al sonido (chip AY), creo que ya es hora de
ir pensando en cerrar este proyecto!
Con la ayuda de Kees van Oss empezamos la tediosa tarea de pruebas y una vez solucionados los errores encontrados, nos decidimos a añadir
algunas nuevas funcionalidades que se están añadiendo en la actualidad al estandar AGD.
Por ejemplo además de los sprites 16x16 ahora podemos manejar los de 16x24

Como los sprites se mueven dos pixels a la vez, implica que debe haber cuatro 'imágenes' desplazadas desde la izquierda 0,2,4,6 pixels
para mostrar una secuencia competa.
Por ahora, AGD lo solventa creando cuatro bloques de datos para cada sprite, uno para caga imágen. Estas imágenes adicionales las genera el compilador de forma que el fichero ASM final contiene 128 bytes en lugar de 32 por sprite.
Existe un desarrollo muy ingenioso que, usando cuatro tablas de solo 256 bytes, es capaz de pintar las cuatro imágenes partiendo
de solamente la principal. Ello implica mas código y las tablas en si mismo, pero como muchos juegos usan
muchos sprites, el resultado global es muy positivo.
De este modo, algunos juegos que NO cabían en las 32K bajas, ahora SI caben!
Posteriormente, estas tablas las he enviado a la parte alta de RAM, liberando otros 1024 bytes de forma que ahora todos los juegos
funcionan en CoCo-Dragon. Además, el código tiene varios indicadores de compilación condicional, que permiten evitar partes
que no hacen falta para un juego.
*** Solo recordaros que los juegos AGD *requieren* máquinas con 64K de RAM (obligatoriamente) ***

Bien, el 'motor' ha sido la primera parte que debía ser convertida. Contiene las funciones que se ofrecen al creador de juegos que puede
llamarlas desde el script que genera la aplicación AGD en el Spectrum.
A continuación, con Kees nos dedicamos a modificar el compilador que lee este script y genera un fichero ASM con código 6809 y los datos del programa. Es un programa en C que se ejecuta bajo Windows y se compila bajo MinGW
La suite se completa con otra herramienta importante, el conversor que, también es un programa en C que lee un fichero .sna de Spectrum
(creado con AGD) y es capaz de extraer un fichero de scripts y datos para su posterior compilacion.

Con el conversor, el compilador y el motor podríamos convertir unos 150 juegos aprox.
Para hacernos la vida mas fácil, he creado una colección de ficheros .bat que permiten probar ficheros AGD en XRoar emulando CoCo o Dragon,
crear los discos (VDK, DSK) e incluso crear una carpeta para cada juego con todos los ficheros intermedios utilizados
puede hacerse de forma individual o masiva.

Para todo ello, estamos utilizando algunas heramientas de otros programadores (listados alfabéticamente)
- ASM6809 de Ciaran Anscomb (Sixxie)
- DragonDos de Rolf Michelsen
- ImgTool de MAME/MESS
- XRoar de Ciaran Anscomb (Sixxie)

AGD es el acrónimo de Arcade Game Designer y fué creado en 2008 por Jonathan Cauldwell

Que esperamos ahora de todo esto?
Bien, la guinda en el pastel sería que la aplicación WinAGD sea capaz de dar soporte a los esquemas de colores del 6847 (Pmode3 y Pmode 4).
Este es un punto importante para cualquiera que desee hacer una versión en colores de cualquier juego que vayamos
liberando a partir de ahora ...
Y mas importante, nos permitiría crear juegos desde cero!
La imaginación al poder!!

saludos
pere

Ps Podéis ver mas datos sobre el proyecto AGD en estas páginas
https://jonathan-cauldwell.itch.io/arcade-game-designer
http://www.worldofspectrum.org/infoseek ... id=0020176

jltursan
Mensajes: 5619
Registrado: 20 Sep 2011 13:59
Ubicación: Madrid
Agradecido : 990 veces
Agradecimiento recibido: 2040 veces
Contactar:

Re: Port del AGD de Z-80 a 6809

Mensajepor jltursan » 14 Dic 2018 22:17

Parece buena idea la de generar al vuelo los fotogramas del sprite; pero, ¿se pierde mucho más tiempo o es muy asumible?

Avatar de Usuario
pser1
Mensajes: 4094
Registrado: 08 Dic 2012 18:34
Agradecido : 1352 veces
Agradecimiento recibido: 1118 veces

Re: Port del AGD de Z-80 a 6809

Mensajepor pser1 » 14 Dic 2018 22:56

te diria que pràcticamente no se nota. Solamente es un acceso indexado a una tabla de 256 bytes alineada a 256 con lo que el acceso es realmente simple ...
saludos

Avatar de Usuario
explorer
Mensajes: 695
Registrado: 10 Ene 2016 18:43
Ubicación: Valladolid, España
Agradecido : 24 veces
Agradecimiento recibido: 680 veces
Contactar:

Re: Port del AGD de Z-80 a 6809

Mensajepor explorer » 20 Ene 2023 19:55

pser1 escribió:Como los sprites se mueven dos pixels a la vez, implica que debe haber cuatro 'imágenes' desplazadas desde la izquierda 0,2,4,6 pixels
para mostrar una secuencia competa.

Por ahora, AGD lo solventa creando cuatro bloques de datos para cada sprite, uno para caga imágen. Estas imágenes adicionales las genera el compilador de forma que el fichero ASM final contiene 128 bytes en lugar de 32 por sprite.

Existe un desarrollo muy ingenioso que, usando cuatro tablas de solo 256 bytes, es capaz de pintar las cuatro imágenes partiendo
de solamente la principal. Ello implica mas código y las tablas en si mismo, pero como muchos juegos usan
muchos sprites, el resultado global es muy positivo.

Hola, Pere.

¿Puedes darme un enlace donde se comente el funcionamiento de esas tablas?

Gracias.

Avatar de Usuario
ron
Mensajes: 21856
Registrado: 28 Oct 2010 14:20
Ubicación: retrocrypta
Agradecido : 3862 veces
Agradecimiento recibido: 4754 veces

Re: Port del AGD de Z-80 a 6809

Mensajepor ron » 20 Ene 2023 23:17

Gracias Pere. Tu trabajo es una pasada, eternamente agradecidos

Avatar de Usuario
pser1
Mensajes: 4094
Registrado: 08 Dic 2012 18:34
Agradecido : 1352 veces
Agradecimiento recibido: 1118 veces

Re: Port del AGD de Z-80 a 6809

Mensajepor pser1 » 22 Ene 2023 11:43

explorer escribió:
pser1 escribió:Como los sprites se mueven dos pixels a la vez, implica que debe haber cuatro 'imágenes' desplazadas desde la izquierda 0,2,4,6 pixels
para mostrar una secuencia competa.

Por ahora, AGD lo solventa creando cuatro bloques de datos para cada sprite, uno para caga imágen. Estas imágenes adicionales las genera el compilador de forma que el fichero ASM final contiene 128 bytes en lugar de 32 por sprite.

Existe un desarrollo muy ingenioso que, usando cuatro tablas de solo 256 bytes, es capaz de pintar las cuatro imágenes partiendo
de solamente la principal. Ello implica mas código y las tablas en si mismo, pero como muchos juegos usan
muchos sprites, el resultado global es muy positivo.

Hola, Pere.

¿Puedes darme un enlace donde se comente el funcionamiento de esas tablas?

Gracias.

==========================================================================================================
Hola,
no hay información en ninguna parte, que yo sepa ...
Es algo que añadimos en su momento al motor convertido AGD, creo que con Kees van Oss, cada uno para su máquina
No es muy complicado, básicamente existen cuatro tablas que se cargan al iniciar el juego , cada una de ellas contienen 256 bytes
y se cargan alineadas a direcciones múltiplos de 256 o sea que el byte bajo sea cero.
Cada tabla tiene por tanto 256 entradas de consulta. Cada byte en ellas es el valor del 'offset' desplazado 0,2,4 o 6 bits
De esta forma la entrada con valor 3 en la tabla NO desplazada, que corresponde al offset 4 tendrá
en shift0 un 03 --- 00000011
en shift1 un 192 --- 11000000
en shift2 un 48 --- 00110000
en shift3 un 12 --- 00001100
Los desplazamientos se realizan de forma circular, es decir los dos bits que salen del octeto por la derecha entran de nuevo
por la izquierda.
Por supuesto el motor que los utiliza debe saber a cual de las tablas debe llamar según el desplazamiento deseado.
Basta con acceder a la tabla correcta con cada byte que exista en la única versión del sprite que estamos procesando y la tabla
nos devuelve el valor desplazado 0-2-4-6 píxels con un solo acceso! Salvas espacio de memoria en la definición de los sprites
a costa de 4x256 -> 1Kb por lo que solamente es 'rentable' en juegos que manejen muchos sprites.
Por si te puede ser útil, adjunto un zip que contiene un binario con las cuatro tablas y un fichero 'fuente' en ensamblador con las
definiciones de las cuatro tablas, así podrás ver mejor que valores se han generado en cada desplazamiento doble (2 píxels-bits)
Cualquier duda que tengas al respecto, podemos continuar en este mismo hilo ...
saludos
pere
SHIFTED.ZIP
(2.97 KiB) Descargado 28 veces

Avatar de Usuario
explorer
Mensajes: 695
Registrado: 10 Ene 2016 18:43
Ubicación: Valladolid, España
Agradecido : 24 veces
Agradecimiento recibido: 680 veces
Contactar:

Re: Port del AGD de Z-80 a 6809

Mensajepor explorer » 22 Ene 2023 23:43

pser1 escribió:No es muy complicado, básicamente existen cuatro tablas que se cargan al iniciar el juego , cada una de ellas contienen 256 bytes
y se cargan alineadas a direcciones múltiplos de 256 o sea que el byte bajo sea cero.
Cada tabla tiene por tanto 256 entradas de consulta. Cada byte en ellas es el valor del 'offset' desplazado 0,2,4 o 6 bits
De esta forma la entrada con valor 3 en la tabla NO desplazada, que corresponde al offset 4 tendrá
en shift0 un 03 --- 00000011
en shift1 un 192 --- 11000000
en shift2 un 48 --- 00110000
en shift3 un 12 --- 00001100
Los desplazamientos se realizan de forma circular, es decir los dos bits que salen del octeto por la derecha entran de nuevo
por la izquierda.
Por supuesto el motor que los utiliza debe saber a cual de las tablas debe llamar según el desplazamiento deseado.
Basta con acceder a la tabla correcta con cada byte que exista en la única versión del sprite que estamos procesando y la tabla
nos devuelve el valor desplazado 0-2-4-6 píxels con un solo acceso! Salvas espacio de memoria en la definición de los sprites
a costa de 4x256 -> 1Kb por lo que solamente es 'rentable' en juegos que manejen muchos sprites.
Por si te puede ser útil, adjunto un zip que contiene un binario con las cuatro tablas y un fichero 'fuente' en ensamblador con las
definiciones de las cuatro tablas, así podrás ver mejor que valores se han generado en cada desplazamiento doble (2 píxels-bits)

Entonces, en el caso de querer pintar $0F (0000 1111), desplazado 1 vez, sería realizar una serie de operaciones con máscaras, ¿verdad?

$0F desplazado una vez es $C3 (1100 0011).

Entonces, necesito pintar 0000 0011 en un byte, y 1100 0000 en el siguiente, para mezclarlo más tarde con el siguiente byte.

Y de esta manera vamos creando la imagen del sprite, en memoria, rotado 4 veces.

Y luego viene el proceso de pintado en memoria de vídeo. ¿Es así?

Avatar de Usuario
pser1
Mensajes: 4094
Registrado: 08 Dic 2012 18:34
Agradecido : 1352 veces
Agradecimiento recibido: 1118 veces

Re: Port del AGD de Z-80 a 6809

Mensajepor pser1 » 23 Ene 2023 15:32

explorer escribió:Entonces, en el caso de querer pintar $0F (0000 1111), desplazado 1 vez, sería realizar una serie de operaciones con máscaras, ¿verdad?
$0F desplazado una vez es $C3 (1100 0011).
Entonces, necesito pintar 0000 0011 en un byte, y 1100 0000 en el siguiente, para mezclarlo más tarde con el siguiente byte.
Y de esta manera vamos creando la imagen del sprite, en memoria, rotado 4 veces.
Y luego viene el proceso de pintado en memoria de vídeo. ¿Es así?

Si miras el offset $0f en la tabla 1 verás que tiene el valor $c3 como tu has indicado.
Te adjunto el código (para 6809) que maneja las cuatro tablas y que busca el valor 'desplazado' para cada byte del sprite en dichas tablas
Es algo enmarañado ya que solo he copiado la rutina que trabaja con un sprite (nuevo o viejo) para dibujar o bien borrar
Verás que la primera rutina determina la tabla de shifts a emplear y sobrescribe el byte alto de la dirección donde hay que buscar
en la rutina que muestra una línea. Esta última lee el byte del sprite y lo pone como byte bajo para acceder al offset correcto de la tabla
que necesitamos en cada caso ...
Si te puede ser mas útil, puedo subirte aquí el fuente completo del motor AGD. Como admite muchos parámetros para poder trabajar con
distintos casos, su lectura es algo pesada, pero ... ya me dirás!
saludos
pere
SpritesReducidos.zip
(1.44 KiB) Descargado 45 veces

Avatar de Usuario
pser1
Mensajes: 4094
Registrado: 08 Dic 2012 18:34
Agradecido : 1352 veces
Agradecimiento recibido: 1118 veces

Re: Port del AGD de Z-80 a 6809

Mensajepor pser1 » 23 Ene 2023 15:36

explorer escribió:Entonces, en el caso de querer pintar $0F (0000 1111), desplazado 1 vez, sería realizar una serie de operaciones con máscaras, ¿verdad?
$0F desplazado una vez es $C3 (1100 0011).
Entonces, necesito pintar 0000 0011 en un byte, y 1100 0000 en el siguiente, para mezclarlo más tarde con el siguiente byte.
Y de esta manera vamos creando la imagen del sprite, en memoria, rotado 4 veces.
Y luego viene el proceso de pintado en memoria de vídeo. ¿Es así?

Olvidé decir respecto a tu última pregunta, que en el motor AGD no preparamos los bytes del sprite por cuadruplicado en memoria,
sino que se trabaja leyendo un solo sprite (byte a byte) y buscando en las tablas de desplazamientos (en función del frame actual), se procesan
y se escriben directamente en pantalla.
saludos
pere

jltursan
Mensajes: 5619
Registrado: 20 Sep 2011 13:59
Ubicación: Madrid
Agradecido : 990 veces
Agradecimiento recibido: 2040 veces
Contactar:

Re: Port del AGD de Z-80 a 6809

Mensajepor jltursan » 23 Ene 2023 16:01

Ya por curiosidad, Pere, ¿por experiencia habéis encontrado cual es la cantidad de sprites (a ojo de buen cubero) que hace que empiece a merecer la pena esta alternativa?.
Está claro que supone ese KB extra en tablas y una ligera pérdida de velocidad en el pintado; pero en caso de apreturas te puede salvar la vida.

Avatar de Usuario
pser1
Mensajes: 4094
Registrado: 08 Dic 2012 18:34
Agradecido : 1352 veces
Agradecimiento recibido: 1118 veces

Re: Port del AGD de Z-80 a 6809

Mensajepor pser1 » 23 Ene 2023 18:48

jltursan escribió:Ya por curiosidad, Pere, ¿por experiencia habéis encontrado cual es la cantidad de sprites (a ojo de buen cubero) que hace que empiece a merecer la pena esta alternativa?.
Está claro que supone ese KB extra en tablas y una ligera pérdida de velocidad en el pintado; pero en caso de apreturas te puede salvar la vida.

Nunca he hecho cálculos al respecto. En realidad me limito a convertir el fichero .SNA de Spectrum a fichero fuente AGD
y lo compilo para crear el binario 6809 para jugar. Si el fichero resultante excede de 32k (acaba mas allá de $8000) directamente
lo vuelvo a compilar con el parámetro R que habilita las tablas y, hasta ahora, siempre ha dado un ejecutable que cabe perfectamente
y, a veces, con mucha holgura!
Supongo que podríamos hace el cálculo al revés.
Las tablas ocupan 1024 bytes, asumiendo que el código ocupe 256 mas, el total serían 1280 bytes
Ahora depende del tipo de sprite que utilices, normal 16x16 o grande 16x24
Esto serían 32 bytes o 48 bytes por sprite/frame o sea 128 o 192 bytes por cada sprite (asumiendo máximo cuatro frames de animación)
Entonces, 1280 bytes/128 = 10 sprites. Mientras que 1280 bytes/192 = 6,6
Se ve claramente que con pocos sprites ya te sale a cuenta, 10 de 'normales' o 7 grandes ya compensarían el sistema
Y la verdad es que muchos juegos utilizan muchos mas sprites que estos mínimos.
saludos
pere

jltursan
Mensajes: 5619
Registrado: 20 Sep 2011 13:59
Ubicación: Madrid
Agradecido : 990 veces
Agradecimiento recibido: 2040 veces
Contactar:

Re: Port del AGD de Z-80 a 6809

Mensajepor jltursan » 23 Ene 2023 18:54

Entonces parece bastante práctico :-). El criterio de recurrir únicamente a este algoritmo cuando el programa no entre en memoria creo que es el más efectivo.

Avatar de Usuario
pser1
Mensajes: 4094
Registrado: 08 Dic 2012 18:34
Agradecido : 1352 veces
Agradecimiento recibido: 1118 veces

Re: Port del AGD de Z-80 a 6809

Mensajepor pser1 » 23 Ene 2023 18:58

@jltursan,
en el último cálculo he sido demasiado optimista.
He considerado que el truco salva la totalidad del los cuatro frames por sprite, pero en realidad siempre queda UNO
Así que el ahorro es de tres frames de forma que habría que recalcularlo de nuevo ....
1280 / (128-32) = 13,33 y los grandes 1280 / (192-48) = 8,88
El resultado no cambia demasiado pero establece los mínimos 'reales' en 14 sprites normales o 9 de grandes
Siguen siendo cifras bajas como habrás visto en muchos de los juegos que has convertido ...
saludos
pere


Volver a “Software Dragon”

¿Quién está conectado?

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