Temas AGD

[jimbobaby]

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

Ok, veamos. La ventaja de las IRQs es que de mientras te dejan tranquilo y puedes hacer cosas.. como metas Vsync's alegremente te estaras comiendo la CPU a bocaos sin darte cuenta.

En mi opinion lo mas sencillo seria ir con timers de momento.

Dicho esto.. el motor AGD ¿que necesita a nivel timers? ¿Uno unico cada 1/50 de seg? ¿Hay AGD para maquinas NTSC o todas son PAL?

Edit: Nada, que leo en diagonal ...

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

Pero entonces... por lo que leo, en VSYNC (50 o 60 veces por segundo, habria que ver segun lo dicho, que pasa con NTSC) se lee la variable contador que se incrementa por un timer de... ¿que frecuencia?

[pser1]

Ok, veamos. La ventaja de las IRQs es que de mientras te dejan tranquilo y puedes hacer cosas.. como metas Vsync's alegremente te estaras comiendo la CPU a bocaos sin darte cuenta.
En mi opinion lo mas sencillo seria ir con timers de momento.

Es posible que sea esto lo que pase, pero de todas formas en la rutina VSync se guarda una copia del valor anterior de TIMER y no se mueve nadie hasta que cambie de valor, mas o menos como si estuvieras en un bucle de espera.

Dicho esto.. el motor AGD ¿que necesita a nivel timers? ¿Uno unico cada 1/50 de seg? ¿Hay AGD para maquinas NTSC o todas son PAL?
Edit: Nada, que leo en diagonal ...

Efectivamente hay un único contador/timer en el motor AGD

Pero entonces... por lo que leo, en VSYNC (50 o 60 veces por segundo, habria que ver segun lo dicho, que pasa con NTSC) se lee la variable contador que se incrementa por un timer de... ¿que frecuencia?

En las dos versiones que he hecho del motor AGD, el contador lo incrementa en sincronismo vertical, por lo que en Dragón va a 50Hz, pero en CoCo va a 60Hz por lo que los juegos van un 20% mas rápidos en los CoCo-NTSC
Aquí no habrá problemas ya que solo conozco FM77AV2 de Japón, creo que no se llegaron a fabricar en España.
saludos

[jimbobaby]

En las dos versiones que he hecho del motor AGD, el contador lo incrementa en sincronismo vertical, por lo que en Dragón va a 50Hz, pero en CoCo va a 60Hz por lo que los juegos van un 20% mas rápidos en los CoCo-NTSC
Aquí no habrá problemas ya que solo conozco FM77AV2 de Japón, creo que no se llegaron a fabricar en España.

Ok, con lo cual el timer actual (el normal de la maquina) como genera 492 ticks por segundo, si queremos algo similar a los 60hz, pues cada 8 ticks incrementariamos esa variable interna (lo cual da 61hz, no es lo mismo ni esta sincronizado con pantalla, pero tampoco se desmadra demasiado).

Usando otros timers se pueden conseguir esos 60hz de forma mas precisa, claro, lo reviso.

[jltursan]

No perdamos de vista cual es el objetivo de este "timer" del AGD, no sólo se trata de marcar el ritmo de ejecución, ya sea 1/50 o 1/60, se trata también de localizar realmente cuando se está entrando en el VBLANK, de ahí que la subrutina se haya llamado "vsync" .
En máquinas como el Spectrum es crucial ya que ese es el momento ideal para volcar los sprites por software y junto con el ordenamiento según su ordenada, tratar de evitar en lo posible que haya "tearing".
En los MSX no resultaba demasiado crítico esto ya que eso, al estar resuelto por hardware, tardaba ná y menos.
En el FM77AV2 es probable que si no se respeta ese inicio del VBLANK y se funcione simplemente mediante interrupciones sin relación con el barrido, se observen esos problemas de "tearing".

En el Tatung Einstein me encontré con un problema similar al no tener el Tatung ligado el evento de VBLANK con alguna interrupción del Z80 y por lo tanto había que estar leyendo continuamente un registro para saber cuando se entraba en ese periodo. La única solución que encontré es que inicialmente se detectara ese instante con la mayor precisión posible y que se programara un timer con el periodo exacto de un frame...y funcionaba, al menos hasta que la emulación comenzaba a derivar y ese instante iba desplazándose en el tiempo. No avancé mucho más con ese motor.

[jimbobaby]

No perdamos de vista cual es el objetivo de este "timer" del AGD, no sólo se trata de marcar el ritmo de ejecución, ya sea 1/50 o 1/60, se trata también de localizar realmente cuando se está entrando en el VBLANK, de ahí que la subrutina se haya llamado "vsync" .
En máquinas como el Spectrum es crucial ya que ese es el momento ideal para volcar los sprites por software y junto con el ordenamiento según su ordenada, tratar de evitar en lo posible que haya "tearing".
En los MSX no resultaba demasiado crítico esto ya que eso, al estar resuelto por hardware, tardaba ná y menos.
En el FM77AV2 es probable que si no se respeta ese inicio del VBLANK y se funcione simplemente mediante interrupciones sin relación con el barrido, se observen esos problemas de "tearing".

No, si no pierdo el objetivo , soy muy fan del framerate "rock solid". Y esta clarisimo que sin vsync y solo con timer vas a tener tearing y parpadeos mas o menos a tutiplen, aunque por lo que se ha visto parece mas tolerable de lo que dice la teoria.

Pero si pasas a usar vsync, tienes muuuuyyyyy poquito tiempo para hacer las cosas, y tal y como funciona la maquina (varios bitplanes, "pintado" por software, sincronizar dos cpus, velocidades lentas (y aun mas con MMR)) te obliga a aligerar mucho la carga grafica si quieres mantener el ritmo.

Si no lo haces, y te enganchas a vsync, tendras sprites que en funcion de que coordenada Y se pinten, desapareceran total o parcialmente, o que iran cambiando de color (segun cuantos bitplanes hayas podido colorear antes de que te pille el haz).

[jltursan]

El trabajo de pintado creo que Pere lo mantenía repartido entre dos fotogramas (al estilo del Spectrum) y juraría que comentó que la máquina iba alegre. De todas formas, si se implementa el vsync dinámico en condiciones, se supone que cuando llegues a esperar por un cambio de fotograma o por el periodo de vblank, si detectas que te has pasado de tu tiempo, ya no te vas a detener y dejarás que el código se ejecute a escape libre (excepto lo que no pueda ser, como los temas de sonido y tal).

En general, cuando te pasas del tiempo del fotograma, son todo problemas y tirones

[jimbobaby]

En general, cuando te pasas del tiempo del fotograma, son todo problemas y tirones

No, si no hablo de cuando te pasas del tiempo de fotograma. Hablo del poquito tiempo desde que la maquina te dice que hay vsync (que en el caso de la familia del FM7 es aun mas doloroso) hasta que se empiezan a ver las mismas lineas sobre las que estas trabajando (en 4 bitplanes que no puedes modificar "a la vez")

Pero bueno, ya se ira viendo (pun intended)

[jltursan]

Ah, si claro; pero bueno, si se haga lo que se haga al final no da tiempo a pintar todos los sprites que toque pintar y te pilla el barrido moviendo...pues que se le va a hacer. El problema es que si ya vas mal en el fotograma, el riesgo de que acabes pasándote al siguiente fotograma es grande.
Le tengo ojeriza a la gestión de las colisiones, en general los scripts son ágiles; pero como se te vaya la pinza buscando colisiones, te comes el tiempo cosa mala.

Respecto al pintado, creo que ya lo hemos comentado; pero la versión Spectrum, que es el referente, maneja 6 sprites por fotograma y actualiza el total, 12 sprites, cada dos frames. Como sigo sin tener claro como se maneja Pere, pues no quiero opinar mucho. Se que por cuestiones de economía de memoria estaba pintando un color único por línea, como los sprites de del V9958, cosa que no creo que permita ahorrar mucha CPU tampoco.

[pser1]

Ah, si claro; pero bueno, si se haga lo que se haga al final no da tiempo a pintar todos los sprites que toque pintar y te pilla el barrido moviendo...pues que se le va a hacer. El problema es que si ya vas mal en el fotograma, el riesgo de que acabes pasándote al siguiente fotograma es grande.
Le tengo ojeriza a la gestión de las colisiones, en general los scripts son ágiles; pero como se te vaya la pinza buscando colisiones, te comes el tiempo cosa mala.
Respecto al pintado, creo que ya lo hemos comentado; pero la versión Spectrum, que es el referente, maneja 6 sprites por fotograma y actualiza el total, 12 sprites, cada dos frames. Como sigo sin tener claro como se maneja Pere, pues no quiero opinar mucho. Se que por cuestiones de economía de memoria estaba pintando un color único por línea, como los sprites de del V9958, cosa que no creo que permita ahorrar mucha CPU tampoco.

Hola,
me he despistado un rato y al volver me encuentro un montón de mensajes!
El 'intento' de motor para FM77AV procesará los sprites en dos pasadas, mitad en cada uno como con el MC6847
Con el V9958 acabé utilizando otro método. Mostrar todos los sprites en un VSync y en el siguiente solamente hacer los cálculos con lo
cual viene a ser lo mismo, todo se hace cada dos pasadas
En la función, todavía no implementada "VSync" se compara el TIMER con el valor recibido en la llamada anterior y si no ha cambiado
espera pacientemente hasta que esto suceda para proseguir con sus tareas ....
Así que tal vez no sea descabellado implementar en VSync la lectura del 'periodo' dibujado/Retrazado en un bucle de espera.
saludos

Ps me pongo el traje de buzo para debugar. Cuando permito que se llame a DRoom incluso con el código empleado en la versión
anterior que funcionaba perfectamente, aquí no muestra nada de nada
Avanzar con el motor es una carrera de obstáculos

[pser1]

por cierto, habiendo leído el comentario de José Luis sobre los sprites, me quedo con la duda, que despejaremos mas adelante, de si
vale la pena tener sprites policromados sobre fondos con 16 colores. Lo cierto es que con uno, dos y hasta cuatro colores me parece mas
que suficiente. Esto permitiría que el pintado a cuatro planos fuera algo mas rápido pues una vez testeado el bit de color para el
plano actual, podríamos enviar a pantalla 4 pares de bytes en lugar de solo un par, reduciendo los testeos a la cuarta parte.
La alternativa de permitir definir el sprite con sus colores directamente en cuatro planos sería mucho mas eficiente, pero choca con la
posibilidad que ofrece AGD de tener distintas 'copias' de un sprite con colores distintos ...
Habrá que valorar pros y contras ... sin prisas, primero Patrones/Pantallas, luego ya veremos
saludos

[jimbobaby]

Ps me pongo el traje de buzo para debugar. Cuando permito que se llame a DRoom incluso con el código empleado en la versión
anterior que funcionaba perfectamente, aquí no muestra nada de nada

A mi me ha sorprendido una cosa: con el formato actual de 3 ficheros, se puede ver en pantalla los datos cargados en VRAM (cosa que antes no lo hacia, pero puede ser simplemente que haya cambiado el orden en carga de datos y asignacion de la paleta) y luego (no se exactamente en que momento, pero parece que es antes de volver al basic) desaparecen dichos datos y en cambio aparece una franja en el final del ultimo bitplane (de la pagina 1).

No he mirado todavia cuando ocurre, ni si esto ultimo esta relacionado con lo que te pasa (lo de la paleta entiendo que es anecdotico).

[pser1]

A mi me ha sorprendido una cosa: con el formato actual de 3 ficheros, se puede ver en pantalla los datos cargados en VRAM (cosa que antes no lo hacia, pero puede ser simplemente que haya cambiado el orden en carga de datos y asignacion de la paleta) y luego (no se exactamente en que momento, pero parece que es antes de volver al basic) desaparecen dichos datos y en cambio aparece una franja en el final del ultimo bitplane (de la pagina 1).
No he mirado todavia cuando ocurre, ni si esto ultimo esta relacionado con lo que te pasa (lo de la paleta entiendo que es anecdotico).

Efectivamente, esto debe ser así. La franja del final de la VRAM es al mapa de propiedades de los patrones en la pantalla de trabajo
que por defecto se llena a valor $02 = WALL
Por lo que he podido debugar, he llegado hasta el final de la función DRoom, que después de ir recogiendo bytes descomprimidos los va pasando
a VRAM (layout) -> $1BD00-$1BFFF mapeados a $9D00-$9FFF. He comprobado que los valores son correctos, comparando con el fuente AGD del
juego original en blanco y negro.
El problema (en esta versión) es que el Subsistema no hace ni caso de la llamada que hay al final de DRoom que simplemente le envía el
subcomando $80 (Draw Screen) y el parámetro $04 (margen izquierdo)
Por algún motivo con tanto cargar ficheros le pasa algo al subsistema y deja de reconocer los comandos.
Mirando la RAM del subsistema se puede ver perfectamente el código a partir de $D500
Es como si ya no estuviera haciendo su bucle por el área FC80- o su equivalente D380-
¿Puede haberse quedado parado hasta el punto de no ser capaz de Reanudar su trabajo?
Sabemos perfectamente que la versión anterior con solo dos ficheros funcionaba correctamente y el SUB pintaba pantallas ...
Adjunto última versión por si alguien quiere quemarse las cejas
saludos

FM77DISK-v03.ZIP

(282.81 KiB) Descargado 8 veces

[jimbobaby]

¿Puede haberse quedado parado hasta el punto de no ser capaz de Reanudar su trabajo?

El problema es que en el loader2, nada mas empezar, pones de nuevo el modoB, limpiando la VRAM en el proceso
Es solo comentar esa linea y todo va sobre ruedas!!!

[pser1]

El problema es que en el loader2, nada mas empezar, pones de nuevo el modoB, limpiando la VRAM en el proceso
Es solo comentar esa linea y todo va sobre ruedas!!!

Vaya hombre,
buen descubrimiento
O sea que no era el subsistema, sinó que los Tiles habian sido sobreescritos
Ni se me había ocurrido que pudiera suceder esto
saludos

[pser1]

Dejo como v03 la versión corregida como indica jimbobaby.
Ahora toca adaptar el código de "DRoom" para que tenga/use las mismas subrutinas que el motor AGD.
Puede que haya problemillas ya que en AGD Tiles y Fonts tienen puntos de código compartidos (todos son 8x8)
Lo malo es que para FM77AV mientras que los tiles están definidos como 4 planos de 8 bytes (32 bytes) los caracteres de texto
están definidos con solo 8 bytes pudiendo aplicar color o no a la mitad superior/inferior
Habrá que ir con sumo cuidado para evitar llamadas entre las funciones que tratan esos tipos de datos para evitar fallos graves!
saludos

[pser1]

Ha habido suerte.
Me había estado mirando el motor para MC6847, pero luego me he decidido por 'copiar' el procedimiento empleado para el V9958
Al hacerlo la versión actual ya llena la tabla PROPMAP que son 24x32 bytes con la propiedad de cada patrón en la pantalla actual
Estos datos son imprescindibles para verificar si los sprites pueden moverse ...
Para respetar el orden de datos para el V9958 he tenido que cambiar las direcciones de Layout y PROPMAP tanto en el programa de carga1
como en el motor.
Otro efecto secundario es que queda preparado para Metabloques que son conjuntos de cuatro patrones o sea patrones de 16x16 que deben
seguir ciertas reglas. Se habilitan con el XFLAG
Otra parte que añadiré ya es el tema de los patrones/bloques pulsantes, que parpadean. Solo los implementé para el V9958, creo.
En fin, que os subo la versión FM77DISK-v04. Las diferencias solo son apreciables trazando el programa y viendo los datos ...
El mapa de memoria ha cambiado por lo que también os lo adjunto
saludos

FM77DISK-v04.ZIP

(285.15 KiB) Descargado 6 veces