Seuls les membres ayant 30 points peuvent parler sur le chat.

Forum Casio - Projets de programmation


Index du Forum » Projets de programmation » gint : un noyau pour développer des add-ins
Lephenixnoir Hors ligne Administrateur Points: 18132 Défis: 142 Message

gint : un noyau pour développer des add-ins

Posté le 20/02/2015 17:30

Les SDKs classiques pour écrire des add-ins sont le fx-9860G SDK de Casio avec fxlib (pour Graph monochrome) et le PrizmSDK avec libfxcg (pour Prizm et Graph 90+E). Voici mon alternative : le fxSDK avec gint, pour toutes les plateformes.

Contrairement à fxlib et libfxcg, qui appellent les fonctions de l'OS pour faire leur travail, gint est un noyau indépendant de l'OS qui exploite seul le matériel et le met à disposition de votre add-in. Il vous offre plus de finesse sur le contrôle du matériel, notamment le clavier, l'écran et les horloges, de meilleurs performances sur le dessin, les drivers et la gestion de interruptions, et des choses entièrement nouvelles comme le moteur de gris.

Toutes les sources de gint sont publiques et accessibles sur la forge de Planète Casio :

» Dépôt Gitea Lephenixnoir/gint «

Voici plus précisément ce que gint vous offre de nouveau :

• Un contrôle détaillé du clavier pour les jeux, parfait pour les combos !
• Des timers avec une précision de 60 ns, d'autres à 30 µs
• Toutes vos images converties automatiquement sans code à copier (plus de Sprite Coder)
• Des polices personnalisées
• Des fonctions de dessin, d'images et de texte fulgurantes et optimisées la main
• Mesurer les performance de votre code à la microseconde près (avec libprof)
• Le contrôle du matériel et des interruptions
• Plein de petites choses pratiques comme dprint(1, 1, "x=%d", x)

• (Graph monochrome) Un moteur de gris pour faire des jeux en 4 couleurs !
• (Graph monochrome) La compatibilité SH3 et SH4, avec le même fichier g1a.

• (Graph 90+E) Une nouvelle police de texte, plus lisible et économe en espace
• (Graph 90+E) Le dessin en plein écran, sans les bordures blanches et la barre de statut !
• (Graph 90+E) Un driver écran capable de triple-buffering

Le coût de tout ceci, c'est que vous avez une copie du code de gint dans votre add-in. Cela prend environ 20 ko de place (selon la quantité de fonctions que vous utilisez), soit à peu près comme le sprintf() de fxlib qui fait 18 ko !

Et voici quelques photos et captures d'écran !





Tester gint sur votre machine

La fin du portage vers la Graph 90+E signera la sortie de gint v2. L'add-in de test de l'application est désormais gintctl :

» Dépôt Gitea Lephenixnoir/gintctl «

En plus de tester les fonctionnalités de gint, cet add-in contient quelques outils permettant d'inspecter la machine, la mémoire, et les registres. Je le développe au fur et à mesure, et je posterai un protocole de test complet avec la sortie de la v2 !

Utiliser gint pour développer des add-ins

Normalement, vous avez besoin du fxSDK pour développer avec gint. Le fxSDK est compatible avec Linux et Mac OS, et on peut réfléchir à un portage sous Windows s'il y a vraiment des intéressés. Il faut l'installer en premier (et avoir un cross-compilateur GCC).

La procédure de compilation et d'installation de gint est décrite sur le README du dépôt, c'est du configure - make tout à fait banal.

Une fois que gint est installé sur votre système, voyez les tutoriels de développement pour avoir un aperçu de son fonctionnement. La plupart des choses sont expliquées dans les en-têtes (fichiers .h) de la bibliothèque que vous pouvez consulter en ligne, sur votre copie locale du dépôt, ou dans les dossiers d'installation du compilateur.

Obtenir la dernière version de gint après une mise à jour

Je pousse régulièrement des mises à jour de gint sur le dépôt du projet. Pour les télécharger, tapez git pull, puis recompilez et réinstallez gint avec make et make install.


Fichier joint


Précédente 1, 2, 3 ··· 10 ··· 20 ··· 30 ··· 39, 40, 41, 42
Lephenixnoir Hors ligne Administrateur Points: 18132 Défis: 142 Message

Citer : Posté le 20/06/2020 22:37 | #


Aha RIP. Ça m'est arrivé une fois aussi, j'ai tout recompilé dans le doute. Sinon tu fous des liens symboliques pour tout le monde non ?

Ajouté le 20/06/2020 à 23:06 :
J'ai poussé sur la branche dev une modification de la fonction timer_setup() qui permet de configurer les timers. Je sais que c'est un point compliqué pour pas mal de gens, donc j'ai essayer de simplifier ça sans casser le code qui veut exploiter toute la puissance du système.

La nouvelle fonction a un prototype largement plus simple avec seulement trois arguments obligatoires :
• Le timer que vous voulez utiliser (vous pouvez aussi laisser gint en choisir un)
• Le délai en micro-secondes
• La fonction à appeler une fois le délai écoulé

Modification 1 : plus besoin de gérer les numéros de timers. En général vous vous en foutez pas mal de savoir qui est un TMU et qui est un ETMU, disponible ou pas, et si la précision est de 0.3 ms ou 0.3 µs. Et en général perso j'ai pas envie de traquer quel timer j'ai utilisé à quel endroit. Et donc on peut simplifier les deux situations en mettant TIMER_ANY en premier argument. gint se charge de trouver un timer disponible qui est capable d'attendre le délai que vous demandez.

/* Exécuter f() dans 25 ms */
int timer = timer_setup(TIMER_ANY, 25000, f);
if(timer >= 0) timer_start(timer);

Évidemment il faut quand même vérifier qu'un timer libre existe bel et bien; timer_setup() renvoie -1 si aucun timer n'est disponible pour répondre à votre demande.

Modification 2 : le délai directement en micro-secondes. Mais si vous voulez utiliser explicitement un timer par son ID, le délai est traité comme une valeur de TCOR, comme avant (utile pour libprof et le moteur de gris, notamment). Mais bon les power users peuvent lire le header, je détaille pas ici.

Modification 3 : plus de type bizarre sur les fonctions de callback . Grâce à de la magie noire de GCC, timer_setup() accepte différents types de callbacks, notamment int f(void) (aucun argument). Dans ce cas vous n'êtes pas obligés de passer un argument à timer_setup(). Le callback peut avoir au plus un argument qui doit forcément être de 4 octets (en gros : un entier ou un pointeur).

/* Exécuter f() dans 25 ms */
int f(void) { ... return TIMER_STOP; }
int timer = timer_setup(TIMER_ANY, 25000, f);
if(timer >= 0) timer_start(timer);

/* Exécuter g(5) dans 25 ms */
int  g(int x) { ... x ... return TIMER_STOP; }
int timer = timer_setup(TIMER_ANY, 25000, g, 5);
if(timer >= 0) timer_start(timer);

Comme avant le callback doit renvoyer un entier indiquant au timer s'il doit continuer à tourner ou s'arrêter. Mais au lieu de 0 et 1, ils s'appellent maintenant TIMER_CONTINUE et TIMER_STOP, ce qui est quand même plus agréable.

Pour adapter votre code. La plupart des appels à timer_setup() jusque-là avaient cette forme :

timer_setup(<id>, timer_delay(<id>, <delay>), timer_default [ou 0], <callback>, <arg>);

La façon safe de transposer ça dans la nouvelle API sans risquer de problème est ceci :

timer_setup(<id>, timer_delay(<id>, <delay>, TIMER_Pphi_4), <callback>, <arg>);

Mais ça c'est que si vous voulez utiliser explicitement le timer <id>. Si au fond n'importe quel timer vous convient, vous pouvez utiliser TIMER_ANY et dans de cas gint calculer timer_delay() pour vous. Votre code devient :

timer_setup(TIMER_ANY, <delay>, <callback>, <arg>);

Enfin si votre callback ne prend au fond pas d'argument (avant vous étiez obligés d'en avoir un de type volatile void *), vous pouvez le retirer (votre callback et alors de type int callback(void)) et ne plus le passer à timer_setup(). Votre code devient :

timer_setup(TIMER_ANY, <delay>, <callback>);


Voilà, j'espère que ça vous simplifiera les choses pour aborder tranquillement les timers sans maux de tête. J'ai fait de mon mieux pour garder l'API proche de l'ancienne version pour que les changements soient faciles pour vous.

Ajouté le 29/06/2020 à 21:32 :
Je continue à bosser sur la prochaine release. Actuellement, j'essaie de rendre gint compatible avec l'émulateur officiel Graph 90+E. La plupart des choses semblent fonctionner, mais l'affichage à l'écran non (ce qui rend difficile le test dans la plupart des cas !).

J'ai déjà déterminé que la méthode naïve pour afficher des données (envoyer chaque pixel à l'écran par l'action du CPU) fonctionne, seule la méthode DMA semble échouer. Je vais voir ce que je peux trouver là-dessus, au pire cas je peux toujours utiliser la méthode naïve car les problèmes de performance ne sont pas aussi intéressants sur l'émulateur que sur la calculatrice.

S'il s'est passé un bon moment depuis la dernière update (9 jours) c'est qu'en décortiquant l'émulateur j'ai trouvé plein d'infos intéressants sur le SH7305 et j'ai pris un moment pour évaluer les conséquences sur le reverse-engineering du matériel avec Yatis.

Ajouté le 02/07/2020 à 11:21 :
J'ai progressé. En fait je crois que sur la calculatrice la RAM est à 8c000000 (ou ac000000) tandis que sur l'émulateur elle est à 88000000 (ou 8c000000). La preuve c'est que je me sers de cette méthode pour différencier Prizm et Graph 90+E et l'émulateur est détecté comme une Prizm ! De plus, les problèmes d'affichage n'étaient pas liés au DMA mais au fait que j'utilisais une zone de RAM qui n'existait pas (puisque pas au bon endroit dans la RAM).

Il est donc possible que l'émulateur est la Graph 90+E n'utilisent pas tout à fait le même OS. Ça mérite d'être étudié.

Ajouté le 02/07/2020 à 16:08 :
Alright, donc grâce aux mécanismes de compatibilité Prizm de gint, la transition vers l'émulateur s'est faite sans problème. Le fx-CG Manager de Casio est désormais officiellement une platforme supportée par gint

Je pense que c'est le bon moment pour tester sur Prizm aussi.

--

Sentaro21, a couple months ago you mentioned that you might be able to test the project on fx-CG 20. If you can still do it, please download the test application gintctl.g3a (you will need to rename it).

The application has many tests but I'm interested in the following information in the GINT tab:
• In "Hardware", the "MPU/CPU" page should show "Calculator model: Prizm fx-CG 20"
• In "Memory dump", you should be able to press F3 then F6 to dump some of the RS RAM to a file called RS00.bin without a crash
• In "Switch to OS", you shoud be able to press F1 (SWITCH) repeatedly without a crash, and you should also be able to press F3 (MENU) to switch between the main menu and the add-in.
• In "TLB management", pressing F5 (MISS) and F6 (TIMER) should map new pages (more squares should be green).
• In "Timers", you should see TMU2 and ETMU5 running, and pressing F1 (SLEEP) sould make TMU0 run for about a second
Finally, in the MEMORY tab of the main menu, you should be able to press F3 (ROM) then Up and have a red "TLB error" on screen.

Because it works on fx-CG 50 and in the fx-CG Manager which behaves like an fx-CG 20, I am confident this will work.
Kirafi Hors ligne Membre Points: 2142 Défis: 10 Message

Citer : Posté le 04/07/2020 10:28 | #


Hello, une date de realease en vu pour une version 2 stable ? De ce que j'ai compris elle est quasiment prête t'es en train de faire quelques petits correctifs ?
iPod
Pour des parties rapides
Jusqu'où pourras-tu aller dans ce jeu "partie rapide" qu'est Dextris (élu Jeu Du Mois)
Pourras-tu survivre plus de 20 secondes dans ce fameux tunnel appelé Graviton
Rebondis entre les murs en évitant les piques dans SpikeBird
Pourras-tu éviter de te faire écraser dans FallBlocs (élu Jeu Du Mois)
Autres
Franchement ils valent le coups
Deviens l'amiral de la marine dans SeaRush (jeu concours) (élu Jeu Du Mois)
La version 2048 tactile amélioré au plus haut point : 2048 Delux !
Pars à la recherche des morceaux d'étoile dans Lumyce (élu Jeu Du Mois)
Lephenixnoir Hors ligne Administrateur Points: 18132 Défis: 142 Message

Citer : Posté le 04/07/2020 11:02 | #


Yo ! Donc en effet je suis en bêta là, la plus récente étant la 2.0.2-beta.

Voilà la TODO list des features avant la fameuse 2.1 que je tease depuis un moment :
• Faire les fonctions de mémoire optimisées : memcpy, memcmp, memset, et pour memmove je reste naïf (je suis là tout de suite dessus) [4]
• Supporter la Prizm fx-CG 20, normalement c'est bon j'attends juste un test (non bloquant pour la 2.1)
• Double-buffer les paramètres du moteur de gris (en gros : activation frame-perfect du moteur) [2-3]
• Supporter les polices Unicode dans topti (pour uf5x7 et virer les anciens charsets) [2-3]
• Gérer le spread spectrum sur Graph 90+E, les timers sont pas tout à fait précis actuellement [1]
• Ajouter une valeur de retour de main() qui permet de revenir au menu au lieu de quitter l'add-in et donc de revenir [1]

Voici les choses que je dois casser :
• Supprimer image_t qui a été renommé bopti_image_t par clarté
• Supprimer la branche compat, maintenant tout le monde doit utiliser master ou dev
• Unifier les fonctions g*() avec les d*() ; vu que le moteur de gris est double-buffer, plus besoin de séparer [2]

Et voici des choses qui iront dans les releases suivantes :
• Système de fichiers propre
• Overclock
• Musique avec la méthode de TSWilliamson
• Communication série et USB
• Jouer avec le DSP, si ça peut aider

J'ai mis entre crochets une estimation du nombre d'heures pour faire marcher les points principaux. Le temps que j'arrive à passer sur gint est assez instable cette semaine mais j'espère pousser la release à la fin de la semaine prochaine ou au début de la semaine suivante, donc autour du 12-14 Juillet.
Kirafi Hors ligne Membre Points: 2142 Défis: 10 Message

Citer : Posté le 04/07/2020 16:04 | #


C'est quoi le truc du double buffer ? ça va améliorer le moteur de gris ?
Le retour au menu c'est une grande première dans les Add-In haha !

C'est cool pour la branche master ça fait plus propre .

Les release suivante sont dans l'ordre ou pas là ? Car je pense que la communication est assez importante comparé aux autres.

Okay bon, tkt si ça prend un mois c'est pas grave c'est déjà ouf ce que tu produis !
iPod
Pour des parties rapides
Jusqu'où pourras-tu aller dans ce jeu "partie rapide" qu'est Dextris (élu Jeu Du Mois)
Pourras-tu survivre plus de 20 secondes dans ce fameux tunnel appelé Graviton
Rebondis entre les murs en évitant les piques dans SpikeBird
Pourras-tu éviter de te faire écraser dans FallBlocs (élu Jeu Du Mois)
Autres
Franchement ils valent le coups
Deviens l'amiral de la marine dans SeaRush (jeu concours) (élu Jeu Du Mois)
La version 2048 tactile amélioré au plus haut point : 2048 Delux !
Pars à la recherche des morceaux d'étoile dans Lumyce (élu Jeu Du Mois)
Lephenixnoir Hors ligne Administrateur Points: 18132 Défis: 142 Message

Citer : Posté le 04/07/2020 22:01 | #


Kirafi a écrit :
C'est quoi le truc du double buffer ? ça va améliorer le moteur de gris ?

En gros quand tu fais gray_start() ou gray_stop(), au lieu d'activer ou de désactiver le moteur de gris tout de suite, ça ne le modifie qu'au prochain dupdate(). Comme ça tu as le temps de pousser ton premier frame en gris (ou ton premier frame mono après l'arrêt du moteur de gris) sans risquer que des VRAMs impropres s'affichent brièvement.

Les release suivante sont dans l'ordre ou pas là ? Car je pense que la communication est assez importante comparé aux autres.

Ouh là non c'est pas encore un plan tout ça ! Une partie de ces choses dépend de résultats de reverse-engineering qu'on est encore en train d'établi donc c'est vraiment dur de donner une estimation.

Okay bon, tkt si ça prend un mois c'est pas grave c'est déjà ouf ce que tu produis !

Merci ! Ça devrait pas prendre un mois quand même. Je me suis débarrassé des fonctions de mémoire tout à l'heure.

Ajouté le 06/07/2020 à 18:24 :
J'ai trouvé des problèmes bizarres sur le retour au menu, en particulier sur SH3, donc j'enquête. Je reprendrai les ajustements sur le moteur de gris quand j'aurai trouvé.
Kbd2 En ligne Membre Points: 12 Défis: 0 Message

Citer : Posté le 07/07/2020 12:58 | #


Hi, are there any plans to implement some standard math library functions? I would use the newlib port but I can't find any working repos for it (I did manage to implement the cosine function I needed in my code).
Current Project
Close
Dark storm Hors ligne Membre d'honneur Points: 11092 Défis: 176 Message

Citer : Posté le 07/07/2020 20:45 | #


Maybe you can look at the Memallox' port of Newlib : https://gitea.planet-casio.com/PlaneteCasio/libc

I do not know if it includes math functions, but it's definitely the more complete project of a libc on Casio calcs
Finir est souvent bien plus difficile que commencer. — Jack Beauregard
Kbd2 En ligne Membre Points: 12 Défis: 0 Message

Citer : Posté le 08/07/2020 02:56 | # | Fichier joint


That refuses to build for some reason, the compiler finds errors in /libc/newlib/libc/include/ieeefp.h and stops. I don't know enough to try messing around with the header and fix them, I've attached a text file containing the output.

EDIT: Adding a
#define _LDBL_EQ_DBL
to the header seemed to fix it, everything compiled correctly. The SuperH manual says long doubles and doubles are the same size, so hopefully there shouldn't be any problems...

EDIT 2: Hooray! After adding -lm to the compiler flags for the addin everything seems to be working perfectly! Thanks for the link to the repo, all the ones I could find were dead.
Current Project
Close
Dark storm Hors ligne Membre d'honneur Points: 11092 Défis: 176 Message

Citer : Posté le 08/07/2020 09:34 | #


You're welcome

If you think your patch is clean enough to be integrated to the code repository, we'll pleased to create you an account on the Gitea, so you can post a merge request. Maybe you can add some notes/hints too.
Finir est souvent bien plus difficile que commencer. — Jack Beauregard
Kbd2 En ligne Membre Points: 12 Défis: 0 Message

Citer : Posté le 08/07/2020 14:32 | #


Unfortunately, unless someone can reproduce it, I can't be sure if it was a missing define somewhere or if I messed up earlier building the bootstrap GCC.
I do think the newlib/gcc tutorials should say that '-lm' needs to be added to the compiler options (or in the fxSDK project config) when compiling an addin for the math library to be linked, I was worried for a bit that I didn't build newlib/gcc properly
Current Project
Close
Lephenixnoir Hors ligne Administrateur Points: 18132 Défis: 142 Message

Citer : Posté le 08/07/2020 16:47 | #


Interesting, I didn't have this problem when building the library. I did experience some crashes with core memory functions like memcpy() using this port (that did not appear with naive implementations), so if you encounter trouble know that newlib might (?) be in fault.

My stance on the standard library is not very clear yet. I wanted to use this newlib port at some point but Memallox has unfortunately not developed it for a while. gint currently provides a couple optimized memory and string functions but I haven't yet gone all the way and implemented the whole set.

As for the math library, I think we can at least port an independent libm as the Prizm SDK does (although it ships libm.a directly without explaining how to build it so it's not that useful). Just for completeness, you can find that file here (I don't know whether there is an official PrizmSDK repository so I pointed to TSWilliamson's personal version - the binary libraries should be the same).

Hope this helps clarify the situation. Also, thanks for your interest in this project

Ajouté le 08/07/2020 à 17:29 :
Lephenixnoir a écrit :
J'ai trouvé des problèmes bizarres sur le retour au menu, en particulier sur SH3, donc j'enquête. Je reprendrai les ajustements sur le moteur de gris quand j'aurai trouvé.

J'ai continué et j'ai trouvé... pas mal de problèmes sur SH3, wow. Ils sont apparus avec le changement de l'API timer mais ça n'a pas vraiment de raison d'être lié. Visiblement la zone dans laquelle j'installe la VBR et la mémoire mappée de gint est vraiment pas fiable. Il faut que je voie au plus vite si je peux m'en débarrasser, même si c'est pas gagné. En gros j'ai besoin d'une zone non virtualisée dans P1 ou P2 pour avoir la VBR et une poignée de fonctions auxiliaires. Une fois les trivialités éliminées, en gros il me faut une zone de RAM d'environ 8k. Pour l'instant j'étudie mes options, je vous tient au courant.

Ajouté le 10/07/2020 à 11:56 :
Okay donc petite explication de ce qui se passe ici. Il y a grosso modo 3 types de mémoire sur la calto : la ROM, la RAM, et la mémoire on-chip. Quand on lance un add-in, on a le code dans la ROM et les données dans la RAM. Pour accéder à la ROM et à la RAM, normalement on utilise des adresses "absolues" qui accèdent exactement à l'octet qu'on demande.

Cela pose deux problèmes pour les add-ins. D'une part le code est dans le fichier g1a/g3a, qui est fragmenté dans la ROM, donc il n'est pas continu (l'instruction qui suit l'instruction actuelle peut être à l'autre bout de la ROM). D'autre part la zone de RAM que l'OS nous donne n'est pas au même endroit ni de la même taille d'une version de l'OS à l'autre. Tout cela fait qu'il est quasi-impossible de savoir où le code et les données sont.

Pour pallier à ce problème (et d'autres !), un outil matériel appelé le MMU a été inventé. Le MMU présente des adresses "virtuelles" à l'add-in et les traduit en adresses "absolues" de façon transparente. Ainsi, le système peut configurer le MMU pour me présenter le code de mon add-in dans des adresse virtuelles consécutives tout en les redirigeant individuellement vers les fragments du fichier g1a/g3a qui peuvent être éparpillés dans la ROM. De même, il peut présenter une adresse virtuelle fixe pour la RAM même si l'adresse absolue change. En pratique, on n'utilise quasiment que ces adresses virtuelles.

Mais dans gint, j'ai une poignée de code et de données que je dois absolument désigner par une adresse absolue dans la RAM. Sur Graph 90+E, j'accède au MMU pour connaître l'adresse absolue accordée à l'add-in et je m'installe là. Sur Graph mono, historiquement je me plaçais à une addresse fixe qui semblait inutilisée.

Donc ce que j'ai découvert récemment à travers le retour au menu c'est que la zone est effectivement utilisée et que revenir au menu provoque une écriture dedans. Ça veut dire que chaque fois qu'on revient au menu, des variables et tableaux de gint se font modifier de façon aléatoire. Comme vous pouvez vous en douter, ce n'est pas une situation acceptable.

Donc ce que j'ai commencé à faire c'est préparer le terrain pour déplacer mes données sensible au début de la zone de RAM accordée par l'OS, comme je le fais sur Graph 90+E. Mais cela pose quelques difficultés. Sur SH3, il n'y a que 8k de RAM disponible, et mes données sensibles prennent de base.... 8k aussi. Donc j'ai commencé à agencer tout ça de façon à le faire tenir dans moins, même si c'est pas tout à fait gagné encore. J'espère tout fait tenir dans 3k-4k.

Actuellement je suis en train de debugger le déplacement ; j'espère faire marcher tout ça ce soir. Ça veut dire que je dois attendre un peu pour faire les autres modifications (celles du moteur de gris), mais je vais faire au plus vite.

Ajouté le 10/07/2020 à 17:08 :
Voilà, j'ai fait ces modifications. Tout confondu j'arrive à faire tenir les données dans environ 4k, donc il reste 4k de variables globales sur SH3 (j'envisage de gratter 1k en déplaçant la VRAM). Notez que ces problèmes de taille c'est vraiment spécifique à la SH3, il reste aisément 28k sur SH4 et plus de 500k sur Graph 90. J'en ai profité pour réduire un peu l'empreinte mémoire de gint et gintctl de façon générale. Au total gintctl utilise que 500 octets sur les 4k qui restent donc vous voyez que si on fait un peu attention même une grosse appli a pas besoin de beaucoup de mémoire.

En fin de compte ça m'a pris un moment mais ça a bien nettoyé les facteurs d'incertitudes/instabilité dans gint. Cela explique et résoud en même temps les quelques bugs de retour au menu sur Graph mono que j'avais laissés il y a quelques mois. Il me reste quelques observations étranges sur SH3, mais pas reproductibles donc pour l'instant je ne peux rien y faire. (Assurer la compatibilité sur plusieurs plateformes est plus dur que ça peut en avoir l'air, toutes ces calculatrices ont quand même des sales différences qui rendent le boulot compliqué. xD)

Donc je reprends la liste des modifs que j'ai indiquée à Kirafi et j'espère ne pas croiser d'autre problème majeure du type avant la prochaine release.

Nouvelle bêta : gint 2.0.3-beta

Nouvelles fonctionnalités :
• Ajouté une fonction drect_border() pour les rectangles avec des bordures de tailles et couleurs variables
• Ajouté deux fonctions dtext_opt() et dprint_opt() permettant de contrôler l'alignement du texte
• Compatibilité Prizm fx-CG 20 (encore à tester sur une vraie machine, que je n'ai pas)
• Compatibilité avec l'émulateur fx-CG Manager
• Ajouté des valeurs par défaut correctes pour le moteur de gris sur les Graph mono autres que la Graph 35+E II
• Fonctions memcpy(), memset(), memcmp() et memmove() optimisées à fond à la fois sur SH3 et SH4

Changements :
dtext() et dprint() ne spécifient plus la couleur de fond, c'est désormais géré par dtext_opt() et dprint_opt()
• Supprimé le boot log, un vieux mécanisme de debuggage
• Retiré l'utilisation d'une région "rram" héritée des Graph mono sur Graph 90
• Ultime modification de l'API timer pour vous simplifier la vie sans casser le code existant. Instructions de migration ici.
• Modifié la structure de la VBR sur SH3 pour économiser de la mémoire.
• En conséquence du point précédent, supprimé la région "rram" pour utiliser une partie des 8k de mémoire utilisateur à la place

Corrections de bug : plein, mais aucun qui m'a été rapporté. Principalement :
• Instabilités sur SH3 lorsque le retour au menu est utilisé.
Précédente 1, 2, 3 ··· 10 ··· 20 ··· 30 ··· 39, 40, 41, 42

LienAjouter une imageAjouter une vidéoAjouter un lien vers un profilAjouter du codeCiterAjouter un spoiler(texte affichable/masquable par un clic)Ajouter une barre de progressionItaliqueGrasSoulignéAfficher du texte barréCentréJustifiéPlus petitPlus grandPlus de smileys !
Cliquez pour épingler Cliquez pour détacher Cliquez pour fermer
Alignement de l'image: Redimensionnement de l'image (en pixel):
Afficher la liste des membres
Pour coloriser votre code, cliquez ici.
Sinon cliquez sur le bouton ci-dessous.
:bow: :cool: :good: :love: ^^
:omg: :fusil: :aie: :argh: :mdr:
:boulet2: :thx: :champ: :whistle: :bounce:
valider
 :)  ;)  :D  :p
 :lol:  8)  :(  :@
 0_0  :oops:  :grr:  :E
 :O  :sry:  :mmm:  :waza:
 :'(  :here:  ^^  >:)

Σ π θ ± α β γ δ Δ σ λ
Veuillez donner la réponse en chiffre
Vous devez activer le Javascript dans votre navigateur pour pouvoir valider ce formulaire.

Si vous n'avez pas volontairement désactivé cette fonctionnalité de votre navigateur, il s'agit probablement d'un bug : contactez l'équipe de Planète Casio.

Planète Casio v42 © créé par Neuronix et Muelsaco 2004 - 2020 | Il y a 18 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