Hodor escribió:atreyu_ac escribió:Hodor escribió:Yo pondría la mano en el fuego porque el core de ZX Spectrum no es mejor que ZXBaremulator, por poner un ejemplo que se me ocurre a bote pronto. Incluso el core principal de otra FPGA como el Spectrum NEXT se está demostrando no tan compatible como afirmaban sus autores y netamente inferior a emuladores muy sólidos como el que he nombrado o incluso otro con bastante solera como Fuse.
Un saludo.
Meec. Falso. MUY falso. El baremulator no se sincroniza con el vídeo de la Pi, por lo que en los juegos que tienen movimientos "pixel a pixel" este no se ve bien. Estuve intercambiando correos con el autor del baremulator y me dijo que no se podía arreglar tal como está escrito.
Efectivamente. Entonces también sabrás si has hablado con él que FPGAs como ZX-UNO sufren de ese problema incluso en una magnitud mayor que ZXBaremulator utilizando el modo 128KB -desconozco si en modo 48KB ocurre. Por otro lado, ¿el core de Mister pasa correctamente todos los test de instrucciones del Z80? Lo pregunto por simple curiosidad.
Un saludo.
Pues te aseguro que
eso NO es cierto: las implementaciones del ZX Spectrum en FPGA (ZXUNO, MiST, MiSTer... todas las que tengo y he tenido) actualizan la pantalla con la sincronía correcta: es fácil de ver porque no presentan tearing en las secuencias de scroll al píxel, y el Baremulator sí que tiene tearing a dolor.Coge la pantalla del título del Egghead 4 y fíjate en el scroll de las letras, o en las letras del título del Aufwedersen Monty y ahí se ve (aunque hay cientos de juegos más con scroll al pixel en el Spectrum, no sólo esos dos). En las FPGAs va como debe, y en el Baremulator no. Y creeme, me encantaría que funcionase en el Baremulator bien, porque suelo regalar Raspberrys a mis amigos, pero no puedo hacer lo mismo con una MiSTer.
@aranya: Un emulador baremetal (que a mi me la ponen muy morcillona, conste: me vuelve loco el único con el nivel aceptable que conozco, que es el BMC64) no es más que un emulador software sin sistema operativo de por medio, pero sigue siendo una máquina que, mediante software, emula a otra.
Las FPGAs no emulan, sino que implementan. Voy a intentar explicarte la diferencia porque es brutal, de la noche al día, no tiene nada que ver.
Verás. Tenemos que empezar por entender algo sobre cómo funcionan las máquinas que tanto nos gustan: las consolas, ordenadores y arcades retro. Bien: estas máquinas son arquitecturas tremendamente paralelizadas. Mientras la CPU hace algo, el chip de vídeo hace sus cosas, el de audio las suyas, el controlador de I/O las suyas... Sí, se comunican entre ellos, pero trabajan de manera paralela. Quédate con esto: paralelismo.
Ahora vamos a ver las opciones por separado.
-Emulación software sobre un SO decente (RetroArch sobre KMS/DRM en GNU/Linux. Escoria como Windows ni lo considero porque no tiene la infraestructura necesaria para gráficos de baja latencia): Cuando emulamos por software con un sistema operativo moderno de por medio, estamos sujeros a sus miserias y virtudes en cuanto a multiprocesamiento, diferentes procesos y threads, un scheduler que le da la CPU a quien le toque en cada momento en función de un algoritmo... Te lo dice un fanático de GNU/Linux que lo usa todos los días, eh? No es una crítica, yo uso un sistema operativo. Es que es así como funcionan las cosas ahora. Ningún proceso tiene la máquina para sí: tiene rodajas de tiempo de la CPU que el scheduler le da cuando le parece bien (bueno, cuando el algoritmo lo decide).
Decíamos que la máquina emulada era originalmente un sistema con un tremendo paralelismo en su funcionamiento. Te imaginas el desaguisado de implementar eso en software, dentro de un mismo proceso? Los desarrolladores de emuladores lo que hacen al final es irse a línea a línea, o a frame a frame. Dentro de esa línea o de ese frame, el timming no es exacto ni remotamente (no puede serlo, porque no existe una réplica física de la electrónica, sino un programa que hace como buenamente puede lo mismo que esa electrónica, pero a una velocidad mucho menor porque no existe ese paralelismo del que te hablaba). Esto afecta al vídeo, al audio, a la entrada/salida... todo pasa, de ser paralelo en el sistema original a ir "serializado" en el sistema emulado por software. Las consecuencias son conocidas: lag, inexactitud de vídeo y audio inherente a la emulación (no es posible resolverla, aunque se pueden adoptar soluciones de compromiso), etc. En una FPGA puede haber inexatitud, pero se puede resolver con una implementación correcta: es decir, se trata de una inexactitud que no es propia de la FPGA. En la emulación software no es posible en algunos casos.
Alguien dirá que es posible bajar a una exactitud de ciclo a nivel de píxel o por debajo incluso, usando emulación software: sí, posible es. Pero buena suerte con las necesidades de CPU de la máquina para correr eso al framerate original. Es un ejercicio de masoquismo absurdo y de todos modos el jittering del sistema operativo te va a follar el culo salvajemente, así que...
-Emulación software sin SO (el puto amo es el BMC64. El Baremulator si algún día arregla el vídeo igual se me hace tolerable...y creo que poco más hay, por desgracia):
Lo mismo que lo anterior pero como no hay un SO moderno de por medio los recursos de CPU y acceso a RAM son todos para el emulador. Y puede leer los puertos cuando quiera, etc. Way cool! Pero estamos en las mismas en cierto modo: el paralelismo de la máquina original a tomar por culo, toooodo serializado. Por eso aún tienen lag los emuladores baremetal, no se oyen igual, el tacto no es el mismo... Ya me gustaría a mi que no lo tuvieran, joder. Pero mira la tabla que el desarrollador del BMC64 tiene en su web:
https://accentual.com/bmc64/-FPGA: Como lo que hacemos es usar electrónica para implementar electrónica, lo que tenemos es... la máquina original (siempre que la implementación sea correcta, claro: pero eso no es una limitación de la FPGA sino de la implementación. En la emulación teníamos compromisos por ser emulación software). Tenemos la máquina original con su paralelismo y todo. Tal cual. Donde había un contador, ahí hay un contador. Donde había un oscilador, ahí tenemos un oscilador. Etc, etc. Y si la máquina tenía una CPU, dos PPUs y una SPU todo en pararelo, pues ahí está todo corriendo en pararelo de verdad.
A la vez que las PPUs pintan un scanline, se lee el mando por otro lao: simultáneamente, sin esperar a completar la línea ni un frame entero ni pollas. Por eso notas que la máquina tiene el tacto de la máquina original.
Espero que te sirva mi explicación.
PD: Algunas de las cosas dichas aquí no aplican a máquinas "modernetas" con un framebuffer como una PSX. Ahí ya te la pela un poco bastante el paralelismo a nivel de scanline o píxel, porque la PSX va produciendo frames completos. Es otro rollo. Hablo de máquinas como SNES, MegaDrive, NeoGeo, Amiga, Spectrum...