[NES] Beta Mesen emulateur

[upsilandre]

Mesen ( Nes em a l'envers pour NES emulator) est un emulateur NES récent encore en Beta (version 0.9.3 actuellement) mais qui est partie pour etre la référence de l'emulation NES sur nos PC. Et celui qui est derrière ce projet (Sour) est québécois et inscrit sur le forum du coup y a moyen de faire remonter des choses a partir d'ici et en francais.
Y a aussi le Github pour participer a la beta https://github.com/SourMesen/Mesen

Mesen réunis beaucoup de qualité a la fois pour les joueurs et pour les programmeurs. C'est un émulateur NES qui pousse au maximum la précision d'émulation et les outils de debug pour simplifier la vie des programmeurs tout en etant un émulateur tres ergonomique et accueillant pour le joueur lambda avec des features tres sympa (Le rembobinage, une base de donnée de 11500 cheat code integré, une mise a jour automatique de l'emulateur, le support automatique des patch IPS sans avoir besoin de modifier la ROM d'origine, le support des fichiers audio NSF, Tout les filtres possible ect...)
Et meme si on est pas programmeur y a des outils de debug qui sont tres sympa a tester comme le PPU Viewer qui vous permet de voir tout ce qu'il se passe au niveau du processeur graphique de la NES et de sa VRAM et vous pouvez meme modifier en temps réel l'aspect des tuiles sans passer par un outil externe.

Meme le site et la documentation est bien fichu et reflète assez bien le ton de l’émulateur. Vous avez tout ici:
https://www.mesen.ca/fr/
On peut aussi utiliser le topic juste pour l'encourager parce que c'est vraiment du boulot  

[upsilandre]

Ma liste de doléance que je mettrais a jour au file du temps  
Tout n'est pas digne d'interet ou réalisable.


Script Lua
-- plus de requête pour l'instant  

Debug
-- Ca serait bien alors d'avoir un highlight avec une couleur spécifique qui montre les octets que l'on a modifié dans le memoryTool par rapport a la rom d'origine


Autres
-- Le frame advance auto me manque. j'aimerais bien que l’émulation avance a environ 15fps quand on reste appuyé sur le bouton frame advance mais que ce mode auto ne s'active pas trop vite, seulement si on reste appuyé une quinzaine de frame (parce que dans la 0.9.3 le frame auto etait present mais génant, il s'enclenchait quasi instantanément en 3 ou 4 frames et rendait l'utilisation du frame advance difficile)

Bug
-- plus rien

[Tryphon]

Gloire à Sour ! Il veut pas faire le même pour Megadrive ? Ou Saturn ?

[Invité]

Cool il a l'ai bien bon cet émulateur, surtout pour faire du dev,et comme tryphon, si faire un mesen pcengine le tente 

[upsilandre]

nan nan on le garde pour nous. La NES est la machine la mieux servie et le restera parce qu'elle le vaut bien

[brokestudio]

Cool, merci ! Et encore une fois, super super super boulot Sour !

Comme précisé dans le topic "Mr ToutLeMonde et la programmation NES", l'option d'édition du code dans le debugger est top, mais elle serait parfaite si il était possible de modifier directement les valeurs héxa dans la partie droite de la fenêtre.

Pour le moment, c'est tout pour moi.

[Sour]

Merci pour vos commentaires!

Si seulement j'avais le temps de faire tout ça! :) J'ai probablement déjà passé un bon 2000+ heures de temps sur Mesen au cours des 2-3 dernières années.. Personnellement, j'aimerais bien ça faire une version SNES de Mesen, mais même avec toutes les leçons apprises à travers Mesen et même en comptant le code que je pourrais réutiliser, j'en aurais sûrement pour au minimum une bonne année avant d'en arriver à quelque chose d'intéressant. Mais bon, pour le moment je préfère essayer de "finaliser" Mesen avant tout autre chose.

[upsilandre]

Merci pour vos commentaires!

Si seulement j'avais le temps de faire tout ça! :) J'ai probablement déjà passé un bon 2000+ heures de temps sur Mesen au cours des 2-3 dernières années.. Personnellement, j'aimerais bien ça faire une version SNES de Mesen, mais même avec toutes les leçons apprises à travers Mesen et même en comptant le code que je pourrais réutiliser, j'en aurais sûrement pour au minimum une bonne année avant d'en arriver à quelque chose d'intéressant. Mais bon, pour le moment je préfère essayer de "finaliser" Mesen avant tout autre chose.

Bon voila j'ai mis a jour mon premier post avec la liste de mes dernières doléance
Maintenant je tiendrais a jour directement sur ce post, je pense que c'est plus simple (tout en le metant aussi dans le file du topic quand je fais des mise a jour).

[Invité]

c'est clair, excellent travail, bravo à toi,continues à ton rythme Sour, de toute façon, tu as déjà marqué le monde de l'émulation !

[Sour]

Pour répondre aux points que tu as notés:
-Lua: Info du rom & input, ça devrait être facile à faire pour la prochaine version

-Highlights: Pour la VRAM et les autres options que tu suggères pour PRG, c'est possible, mais avec autant d'options, il faudrait un UI plus approprié (le système de menus en place présentement est déjà relativement difficile à utiliser).  Pour OAM/palette, ça peut être un peu plus compliqué, principalement parce que je veux éviter de ralentir l'émulation pour ça - le debugger n'a présentement aucune connaissance des lectures & écritures sur l'OAM et la palette.

-Ouvrir le hex editor à la bonne addresse à partir du debugger, facile, par contre, pouvoir modifier l'hexa directement dans l'assembleur, c'est plus complexe - ça implique devoir updater le texte à gauche selon les changements fait à l'hexa.  Donc il faudrait décompiler l'hexadécimal, et présentement je n'ai pas de façon simple d'y arriver - sans compter la complexité de modifier le code assembleur tout en gardant les labels et commentaires, etc.  Bref, ça ne sera probablement pas quelque chose que je sois en mesure de faire dans le court terme (et même à plus long terme, ça reste complexe)

-Watch: Personnellement, après des années à utiliser VS avec le watch comme il est placé dans Mesen, je suis un peu réticent à le changer. Le mettre dans les memory tools est problématique puisqu'on peut ouvrir plusieurs memory tools à la fois (ce qui impliquerait que le watch devrait se synchroniser d'une fenêtre à l'autre, etc.) L'idéal serait une option pour le "un-docker" de la fenêtre du debugger, mais ça demanderait aussi un bon nombre de changements. Je vais prendre l'idée en note, mais ça risque ça aussi de prendre un certain temps.

-Afficher le contenu de l'adresse RAM directement dans le code: J'ai quelques solutions potentielles en tête, il s'agit de vérifier ce qui sera le plus rapide point de vue de la performance du debugger.

-Pour le reste (compteur lag, frame advance, bug à l'ajout des labels), ça devrait être relativement simple à corriger (mais comme pour le reste, je dois d'abord venir à bout de mes changements par rapport aux inputs, ce qui risque de prendre quelques semaines encore, au minimum)

[upsilandre]

merci  
Tu es évidement le seul a savoir ce qui est pertinent ou pas de modifier (notamment pas ralentir inutilement l'emulation) donc comme a chaque fois je te fais confiance pour faire le tri et il faut faire le tri (l'inverse serait pas rassurant du tout). Et évidement c'est pas urgent, c'est des idées pour plus tard.

-- Pour le watch effectivement c'est mieux de pas y toucher du tout mais du coup ma priorité pour les highlight du memoryTool ca serait alors de pouvoir simplement appliquer manuellement une couleur spécial de highlight sur des adresses RAM (Donc pas forcement les labels parce que ca pourrait etre un peu trop le bordel sur une source ou tout est labellisé) qui servirait alors de jalon temporaire. Pour moi ca compléterait tres bien le watch tel qu'il est.
Quand tu cherches juste a cheater rapidement un jeu et a identifier quelque variable du jeu en RAM pendant que tu joues c'est vraiment pratique. Poser quelques highlight en RAM comme des jalons (juste une option quand on fait clique droit sur une adresse) tout en continuant de surveiller ce qu'il y a autour, c'est comme ca que je faisais sur Fceux (enfin ca fonctionnait pas tout a fait comme ca sur Fceux, fallait mettre l'adresse dans le bookmark pour avoir un highlight mais le bookmark est pas utile).
Le watch c'est en quelque sorte l'etape d'apres si tu veux vraiment entrer dans le code ou poser des conditions sur l'affichage du watch ect... Avoir un simple highlight manuel sur les adresses RAM (tout comme on a un highlight sur les freezes, faudrait juste une autre couleur) serait pour moi un palliatif satisfaisant et qui du coup nécessite pas de changer le watch.
Et ca serait bien aussi de pouvoir quand meme visualiser le nom des labels dans le memory tool (seulement quand on clique sur l'adresse en question), comme ca on peut aussi poser un label et identifier nos highlight manuel (et globalement c'est pratique d'avoir un feedback des labels dans le memorytool).

-- Et pour ce qui est des modifications de l'hexa dans l'assembleur personnellement j'en ai pas besoin si on peut ouvrir directement l'hex editor a la bonne adresse en cliquant dans le debugger. Moi j'adorais ca sur Fceux pour faire des petites modifs rapides donc ca me va tout a fait.  

[upsilandre]

Sinon je suis fasciné aussi par ta version de Visual NES. Je trouve ca génial d'avoir une simulation complete de la NES qui tourne deja en l'etat a 2 frames par minute et d'avoir toute la visualisation bien plus fonctionnel que sur la version java. C'est vraiment beau juste a regarder.

Dans le 2A03 le bloc vide au dessus du 6502 c'etait censé etre quoi? Le boc qui servait pour tester le chip?

[brokestudio]

Le mode décimal non ?

[upsilandre]

non le DCB il est a l'interieur du 6502 et de toute facon il est present dans la simulation si je ne m'abuse (c'est un 6502 classique, ils ont pas refait la micrographie du 6502 de la NES). D'ailleurs ils ne l'ont pas vraiment enlevé dans la NES, je crois qu'ils ont juste coupé un canal pour le rendre non fonctionnel.
Moi je parlais du gros bloc vide qu'il y a au dessus du 6502.

[upsilandre]

C'est ce bloc la qui n'est pas dans la simulation




A part un bloc pour tester le chip lors de la production (et qui donc serait pas utile pour la simulation) je vois pas ce que ca pourrait etre.

[Sour]

Je ne connais pas trop les détails pour ça - j'ai cherché un peu, mais je n'ai pas trouvé de photos du 2A03, seulement ceux du 2C02. Mon travail a été plus ou moins limité à prendre le code javascript existant et refaire exactement la même chose en C++, à connecter les 2 chips ensemble (et il reste potentiellement quelques petits problèmes à ce niveau là, d'ailleurs) et faire un UI qui permet de manipuler le tout.

Il y a aussi un thread sur NesDev avec pas mal d'infos sur le Visual NES, avec des mentions des problèmes existants (mais j'imagine que tu l'as déjà vu). Le mode décimal est en effet disponible dans le core - j'avais quelques modifications de faites pour le désactiver, mais je n'étais pas certain de mes changements et je n'ai jamais commité ce changement sur GitHub.

[upsilandre]

J'ai trouvé la micrographie

http://www.visual6502.org/images/RP2A/Nintendo_RP2A03G_die_shot_1b_6500w.jpg
http://www.visual6502.org/images/RP2A/Nintendo_RP2A03G_die_shot_1a_6500w.jpg

effectivement y a pas grand chose a cette endroit. Ca a l'aire d'etre un bloc totalement isolé du reste. Peut etre un bloc pour tester la qualité du process de production.

[upsilandre]

En fait le bug qui fait avancé l'émulation d'une instruction concerne toutes les fenêtres. dès qu'on focus sur une autre fenêtre que celle du debug (breakpoint, memoryTool, fenetre de jeu, PPU viewer...) et qu'on revient sur la fenetre de debug ca fait avancer l'emulation d'une instruction, c'est super chiant quand tu veux t’arrêter sur un truc

[vincent2105]

J'ai voulu suivre un tuto sur le son, et les roms de démo ne passent pas ou très mal...
http://nintendoage.com/forum/f.cfm?f=78189&m=2606856
Idem pour tes roms "keziah jones" et "megaman" upsilandre  :/


Quelqu'un aurait il une explication ?

EDIT : j'ai le même problème avec toutes les roms en fait ! SMB etc...
@Sour : c'est hautement probable   Je vais y remédier.

[Sour]

En fait le bug qui fait avancé l'émulation d'une instruction concerne toutes les fenêtres. dès qu'on focus sur une autre fenêtre que celle du debug (breakpoint, memoryTool, fenetre de jeu, PPU viewer...) et qu'on revient sur la fenetre de debug ca fait avancer l'emulation d'une instruction, c'est super chiant quand tu veux t’arrêter sur un truc  

De ce que je vois, le problème c'est que tu as l'option "Break on debugger focus" d'activé et ça semble causer un "break" même si c'était déjà en break (j'arrangerai ça)

Je ne suis pas capable de voir le lien sur nintendoage, mais j'ai réussi à trouver et tester les roms de "Keziah Jones" et tout semble fonctionner correctement.  Peut-être que tu as changé un ou des settings dans les options qui causent des problèmes avec ces roms?

[upsilandre]

J'avais pourtant desactiver toute les options break il me semble mais effectivement en cochant et décochant le "break on debugger focus" ca enleve le probleme du coup ca me va comme ca  

Et je confirme j'ai pas de probleme avec mes ROM de sampling. regarde un peu les options (ou reset tout en effacant le setting)
Prend le temps de faire un tour de tout le setting, y a des truc sympa.

[vincent2105]

J'ai désinstallé/réinstallé mais le problème demeure.


Configuration : Windows 10 (1703) / DirectX 11 / NET Framework 4.5+ 

HP Pavilion 17 Notebook PC - Pentium N3540 2.16GHz - 7.89Go RAM utilisable - x64

[upsilandre]

ca tourne a combien de fps? parce que j'ai pas l'impression que c'est juste un probleme de son, tu vois pas que l'emulation tourne au ralentie? C'est pas plutot ca qui devrait t'interpeller?  
En tout cas c'est bizarre. Affiche les fps et augmente la vitesse d'emulation pour voir comment Mesen réagis, j'imagine qu'il va pas pouvoir aller plus vite comme si y avait quelque chose qui le ralentissait enormement.

[vincent2105]

Ah j'ai oublié de parler des ralentissements ici, j'avais envoyé un mp à Sour en lui signalant. 
En fait je n'avais testé que des roms "sonores" avant. Donc j'avais pas conscience des ralentissements avant de faire tourner des roms de jeux. 
Et justement pour les FPS, je l'ai également signalé à Sour, je n'arrive pas  à les afficher que ce soit avec F10 ou en cliquant dessus. :/
Oui il s'agit de gros ralentissements quasi continus ; de temps en temps ça passe correctement, mais c'est rare.

[upsilandre]

A titre indicatif meme si Mesen est un emulateur tres precis et que mon PC est vieux je le fais tourner quand meme au moins a 350fps en général. chez toi ca a l'aire de tourner 10 fois moins vite donc y a effectivement un probleme.

[vincent2105]

Y'a moins d'une semaine, j'ai eu une maj de windows, suite à ça j'ai eu un message du genre : "HP Accelerometer ne fonctionne pas sur cette version de Windows".
Du coup, j'ai suivi la procédure suivante : https://h30478.www3.hp.com/t5/Ordinateurs-portables-Syst%C3%A8mes-d-exploitation-D%C3%A9marrage-et/HP-Accelerometer-ne-fonctionne-pas-sur-cette-version-de/td-p/756054

Peut-être que ça vient de là... 

Enfin, pour l'affichage des FPS, je suis perplexe. En supposant que ma touche F10 soit défectueuse, en cliquant sur FPS  ça devrait fonctionner aussi non ?

[upsilandre]

oui mais a partir du moment ou l'emulateur ne fonctionne pas vraiment j'imagine qu'il y a plein d'autre truc qui peuvent deconner (comme le son par exemple, meme au ralentie ca devrait pas donner ca) donc tant que l'emulateur fonctionne anormalement je pense que c'est pas la peine de chercher a comprendre les autres probleme.

[upsilandre]

et quand t'affiche le gestionnaire de tache de ton PC ca donne quoi en ressource (avec ou sans Mesen)

[vincent2105]

Sans Mesen, puis avec.

Spoiler:

EDIT : 

Avec Mesen, puis sans.

Spoiler:

[upsilandre]

EDIT : 

Avec Mesen, puis sans.

Spoiler:

La c'est la vue d'ensemble, le mieux c'est de cliquer sur l'onglet "processeur" pour voir chaque coeur/thread individuel si ca sature ou pas (ca a l'aire).