Mod Math+
Posté le 02/12/2024 12:36
Comme annoncé pour le
Puzzle de l'Avent, un mod Math+ non-officiel est en cours de développement pour permettre d'écrire des add-ins sur la Math+.
Le mod n'est pas encore public du fait qu'il n'y a pas encore les sécurités nécessaires pour bien empêcher qu'on en abuse. Mais les questions techniques sont partiellement résolues et on commence à avoir une vue raisonnable de ce qu'on va pouvoir, ou pas, faire sur la Math+.
La préoccupation principale est
si les .g3a existants vont marcher tels quels, ou
compatibilité binaire. Ce serait le pied, mais c'est pas encore clair si on peut parce que la table des syscalls n'existe plus.
Par ce topic je souhaiterais savoir ce que la communauté voudrait voir dans un tel mod et discuter de la faisabilité technique. Y a-t-il des choses qui posaient problèmes sur la 90 que vous voudriez améliorer ? Des soucis attendus avec la Math+ que vous voulez voir adressés ? J'ai déjà quelques idées en tête, mais je vous laisse vous exprimer.
—
Liste de préoccupations :
- Compatibilité binaire :
Pas encore clair
Si on peut l'avoir, c'est super. Sinon, y'a un casse-tête à attendre pour traquer quels add-ins sont compatibles. L'absence de table de syscalls est le principal souci ici, ce qui peut peut-être se contourner avec un coup d'UBC pour intercepter les appels.
- Compatibilité de la disposition clavier : Pire cas, en recompilant
Syscalls + GetKey() : les codes sont adaptés, certaines touches disparaissent, d'autres sont nouvelles.
gint sans recompiler : j'ai un trick en tête mais il vaut mieux imaginer que ça va donner des mauvais résultats.- gint en recompilant : la compatibilité sera assurée.
- Reste du matériel : Quasiment garanti identique
Il faudrait qu'un truc très gros m'ait échappé.
- RAM étendue : Probablement OK
Il y a de la mémoire après les 2 premiers Mo, pas sûr cependant de si l'utiliser interférera avec l'opération normale de l'OS.
- Récupérer 16 Mo de mémoire de stockage : Pas clair
Il faut que ça marche en pratique et c'est dur d'écarter tous risques de brick. Et je sais pas comment faire techniquement parlant.
Citer : Posté le 02/12/2024 12:45 | #
Partant du principe que l'on peut faire tourner un g3a sur math+, il me semble que le souci premier sera le changement de layout du clavier.
Les touches F1 a F6 ayant disparu.il faudra revoir pas mal de mécanique et d'addins (par exemple gintctl, Prune, ...).
Toujours avec le clavier, un truc chiant était le ghosting, mais ça vient du matériel donc je sais pas si la conception de la math+ souffre de ça aussi.
J'ai plus en tête si il y a un serial 3pin sur la math+.
Y'a aussi la ram étendu qu'il faudra checker. Au pire on fera comme avec la prism cg10/20.
Citer : Posté le 02/12/2024 12:48 | #
Pour le clavier, ça "devrait aller". GetKey() adapte ses codes de touche donc les add-ins à syscalls, s'ils marchent, continueront de marcher sur les touches fléchées, SHIFT, ALPHA. Les quelques touches sans correspondance seront perdues, par contre.
Pour gint, il faudra recompiler. Je peux vaguement imaginer une astuce pour rétablir le layout mais je suis pas sûr que ça marche bien. Mais recompiler irait. Ça invite à ajouter un flag dans le g3a pour dire s'il est compilé pour la Math+ ou juste 90.
De ce que j'ai pu voir, la RAM étendue ça a l'air de passer.
Citer : Posté le 02/12/2024 12:53 | #
J'ai plus en tête si il y a un serial 3pin sur la math+.
Il y a, mais il ne sert plus qu'à désactiver le mode examen.
L'application Lien/Link pour les transferts de données n'est plus présente, tout comme l'application E-CON4 pour l'acquisition de mesures physiques via une interface compatible comme le C-LAB.
Nous avons tenté malgré tout de transférer depuis une autre calculatrice, ce qui ne marche pas, et de mémoire il me semble que le comportement de l'erreur diffère, ce qui pourrait signifier qu'ils ont également sabré des branches entières du protocole, et qu'il y aurait donc peu de chances que cela revienne plus tard.
Citer : Posté le 02/12/2024 12:55 | #
Notez que gint s'en fout si le protocole est codé. Tout coder en freestanding a ses mérites, heh.
Citer : Posté le 02/12/2024 13:30 | #
Oui comme a priori le proc est le même, le module serial de gint (cough, cough !!
Citer : Posté le 02/12/2024 13:41 | #
Pour ceux qui se demandent, la Math+ est avant tout un reskin de la 90+E. Ça ira beaucoup, beaucoup plus vite de lister les différences que les points communs. Le matériel est le même sauf le clavier, le CPU est le même, MPU est le même...
Citer : Posté le 02/12/2024 14:27 | #
Alors concernant KhiCAS, les deux premiers points auxquels je pense sont :
1/ est-ce que la taille de flash user va rester à 4.7Mo ou bien peut-on imaginer utiliser une partie de la flash non utilisée par l'OS mais non accessible normalement? Actuellement la version complète de KhiCAS occupe 4.3M, ça laisse bien de la place sur les 90, mais sur les math+ 4.7-4.3 reste 400K
2/ est-ce qu'on pourrait éviter la limite des 2Mo d'un addin et donc ne pas avoir à recopier une partie du code en RAM?
Sinon, si on a compatibilité binaire ce serait très intéressant. En ajoutant des codes touches pour les nouvelles touches de la Casio (c'est ce que je fait pour gérer les autres calculatrices avec une grande base de code commun pour l'UI), on pourrait gérer la 90 et la math+ correctement.
Citer : Posté le 02/12/2024 14:32 | #
Pour 1/, c'est un peu compliqué. Revenir à 16 Mo semble possible sur le plan de l'expérience de pensée. Mais il est probable que ça casse à chaque mise à jour de l'OS, avec au meilleur cas besoin de sauvegarder + restaurer les fichiers, pire cas bricker la calto.
Par contre, on peut compresser les g3a. Il se passe quoi si tu gzip le fichier de 4.3 Mo ?
Pour 2/, le loader va probablement charger le code en RAM de toute façon, auquel cas la limite de 2 Mo devrait pouvoir sauter oui. Je sais pas si c'est raisonnable/possible d'exécuter depuis la ROM, je regarderai. En tous cas exécuter depuis la ROM est incompatible avec la compression.
Citer : Posté le 02/12/2024 15:31 | #
Oui, j'y pensais aussi, compresser la partie de l'addin qui est recopiée en RAM est certainement faisable. Ca gagne environ 800Ko de flash (2.2Mo -> 1.4Mo), et on se retrouverait avec environ 1.2Mo de libre pour la version complète de KhiCAS. C'est mieux.
Citer : Posté le 02/12/2024 15:34 | #
Et si tu charges tout en RAM ? On a assez de RAM, enfin à moins que tu utilises déjà tout pour les données dans KhiCAS, mais je ne crois pas ?
Citer : Posté le 02/12/2024 17:23 | #
Gain de 850Ko environ en flash mais il faut 2M de RAM en plus. Or dans la config actuelle, je n'ai que 512K de libre en RAM pour le tas, pris à partir de l'adresse 0x8c480000 (la 2ème partie de l'addin est chargée en 0xac200000, avec de la marge pour jusqu'à 2.5M). Il y a peut-être plus de disponible?
Citer : Posté le 02/12/2024 17:30 | #
Si on s'aventure un peu plus la zone à 0x8c200000 fait en réalité 6 Mo, donc oui a priori y'a de quoi.
Si je lis bien tu gagnes donc 800 ko + 850 ko en compressant la totalité, soit 3.1 Mo pour KhiCAS complet ? Ça semble pas trop mal, 34% de réduction.
Je viens de tester sur quelques add-ins que j'ai sous la main, avec gzip :
Si dans le cas moyen on est dans les 40% ça donnerait une capacité "réelle" de 7.5 Mo de stockage.
Citer : Posté le 02/12/2024 17:35 | #
I used the miniz library for in-memory decompression in my Calibrate add-in, and it worked well. Source code: https://git.planet-casio.com/calamari/Calibrate
ETA: In particular, see this line (ignore the text of the error message, the file was already read into memory and closed): https://git.planet-casio.com/calamari/Calibrate/src/commit/9ace765efe072f17b2a2dbb7933f4fd2fd433af9/src/main.c#L43 and the lines here: https://git.planet-casio.com/calamari/Calibrate/src/commit/9ace765efe072f17b2a2dbb7933f4fd2fd433af9/src/main.c#L52
And here is how I determined the value of C_IMAGE_SIZE https://git.planet-casio.com/calamari/Calibrate/src/commit/9ace765efe072f17b2a2dbb7933f4fd2fd433af9/src/compress-image.c#L69
“They call me the king of the spreadsheets, got 'em all printed out on my bedsheets.” — “Weird Al” Yankovic
Citer : Posté le 02/12/2024 19:39 | #
Du coup, je peux remplacer 0x80000 par 0x380000 sur la 90 dans le code suivant:
ram3M.start=0x8c480000;
ram3M.end=ram3M.start+0x80000;
Comment vont se lancer les addins sur la math+? Depuis le menu principal j'imagine, mais du coup tu dois probablement détourner l'affichage des icones et capturer l'appui sur entrée pour lancer le g3a. Donc c'est qqchose qui pourrait être rendu transparent, en décompressant les addins compressés à la volée vers une zone fixe en RAM, 0x8c20000 par exemple. Ensuite je pourrais utiliser kmalloc pour accéder au reste de la ram à partir d'une adresse calculée avec la taille de l'addin non compressée.
Citer : Posté le 03/12/2024 09:22 | #
Pour 1/, c'est un peu compliqué. Revenir à 16 Mo semble possible sur le plan de l'expérience de pensée. Mais il est probable que ça casse à chaque mise à jour de l'OS, avec au meilleur cas besoin de sauvegarder + restaurer les fichiers, pire cas bricker la calto.
Il suffit de patcher la taille dans le code d'initialisation du système de fichiers.
Il serait souhaitable qu'un patch en ce sens soit intégré, avec si besoin vérification du modèle (uniquement Graph Math+ voir fx-CG100, et pas fx-1AU Graph).
Car le problème de taille sera très loin d'être résolu par la simple gestion de .g3a compressés. Nombre de jeux ne pourront plus rentrer correctement. Je peux citer :
Par mon expérience sur Graph 90+E, il n'y a pas de raison qu'une mise à jour casse quelque chose.
Il n'y a pas de vérifications spécifiques du système de fichiers lors d'une mise à jour.
Le système de fichiers n'est réinitialisé (avec dans le cas qui nous concerne ici un redimensionnement qui ferait perdre tous les fichiers) :
Une alternative si tu n'oses pas toucher au code Casio figeant désormais le système de fichiers à 4.5M, ce serait de créer un 2e système de fichiers dans les 11.5M suivants qui ne servent désormais plus à rien.
Et des add-ins / bibliothèques pour le gérer (accès, copie/déplacement de fichiers entre les 2 systèmes de fichiers, etc.).
Citer : Posté le 03/12/2024 09:25 | #
ROMs pour émulateur Nintendo NES et Game Boy
Des ROMs NES sont très petites habituellement. Les jeux les plus anciens dessus tenaient sur 24,6 Ko.
Citer : Posté le 03/12/2024 09:27 | #
Très bien je supprime, mais ce n'était qu'un exemple parmi d'autres, et cela ne change rien à la problématique.
À la place, pense aux Game Boy Color plutôt, et compte en mégaoctets.
Citer : Posté le 03/12/2024 09:30 | #
Après oui bien sûr certains jeux NES peuvent être plus gros aussi, comme par exemple SMB3…
Citer : Posté le 03/12/2024 09:36 | #
Je parle bien évidemment des ROMs problématiques, qui bien souvent concernent les jeux les plus intéressants/populaires.
Je ne dis pas qu'aucune ROM ne va rentrer.
Mais le plus caractéristique du problème c'est Doom, où déjà rien que le .wad très incomplet du shareware fait 4.1M ; c'est-à-dire que si il rentre, il ne rentrera quasiment plus rien d'autre.
Nous avons une version allégée (avec entre autres suppression de tous les éléments relatifs à la musique et aux bruitages), mais qui fait malgré tout 3.2M.
Faire rentrer un .wad commercial complet relèverait à ce jour de l'impossible si l'on ne touche pas au système de fichiers.
Citer : Posté le 03/12/2024 10:04 | #
Donc si je comprends bien actuellement l'OS tient dans 16Mo en 1ère partie de flash, suivi par 4.7Mo de flash user et 11.5M de flash inutilisée. Est-ce que c'est comme ca sur la fxcg50 australienne ? Sait-on où vont se trouver les ex-addins Casio qui seront ajoutés dans la version 2? Dans la partie système des 16M ou dans les 11.5 de flash actuellement inutilisée? Dans les deux cas, je ne vois pas bien pourquoi on se priverait d'utiliser une partie de ces 11.5M de flash, quel serait le risque? Il sera toujours temps de changer si une mise à jour Casio remettait cela en question non?
Petite remarque au passage: je ne crois pas que Casio pourrait prendre le risque de "punir" une utilisation de ces 11.5Mo de flash. Une action malveillante sur le bon fonctionnement d'autres logiciels est un délit punissable de 5 ans d'emprisonnement.
https://www.legifrance.gouv.fr/codes/section_lc/LEGITEXT000006070719/LEGISCTA000006149839/#LEGISCTA000006149839