A raíz de las incompatibilidades detectadas en Retaliot con MSX1, creo que sería interesante mover el tema de los emuladores para que ofrecieran una emulación más fiel de los pormenores del VDP en dicha generación como una herramienta complementaria de ayuda al desarrollo.

Los principales emuladores actuales para Spectrum por ejemplo, ostentan un nivel de exactitud tan alto que te permiten poder desarrollar con la tranquilidad de que tu código se ejecutará perfectamente en las máquinas reales (aunque nunca hay que dejar de probarlo en ellas, por supuesto), ahorrando tiempo de desarrollo ya que las pruebas en real no tienen que ser tan frecuentes, y también permitiéndote probar configuraciones que puedas no tener físicamente.

Con Seleniak ya ocurrió el tema del wait-state en M1. Me parece que en el 2004 NINGÚN emu lo tenía en cuenta (el blueMSX fue actualizado a raíz del descubrimiento.)

Creo que hay información de sobra en cuanto a la contención del VDP para poder implementar dichos aspectos, y la que pudiera faltar, se podría sacar mediante las pruebas-ensayos-ajustes sobre máquina real y emulador pertinentes. Si dicha emulación enlenteciera demasiado el rendimiento, siempre se podría hacer opcional (seleccionable entre modo standard y accurate.) Tampoco veo problema en que algunas máquinas tuvieran que parametrizarse especialmente, ya que podrían entrar dichos parámetros en los ficheros de configuración.

Bueno, técnicamente lo que comentáis no es difícil, enlentecería un poco la emulación pero en condiciones normales en PCs normales sobrarían literalmente miles de millones de ciclos, así que no sería un problema, y menos sí se hace opcional. Otro asunto más delicado sería el dónde poner el corte, y si por hacer esto algún juego que funciona en un MSX real dejara de funcionar en un emulador... Es decir, que la regla no es tan secilla como controlar en que tic fue el anterior out y ver si el nuevo es muy cercano, porque dependerá de la cadencia, de si estamos en retrazo, del modo screen... Y ya no sé de otras cosas como si hay muchos sprites en pantalla por ejemplo. ¿Esta ya determinado el mínimo que funciona en todas las máquinas?

Quizás se podía hacer una solución básica que es la que yo hago en el emulador que tengo entre manos: como nació para hacer desarrollo rápido de juegos con funciones de alto nivel, no tenía sentido que luego de hacer algo no fuera viable en una máquina real porque por ejemplo no hubiera ancho de banda con la vram, así que tengo la opción de monitorizar el tic en que se hace cada escritura al vdp entre cada retrazo (Se escribe en in .log), y luego se podría analizar si hay alguna serie que no funcionarían en una máquina real...

Creo que no es nada que no se pueda obtener empíricamente con rutinas-experimento adecuadas. Así se hizo en el Spectrum antes de que estuvieran disponibles los diagramas internos de la ULA, los cuales corroboraron los resultados.

Por cierto, ¿no estan disponibles los diagramas del TMS?

¡Darth 007, te necesitamos!

Por mi parte me ofrezco para participar en la investigación y documentación seria y detallada del tema (con los ensayos registrados y compuestos pulcramente en LaTeX, y lo que haga falta, LOL!)


¡Ostras, pues eso sería ultra-crucial!

Gracias, pero a mi no me rula De todas maneras lo he encontrado aquí: http://www.smspower.org/dev/docs/wiki/uploads/VDP/TMS9918Patent.pdf

Está de-pu-tí-si-ma-ma-dre, más detallada que la patente del Spectrum. Crucial!!!


Perfecto Mortimer! Pues venga, a ver quién más se anima


Sí. Los modos chungos tienen su explicación en hard. Es apasionante entenderlos y utilizarlos en la medida que sea posible, como las instrucciones no documentadas del Z80.

Pero es que no solo son problemas como los aquí indicados.

Luego hay cosas tan divertidas como el famoso modo mixto para msx1, que hasta hace poco no se descubrió la problemática, ...y es que recordemos que, sin ir más lejos, hay MSX1 que tienen vdps de una marca y MSX1 que tienen de otras marcas, y tener una marca u otra implica que cosas como el modo mixto no funcionen (y que por tanto ya no sean usados en más desarrollos), pero claro, cualquier emulador se pasa eso por el forro.

Yo con mi hb-55p puedo ayudar, con sus 16KB de RAM a veces me siento obligado a usar una expansión de RAM externa para hacer funcionar segun que juegos, pero esta solución no siempre funciona con todos los juegos.

Makinavaja

Esto me interesa
Podria ustes hacer un post especial titulado: "Lo que nunca debes hacer en tu codigo para hacerlo 100% compatible MSX". No explicando como hacer sino solo lo prohibido, como la primera linea que has puesto del prohibido 99h-98h. Luego ya nos apañariamos entre todos para decir alternativas compatibles o buscarnos la vida que es más divertido. 

En mi caso, me interesa a nivel de hacer una ROM 32ks MAX...que estoy empezando  Ya para el MSX2 otro gallo cantaria.

Arigatoo.

EDIT : Vale , ya lo veo...hay tuto namas entrar en este foro Me sirve no para lo de la ROM de 32 ?

P.D: Y por que no se lo lee los desarroladores si tan a mano está !? XD XD

Bueno, con eso de que la norma no lo contemple, no estoy de acuerdo del todo, la norma indica que el chip de video tiene que ser un TMS9918 o compatible, que está autorizada la escritura directa a puerto (Leyendo antes la dirección en el BIOS), y que diferencias con los comportamientos originales pueden ser subsanados por los fabricantes vía BIOS. Pero como sabemos, con los 'compatibles' Toshiba, ni una cosa ni otra 

Cierto que la norma no explica cómo usar el flag del 5º sprite, o cómo usar la máscara AND para los modos mixtos, pero tampoco dice que sólo se pueda usar lo que se detalla, igual que tampoco entra a explicar cada opcode del Z80. Además, bueno que lo del modo mixto quizás sea fruto de como está diseñado el chip (Aunque Texas Instruments también lo tenga documentado por algún sitio), pero lo del 5º sprite, está documentado en todos los documentos oficiales, y lo peor, no es que no esté implementado, ¡Es que funciona mal!  . Seguramente nunca sabremos si todo esto fue por ahorrar unos yenes, desidia, desconocimiento, problemas de patentes, desición consciente... Pero al fin y al cabo a mi entender fue una chapuza... Además para rematar, luego llega Yamaha, hace un chip compatible y sí que incluye todos estos comportamientos.

Pero bueno, volvamos al lado práctico y a 2009  , pienso que lo mejor para todos es asumir que un MSX es la máquina de menor común denominador, y por tanto adaptarnos a ella. En mi emulador de refencia, lo que tengo es unos flags que activan o desactivan el uso de las máscaras sobre el registro R3 y R4, para el 5º sprite la opción que tengo por ahora es emularlo correctamente o no emularlo. La idea era, poder elegir qué tipo de chip estamos usando, que conectará o desactivará los distintos comportamientos,  y también crear un chip virtual que fuera algo así como 'lo peor de cada casa', y si funciona en eso, funcionaría en todo. Pero ahora mismo sobre la marcha, se me ocurre otra cosa quizás más interesante: se podría crear un modo de 'comprobación de compatibilidad', en la que se emulase en paralelo los distintos VDPs y se compararan la salidas. Si son distintas, es que algo no se verá bien en alguna máquina...