emulation - son - youtube romualdfons




¿Cómo funcionan los emuladores y cómo se escriben? (11)

Los emuladores son muy difíciles de crear, ya que hay muchos hacks (como en efectos inusuales), problemas de tiempo, etc. que necesitas simular.

Para ver un ejemplo de esto, consulte http://queue.acm.org/detail.cfm?id=1755886 .

Eso también le mostrará por qué 'necesita' una CPU de varios GHz para emular una de 1MHz.

¿Cómo funcionan los emuladores? Cuando veo emuladores NES / SNES o C64, me sorprende.

¿Tiene que emular el procesador de esas máquinas interpretando sus instrucciones de ensamblaje particulares? ¿Qué más entra en ello? ¿Cómo se diseñan típicamente?

¿Puede dar algún consejo a alguien interesado en escribir un emulador (especialmente un sistema de juego)?


¿Consejos para emular un sistema real o lo tuyo? Puedo decir que los emuladores funcionan emulando TODO el hardware. Tal vez no hacia el circuito (como mover los bits como lo haría el HW. Mover el byte es el resultado final, por lo que copiar el byte está bien). Los emuladores son muy difíciles de crear, ya que hay muchos hacks (como en efectos inusuales), problemas de tiempo, etc. que necesitas simular. Si una pieza (entrada) es incorrecta, todo el sistema puede fallar o, en el mejor de los casos, tener un error / falla.


Cómo empezaría la emulación.

1. Consiga libros basados ​​en programación de bajo nivel, lo necesitará para el sistema operativo "ficticio" de Nintendo ... game boy ...

2. Obtener libros sobre emulación específicamente, y tal vez el desarrollo. (No estarás haciendo un OS, sino lo más cercano a él.

3. Observe algunos emuladores de código abierto, especialmente los del sistema para el que desea crear un emulador.

4. Copie fragmentos del código más complejo en su IDE / compliler. Esto te ahorrará escribir código largo. Esto es lo que hago para el desarrollo del OS, usar un distrito de Linux.


Cuando desarrolla un emulador, está interpretando el ensamblaje del procesador en el que está trabajando el sistema (Z80, 8080, CPU PS, etc.).

También debe emular todos los periféricos que tiene el sistema (salida de video, controlador).

Debería comenzar a escribir emuladores para los sistemas Simpe como el viejo Game Boy (que utiliza un procesador Z80, no me equivoco) O para C64.


Escribí un artículo sobre la emulación del sistema Chip-8 en JavaScript .

Es un buen lugar para comenzar, ya que el sistema no es muy complicado, pero aún así aprende cómo funcionan los códigos de operación, la pila, los registros, etc.

Estaré escribiendo una guía más larga pronto para la NES.


Habiendo creado mi propio emulador de la BBC Microcomputadora de los años 80 (escriba VBeeb en Google), hay una serie de cosas que debe saber.

  • No estás emulando la cosa real como tal, eso sería una réplica. En cambio, estás emulando al estado . Un buen ejemplo es una calculadora, la cosa real tiene botones, pantalla, estuche, etc. Pero para emular una calculadora solo necesita emular si los botones están arriba o abajo, qué segmentos de LCD están encendidos, etc. Básicamente, un conjunto de números Representa todas las combinaciones posibles de cosas que pueden cambiar en una calculadora.
  • Solo necesita la interfaz del emulador para aparecer y comportarse como si fuera real. Cuanto más convincente es esto, más cerca está la emulación. Lo que sucede detrás de escena puede ser lo que quieras. Pero, para facilitar la escritura de un emulador, existe un mapeo mental que ocurre entre el sistema real, es decir, chips, pantallas, teclados, placas de circuitos y el código de computadora abstracto.
  • Para emular un sistema informático, es más fácil dividirlo en trozos más pequeños y emular esos trozos individualmente. Luego ensarte todo el lote para el producto terminado. Al igual que un conjunto de cajas negras con entradas y salidas, que se presta a la programación orientada a objetos. Puede subdividir aún más estos trozos para hacer la vida más fácil.

En términos prácticos, generalmente se busca escribir para obtener velocidad y fidelidad de emulación. Esto se debe a que el software en el sistema de destino se ejecutará (puede) más lentamente que el hardware original en el sistema de origen. Eso puede restringir la elección del lenguaje de programación, compiladores, sistema de destino, etc.
Además, tiene que circunscribir lo que está preparado para emular, por ejemplo, no es necesario emular el estado de voltaje de los transistores en un microprocesador, pero es probable que sea necesario emular el estado del conjunto de registros del microprocesador.
En general, cuanto menor sea el nivel de detalle de la emulación, mayor será la fidelidad que obtendrá con el sistema original.
Finalmente, la información para sistemas más antiguos puede ser incompleta o inexistente. ¡Así que conseguir el equipo original es esencial o, al menos, diferenciar otro buen emulador que alguien más ha escrito!


La emulación puede parecer desalentadora, pero en realidad es bastante más fácil que simular.

Cualquier procesador normalmente tiene una especificación bien escrita que describe estados, interacciones, etc.

Si no le importaba el rendimiento en absoluto, entonces podría emular fácilmente la mayoría de los procesadores antiguos utilizando programas muy elegantes orientados a objetos. Por ejemplo, un procesador X86 necesitaría algo para mantener el estado de los registros (fácil), algo para mantener el estado de la memoria (fácil) y algo que tomaría cada comando entrante y lo aplicaría al estado actual de la máquina. Si realmente deseara precisión, también emularía las traducciones de memoria, el almacenamiento en caché, etc., pero eso es factible.

De hecho, muchos fabricantes de microchips y CPU prueban los programas contra un emulador del chip y luego contra el propio chip, lo que les ayuda a descubrir si hay problemas en las especificaciones del chip o en la implementación real del chip en el hardware. Por ejemplo, es posible escribir una especificación de chip que podría resultar en puntos muertos, y cuando se produce una fecha límite en el hardware, es importante ver si podría reproducirse en la especificación, ya que eso indica un problema mayor que algo en la implementación del chip.

Por supuesto, los emuladores para videojuegos generalmente se preocupan por el rendimiento, por lo que no usan implementaciones ingenuas, y también incluyen código que interactúa con el sistema operativo del sistema host, por ejemplo, para usar dibujo y sonido.

Teniendo en cuenta el rendimiento muy lento de los videojuegos antiguos (NES / SNES, etc.), la emulación es bastante sencilla en los sistemas modernos. De hecho, es aún más sorprendente que solo puedas descargar un juego de todos los juegos SNES de la historia o cualquier juego Atari 2600, considerando que cuando estos sistemas eran populares, tener acceso gratuito a todos los cartuchos hubiera sido un sueño hecho realidad.


Nunca he hecho nada tan sofisticado como para emular una consola de juegos, pero una vez hice un curso en el que la tarea era escribir un emulador para la máquina descrita en Andrew Tanenbaums Structured Computer Organization . Eso fue divertido y me dio muchos momentos aha. Es posible que desee recoger ese libro antes de sumergirse en escribir un emulador real.


Sé que esta pregunta es un poco vieja, pero me gustaría agregar algo a la discusión. La mayoría de las respuestas aquí se centran en los emuladores que interpretan las instrucciones de la máquina de los sistemas que emulan.

Sin embargo, hay una excepción muy conocida a esto llamada "UltraHLE" ( artículo de WIKIpedia ). UltraHLE, uno de los emuladores más famosos jamás creados, emuló los juegos comerciales de Nintendo 64 (con un rendimiento decente en las computadoras domésticas) en un momento en el que se consideraba imposible hacerlo. De hecho, ¡Nintendo todavía estaba produciendo nuevos títulos para la Nintendo 64 cuando se creó UltraHLE!

Por primera vez, vi artículos sobre emuladores en revistas impresas donde antes solo los había visto en la web.

El concepto de UltraHLE era hacer posible lo imposible mediante la emulación de llamadas a la biblioteca C en lugar de llamadas a nivel de máquina.


Sí, hay que interpretar todo el lío del código de máquina binario "a mano". No solo eso, la mayoría de las veces también debe simular un hardware exótico que no tiene un equivalente en la máquina de destino.

El enfoque simple es interpretar las instrucciones una por una. Eso funciona bien, pero es lento. Un enfoque más rápido es la recompilación: traducir el código de máquina de origen al código de máquina de destino. Esto es más complicado, ya que la mayoría de las instrucciones no se asignarán una a una. En su lugar, tendrá que realizar soluciones alternativas que impliquen código adicional. Pero al final es mucho más rápido. La mayoría de los emuladores modernos hacen esto.