Karoshi MSX Community

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.

Es lo que os pasa a los que os pasáis mil pueblos, si es queeeee... ;D

Yo tuve mi experiencia con Malaika Prehistoric Quest... en un momento concreto del desarrollo, antes de hacer la versión física del juego, detecté corrupciones en gráficos (más bien, me las detectaron, jeje) y en parte del marcador al hacer las pruebas en el hard real: no se veían en ningún momento ni en el blue ni en el nlmsx. Tal vez las prisas nos hagan tirar en gran parte de emulador para desarrollar, y estaría bien que los emus tuvieran en cuenta las pausas necesarias para outear datos al VDP en MSX1, pero bien cierto es que lo mejor es probar en la máquina real, sobre todo cuando nuestro juego es muy exigente.

O si no, si se va de culo de tiempos, tirar de testers, y que te hagan ellos el trabajo de campo, que, como siempre, cuatro ojos ven siempre más que dos. Estoy seguro de que si comentas por aquí a la gente que se quede todo último dia del dev echándote una mano probando lo que fueras compilando en una máquina real, fijo que encontrabas algún usuario hardcore que pudiera ayudarte.

Pero vamos, queda claro que, en situaciones críticas, los emuladores no reflejan la realidad del MSX1...

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...

Ya decía mi madre que tanto OUTI en plena calle no podía ser bueno ;D


Sí. El problema al fin y al cabo son las prisas. Porque realmente el mover el "campo de OUTIs" fuera de la zona segura del VBL fue una (desafortunada) decisión tomada en las últimas horas a causa de que nos salíamos del frame y hubo que usar double buffering. Es posible que aun hubiéndolo probado en máquina real se hubiera escapado algo por el gran movimiento que hubo en el kernel en los últimos instantes, que habría imposibilitado probarlo suficientemente a fondo, pero en fin, a lo hecho, NEXT N.

Las deadlines de los concursos van en parte bien para obligarte a cumplir con un plazo, pero como son INTERRUPCIONES NO ENMASCARABLES, cuando acaba, acaba, y afrontar un proyecto con cara y ojos desde el cero absoluto en 2 meses con poquísimo tiempo dedicable al día he visto que no es aconsejable. Para la próxima a ver si me sincronizo con la interrupción.


Es la solución más lógica, pero tiene 2 inconvenientes a mi modo de ver:

• El planteamiento del kernel que "bombardea el hierro" puede variar muchas veces durante el desarrollo, y es lo más delicado en cuanto a compatibilidad, por lo que no veo viable probarlo sólo el último día.
• La otra opción sería pasar el build actual del juego frecuentemente a bastantes beta-testers de confianza que cubrieran un rango de máquinas lo más amplio posible, lo que quitaría no sólo el factor sorpresa para esa cantidad importante de gente, sino que con los cambios que sufre el juego, para muchas de esas personas la opinión del juego va empeorando (esto lo tengo comprobado empíricamente).

Supongo que la única manera de asegurarse será pasárselo a Ramones y obtener su sello :)

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! :D

Pues sí, se pueden definir las pruebas y hacerlas, no creo que ningún emulador tenga inconveniente en adaptarse a los resultados...

Yo tengo por algún lado el documento de la patente del TMS, que creo que es bastante detallado al respecto, luego lo busco y lo subo si no lo tiene nadie más.

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! :o

Pues aquí os dejo el enlace al documento en cuestión: http://www.megaupload.com/?d=TKF3K9TB (http://www.megaupload.com/?d=TKF3K9TB)

Y yo también me ofrezco a participar en las pruebas, y a que mi emulador sea el primero en cumplirlas excrupulosamente  ::)

Y bueno, ya que estamos, quizás podemos aprovechar para otras lagunas que quedan por ahí, como el VDP Toshiba y los modo mixtos...

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 (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!!! :o


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


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.

:D

Ya me he hartado de decirlo por aquí. Disponible estoy para probar las cosas. ;)

En cualquier caso, sobre el Retaliot... pues hombre, mirando el código, si, un emulador "perfecto" te hubiese avisado hace mucho tiempo de los problemas. Pero al final sabiendo 3 ó 4 cosas básicas  no habrías tenido problemas... En tu caso son tres:

- Usar 099h y 098h directamente: Prohibido en MSX1 (pero que no pasa nada, hay muchos juegos así)
- Búsqueda y posicionamiento de la memoria en página 0 totalmente incorrecto: De nuevo no pasa nada ... hay muchos juegos así.
- No poner las esperas necesarias entre outs/outi (porque lo de otir es como superavanzado para MSX1, casi inusable), que es realmente le problema más grave del Retaliot.

Como bien dices, si, el campotraviesa y la falta de experiencia es lo que jode todo. Pero bueno, de estas cosas se aprende. ;) Lo mejor es darse cuenta y saber corregirlo para el futuro.

Eso si... otra vez os voy a hacer yo tutoriales de cómo buscar la memoria en MSX y demás... si es que luego no le hacéis ni caso. xD

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

Sip, razón llevas en el modo mixto. Y otra cosa que no es NORMA de MSX y el TMS original si tiene, es el flag del 5º sprite. El chip lleva implementado ese flag... pero el MSX o la norma MSX no, así que algunos VDPs de Toshiba SI soportan el modo mixto pero NO soportan este flag (hace mil tonterías como indicarte que hay 5 sprites en linea y luego un número de plano que... no está en pantalla!!).

De hecho es que si os fijáis no hay ningún juego clásico que haga uso de él. Y si los clásicos conocidos  no lo usan, imagino que son de fiar. Tendrían documentación de primera mano. Por poner un ejemplo, Konami no lo usó nunca (y tenía rutinas para controlar el 5º sprite). Pero bueno, también es cierto que Konami no es precisamente muy fina para según que cosas, más bien eran brutotes. :D


Así que, ya que Mortimer parece decidido a implementar un modo MSX1 compatible, emulando las esperas del VDP, etc, etc... no estaría de más que emulase también estas cosas. (O mejor dicho NO las emulase) en algun modo específico de su emulador. No se, algo como "MSX 100% Compatible System" o que se yo. ;)

Temías que no te fuese algún juego...pues yo te digo que de los clásicos te irán todos o casi todos. Los que fallarán son los actuales. Pero vamos que para eso está lo de poder activar o no ese modo que te comento. Y, leches, a los desarrolladores nos harás felices si implementas estas cosas (o no las implementas xD) porque así podremos desarrollar más rápido y con más seguridad. Aunque como ya he repetido antes, al final son 3 cositas que tener en cuenta. Y, bueno, que lo suyo es probar luego todo en los MSX reales (y por favor, JUGARLO en los MSX reales). :P

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.  ;D

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

Arigatoo.

EDIT : Vale , ya lo veo...hay tuto namas entrar en este foro :P 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

El documento es el mismo que yo tenía, pero aunque lo explique todo con pelos y señales, seguramente en las máquinas reales su respuesta también vendrá dada por las de la memoria y demás componentes que intervengan. Así que nos harán faltan muchas pruebas de campo para buscar la velocidad máxima a la que escribir...

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...

Yo no sé los demás desarrolladores, pero yo ni me he leído nada de lo que haya escrito Ramones al respecto y, después del tono con que ha manejado el tema, ni me lo pienso leer en un futuro.

Y es simplemente porque cualquier programador que haya estado sus años y haya publicado sus juegos con el MSX sabe de sobras cómo va el tema de los OUTs, el R7 del PSG, la paginación, etc., pero por lo visto, hay gente que aun no comprende qué significa campo-traviesa, dejarse cosas por probar, cambiar un kernel en los últimos momentos o presentar un juego apresuradamente a un concurso con una deadline inamovible.

Creo que lo único que hice mal fue meterme en camisas de 11 varas al entrar en la dev 2 meses antes de su conclusión, sabiendo el poco tiempo del que dispongo actualmente cada dia para dedicar a la programación. Pero bueno, de eso, a dudar de la profesionalidad y experiencia, me parece que es pasarse. Que yo sepa no estoy pidiendo dinero por el producto y, de los productos que hemos vendido cuando estaba en Matra, nunca nadie nos los ha devuelto por incompatibilidades, y creo que en el milenio pasado fuimos precisamente de los pioneros en tratar el tema con un tinte más profesional.

Que cómo te lo voy a decir, Armando. Que los fallos que tiene Retaliot son por las prisas. Que ni siquiera te has fijado que ni estoy procesando el EARLY CLOCK de los sprites, y no clipean por la izquierda. Sí, sí, algo que todo el mundo sabe y se hace en 1 minuto, y que en mis 6 anteriores juegos evidentemente he hecho. Que 90 minutos antes del deadline ni leía el joystick, ni tenia joystick ni máquina real para probar la rutina, ni tenía repajolera idea de cómo configurar el blueMSX para que lo emulase por teclado. Que los OUTIs estaban en el vertical blank, que en ese periodo no contencionan, que hay porron de juegos y demos que lo hacen sin petar (Seleniak mismamente), pero con las prisas, nos salimos de frame, y tuve que mover los OUTIs a "campo abierto", donde sí hay contención, y me olvidé de añadir los NOPs. Punto pelota, no le des mas vueltas. Un fallo. Si hay que descalificar el juego, se descalifica.

Que vamos, al final voy a tener que pedir perdón por presentar un juego gratuitamente a un concurso. Concurso que gané hace 5 años y en el que no sólo entre pitos y flautas no me entregaron el premio, sino que encima me metieron castaña porque no funcionaba en los emus porque éstos no contaban los wait-states M1!!! Si es que hay para rasgarse las vestiduras!!! Que te metan porque no funcione en algo que está mal!!!

Que aparte de las horas y horas y horas de codos, de que puse en peligro mi matrimonio y el trabajo, para que luego se diga que ni tengo experiencia ni soy profesional y que soy poco menos que un inmigrante: que con 4 scrolles pa qui y 4 p'alla estoy "eclipsando" la sagrada labor de los que lo hacen todo bien, conforme al standard, con su BIOS, sus HOOKs y suputamadre.

[mod: Madonna, entiendo tu enfado, pero sintiéndolo mucho, tengo que moderar este párrafo. Violencia verbal, la justa, pero alusiones a la física, muchísimo menos. Apercibido quedas: de verdad que me duele, pero DEBES bajar el tono]

Yo paso de leer ya más alusiones y coletillas, prefiero estar programando la secuela del Retaliot, con sus OUTIs correctos, su búsqueda exhaustiva de RAM, su EARLY CLOCK, sus intros, outros, etc. etc. Y tranquilo que ya le pondré una opción RAMONES en el menú para que puedas jugar sin parallax, con scroll carácter a carácter, todo por BIOS/HOOKs, no sea que alguno de tus arcanos MSX de menor común denominador tenga algo tan enrevesado y oscuro que, por algun "defecto legal" (como los que permiten que salgan asesinos y violadores a la calle), cumpla con el standard, pero lo haga petar.

¿No te gustaba la polémica? Pues hala, a ver si te empachas.

En spectrum la emulacion es mas exacta porque solo hay que manejar un hardware (bueno, varios modelos, pero todos ellos del mismo fabricante y con los mismos componentes), mientras que en MSX hay docenas de fabricantes y se usan varios chips de video, por lo que no es tan directo que el emulador funcione perfectamente.

pero se supone que cumpliendo el estandar deberia ser la emulacion perfecta ¿no?  ademas si hay varios "fabricantes" de spectrum si a Inves se le considera fabricante

En cuanto lei el post de ramones me esperaba esta polemica :P y mas conociendo la experiencia de Madonna Mk2 en el MSX, y es que señores, criticar es muy facil y la gente se calienta, en ocasiones con razon, otras no.

Yo creo que ramones no lo ha dicho con malan intencion, creo que MMk2 estaba ya calentito con las criticas

paz hermanos

pd.que es el EARLY CLOCK ?

No, gobblin, no. Su post fue el 1º, así que no iba calentito, todo lo contrario. Y si no lo dijo con mala intentición, ¿porque al poco empecé a recibir cantidad de privados diciendo "no se lo tengas en cuenta a Ramones, el es así"? En ese momento comprendí que no era el único que veía claramente que me estaba llamando poco profesional.

En cuanto a las otras "críticas" (las elaboradas, tipo monosílabos "sux") pues evidentemente me las paso por el forro, porque capullos de miras y vocabulario tan elaborados hay en todos sitios, y si haces algo poco ortodoxo has de apechugar con que a una parte importante de la gente no le va a gustar nada.

Lo que cuenta es que al final han sido muchísimas reacciones más positivas que negativas, por lo que dado el campo-traviesa y los problemas de compatibilidad, me siento bastante satisfecho.

Por mí, paz. Pero hay que comprender que si se sueltan ciertas cosas injustamente, haya reacción.

Ya comenté en otro hilo que un mensaje al programador diciendo tranquilamente que el juego no funciona en tal ordenador, sin tanta Decepción ni desarrollo de la decepción, ayudaría a no crear esta polémica. Porque aunque seguro que Ramones no lo dice a mala fe, ese tono condescendiente y paternalista, en ocasiones y según cómo te pille puede rebentar  :P

Yo no lo se. En otro hilo más calmado podrías explicarlo  :)

Haya paz, joes.

A eso me refiero. Muchísima gente me comentó en privado los problemas y se ofrecieron a ayudar, que es lo lógico. Meter directamente un post en ese tono me parece una pasada de 3 pueblos. Que como decís todos "Ramones es así". Pues vale, yo soy asá, y me revienta. Así que si yo he de apechugar con su tono condescendiente y paternalista, que apechugue con mi tono "parricida", LOL!


Es un bit que sirve para que aparezcan correctamente los sprites por la izquierda. Si les pones coordenada x = 255 y vas decrementando, el sprite asoma pixel a pixel por la derecha correctamente, pero en la izquierda, si les pones x = 0, aparecen de golpe en el borde. Para que asomen, debes setear ese bit, con lo que a la coordenada X se le resta por hard 32, y puedes hacer que asome pixel a pixel (x = 16, 17, 18... en caso de que sean de 16x16 no ampliados.)

Hmm... lo siento MK2... pero no voy a seguir este hilo. No voy a contestar todo esto porque, seguramente, el que saldrá perjudicado seré yo. Se montará un pollo, se cerrará el hilo y solo habrá mosqueos.

Lógicamente puedo contestar todas tus argumentaciones, y de una forma sana y correcta, sin problemas, y estoy seguro que, como persona inteligente que eres las entenderías. Pero viendo tu tono actual me parece que jamás nos pondremos de acuerdo, por lo menos hasta que no te calmes.

Creo que estos problemas se resuelven en casa y no en un foro. Así que por respeto a todos los usuarios del mismo, y a sus moderadores, si hemos de mantener esta conversación prefiero llevarla al privado.

Entiendo la posición de Madonna Mk 2, como ya le he transmitido, y que esté quemado por las reacciones, pero la explosión ha sido, a mi enteder, excesiva, incluso obligándome a moderar parte del mensaje. Por otra parte, el post de Ramones de "Decepción", totalmente derrotista, pierde todas sus razones en cuanto a que omite el factor "error" o "fallo" de los desarrolladores, asumiendo directamente que la gente hace las cosas mal por defecto: aunque intenté bajar el tono del mensaje, el mal ya estaba hecho. Mal por uno y mal por otro. Así que, capón para los dos: me duele mas que a vosotros, que lo sepáis >:(

Hilo cerrado :-\

[Quejas al respecto, me ponéis un PM. Pero solo faltaría que ahora os enfadarais conmigo. Haya paz, por favor.]