Outil ajout facile appli & ROMs Nintendo NES sur ta NumWorks

[Admin]

Tu ne le savais peut-être pas, mais tu peux avoir bien plus que les 9 applications intégrées de ta NumWorks.

Nombre d'applications additionnelles ont en effet déjà été développées par divers utilisateurs. On peut citer notamment parmi les dernières réalisations un émulateur de console Nintendo NES par zardam.

Toutefois, la calculatrice ne dispose d'aucune gestion des applications, si bien que la seule façon de rajouter ou retirer une application consiste à reprogrammer intégralement le firmware (micrologiciel) de la calculatrice.

Et cela implique par conséquent au préalable de compiler ce firmware en lui rajoutant les applications de ton choix.

Bref, c'était très loin d'être à la portée de l'utilisateur moyen.

Et bien zardam nous revient avec un outil en ligne inédit qui va complètement changer ça.

L'outil est dédié à son émulateur NES, et se propose de reprogrammer directement ta calculatrice avec un firmware basé sur la dernière version disponible à ce jour (1.7.0) et intégrant l'application d'émulation NES. Il met ainsi l'émulation NES à la portée de tous les utilisateurs NumWorks, ces derniers n'ayant désormais rien de plus compliqué à faire que de cliquer !

Il te suffira juste de lui fournir la ROM brute du jeu NES de ton choix, la calculatrice n'ayant pas non plus de gestion de fichiers à ce jour. Tu ne pourras donc avoir qu'un seul jeu à la fois sur ta calculatrice.

De quoi enfin découvrir les fiabilité et fluidité remarquables de cet émulateur :

Précisons toutefois que :

• ta calculatrice NumWorks ne dispose que de 1Mio de mémoire Flash
• la dernière version 1.7.0 du firmware dépasse les 760Ko
• et l'émulateur NES sans la ROM nécessite un peu plus de 138Ko

Sans le jeu, le firmware prend donc déjà 898Ko, et soustraction faite il ne te resterait plus que 150Ko pour la ROM NES.
Certes, on peut trouver des jeux NES dont le fichier ROM ne fait que 144Ko ou même moins. Mais ce sont loin d'être les meilleures références de la console, qui elles nécessiteront bien souvent 256Kio, 384Kio, 512Kio ou même davantage.

Et bien zardam a là encore tout prévu.
Tu pourras opter pour deux versions de firmware allégées en applications NumWorks :

• une version ne conservant que les 3 applications Calculs, Fonctions et Python, faisant 711Ko et te laissant donc 337K, de quoi caser les jeux faisant 160Kio, 192Kio ou 256Kio
• une version supprimant toutes les applications NumWorks, ne faisant plus que 418Ko et te laissant donc 630K, de quoi caser les jeux faisant 384Kio ou 512Kio

Pas sûr toutefois que ton prof de Maths apprécie cette dernière option.

Un outil révolutionnaire nous apportant enfin pour la NumWorks un embryon de la gestion des applications déjà présente sur d'autres modèles.

Espérons qu'il poura évoluer en :

• permettant de sélectionner soi-même les applications NumWorks à conserver, Suites et Statistiques me semblant par exemple essentielles pour le lycée français
• permettant de rajouter d'autres applications additionnelles que l'émulateur NES

Auquel cas, pourquoi pas l'intégration d'un tel outil directement sur la page officielle de NumWorks ?

Concernant l'émulateur NES, espérons qu'il pourra gérer une compression des ROMs, parce que 1Mio de Flash, avec un firmware de 760Ko encore amené à évoluer, ce n'est clairement pas beaucoup...

Lien : https://zardam.github.io/webnofrendo/

Source : viewtopic.php?f=102&t=21764#p235619

[jean-baptiste boric]

Espérons qu'il poura évoluer en :

• permettant de sélectionner soi-même les applications NumWorks à conserver, Suites et Statistiques me semblant par exemple essentielles pour le lycée français
• permettant de rajouter d'autres applications additionnelles que l'émulateur NES

Auquel cas, pourquoi pas l'intégration d'un tel outil directement sur la page officielle de NumWorks ?

Malheureusement, la page web se contente de concaténer un firmware précompilé avec la ROM du jeu. A moins de préparer à l'avance toutes les combinaisons possibles, ce n'est pas une solution qui passe à l'échelle. On pourrait utiliser un linker pour composer des applications précompilées en bibliothèques statiques, mais ça demande soit un backend pour exécuter le linker, soit d'embarquer un linker dans la page web, dans les deux cas c'est autrement plus compliqué à faire.

[Adriweb]

Malheureusement, la page web se contente de concaténer un firmware précompilé avec la ROM du jeu. A moins de préparer à l'avance toutes les combinaisons possibles, ce n'est pas une solution qui passe à l'échelle. On pourrait utiliser un linker pour composer des applications précompilées en bibliothèques statiques, mais ça demande soit un backend pour exécuter le linker,

J’avais commencé à faire ça sur le project builder ?
Mais il y avait eu quelques soucis avec la build enscripten pour tester en live. Mais comme on est en train de migrer de serveur vers une Debian 9 à jour... je pourrais peut être reprendre cette histoire de module NumWorks pour le project Builder et ainsi avoir des builds véritablement custom.

Enfin bref Romain avait dit que c’était une bonne idée et qu’un jour peut être ça serait sur le workshop... déjà rien que le fait d’avoir une build officielle mais avec des langues restreintes ça serait pas mal niveau taille

[Lionel Debroux]

Idée: est-ce qu'on ne pourrait pas jouer avec __attribute__((section("XYZ"))) sur les variables, et une gestion spéciale de ces sections dans le ldscript, pour faciliter la modularité des langues ?

[Adriweb]

Pour les langues, c’est déjà complètement modulaire - juste une variable à changer dans le makefile pour choisir les langues à inclure.

[Lionel Debroux]

En effet, mais je voulais essayer d'éviter au maximum l'utilisation du compilo pour faire une image réduite qui ne comporte qu'un sous-ensemble des langues possibles. L'idée serait de pré-compiler tous les fichiers de langue, et d'utiliser seulement le linker pour inclure les langues sélectionnées dans le binaire final.

[jean-baptiste boric]

Le système de traduction tel qu'implémenté à l'heure actuelle ne se prête pas à la modularisation au moment du link (un gros enum uint16_t pour identifier tout ce qu'il y a à traduire, la constante NumberOfLanguages...). Accessoirement, même en modularisant les apps en bibliothèques statiques précompilées, on serait obligé d'embarquer toutes les traductions pour toutes les applications pour tous les langages avec l'implémentation actuelle. Ce n'est pas vraiment gênant tant que les sets d'applications et de traductions sont fixés à l'avance, mais epsilon nécessite des améliorations avant d'être modulaire au-delà d'un flow de compilation complète.

[Clément.7]

Ne pourrait-on pas mettre la ROM dans un format compressé en ajoutant son support dans l'émulateur ? Par exemple, la ROM compressée de Super Mario Bros 3 ne fait que 223 Kio alors que la version non compressée fait 384 Kio. De quoi la faire tenir bien plus facilement... À moins que ça ne dégraderait trop les performances de l'émulateur ?

[jean-baptiste boric]

Ne pourrait-on pas mettre la ROM dans un format compressé en ajoutant son support dans l'émulateur ? Par exemple, la ROM compressée de Super Mario Bros 3 ne fait que 223 Kio alors que la version non compressée fait 384 Kio. De quoi la faire tenir bien plus facilement... À moins que ça ne dégraderait trop les performances de l'émulateur ?

C'est déjà tendu niveau RAM, zardam a dû remplacer l'allocateur mémoire car celui de NumWorks n'arrivait tout simplement pas à suivre. La ROM décompressée ne tiendra pas entière en RAM et je doute que rajouter de la décompression à la volée améliore la situation...

Quitte à vouloir faire de la place pour mettre des jeux, autant virer epsilon et faire des firmwares standalone. Et si le prof de maths n'approuve pas, on a qu'à faire un jeu NES pour jouer à la calculatrice

[critor]

Ah zut, j'avais complètement oublié que nous n'avions que 128K de RAM.

En effet, comme j'en suis plutôt à m'arracher les cheveux pour que les scripts Python du concours n'explosent pas la frontière des 16K (code + exécution confondus)...