Posté le 02/12/2024 12:36
Pas encore clair 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. Quasiment garanti identique Probablement OK Pas clairPlanète Casio v4.3 © créé par Neuronix et Muelsaco 2004 - 2025 | Il y a 100 connectés | Nous contacter | Qui sommes-nous ? | Licences et remerciements
Planète Casio est un site communautaire non affilié à Casio. Toute reproduction de Planète Casio, même partielle, est interdite.
Les programmes et autres publications présentes sur Planète Casio restent la propriété de leurs auteurs et peuvent être soumis à des licences ou copyrights.
CASIO est une marque déposée par CASIO Computer Co., Ltd
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!
Citer : Posté le 11/02/2025 18:19 | #
J'ai compilé la version complète de KhiCAS, non compressée, en raccourcissant un peu la doc, ça prend 3.5M,
https://www-fourier.univ-grenoble-alpes.fr/~parisse/casio/mpm/mpmcasfr.g3a
Du coup il faut utiliser une version à nouveau modifiée du mpm.bin , par exemple compilée ici
https://www-fourier.univ-grenoble-alpes.fr/~parisse/casio/mpm/mpm.bin
Je l'ai compilé avec les paramètres suivants
static int load_addin(struct AddIn *addin)
{
if (addin->filesize > 0x380000-0x10000)
return -1001;
void *romAddress = (void *)0x8c390000;
void *ramAddress = (void *)0x8c780000;
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?!) */
for(int i = 0; i < 55; i++) {
MMU_Map((void *)0x00300000 + (i << 16), romAddress + (i << 16),
0x10000, i);
}
...
Si on a bientôt un décompresseur dans mpm.bin, il vaut probablement mieux ne pas modifier le mpm.bin général.
Citer : Posté le 13/02/2025 08:56 | #
Après réflexion, je pense que la solution optimale serait de virtualiser le code à partir de 0x8c200000 (à la place de 0x8c400000). En effet l'auteur de l'addin connait la taille de son addin, il peut donc utiliser de manière optimale la partie entre la fin de son addin et 0x8c700000 pour son propre usage, s'il a besoin de ram en plus de ce qu'il y a en 0x8c780000.
Citer : Posté le 13/02/2025 09:35 | #
On en a discuté avec SlyVTT. C'est le cas uniquement pour les add-ins recompilés pour MPM. Pour les autres, la taille est garantie inférieure à 2 Mo, et à l'inverse la zone 0x8c200000 a été régulièrement utilisée. Donc ça casserait les vieux add-ins.
L'approche sur laquelle on s'est arrêtés est de laisser MPM communiquer à l'add-in quelle zone il reste après le chargement et ensuite l'add-in se débrouille. Techniquement on peut déjà le faire en lisant le MMU. Mais surtout c'est plus future-proof vis-à-vis du fait que CASIO est quasiment certain d'utiliser toute cette RAM dans le futur. Quand ça se produira, avoir isolé la responsabilité de découper la mémoire dans le loader évitera d'avoir de nouveau à recompiler dans tous les sens.
Citer : Posté le 13/02/2025 11:12 | #
Mais le début actuel en 0x8c400000 n'est pas compatible avec KhiCAS full (meme après avoir supprimé la doc complète), sauf si on peut écraser le code du MPM en 0x8c700000, mais cela suppose de revenir directement au menu principal. Comment peut-on faire vu que return redonne la main au MPM?
Une autre idée serait d'avoir 2 extensions reconnues par le MPM, la g3a resterait comme actuellement, et une autre, par exemple g2a ou bien mpm, qui serait virtualisée en 0x8c200000, voire meme pas virtualisée ?
Et d'ailleurs, si on a une extension différente, on pourrait peut-etre y utiliser le nouveau format graphique que Casio utilise pour les icones, qui a l'air nettement plus compact, as-tu une idée de comment il fonctionne?
Casio a maintenant 4 icones par entrée du menu principal, probablement pour afficher hors et en mode examen, sélectionné ou non. Sauf erreur de ma part, avec l'ancien format qui prend 0x2e00 octets par icone, ca ferait 0x2e00*4*20=942080 octets, du coup ils ont du trouver que ca prendrait trop de place. Sur un petit addin, le poids des icones est relativement important, cela occupe 0x6000 octets = 24K, pouvoir utiliser le meme format pourrait etre intéressant, non?