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 10/02/2025 11:48 | #
Si tu as installé un g3a tu le trouveras dans le menu des add-ins qui s'ouvre avec TOOLS dans le menu principal.
Je réalise que j'ai rien écrit à ce sujet, oups. >_>
Note que la compatibilité est très limitée pour le moment, le mod est plus prévu pour les développeurs.
Citer : Posté le 10/02/2025 11:49 | #
Quelle est l'extension du fichier ?
C'est normal que tu ne puisses pas le lancer depuis la mémoire, c'est pour ça qu'il y a le MPM justement.
Est-ce bien un fichier .g3a ?
Tu l'as copié dans la mémoire de stockage (comme sur une clef USB) ?
Citer : Posté le 10/02/2025 12:04 | #
Un grand merci, ça marche, je ne savais juste pas comment voir les add-ins, vu que je n'ai jamais eu à me poser la question sur Graph Math+, en effet, un petit mot dans le texte serait pas mal !
Citer : Posté le 10/02/2025 12:05 | #
@Herlock, en ce qui concerne micropy version mpm, il devrait fonctionner à peu près, mais il y a encore des éléments d'interface à adapter : les dialogues F1/F6 par exemple, où la ligne d'état qui n'apparait pas (apparemment les adresses des syscalls correspondants ne fonctionnent pas, ou alors il écrit en noir sur fonds noir...)
Je vais travailler sur la version light de khicas, et je reviendrai sur micropy ensuite, et si GetKeyWait marche avec khicas, je l'utiliserai aussi pour micropy.
Citer : Posté le 10/02/2025 12:13 | #
Merci ! Je vais pas trop pousser avec micropy alors !
Citer : Posté le 10/02/2025 13:24 | #
Bonne nouvelle: GetKeyWait permet de reconnaitre ON.
Il faudrait modifier le source du mpm.bin de la manière suivante:
static int load_addin(struct AddIn *addin)
{
if(addin->filesize > (2 << 20))
return -1001;
void *romAddress = (void *)0x8c400000;
void *ramAddress = (void *)0x8c680000;
int fd = CW_BFile_Open(addin->path, CW_BFile_ReadOnly);
if(fd < 0)
return fd;
/* Skip the header, load only the code */
int read_size = addin->filesize - 0x7000;
int rc = CW_BFile_Read(fd, romAddress, read_size, 0x7000);
CW_BFile_Close(fd);
if(rc < 0 || rc != read_size)
return rc;
/* Map the entire range (why the heck not?!) */
#if 1
for(int i = 0; i < 32; i++) {
MMU_Map((void *)0x00300000 + (i << 16), romAddress + (i << 16),
0x10000, i);
}
#else
for(int i = 0; i < 2; i++) {
MMU_Map((void *)0x00300000 + (i << 20), romAddress + (i << 20),
0x100000, i);
}
#endif
...
Détail des modifs: au début, la taille du fichier max passe de 1 à 2M (en fait on devrait pouvoir passer à 2.8M dans la config expliquée ici)
Adresse de la ram: passe de 0x8c580000 à 0x8c680000
Et j'ai doublé le nombre de mappings du mmu pour mapper 2M au lieu de 1M. D'après loader.h, on peut probablement utiliser la version #else avec juste 2 mappings de 1M au lieu de 32 mappings de 64K, mais comme je n'y connais rien, je préfère laisser ceux qui s'y connaissent agir.
Ce serait sympa que le mpm.bin fourni par défaut intègre ces changements pour supporter des addins de 2M.
Il me reste à générer les tableaux de keystrokes de la math+ pour khicas, on devrait bientôt avoir un prototype.
Citer : Posté le 10/02/2025 13:49 | #
Faut que je regarde les adresses mais oui bien sûr je vais intégrer ça. La taille maximale devrait être du genre 3 Mo même, parce que la version complète de KhiCAS est encore assez grosse right?
Ouf pour GetKeyWait(), c'est rassurant que la touche soit pas perdue.
Citer : Posté le 10/02/2025 14:10 | #
La version complète de khicas en 1 seul bloc, c'est 3.8M non compressé. Mais comme on n'a que 4.5M de flash, il vaudrait quand même mieux compresser, ce qui prend 2.4Mo. Problème actuellement, j'ai seulement du code qui décompresse en un seul bloc, de ram vers ram, donc il faudrait 2.4+3.8Mo de ram, et là on ne tient plus. Il faut donc implémenter de la décompression par morceaux, sans avoir besoin de 2.4Mo de buffer RAM pour stocker le fichier compressé. Tu as déjà implémenté ça?
Citer : Posté le 10/02/2025 14:20 | #
Ça dépend des algos de compression. Si tu sors une lib toute faite il doit généralement y avoir un moyen de fournir l'entrée par morceaux. Personnellement j'ai déjà codé une version simplifiée de gzip et je garde un oeil dessus au cas où les performances soient pas assez bonnes (optimiser à la main pour la calto peut améliorer les résultats). Dans gzip tu n'as pas besoin de l'entrée précédente, tu n'as à tout instant besoin que d'avoir la totalité du fichier décompressé. Vu que les libs classiques sont aussi utilisées sur le réseau, elles savent certainement faire.
Citer : Posté le 10/02/2025 14:23 | #
Oui, miniz.h/.c sait faire. C'est juste qu'il faut le faire et si quelqu'un l'a déjà fait, autant réutiliser. Et puis à mon avis ça serait plus à sa place dans mpm.bin que dans khicas, parce que ça permettrait de compresser plusieurs addins sans dupliquer de code. Peut-être que Slyvtt a déjà ça?
Citer : Posté le 10/02/2025 14:25 | #
Ah ça va carrément dans mpm.bin à mon avis oui, en effet.
Citer : Posté le 10/02/2025 14:41 | #
Voilà un premier proto de khicas version light. Je n'ai pas encore eu le temps de nettoyer l'UI, donc les menus sont trop courts (à cause de la nouvelle fonte), les touches de la ligne du haut devraient fonctionner sauf bien sur up/F4 (je remplacerai sans doute la légende cmds correspondant à up par une légende vide).
https://www-fourier.univ-grenoble-alpes.fr/~parisse/casio/mpm/mpmcas.g3a
Les calculs ont l'air de fonctionner normalement pour le peu que j'ai eu le temps de tester. Taper HOME EXE EXE pour quitter (ou à partir du menu F6 up EXE).
J'ai aussi un problème avec la ligne d'état, rien n'apparait, il va falloir que je remplace les appels aux syscalls correspondants par un printmini.
Citer : Posté le 10/02/2025 18:45 | #
J'ai modifié les adresses d'une façon qui permet de monter jusqu'à 3 Mo dans l'immédiat.
Citer : Posté le 10/02/2025 19:18 | #
J'ai pas pu mettre en pratique, mais la zlib a une possibilité de travailler sur un buffer "tournant" qu'on alimente en chargeant un fichier par exemple par morceaux depuis la flash et qui décompresserait en RAM.
La zlib implémente des "z_stream" justement pour cela. Logiquement le flux de sortie est orienté vers un fichier, mais on doit pouvoir détourner vers une adresse en RAM sans problème.
l'exemple ici fait ça de fichier vers fichier, mais si on oriente la sortie vers un buffer en RAM ça doit passer : https://terminalroot.com/how-to-use-the-zlib-library-with-cpp/
Citer : Posté le 10/02/2025 20:03 | #
J'ai modifié les adresses d'une façon qui permet de monter jusqu'à 3 Mo dans l'immédiat.
Du coup, la ram de l'addin est en toute fin, j'en déduis que tu n'as plus de crainte d'interaction avec l'OS?
Citer : Posté le 10/02/2025 20:07 | #
Y'a pas de meilleur moment pour essayer~
Citer : Posté le 10/02/2025 20:46 | #
En effet!