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 29/05/2020 21:59 | #
Avec cette commande, je n’ai pas besoin de tout réinstaller ?
Citer : Posté le 29/05/2020 22:04 | #
C'est un troll, au cas où
Citer : Posté le 29/05/2020 22:15 | #
Je sais, je voulais juste savoir s’il avait installé GCC (visiblement non donc il ne va pas allez bien loin sans) x)
@Leno: regarde ce tuto, bonne chance
Citer : Posté le 29/05/2020 23:28 | #
Bon, c'est sûrement crade, mais quitte à avoir fait des paquets, autant ne pas les avoir faits pour rien.
Si vous voulez juste avoir une installation classique de la toolchain, autant passer par les PKGBUILDS de l'AUR.
Je setup une VM Debian histoire de voir comment ça peut marcher sous Debian, mais dans l'idée faudrait ce script
Puis récupérer les PKGBUILD sur l'AUR (cloner les dépots suivants)
- https://aur.archlinux.org/sh-elf-binutils-casio.git
- https://aur.archlinux.org/sh-elf-gcc-casio.git
- https://aur.archlinux.org/fxsdk-git.git
- https://aur.archlinux.org/gint-git.git
Éventuellement
- https://aur.archlinux.org/mkg3a.git
Je garantis rien, mais ça me parait être convenable vu les galères que certains peu habitués aux environnements unix rencontrent.
Si ça marche, je ferais un tuto plus propre.
Citer : Posté le 30/05/2020 08:57 | #
... mais du coup faut installer en root puisque c'est dans le dossier système, n'oubliez pas ça.
Citer : Posté le 30/05/2020 18:48 | #
Finalement, j'ai reset ma machine virtuelle et j'ai tout réinstallé proprement sans sudo mais j'ai un problème lors du make de gint:
-e > fxconv font8x9.png
Traceback (most recent call last):
File "/home/leno/opt/sh-elf-2.34-9.3.0/bin/fxconv", line 6, in <module>
import fxconv
File "/home/leno/opt/sh-elf-2.34-9.3.0/bin/fxconv.py", line 9, in <module>
from PIL import Image
ModuleNotFoundError: No module named 'PIL'
make: *** [Makefile:114: src/font8x9.png.o] Error 1
Citer : Posté le 30/05/2020 19:03 | #
Comme le message d'erreur l'indique... tu as besoin du module Python PIL. Il est utilisé en l'occurrence pour convertir la police par défaut dans un format approprié.
Citer : Posté le 30/05/2020 21:53 | #
Bon, question à la con niveau gestion de framerate.
J'ai un jeu potentiellement lourd en calcul (jusqu'à ~100~200 objets à l'écran), qui doit tourner à ~20 fps pour être jouable.
Je vois trois solutions :
1 → Faire une boucle qui tourne à fond et qui adapte le mouvement des objets à la vitesse du tick précédent.
Avantage : je risque pas de plantage, et si la calto est assez puissante j'augmente le framerate.
Inconvénient : j'inclus un tas d'opérations sur des flottants pour gérer de manière dynamique la vitesse de mes objets. Potentiellement plus lent
2 → Faire un timer à 20 Hz pour la physique + l'affichage, et gérer les évènements à coup de getkey dans une boucle infinie.
Avantage : le framerate censé être constant
Inconvénient : si j'overflow la période du timer (calcul trop long), je risque le crash
3 → Faire un timer à 20 Hz pour l'affichage, gérer physique + évènements dans une boucle infinie
Avantage : l'affichage est constant à 20 Hz, la physique est aussi réactive que possible.
Inconvénient : idem que n°1, sans le lag visuel.
Des avis sur la solution à adopter ? Je pense partir sur #2 et optimiser à fond pour pas que ça foire. Au passage, si en plus y'a une solution qui permet de garder la vitesse constante quelque soit le niveau d'overclock (juste augmenter les fps/tps), ça serait le feu
Citer : Posté le 30/05/2020 21:59 | #
À mon avis la solution la plus simple est similaire, mais différente de toute ça. Je serais partant pour avoir la boucle principale qui fait dessin, gestion des entrées, simulation de la physique en boucle, sachant que (1) la simulation de la physique tient compte du temps réel écoulé depuis la simulation précédente, et (2) il y a un timer à 20 Hz pour limiter les FPS juste au cas où ça aille plus vite que prévu (le callback incrémente un compteur et chaque frame décrémente le compteur, s'il tombe en négatif tu sleep()).
Ça te donne la même contrainte que ta solution #1 mais si les calculs sont en point fixe y'a rien à craindre. Les perfs c'est vraiment tout sur l'affichage, 200 objets × 10 multiplications de plus par frame ça n'arrive pas à la cheville de 170k accès RAM pour générer les données graphiques.
La solution #2 ne crashe pas en cas de lenteur, mais les interruptions se succéderont sans jamais laisser les entrées clavier se faire gérer par le thread principal, donc tu perds les entrées, ce qui est inacceptable.
Pareil pour la solution #3, ça ne crashe pas non plus, mais si l'affichage est trop long ni la physique ni les événements ne pourrait être effectués donc ton jeu freeze complètement.
J'ai imaginé pas mal de variantes de ça à une époque, mais en fin de compte je ne conseille d'utiliser un timer que si tu veux absolument pas gérer le delta temporel dans le moteur physique. Et dans ce cas, tu mets que les entrées et la physique dans le timer. Ce serait la solution alternative. N'oublie pas que le timer a la priorité et doit rester le plus rapide possible, ce n'est surtout pas l'endroit où mettre la partie la plus sensible du système, qui est le dessin.
Citer : Posté le 30/05/2020 22:19 | #
Bon, du coup je vais faire plus simple, vu ce que tu me dis.
Je résume les quelques tests que j'ai fait, mais en gros afficher un fond + 2000 objets 8×8 à l'écran reste dans les 50 ms correspondants aux 20 Hz que je m'impose.
Vu que j'ai 10× moins d'objets à gérer, et que le calcul physique sera à priori pas 10× plus long que le dessin, autant tout mettre dans la même boucle : si la calto arrive à monter les FPS, tant mieux, ça n'en sera que plus agréable. Et potentiellement on pourra faire des concours de FPS à coup d'overclock (même si ça sera peut-être pas nécessaire
D'ailleurs pour l'affichage des FPS, la libprof c'est adapté ou un peu overkill ?
Citer : Posté le 30/05/2020 22:29 | #
Ça a l'air raisonnable. Pour le calcul des FPS, libprof est très bien ; si tu veux avoir une donnée un minimum précise tu finirais par recoder quasiment la même chose de toute façon.
Citer : Posté le 30/05/2020 23:18 | # |
Fichier joint
Je suis perfectionniste : dfont supporte les polices autres que N&B ? Genre celle en PJ ?
Citer : Posté le 31/05/2020 09:00 | #
Hmm... non, malheureusement ! Mais ce serait une extension intéressant sur G90. Dans ce cas les glyphes seraient des bitmaps et la couleur du texte serait ignorée en général.
Ce que tu peux faire en attendant c'est convertir comme une image et faire une fonction de dessin de texte custom. Ou tu peux séparer en images individuelles si tu préfères, dans ce cas tu peux utiliser fxconv.Grid qui implémente la séparation des glyphes en grille comme dans la conversion des polices.
Ajouté le 31/05/2020 à 22:34 :
Deux bonnes nouvelles aujourd'hui !
1. J'ai enfin réussi à rendre BFile stable avec gint. Il faut faire attention à pas mal de choses quand on sort puis revient dans gint (notamment que le DMA soit pas en train de transférer des trucs, et que toutes les pages soient toujours dans le TLB), mais après un peu d'effort ça a fini par sortir. Je peux écrire des gros fichiers (1M) de façon fiable sans crash, donc c'est super !
2. J'ai enfin ajouté la génération de nombres aléatoires avec un générateur pas trop stupide, à savoir TinyMT. srand() et rand() sont dans <gint/std/stdlib.h> du coup.
En plus de ça, j'ai revérifié que tout marche sur SH3 et tout marche sur SH3.
Plus qu'à gérer le TLB, ce qui permettra enfin de monter la limite de taille des add-ins de 220k à 512k (Graph mono) ou 2M (Graph 90+E), et tout sera bon. C'est l'ultime pirouette technique dont gint a besoin pour faire de l'idée folle de remplacer le noyau du système à la volée une réalité bien tangible.
Ajouté le 01/06/2020 à 09:21 :
Avec tout ça, voici la prochaine release en beta sur la branche master: 2.0.1-beta
Si vous êtes toujours sur la branch compat (parce que vous avez clôné le dépôt il y a plus de 3 semaines), pensez à git checkout master pour la release, voire git checkout dev si vous voulez les versions de développement avec les fonctionnalités le plus vite possible.
Citer : Posté le 01/06/2020 15:51 | #
Question à la con, mais est-ce que ça t'intéresserais que je commence à écrire un addin de tests unitaires ? Ça peut aussi se faire dans gintctl.
Le projet commence à être conséquent, et un truc du genre permettrait de vérifier facilement qu'il n'y ait pas de non-régressions.
Citer : Posté le 01/06/2020 15:53 | #
C'est exactement le but de gintctl. Si tu vois des tests importants qui sont pas dedans, je prends les suggestions/PR avec plaisir.
Citer : Posté le 01/06/2020 15:58 | #
À ma connaissance gintctl ne déroule pas l'ensemble des tests de manière automatique. Tu peux potentiellement passer à coté d'effets de bord un poil chelous. Je regarde ce que je peux faire à ce niveau là.
Bon du coup je passerai le paquet gint-git sur la branche master en même temps que le passage à GCC 10. Ça évitera d'avoir à recompiler 2 fois gint.
Et dernière remarque, il est fort probable qu'une nouvelle lib fixed fasse son apparition dans l'écosystème. Vu que je suis un gros flemmard, je comptais faire les paquets AUR pour la libprof, libimg et potentiellement la libfixed. Deux options : 1. un paquet par lib, faut voir comment les nommer ; 2. un paquet qui installe tout d'un coup, probablement gint-devel. T'as une préférence ?
Citer : Posté le 01/06/2020 16:09 | #
Tu peux pas vraiment dérouler les tests de façon automatique... comment veux-tu vérifier automatiquement qu'un timer de 1 seconde dure une seconde (configuration du CPG) ? Comment veux-tu vérifier les entrées clavier sans appuyer dessus à la main (ghosting) ? Comment tester le driver DMA sachant que si ça se plante vraiment l'add-in crashe et que si les données sont fausses ça se voit qu'à l'écran (écran Graph 90) ? Comment tester que les valeurs du moteurs de gris sont correctes ? Comment tester le retour au menu sachant qu'il faut une entrée de l'utilisateur pour revenir dans l'add-in ? Bref, tu vois un peu l'idée.
Le but reste de tester des bugs de drivers ou de noyau, avec en gros la démarche suivante :
1. Implémenter des outils dans lesquels on peut manuellement tester les drivers et les actions sensibles.
2. Implémenter un maximum d'écrans de visualisation parce que l'information est le nerf de la guerre. Tout doit être visualisable.
3. Pour les trucs automatisables (printf, memcpy et consorts par exemple), y'a des tests automatiques, bien que ce soit sous-développé.
Les tests unitaires de libs sont largement bienvenus dans l'onglet LIBS, par exemple j'ai 768 variantes de memcpy/memmove avec un test unitaire auto que je m'apprête à y ajouter. (On pourrait aussi vérifier automatiquement la sortie de TinyMT, mais bon soyons honnête ça va jamais bugger ça vu qu'on y touchera pas.) Les fixed par exemple ce serait parfait ici !
Hmm si c'est pour faire un paquet pour chaque lib, autant utiliser git. Je vois plus d'intérêt à avoir gint-devel (gint-devel-git ?) ou un truc du type. En fait j'ai un peu peur des collisions de noms dans le schmilblick aussi, genre libimg sur l'AUR ça pue un peu. Peut-être gint-libimg-git sinon.
Citer : Posté le 01/06/2020 23:44 | #
Pour les très gros flemmards, j'ai créé le paquet AUR gint-devel-git.
Il comprend :
– un GCC spécial Casio à jour
– le fxsdk
– mkg3a
– gint
– la libprof
– la libimg
Et d'autres outils qui viendront par la suite.
Et au passage, sh-elf-gcc-casio est passé en version 10.1.0, et gint-git sur la dernière release
Citer : Posté le 02/06/2020 08:21 | #
Niiice, merci beaucoup
Les dérivés de Arch sont maintenant officiellement les distros les plus faciles pour bosser avec gint :3
Ajouté le 11/06/2020 à 18:29 :
J'ai commencé à jouer avec la fonctionnalité cruciale manquant avant la prochain release (gint 2.1) : supporter un TLB rempli dynamiquement. En gros, l'add-in est chargé sélectivement en mémoire à travers un truc qu'on appelle le TLB. Un gros add-in (≥ 220k) ne peut pas être chargé entier d'un coup, et donc il est nécessaire de charger les bouts au fur et à mesure qu'ils sont utilisés quitte à décharger d'autres bouts au passage.
Jusque-là gint nécessite que l'add-in soit chargé entier et le TLB reste inchangé pendant toute l'exécution. Sauf que la limite de 220k est horrible sur Graph 90+E, sachant que le maximum technique est 2M. Donc je commence à chercher à créer et faire fonctionner des add-ins plus gros. Actuellement je fous une énorme image dans l'add-in (que je fais attention de ne pas charger sinon mes routines de dessin et mes drivers sont délaissés !) et donc je travaille avec un add-in à moitié chargé. C'est flippant. ^^"
Le remplissage du TLB qui permet de charger différentes parties de l'add-in ne peut être fait que par l'OS, donc c'est toujours un peu compliqué de savoir si ça va bien se passer. Je vous tiens au courant... :3
Citer : Posté le 11/06/2020 18:50 | #
J'avais déjà fait quelque chose similaire lors de mon prototype de débogueur/traceur. Si tu as de quoi restaurer proprement l'environnement de Casio, ça ne devrait vraiment pas être complexe à mettre en place (en tout cas pour les SH4).
Là où il faut faire gaffe, c'est à l'endroit où tu invoques l'handler de Casio car il doit absolument être en RAM (pour éviter qu'il se fasse décharger). Autre point, ne fais pas mon erreur de vouloir rediriger l'exception (car j'avais des problèmes avec ce qu'affichait l'handler si la zone en question ne pouvais pas être mappée), appelle uniquement le syscall 0x0001.
Es-ce que tu ne serais pas gagnant en termes de perf' si tous les drivers de Gint étais relocalisés en 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.