gint : un noyau pour développer des add-ins
Posté le 20/02/2015 17:30
Ce topic fait partie de la série de topics du fxSDK.
En plus des options de programmation intégrée comme le Basic Casio ou Python, la plupart des calculatrices Casio supportent des
add-ins, des programmes natifs très polyvalents avec d'excellentes performances. Les add-ins sont généralement programmés en C/C++ avec l'aide d'un ensemble d'outils appelé SDK.
Plusieurs SDK ont été utilisés par la communauté avec le temps. D'abord le
fx-9860G SDK de Casio avec fxlib pour Graph monochromes (plus maintenu depuis longtemps). Puis le
PrizmSDK avec libfxcg pour Prizm et Graph 90+E (encore un peu actif sur Cemetech). Et plus récemment celui que je maintiens, le
fxSDK, dont gint est le composant principal.
gint est un unikernel, ce qui veut dire qu'il embarque essentiellement un OS indépendant dans les add-ins au lieu d'utiliser les fonctions de l'OS de Casio. Ça lui permet beaucoup de finesse sur le contrôle du matériel, notamment la mémoire, le clavier, l'écran et les horloges ; mais aussi de meilleures performances sur le dessin, les drivers et la gestion des interruptions, plus des choses entièrement nouvelles comme le moteur de gris sur Graph monochromes.
Les sources de gint sont sur la forge de Planète Casio :
dépôt Gitea Lephenixnoir/gint
Aperçu des fonctionnalités
Les fonctionnalités phares de gint (avec le fxSDK) incluent :
- Toutes vos images et polices converties automatiquement depuis le PNG, sans code à copier (via fxconv)
- Un contrôle détaillé du clavier, avec un GetKey() personnalisable et un système d'événements à la SDL
- Une bibliothèque standard C plus fournie que celle de Casio (voir fxlibc), et la majorité de la bibliothèque C++
- Plein de raccourcis pratiques, comme pour afficher la valeur d'une variable : dprint(1,1,"x=%d",x)
- Des fonctions de dessin, d'images et de texte optimisées à la main et super rapides, surtout sur Graph 90+E
- Des timers très précis (60 ns / 30 µs selon les cas, au lieu des 25 ms de l'OS), indispensables pour les jeux
- Captures d'écran et capture vidéo des add-ins par USB, en temps réel (via fxlink)
Avec quelques mentions spéciales sur les Graph monochromes :
Un moteur de gris pour faire des jeux en 4 couleurs !
La compatibilité SH3, SH4 et Graph 35+E II, avec un seul fichier g1a
Une API Unix/POSIX et standard C pour accéder au système de fichiers (Graph 35+E II seulement)
Et quelques mentions spéciales sur les Graph 90+E :
Une nouvelle police de texte, plus lisible et économe en espace
Le dessin en plein écran, sans les bordures blanches et la barre de statut !
Un driver écran capable de triple-buffering
Une API Unix/POSIX et standard C pour accéder au système de fichiers
Galerie d'add-ins et de photos
Voici quelques photos et add-ins réalisés avec gint au cours des années !
Arena (2016) — Plague (2021)
Rogue Life (2021)
Momento (2021)
Communication avec le PC (cliquez pour agrandir)
Utiliser gint pour développer des add-ins
Les instructions pour installer et utiliser gint sont données dans les divers tutoriels recensés dans le
topic du fxSDK. Il y a différentes méthodes de la plus automatique (GiteaPC) à la plus manuelle (compilation/installation de chaque dépôt). Le fxSDK est compatible avec Linux, Mac OS, et marche aussi sous Windows avec l'aide de WSL, donc normalement tout le monde est couvert
Notez en particulier qu'il y a des
tutoriels de développement qui couvrent les bases ; tout le reste est expliqué dans les en-têtes (fichiers
.h) de la bibliothèque que vous pouvez
consulter en ligne, ou dans les ajouts aux changelogs ci-dessous.
Changelog et informations techniques
Pour tester les fonctionnalités et la compatibilité de gint, j'utilise un add-in de test appelé gintctl (
dépôt Gitea Lephenixnoir/gintctl). Il contient aussi une poignée d'utilitaires d'ordre général.
Ci-dessous se trouve la liste des posts indiquant les nouvelles versions de gint, et des liens vers des instructions/tutoriels supplémentaires qui accompagnent ces versions.
Anecdotes et bugs pétés
Ô amateurs de bas niveau, j'espère que vous ne tomberez pas dans les mêmes pièges que moi.
TODO list pour les prochaines versions (2023-04-03)
gint 2.11
- Changements de contextes CPU. À reprendre du prototype de threading de Yatis pour permettre l'implémentation d'un véritable ordonnanceur. Demandé par si pour faire du threading Java.
- Applications USB. Ajouter le support de descripteurs de fichiers USB. Potentiellement pousser jusqu'à avoir GDB pour debugger.
- Support de scanf() dans la fxlibc. Codé par SlyVTT, plus qu'à nettoyer et fusionner.
Non classé
- Regarder du côté serial (plus facile que l'USB) pour la communication inter-calculatrices (multijoueur) et ultimement l'audio (libsnd de TSWilliamson).
- Un système pour recompiler des add-ins mono sur la Graph 90+E avec une adaptation automatique.
- Support des fichiers en RAM pour pouvoir utiliser l'API haut-niveau sur tous les modèles et éviter la lenteur de BFile à l'écriture quand on a assez de RAM.
Citer : Posté le 11/06/2020 19:13 | #
Ooh je ne savais pas qu'on avait le syscall 0x001 pour faire ça. Intéressant ! Ce sera sans doute plus fiable que le handler, comme tu dis. Est-ce que tu sais si ce syscall a des effets indésirables comme modifier la VBR ou ce genre de choses ? :o
L'affichage n'est pas trop un problème, je peux de toute façon vérifier que la page demandée est valide avant d'appeler le système.
Du reste oui, faut mettre plein de trucs en RAM. Est-ce que c'est mieux si les drivers y sont, je sais pas. D'un côté la RAM est plus rapide en théorie, de l'autre c'est pas de beaucoup et la RAM a déjà beaucoup plus de pression dans l'application à cause de la VRAM. Je sais pas à quel point un accès à la ROM peut être "parallèle" parce qu'il y a un bus d'adresse plus ou moins partagé entre le proco et tout le reste. Éventuellement on peut mettre du code critique dans la mémoire IL (sur SH4) mais ça je n'ai pas encore vraiment testé en termes de performance.
Citer : Posté le 11/06/2020 19:53 | #
Tu m'as mis un doute, du coup j'ai regardé rapidement le code et en fait elle s'occupe uniquement d'afficher la popup avec les infos sur le TLB miss. J'étais persuadé que ça traitais l'exception, désolé
Je ne parlais pas en matière de rapidité mais en matière de "laisser charger les drivers" constamment pour éviter que le système les décharges ; le but étant d'être sûr que Gint aura jamais de TLB miss pour lui. Sinon je n'ai aucune idée de si ce sera plus rapide, probablement mais pas sûr que ce sois flagrant (?)
Citer : Posté le 11/06/2020 20:01 | #
Ah oui ok, l'intérêt de la RAM en ce que les drivers n'ont pas besoin d'être mappés. Oui c'est un peu mon but, mais je sais pas où mettre la limite. En plus faudra que je fasse gaffe aux interruptions parce que les callbacks peuvent créer des TLB miss et actuellement je réactive pas les interruptions dans les callbacks. Je sens que ça va me jouer des tours.
Ajouté le 11/06/2020 à 20:05 :
Mais en fait ça pourrait être la bonne piste. Je vais regarder si je peux utiliser Hmem_SetMMU() ou les autres syscalls TLB que j'ai découverts en plus de ceux de SimLo !
Citer : Posté le 11/06/2020 20:10 | #
Il me semblait que ces sycall là n'étaient plus implémentés ? Le mieux serai de désassembler la partie de la VBR qui gère l'exception et voir s’il y a des appels système qui trainent (dans mes souvenirs ce n'est pas le cas).
Citer : Posté le 11/06/2020 20:11 | #
J'ai refait un tour et effectivement Hmem_SetMMU() ne fait plus rien. Les autres syscalls que je connais ne sont pas spécifiques aux add-ins. Hmm... je peux regadrer dans le handler et dans App_Start() aussi. Je te dis si je trouve quelque chose d'intéressant
Ajouté le 11/06/2020 à 21:54 :
Donc j'ai regardé un peu les syscalls de plus près et en fait c'est pas 0x001 qui nous intéresse mais 0x003 (merci Yatis !). J'ai désassemblé la version 3.10 et par rapport à ce à quoi je m'attendais c'est *très* proche de ce dont j'ai besoin. Il va falloir désassembler plus, sur d'autres versions, et surtout tester, mais il est possible que cette histoire de se passe bien grâce à une bonne organisation dans l'OS (qui l'eût cru ?).
Ajouté le 11/06/2020 à 22:44 :
Bon j'ai fini de désassembler la chose avec l'aide précieuse de Yatis (qui en fait était déjà passé là avant moi donc avait compris 90% du truc xD), si vous avez envie de rigoler vous pouvez jeter un oeil à l'assembleur annoté sur notre dépôt de documentation.
Ce syscall fait vraiment *exactement* ce dont j'ai besoin (bon à part balancer un System ERROR si l'adresse est pas bonne) donc j'ai un bon espoir que ce dernier défi technique ne sera en essence qu'un simple appel de fonction et une réorganisation du linker script pour envoyer plus de code de gint dans la RAM (et deux/trois trucs sur les callbacks d'interruptions comme les timers, mais vous inquiétez pas pour ça).
Il est possible que la prochaine release majeure de gint ("v2" de son petit nom) ne soit plus qu'une question de temps. Stay tuned
Ajouté le 13/06/2020 à 20:31 :
Donc aujourd'hui j'ai modifié fxos pour supporter les OS de Graph 90+E, et j'ai vérifié que le syscall en question fait la même chose sur Graph 90+E que sur les Graph mono, et c'est bon. Les choses se concrétisent. Prochaine étape je fais des tests pour changer dynamiquement les mappings sur Graph 90+E en espérant ne pas me planter. Souhaitez-moi bonne chance :3
Ajouté le 14/06/2020 à 10:17 :
Le syscall en question fait bien son travail sur Graph 90+E d'après mes tests. Donc maintenant il faut que je m'adapte à ce nouveau mode de fonctionnement :
• Il faut que je déplace certaines zones cruciales du noyau, qui sont actuellement dans la zone gérée par le TLB et peuvent donc être déchargées (!)
• Il faut aussi que j'active les interruptions pendant les callbacks de timers et affiliés pour que les TLB miss puissent être gérés à cet endroit
La balle est dans mon camp a priori, sauf mauvaise surprise je vois comment la suite va se passer jusqu'à la prochaine release.
Ajouté le 14/06/2020 à 14:31 :
J'ai progressé ! J'ai implémenté un test dans gintctl avec deux façons de charger des pages : soit directement en appelant le syscall, soit en effectuant un TLB miss normal. La seconde marche à tous les coups avec pour l'instant aucun crash à déplorer. La première crashe de temps en temps et j'ai fini par comprendre pourquoi : parfois l'exécution de getkey() ou le dessin de l'écran charge les pages dont on a besoin par TLB miss. Dans ce cas la deuxième méthode ne fait rien car le TLB miss recherché ne se produit pas. Mais la première méthode va quand même forcer la page à être chargée une *deuxième fois*, ce qui produit un TLB multihit qui est un reset (même pas moyen d'afficher une System ERROR).
Donc... je pense que je suis bon pour l'instant, je vais continuer à isoler ce qu'il faut de gint et à jouer avec les tests pour rendre ça un peu robuste. Il faut aussi que j'active les interruptions pour avoir les TLB miss dans les callbacks de timers. Mais je pense que je suis sur la bonne voie !
Ajouté le 15/06/2020 à 20:49 :
Les progrès de cette semaine sont très bons, presque miraculeux ! Avoir une gestion dynamique du TLB simplifie plusieurs problèmes gênants rencontrés jusqu'ici. Désormais, il n'y a plus que les procédures exécutées avec les interruptions bloquées (ie. le point d'entrée des gestionnaires d'interruption et les fonctions de changement de contexte noyau) qui doivent se trouver en RAM, tout le reste est géré par le TLB.
À ce sujet, il me reste toujours à réactiver les interruptions lors d'un callback de timer pour que le callback puisse produire des TLB miss sans que ce soit une erreur. Je vais voir si je peux tout réactiver, si ça ne marche vraiment pas je bloquerai uniquement les interruptions à proprement parler (VBR + 0x600) avec IMASK.
En attendant, c'est des superbes progrès et gint sur Graph 90+E n'a jamais été aussi stable et aussi élégant !
J'ai backporté les changements liés au TLB vers les Graph mono pour supporter des add-ins jusqu'à 512k (limite imposée par l'OS) au lieu de 220k (limite imposée par le TLB). Pour rappel, la nouvelle limite sur la Graph 90+E est de 2M (limite imposée par l'OS) au lieu de 220k. Je suis hors de Lyon et sans ma Graph SH3 donc la release devra attendre au moins la semaine prochaine, mais ça marche au moins déjà sur SH4. o/
Je suis incroyablement hypé par ces nouveaux changements (même si l'accumulation de ces messages montre que le sujet est trop technique pour remplir convenablement ce topic xD). Je vais bientôt publier une nouvelle bêta sur master quand la fonctionnalité sera stable vis-à-vis des callbacks de timers. Le reste ne sera que la dernière ligne droite !
Ajouté le 16/06/2020 à 21:10 :
J'ai modifié les callbacks de timers pour y activer les interruptions. On peut donc maintenant faire plus de choses dans les callbacks, même si la limite exacte est floue. J'ai trois tests qui passent bien dans gintctl, dont deux trucs un peu tendus : un sleep() dans le callback (ce qui force une interruption à se produire pendant le callback) et lancer+attendre un timer (donc le code normal se fait interrompre, un callback est lancé, qui lance un nouveau timer, qui vient l'interrompre pour lancer un second callback). Ça ça marche, même si je promets pas qu'on puisse tout faire. Gardez vos callbacks simples de façon générale.
Étonnement un TLB miss dans un callback continue de crasher donc il me reste encore des choses à voir. Une fois ce bug passé, je pousserai la première bêta stable avec gestion du TLB. Fini les limites à 220k, enjoy les images en résolution complète sur Graph 90+E.
Citer : Posté le 17/06/2020 14:52 | #
Promis cette saga s'arrête bientôt ! J'ai fini de faire marcher cette histoire de TLB sur les Graph mono SH4 (testé : Graph 75+E, Graph 35+E II) et Graph 90+E. Il me restera à tester la SH3. J'ai donc poussé une nouvelle bêta sur le dépôt.
Nouvelles fonctionnalités :
• Ajouté la gestion du TLB, ce qui autorise des add-ins jusqu'à 512k (Graph mono) ou 2M (Graph 90) au lieu de 220k.
Changements :
• Renommé image_t en bopti_image_t pour faire une différence propre avec le type img_t utilisé par libimg. Vous devez faire ce changement dans votre code (un simple rechercher/remplacer). Si vous continuer d'utiliser image_t, vous aurez un warning, et à la prochaine release majeure (2.1.0) une erreur.
Corrections de bugs :
• Corrigé un bug de tracé de lignes horizontales (dline() avec y1=y2) où gint écrivait hors de la VRAM si la ligne demandée était entièrement en-dehors de l'écran.
• Corrigé un bug de la famille printf() qui rendait %% inutilisable.
Comme vous pouvez le voir je tente un format un peu plus digeste pour les nouvelles versions ; l'icône est un vieil avatar que j'ai utilisé à une époque, je l'ai choisie simplement pour que les releases soient faciles à voir dans le flot des commentaires.
Citer : Posté le 17/06/2020 21:57 | #
Wow, cool
Je mets à jour les paquets sur l'AUR
En fait t'as pas poussé sur master, donc gint-git peut pas être à jour
Citer : Posté le 18/06/2020 19:45 | #
Salut! J'ai pu installer le fxSDK. J'ai seulement du mal à comprendre les premières instructions du Readme de Gint:
Dans le terminal, je dois me positionner dans le dossier principal de gint ou du fxsdk? (ou alors le dépôt de gint aurait dû être cloné dans le dossier du sdk)?
Ensuite, le terminal n'arrive pas à exécuter le --target=fx9860g. Je vois qu'il est aussi question d'un --prefix mais je ne sais pas quoi faire avec.
Citer : Posté le 18/06/2020 21:12 | #
Je mets à jour les paquets sur l'AUR
En fait t'as pas poussé sur master, donc gint-git peut pas être à jour
Eh oui, je l'ai pas dit sur le coup, mais c'est pas encore assez stable ; c'est une bêta, pas une release complète. Mais ça vient bientôt
J'ai seulement du mal à comprendre les premières instructions du Readme de Gint:
Dans le terminal, je dois me positionner dans le dossier principal de gint ou du fxsdk? (ou alors le dépôt de gint aurait dû être cloné dans le dossier du sdk)?
Le README de gint parle uniquement du dépôt de gint, sauf mention explicite. Dans ce cas-là, il faut toujours considérer que tu es dans le dossier principal d'un dépôt clôné. C'est en-effet là que commencent les explications (même si on se déplace dans un nouveau dossier build.fx ensuite poru compiler).
Contrairement à ce que la coloration syntaxique maladroite de Gitea laisse entendre, la commande c'est bien ../configure --target=fx9860g. Le premier mot d'une commande est toujours le nom d'un outil ou programme à invoquer, et traditionnellement les mots qui commencent par un tiret sont des options (-o, --option, --option=valeur sont les formes les plus courantes). Ici tu dois appeler le script ../configure qui est à la racine du dépôt avec l'option --target=fx9860g (littéralement : on cible les Graph mono).
L'option --prefix te permet de choisir le dossier dans lequel gint sera installé. Le nom "prefix" est très classique et tu le retrouves partout dans les instructions d'installation (... de toute ce que tu installes depuis les sources au lieu du gestionnaire de paquets). Ici, tu ne dois normalement pas t'en servir car gint doit s'installer quelque part dans les fichiers de GCC et il trouve le bon endroit tout seul (d'ailleurs la commande affichera où).
Citer : Posté le 19/06/2020 01:51 | #
Je ne comprends pas...J'ai pourtant tout installé du cross-compilateur et malgré ça lorsque je veux faire le build pour fx-cg50 et pour fx-9860g, j'ai tout le temps cette erreur et ne veut plus continuer après:
redeyes@Red-VirtualBox:~/gint/build.cg$ ../configure --target=fxcg50
No prefix specified, let's ask the compiler:
sh-elf-gcc --print-search-dirs | grep install | sed 's/install: //'
../configure: ligne 160: sh-elf-gcc : commande introuvable
Got ' '.
Directory does not exist (or is not a directory), giving up.
Pourtant sh-elf-gcc est bien dans mon pc et mon PATH contient le dossier qui le possède:
/home/redeyes/.local/bin:/usr/local/sbin:usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin:/home/redeyes/opt/sh-elf-2.34-9.3.0/bin
Résultat, je ne sais plus quoi faire.
Citer : Posté le 19/06/2020 02:03 | #
Que donne un ls ~/opt ? Au passage, la commande export PATH=PATH:new/path est à lancer à chaque ouverture de terminal, sauf si tu as ajouté la commande au fichier ~/.profile ou .bashrc.
Citer : Posté le 19/06/2020 20:31 | #
Je peux retenter le build de gint à présent?
edit: le build ne marche toujours pas
Citer : Posté le 19/06/2020 21:31 | #
Je devrais préciser que .profile n'est chargé qu'au lancement de ta session donc il faut au moins te déconnecter.
Si tu as un doute, ouvre un terminal au hasard et vérifie que le dossier est bien dans ton PATH, puis que GCC est bien trouvé (which sh-elf-gcc te le dira).
Au fait ne configure pas avec sudo.
Citer : Posté le 20/06/2020 13:57 | #
J'ai tout recommencé à zéro pour la compilation de gcc, maintenant sh-elf-gcc est bien repéré par le terminal!
Le ../configure --target= m'autorise le make pour fx9860 et cg50, mais j'ai cette erreur qui apparaît:
make: *** [Makefile:109: src/font5x7.png.o] Error 1
C'est quand je veux faire le build pour fx9860g. Et pour cg50 c'est à peu près la même erreur, mais pour l'autre image font8x9.png.
Citer : Posté le 20/06/2020 14:14 | #
L'outil fxconv du fxSDK a voulu appeler sh-elf-objcopy à un moment de la conversion. Tout comme sh-elf-gcc, il devrait être quelque part dans ton PATH et disponible. Est-ce que which sh-elf-objcopy te renvoie bien quelque chose ? (Ça me surprend un peu cette erreur parce que binutils doit être installé si GCC marche, mais bon.)
Citer : Posté le 20/06/2020 14:30 | #
Comme les erreurs que je recevais portaient surtout sur le fait que les fichiers sh-elf-objcopy et sh-elf-ar n'étaient pas retrouvés, j'ai vu dans le dossier du PATH que ces fichiers s'appelaient sh-elfobjcopy et sh-elfar. Je les ai juste renommés dans le dossier en ajoutant le "-" manquant .
Citer : Posté le 20/06/2020 14:45 | #
Ah mais je vois que tu as oublié un caractère dans la commande de binutils. C'est "--program-prefix=sh-elf-" avec un tiret à la fin !
Citer : Posté le 20/06/2020 22:26 | #
Ah mais je vois que tu as oublié un caractère dans la commande de binutils. C'est "--program-prefix=sh-elf-" avec un tiret à la fin !
Du coup dans ce même fichier je dois rajouter ce petit tiret dans tous les noms de fichiers sh-elf ?
Citer : Posté le 20/06/2020 22:34 | #
Tu devrais oui, dans le dossier bin, renommer tout le monde. Je suppose que ça marche, enfin si un jour t'as des problèmes bizarres ça viendra peut-être de là. x)
Citer : Posté le 20/06/2020 22:34 | #
faut recompiler, il me semble que le nom est utilisé en interne
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.
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).
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 :
La façon safe de transposer ça dans la nouvelle API sans risquer de problème est ceci :
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 :
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 :
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.