Si sincronizas con el VBLANK y en cada ciclo eres capaz de actualizar toda la lógica del juego y actualizar pantalla, vas a 60FPS (o 50 según la máquina sea a 50 o 60Hz)... Hmmm... acabo de soltar una perogrullada 8P


Mi experiencia (que es más bien poca ;-) me dice que tienes que hacer muchisimos cálculos para pasarte una interrupción. Lo que puede provocartelo, según mi experiencia, más que cálculos o la lógica del juego, son transferencias a saco en RAM, tipo actualizar la pantalla en RAM para un scroll antes de transferir a VRAM. Anyway, sí, puede pasar: te puedes saltar una int.


Juas! XDDDD



Pues yo lo definiría como el intervalo de tiempo en que se dibuja el borde inferior de la pantalla, se produce el retrazado vertical del CRT y se dibuja el borde superior.


Sí y no. Durante el VBLANK hay dos aspectos a tener en cuenta:

• No se pinta nada en pantalla (salvo el color de borde). Por lo tanto, si consigues enviar todos los datos de un frame a VRAM dentro del VBLANK, tienes la garantía de que ese frame se va a visualizar completo. Es decir, si envías datos fuera del VBLANK puede que parte de la pantalla se pinte actualizada y parte sin actualizar (con datos del frame anterior). Seguro que este efecto tiene un nombre.
  
• El VDP va más descansado y se le pueden enviar datos más rápidamente. Vamos, que dentro del VBLANK puedes poner OUTI a saco sin problemas. En cambio si mandas datos con OUTIs a saco fuera del VBLANK, se pueden corromper.
  

Si usas la BIOS, lo segundo no importa: la BIOS ya manda los datos lentamente para asegurarte que todo va bien. Mandes los datos dentro o fuera del VBLANK, la BIOS te los manda bien. Peeero, los manda muy lentamente. Así que si tienes que transferir mucha información, lo mejor es prescindir de la BIOS y asegurarte que lo haces todo dentro del VBLANK.

Eso sí, aunque uses la BIOS, si mandas fuera del VBLANK se puede producir el primer efecto que comentaba.


Yo también tenía una idea bastante intuitiva del VBLANK cuando hice el Caos. Ahí en cada frame sólo se mandaba a VRAM la tabla de atributos de sprites, y la pantalla cuando se cambiaba. En lo que estoy intentando hacer ahora hay más "berenjenal" y era aprovechar a fondo el VBLANK o abandonar

Un consejo: si quieres aprovechar el VBLANK, no te fies de los emuladores. Si por lo que fuera te salieras del VBLANK y mandaras datos demasiado rápido al VDP, el emulador se lo tragaría sin problemas pero el MSX real petaría.

Echa un vistazo al hilo "desarrollo compatible". Ahí hay información muy útil. Y en el hilo de "retrazado vertical" (y en algún otro) se comenta el tema de como ver fácilmente si te pasas del VBLANK o no.

Esta muy interesante el tema. Supongo que es algo que ira surgiendo continuamente en estos foros, a medida que nos vayamos sumando más en la programación...   
Veo que tenia una idea equivocada de lo que es el Vblank, y me surgen dudas: 
Yo pensaba que la interrupción del VBlank se disparaba cuando el vdp terminaba de dibujar la pantalla.
@MrSpock, a que te refieres con estar dentro o fuera del VBlank?
Estoy buscando una rutina rápida de volcado de ram a vram, para sustituir a la de la bios.
Se ha publicado alguna en los foros?
Saludos!

Vamos a intentar explicarlo de forma sencilla, aunque con algunas reservas que comentaré al final.

Empecemos desde el principio: el VDP es el encargado de dibujar la pantalla, para ésto lo que hace es leer la VRAM a partir de las direcciones que tenga configuradas en sus registros. Mientras el VDP realiza esta tarea, si queremos que haga otra tarea, como escribir en VRAM, el VDP no da para tanto y si le enviamos datos demasiado deprisa, se arma un lío y hace mal su trabajo, lo que se manifiesta con glitches visibles en la pantalla.

El VBLANK (ese gran desconocido) es el periodo que va desde que el VDP termina de dibujar la última línea con gráficos de la pantalla (proceso que, recordemos, implica una lectura contínua de la VRAM) hasta que empieza a dibujar la primera línea con gráficos de la pantalla en el siguiente frame. Durante ese período de tiempo, el VDP no necesita leer la VRAM para crear la pantalla visible, ya que sólo se visualiza el color de fondo (vale, sí, puede cambiar, pero el susodicho color está en un registro del VDP y no hay que leer en VRAM).

Así pues el concepto de "transferencias dentro del VBLANK" se refiere a todas aquellas transferencias a (o desde) VRAM que se realizan dentro del periodo del VBLANK. En este proceso, ya que el VDP no necesita acceder a la VRAM, podemos realizar transferencias al VDP a toda velocidad, sin esperas entre una y otra.

Por el contrario, el concepto de "transferencias fuera del VBLANK" hace referencia a todas aquellas transferencias a (o desde) VRAM que se realizan FUERA del periodo del VBLANK, es decir, mientras el VDP está pintando la pantalla (leyendo, para ello, el contenido de la VRAM). Como el VDP está ya accediendo constantemente a VRAM, es necesario realizar una pausa entre cada dos transferencias. Normalmente un par de NOPs son suficientes, aunque mejor que NOPs, si podéis realizar otros cálculos, aprovecharéis estos ciclos "muertos" para ir adelantando trabajo (ojo, no siempre será posible o fácil de hacer, pero si lo conseguís os sentiréis muy satisfechos).

Esa es, básicamente, la diferencia entre realizar transferencias dentro o fuera del VBLANK.

Las reservas a las que me refería al principio son los sprites. Si pensamos un poco más, si la pantalla utiliza sprites el VDP debe leer al mismo tiempo VARIAS direcciones de VRAM, ya que para saber el color de un pixel deberá leer la tabla de patrones, colores, sprites... vamos, un montón de lecturas. Si mal no recuerdo, si se desactivan los sprites las transferencias se pueden realizar a toda velocidad.

Otra cuestión es que si se desactiva la visualización de la pantalla, se pueden también realizar transferencias a toda pastilla, ya que el VDP sólo necesita pintar el color de fondo.

Así que básicamente esas son las cuestiones que hay que tener en cuenta a la hora de realizar transferencias a VRAM. La BIOS se cura en salud y siempre mete pausas entre una transferencia y otra, ese es el motivo por el cual las transferencias usando la BIOS son lentas.

En cuanto a la rutina rápida de transferencia, luego publico en Snippets la que uso yo.

Indeed, "peaso" explicación ;-)
Sólo he echado en falta una introducción en plan "Sea V el conjunto de posiciones de la VRAM y R un conjunto de registros. Definimos el VDP como una función f:VxR->VxR tal que bla bla bla" XDD


Exacto, tal y como comenté en mi primer post.


Ese hilo es una joya. Lo tengo al lado del RedBook y del listado de instrucciones del Z80.

No es tan simple, porque (al menos) el codominio de la función debería multiplicarse por un conjunto P de píxeles que representan la visualización de la pantalla... Sería divertido formalizar el VDP, pero creo que saldría demasiado complejo

Gracias a todos! 
aunque me queda un pregunta por hacer:
que tiempo dura el VBlank?
Si no he entendido mal, es el tiempo que dura desde que termina el trazado, marcado por la interrupción, hasta que empieza de nuevo a dibujar la pantalla, no?

y hay más tipos de interrupciones en el MSX?
creo que el z80 tiene varios modos de interrupciones y me pareció leer que los msx con controladora de disco, tenían una interrupción del reloj.
Es eso cierto?

Correcto.


En un MSX normal y corriente, sin ninguna tarjeta pinchada, las únicas interrupciones son las generadas por el VDP. En los MSX1 los VDP sólo generan las interrupciones de VBLANK, mientras que en los MSX2 o superior, también hay interrupciones por línea (que se aprovechan para los famosos screen split.


Que sólo controlan la forma en la que el Z80 responde a las interrupciones que lleguen. El problema es que TODAS las interrupciones han de ser controladas por la misma rutina de interrupciones, lo que obliga a discernir el tipo de interrupción y eso es costoso.

Existen tarjetas que generan sus propias interrupciones, el software que las utilice ya deberá tenerlas en cuenta. ¿Un ejemplo sencillo? La Franky/Playsoniq, que produce interrupciones generadas por el VDP de la SMS