Posté le 15/07/2018 12:09
Planète Casio v4.3 © créé par Neuronix et Muelsaco 2004 - 2024 | Il y a 241 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
ljf Invité
Citer : Posté le 05/10/2022 18:16 | #
Et toujours : fx-CG50, os 3.60.0202
Citer : Posté le 06/10/2022 20:41 | #
Bizarre, sur ma 90 ca fonctionne.
Avez-vous des variables définies (VARS)?
Essayez de supprimer le fichier session.xw dans la mémoire de stockage pour voir, peut-être qu'il y a une variable qui interfère avec le mécanisme de chargement des figures.
ljf Invité
Citer : Posté le 07/10/2022 16:10 | #
Pas de changement. VARS = vide. Fichier session.xw supprimé. Avec ou sans accélération, en XCas ou en Python le résultat est le même.
Citer : Posté le 10/10/2022 13:13 | #
Je n'arrive toujours pas à reproduire de crash. Je mets en téléchargement une version où j'ai accéléré l'affichage d'une figure 3d vide et corrigé un bug dans l'afficheur 3d pour une figure vide. Est-ce que le crash est toujours là?
ljf Invité
Citer : Posté le 16/10/2022 19:03 | #
Plus de crash. Ce devait bien être le bug dans l'afficheur 3d la cause du crash.
Citer : Posté le 27/11/2022 16:43 | #
En regardant la facon dont ExistOS, un OS entierement libre pour la hp39gii, gere la memoire, j'en viens a me demander s'il y aurait une possibilite technique de programmer le mmu directement nous meme, et donc de creer un lanceur d'addin pouvant gerer un fichier de taille > 2Mo, ce qui permettrait de liberer 2.5Mo de RAM pour KhiCAS...
Si c'est possible, c'est surement difficile a faire ceci dit. Mais ca pourrait aussi etre un premier pas vers un OS completement libre sur Casio.
Citer : Posté le 27/11/2022 17:26 | #
C'est parfaitement possible en théorie. Mais l'histoire a montré par AHelper qu'une mauvaise configuration du MMU peut bricker une calto (dans son cas une Prizm) de façon permanente, en particulier si un crash/reset se produit avant que l'on ne remette le MMU dans sa configuration normale. Par conséquent, je suis très réticent à attaquer cette idée.
Citer : Posté le 27/11/2022 20:45 | #
Effectivement, il faut avoir une solution en cas d'erreur sinon c'est beaucoup trop risque. Les hp39gii semblent imbricables, il y a un firmware rescue qui se lance et permet de flasher en bootant avec ON appuye (comme sur les Numworks non verrouillees ou reset+6 active le firmware de ST). Les hp39gii sont sorties en 2012, il n'y a vraiment rien d'equivalent sur des Casio sorties bien apres?
Citer : Posté le 27/11/2022 22:09 | #
Il est impossible de savoir car personne n'a reproduit le problème en question. Mais je crois que l'OS udpate, qui est l'équivalent direct des options que tu mentionnes, avait été tenté sans succès (ce ne serait pas la première fois qu'il échoue, puisqu'il faut boot de façon standard jusqu'à un certain point pour y avoir accès). Refouiller les threads d'époque le révélerait peut-être...
ljf Invité
Citer : Posté le 27/12/2022 18:08 | #
Après màj --> 3.70 Khicas plante à nouveau sur fx-CG50. "System Error" lorsque l'on appuie sur F1 ou F6 au lancement de Khicas.
Citer : Posté le 27/12/2022 18:15 | #
C'est déjà signalé à l'auteur, pas de nouvelles précises pour le moment.
Si tu as un besoin immédiat de KhiCAS, tu peux toujours redescendre à la version 3.60.
Citer : Posté le 28/12/2022 13:01 | #
Casio a changé quelque chose dans l'affection de la ram, ce qui rend l'addin complet en 2 fichiers incompatible avec l'os 3.7, en tout cas pour le moment. La version light de khicas en un seul fichier n'est pas impactée.
Donc ne mettez pas à jour ou downgradez en 3.6 si vous voulez utiliser la version complète de Khicas.
Franchement, je ne vois pas bien l'intérêt de mettre la version 3.7, juste pour avoir quelques traductions du bandeau en français
Citer : Posté le 04/01/2023 10:02 | #
Bon, j'ai accusé à tort Casio! Le bug était dans la routine de confirmation, il est maintenant corrigé et il semble qu'il n'y a pas de problème d'incompatibilité avec l'OS 3.7. J'attends un peu qu'il y ait plus de tests avant d'enlever la confirmation.
Citer : Posté le 04/01/2023 10:32 | #
Content de voir que tu as trouvé. Ça me faisait un peu peur de me lancer là-dedans vu que KhiCAS reste un peu insondable pour moi. x_x
L'absence de changements majeurs est rassurante (c'est ce qu'on attendait après tout). Je n'ai pas encore mis à jour mais je teste KhiCAS dès que je le fais...
Citer : Posté le 04/01/2023 13:51 | #
Il faudrait peut être qu'on regarde si pour allouer un maximum de mémoire, la zone considérée "safe" avec seulement des 0 a bien toujours la même taille.
En gros que dans le code "usuel" suivant :
static kmalloc_arena_t extended_ram = { 0 };
kmalloc_gint_stats_t *extram_stats;
if((!strncmp(osv, "03.", 3) && osv[3] <= '6') && gint[HWCALC] == HWCALC_FXCG50)
{
extended_ram.name = "extram";
extended_ram.is_default = true;
extended_ram.start = (void *)0x8c200000;
extended_ram.end = (void *)0x8c500000 ;
kmalloc_init_arena(&extended_ram, true);
kmalloc_add_arena(&extended_ram );
}
on puisse bien changer le "3.6" en "3.7" sans risque de fracasser qq chose au passage.
Mais peut être que Bernard dans KhiCAS fait déjà la vérification.
Citer : Posté le 04/01/2023 17:55 | #
Non, pour une raison toute simple, c'est qu'une fois khicas chargé, la zone en question contient du non 0. Ou alors il faudrait effacer la zone en sortant de l'addin...
Citer : Posté le 04/01/2023 18:14 | #
Ah oui, j'ai oublié de préciser.
A la fin de l'Addin, je remets tout au propre avec des 0 dans la zone allouée.
memset(extended_ram.start, 0, (char *)extended_ram.end - (char *)extended_ram.start);
Comme tu le précises dans ton message.
Citer : Posté le 04/01/2023 19:29 | #
Ce problème soulevé par Parisse est crucial à mon goût, il ne suffit pas de réinitialiser en sortant de l'add-in, on peut sortir par Getkey(), on peut sortir par System ERROR ou crash, on peut sortir de plein de façons qui ne garantissent pas que c'est du 0 à la fin.
Dans l'immédiat je reste plus ou moins convaincu qu'on est obligés de s'attribuer la mémoire même s'il n'y a pas de 0...
Citer : Posté le 04/01/2023 19:37 | #
Du coup il faut continuer de vérifier OS après OS en faisant un "dump" de la mémoire via un addin pour voir si effectivement on peut continuer d'utiliser la mémoire, c'est ça ? si on trouve autre chose que des 0, on limite la zone utilisable en conséquence.
Citer : Posté le 05/01/2023 08:51 | #
S'il y avait un gros changement (par exemple OS 4.x), il y aurait des craintes. Mais là, ça parait assez improbable que Casio change sa façon d'utiliser la mémoire juste pour localiser quelques messages et la gestion des unités (et ça aurait du me mettre la puce à l'oreille sur la cause du bug de la version intégrale de KhiCAS...). En fait, j'ai nettement le sentiment que Casio essaie de garder un seul code source avec juste un paramétrage pour monochrome vs couleur. D'où les tailles d'écran avec un facteur 3 horizontal/vertical et la taille de fonte vraiment grande sur la Graph 90. D'où la mémoire disponible non utilisée par Casio.
Citer : Posté le 05/01/2023 09:01 | #
Oui, je suis d'accord. La taille de police c'est clairement un reste de l'OS mono, où de ce que je comprends à l'époque de la Prizm ils voulaient pas réécrire tout l'OS. Que ce soit le même code source, je n'y avais pas pensé, ce serait assez marrant. La RAM non utilisée est aussi que la Prizm ne s'en servait pas, donc ils se donnent de la marge dans le futur (Python notamment...) mais pas encore besoin dans l'immédiat. Ils ont déjà fait ça une fois dans les Graph mono.
En tous cas avec un OS qui n'a pas vraiment changé en bien 15 ans, on a de quoi espérer !