Pruebas de sincronizacion con VSYNC via timer OPL [FM77AV]

[jimbobaby]

Hola

Abro este hilo para lo que dice el topic, intentar ver si encontramos un valor magico que permita hacer eso. Por una parte no hay ninguna garantia de que exista, pero por otro lado hay tantos valores posibles de timer que seria una lastima que ninguno funcionase

Asi que he estado filtrando la tabla de posibles frecuencias programables por ambos timers del chip de sonido, buscando los que tengan el rango de 16000 a 17000 microsegundos (aprox 62.5Hz a 58.8Hz), y a ver si suena la flauta.

En una primera aproximacion no he puesto todos los valores posibles por ambos timers, he puesto solo 34 posibilidades (de las 70 que hay), pero a ver si al menos vamos acotando.

El programa es muy sencillo (creo).

Basicamente al arrancarlo sale una pantalla donde puedes arrancar (tecla '1' ) o parar (tecla 'z') el timer. De entrada esta parado asi que le dariamos a 1 para empezar. En ese momento la barra vertical de la izquierda indicara sincronismo. En caso que la barra roja "disminuya", hay que incrementar el timer (tecla 'q'). En caso opuesto, que la barra roja crezca, hay que disminuirlo (tecla 'a').
Si la barra roja esta totalmente quieta, hay que dejarla un rato a ver si hay algo de deriva o no, pero seria buena señal.
En el emulador , con el valor inicial de partida, esta completamente sincronizado asi que no hay deriva ni desplazamiento. Supuse que seria un buen punto de partida con el hw real.
Cuando se cambia el timer, en pantalla sale un numero que es la configuracion del timer, y los microsegundos correspondientes. Con cualquiera de los dos valores ya me sirve.

Si no fuese posible encontrar un valor exacto que congelase la barra, me gustaria saber entre que dos valores estaria (quiero decir, el ultimo valor de timer en el que disminuye la barra roja, y el primer valor en el que crece)

Muy posiblemente me explico fatal, y no haria falta ni siquiera decir nada, pero bueno...

vsync_timer.zip

(44.97 KiB) Descargado 4 veces

PD: como es logico esto no tiene ninguna prisa....

[pser1]

Buenos días,
me he ajado el disco y lo he copiado a un disquet.
Al probarlo en mi FM77AV ha pasado esto:
- Con el valor por defecto 21, la barra roja de la izquierda baja bastante despacio pero sin para nunca
- Bajando el valor a 20, entonces la barra sube rápidamente
Ved los dos vídeos adjuntados. Uno de ellos es demasiado grande y lo he comprimido en partes de 15Mb
saludos

Pd como el sistema es torpe y no permite zip hechos en bloques (prohíbe las extensiones z01 y z02) entonces he renombrado
las dos partes siguientes al "Con valor 21 - barra bajando" añadiéndoles P1 y P2, así que tendréis que renombrarlos a .z01 y .z02
para que el descompresor de windows los procese juntos ...

Con valor 20 - barra subiendo.zip

(17.88 MiB) Descargado 4 veces

Con valor 21 - barra bajando P1.zip

(15 MiB) Descargado 4 veces

Con valor 21 - barra bajando P2.zip

(15 MiB) Descargado 3 veces

Con valor 21 - barra bajando.zip

(10.33 MiB) Descargado 4 veces

[jimbobaby]

- Con el valor por defecto 21, la barra roja de la izquierda baja bastante despacio pero sin para nunca
- Bajando el valor a 20, entonces la barra sube rápidamente
Ved los dos vídeos adjuntados. Uno de ellos es demasiado grande y lo he comprimido en partes de 15Mb

Muchas gracias, Pere!!! Los videos me vienen genial para hacerme a la idea...

Lo que me sorprende sobremanera es el "aspecto" . Me tiene totalmente desconcertado ese marco que hay alrededor... no me explico de donde sale.
Es como si vieses los datos de "overscan", pq esta claro que estas viendo el color 0 (que es con el que juego redefiniendo la paleta), pero sin embargo la parte en verde es tal cual el "area de dibujo" del modo B (320x200x4096).

Pero vamos, que lo comento como curiosidad, nada mas, no influye en nada
Ok, pues me pongo a hacer calculos y acotaciones..., de nuevo, muchisimas gracias!!!

[jimbobaby]

Ok, pues me pongo a hacer calculos y acotaciones..., de nuevo, muchisimas gracias!!!

Pues tiene mala pinta me temo
Entre 16611 microsegs y los 16640 microsegs, solo existe el 16621, cuando el que me seria ideal seria posiblemente un 16635.

Que se le va a hacer...

[pser1]

Ok, pues me pongo a hacer calculos y acotaciones..., de nuevo, muchisimas gracias!!!

Pues tiene mala pinta me temo
Entre 16611 microsegs y los 16640 microsegs, solo existe el 16621, cuando el que me seria ideal seria posiblemente un 16635.
Que se le va a hacer...

Si quieres subir un disco para que lo pruebe en el FM77AV, tu mismo
saludos

[jltursan]

Um...y digo yo...

Por lo que estáis comentando parece que el problema es que el temporizador acumula el error por culpa de no poder definir un timer más preciso; así que, ¿no sería posible redefinir el timer cada vez que este salte?.
Entiendo que esta operación es factible y que el recien reprogramado temporizador saltaría el siguiente fotograma. También estoy dando por supuesto que dicha reprogramación no debe ser demasiado costosa y tampoco se comería muchos ciclos.

Con todo esto, aun existiría "deriva" y se acumularía error; pero cada "x" temporizaciones se podría definir un temporizador "corrector" diferente que nos permitiera dejar las cosas como al principio y luego vuelta a empezar con el temporizador original.

Lo malo de todo esto es que el tiempo de cada fotograma sería ligeramente variable, no se si hasta el punto de que llegara a notarse.

[jimbobaby]

Por lo que estáis comentando parece que el problema es que el temporizador acumula el error por culpa de no poder definir un timer más preciso; así que, ¿no sería posible redefinir el timer cada vez que este salte?.
Entiendo que esta operación es factible y que el recien reprogramado temporizador saltaría el siguiente fotograma. También estoy dando por supuesto que dicha reprogramación no debe ser demasiado costosa y tampoco se comería muchos ciclos.

Con todo esto, aun existiría "deriva" y se acumularía error; pero cada "x" temporizaciones se podría definir un temporizador "corrector" diferente que nos permitiera dejar las cosas como al principio y luego vuelta a empezar con el temporizador original.

Lo malo de todo esto es que el tiempo de cada fotograma sería ligeramente variable, no se si hasta el punto de que llegara a notarse.

Creo que lo he entendido, pero me has dado otra idea "mejor" (sobre el papel, luego ya tu sabeh...). Pasar a usar el timer en modalidad "one shot", y en el ISR, hacer un delay fijo y controlado (sin interrupciones) antes de volver a reprogramar el timer. Lo que claro, habria que ver si es capaz de a) funcionar y b) convivir con todo lo que haya alrededor (musica, codigo, etc)

Lo pongo en la recamara

[jltursan]

Pues efestivamente, se puede hacer ese "one shot" que se quede corto y rellenar lo poco que falte con algo que sea medible en ciclos de forma muy precisa. El nuevo "one shot" habría que generarlo tuneando ese retardo, que siempre sería mucho más preciso que los temporizadores disponibles.

Ahora bien, si estamos puestos a meternos en un retardo de "x" ciclos, yo ya me cogía y ese espacio de tiempo me estaba "polleando" el comienzo del "vblank" (¿se podía hacer, verdad?, me suena que en un registro se reflejaba la entrada al retrazado), así conseguiríamos ser lo más estables posible y desaparecerían las posibles desviaciones en el periodo.