Cerrado . Esta pregunta está
basada en opiniones . Actualmente no acepta respuestas.
Comentarios
Respuesta
Una ventaja que los emuladores de FPGA generalmente comparten con el hardware clásico es la capacidad de usar dispositivos que interactúan con el hardware de formas que dependen mucho del tiempo. Por ejemplo, si uno tiene un cartucho de juego para NES que desencadena una interrupción cada vez que se recupera la primera línea de datos de un objeto en particular, una consola que lee el contenido de un cartucho y luego lo emula solo podría jugar el juego correctamente si fuera capaz de reconocer lo que el cartucho estaba haciendo con la línea de interrupción.
El hardware basado en FPGA generalmente funcionaría tan bien como, si no más más confiable que el hardware clásico, pero hay algunas peculiaridades extrañas a tener en cuenta. Algunos prototipos de cartuchos de expansión para el Atari 2600, por ejemplo, se basaron en el hecho de que incluso cuando el NMOS 6502 está tratando de elevar el bus de datos, es incapaz de esforzarse lo suficiente como para dominar un dispositivo externo que intenta tirar de la línea hacia abajo, ni dañarse en el intento. Tenga en cuenta que lo contrario no es cierto: un dispositivo NMOS que intenta tirar de una línea hacia abajo mientras un dispositivo externo la tira hacia arriba puede dañarse a sí mismo en el intento (RIP 2600jr). Si se conectara a un sistema de recreación moderno un dispositivo NMOS que dependiera de la capacidad de saturar los cables del bus, y el sistema no limitara la corriente de excitación del lado alto en esos cables, podría dañar el dispositivo externo. Yo no No sé hasta qué punto eso sería un problema, pero dado que los dispositivos que dependen de tales técnicas probablemente sean raros, sería muy desafortunado si se dañaran.
Otro problema potencial es que los dispositivos electrónicos antiguos se a menudo bastante lento para responder a las señales, lo que significaba que si un dispositivo emitiera una señal muy brevemente por un cable, probablemente sería ignorado. Algunos dispositivos electrónicos antiguos a veces emiten breves pulsos de falla si alguna combinación de entradas cambia entre un estado donde la salida debería ser baja y un estado diferente donde la salida debería ser baja. Si una recreación FPGA no está diseñada para ignorar tales pulsos, pueden causar un funcionamiento erróneo en el hardware recreado aunque no hubieran causado ningún problema en el original.
Personalmente, creo que las FPGA son la mejor manera de sistemas de recreación. El hardware clásico es genial, pero la confiabilidad a menudo es problemática. La emulación de software puede funcionar bastante bien, pero se limitará a interactuar con el hardware que el diseñador del emulador conoce. Una buena recreación basada en FPGA puede interactuar con casi cualquier tipo de hardware, incluidos los dispositivos de los que el diseñador de FPGA no sabe nada , a la vez que ofrece una mayor fiabilidad que el hardware antiguo.
Respuesta
Prefacio: La pregunta parece pedir opiniones, como es opinión si alguien acepta una emulación, no importa si el software está en una CPU o en una FPGA, es lo mismo que el real o no.
Pregúntese, es conducir un automóvil de tecnología moderna mejorado para lucir como un SSK lo mismo que conducir un vehículo real? ¿Quieres conducir un BMW de la década de 1950 con todos sus sonidos, olores y vibraciones (y todos los retoques necesarios para que siga funcionando) o una bicicleta eléctrica 2020 hecha para parecerse a una, que te brinda el sonido clásico de un iPod integrado? ?
Me pregunto cuáles son las diferencias entre usar un hardware real, emuladores de hardware basados en FPGA como MiSTer y la gran cantidad de software emuladores para diferentes sistemas que se ejecutan en computadoras modernas con Windows, MacOS y Linux.
Si solo es un usuario, convencido de usar su teclado y mouse modernos manejando alguna imagen, que parece 640 x 400, en su pantalla 4k, entonces el software es todo lo que necesita. Ya una versión FPGA será excesiva, ya que usa los mismos dispositivos modernos.
Por otro lado , si la imagen no es suficiente, pero quiere sentir el voluminoso mouse Atari, el ondulante teclado Amiga o el voluminoso joystick C64, todos presentados con un verdadero resplandor CRT, entonces no hay otra manera y obtener lo real.
Una cosa que me vino a la mente es que tanto los emuladores de software como los de hardware podrían no ser lo suficientemente precisos
A estas alturas lo son. en todos y cada uno de los detalles. El hardware moderno es lo suficientemente rápido como para permitir el uso del software HLL para adquirir la sincronización exacta del ciclo. Especialmente cuando de todos modos se emula todo en y salida, mapeado a dispositivos modernos.
Pero esto me parece algo que depende de la calidad de la implementación que puede varían entre diferentes emuladores y mejoran con el tiempo debido a la corrección de errores, pero no como un problema fundamental.
La programación y el mantenimiento perezoso no invalidan el enfoque. Para todos los propósitos, excepto las manos reales en el hardware, no hay diferencia.
También escuché sobre el problema de latencia con los emuladores de software, pero «Me sorprende un poco que algo como esto realmente se pueda sentir en una computadora que probablemente sea millones de veces más rápida que la máquina emulada.
Tal vez cien veces, en todo caso. Tenga en cuenta que la mayoría de los componentes principales no se han acelerado tanto, y la mayor parte ha sido consumida por dispositivos de mayor tamaño y necesidades de datos.
El problema de la latencia es algo que ha existido desde siempre. Siempre habrá alguien que diga que puede ver / sentir la diferencia. Si bien esto puede ser cierto en algunas situaciones muy dedicadas, la mayor parte del tiempo es una tontería. Afirmar que se siente unos microsegundos, cuando probar un joystick ya puede costar más es simplemente una fantasía.
¿Existe realmente una razón técnica para preferir la emulación basada en hardware real o FPGA frente a la emulación de software?
¿Qué constituye una razón técnica? ¿Para ti? En sí mismo, el término no es claro al comparar diferentes implementaciones completas.
o esto es solo una cosa de nostalgia, causada por el deseo de llenar como tú ¿Están realmente de vuelta en los 80 o 90?
¿Alguna vez se ha sentado frente a una de las máquinas antiguas? Es sorprendente cómo diferentes teclados se sienten al dejar el equipo estandarizado de hoy.
Y luego, por supuesto, está el retoque del hardware, no es realmente divertido con los emuladores, ya que aquí agregar una interfaz es simplemente agregar unas pocas líneas de código – o simplemente configurati en algunos casos. Sin diseño, sin grabado, sin soldaduras y especialmente sin maldiciones ni parches hasta que funcione.
Responder
Me gustaría aclarar el término «emulación FPGA» mencionado en la pregunta.
Primero, por supuesto que existe la emulación de software. Tomemos como ejemplo algunos (más o menos) emuladores de software exactos de la CPU 6502 . Intentan emular todos los artefactos externos de la CPU real, como el número de ciclos por cada comando, las direcciones de los accesos a la memoria e incluso el «estado interno» (en lugar de sólo el estado de los registros visibles por software). Sin embargo, no tiene nada parecido con la CPU real, comenzando desde el punto en que es pura cuestión de software, no de dispositivo de hardware.
Cuando se descubre cualquier característica nueva del 6502 real (como nuevos códigos de operación o banderas o detalles de ejecución indocumentados ), se inserta en el emulador de software como «otra característica a implementar». Ninguna característica de lo real aparecería en el emulador de software, si son desconocidas para el implementador.
Entonces veamos los núcleos HDL compatibles con 6502.Ahora en realidad representan un dispositivo lógico digital real, o un modelo de eso (en el caso de que el HDL sea simulado, no implementado en el hardware real como FPGA o ASIC). Ahora tienen almacenamiento flipflop (o pestillo) real para los registros de la CPU, podrían implementar señales de bus de CPU reales e incluso insertarse en la computadora retro en lugar del 6502 original. Sin embargo, están hechos (más o menos) «desde cero», con las especificaciones de la CPU que pretenden reemplazar, no su estructura interna. Y, sin embargo, carecerían de características no descritas en esas especificaciones, que existen en la CPU retro real, pero aún son desconocidas para el implementador.
Otro nivel de la reconstrucción podría ser el diseño HDL construido de la siguiente manera:
- La CPU retro real se descarta y se fotografía
- luego se recrea la lista de redes y los esquemas a nivel de transistor (ya sea a mano o con algunas herramientas más o menos automatizadas)
- netlist se convierte a los esquemas de nivel de puerta y luego a la descripción HDL, que a su vez se implementa en FPGA o ASIC.
A diferencia de los casos anteriores, ahora casi todas las características de la CPU real se implementan «de forma nativa», porque la estructura del HDL resultante es más o menos equivalente a la estructura del objeto real (a nivel de puertas lógicas y flipflops).
Aún podría haber problemas, por ejemplo 6502 tiene algunas instrucciones que se comportan de manera errática y siento que tal comportamiento no surgiría en HDL de forma natural.
En términos generales, considero er todo lo que está arriba de la «ingeniería inversa, luego recrear HDL» es en realidad una emulación , ya sea en software o hardware, mientras que la última forma es no .
En otras palabras, consideremos la preservación del software antiguo. Podríamos ejecutarlo en hardware actual, pero si no está disponible, los emuladores de software entran en juego, sin embargo, la antigua pieza de software para la que están acostumbrados a ejecutar sigue siendo exactamente la misma.
Ahora nos gustaría preservar la vieja pieza de hardware (CPU), pero su implementación auténtica no está disponible, así que la recreamos usando tecnología más nueva, pero la estructura lógica de la CPU sigue siendo exactamente la misma.
Respuesta
Para ofrecer una respuesta a la pregunta de latencia únicamente, como autor del emulador:
Abundan las excepciones, pero la regla general sobre el hardware original de los años 80 y en principios de los 90 es que los cambios de entrada del teclado y el joypad pueden ser detectados por el hardware casi inmediatamente después de que sucedan, y que cuando el video y el audio salen de la máquina, llegan al usuario casi de inmediato; por ejemplo, para un televisor CRT clásico, el nivel del raster que está pintando ahora es casi la salida en vivo de la máquina.
Con el hardware ahora, la entrada generalmente atraviesa es una pila de Bluetooth o USB, que puede ser inspeccionada solo en un cierto intervalo por el sistema operativo host, y si algo ha sucedido, se lo comunica al proceso interesado, lo que puede suceder o no de inmediato según el programador específico.
Muchos emuladores también implementan un bucle principal que se parece a cómo se podría diseñar un juego:
- recopilar toda la entrada más reciente y reenviarla a la máquina emulada;
- ejecutar la máquina para un marco;
- pintar el siguiente marco de salida en un búfer invisible;
- ponerlo en cola para mostrarlo en el siguiente vsync y bloque;
- repetir.
Por el bien de la argumentación, imagine que su máquina moderna es muy rápida y que los pasos 2 y 3 son instantáneos. Luego:
- hay un promedio de medio marco de latencia de entrada más cualquier señal de Bluetooth / USB y el sistema operativo agregado; cualquier entrada que ocurra justo después de la parte superior de un marco no se reenviará hasta el comienzo del siguiente, todo lo que ocurra justo al final se comunicará casi en el momento adecuado, y el rango de latencias intermedias es lineal, por lo que el promedio está a la mitad; y
- hay un marco adicional fijo de latencia de salida porque publica un marco para la presentación en el próximo vsync y luego espera hasta que sea el momento de mostrarse.
Entonces, con ese bucle simple, en hardware ideal, en el caso promedio, el retraso entre que presiona algo y la pantalla reacciona es alrededor de 1.5 cuadros más que el hardware real. Y eso es solo si las máquinas host y emuladas se ejecutan a la misma velocidad de cuadros .
Los puristas argumentan que algunos juegos originales están tan finamente ajustados, después de la cantidad apropiada de horas probando y ajustando en el día, que 1.5 cuadros los pone en una desventaja que pueden detectar.
Los FPGA suelen ser * emulación, sin importar cómo se vendan, porque normalmente son una persona que vuelve a implementar una especificación en un lenguaje de descripción de hardware de alto nivel. Pero buscan omitir la mayor cantidad posible de esa latencia: una de buena calidad omitirá el almacenamiento en búfer de video por completo, ejecutará el resto del sistema en tiempo real y enviará la entrada con un retraso mínimo.
* calificación agregado según la corrección proporcionada por @lvd a continuación. Vea su respuesta para más color.
Por supuesto, no es difícil solucionar la mayoría de los problemas de software en el software:
- reenviar la entrada con más frecuencia;
- no use vsync para activar una nueva salida a vsync; y
- no utilice un búfer doble.
In extremis, incluso puede competir con el ráster para obtener una latencia de salida similar a una FPGA, si ya tiene un alto -bucle de frecuencia para entrada frecuente, y si el hardware base soporta cualquier tipo de salida que pueda producir desgarro de pantalla, entonces tienes las herramientas.
Desafortunadamente, estos enfoques no eran usualmente tomados por emuladores en el pasado, especialmente antes de que la latencia se convirtiera en un tema tan ampliamente discutido, y algo de una imagen negativa se haya quedado.
Comentarios
Respuesta
Muchos aspectos de HW vs SW han sido cubiertos por otras publicaciones aquí, así que lo haré no tocarlos. En cambio, me gustaría explicar el problema de LATENCY desde mi punto de vista junto con la experiencia que adquirí durante la codificación de mis emuladores para varias plataformas …
Hacer un emulador de SW en máquinas modernas es mucho más difícil desde el punto de vista de la latencia que en los tiempos de acceso directo de E / S. Para las computadoras domésticas y las consolas de juegos, necesitamos simular / emular el sonido, la salida visual y la entrada del usuario con la mayor precisión posible. El mayor problema es el sonido. Esto se debe a que nuestra audición es mucho mejor que la de cualquier otro de nuestros sentidos y podemos sentir / escuchar la diferencia si el sonido está apagado incluso por unos pocos ms o Hz. Si la pantalla está apagada por 1 o 2 cuadros no podemos ver la diferencia. Además, si la entrada se retrasa un poco, está bien (para la mayoría de los humanos).
En la arquitectura de máquina moderna, todo está almacenado en búfer (especialmente sonido). Por lo tanto, para generar sonido, debemos crear un PCM datos que se envían al chip de sonido y se reproducen a través de DMA + DAC . Para hacer esto, generalmente se utilizan 2 búferes circulares o muchos pequeños búfer lineales. Ahora, para producir sonidos sin fallas, los búferes deben ser lo suficientemente grandes. Por ejemplo, en Windows, la última vez que verifiqué WAVEOUT necesita al menos 20-80 ms. DirectSound necesita >400 ms
Ahora, si el programa emulado se ajusta la salida de sonido se emitirá solo después de que se reproduzca el sonido ya solicitado.
Lo mismo ocurre con la entrada de E / S en algunas plataformas, por lo que los retrasos se suman.
Cuando usa FPGA entonces tiene acceso directo a la salida de sonido sin ningún búfer. Lo mismo ocurre con la entrada.
Sin embargo, la latencia de entrada del juego (teclado, joystick) no suele tener nada que ver con la latencia del sistema host . La causa habitual es que la mayoría de los emuladores utilizan tics de reloj para mantener las velocidades emuladas. Así que simulan la CPU o lo que sea y una vez alcanzado el número deseado de relojes simulados por tiempo, duermen hasta que se emita el siguiente temporizador o lo que sea. Cuanto más rápida sea la computadora host, menor tiempo necesitará para emular, por lo tanto, la simulación no reaccionará la mayor parte del tiempo real.
Por ejemplo, supongamos que nuestra simulación puede ejecutarse 100 veces más rápido que la velocidad original de la computadora emulada. Eso significa que solo el 1% del tiempo la simulación está haciendo algo y el resto es solo Sleep(). Durante el sueño, la emulación no puede responder a nada. Por lo tanto, puede perder pulsaciones de teclas, clics de disparo, etc. Para remediar que algunos emuladores pueden usar el almacenamiento en búfer nuevamente, lo que lleva a la latencia en lugar de ignorar la entrada. También hay diferentes estilos de control del tiempo que eliminan por completo este problema. Para obtener más información sobre este tema, consulte:
Responder
Las máquinas NTSC antiguas (y Macs CRT, etc.) pueden cambiar su salida de gráficos en medio de la actualización de la pantalla CRT (parcialmente hacia abajo del ráster vertical), rompiendo así la imagen en respuesta a la entrada en tiempo real.
Los emuladores que usan monitores que no son CRT no pueden hacer eso en tiempo real, y solo pueden simular un ráster rasgado al siguiente marco o campo.
Y la única forma de probar si una emulación es precisa en comparación con el hardware antiguo real (verdad fundamental). Vea si hay trampas lógicas ocultas no documentadas (defusión, etc.) o errores de diseño analógico en las distintas capas del chip ASIC.
Comentarios