Yo no.... porque mis juegos van en 8k.

Bueno, lo cierto es que ya llevaba la idea rondándome por la cabeza desde hace un par de años, cuando Salva y yo estábamos en mi casa después de una MadriSX & Retro (aún se llamaban así) y probábamos el Gradius II de PC-Engine en el emulador para la XBOX. Resulta que pusimos una tarjeta de CD inadecuada y salía una animación muy graciosa indicando que necesitábamos la tarjeta patatín...

Tened por seguro (y llamadme friki) que cuando haga un juego para MSX2, si se pincha en un MSX1 va a salir algo más elaborado que un simple mensajito

Como ellos. A ver, que tienen razón, claro que si. El juego HA de funcionar en su modo natural, es decir LA ROM. SOLO hay un problema, y es que eso no ocurre siempre.


En efecto, a veces cuesta poco, pero a veces es imposible, depende de como sea el programa.

En cualquier caso, sobre el modo "inteligente" de que un cargador de Ram funcione, hay muchos problemas, partiendo de la base de que el juego ROM no esté preparado. Enumero:

a) ¿Que hago si la Ram del MSX está en distintos slots/sublots? Los juegos ROM siempre funcionan en el mismo slot. En caso de ser un 32k o más se posicionará solito en donde arranque (el slot subslot), por lo que, o se tiene la Ram lineal o no va. ¿Cómo solucionan esto los inteligentes? Obviosamente, hay una solución, la explico al final.

b) El juego busca memoria porque la necesita. Imaginemos, de nuevo un 32k. Que necesita 32k de Ram, PARA LO QUE SEA. En el momento que encuentre memoria lo más fácil es que encuentre la memoria donde se está "emulando" el cartucho. ¿Cómo se soluciona esto? De nuevo solo hay una forma
 
c) Juegos de Basic: Emular un ROM de Basic es un infierno. Hay un caso especial donde no se puede emular bien desde RAM.

d) El juego se sobreescribe para evitar que vaya en Ram. ¿Cómo solucionamos esto? De nuevo con la única solución plausible.

Solución, como dije: Parchear el juego. El cargador "superinteligente" de Bifi y Patriek debe de tener una base de datos, hacer un  checksum para saber qué juego es y parchear las zonas conflictivas. Porque hacer algo GENERICO para esto es IMPOSIBLE.

Y además, es que solo hay que ver lo que hace Bifi: Prepara IPSs para que funcionen cno la flash de Padial de todos los juegos. Es lo más lógico y obvio, y está muy bien. Pero... ¿a que no hace un programa "inteligente" que haga eso por si solo en tiempo real cuando carga la Rom? No es que no se pueda hacer, es que, de nuevo, necesita una base de datos, como hace el OPF que si parchea específicamente muchos. Y eso, nenes, es MUCHO CURRO.

Ramones, no estoy de acuerdo contigo con que hacer un cargador superinteligente sea MUCHO CURRO, porque yo diría que es sencillamente ¡Imposible!, y es que no es viable computacionalmente analizar y parchear una ROM en el 100% de los casos con el 100% de efectividad, y para los casos en que se pueda hacer, los recursos propios de un MSX se quedan más que cortos.

Pensad, que ni siquiera es nada trivial, ni siempre resoluble, hacer un algoritmo que dado un programa distinga sin dudas que es datos y que es código, cómo para ponerse además a parchear cada caso particular para cada uno de las posibles soluciones en canto a la distribución de la memoria... Como mucho, se podría hacer una ROM 'loader friendly', estableciendo unas reglas o rutinas estandarizadas para la búsqueda y selección de slots, o que metamos marcas en el código para que el loader sepa qué hacer...

Pero como dice SapphiRe, sería mucho más sencillo tener cuidado a la hora de programar la ROM, o incluso seguiría siendo más sencllo preparar dos versiones del mismo juego, una pensada para ROM y otra para RAM que dejar la responsabilidad en un cargardor.

Saludos

Estamos parcialmente de acuerdo. Analizarlo en tiempo real, es decir, hacer un
programa genérico es imposible. Pero como imposible no hay nada, ya daba la
solución para que sea "posible".


A veces lo más simple es lo más efectivo. Os liais mucho a veces cuando la
solución está delante de nuestros morros.

La solución que proponía, y que *ya es funcional en el OPF (cargador de Roms en
la MegaFlashRom de Pazos), que YA es funcional en el openMSX, y que será
funcional en un cargador de RAM es tan sencillo como tener una BASE DE DATOS.
Algo tan sencillo como leer, por ejemplo los 256 primeros bytes del programa a
cargar, hacer un CRC sencillito (lo tengo hecho) y averiguar si es un juego
"parcheable". Una vez que tienes el juego que es APLICAS el parche
correspondiente al cargarlo. Y eso implica MUCHO CURRO. Y a eso me refería. Que
primero has de saber por qué falla, luego saber arreglarlo (desensambla y
parchea cuando no vas a tener los fuentes), aplicar el cambio y cargar. Y esto
lo multiplicas por cada juego que quieras.

Ya te digo, el propio openMSX lo hace para detectar el mapper de la Rom que
cargas. Lo cual es lo mejor porque es 100% seguro, y no como los programas que
intentan "detectar" el mapper (cómodo para el usuario) que pueden fallar.


Esto no se le puede obligar a nadie. Si alguien hace un juego y el formato es en
ROM, normativa del concurso, ha de pensar que funciona así. Los "dulces" se
pueden hacer... como comenta Fernando, algunos problemas se solucionan de una
manera sencillísima con un mínimo código extra. Otros problemas pueden ocasionar
al programador/es/a/as un quebradero de cabeza y complicar su programa con
extras que se salen de la base: el juego.

Aún así, y como esto va con cada persona, yo lo que he hecho en 8/16/32/48k
siempre ha funcionado en Ram, sencillamente para facilitar los testeos y no
tener que estar continuamente grabandolo en una flash.

En fin, que si alguien se anima a hacer un cargador en Ram de juegos de 8-48k
(como el ODO, ExecRom) y que analice los juegos parcheándolos bien, pues que lo
hagan que saldremos todos beneficiados. A mi no me mireis.

En efecto, a eso iba. Y teniendo la chuleta, para el usuario es igual de sencillo. No tiene que especificar nada de nada, pues al leer la Rom el programa sabe cual es y actúa en consecuencia. De hecho esto es lo que hace la propia Konami para detectar si hay un cartucho en otro slot cuando quieren activar cheats, extras, etc... o el propio Game Master.


Está a medias, pero no completa. Leyendo unos 16k o cosa así, normalmente se puede averiguar el tipo de mapper. Pero no siempre. Y si el mapper es "rarito", tipo R-Type, ya ni de bollo.


Claro que no es inabordable. Pero lleva HORAS y HORAS de chequeos. Y por ejemplo, preparar que todos los juegos del Dev FUNCIONEN con esas utilidades cuando van a salir, ya necesita de que el autor del programa los tenga antes. Y sobre todo sería hasta interesante ayuda por parte de los participantes/programadores.






Exacto! Y aquí es donde yo he ido siempre... ¿cómo comprueban los jueces que funcionan en un MSX? Es complejo, ya digo, porque tienes que tener un buen equipo. Pero me parece una excelente idea que si por un casual un programa no es 100% compatible y tiene problemas, se le pueda aplicar algún punto negativo. Y así premiar a quien hace las cosas como tocan.



Es que, y este es otro problema, me parece que hay demasiada gente que solo juega en emulador. Que realmente ponen 5 minutos el programa, lo ven y lo dejan. Otro de los problemas potenciales del soft gratuito.

Es raro que se le corrompa en el turbo R algo a 60hz, pues ... ah vale... nada, es que el Turbo R mete esperas en el VDP, pero solo cuando está en R800 (creome recordar). Así que el problema es que a 60hz se corrompe algo. Pues tendrías que mirarlo Jon, puesto que si en un MSX2 o superior se corrompe algo a 60hz, en un MSX1 a 60hz será la risa. (no, no lo he podido probar).

También puede ser todo el mismo tema de la pila del que hablamos ya, y puede que te estés machacando tus variables y cosas. Míratelo.

No, no creo que tenga que ver con las transferencias. El problema era que, tras jugar un rato, el tile inferior derecho de la moneda se corrompía, y se quedaba corrupto.