Mise à jour NTSC émulateur NES + comparaison performances

[Admin]

La sortie vidéo des consoles Nintendo NES utilisait différents formats selon la zone de vente :

• NTSC (60Hz) pour l'Amérique du Nord et le Japon
• PAL (50Hz) pour l'Europe

Pour ne faire afficher que 50 images par seconde aux consoles européennes, Nintendo a tout simplement ralenti la console en utilisant des processeurs de fréquence inférieure.

En conséquence, les mêmes jeux sont 20% plus rapides si joués sur une console américaine ou japonaise.



L'émulateur NES pour NumWorks, un portage par zardam de nofrendo, ne gérait initialement que le mode PAL, ce qui donnait une émulation nettement plus lente que sur les modèles concurrents TI-Nspire.

Dans la nouvelle version de son émulateur et du convertisseur en ligne webnofrendo associé, zardam te donne le choix du format vidéo à cibler : PAL ou NTSC.
Choisis donc PAL pour une expérience de jeu oklm, ou NTSC si tu as l'âme d'un champion international !



Profitons-en pour comparer maintenant équitablement les performances d'émulation NES de nos calculatrices.

La Graph 90+E ne sera hélas pas incluse dans ce test, parce que son émulateur NES n'a pas bougé depuis un an, qu'aucune version compilée n'en a jamais été disponible, que nous n'avons pas réussi à le compiler même en demandant de l'aide sur Planète Casio, et que l'auteur n'a pas davantage répondu à un courriel demandant un binaire de démo/test en 2017.

1. La NumWorks (processeur ARMv7 à 100MHz) et la TI-Nspire monochrome (processeur ARMv5 à 120MHz) sont les premières à terminer l'intro de Ninja Gaiden en 1min29.
2. Elles sont suivies de peu par la génération de TI-Nspire CX avec processeur ARMv5 à 132MHz, en 1min31.
3. Et la TI-Nspire CX CR4+ malgré son processeur ARMv5 plus rapide à 156MHz, se traîne lamentablement pendant 2min00.

Voyons maintenant si les TI-Nspire peuvent rattraper leur retard avec un peu d'overclocking :

1. La TI-Nspire monochrome avec son processeur ARMv5 monté à son maximum de 150MHz est mainenant seule à terminer l'intro en 1min28.
2. La NumWorks, toujours avec sonprocesseur ARMv7 à 100MHz, met donc encore 1min29.
3. Sur la représentante de la génération TI-Nspire CX à 132MHz, Nover a détecté et enregistré une configuration d'overclocking stable à 252MHz qui ne met plus que 1min30 !
4. La seule représentante de la génération TI-Nspire CX CR4+ à 156MHz dont nous disposons pour les tests s'overclocke assez mal en comparaison, Nover ayant abandonné l'accélération à seulement 216MHz, ce qui prend donc encore une éternité de 1min56.

Apparemment, mieux vaut acheter sa TI-Nspire CX d'occasion.
A quand l'overclocking sur NumWorks par contre ?

Lien NumWorks : convertisseur en ligne de ROM NES

Téléchargements Nspire :

• Ndless
• NESpire

Ressources Nspire :

• tutoriel d'installation Ndless
• tutoriel pour rajouter et lancer ses ROMs NES

[jean-baptiste boric]

A quand l'overclocking sur NumWorks par contre ?

Selon les datasheets officielles, le STM32F412 est déjà quasiment au maximum dans tous les domaines d'horloges (96 MHz actuels/100 MHz maximum nominal). On peut toujours essayer de changer les facteurs du PLL ainsi que les waitstates de la Flash (sachant qu'on ne peut pas espérer gratter plus avec de l'overvolting sans changer le régulateur de tension, fixé à 2,8 V).

Si on se réfère aux datasheets (et les principales limites officielles):

• f(VCO clock) = f(PLL clock input) × (PLLN / PLLM), 50 <= PLLN <= 432, 100 <= f(VCO clock) <= 432, 2 <= PLLM <= 63
• f(PLL general clock output) = f(VCO clock) / PLLP, PLLP = {2, 4, 6, 8}
• f(USB clock output) = f(VCO clock) / PLLQ, 2 <= PLLQ <= 15

Les réglages de NumWorks donnent:

• f(VCO clock) = 25 MHz × (192 / 25) = 192 MHz
• f(PLL general clock output) = 192 MHz / 2 = 96 MHz
• f(USB clock output) = 192 MHz / 4 = 48 MHz (doit être à 48 MHz pour que l'USB fonctionne)

Bref, officiellement on est déjà quasiment au taquet et je ne sais pas a priori quelle est la marge de manœuvre dont on dispose.

Sans transition, NumWorks vient de merger du code visant à compresser les glyphes et images avec l'algorithme LZ4. Au delà de l'économie en Flash actuelle (qui pourrait encore augmenter s'ils se mettent à compresser d'autres choses en plus), on pourrait l'appliquer aux ROMs de l'émulateur NES. Il n'y a pas assez de RAM pour faire tenir une ROM décompressée complète, donc ça nécessiterait un mécanisme de paging à la demande+cache LRU pour décompresser à la volée. Avec un peu de chance ça n'impacterait pas trop les performances.

[critor]

Ah ben merci pour la réponse détaillée et très intéressante une fois de plus.

[zardam]

J'avais testé rapidement l'overclock il y a quelques temps.

En utilisant les valeurs suivantes (dans device.cpp aux alentours de la ligne 266) :

Code: Select all

RCC.PLLCFGR()->setPLLQ(5);
RCC.PLLCFGR()->setPLLN(240);

On fait passer le CPU à 120 MHz, tout en conservant l'USB à 48 MHz.

Avec ces réglages, le script Python mandelbrot(10) s'exécute en environ 35 s au lieu de 42 s. On est bien sur hors spécification.

Concernant la compression des ROM, il est très certainement possible de faire quelque chose. La NES utilise un système de bank switching, et on peut donc se baser la dessus pour décompresser uniquement le nécessaire, en espérant que les switch ne soient pas trop pénalisants ni trop fréquents, à voir aussi. Enfin le plus efficace serait d'avoir plus de place, dommage que la flash additionnelle se soit pas "de série"...