Forum TI-Planet.org

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

critor wrote: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.

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

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"...