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 08/07/2016 22:28 | #
À la rémanence de l'écran. Et ça, on y peut pas grand chose à part adapter les valeurs des timers du gris au mieux.
Citer : Posté le 08/07/2016 22:31 | #
Hmm... les bandes sont supposées être précisément ce qu'on ne voit pas sur cette vidéo. ^^'
Qu'on se mette bien d'accord : s'il y a quatre rectangles -- blanc, gris clair, gris foncé et noir -- c'est parce que c'est ce que j'ai mis dans la mémoire vidéo. C'est voulu. Ce que je veux maintenant c'est que ces quatre couleurs soient les plus stables et jolies possibles.
En l'occurrence ça clignote pas mal, mais il n'y a pas de « bandes parasites ». Ce sont des bandes qui remontent ou descendent tout l'écran en permanence et causent des variations de couleur là où elles passent : des dégradés moches, des inversions de couleur et même parfois la suppression pure et simple de l'illusion de gris, ne laissant que du noir et blanc. Ça c'est ce que j'ai réussi à éviter.
Citer : Posté le 08/07/2016 22:33 | #
Ce qu'il voulait dire, c'est que, sans doute à cause des 25 fps de ta caméra, on voit de légères bandes parasites à l'écran. Mais c'est pas du tout dérangeant par rapport à ce que j'avais testé de mon coté, via revolutionfx et l'addin de test.
Citer : Posté le 09/07/2016 08:46 | #
Oh, je vois. On voit quelques bandes sur le gris foncé au début de la vidéo.
Alors Ninestars, il faut que je précise. Le moteur de gris, c'est pas de la magie. Les bandes, il y en a toujours. La question c'est comment on s'arrange pour qu'on les voie pas trop. Il y a deux solutions :
- Elles sont si rapides que de loin (30 cm) l'effet est négligeable
- Elles ne bougent (quasiment) pas
J'ai des valeurs pour les deux solutions. Le premier cas, c'est celui que j'ai mis dans la vidéo. Le clignotement est assez fort, j'essaie d'y travailler mais c'est pas gagné d'avance. Le second, il est cool parce qu'il est hyper stable (aucun clignotement) et les couleurs sont pas trop mal. Son problème c'est qu'il y a une zone de 15-20 pixels au milieu dans laquelle la bande statique réside, où les couleurs sont plus ou moins inversées et un peu altérées. Ça bouge très lentement (genre d'un pixel par second) et ça reste plus ou moins dans la même zone, mais les pixels gris clair et gris foncé échangent carrément leurs positions.
Quand on dessine un tileset ou un objet qui ne possède pas de grandes zones de gris, ce dernier effet ne se voit pas trop, mais le rendu est pas très fidèle. Si on veut obtenir quelque chose de correct, il faut augmenter la vitesse des bandes jusqu'à ce qu'elle atteigne plus ou moins la fréquence « propre » de l'écran.
Le problème c'est qu'il y a deux effets à surveiller. J'ai compris comment calculer des valeurs pour lesquelles il n'y a pas de clignotement, mais pour les bandes c'est plus subtil. Ce dont j'ai peur c'est que si on fait accélérer les bandes jusqu'à ce qu'elles se confondent avec elles-mêmes à chaque passage (et ainsi disparaissent plus ou moins), alors cela crée nécessairement du clignotement. On ne peut pas se permettre de laisser des bandes, c'est très moche. Déjà sur cet exemple tu avais de dire que c'était moyen, et c'est clairement excellent par rapport à des réglages bourrins.
Pour qualifier un peu mieux, les meilleures suppressions de bandes sont dans la vidéos. Les réglages qui éliminent le mieux les clignotements les font disparaître totalement à 30 centimètres de distance.
Voilà, tout ça pour dire qu'on ne peut pas attendre des miracles et que vous vous casserez probablement les yeux si vous tentez de jouer à un jeu en gris à 5 centimètres.
Citer : Posté le 09/07/2016 09:03 | #
Est ce qu'on pourrais avoir le G1A pour tester chez nous le gris, si bien sur il marche sur SH4 ?
- Kirby's DreamLand : Gobe , Gobe , Gobe !!!
- L'invasion Seanchans : Détruit la flotte ennemis a bord du "Danseur des vagues".
Citer : Posté le 09/07/2016 09:11 | # |
Fichier joint
Il marche sur les deux machines, mais il faut le tester sur SH4. Les valeurs que j'ai ne fonctionnent pas bien sur SH3.
Tu peux te balader dans les menus. Pour le moteur de gris ([4]), les touches [F1] à [F3] configurent les valeurs que j'ai trouvées. La touche [F6] déplace le curseur. Les touches [←] et [→] modifient la valeur sélectionnée de 1, et [↑] et [↓] de 10.
Citer : Posté le 09/07/2016 09:26 | #
Merci
- Kirby's DreamLand : Gobe , Gobe , Gobe !!!
- L'invasion Seanchans : Détruit la flotte ennemis a bord du "Danseur des vagues".
Citer : Posté le 12/07/2016 18:30 | # |
Fichier joint
Bon, j'ai fais des tests avec des sprites... voilà à quoi ça ressemble.
En vrai le rendu est magnifique. Pour du gris léger, utilisé uniquement comme « décoration » et pas en grandes bandes comme la dernière fois c'est assez superbe
Citer : Posté le 12/07/2016 20:44 | #
Ah c'est top !
Citer : Posté le 14/07/2016 10:15 | #
Joli travail, il y a de quoi être fier !
Citer : Posté le 14/07/2016 21:01 | #
J'ai fait quelques tests sur la vitesse des bitmaps. C'est assez... énorme
J'ai compté le temps mis pour afficher des bitmaps par ML et gint. Les valeurs affichées sont dans une unité quelconque. « k » et « M » signifient milliers et millions, respectivement.
-------------------------------------------------------------------
128x64 0, 0 oui 11.9 M 1.06 M 11.2
128x64 -64, -32 oui 3.25 M 335 k 9.69
128x64 1, 1 oui 15.2 M 1.65 M 9.16
gint est ici 10 fois plus rapide ! \o/
Citer : Posté le 15/07/2016 12:40 | #
Oui en effet je parlais des raies qui se déplacent verticalement à l'écran. Et si tu montes en fréquence elles ne sont pas sencées disparaître ?
En tout cas cette effet n'est pas visible sur des sprites, c'est juste sur des grands rectangles ce que l'on n'affiche pas dans un jeu donc c'est parfait
Gint 10x plus rapide que ml... Moi qui pensait que ML était le summum
Citer : Posté le 15/07/2016 12:46 | #
Je suis au minimum sur la vidéo, si je monte en fréquence c'est pire... bon, faudra éviter les gros rectangles quoi
Cela dit, j'ai encore trouvé des opti ce matin. Faudra que je teste pour quantifier mais il n'est pas impossible que la vitesse monte encore de 30-40%. Je commence à tomber à court d'idées par contre x)
Ajouté le 19/07/2016 à 14:16 :
Bon, j'ai un très joli problème de gestion de mémoire.
Pour faire simple, il y a une unité dans la machine appelée MMU (pour Memory Management Unit) dont le rôle est de traduire les adresses logiques (des pointeurs) en adresses physiques (vous vous doutez bien qu'il y a beau avoir 4 Gio d'adresses de pointeurs, il n'y a pas autant de mémoire physique).
Pour calculer les adresses physiques, cette unité utilise un tableau contenant les correspondances entre des blocs de mémoire logique et des blocs de mémoire physique. Ce tableau s'appelle le TLB (pour Translation Look-aside Buffer), et je viens de vous apprendre ce que sont 90% de vos System ERROR (élégamment nommées « TLB ERROR!! »). Ça se produit quand vous demandez d'aller lire la mémoire à une adresse qui n'est pas enregistrée dans le TLB.
C'est ce que je rencontre maintenant. Sur SH4 je les détecte moi-même, mais sur SH3 j'ai une System ERROR, ce qui signifie que l'erreur se produit avant même que je n'aie initialisé le gestionnaire d'exceptions et remplacé celui du système (c'est-à-dire dès le lancement du programme).
En général cette « erreur » est en fait un signalement : dans un système multi-processus, chaque correspondance de bloc entre la mémoire logique et la mémoire physique existe pour un seul processus. (De cette manière, si un autre processus tente d'accéder à la mémoire, l'accès lui est refusé : c'est la base de la sécurité.) Ainsi quand un processus A demande la RAM mais qu'il n'y en a plus, on sélectionne généralement des données peu utilisées dans la RAM (qui appartiennent à un processus B) et on les place sur le disque en attendant (dans un espace connu sous le nom de swap). On peut alors allouer la zone libérée au processus A. Si le processus B tente d'accéder à sa mémoire, le système de rend compte qu'il l'a donnée au processus A et réalise alors une commutation : il recharge les données du processus B dans la RAM.
Ici la solution est plus simple puisqu'il n'y a qu'un seul processus : il suffit de charger la correspondance entre mémoire logique et mémoire physique qui permettra d'accéder aux données que l'on cherche. Cependant, le système ne semble pas le faire (puisqu'il affiche les « TLB ERROR!! » au lieu de les résoudre) : il se permet a priori de tout charger d'un coup parce que le TLB est assez gros et de ne plus y toucher après en partant du principe que l'add-in n'a pas à tenter d'aller lire de la mémoire ailleurs.
Ça pourrait se passer tranquillement comme ça mais il n'empêche que j'ai de telles erreurs quand mes programmes deviennent gros et la limite est vite atteinte (encore plus vite sur SH3 que sur SH4). Il va donc falloir que je travaille au remplissage du TLB et c'est un peu long.
Voilà voilà, c'était surtout pour donner quelques nouvelles (vu que tout allait bien il y a quelques jours et depuis plus rien).
Ajouté le 11/08/2016 à 22:08 :
Tiens, je passe ici et je me rends compte que je n'ai pas donné de nouvelles depuis que je suis rentré de Bretagne.
J'ai trouvé une sorte de workaround qui oblige le système à charger ce que je veux dans le TLB avant d'initialiser gint pour ne plus avoir à y toucher après. Je pourrais modifier le TLB manuellement mais c'est une mauvaise idée. Cette méthode est garantie de fonctionner pour les add-ins de moins de 128 kio et garantie d'échouer pour ceux de plus de 384 kio. Entre les deux, c'est plus ou moins de la chance par rapport à ce que dit le système. J'ai pas encore essayé. Btw, ce que j'ai découvert coïncide avec la limite de 512 kio pour un add-in.
Je vais utiliser gint pour la vingtième édition du CPC, histoire d'en tester/démontrer les capacités en milieu réel. Je n'ai pas encore de garantie que ça fonctionnera sur toutes les machines mais j'ai bon espoir. À suivre !
Ajouté le 16/10/2016 à 10:01 :
Salut à tous ! Ça fait longtemps que j'ai pas posté sur ce topic. Histoire de répondre au message précédent, j'ai été content de constater quand dans l'immense majorité des cas gint a fait tourner sans défaut le programme sur des modèles variés ! À part quelques problèmes de backlight sur la G75, la portabilité a été au-delà de mes espérances. Le jeu en question, Arena, a finalement remporté le CPC
Le problème qui m'intéresse maintenant concerne plutôt l'API, et quelque chose que les dev's vont souvent utiliser. Il s'agit des événements.
Cake a proposé, qu'à la place d'utiliser getkey() et d'autres techniques spécifiques pour lire les événements du clavier, du port série (quand il sera implémenté) et tout ce qu'on pourrait ajouter, on centralise les informations dans un système d'événements comme celui de la SDL.
Cela pose quelques problèmes techniques, le premier étant celui du multi-getkey. Voici en quoi :
- En utilisation « normale » du clavier, on attend deux types d'événements : les pressions de touches et les relâchements de touche. Une seule touche par événement, tout arrive séquentiellement et tout se passe bien.
- En mode multi-getkey, on s'intéresse tout particulièrement aux pressions simultanées de touches et les relâchements importent peu. Les événements devraient pouvoir contenir plusieurs touches à la fois.
Ma question, pour vous du point de vue de l'utilisation de la lib', est : comment voulez-vous utiliser le getkey et le multi-getkey dans vos programmes ? (événements ou pas événements, un mode normal et un mode multi-getkey séparés ou confondus, deux fonctions getkey() et multigetkey() comme aujourd'hui, ou n'importe quoi d'autre)
Du point de vue technique, il y a d'autres problèmes à régler, notamment pour savoir ce qu'on l'on fait des événements accumulés lorsqu'on change de mode. La meilleure solution me semble quand même être de générer les événements clavier à la volée.
Citer : Posté le 16/10/2016 10:15 | #
Pour ma part, j'aimerais une unique fonction qui reçoit en paramètre une liste de touche que l'on souhaite tester et qui modifie la valeur des variables en paramètre.
Genre :
int k_left;
getkey(&k_exe, &k_left)
// k_exe = 0 si pas pressée et 1 sinon
if (k_exe == 1)
{
...
}
Si rien n'est pressé ça bloque
Citer : Posté le 16/10/2016 10:16 | #
Comment veux-tu que la fonction comprenne de quelle touche tu parles dans ton exemple ?
Citer : Posté le 16/10/2016 10:18 | #
Le multi-getkey, c'est caca. cf. le code crado que j'ai dû faire dans Tu Quoque, alors que les events permettent de faire ça proprement.
Le getkey, je suis pas chaud chaud pour, mais on peut imaginer que ça parcourt les events à venir pour uniquement considéré les évènements du type KeyDown.
Je te l'ai déjà dit sur la shout, mais comme môssieur des neufs étoiles exige ma participation ici : franchement, je sais pas pourquoi tu t'enquiquines autant avec le clavier. C'est pas compliqué : quand le timer arrive, tu check les touches qui ont changé d'état depuis le dernier gong, tu push les évènements correspondants (dans un ordre osef mais constant, si possible logique, genre de gauche à droite et de haut en bas), et voilà. (dans ma tête, les deux fonctionnent grâce à des timers quoi. celui du SH4 est juste moins préçis à cause de ce k,oiezngd de module KEYSC)
Le seul cas où tu as effectivement raison de t'enquiquiner selon moi (toujours, j'ai pas changé de corps entretemps), c'est "omg mais comment je sais si telle touche était appuyée à ce moment-là", et la solution évidente : stocker le buffer de clavier dans chaque event (puisque garder ce buffer côté utilisateur, bah, en cas de pipe overflow, il est fucked). Et voilà, t'as mon avis. >_>
Mon blog ⋅ Mes autres projets
Citer : Posté le 16/10/2016 10:19 | #
En effet je n'y avais pas pensé
Merci Cake pour ta participations ici
Citer : Posté le 16/10/2016 10:20 | #
Ceci n'est pas possible non plus, parce qu'il n'est pas possible de prédire le nombre d'arguments variables.
Au mieux, on pourrait faire :
Citer : Posté le 16/10/2016 10:22 | #
Oui, pourquoi pas, je donne l'idée pour l'utilisation, comment ça fonctionne derrière c'est toi qui voit
Ajouté le 16/10/2016 à 10:25 :
Après ça fait pas hyper user friendly comme ça :/
Citer : Posté le 16/10/2016 10:30 | #
J'avoue que le coté évènementiel reste beaucoup plus propre. Après faut voir comment le mettre en pratique de manière user-friendly.
Déjà, je pense que personne n'utilisera gint pour faire autre chose que des jeux je pense. Donc pas d'entrée clavier "classique" à proprement parler. En suivant le raisonnement jusqu'au bout, on a aussi une prépondérance du multigetkey. Le getkey simple restant un cas particulier du multi.
Par contre, je propose pas de solution technique parce que j'ai aucune idée de comment faire. x)
Citer : Posté le 16/10/2016 12:04 | #
Je pense que j'ai trouvé ce que je vais faire. Le dev' va demander des événements clavier, sous différentes formes et le clavier va lui renvoyer les événements qu'il a demandé. Chaque forme d'événements aura une fonction indépendante.
Certaines formes ne donneront que les touches pressées, d'autres donneront les touches unes par unes et d'autres simultanément. Certaines formes pourront utiliser les modificateurs SHIFT et ALPHA, d'autres ne pourront pas. Au final, ce seront les mêmes compte-rendus d'événements claviers, mais pas présentés pareil.
Ma priorité reste d'avoir du code simple pour chaque utilisateur. Darks, je compte bien passer WebCalc sous gint quand le projet sera assez stable. Il faut que le code du clavier soit aussi simple que possible, et la souplesse de ce système me convient plus que pour tout autre système auquel j'ai pensé jusqu'à maintenant. On pourra également intégrer la proposition de Ninestars.
Ça va être difficile à implémenter mais ce n'est pas mon problème, à la limite. Au final, on aboutirait sur différentes interfaces comme :
- getkey()
- multigetkey()
- getevent()
- multigetevent()
Ne criez pas à l'arnaque.