Emulador

Un uso popular de los emuladores es el de imitar la experiencia de los videojuegos de máquinas recreativas o videoconsolas en computadoras personales, o el poder ser jugados en otras videoconsolas. La emulación de videojuegos de sistemas antiguos (abandonware) en las modernas computadoras personales y videoconsolas de hoy día resulta generalmente más cómoda y práctica que en los dispositivos originales. Sin embargo, puede ser requerido a los creadores de emuladores una licencia de software para escribir programas originales que dupliquen la funcionabilidad de la ROM y BIOS del hardware original, lo que comúnmente se conoce como high-level emulation o emulación de alto nivel.

Otro uso común es el de emular sistemas operativos obsoletos, o vigentes para otra máquina o dispositivo, para utilizar programas compatibles con estos sistemas operativos.

En sentido teórico, la tesis de Church-Turing implica que cualquier ambiente funcional puede ser emulado dentro de cualquier otro. En la práctica, esto puede resultar realmente difícil, particularmente cuando el comportamiento exacto del sistema emulado no está documentado y debe ser deducido mediante ingeniería inversa. Tampoco se habla en la tesis sobre las diferencias en sincronización; si el emulador no actúa tan rápidamente como el hardware original, el software de emulación va a ir más lento que si fuese el hardware original.

La mayoría de los emuladores solo emulan una determinada configuración arquitectura de hardware - si el sistema de explotación (o sistema operativo) también se requiere para emular cierto programa entonces ha de ser emulado también. Tanto el sistema de explotación como el programa deben ser interpretados por el emulador, como si estuviese ejecutándose en el equipo original. Aparte de la interpretación del lenguaje de la máquina emulada, es preciso emular el resto del equipo, como los dispositivos de entrada y salida, de forma virtual: si escribir en una región específica de la memoria debe influir en el contenido en pantalla, por ejemplo, esto también debe ser emulado.

En vez de una emulación completa del equipo, una compatibilidad superficial puede ser suficiente. Esto traduce las llamadas del sistema emulado a llamadas del sistema anfitrión.

Los desarrolladores de programas para máquinas con sistemas computarizados y consolas de videojuego comúnmente utilizan emuladores especialmente exactos llamados simuladores antes de ejecutarlos en el equipo real. Esto permite que el programa pueda ser producido y probado antes de que la versión final del equipo para el cual se está desarrollando sea producida en grandes cantidades, de esta forma puede ser probado sin tener que copiar el programa en el equipo, de modo que puedan ser eliminados errores en un nivel bajo sin tener los efectos colaterales de un depurador.^[3]​

Típicamente, un emulador se divide en módulos que corresponden de forma precisa a los subsistemas del equipo emulado. Lo más común, es que un emulador este compuesto por los siguientes módulos:

• Un emulador de la unidad central de procesamiento.
• Un módulo para el subsistema de memoria.
• Varios emuladores para los dispositivos de entrada y salida.

Lo más común es que los buses no sean emulados, por razones de simplicidad y rendimiento, y para que los periféricos virtuales se comuniquen directamente con la UCP y los subsistemas de memoria.

El simulador de la unidad central de procesamiento (CPU) es a menudo la parte más compleja de un emulador. Muchos emuladores son escritos utilizando simuladores de CPU "preempaquetados", para así poder realizar una emulación fiel y eficiente de una máquina específica.

El simulador de CPU más simple sería un intérprete informático, que sigue el flujo de ejecución del código de programación emulado y, por cada instrucción de código de la máquina emulada, ejecuta en el procesador en que se carga, instrucciones semánticamente equivalentes a las originales.

Esto es posible asignando una variable a cada registro y flag de la CPU emulada. La lógica de la CPU simulada puede ser más o menos traducida directamente a algoritmos de software, creando una reimplementación del software que básicamente refleja la implementación original del hardware.

El ejemplo siguiente ilustra el modo en que la simulación de CPU por un intérprete. En este caso, las interrupciones se revisan después de la ejecución de cada instrucción, aunque este comportamiento no es usual en los emuladores en la realidad, por razones de rendimiento.

 void Execute(void) {
     if(Interrupt!=INT_NONE) {
         SuperUser=TRUE;
         WriteMemory(++StackPointer, ProgramCounter);
         ProgramCounter=InterruptPointer;
     }
     switch(ReadMemory(ProgramCounter++)) {
         // Handling of every valid instruction
         default:
         Interrupt=INT_ILLEGAL;
     }
 }

Los intérpretes son muy populares en el caso de los simuladores de CPU, ya que son más sencillos de implementar que otras soluciones alternativas de mejor rendimiento, y su velocidad es más que adecuada para emular computadoras de hace más de una década en máquinas modernas.

Aun así, la penalización de velocidad inherente en la interpretación puede ser un problema al emular computadores cuya velocidad de procesador está en el mismo orden de magnitud que la máquina huésped. Hasta no hace tantos años, la emulación en tales situaciones era considerada impracticable.

Lo que permite el rompimiento de esta restricción son las técnicas avanzadas de recompilación dinámica. Una translación simple a priori del código del programa emulado al código que corre en la arquitectura original es usualmente imposible por varias razones:

• el código puede ser auto modificable
• no existe una forma que distinga de forma confiable los segmentos de información (que no deben ser traducidos) de los segmentos de texto (segmentos de código)
• no existe forma de comunicarse con el sistema operativo emulado para que el emulador reconozca los nuevos códigos cargados (por ejemplo del disco)

Varias formas de recompilación dinámica, incluyendo la popular técnica de compilación en tiempo de ejecución (compilación JIT), trata de bordear estos temas esperando hasta que el proceso de control de flujo se mueva hasta donde esta la parte donde está localizado el código sin traducir, y es solo entonces {"en tiempo de ejecución") cuando los bloques traducidos del código al código anfitrión pueden ser ejecutados.

El código traducido se mantiene en el código caché, y el código original no se pierde ni es afectado; de esta forma, incluso los segmentos de data pueden ser trasladados por el recompilador, resultando solo en un gasto de tiempo de traslado.

La mayoría de los emuladores, como dicho anteriormente, no emulan el sistema principal bus; cada dispositivo de entrada y salida es tratado a menudo como un caso especial, y no existe una interfaz constante para los periféricos virtuales.

Esto puede resultar en una ventaja en el funcionamiento, proveyendo que cada módulo de entrada y salida pueda ser adaptado a las características del dispositivo emulado; diseños basados en un estándar, entradas y salidas unificadas por medio de API pueden sin embargo proveer modelos más simples, y además tienen la ventaja adicional de permitir de forma "automática" la utilización de servicios plugins para proveer dispositivos virtuales de terceros en el emulador.

Las entradas y salidas unificadas por medio de API no necesariamente reflejan la estructura del bus del hardware real: el diseño del bus está limitado por varios parámetros eléctricos y la necesidad del manejo de programación paralela que la mayoría de las veces puede ser ignorada en la implementación del software.

Aún los emuladores que tratan cada dispositivo como un caso especial poseen una infraestructura básica en común para ello:

• manejando interruptores, por medio de procedimientos que fijen banderas legibles por el simulador del CPU siempre que un interruptor sea levantado, permitiendo al CPU virtual "convertir los interruptores (virtuales)".
• escribiendo y leyendo de la memoria física, por medio de dos procedimientos similares mientras este lidia con la memoria lógica (contrario a este último, el anterior puede comúnmente ser echado a un lado, y en su lugar se emplean las referencias directas al arreglo de memoria)

 

Los emuladores arrancan imágenes ROM, o sea el contenido de los cartuchos, disquetes o cintas que se usaban con los sistemas antiguos. Físicamente en las PC las ROM son archivos binarios que se pueden cargar en la memoria. Es decir, el emulador es un programa que hace las funciones de una consola, por ejemplo la Game Boy Advance o una PDA, y la ROM es un archivo que hace de cartucho, CD-ROM, o cinta, por ejemplo Mario Bros..

La emulación puede ser utilizada para obtener una máquina virtual que se ejecuta dentro de otra máquina. Esta máquina virtual puede emular tanto máquinas que existen físicamente como máquinas que solo existen como una especificación (por ejemplo la máquina virtual de Java, la máquina virtual del entorno .NET, Open Firmware o la máquina virtual p-code de Pascal). De esta forma se puede conseguir ejecutar software escrito para una máquina con solo llevar la máquina virtual a cada una de las plataformas..

Los emuladores de videoconsolas son un tipo de emuladores diseñados para emular una o varias videoconsolas y así poder jugar un videojuego diseñado para ser jugado en esta(s). Los emuladores múltiples suelen emular consolas con características similares (por ejemplo MEKA emula todas las consolas de Sega de 8 bits y la Colecovision)

• Emulador de consola
• Imagen ROM
• Virtualización
• Retrogaming

• How To Write a Computer Emulator by Marat Fayzullin

1. ↑ Rodríguez, Luis H. (5 de junio de 2021). «Qué es un emulador digital y para qué puedes utilizarlo». ElDiario.es. Consultado el 21 de mayo de 2022. 
2. ↑ Noguera, Bulmaro (3 de octubre de 2011). «Qué es un emulador y para qué se utiliza». Culturación. Consultado el 18 de agosto de 2022. 
3. ↑ Salgado, Juan José (2000). «Emuladores: Unas herramientas imprescindibles». Mundo electrónico (309): 80-83. ISSN 0300-3787. Consultado el 21 de mayo de 2022.