Stenzek, un développeur et ingénieur spécialisé dans la rétro‐ingénierie, très connu en matière d’émulation, ayant notamment participé activement au développement de l’émulateur Dolphin pour GameCube et Wii, nous gratifie d’un excellent émulateur pour la PlayStation de Sony, émulateur en développement depuis le 9 août 2019.
En termes d’émulation, EPSXE, qui n’était pas libre, a longtemps tenu la palme. Puis, suite à la perte du code source de l’auteur, lui‑même finalement piégé par sa propre politique en la matière, il a dû redémarrer de zéro, et l’émulateur n’a plus vraiment été à la hauteur sur ce qui faisait son succès et son suivi. Au‑delà de ça, s’est longtemps posé le problème de la portabilité, car, faute de code libre, les sorties sur telle ou telle architecture, étaient limitées au choix du développeur.
Dans ce domaine, c’est clairement PCSX, qui a parallèlement pris le relai (développé depuis 2001) et dépassé EPSXE, que ce soit à travers le projet original, ou ses nombreuses reprises allant de PCSX-df et PCSX-rearmed. On se retrouvait néanmoins systématiquement à hériter des limitations et problèmes de compatibilité et à des choix de désengagement de l’émulateur vieillissant, lui‑même basé sur de multiples greffons.
DuckStation est né afin de remettre à niveau l’émulation PSone avec un émulateur Open Source, libre, pour profiter des technologies d’aujourd’hui et obtenir le meilleur rendu et la meilleure prise en charge possible des jeux.
DuckStation apporte la prise en charge de plusieurs API graphiques, c’est‑à‑dire logicielle (sur processeur avec exécution parallélisée), OpenGL, DirectX, mais surtout Vulkan ! Ce dernier est même déjà disponible sous Windows, macOS et GNU/Linux, en versions 32 et 64 bits pour Intel et ARM, et Android, et propose une application prête à l’emploi avec une interface Qt, ou SDL, ou même un cœur libretro pour RetroArch et consorts ! De nombreuses options sont intégrées, comme le préchargement des jeux en mémoire vive, le débogage mémoire en direct, le gestion des codes de triches et listes de codes importées de RetroArch, la configuration d’un BIOS spécifique pour chaque région, l’outrepassement des régions, le surcadencement du processeur émulé de la PSone, l’accélération ou la limitation de la vitesse de lecture des disques avec disques virtuels, le gestion automatisée de deux cartes mémoire dédiées pour chaque jeu, listage automatique des images ISO de jeux, la prise en charge de presque tous les périphériques PSone (incluant NamcoGun et souris), l’accélération « in‑game »…
Mais le gros point fort de DuckStation, c’est son excellente gestion des écrans larges sur tous les jeux 3D en temps réel. Elle permet d’afficher des jeux PSone initialement développés pour du format 4/3 en 16/9 ou même en 21/9 et tout un tas d’autres ratios, tout en corrigeant, avec sa propre techno de correction PGXP, les problèmes inhérents de rendu 3D d’une telle conversion. Une option permet même de conserver le ratio 4/3 des vidéos sans déformation.
Seules les images fixées restent déformées (généralement les éléments de l’afficheur tête haute et les images 2D de jeux comme Resident Evil et Final Fantasy) du fait de la correction (il est possible de régler individuellement les jeux pour leurs propres options activées ou non !), mais Stenzek pense à terme, à inclure la prise en charge du chargement des textures externes à l’émulateur afin que chacun puisse apporter ses corrections.
De même, certains jeux intègrent nativement une limitation apportant alors du clipping sur les côtés de l’image, il convient alors de trouver et d’intégrer des codes de triches afin de faire sauter ces limitations.
Des limitations outrepassées qui ne poseront d’ailleurs pas de problèmes à l’émulateur, car il est possible de surcadencer le processeur émulé de la PSone.
La gestion de la conversion vidéo ascendante, quant à elle, est tout simplement excellente, que ce soit à la volée ou manuellement, avec prise en charge de la 4K et au‑delà, ainsi que la gestion de l’anticrénelage (SSA/MSA) et des filtres (dont xBR).
La prise en charge de Vulkan n’est pas négligeable, permettant de gagner de précieuses trames vidéo et de soulager le processeur quand on pousse l’émulation dans ses retranchements !
Ce dernier a également une fonction bien pratique, permettant de passer en [NTSC] la majorité des jeux [PAL], tout en ne provoquant pas de problèmes audio, corrigés à la volée pour la grande majorité des jeux.
Du côté du BIOS, Stenzek se concentre actuellement sur la fidélité de l’émulation, et n’a donc pas intégré de BIOS HLE, ni le BIOS clone de NoCash. Vous pourrez néanmoins profiter des BIOS originaux pour l’instant (à condition d’avoir la console d’origine), voire mieux, car de petits malins ont récupéré le BIOS présent dans l’émulateur PSone de Sony sur PSP, et se sont aperçu qu’outre faire sauter la limitation des régions, il permettait d’obtenir un meilleur taux d’images par seconde dans la plupart des jeux, et d’améliorer le rendu des textures en haute résolution.
Le dump du dernier BIOS PSone de Sony sur PSP, se trouve généralement sous le nom « PSXONPSP660.BIN », et sa somme MD5 est C53CA5908936D412331790F4426C6C33.
Cet émulateur, nouvelle pointure pour jouer aux jeux PSone, déjà excellent en l’état et très prometteur, pourra du fait de son code libre, être porté sur n’importe quelle architecture en lieu et place de PCSX, que ce soit sur Xbox, Xbox 360, PS3, PS4, Wii, Wii U, Switch, PC, Raspberry Pi (bien qu’actuellement n’étant pas porté sur architectures PPC, uniquement ARM et x86/x64)…
Aller plus loin
- Télécharger l’émulateur (2570 clics)
- Code source (573 clics)
# Retroarch
Posté par AlexTérieur . Évalué à 3.
Il me semble que tu as omis Retroarch, bien qu'il se rapproche plus d'un front-end qu'un réel emulateur à lui seul, il utilise le moteur de PCSX en version modifiée pour les besoins. Cela lui permet d'utiliser les traitements de shaders dont ePSXe se targuait d'avoir, par le biais du plug-in de Pete's Opengl, mais qui n'a jamais été mis à jour (resté à Opengl 2 je crois).
Pour moi il a été un remplaçant convaincant à PCSX qui n'était quasiment plus maintenu et qui avait des soucis (reconnaissance des manettes analogiques).
[^] # Re: Retroarch
Posté par tikilou (site web personnel) . Évalué à 5. Dernière modification le 13 décembre 2020 à 20:24.
Retroarch est une interface unifiée prenant en charge divers émulateurs. PCSX n'en est qu'un parmi d'autres, différents "coeurs" (équivalent à des versions minimales en lignes de commandes, mais adaptées à l'API de Retroarch) sont disponibles directement téléchargeable en son sein. On peut ainsi récupérer le dernier fork le plus abouti en date de PCSX (PCSX-Rearmed), DuckStation, et d'autres pour PsOne, mais également une multitude d'émulateurs pour d'autres consoles de jeu, et de moteurs de jeux libres, d'homebrews.
Il manque toutefois quelques émulateurs encore hélas propriétaires, comme CEMU, et d'autres encore en développement comme Yuzu et Ryunjx pour émuler la Nintendo Switch, et RPCS3 pour la PS3.
[^] # Re: Retroarch
Posté par AlexTérieur . Évalué à 2. Dernière modification le 14 décembre 2020 à 22:00.
Je ne suis pas si faux, j'ai bien suivi l'histoire de l'émulation de la Playstation. D'ailleurs, il faudra aussi rajouter Mednafen, qui au départ était censé émuler à la perfection l’architecture de la Playstation (càd, pas d'accélération, l'image affichée est 100% conforme à ce qu'afficherait une vraie Playstation, sans aucune "amélioration"). Il y a des bouts de codes qui ont été échangés entre Mednafen, PCSX(-Reloaded) et Retroarch.
# magie
Posté par ckiller . Évalué à 8.
Comment on fait ce genre d'émulateur ?
Avec la doc fournit par Sony ? en décompilant ?
Ca me parait magique en fait.
[^] # Re: magie
Posté par pushmepullme . Évalué à 2.
Est-ce qu'il ne suffit pas d'avoir les spécifications du proc/coproc, carte mère, gpu et quelques adresses pour taper dans les devices ? J'avoue ne pas savoir moi non plus mais je suis curieux de savoir ;) En decompilant, ça me parait assez rock'n roll mais pourquoi pas peut-être..
[^] # Re: magie
Posté par tikilou (site web personnel) . Évalué à 10. Dernière modification le 14 décembre 2020 à 02:07.
En étudiant autant le fonctionnement du matériel que du logiciel, on appelle ça l’ingénieure-inverse (reverse-engeenering).
C'est la première base, des passionnés d'électronique et développeurs documentent à partir de zéro, les spécifications du matériel sans documentation (et ce qui fuite). Ça s'apparente un peu à ce que beaucoup de contributeurs au noyau Linux on fait pour apporter le support de pas mal de périphériques faute de pilotes logiciels pour Linux que bien des fabricants ignoraient.
Ensuite c'est un peu un équivalent d'un Wine pour le système et librairies d'une console en particulier, mêlé à une machine virtuelle avec accélération logicielle ou matérielle avec OpenGL ou Vulkan, et l'émulation de la plupart des composants de la machine (chipset, processeur, puce audio, lecteur…)
Parfois c'est plus compliqué que prévu, car certains jeux peuvent pousser le vice jusqu'à exploiter des erreurs de conception logicielles/materielles et bugs dans les microprogrammes et bios de consoles, à leur avantage… Il faut donc parvenir à pousser le vice jusqu'à reproduire ces erreurs sans pour autant affecter la compatibilité avec d'autres jeux.
Et enfin pour outrepasser les capacités de la console d'origine, il faut intercaler entre ces différents éléments, des liens entre des technologies/API logicielles (DirectX, OpenGL, Vulkan, SDL, Cube…) du programme et de l'OS hôte et le matériel virtuel, modifiant à la volée les entrées/sorties. :)
[^] # Re: magie
Posté par Ysabeau 🧶 (site web personnel, Mastodon) . Évalué à 10.
Plus précisément rétro-ingéniérie ou ingénierie inverse.
« Tak ne veut pas quʼon pense à lui, il veut quʼon pense », Terry Pratchett, Déraillé.
[^] # Re: magie
Posté par Dinofly (site web personnel) . Évalué à 1.
La doc du constructeur n'est qu'une toute première étape. Afin de maximiser la compatibilité avec les jeux, les émulateurs doivent également reproduire les bugs ou comportements non documentés. Le blog des développeurs de Dolphin regorge d'infos à ce sujet et est passionnant.
Au delà de l'analyse directe des bus de données d'une machine en fonctionnement, dernièrement la tendance va jusqu'à décaper au laser les puces afin de les scanner en haute résolution et documenter ce qu'elles contiennent. C'est un processus extrêmement long (peut-être qu'un jour une IA pourra le faire automatiquement ?) mais heureusement réservé aux choses qu'on n'a pas réussi à trouver par les moyens conventionnels.
À ce niveau on peut commencer à se poser la question de la limite entre la rétro-ingénierie et la copie.
[^] # Re: magie
Posté par orfenor . Évalué à 2.
Eh ? J'ai vu ça sur une très vieille puce, un ancêtre des 8086, mais pas sur du matériel plus récent, qui est bien trop complexe et minuscule. Tu n'extrapolerai pas un peu là ? :-)
[^] # Re: magie
Posté par Aldebaran (site web personnel) . Évalué à 1. Dernière modification le 14 décembre 2020 à 14:49.
De ce que j'ai compris, de nos jours la circuiterie est recouverte de caches prévu pour empêcher cette investigation. Ça a sûrement du fonctionner, mais ça doit être coton d'enlever la protection d'une puce récente !
[^] # Re: magie
Posté par tikilou (site web personnel) . Évalué à 4.
Effectivement, même des hackers relativement connus dans la scène console, ont ce genre de pratiques, et y bousillent de nombreuses consoles à travers l'étude de ces dernières. Mais c'est généralement comme ça qu'ils trouvent des points d'entrée pour mieux comprendre le fonctionnement et outrepasser les systèmes de sécurité présents.
[^] # Re: magie
Posté par tao popus . Évalué à 7.
Le très intéressant videoblog « Deus Ex Silicium » (malheureusement sur Youtube) montre le mode opératoire pour analyser une puce. Quelques coups de cutter, et bains d'acide, pour libérer le circuit. Un microscope électronique pour visualiser le circuit. À priori aucune puce ne résiste à cette méthode.
[^] # Re: magie
Posté par AlexTérieur . Évalué à 3. Dernière modification le 17 décembre 2020 à 07:10.
Dans ses dernières vidéos, il ne s'embête même plus, il va carrément à coup de chalumeau pour carboniser la protection, c'est plus rapide :)
[^] # Re: magie
Posté par srb (site web personnel) . Évalué à 1.
Il montre justement la grille de protection qui est difficile à enlever dans une des vidéos. Elle protège une puce qui fait du chiffrement pour garder la clef d'un portefeuille de cryptomonnaie (https://www.youtube.com/watch?v=ma3S7UTrwgo).
La vidéo montre aussi que la documentation publique de la puce est très limitée.
[^] # Re: magie
Posté par Dinofly (site web personnel) . Évalué à 4.
Ce n'est pas parce que ça se fait aujourd'hui que ça concerne des machines récentes :)
Le PPU de la Super Nintendo n'était pas entièrement connu jusqu'à très récemment: https://www.reddit.com/r/EmuDev/comments/jxvh8v/snes_ppu_was_decapped/
[^] # Re: magie
Posté par orfenor . Évalué à 2.
Ah oui bien vu ! faut que je me mette à jour…
# Compatibilité et Mednafen
Posté par hokata . Évalué à 2.
Bonjour,
Au delà des fonctionnalité sur l'affichage, où en est t'il sur l'émulation à proprement parler ? Quelle compatibilité par rapport au catalogue ? Comment se compare t'il à Mednafen ?
Sur quoi peut-on le faire tourner ? Un rpi 3b+ est-il suffisant ?
Merci,
[^] # Re: Compatibilité et Mednafen
Posté par tikilou (site web personnel) . Évalué à 1.
Question intéressante, Stenzek a intégré un outil de rapport de compatibilité tel qu'expliqué ici : https://github.com/stenzek/duckstation/issues/450
Et voici la liste actuelle : https://docs.google.com/spreadsheets/d/1H66MxViRjjE5f8hOl5RQmF5woS1murio2dsLn14kEqo/htmlview
Quand à ce sur quoi il peut tourner, bonne question. Il devrait pouvoir tourner sur rpi 3b+ normalement, il y a d'ailleurs une version ARM proposée.
Après il ne faut pas s'attendre à des miracles j'imagine, l'on ne pourra pas exploiter pléthores d'améliorations graphiques sur ce genre de plateforme, mais avec un rendu original ou un peu mieux, sans doute.
[^] # Re: Compatibilité et Mednafen
Posté par Élafru . Évalué à 2.
J'allais citer Mednafen également. J'ai d'horribles souvenirs de Epsxe et PCSX, et j'ai longtemps attendu «le» bon émulateur ouvert qui réglerait tout. Depuis l'arrivée de Mednafen, j'en attendais pas d'autres, mais un nouveau n'est pas malvenu.
[^] # Re: Compatibilité et Mednafen
Posté par AlexTérieur . Évalué à 3.
Comme je l'ai dit plus haut, Mednafen est censé émuler à la perfection la Playstation, sans trucage/triche (lancer un jeu PS sur l'émulateur qui n'a jamais été testé par les développeurs, cela doit quand même marcher) et ne permet pas (en dehors de l'étirage de l'image en filtrage bilinéaire) d'apporter des technologies modernes de correction et d'amélioration (filtrage bi/tri-linéaire des textures, correction de perspective etc.) qu'a apporté par la suite l'informatique. C'est très bien (sachant que la compatibilité sera forcément meilleure) mais les émulateurs qui ont tenté apporter des corrections modernes de l'affichage 3D polygonale ont permis d'apporter un souffle nouveau sur l'émulation Playstation, voire même salvateur. Jouer à des jeux PS sans un minimum de correction (comme le filtrage des textures) sur nos écrans actuels qui peuvent dépasser très couramment les 22" qui plus est LCD (technologie quasi inexistante lors de la sortie PS, qui était majoritairement branchée sur des écrans cathodiques), cela peut vite devenir de la torture et une sorte de bouillie de pixel.
[^] # Re: Compatibilité et Mednafen
Posté par dinomasque . Évalué à 6.
J'ai depuis peu un ordinateur doté d'un écran 27" 5k (d'un célèbre constructeur de produits magiques et révolutionnaires) et mon péché mignon est l'émulation Sega Saturn (pour jouer à des jeux traduits sans niquer mes vraies consoles branchées sur la télé du salon pour les jeux originaux).
L'émulation Saturn est encore jeune et il y a peu d'améliorations graphiques par rapport à ce qu'on trouve par exemple dans les émulateurs Playstation.
Il y a deux écoles : d'une part Yabasanshiro qui permet de monter la résolution et d'autre part Mednafen qui fait le rendu à la résolution native de la machine et propose des "filtres" pour étirer l'image aux résolutions contemporaines.
Les calculs 3D des consoles 32bits avaient une précision rudimentaires et il y a plein d'espaces entre les polygones. Avec les basses résolutions d'époque, ça ne se voyait pas (les routines d'anti aliasing basiques de l'époque épaississaient les traits pour masquer le problème) mais en haute résolution c'est tout moche. Sans parler des textures bien pixellisées qu'aucun émulateur Saturn ne sait encore lisser.
Et sans compter non plus les éléments 2D qui restent en basse résolution, ainsi que les "background planes" qui sont encore rendus en basse résolution (en attendant des techniques de rendu haute résolution comme dans les émulateurs SNES qui le font maintenant pour le Mode7 ?)
A tout prendre, je préfère largement les filtres "CRT" qui offrent un rendu très similaire aux télés de l'époque dont les "défauts" étaient utilisés créativement pour masquer les défauts de rasterization des puces graphiques de l'époque.
En tout cas, chapeau aux développeurs de Mednafen qui font un boulot exceptionnel et aussi aux développeurs de front-end déconcertants de facilité d'utilisation comme OpenEmu :)
BeOS le faisait il y a 20 ans !
[^] # Re: Compatibilité et Mednafen
Posté par Psychofox (Mastodon) . Évalué à 3.
Faut se rendre à l'évidence, la pire époque pour les consoles c'étaient les débuts de la 3D. Même avec une télé CRT de l'époque on trouvait ça archi-moche. Il n'y a qu'à partir de la Dreamcast puis de la PS2 qu'on a commencé à avoir des jeux graphiquement passables en 3D sur consoles.
Heureusement il existait encore quelques éditeurs qui faisaient des jeux en 2D et les megadrive et snes ont reçu des nouveaux jeux jusqu'à très tard dans le cycle de vie des maudites ps1/saturn/n64.
[^] # Re: Compatibilité et Mednafen
Posté par ben51 . Évalué à 2.
La N64 c’était pas si mal.
Et puis entre sur PS1 il y a une différence entre les premier jeux et les tout dernier sorti.
[^] # Re: Compatibilité et Mednafen
Posté par AlexTérieur . Évalué à 2.
L'émulation de la Saturn n'est pas "jeune" et date presque autant que la Playstation. Juste que la Saturn s'est faite écrasée commercialement par la Playstation de Sony, et en plus, elle a une architecture avec une multitude de micro-processeurs qui complexifient notablement son émulation… Rien qui n'a permis à des génies de l'émulation de s'attarder sur elle. C'est bête à dire, malgré les qualités de la Saturn, mais c'est comme cela.
Concernant les filtres CRT, apparemment, jusqu'à au moins la Dreamcast, certains jeux ont été spécifiquement développés selon l'affichage CRT, càd s'amuser des limitations du CRT pour proposer un résultat visuel très convaincant sur CRT… ce qui veut dire que leur émulation, sans simulations CRT, apporte des résultats assez ratés… Heureusement, les filtres typés "CRT" et adaptés à nos écrans LCD actuels peuvent palier à ce problème.
[^] # Re: Compatibilité et Mednafen
Posté par Tarnyko (site web personnel) . Évalué à 0. Dernière modification le 12 janvier 2021 à 13:45.
Merci pour la citation, j'ignorais l'existence de celui-ci (me limitant à SSF pour une compat' maximale).
[^] # Re: Compatibilité et Mednafen
Posté par damaki . Évalué à 2. Dernière modification le 18 décembre 2020 à 13:43.
Comme dit nonmame, une page spécialisée dans la fidélité de l'émulation de systèmes dans un but de conservation, donc avec un biais vers le libre.
# ePSXe, perte du code source
Posté par Tarnyko (site web personnel) . Évalué à 1. Dernière modification le 12 janvier 2021 à 13:38.
Commentaire un peu H.S. ; mais pour avoir 4 exemples en tête (2 sur un logiciel "public", 2 dans un contexte professionnel), je suis toujours stupéfait quand ce genre de choses se produit.
Le code source d'un logiciel de cette envergure, si EN PLUS il n'est pas hébergé à l'extérieur, tu prends les précautions nécessaires pour pas le perdre. Au même titre que le rendre fonctionnel (je parle même pas de sa qualité), c'est le critère n°1 du sérieux d'un développeur !
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.