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 124 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 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?
Citer : Posté le 13/02/2025 11:39 | #
Le code actuel de chargement n'est pas figé, on peut continuer à itérer sur différentes méthodes de chargement. En particulier on peut faire interagir MPM avec les add-ins, pourvu que ce ne soit nécessaire que pour les add-ins qu'on recompile.
Personnellement, je viserais de :
De cette façon, les vieux g3a, qui sont tous petits, pourront être chargés le plus loin possible et on limitera au maximum les interférences entre le code qui accède brutalement à 0x8c200000 et le système de chargement.
Pour les gros add-ins comme KhiCAS, toutes les tailles deviennent possibles jusqu'à 5 Mo peu ou prou (... modulo la place nécessaire pour décompresser, évidemment), et le restant de RAM est communiqué explicitement pour pouvoir être utilisé si le besoin se présente.
Et enfin, le jour où CASIO se met à utiliser cette zone de RAM, les add-ins qu'on aura déjà recompilés une fois s'adapteront automatiquement aux informations qu'une version à jour de MPM enverra qui contourne les zones utilisées par CASIO.
On peut toujours créer des variations, toutefois moins on en met mieux on se porte. Côté HollyHock ce problème se pose actuellement avec deux formats binaire et ELF et c'est chiant, alors qu'ils ont moins de programmes que nous. Surtout, si tu crées un autre format tu perds instantanément la compatibilité avec la 90+E. Je sais que toi tu as une version de KhiCAS par modèle mais le reste des programmes de Planète Casio bénéficie d'avoir un seul g3a pour tout le monde. Tu as sans doute vu le bordel que c'est sur mono avec les SH4 et la 35+E II ; faute de sources ou de versions génériques des libs y'a des g1a spécialisés partout, c'est un peu le bordel. Donc oui, on peut le faire, mais je ne crois pas qu'on en soit arrivés là encore. Note que c'est pareil pour la compression, mon espoir est de juste compresser un g3a ou la partie post-header d'un g3a et d'avoir quand même qu'une seule version du code pour tout le monde (le site pourrait offrir les deux téléchargements automatiquement en convertissant).
Je n'ai pas de certitudes sur le fait qu'il y a un format d'icône différent. L'OS est plus petit qu'avant dans tous les cas, ils ont de la place en rab'. Personnellement je ne suis pas très en faveur de décliner le format pour les raisons exprimées ci-dessus. Si on peut compresser les g3a entiers, sûrement ce sera déjà pas mal.
Citer : Posté le 13/02/2025 12:32 | #
Oui, si le g3a est entièrement compressé, la place occupée par les 2 icones va drastiquement diminuer sans rien faire de plus. Mais le code de l'affichage du mpm va etre plus compliqué puisqu'il va devoir faire une décompression partielle pour afficher les icones.
Fixer le début de la virtualisation du code à la taille de l'addin est effectivement optimal, c'est facile à coder et c'est facile pour moi de déterminer la fin de la zone ram utilisable meme sans interagir avec le MPM.
Tu penses vraiment que Casio va utiliser la zone de ram au-delà de 0x8c200000 de manière incompatible ? Moi j'en doute. Ca ne veut pas dire qu'ils ne le feront pas dans une de leurs apps, par ex. Python pour fournir un gros tas, mais qui est à nouveau disponible une fois sorti de leur app. Je ne vois pas de raison d'avoir des variables indispensables à l'OS en-dehors des zones qu'ils utilisent déjà.
Bon, en fait, je doute que Casio nous sorte beaucoup de nouveau sur la math+ maintenant, il y aura probablement des adaptations suite aux retours de l'utilisation de la math+ (avec à la clef une version 2.1), mais je parie que la priorité de la R&D porte sur une version monochrome pour cette rentrée ou la suivante.
Citer : Posté le 13/02/2025 12:34 | #
On ne le voyait pas non plus avec la 35+E II et on l'a regretté
Citer : Posté le 13/02/2025 13:08 | #
C'était surement pour une bonne raison?
D'ailleurs sur les monochromes, il risque d'y avoir plus de changement que sur les couleurs, j'imagine mal qu'on reste avec une résolution inférieure à la graph light...
Enfin bref on verra bien.
Citer : Posté le 13/02/2025 13:13 | #
Oui je m'attends pas à des masses mais c'est tout le paradoxe : on essaie d'anticiper des changements qu'on ne peut pas prédire.
Sur la 35+E II ils ont déplacé le tas, la pile, et le segment de données dans la RAM supplémentaire ; autant le tas on le voit venir pour Python, autant le reste y'avait pas de raison évidente.
Sur la Math+ il suffit qu'il reste des données vivantes dans le tas Python pour potentiellement tout casser. D'ailleurs j'ai pas essayé mais exécuter un add-in via MPM pendant que l'appli Python est utilisée crée sans doutes des problèmes puisque MPM ne ferme pas les applis natives quand il lance les add-ins.
Citer : Posté le 13/02/2025 13:25 | #
D'ailleurs pendant qu'on est sur la mémoire, MPM devrait peut être écrire des zéro dans la zone allouable car si on lance 2 fois un addin, on retrouve les valeurs stockées en RAM. Il me semble sur que la G90 ou la Prizm, lorsqu'on lance un addin, il y a eu une remise à 0 de la mémoire avant.
Quand je sors d'un addin avec "Extra RAM", je fais d'ailleurs très attention de rendre la main à l'OS en mettant des zéros dans la zone allouée.
Pour le fun, avec SDL_Tetris, si on le lance 2 coups de suite, on retrouve la position des anciennes pièces de la partie d'avant avant le reset des positions. Là c'est pas grave, mais ça pourrait être plus critique dans d'autres cas.
Citer : Posté le 13/02/2025 13:31 | #
On peut effectivement. Je note quand même au passage que si les programmes n'initialisent pas leurs données c'est un bug dans les programmes...
Au passage, la mémoire est initialisée par l'OS à 0x55 (pour les parties originellement dédiées aux add-ins).
Citer : Posté le 13/02/2025 13:36 | #
Yes, je suis 100% d'accord sur l'initialisation.
Oui le "zérotage" n'est pas à 0 mais à 0x55, qui nous vaut ce superbe bleu-vert lors d'un dupdate() sans rien de dessiné (0x5555)
Citer : Posté le 13/02/2025 14:04 | #
Sur la 35+E II ils ont déplacé le tas, la pile, et le segment de données dans la RAM supplémentaire ; autant le tas on le voit venir pour Python, autant le reste y'avait pas de raison évidente.
Ca s'est passé quand? Entre la version sans Python et la suivante?
Sur la Math+ il suffit qu'il reste des données vivantes dans le tas Python pour potentiellement tout casser. D'ailleurs j'ai pas essayé mais exécuter un add-in via MPM pendant que l'appli Python est utilisée crée sans doutes des problèmes puisque MPM ne ferme pas les applis natives quand il lance les add-ins.
Effectivement, il risque d'y avoir un problème si on relance Python juste après. Tu sais comment fermer l'app courante ? Sinon, il faudrait au moins le documenter, j'imagine que les autres apps ne posent pas ce problème, en tout cas celles présentes sur les fxcg10 et 20.
Citer : Posté le 13/02/2025 15:25 | #
Dès la sortie de la 35+E II, donc au passage entre la 75+E et la 35+E II.
Non je ne sais pas encore comment fermer l'app en cours. Mais je dois pouvoir le trouver.
Note aussi qu'il y a un problème si on utilise le menu de MPM quand l'appli MEMORY est ouverte sur l'onglet mémoire de stockage. Le tas est beaucoup plus plein dans ces conditions, donc malloc() peut fournir beaucoup moins de mémoire. Une version plus ancienne de mpm.bin stockait les headers g3a dans le tas et tombait à cours de mémoire dès 3-4 add-ins si utilisée lorsque MEMORY est ouverte (erreur -99). J'ai délayé le problème en utilisant de la RAM là où le code de mpm.bin est chargé pour avoir 8 add-ins de marge mais je pense que si tu en mets 12 et que tu ouvres le menu pendant que MEMORY tourne le problème revient.
Citer : Posté le 13/02/2025 16:26 | #
Dès la sortie de la 35+E II, donc au passage entre la 75+E et la 35+E II.
Ok, comme mon 1er portage en monochrome c'est sur la 35eii, c'est normal que je n'ai rien vu passer.
Ici je pense qu'on n'est pas dans la meme situation, le hardware est essentiellement identique depuis bientot 8 ans et je ne vois rien d'équivalent à l'arrivée de Python qui est sans doute pour beaucoup dans les changements de la 35eii. Difficile de deviner pourquoi Casio est passé de 2 à 8M d'ailleurs, peut-etre que c'était juste une précaution pour ne pas devoir changer de hardware au cas où ils en auraient eu besoin. Et puis ca ne devait pas etre beaucoup plus cher (quelques centimes?).
Pour en revenir à la mémoire, si tu arrives à trouver comment fermer l'app courante, ca devrait améliorer, non? Sinon il faut limiter le nombre d'addins en fonction de la place qu'il te reste dans entre 8c70 et 8c78.
Arka86 Invité
Citer : Posté le 16/02/2025 12:36 | # |
Fichier joint
Hello , déjà , félicitation à tous , je viens d'essayer l'installateur , malheureusement , j'ai ca comme sortie :
Calculator detected (005:010): UMS calculator (fx-CG, fx-CP400+, fx-GIII)
[2025-02-16 11:26:09 cahute error] find_win32_usb_device: CM_Get_Device_ID_ListA (disk drive) returned error 0x00000025.
[2025-02-16 11:26:09 cahute error] open_usb_link: libusb_open returned -12: LIBUSB_ERROR_NOT_SUPPORTED
cahute_open_simple_usb_link: CAHUTE_ERROR_UNKNOWN
La calculatrice se met sur l'écran du MPM mais ne répond plus a aucune touche
Apres l'avoir redémarré elle fonctionne de nouveau mais c'est toujours la même chose quand je lance l'installateur ...
Citer : Posté le 16/02/2025 12:43 | #
Alors... ça ça veut dire que Windows n'a pas associé le bon driver à la calculatrice, probablement.
Déjà pas d'inquiétude pour ta calculatrice tant que tu ne confirmes pas dans l'installeur il ne peut rien se passer de gênant.
Peux-tu aller dans le gestionnaire de périphériques et identifier le driver que Windows a collé sur la calculatrice ?
Citer : Posté le 16/02/2025 13:07 | #
Merci , ca devait être un problème de port USB ou de Windows , j'ai changé de pc , maintenant j'ai toujours une erreur mais l'installateur àl'air d'avoir fonctionné et Tetris fonctionne
Calculator detected (001:003): UMS calculator (fx-CG, fx-CP400+, fx-GIII)
Communicating more...
[2025-02-16 12:48:47 cahute error] receive_on_link_medium: USB device is no longer available.
Citer : Posté le 16/02/2025 13:09 | #
Cette erreur est inoffensive en effet. Amuse-toi bien !
Citer : Posté le 22/02/2025 07:36 | #
@Parisse J'ai essayé le système de chargement dynamique mais ça crashe dans pas mal de situations, typiquement si je lance deux add-ins à la suite. J'imagine que tu as dû le voir aussi. J'attends de trouver quelle partie de la méthode pose problème avant de fusionner, en attendant c'est sur une branche de test.