Quels sont les avantages / inconvénients de lutilisation de matériel rétro par rapport à lémulation FPGA par rapport à lémulation logicielle? [fermé]

Un avantage que les émulateurs FPGA partagent généralement avec le matériel vintage est la possibilité dutiliser des périphériques qui interagissent avec le matériel de manière très dépendante du timing. Par exemple, si lon a une cartouche de jeu pour le NES qui déclenche une interruption à chaque fois que la première ligne de données pour un sprite particulier est récupérée, une console qui lit le contenu dune cartouche puis lémule ne pourra jouer correctement au jeu que si elle était capable de reconnaître ce que la cartouche faisait avec la ligne dinterruption.

Le matériel basé sur FPGA fonctionnerait généralement aussi bien, sinon plus fiable que le matériel vintage, mais il y a quelques bizarreries à garder à lesprit. Certains prototypes de cartouches d’extension pour l’Atari 2600, par exemple, reposaient sur le fait que même lorsque le NMOS 6502 essayait de mettre le bus de données à un niveau élevé, il était incapable d’essayer suffisamment de maîtriser un périphérique externe qui essaie de tirez la ligne bas, ne vous endommagez pas lors de la tentative. Notez que linverse nest pas vrai: un périphérique NMOS qui tente de tirer une ligne vers le bas alors quun périphérique externe le tire vers le haut peut sendommager lors de la tentative (RIP 2600jr). Si lon devait brancher dans un système de loisirs moderne un appareil NMOS qui reposait sur la capacité de surmultiplier les fils de bus, et que le système ne limitait pas le courant dentraînement du côté haut sur ces fils, cela pourrait endommager le périphérique externe. Je ne le fais pas. Je ne sais pas dans quelle mesure ce serait réellement un problème, mais comme tous les appareils qui reposent sur de telles techniques sont probablement rares, il serait très malheureux quils soient endommagés.

Un autre problème potentiel est que lélectronique vintage était souvent plutôt lent à répondre aux signaux, ce qui signifiait que si un appareil sortait très brièvement un signal sur un fil, il serait probablement ignoré. Certains appareils électroniques dépoque produiraient parfois de brèves impulsions de pépin si une combinaison dentrées changeait entre un état où la sortie devrait être basse et un état différent où la sortie devrait être basse. Si une récréation FPGA nest pas conçue pour ignorer de telles impulsions, elles peuvent provoquer un fonctionnement erroné sur le matériel recréé même si elles nauraient causé aucun problème sur loriginal.

Personnellement, je pense que les FPGA sont le meilleur moyen Le matériel vintage est cool, mais la fiabilité est souvent problématique. Lémulation logicielle peut fonctionner assez bien, mais se limitera à linterfaçage avec le matériel que le concepteur de lémulateur connaît. Un bon jeu basé sur FPGA peut sinterfacer avec presque nimporte quel type de vintage matériel, y compris les périphériques dont le concepteur FPGA ne sait rien , tout en offrant une meilleure fiabilité que le matériel vintage.

Préface: La question semble demander des opinions, car cest une opinion si quelquun accepte une émulation, peu importe si le logiciel sur un processeur ou sur un FPGA, identique ou non à la vraie chose.

Demandez-vous, conduit une voiture de technologie moderne soutenue pour regarder comme un SSK la même chose que conduire la vraie chose? Voulez-vous conduire une BMW des années 1950 avec tous ses sons, odeurs et vibrations (et tout le bricolage nécessaire pour le maintenir) ou un vélo électrique 2020 conçu pour en ressembler à un, vous donnant le son classique dun iPod intégré ?

Je me demande quelles sont les différences entre lutilisation dun vrai matériel, des émulateurs matériels basés sur FPGA comme MiSTer et la grande quantité de logiciels des émulateurs pour différents systèmes fonctionnant sur des ordinateurs Windows, MacOS et Linux modernes.

Si vous « êtes juste un utilisateur, convaincu dutiliser votre clavier moderne et votre souris moderne gérer une image, qui ressemble à 640 x 400, sur votre écran 4k, alors le logiciel est tout ce dont vous avez besoin. Déjà une version FPGA sera exagérée, car elle utilise les mêmes appareils modernes.

Dun autre côté , si limagerie ne suffit pas, mais que vous voulez ressentir la souris Atari encombrante, le clavier Amiga ondulant ou le joystick C64 encombrant, le tout présenté avec un véritable reflet CRT, alors il ny a pas dautre moyen e une chose qui me vient à lesprit.

Une chose qui mest venue à lesprit est que les émulateurs logiciels et matériels pourraient ne pas être assez précis

Ils le sont maintenant. dans chaque détail. Le matériel moderne est suffisamment rapide pour permettre lutilisation du logiciel HLL pour acquérir la synchronisation exacte du cycle. Surtout quand tout est émulé et la sortie est de toute façon émulée, mappée sur des appareils modernes.

Mais cela me semble être quelque chose en fonction de la qualité de limplémentation qui peut varient entre les différents émulateurs et s’améliorent avec le temps en raison de la correction de bogues, mais pas en tant que problème fondamental.

La programmation et la maintenance paresseuses n’invalident pas l’approche. Dans tous les cas, à lexception de la pratique matérielle, il ny a pas de différence.

Jentends également parler du problème de latence avec les émulateurs logiciels, mais je « je suis un peu surpris que quelque chose comme ça puisse vraiment être ressenti sur un ordinateur qui est probablement des millions de fois plus rapide que la machine émulée.

Peut-être cent fois, le cas échéant. Gardez à l’esprit que la plupart des principaux composants n’ont pas été aussi rapides – et la plupart ont été absorbés par des appareils de plus grande taille et des besoins en données.

Le problème de latence est quelque chose qui existe depuis, comme toujours. Il y aura toujours des affirmations quils peuvent voir / sentir la différence. Bien que cela puisse être vrai dans quelques situations, très dévouées, cest la plupart du temps des ordures. Prétendre ressentir quelques microsecondes, tester un joystick peut déjà coûter plus cher est tout simplement de la fantaisie.

Y a-t-il vraiment une raison technique de préférer lémulation matérielle ou basée sur FPGA à lémulation logicielle?

Ce qui constitue une raison technique pour vous? En soi, le terme nest pas clair lorsque lon compare des implémentations complètes différentes.

ou cest juste une chose de nostalgie, causée par le désir de remplir comme vous sont vraiment de retour dans les années 80 ou 90?

Vous êtes-vous déjà assis devant lune des vieilles machines? différents claviers se sentent lorsquils quittent léquipement standardisé daujourdhui.

Et puis il y a bien sûr le bricolage du matériel – pas vraiment amusant avec les émulateurs, car ici lajout dune interface consiste simplement à ajouter quelques lignes de code – ou simplement configurati dans certains cas. Pas de mise en page, pas de gravure, pas de soudure et surtout pas de malédiction et de patch jusquà ce que cela fonctionne.

Je « voudrais clarifier le terme « émulation FPGA » mentionné dans la question.

Premièrement, il y a bien sûr une émulation logicielle. Prenons comme exemple quelques émulateurs logiciels (plus ou moins) exacts du CPU 6502 . Ils essaient démuler tous les artefacts externes du processeur réel, tels que le nombre de cycles pour chaque commande, les adresses des accès mémoire, et même « létat interne » (plutôt que létat des registres logiciels visibles). Pourtant, il na rien de pareil avec le vrai processeur, à partir du moment où il sagit de pure matière logicielle, pas de périphérique matériel.

Lorsquune nouvelle fonctionnalité du vrai 6502 est découverte (comme de nouveaux opcodes ou indicateurs non documentés ou des détails dexécution ), il est inséré dans lémulateur logiciel comme « une autre fonctionnalité à implémenter ». Aucune fonctionnalité de la chose réelle ne serait emegre dans lémulateur de logiciel, si elles sont inconnues de limplémenteur.

Alors regardons les cœurs HDL compatibles 6502.Ils représentent maintenant en fait un véritable dispositif logique numérique – ou un modèle de celui-ci (dans le cas où le HDL est simulé, non implémenté dans le matériel réel comme FPGA ou ASIC). Ils ont maintenant un vrai stockage flipflop (ou verrou) pour les registres CPU, ils pourraient implémenter de vrais signaux de bus CPU et même être insérés dans lordinateur rétro au lieu du 6502. Pourtant, ils sont (plus ou moins) fabriqués « à partir de zéro », avec les spécifications de la CPU, ils sont destinés à remplacer, pas sa structure interne. Et pourtant, il leur manquerait des fonctionnalités non décrites dans ces spécifications, qui existent dans un véritable processeur rétro, mais qui sont encore inconnues de limplémenteur.

Un autre niveau de reconstruction pourrait être la conception HDL construite de la manière suivante:

1. Le vrai processeur rétro est décapé et photographié
2. puis les schémas au niveau de la netlist et du transistor sont recréés (soit à la main, soit par des outils plus ou moins automatisés)
3. netlist est converti en schémas au niveau de la porte, puis en description HDL, qui est à son tour implémentée en FPGA ou ASIC.

Contrairement aux cas précédents, maintenant presque toutes les fonctionnalités du processeur réel deviennent implémentés « nativement », car la structure du HDL résultant est plus ou moins équivalente à la structure de la chose réelle (au niveau des portes logiques et des bascules).

Il pourrait encore y avoir des problèmes, par exemple 6502 a des instructions qui se comportent de manière erratique et j’ai l’impression qu’un tel comportement n’apparaîtrait pas naturellement en HDL.

De manière générale, je considère Tout ce qui se trouve au-dessus du « reverse-engineering, puis recréer HDL » est en fait une émulation , que ce soit dans le logiciel ou le matériel, alors que la dernière manière nest pas .

En dautres termes, considérons la préservation de lancien logiciel. Nous pourrions lexécuter sur du matériel contemporain, mais sil nest pas disponible, des émulateurs logiciels entrent en jeu, mais lancien logiciel quils sont utilisés pour exécuter est toujours exactement le même.

Maintenant, nous aimerions conserver lancien matériel (CPU), mais limplémentation authentique nest pas disponible, donc nous la recréons en utilisant une technologie plus récente, mais la structure logique du CPU reste exactement la même.

Pour offrir une réponse sur la question de latence uniquement, en tant quauteur démulateur:

Les exceptions abondent mais la règle générale sur le matériel dorigine des années 80 et dans au début des années 90, les changements dentrée du joypad et du clavier peuvent être détectés par le matériel presque immédiatement après quils se produisent, et que lorsque la vidéo et laudio sont sortis de la machine, ils atteignent lutilisateur presque immédiatement – par exemple pour un téléviseur CRT classique, le niveau de trame est en train de peindre en ce moment est presque la sortie en direct de la machine.

Avec le matériel maintenant, lentrée traverse généralement es une pile Bluetooth ou USB, qui peut être inspectée uniquement à un certain intervalle par le système dexploitation hôte, et si quelque chose sest produit, il le communique alors au processus intéressé, ce qui peut ou non se produire immédiatement en fonction du planificateur spécifique.

De nombreux émulateurs implémentent également une boucle principale qui ressemble à la façon dont vous pourriez concevoir un jeu:

1. collecte toutes les dernières entrées et les transmet à la machine émulée;
2. exécuter la machine pour une image;
3. peindre la prochaine image de sortie dans un tampon invisible;
4. mettre en file dattente pour lafficher au prochain vsync et bloquer;
5. répéter.

Par souci d’argument, imaginez que votre machine moderne est très rapide et que les étapes 2 et 3 sont instantanées. Ensuite:

• il y a en moyenne une demi-image de latence dentrée plus la signalisation Bluetooth / USB et le système dexploitation ajoutés – toute entrée qui se produit juste après le haut dune image ne sera pas transmise jusquau début du suivant, tout ce qui se produit juste à la fin sera communiqué presque au bon moment, et la plage de latences entre les deux est linéaire de sorte que la moyenne est à mi-chemin entre les deux; et
• il ya « une trame supplémentaire fixe de latence de sortie parce que vous publiez une trame pour la présentation au prochain vsync et attendez ensuite quil soit temps dêtre montré.

Donc, avec cette simple boucle, sur un matériel idéal, dans le cas moyen, le délai entre le moment où vous appuyez sur quelque chose et la réaction de l’écran est d’environ 1,5 image de plus que le matériel réel. Et ce n’est que si les machines hôtes et émulées fonctionnent à la même fréquence d’images. .

Les puristes affirment que certains jeux originaux sont si finement réglés, après le nombre dheures approprié de tests et de modifications dans la journée, que 1,5 image les désavantage quils peuvent détecter.

Les FPGA sont généralement des émulations *, quelle que soit la manière dont ils sont vendus, car ils sont généralement une personne qui réimplémente une spécification dans un langage de description matérielle de haut niveau. Mais ils cherchent à omettre autant que possible cette latence – une bonne qualité omettra complètement la mise en mémoire tampon vidéo, exécutera le reste du système en temps réel et poussera lentrée avec un délai minimal.

* qualification ajouté selon la correction fournie par @lvd ci-dessous. Voir sa réponse pour plus de couleur.

Bien sûr, il « nest pas difficile de résoudre la plupart des problèmes logiciels dans les logiciels:

• les entrées plus souvent;
• ne » t utilisez vsync pour déclencher une nouvelle sortie vers vsync; et
• nutilisez pas de double tampon.

In extremis, vous pouvez même courir le raster pour une latence de sortie similaire à un FPGA – si vous avez déjà un -fréquence boucle pour les entrées fréquentes, et si le matériel de base prend en charge toute sorte de sortie qui peut produire des déchirures décran, alors vous avez les outils.

Malheureusement, de telles approches nétaient généralement pas prises par les émulateurs dans le passé, surtout avant que la latence ne devienne un sujet aussi largement débattu, et que quelque chose dune image négative est resté bloqué.

Commentaires

• FPGA nest pas toujours un émulation, au moins dans vos termes de " une personne réimplémentant une spécification dans un langage de description matérielle de haut niveau "
• @lvd pour améliorer la réponse, pouvez-vous être plus précis? Je ' je connais une expérience qui a utilisé une netlist extraite par VisualChips dun réel (si la mémoire ) TIA, mais un peu au-delà. EDIT: non, attendez, je vois que ' avez posté une réponse distincte. Merci!

De nombreux aspects de HW vs SW ont été couverts par dautres articles ici, donc je vais ne pas les toucher. Au lieu de cela, je voudrais expliquer le problème LATENCY de mon point de vue ainsi que lexpérience que jai acquise lors du codage de mes émulateurs pour diverses plates-formes …

Créer un émulateur SW sur des machines modernes est beaucoup plus difficile du point de vue de la latence quil ne létait à lépoque des accès directs aux E / S. Pour les ordinateurs personnels et les consoles de jeux, nous devons simuler / émuler le son, la sortie visuelle et lentrée utilisateur aussi précisément que possible. Le plus gros problème est le son. En effet, notre audition est bien meilleure que nimporte quel autre de nos sens et nous pouvons sentir / entendre la différence si le son est coupé par quelques ms ou Hz. Si lécran est éteint de 1 ou 2 images, nous ne pouvons pas voir la différence. Aussi si lentrée est légèrement retardée, cest ok (pour la plupart des humains).

Dans larchitecture moderne des machines, tout est mis en mémoire tampon (en particulier le son). Donc, pour produire du son, nous devons créer des données PCM qui sont envoyées à la puce audio et lues via DMA + DAC . Pour ce faire, généralement 2 tampons circulaires ou plusieurs petits tampons linéaires sont utilisés. Maintenant, pour produire des sons sans problème, les tampons doivent être suffisamment grands. Par exemple sur Windows la dernière fois que je vérifie WAVEOUT nécessite au moins 20-80 ms. DirectSound besoin de >400 ms

Maintenant si le programme émulé sajuste sortie audio, il ne sortira quaprès la lecture du son déjà demandé.

Il en va de même pour lentrée E / S sur certaines plates-formes, donc les retards sadditionnent.

Lorsque vous utilisez FPGA alors vous avez un accès direct à la sortie son sans aucune mise en mémoire tampon. Il en va de même pour lentrée.

Cependant, la latence dentrée du jeu (clavier, joystick) na généralement rien à voir avec la latence du système hôte . La cause habituelle est que la majorité des émulateurs utilisent clock tics pour maintenir les vitesses émulées. Ainsi, ils simulent le processeur ou autre et une fois atteint le nombre souhaité dhorloges simulées par heure, ils se mettent en veille jusquà ce que la prochaine minuterie soit émise ou autre. Plus lordinateur hôte est rapide, moins il a besoin de temps pour émuler, donc la simulation ne réagira pas la plupart du temps.

Par exemple, supposons que notre simulation puisse fonctionner 100 fois plus vite que la vitesse dorigine de lordinateur émulé. Cela signifie que seulement 1% du temps pendant lequel la simulation fait quelque chose et que le repos nest que Sleep(). Pendant le sommeil, lémulation ne peut rien répondre. Ainsi, il peut manquer des coups de touches, des clics de feu, etc. Pour remédier à ce que certains émulateurs pourraient utiliser à nouveau la mise en mémoire tampon conduisant à la latence au lieu dignorer lentrée. Il existe également différents styles de contrôle du temps qui suppriment complètement ce problème. Pour plus dinformations sur ce sujet, consultez:

• Question sur la précision du comptage de cycles lors de lémulation dun processeur

Les machines NTSC dépoque (et les Mac CRT, etc.) peuvent modifier leur sortie graphique au milieu de lactualisation de laffichage CRT (en partie vers le bas du raster vertical), déchirant ainsi limage en réponse à une entrée en temps réel.

Les émulateurs utilisant des moniteurs non CRT ne peuvent pas faire cela en temps réel, et ne peuvent simuler un raster déchiré que le suivant cadre ou champ.

Et la seule façon de tester si une émulation est précise, comparée au matériel vintage réel (vérité terrain). Vérifiez sil y a des pièges logiques cachés non documentés (défusion, etc.) ou des bogues de mise en page analogique sous les différentes couches de puces ASIC.

Commentaires

• _ " .. ne peut que simuler … " _Quelle est la différence? Nest-ce pas ' une émulation qui consiste à simuler le tout?
• Pas sur un écran non CRT. Un écran LCD (et.al.) ne ' t rafraîchir dans 2 champs entrelacés de 30 images, où les lignes alternées et le haut et le bas dune fenêtre apparaissent à des moments différents, sur 10 mS séparés en temps réel. Peut-être quun FPGA alimentant un ancien moniteur CRT serait plus précis quun émulateur.
• Rien nempêche le logiciel démulation de faire de même. et certains le font. Après tout, les écrans 60 Hz sont désormais standard, permettant de transférer le même scintillement quun CRT. Pas besoin de logiciel basé sur FPGA ou de CRT ici.