MPM : Mod add-ins 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 31/01/2025 15:48 | #
il faut preciser la branche dev du depot :
giteapc install fxlibc@dev
Citer : Posté le 31/01/2025 15:56 | #
Merci, ce coup ci ça a fini par compiler.
Citer : Posté le 31/01/2025 16:04 | #
Oups, pardon pour les instructions un peu à l'arrache. Merci Sly @_@
Citer : Posté le 31/01/2025 17:21 | #
Du coup, si j'ai bien compris, on va avoir
1/ un installer windows qui se charge de modifier l'OS, un peu comme l'installer windows de Casio qui permet de changer de version d'OS
2/ mpm.bin à mettre en flash user, et qui sera exécuté quand on tape sur TOOLS depuis Home. Ce mpm.bin se charge alors de lister les addins présents en flash user, et de les lancer.
Une fois mpm.bin installé, il n'y a rien à changer si on ajoute un addin en flash. Correct?
Citer : Posté le 31/01/2025 17:36 | #
Oui, et oui ! Et comme la plupart des fonctionnalités sont dans mpm.bin, notamment la partie taille limite des add-ins, compression, chargement en RAM ou pas, compatibilité syscalls, raccourcis clavier, etc. il sera possible de le mettre à jour et de le personnaliser au fur et à mesure
Citer : Posté le 31/01/2025 22:22 | #
Et au fait le jailbreak est sur la base de quel OS ? la v1 ou la v2.
J'ai pas MaJ ma machine en v2 car je savais pas trop, mais il manque carrément 1 milliard de trucs
Citer : Posté le 31/01/2025 22:30 | #
Le mod est compatible avec les deux. Passez en v2.
Citer : Posté le 01/02/2025 09:52 | #
bon j'ai MaJ et j'en ai profité pour me faire une machine virtuelle propre en win11 pour pouvoir faire les install.
Cette fois ça a bien voulu fonctionner.
Citer : Posté le 01/02/2025 11:10 | #
En regardant fichier casiowin.yaml, je vois une liste partielle d'ancien syscalls avec 2 adresses qui correspondent je suppose à la v1 et à la v2. Ce qui n'est pas clair pour moi c'est
1/ est-ce la liste complète des anciens syscalls dont on a les adresses actuellement (ça me parait le plus probable) ou seulement la liste des syscalls qui sont utilisés par le mpm ?
2/ est-ce que la compatibilité binaire fonctionne déjà avec le mod actuel pour ces anciens syscalls? Je veux dire par là est-ce que le mod change le code en flash à l'adresse 0x80020070 et reconnait par exemple un appel au syscall 0x0EAB, puis renvoie vers GetKey, 0x8012ea7a en version 1 et 0x801d2bba en version 2?
3/ Et je suppose que la mise à jour du mpm n'aura pas d'influence sur cette compatibilité binaire, i.e. la découverte des nouvelles adresses d'autres anciens syscalls et la mise à jour du yaml ne permettra pas la compatibilité binaire sur les syscalls ajoutés, ça nécessitera une mise à jour de l'installeur windows, correct? (Sinon, ça supposerait de conserver précieusement le code exécutable du MPM dans le dernier Mo de la ram...).
Citer : Posté le 01/02/2025 11:42 | #
1/ C'est seulement la liste de ceux utilisés par MPM. Il y a totalement moyen d'en trouver d'autres, j'ai même des outils semi-automatiques pour le faire, c'est juste après sur la TODO list.
2/ Non, c'est pas codé encore. Côté bonne nouvelle par contre ce sera pas implémenté par un changement de l'OS mais avec l'UBC. La différence c'est qu'en gros la compatibilité sera assurée par mpm.bin. Pas besoin de réinstaller le mod via Windows à chaque fois qu'on veut rajouter un syscall, il suffira de recompiler et retransférer mpm.bin.
Enfin, léger détail : j'ai pas encore fait marcher l'émulation de syscalls, je suis confiant que ça va marcher, mais c'est pas fait. Donc petite astérisque.
3/ Incorrect, il suffira de mettre à jour mpm.bin pour avoir les nouveaux syscalls. Et oui MPM laissera du code traîner, je sais pas encore où, mais c'est pas un problème.
Citer : Posté le 01/02/2025 11:42 | #
Je vois un truc qui va être gênant pour moi, la taille des addins supportés semble limitée à 1.5Mo, dans main.c, load_addin je vois:
void *romAddress = (void *)0x8c400000;
void *ramAddress = (void *)0x8c580000;
Donc si je comprends bien, la rom est mappée vers 8c400000 (1.5Mo) et les 0.5Mo qui suivent sont utilisés pour mapper la ram. Ce qui veut dire que pour KhiCAS, j'aurais plutot intérêt à ne pas utiliser load_addin en l'état dans main, mais recompiler avec un fichier pour le loader plaçant directement la rom en ram et la ram ailleurs qu'en 0x8c580000, et donc sans mécanisme de mapping.
Par contre du coup, ça m'interroge sur comment l'OS de la 90 mappe les addins, je n'ai pas l'impression qu'ils recopient en RAM, si ? C'est possible de mapper secteur par secteur directement depuis les adresses physique en flash user ?
Citer : Posté le 01/02/2025 11:45 | #
void *romAddress = (void *)0x8c400000;
void *ramAddress = (void *)0x8c580000;
C'est pour les tests que j'ai faits pour l'instant. Cette disposition n'est pas finale ; j'ai bien l'intention de monter la taille ensuite. L'intention est vraiment qu'un seul mpm.bin marche pour tout le monde donc l'approche par défaut c'est plutôt que si KhiCAS a besoin de quelque chose qui n'est pas possible, on modifie le mpm.bin de tout le monde pour le rendre possible.
L'OS 90+E mappe effectivement cluster par cluster, la difficulté c'est qu'en gros la taille de mappings est limitée à 220 ko dans cette configuration donc il faut tout un système pour rajouter des mappings à la demande pendant que l'add-in s'exécute, ce qui est plus dur. C'est envisageable, mais dans un second temps. Si KhiCAS peut se charger en RAM c'est vraiment plus facile.
Citer : Posté le 01/02/2025 11:46 | #
P.S.: ça veut dire quoi UBC?
Citer : Posté le 01/02/2025 11:49 | #
User Break Controller, essentiellement une sorte de debugger intégré. En gros mpm.bin va poser un breakpoint à 0x80020070 et fera l'émulation de syscall dans le gestionnaire de ce breakpoint.
Citer : Posté le 01/02/2025 11:54 | #
Ok, je pense aussi que le mieux sera de charger khicas directement en ram, vu que vous m'avez convaincu de le stocker en compressé. Il va probablement falloir que j'optimise le code de décompression utilisant miniz.h/.c, car actuellement il suppose que l'image compressée est complètement chargée en mémoire, mais ça suppose d'avoir 6.5M de mémoire dispo (2.4 pour l'image compressée, 4 pour la décompressée). Il est surement possible de lire le fichier compressé par slices, de 128K par exemple.
Le fait que les syscalls ne sont pas encore émulés + ces contraintes techniques => ça va prendre du temps!
Citer : Posté le 01/02/2025 13:12 | #
J'ai l'impression que le plus facile pour moi, dans un premier temps en tout cas, c'est de recompiler juste la libfxcg du prizm-sdk en remplaçant le répertoire syscalls par un fichier source c contenant les adresses connues en version 2 des syscalls, et en ajoutant des implémentations ne faisant rien pour celles qui ne sont pas connues.
Un truc du genre:
int (*GetKey)(int*key)=0x801d2bba;
...
Si le casiowin.yaml n'est pas complet, existe-t-il une liste plus complète des syscalls connus en version 2?
Merci!
Citer : Posté le 01/02/2025 13:58 | #
Tu peux plutôt utiliser casiowin_gen.py et ajouter casiowin.S et casiowin.h à ton projet, ça devrait limite aller plus vite. Faut juste appeler CASIOWIN_SetAPI(1) pour sélectionner l'OS 2.00. Plus tard il faudra se poser la question de si on porte libfxcg proprement.
Il n'y a pas d'autres syscalls connus, mais si tu en as des précis que tu cherches tu peux m'en filer une liste et je peux faire un premier retour rapide facilement.
Citer : Posté le 01/02/2025 14:59 | #
Dans l'état actuel, pas sur, parce que je risque de faire les choses pas correctement avec le code assembleur, et il me faudra de toutes façons la même liste sans les CW_ pour recompiler sans changer le source, et il va y avoir la liste des autres syscalls à ajouter. Une macro emacs depuis l'output inc devrait faire partiellement le boulot, puis complétion des en-têtes.
Je vais essayer de voir ce que ça donne comme ça, et ça me permettra de dire ce qui me manque le plus... A vue de nez, ce serait bien d'avoir GetSetupSetting, SetSetupSetting (pour afficher correctement les menus du bandeau en bas), OS_InnerWait_ms (mais on peut toujours faire une boucle sinon), la gestion des timers (sinon le controle d'interruption va être par du polling), éventuellement mais c'est moins important la gestion de la RTC pour afficher l'heure dans le shell. Sinon je pense que le reste doit pouvoir se dupliquer en C, par ex. la gestion du statusarea
Citer : Posté le 01/02/2025 15:29 | #
Pour la gestion des "CW_" tu peux faire des alias dans un fichier header, ce sera moins "bourrin" que de devoir refaire ton fichier de conversion vers les syscalls. Ça t'évitera surtout de devoir faire une version de ce fichier par version d'OS, car tu n'as pas la garantie que ça ne va pas bouger dans le temps. casiowin.h sert justement à ça si je comprends bien.
Citer : Posté le 01/02/2025 15:35 | #
Le préfixe CW est ajouté par casiowin_gen.py tu peux juste l'enlever du code Python. Mais comme tu préfères. Je regarde les syscalls que tu as listés, sachant que s'ils ont changé sur la Math+ (probable dans le cas de trucs comme la barre de statut) je les aurai pas forcément. Je te dis.
Citer : Posté le 01/02/2025 16:14 | #
Edité pour réussir à compiler, avec plein de fonctions fantomes.
Voilà mon fichier actuel, qui bien sur ne marchera qu'avec la version 2 de l'OS, j'espère qu'il n'y a pas d'erreurs, il y a 3 références qui me sont inconnues, MMPrintRef, UpdateBatteryState et INTERNAL_USBPopup
https://www-fourier.univ-grenoble-alpes.fr/~parisse/casio/mpm/syscalls.c