Temas AGD

[jltursan]

¡Gracias Pere!, voy a bichear un poco con todo esto...

EDITO: ¡Bicheado!, con un pequeño ajuste para no perder la cabeza si no se encuentran objetos, ya tengo todos los recursos gráficos (font, blocks, sprites y map) en formatos "cristianos".
No está nada mal, nada menos que 211 bloques define el Springbot, creo que es el más grande que he visto en este aspecto.

[pser1]

¡Gracias Pere!, voy a bichear un poco con todo esto...
EDITO: ¡Bicheado!, con un pequeño ajuste para no perder la cabeza si no se encuentran objetos, ya tengo todos los recursos gráficos (font, blocks, sprites y map) en formatos "cristianos".
No está nada mal, nada menos que 211 bloques define el Springbot, creo que es el más grande que he visto en este aspecto.

Efectivamente,
yo también creo que es el juego que mas patrones tiene definidos!
Pero en el tema de sprites utiliza solamente seis, debe ser de los que menos emplea ...
saludos

[pser1]

Hola,
tras separar los motores para MC6847 y para V9958 en partes según su función, he ido añadiendo partes para conseguir el esqueleto
del arranque mas bucle principal del juego. Un primer paso hecho!
Todas las llamadas a funciones que implican datos las he comentado así que, cuando pueda, lo podré verificar (con XM7 y debug)
Al mismo tiempo, al programa AGDLOAD le he tenido que añadir otras estructuras de datos que los programas AGD generan al ser
compilados, por ejemplo:
- Mensajes
- Propiedades de los Patrones/Tiles
- Objetos
- Tablas pre-desplazadas
El problema es que esta versión para el juego SPRINGBOT al ser compilada, con todos los datos, ocupa desde $1000 hasta $7845
He tratado de verificar como va grabando en la ram extendida la mayoría de ellos y finalmente para a VRAM los patrones y sus propiedades
Sorprendentemente, al llegar a los patrones, me aparecía un área 'machacada' con valores '$FD' y no había forma de evitarlo
Por casualidad se me ha ocurrido mirar la ocupación del AGDLOAD que sabemos que funciona correctamente, pues bien, este utiliza
desde $1000 hasta $6C4C
He abierto XM7 y sin cargar nada, he mirado en el debug el valor del registro S, resulta ser igual a $7091
He ahí el problema. El puntero del stack está demasiado abajo para poder cargar la nueva versión del cargador, que ahora llamo FM77LOAD
Solo veo dos posibilidades, una que seamos capaces de llevarlo suficientemente hacia arriba para que al cargar FM77LOAD no machaque
el área del stack o bien en el peor de los casos, necesitaríamos dos cargadores para repartir el trabajo y la ocupación de memoria ...
saludos

[pser1]

pensando sobre el tema de programa muy largo que choca con el área de stack ...
No me parece aceptable la solución de comprimir los datos ya que el 'cargador' necesita saber donde acaba cada uno de los 10 bloques
de datos que deben ser copiados a EXT ram o VRAM. Además el descompresor también ocupa memoria y alarga el proceso ...
He puesto un mensaje en el hilo en inglés para malikto999.
Es posible que en algún momento nos haya explicado la ocupación de memoria con el DOS habilitado, a ver que nos dice al respecto
Cualquier idea será bien recibida
saludos

[pser1]

una idea que se me ha ocurrido, por pura desesperación ...
Si los tiles/patrones los declarásemos solamente con 8 bytes para la forma (en B/N) y 2 bytes para colores (tinta, papel)
tendríamos la misma estructura que estoy utilizando para los sprites.
Con la pantalla de 24x32 debemos manejar 768 tiles/patrones mientras que solo moveremos 8 sprites en cada VSync (16 en total)
No tengo claro si el cambio de procedimiento puede llegar a ralentizar demasiado el dibujado de pantalla cuando nos movamos de
una a otra ...
saludos

[jltursan]

¿Entiendo por lo que dices que no tienes los datos gráficos comprimidos?, en relación a eso, no entiendo lo siguiente:

No me parece aceptable la solución de comprimir los datos ya que el 'cargador' necesita saber donde acaba cada uno de los 10 bloques
de datos que deben ser copiados a EXT ram o VRAM

¿A que te refieres?

Y respecto al formato "Spectrum"; sí, seguro que se ralentiza ya que para cada bloque deberías convertir el formato tinta+papel a los datos bitmap necesarios que necesita el FM77. Si conviertes repetidamente cada bloque que imprimas, es un curro.

[pser1]

¿Entiendo por lo que dices que no tienes los datos gráficos comprimidos?

Efectivamente, tengo las definiciones tal como salen del compilador en C que genera el fichero .ASM para ser compilado mas adelante

en relación a eso, no entiendo lo siguiente:

No me parece aceptable la solución de comprimir los datos ya que el 'cargador' necesita saber donde acaba cada uno de los 10 bloques
de datos que deben ser copiados a EXT ram o VRAM

¿A que te refieres?

Pues quiero decir que cada juego va a generar una longitud distinta de datos (fcb $xx) por lo que la rutina que envia los datos desde RAM a la zona mapeada, sea VRAM o EXT ram, usa tres registros, regX como puntero a datos en RAM, regU como puntero a destino y regY como número de 'words' a copiar que será claramente distinto para cada juego. Al trabajar con el fichero .ASM es fácil calcular (FinDatos-InicioDatos)/2.

Y respecto al formato "Spectrum"; sí, seguro que se ralentiza ya que para cada bloque deberías convertir el formato tinta+papel a los datos bitmap necesarios que necesita el FM77. Si conviertes repetidamente cada bloque que imprimas, es un curro.

Lo cierto es que en las pruebas que habíamos hecho tiempo atrás empleé el compresor de Salvador que, de alguna manera, compactaba las 20Kb del original a unas 6,5 Kb solamente. El sistema empleado en un programa como "FSTLDA" consiste en leer el fichero comprimido y lo descomprime en RAM desde donde finalmente lo envía a VRAM para mostrarlo en pantalla.
AGD genera 10 estructuras de datos distintas, no veo muy claramente como controlar la longitud de cada uno sobre la marcha ...
Sinceramente, empiezo a creer que desdoblar el FM77LOAD en dos programas me parece bastante mas simple y no implicará ningún cambio
de formato de datos.
saludos

[jimbobaby]

pensando sobre el tema de programa muy largo que choca con el área de stack ...
No me parece aceptable la solución de comprimir los datos ya que el 'cargador' necesita saber donde acaba cada uno de los 10 bloques
de datos que deben ser copiados a EXT ram o VRAM. Además el descompresor también ocupa memoria y alarga el proceso ...
He puesto un mensaje en el hilo en inglés para malikto999.
Es posible que en algún momento nos haya explicado la ocupación de memoria con el DOS habilitado, a ver que nos dice al respecto
Cualquier idea será bien recibida
saludos

Conforme te iba leyendo me iba acordando de esto:

http://www.retrowiki.es/viewtopic.php?p ... p200182864

Si no quieres complicarte la vida con rutinas de carga por sectores y FAT y todo eso, y seguir cargando con un loader en BASIC, habria que partirlo en comodos plazos y que una vez cargados, se "auto-relocaten" a otras zonas, como hacia el volcado del Cloud Kingdom, y asi te quede todo lineal (en RAM mode, claro)

[pser1]

De momento he desdoblado el Cargador en dos partes FM77LDA1 y FM77LDA2, he procurado repartir la cantidad de bytes a pasar
a EXT ram, VRAM y SUBsytem para tener margen de crecimiento en los dos programas.
Como también tengo el 'bucle básico' preparado, espero poder hacer un largo debug para comprobar que los datos se copian en los
lugares esperados y que el bucle no tiene errores.
Espero que este finde me permita llevar a cabo todas las pruebas necesarias.
Además tendré que modificar el compilador para que trabaje con tres ficheros, así como el programa Basic "STARTUP"
saludos

Pd por si alguien quiere echar una ojeada, os adjunto comprimidos los dos cargadores, el motor (FM77CODE) y el mapa de memoria
que espero que esté actualizada sin errores

FM77DISK-v01.zip

(49.36 KiB) Descargado 8 veces

[jltursan]

Probablemente esa sea una buena opción..o eso, o el cargador "ad-hoc" que propone malikto999. Según dice, con ello se puede cargar en cualquier parte a voluntad...
Eso sí, no reduzcas la resolución de los elementos gráficos, intenta mantener el formato bitmap original del FM77; así, además de la versión "clon" del ZX, siempre se podrá generar una versión nativa más acorde con las posibilidades de la máquina.

[pser1]

Probablemente esa sea una buena opción..o eso, o el cargador "ad-hoc" que propone malikto999. Según dice, con ello se puede cargar en cualquier parte a voluntad...
Eso sí, no reduzcas la resolución de los elementos gráficos, intenta mantener el formato bitmap original del FM77; así, además de la versión "clon" del ZX, siempre se podrá generar una versión nativa más acorde con las posibilidades de la máquina.

Hola,
ya me miré el tema de carga rápida, pero de todas formas necesitas disponer de mucha área RAM (mapeada a EXT ram, por ejemplo) y así el
mismo LOAD deja los datos en destino, pero seguimos con el mismo problema de longitud de datos a menos que los carguemos por partes
por ejemplo sector a sector. Ya he olvidado el sistema que mostró malikto999 en el programa FSTLDA que además de leer sector a sector se
permite el lujo de cargar los datos después de pasar a modo todo RAM con lo cual se mapea 5 páginas (unos 20Kb)
Ya volveremos al tema mas adelante cuando toque preparar y mostrar la pantalla inicial y el posible 'panel' de datos
Respecto al formato de datos, los patrones se cargan con cuatro bitplanes, por tanto cada pixel puede tener su color (0-15), pero para
los sprites, imitando al V9958 solo admiten 1 color por cada línea, no por pixel. Así solo requieren 32 bytes para la forma y 16 para color
Permitir libertad total implicaría reservar 128 bytes por sprite y entiendo que querrás lo mismo para los objetos y esto puede ocupar mucha
pero que mucha memoria
Supongo que con la conversión de varios juegos veremos hasta que punto podemos llegar. Ahora mismo la mitad de la EXT ram está libre
Por cierto, los dos cargadores funcionan perfectamente, verificado pacientemente aunque debo decir que el documento Mapa de memoria
necesita actualización ya que los mapeos los he cambiado ....
Con el bucle de programa he tenido algún problemilla por errores de programación. Algunas definiciones como número de Objetos forman
parte de los datos cargados en FM77LDA1/2 y por lo tanto el motor *no* puede acceder a ellos sin antes mapear su área de EXT ram para asignar los valores a variables en la página 'dp' ($F0xx)
Serán necesarios algunos ajustes, pero lo veo factible. No creo que mañana disponga de tiempo para esto, pero tampoco tenemos prisas
saludos
Buen finde y mejor verbena!!

[pser1]

Hola,
estamos mal acostumbrados con las conversiones del motor AGD a nuestras 'viejas' plataformas.
En todas ellas el compilador C genera un fuente ASM (fichero único) que se puede compilar a su vez sin problemas.
Con el FM77AV tenemos ahora mismo dos cargadores y luego el motor que también llevará el script AGD compilado.
Problemas, pues aparecen mas de los que podía imaginar. Digamos que son molestias en realidad, pero joroban
Me explico. Los datos de gráficos suelen llevar adjuntos algunos valores como numObj, numSc y otros tipo WINDOWTOP, WINDOWLFT,
WINDOWHGT, WINDOWWID y mas que hasta ahora eran declarados con un simple EQU que luego el motor podía emplear sin problema alguno
Ahora estos 'equ' se perderían al cargar el motor, así que hay que convertirlos en fcb o fdb y luego añadir en el motor en su rutina
de inicio de variables un acceso a la ram EXTendida para leer estos valores y asignarlos a variables de la página 'directa' cuando antes no
hacía falta, esto implica modificar el código de funciones pues en lugar de usar valores fijos ahora usarán variables de la página directa.
Todos estos escollos aparecen al trazar el FM77CODE después de cargar y ejecutar los FM77LDA1 y FM77LDA2, sin hablar de los punteros
a datos que antes apuntaban a las estructuras de datos en el mismo fuente ASM pero ahora como los datos se han cargado en EXT ram
pues hay que asociar direcciones 'virtuales' a cada puntero para que funcionen una vez se haya mapeado la zona de datos a ram normal
y la dirección a vincular es precisamente la RAM, que no la EXT y si por cualquier cosa en la ejecución de alguna función se mapea a otra
área ram, pues adiós al puntero que apunta a la ram mapeada en el cargador correspondiente ...
Todo son alegrías
Espero poder tener algo operativo, pero será la próxima semana, seguramente
saludos

[jimbobaby]

Problemas, pues aparecen mas de los que podía imaginar. Digamos que son molestias en realidad, pero joroban

¿Pero tu no estabas de verbena? Haga usted el favor, suelte el teclao y rindase

Ahora en serio, pregunto desde la ignorancia.

¿Como te iria tener 3 ficheros ASM, el principal con el codigo (64KB), el de SUB (64KB, gfx y codigo) y el de EXT (64KB datos)?
El assembler te lo dejaria hacer, imagino (o sea, 64KB por fichero ASM), y luego seria cosa de cargarlo en uno u otro rango de memoria con, p.e., las rutinas de Malik en vez de usar solo el loadm. Eso implica decir adios, eso si, a la posibilidad de volver al F-BASIC (hay que cargarse el rango de disco de $7000-$8000 y usar el modo all-RAM).

Lo que no se como de sencillo te seria asi, porque si te es mas sencillo, eso lo puedo hacer hasta yo (*) , un loader que pille un binario y lo cargue en los 64KB que se diga (std, ext, sub).

(*) en sentido literal, no en tono de desprecio de la tarea

[pser1]

¿Pero tu no estabas de berbena? Haga usted el favor, suelte el teclao y rindase Ahora en serio, pregunto desde la ignorancia.
¿Como te iria tener 3 ficheros ASM, el principal con el codigo (64KB), el de SUB (64KB, gfx y codigo) y el de EXT (64KB datos)?
El assembler te lo dejaria hacer, imagino (o sea, 64KB por fichero ASM), y luego seria cosa de cargarlo en uno u otro rango de memoria con, p.e., las rutinas de Malik en vez de usar solo el loadm. Eso implica decir adios, eso si, a la posibilidad de volver al F-BASIC (hay que cargarse el rango de disco de $7000-$8000 y usar el modo all-RAM).
Lo que no se como de sencillo te seria asi, porque si te es mas sencillo, eso lo puedo hacer hasta yo (*) , un loader que pille un binario y lo cargue en los 64KB que se diga (std, ext, sub).
(*) en sentido literal, no en tono de desprecio de la tarea

Hola,
soluciones hay tantas como programadores Esto es lo que demuestra la experiencia.
Podemos hacer lo que queramos, pero de ninguna manera (fácil) vamos a emular el hecho de tener un solo fichero ASM
Hay información de las dos primeras partes (los cargadores) que deben ser compartidas con el Motor y estoy en ello. Creo que esto nos pasará
tomemos el camino que decidamos ...
De momento acepto trabajar con tres ficheros ASM como mal menor. Mas adelante ya experimentaremos con el cargador de malikto999
para simplificar el trabajo de carga, pero los problemas de definición de datos hay que resolverlos ya!
Espero hacer pruebas en XM7 como muy tarde mañana con la última versión que ya incorpora bastantes correcciones/modificaciones
La parte mas dura va a ser 'personalizar' el compilador en C que genera hasta ahora un solo fichero ASM para que pase a generar tres
cumpliendo los nuevos requisitos para se 'entiendan' los cargadores con el motor, pero esto ya lo tratemos al final de todo!
saludos

[pser1]

Hola,
hace poco conseguí trazar hasta el bucle principal del motor AGD sin observar errores de asignación de variables y punteros.
Así que ahora ya podríamos decir que disponemos de una base 'aceptable' para cargar datos gráficos y luego arrancar el motor AGD
Os adjunto todos los ficheros de la compilación de los tres fuentes junto con el Mapa de memoria que espero que ahora si esté actualizado
A ver por donde sigo, probablemente VSync sea el mejor candidato ya que nos controlaría el ritmo de programa.
En AGD tenemos un IRQ que nos va incrementando una variable contador/timer que es verificada en VSync para saber lo que hay que hacer
Empezaré por 'reactivar' el IRQ que habíamos estado probando para que haga lo mismo
saludos

FM77DISK-v02.ZIP

(278.3 KiB) Descargado 6 veces

[pser1]

Buenos días,
tras unas cuantas pruebas mas para corregir errores elementales como reponer la página directa antes de volver al Basic y reconfigurar
el teclado para usar códigos ASCII, ahora ya es un bucle operativo.
La interrupción IRQ incrementa un contador y cada vez que llega a 20 se resetea y se incrementa otro contador. Este último es chequeado en el Bucle principal (MLoop) de momento solo para verificar que funciona. Cuando llega a 32, el programa termina y vuelve al Basic
No es que me guste mucho esto de que debamos esperar tantos IRQ para que se trabaje con los sprites en el bucle principal, pero de momento
puede servir. No sé, tal vez se podría utilizar el control del período de blanqueo en VSync y pasar del IRQ
Adjunto versión FM77DISK-v02A por lo poco que ha cambiado ...
saludos

FM77DISK-v02A.ZIP

(280.36 KiB) Descargado 7 veces