Bone escribió:mcleod_ideafix escribió:...lo malo es que es lo que el 99% de la gente percibe, pero no es esa su misión real.
Bueno, la verdad es que no se para que sirve un emulador de un hard obsoleto si no es para hacer correr el software que antes hacia correr. Si ese software resulta que son juegos con copyright, pues entonces si no se tiene licencia, pues nada.......a usarlo solo con ROMS libres o lo que sea. Pero creo que has sido un poco benevolo con ese 99%, yo mas bien diria que es un 99,9%.
No fui yo quien dio la cifra del 99%, sino Haze, aunque coincido contigo en que está más próxima al 99,9% que al 99%. Debo ser de ese 0,1% que sí ha entendido MAME como un proyecto de preservación y documentación exhaustiva de esa tecnología. Por supuesto, para probar que dicha preservación se ha hecho correctamente, el emulador debe ser capaz de ejecutar el software de la misma forma que lo haría la placa original, pero reitero que es un efecto secundario, no es la misión principal de MAME.
Si "jugar a juegos antiguos" fuera la meta principal de MAME...
- No incluirían drivers que no funcionan, es decir, drivers que emulan parcialmente un hardware y que no consiguen botar la ROM del juego en cuestión.
- No verías cambios en el dumpeado de las ROM's de cada juego cada dos por tres.
- MAME tendría desde el principio de los tiempos una interfaz más amigable para poder ser usada de forma sencilla, en lugar de una ristra de opciones en la línea de comandos.
- Opciones como mostrar la paleta (¿F4?) no estarían, porque no tendrían sentido para el usuario "gamer".
En cambio, todo lo anterior casa con un proyecto cuya meta principal es la preservación:
- Mejor documentar y dejar en el proyecto un hardware, aunque sea parcialmente conocido. Mejor algo que nada.
- Cualquier cosa que en la placa original se hiciera con chips programados (ROMs, PLAs), debe implementarse en MAME emulando dichos chips, por lo que se necesita su dumpeado, en lugar de meter en el código del driver el comportamiento del chip. Esto es: placas que tienen por ejemplo las ROMs encriptadas, a menudo se sabe como desencriptarlas porque se conoce el algoritmo, o la clave de encriptación es pública, etc, y en el propio driver se incluye el código para que se haga de forma transparente. Más tarde resulta que la ROM que guarda las claves de encriptación, o la PLA que implementa dicha desencriptación es dumpeada y entonces se cambia el fichero ZIP de la placa para incluir esos dumpeados, y se cambia el driver para que no haga emulación de la desencriptación, sino que o bien ejecute el código de desencriptado en ROM, o bien emule la circuitería de la PAL. Entonces resulta que la nueva versión de MAME, para ese juego, necesita un vocado nuevo con más chips.
- Todo lo que sea "eye candy" para usar MAME no es tarea de un proyecto de preservación. Es más: se dice que "la mujer del César no sólo ha de ser decente, sino parecerlo". Esto es: si tú quieres tener a empresas como CAPCOM, Konami, Bally Midway, etc, tranquilas, más te vale que quede claro que no has hecho un programa "para jugar a juegos", así que tu programa no debería dar todas las facilidades y asistentes del mundo para jugar a esos juegos.
- Todas las opciones para mostrar el estado interno de la máquina, la paleta, el modo de servicio, etc, tienen sentido en un proyecto de preservación.
Yo de hecho veo a MAME como una gran enciclopedia, donde cada driver, cada juego, es un tomo. Si sabes leerlo, es como leer el esquemático de la placa, su forma de uso, el datasheet de sus componentes, etc. El código, por ejemplo, del AY-3-8912, después de revisiones y mejoras, se ha convertido en un referente no sólo para la emulación en otros sistemas, como emuladores de Spectrum, sino a la hora de implementar por hardware un clon del chip. Cosas tan sutiles como un cambio en un coeficiente del polinomio del generador de números aleatorios que genera el ruido blanco del canal de ruido del AY han hecho en el pasado que la gente dijera "mmmm, no suena como el original", hasta que han dado con la tecla (¡y con el polinomio!).
Opino que una preservación 100% fidedigna debería desembocar no en un driver de emulador, sino en una descripción a nivel RTL. Pero una descripción de ese calibre dejaría fuera de lugar a un montón de gente que no podría participar añadiendo sistemas, y necesitaría un hardware muy específico para poder probar que la descripción es correcta (o un superordenador que fuese capaz de correr una simulación de esa descripción en un tiempo razonable). En este sentido, la emulación como soporte para la documentación está más que justificada, aunque a veces necesite de "workarounds" para que funcione decentemente en PC's "de andar por casa".
