Pregunta para los desarrolladores de emuladores...

Pues eso, una duda que tengo.

Pongamos que hago desde cero un emulador de, digamos, SNES. Para emular via software el viejo hardware de la consola, tendré que saber (perogrullada) cómo funcionan, qué hacen, sus chips. Por ejemplo, el DSP. Así que, para empezar a emular el DSP... ¿tiro de las implementaciones que ya existen de él? ¿Hago ingeniería inversa desde 0? ¿Tiro de documentación, y lo voy implementando?

Seguramente será una gilipollez, pero es una duda que me surge ante la sensación que tengo de que el Mario Kart, en todos los emuladores que lo he probado, no corre EXACTAMENTE IGUAL que como lo recuerdo en la consola. No sabría decir qué es, pero no lo veo igual.

En fin, iluminadme, plis.
Lo mejor sería que le preguntaras a alguno de los creadores de los mejores emuladores, y les pidas documentación para empezar por tu cuenta, ellos son los que suelen tener bibliotecas de los procesadores. Mirar el código fuente es fácil, pero no te suele explicar demasiado los detalles, aparte que es muy fácil caer en la tentación de copiar/pegar sin enterarte de nada. Hay muchos sitios donde conseguir documentación de estos chips, mame solía ser un buen sitio para mirar también.

En el caso del DSP1 (el del mario kart), la mayoría de los procesadores están basados en alguna arquitectura conocida, y en este caso está basado en unos procesadores de nec conocidos: los uPD77C25/uPD96050 , que son unos procesadores con una bootrom (bios) propia y una interfaz para leer operaciones/datos y escribir resultados.

En este caso hay dos formas de emularlo:
- Ver cuales son las operaciones que se pedían y emular el resultado. Esto se suele llamar "High level emulation" (HLE), y consiste en desensamblar la rom, ver las escrituras en las direcciones que corresponden al DSP1, y averiguar para qué se usaban. Me suena de algún tutorial de programación de DSP1 que ayuda en esto, pero ahora no caigo.

- Emular el DSP como un procesador más, para lo que necesitas esa bios que está guardada dentro. Hay documentación de los procesadores nec suficiente para hacerse una idea, así que desensamblas la bios, interpretas las instrucciones y luego implementas el DSP. O bien lo implementas como un procesador completo con una zona de memoria para esta bios cargada desde fichero, o con pseudo instrucciones que hagan directamente el trabajo (normalmente eran multiplicaciones) al estilo HLE.

En tu caso, dices que el Mario kart "no va igual". ¿Qué emulador usas?¿Estás seguro que es problema del DSP, y no de otros chips, que haya input lag....etc? Si no lo has usado, prueba el higan, es el que mejor emula la snes. Utiliza el timing correcto para todo, y emula en base a las bios de los procesadores que usaban esos cartuchos, por lo que necesitarás las roms de los dsp además de la rom del mario kart.
Poco hay que añadir a lo comentado por nuvalo (en plan resumen claro, el tema daría para cientos de páginas), sólo diré que para lo del SMK pruebes en higan, es un emulador cycle accurate, si tu PC no tiene problemas para moverlo, lo que verás es exactamente lo mismo que saldría de una SNES, bueno, siempre que lo saques del mismo modo, ya que si lo que estás es jugándolo en un monitor actual de ordenador es normal que notes mucha diferencia, en su día en SNES jugabas en una CRT.
Depende del cafe que hagas

- si esta fuerte porai se te da por ingenieria inversa

- si es con leche y azucar, buscas documentos tecnicos u codigo de otros emuladores, e implementas en base a eso

- Si te preparastes una taza de leche con miel, agarras el codigo de otro emu, y lo implementas en tu emulador


Eso claro, hablando de chipsets que sepas no existen librerias 100% fiables que puedas implementar sin tener q recurrir a usar/revisar/robar codigo, no te vas a poner a reinventar la rueda para emular el 68000, cuando existen ya emus mas que probados que funcionan perfectos


El año pasado rescribi el bloque del cpu TLCS-900H del emulador de neogeo pocket para PSP en ensamblador, y basicamente lo que hice fue ir haciendo debug del codigo en C, viendo los resultados, e implementando los mismos en asm

Por un lado, me fue mas facil, por otro lado, errores presentes en la emulacion original siguen estando, ademas de que al ser yo humano, habre metido la pata generando nuevos bugs

Si quisiera haber echo el trabajo de la mejor manera posible, me fiaba de datashets originales si estan o de ingenieria inversa... paso de ese curro para un emu que usare yo y cuatro gatos locos

Cada emu, sera diferente en ciertos aspectos de la emulacion, incluso usando mismas librerias, todo depende como se implementen
podrias indicar que emulador estas usando, pues hay distintos tipos de emuladores, estan los emuladores speed-accurate, que son los más comunes, estos son desarrollados pensando en obtener el mejor framerate y compatibilidad posible a base de hacks de velocidad y configuraciones especiales para los juegos con efectos o chips poco comunes o con rutinas de procesamiento muy pesadas, generalmente estos emuladores corren muy bien en equipos modestos, pero al no ser 100% exactos a la maquina que se emula, puede que no todos los efectos de los juegos sean como los originales, o haya juegos que tengan errores graficos o de timing, o simplemente haya juegos que no corran en dichos emuladores, ejemplos de estos en snes son el Zsnes y el snes9x.
Por otra parte estan los emuladores cycle-accurate que buscan emular una maquina a la perfeccion, ya sea soportando todas las intrucciones de un procesador, efectos graficos, sonido y chips especiales, incluso emulando los bugs de hardware, un emulador de este tipo te entraga lo mismo que haria una consola real, el problema es que emular fielmente una maquina requiere un alto proder de procesamiento, incluso en maquinas antiguas como la snes, un ejemplo es el emulador higan/bsnes, que emula una snes al 100%, pero requiere un pc potente para que vaya a un framerate original
Hay emuladores que han liberado el codigo fuente. Entre eso y la documentación "oficial" que hay por ahí para muchas consolas, ya tienes para empezar.
No voy a desarrollar un emulador. Joder, sería incapaz de desarrollar ni siquiera el emulador de una calculadora de bolsillo. Mi duda proviene de lo que dije antes del Mario Kart. Seguramente sean pajas mentales mías, pero el caso es que ahora tengo una SNES conectada a la tele (cable RGB), y el emulador snes9x_next en una raspberry. Juego uno, juego al otro... y NOTO algo. Menos suavidad en las rotaciones, diferente velocidad, distintas inercias. No lo se, solo se que la sensación es diferente, y se de lo que hablo pues le habré dedicado CIENTOS de horas al original en consola, cuando salió y a lo largo de 24 años.

Es por ello que pensé: joder, si un tío un día se curró la implementación del DSP para, digamos, el emulador ZSnes (pongamos, ya que fue el primero que recuerdo que pudo emular el Mario Kart allá por el año 1997), quizá a lo largo de los años todos los demás emuladores han "tomado prestado" el código de aquel, con sus aciertos y sus fallos. Yo que se.

Pues eso. Muchas gracias a todos, son unas respuestas cojonudas. He aprendido horrores.
Es que te pasan dos cosas, la primera que imagino que de la raspberry estás sacando por hdmi a una TV, con todo lo que eso significa (input lag de la TV, que la raspberry vaya justa si le aplicas filtros de escalado, lo mal que se ve en hd si no le aplicas ningún filtro, etc.), y lo segundo, que el snes9x tuvo su momento, nos dio muchas horas de diversión, pero está claramente superado, ahora ya sólo se usa en equipos de baja potencia (como PCs con más de una década o raspberry y similares).

Si pruebas el higan en un PC sacando 15khz a una tv CRT y pones al lado la SNES con el juego verás que son idénticos pixel a pixel.
7 respuestas