Correcto el tema conceptual y la aplicación. Te puedes fiar bastante de cómo funciona en cuanto al tiempo consumido en los emuladores, se parecerá bastante al empleado en el hardware real.

PERO ten en cuenta lo siguiente:
1.- Estás asumiendo que el puerto correcto es el 99h - deberías leer de la BIOS la dirección correcta o usar la BIOS directamente con un hermosísimo WRTVDP
2.- El emulador te aguantará transferencias a VRAM sin apenas pausas, mientras que los MSX necesitarán retardos, especialmente los MSX1 y, sobre todo, porque algunos modelos necesitan aún más retardo.

Yo iría editando el hilo, porque como vean el código Armando o Sap te va a caer un paquete, Toni

El punto 2, desde un punto de vista estadístico, es muchísimo más relevante que el 1. En cuanto a retardos, échale un vistazo a los documentos de desarrollo compatible que están en esta misma sección del foro.

Un saludo. Y mándame lo que sea por privado, que tengo mono ya de ver cositas tuyas (por pedir, que no quede).

Lo de los netbooks es una bendición. Especialmente ahora que ya tenemos por fin procesadores un poco dignos, como el N550 o el D525, y hasta 2 GB de RAM DDR3 a 1066 MHz o más. Eso sí, te recomendaría que abandones Windows Vista/7 porque van muuuuuy mal. Estoy encantado con Ubuntu (Desktop) y Ubuntu Netbook Remix. Y si necesitas un asMSX para Linux, aquí lo tengo, calentito aún

Ya se que en el manual del standard no dice que se tenga q usar el port 99h SIEMPRE para el VDP pero....
...
Tan tan tan tan tan raro es que no use un MSX el port 99h para el VDP ?  
Que posibilidades hay que un juego creado usando sin preguntar a la BIOS el port 99h no funcione ? [No quiero pensar cual]  
Que modelos se conocen que no use ese port para el VDP ?

fdo. un coder malo que no ha mirado WRTVDP  

30 minutos despues...
EDIT: He leido en el tutorial de desarrollo lo siguiente: "Aunque en el 99,99% de los casos se trata de los puertos $98 y $99". Me quedo más tranquilo. jolin! es q me he hecho "caquita" por un momento.

Si. Otra cosa es que a ti te interese no usarla.

Un vistazo rapido a los mappers. Aqui.
http://bifi.msxnet.org/msxnet/tech/megaroms.html

Buenas!

Creo que ya tengo todo bastante claro. Muy interesante el "meisei fast vram". Tiene alguna cosilla curiosa, como que al arrancar me detecta accesos demasiado rápidos a VRAM de la propia C-BIOS. Y también me detecta accesos demasiado rápidos usando exclusivamente BIOS. Curioso.

Aún así, gracias al "meisei fast VRAM" y cambiando los colores del borde ya he conseguido mandar a VRAM todo lo que necesito en el vblank. Gracias Sapphire y Edu!

Anyway, tengo una nueva duda. Veréis, el núcleo de mi juego era tal que asín:


Y en la interrupción HTIMI básicamente hago

            

El problema con que me encontré es que cuando se produce la interrupción, tras ejecutar mi código, ejecuta otras cosas de la BIOS, y, claro, me roba unos ciclos preciosos del vblank.

Mi solución fue meter las transferencias a VRAM dentro de mi rutina de servicio a la interrupción, así me aseguro que lo primero que se hace en el vblank es actualizar VRAM. Pero, claro, así se me puede colar una interrupción mientras estoy actualizando la lógica del juego y de vez en cuando me salta un frame mal actualizado.

De momento, uso un flag que impide actualizar VRAM si no he terminado con la lógica, pero no me acaba de convencer. ¿Hay alguna forma mejor de hacer que nada más entrar en el vblank se ejecute lo que yo quiera sin tener que esperar a que la BIOS termine sus cosas?

PS: Edu, sí, la verdad es que ya hay netbooks más que decentes. El mío es un Toshiba NB305 con una CPU N455 a 1.66GHz. Eso sí, tiro de Windows 7, y es una lástima, porque va más lento de lo que debería. Aún así, me da un poco de miedo meterle Linux. Según me han comentado puede dar problemas con la salida VGA, y también suelo usarlo para dar charlas con proyector.

PS2: La curiosidad me pudo, y decidí probar el sjasm, así que ahora mismo estoy con este en lugar de asMSX

PS3: No, no estoy preparando nada para la dev. Me puse con este proyecto en navidades, y apenas tengo nada aún.

Supongo que hacemos algo parecido. Lo que hacía yo antes tras la lógica del juego era esperar a que se activara un flag. Y el flag se activaba dentro de la interrupción. Así me sincronizaba con la interrupción. Algo así como un EI HALT.

El tema es que no me gusta meter mucho código dentro de la rutina de servicio a la interrupción, pero supongo que no hay más remedio.

Saludos!
Toni

Hmmm... supongo que con la depre post-navidades no me he explicado bien A ver...

Yo no uso un halt, sólo comenté lo del halt como ejemplo. Lo que hacía antes era lo mismo que dices tú, Sapphire: en el cuerpo principal esperaba un flag que activaba en la rutina de interrupción. Y dentro de la rutina, además de activar el flag, llamaba al replayer musical. La ventaja de esto respecto al EI HALT es que la música siempre suena perfecta aunque en algún ciclo el cuerpo del programa tarde mucho (por ejemplo, en situaciones especiales en que tengo que descomprimir datos).

El problema que me encontré es que la rutina de interrupción, tras ejecutar mi código (flag + música) ejecutaba otras cosas de la BIOS. Con lo cual, no volvía al cuerpo del programa hasta que la BIOS hubiera terminado, y se me comía unos ciclos preciosos de vblank que necesito para transferencias a VRAM.

Mi pregunta era: si quiero que mis transferencias a VRAM empiecen justo en el VBLANK, sin tener que esperar a que la BIOS haga sus cosas, ¿cómo lo hago? ¿no tengo más remedio que meterlas en la rutina de interrupción?

Espero haberme explicado