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 24/12/2019 21:49 | #
Ah super, ça marche ! J'aurais dû regarder les branches sur gitea...
Citer : Posté le 08/01/2020 19:26 | #
J'ai observé un comportement étrange du clavier causé par l'alternance de pollevent et getkey:
*note: je n'ai pas réussi à reproduire exactement le bug décrit sur dev, mais celui-ci est très similaire
voici le code suivant
#include <gint/keyboard.h>
#include <gint/clock.h>
void clavier_par_pollevent()
{
while (1)
{
key_event_t e=pollevent();
while(e.type!=KEYEV_NONE)
{
dclear(C_WHITE);
/* J'ai remplacé les actions par des print pour les 5 instructions suivantes */
if(e.key==KEY_LEFT)
dtext(1, 1, "LEFT", C_BLACK, C_NONE);
if(e.key==KEY_RIGHT)
dtext(1, 1, "RIGHT", C_BLACK, C_NONE);
if(e.key==KEY_SHIFT)
dtext(1, 1, "SHIFT", C_BLACK, C_NONE);
if(e.key==KEY_UP)
dtext(1, 1, "UP", C_BLACK, C_NONE);
if(e.key==KEY_DOWN)
dtext(1, 1, "DOWN", C_BLACK, C_NONE);
if(e.key==KEY_EXE || e.key==KEY_EXIT)
return;
dupdate();
e=pollevent();
}
sleep_ms(3,5);
}
}
int main(void)
{
dclear(C_WHITE);
dupdate();
clavier_par_pollevent();
clearevents();
while (1)
{
int key=getkey().key;
dclear(C_WHITE);
if (key==KEY_UP)
dtext(1, 1, "UP", C_BLACK, C_NONE);
if (key==KEY_LEFT)
dtext(1, 1, "LEFT", C_BLACK, C_NONE);
if (key==KEY_DOWN)
dtext(1, 1, "DOWN", C_BLACK, C_NONE);
if (key==KEY_RIGHT)
dtext(1, 1, "RIGHT", C_BLACK, C_NONE);
if (key==KEY_EXE)
dtext(1, 1, "EXE", C_BLACK, C_NONE);
if (key==KEY_SHIFT)
dtext(1, 1, "SHIFT", C_BLACK, C_NONE);
dupdate();
if (key==KEY_EXIT || key==KEY_MENU) // Quitte le programme : remarque, ça n'arrivera pas si ça plante avant :E
break;
}
return 1;
}
Lorsque qu'on lance l'addin, il faut appuyer sur les flèches et shift et vérifier qu'elles sont bien affichées.
Ensuite on valide par exe ou menu
et on appuie ensuite sur les flèches, shift et exe.
Pour quitter, on appuie sur exit ou menu
Avec ce code j'ai décelé les bugs suivants :
Cela me semble assez vicieux...
Ajouté le 08/01/2020 à 19:36 :
Un de plus:
Si on valide la première fois avec menu, menu n'est plus détecté ensuite,
EDIT: Exit n'est détecté qu'en seconde pression
Note: Les pressions sur la touche menu sont alors bien identifiées, mais la touche renvoyée est erronée puisque l'écran s'efface bien lorsque l'on appuie sur menu mais n'affiche rien d'autre
Ajouté le 10/01/2020 à 10:30 :
Le bug n'est pas dû au fait que la touche précédente soit encore enfoncée au moment de l'appel de getkey();
En effet, j'arrive à reproduire les bugs cité précedemment avec ce code
#include <gint/keyboard.h>
#include <gint/clock.h>
void clavier_par_pollevent()
{
while (1)
{
key_event_t e=pollevent();
while(e.type!=KEYEV_NONE)
{
dclear(C_WHITE);
/* J'ai remplacé les actions par des print pour les 5 instructions suivantes */
if(e.key==KEY_LEFT)
dtext(1, 1, "LEFT", C_BLACK, C_NONE);
if(e.key==KEY_RIGHT)
dtext(1, 1, "RIGHT", C_BLACK, C_NONE);
if(e.key==KEY_SHIFT)
dtext(1, 1, "SHIFT", C_BLACK, C_NONE);
if(e.key==KEY_UP)
dtext(1, 1, "UP", C_BLACK, C_NONE);
if(e.key==KEY_DOWN)
dtext(1, 1, "DOWN", C_BLACK, C_NONE);
if((e.key==KEY_EXE || e.key==KEY_EXIT) && e.type==KEYEV_UP)
return;
dupdate();
e=pollevent();
}
sleep_ms(3,5);
}
}
int main(void)
{
dclear(C_WHITE);
dupdate();
clavier_par_pollevent();
clearevents();
while (1)
{
int key=getkey().key;
dclear(C_WHITE);
if (key==KEY_UP)
dtext(1, 1, "UP", C_BLACK, C_NONE);
if (key==KEY_LEFT)
dtext(1, 1, "LEFT", C_BLACK, C_NONE);
if (key==KEY_DOWN)
dtext(1, 1, "DOWN", C_BLACK, C_NONE);
if (key==KEY_RIGHT)
dtext(1, 1, "RIGHT", C_BLACK, C_NONE);
if (key==KEY_EXE)
dtext(1, 1, "EXE", C_BLACK, C_NONE);
if (key==KEY_SHIFT)
dtext(1, 1, "SHIFT", C_BLACK, C_NONE);
dupdate();
if (key==KEY_EXIT || key==KEY_MENU) // Quitte le programme : remarque, ça n'arrivera pas si ça plante avant :E
break;
}
return 1;
}
Projet de jeu multijoueur : 1V1 3D
Une lib de debug simple : la liblog
Citer : Posté le 10/01/2020 10:40 | #
Alright, il va falloir que je regarde en détail. Quelques remarques :
getkey() ne renvoie jamais KEY_SHIFT puisque SHIFT est utilisé comme modifieur pour former des combinaisons. C'est écrit dans la doc. Pour l'obtenir, appelle getkey_opt() sans GEKEY_MOD_SHIFT.
Ça il faut que je regarde.
Même si le retour au menu n'est pas encore implémenté, les appuis sur MENU sont quand même interceptés. Tu peux le voir dans le code. Donc getkey() ne renvoie jamais KEY_MENU sans modifieur. Pour l'avoir, appelle getkey_opt() sans GETKEY_MENU.
Ça il faut que je regarde.
Ton code ne dessine rien quand on appuie sur MENU de toute façon... ?
Citer : Posté le 10/01/2020 10:46 | #
J'avais oublié que getkey ne renvoyait jamais shift
Ton code ne dessine rien quand on appuie sur MENU de toute façon... ?
Mon code est sensé quitter l'addin lorsque l'on appuie sur menu
Or, il ne quitte pas, mais efface l'écran comme si on avait appuyé sur une touche, mais sans afficher de texte pour autant.
Je vais essayer d'utiliser directement getkey_opt()
Ajouté le 10/01/2020 à 10:55 :
J'utilise maintenant getkey_opt(GETKEY_REP_ARROWS,0) mais j'ai toujours les memes bugs (à l'exception de celui que j'avais mentionné avec shift)
Ceux concernant les touches menu et exe sont toujours présents
#include <gint/keyboard.h>
#include <gint/clock.h>
void clavier_par_pollevent()
{
while (1)
{
key_event_t e=pollevent();
while(e.type!=KEYEV_NONE)
{
dclear(C_WHITE);
/* J'ai remplacé les actions par des print pour les 5 instructions suivantes */
if(e.key==KEY_LEFT)
dtext(1, 1, "LEFT", C_BLACK, C_NONE);
if(e.key==KEY_RIGHT)
dtext(1, 1, "RIGHT", C_BLACK, C_NONE);
if(e.key==KEY_SHIFT)
dtext(1, 1, "SHIFT", C_BLACK, C_NONE);
if(e.key==KEY_UP)
dtext(1, 1, "UP", C_BLACK, C_NONE);
if(e.key==KEY_DOWN)
dtext(1, 1, "DOWN", C_BLACK, C_NONE);
if((e.key==KEY_EXE || e.key==KEY_EXIT) && e.type==KEYEV_UP)
return;
dupdate();
e=pollevent();
}
sleep_ms(3,5);
}
}
int main(void)
{
dclear(C_WHITE);
dupdate();
clavier_par_pollevent();
clearevents();
while (1)
{
int key=getkey_opt(GETKEY_REP_ARROWS,0).key;
dclear(C_WHITE);
if (key==KEY_UP)
dtext(1, 1, "UP", C_BLACK, C_NONE);
if (key==KEY_LEFT)
dtext(1, 1, "LEFT", C_BLACK, C_NONE);
if (key==KEY_DOWN)
dtext(1, 1, "DOWN", C_BLACK, C_NONE);
if (key==KEY_RIGHT)
dtext(1, 1, "RIGHT", C_BLACK, C_NONE);
if (key==KEY_EXE)
dtext(1, 1, "EXE", C_BLACK, C_NONE);
if (key==KEY_SHIFT)
dtext(1, 1, "SHIFT", C_BLACK, C_NONE);
dupdate();
if (key==KEY_EXIT || key==KEY_MENU) // Quitte le programme : remarque, ça n'arrivera pas si ça plante avant :E
break;
}
return 1;
}
Ajouté le 10/01/2020 à 10:57 :
Cela veut dire que le bug ne vient pas du fait que la touche soit pressée alors que getkey est appelé, mais d'une mauvaise transition? entre le passage de pollevent à getkey ??
C'est vachement étrange quand meme, peut être que ça peut venir de mon code, mais là je ne vois pas
Projet de jeu multijoueur : 1V1 3D
Une lib de debug simple : la liblog
Citer : Posté le 10/01/2020 11:19 | #
Je n'ai aucun des bugs que tu décris sur ma Graph 75+E, ma Graph 35+E II et ma Graph 90+E... par souci de lisibilité, j'ai rajouté plus d'infos à l'écran, et il n'y a absolument rien d'anormal.
#include <gint/keyboard.h>
#include <gint/clock.h>
void print_key(int x, int y, int key)
{
if(key==KEY_UP)
dtext(x, y, "UP", C_BLACK, C_NONE);
if(key==KEY_RIGHT)
dtext(x, y, "RIGHT", C_BLACK, C_NONE);
if(key==KEY_DOWN)
dtext(x, y, "DOWN", C_BLACK, C_NONE);
if(key==KEY_LEFT)
dtext(x, y, "LEFT", C_BLACK, C_NONE);
if(key==KEY_SHIFT)
dtext(x, y, "SHIFT", C_BLACK, C_NONE);
if (key==KEY_EXE)
dtext(x, y, "EXE", C_BLACK, C_NONE);
if (key==KEY_MENU)
dtext(x, y, "MENU", C_BLACK, C_NONE);
}
void clavier_par_pollevent()
{
while (1)
{
while(1)
{
key_event_t e = pollevent();
if(e.type==KEYEV_NONE) break;
if((e.key==KEY_EXE || e.key==KEY_EXIT) && e.type==KEYEV_UP) return;
dclear(C_WHITE);
print_key(1, 1, e.key);
if(e.type==KEYEV_DOWN) dtext(1, 9, "DOWN", C_BLACK, C_NONE);
if(e.type==KEYEV_UP) dtext(1, 9, "UP", C_BLACK, C_NONE);
dtext(1, 17, "pollevent", C_BLACK, C_NONE);
dupdate();
}
sleep_ms(3,5);
}
}
int main(void)
{
dclear(C_WHITE);
dtext(1, 17, "pollevent", C_BLACK, C_NONE);
dupdate();
clavier_par_pollevent();
clearevents();
dclear(C_WHITE);
dtext(1, 17, "getkey_opt", C_BLACK, C_NONE);
dupdate();
while (1)
{
key_event_t e = getkey_opt(GETKEY_REP_ARROWS,0);
dclear(C_WHITE);
print_key(1, 1, e.key);
if(e.type==KEYEV_DOWN) dtext(1, 9, "DOWN", C_BLACK, C_NONE);
if(e.type==KEYEV_UP) dtext(1, 9, "UP", C_BLACK, C_NONE);
if(e.type==KEYEV_HOLD) dtext(1, 9, "HOLD", C_BLACK, C_NONE);
dtext(1, 17, "getkey_opt", C_BLACK, C_NONE);
dupdate();
if (e.key==KEY_EXIT || e.key==KEY_MENU) // Quitte le programme : remarque, ça n'arrivera pas si ça plante avant :E
break;
}
return 1;
}
Tu as une calto SH3 ou quoi ?
Citer : Posté le 10/01/2020 11:41 | #
En fait il n'y avait pas de bug, le problème était juste lié à l'utilisation de getkey_opt avec des mauvaises options, le tout associé à une erreur de ma part
Projet de jeu multijoueur : 1V1 3D
Une lib de debug simple : la liblog
Citer : Posté le 12/01/2020 21:01 | #
Nyaa~, c'etait pour savoir comment je suis supposée utiliser les fonction BFiles ?
Nottament pour le chemin vers le fichier…
parceque je trouve pas
Citer : Posté le 12/01/2020 21:23 | #
Déjà tu inclus <gint/bfile.h>, rien d'inattendu ici.
Ensuite tu crées des chemins avec des tableaux de uint16_t. Tu peux le faire à la FONTCHARACTER :
Ou tu peux le faire avec style :
Citer : Posté le 12/01/2020 22:13 | #
Ba-baka…
Merci, il fallait donc remplacer les yens par des antislash
Citer : Posté le 12/01/2020 22:15 | #
Ah ! Oui, c'est parce que le PDF a été encodé en Shift-JIS, qui n'est pas compatible avec ASCII sur ce caractère exact.
Citer : Posté le 12/01/2020 22:57 | #
Merci beaucoup, ça marche ♥
Ce serait possible d'avoir de l'aide pour exposer les autres fonction BFile ? J'ai besoin de faire un explorateur de fichier
Citer : Posté le 12/01/2020 23:01 | #
Oui, rien de bien difficile, il suffit d'ajouter les syscalls correspondants. Les appels sont documentés dans le SimLo. Les prototypes sont à ajouter dans <gint/bfile.h>. Le code consiste juste à appeler les sycalls dans src/core/syscalls.S.
Je peux le faire bien sûr, mais comme je suis à la bourre en ce moment je le mentionne au cas où tu préfères aller plus vite.
Citer : Posté le 13/01/2020 00:14 | #
merci, je devrai pouvoir faire ça mardi
Ajouté le 13/01/2020 à 16:07 :
marquer la date d'une pieere blanche, non seulement j'ai pas laissé la tâche à l'abandon, mais en plus, j'ai fini en avance
https://gitea.planet-casio.com/Lephenixnoir/gint/pulls/7
Ajouté le 13/01/2020 à 21:13 :
BFile_FindFirst,Next,Close sont fait, faut plus qu'a tester, et documenter, mais pour finir la doc je vais avoir besoin des header de la fxlib… mais ca attendra demain
Ajouté le 14/01/2020 à 11:32 :
les tests sont fait, maintenant c'est l'heure de la documentation ♥
Citer : Posté le 14/01/2020 11:34 | #
Merci beaucoup ! J'ai lu le diff, ça a l'air clean, je testerai par principe et ça partira direct dans le code. Tu peux modifier cette PR en continuant de pousser pour les autres fonctions.
Ah aussi j'ai repéré des crashs il y a un moment pour des workflows assez simples (créer - ouvrir - écrire - fermer un fichier), je pense que c'est une interaction bizarre entre gint et BFile, si ça se produit ce n'est pas trop grave.
Citer : Posté le 14/01/2020 12:25 | #
fait, ya plus qu'a tester et que qu'elqu'un check les header de la fxlib.
maintenant, j'ai une question, il y a un moyen pour afficher une chaine en uint16_t sur la calculatrice ?
Citer : Posté le 14/01/2020 12:43 | #
Aaah ! Bonne question ça. Je suppose qu'on pourrait le coder dans le sprintf(). Tu as %ls qui donne normalement des wchar_t. On peut jouer avec ça, puisque de toute façon wchar_t n'est pas supporté. Mais y'aura pas de FONTCHARACTER pour autant.
La meilleure façon de faire serait d'avoir une vraie conversion de FONTCHARACTER vers utf-8 et d'utiliser l'utf-8 dans dtext(), ce qui n'est pas encore implémenté dans topti mais pas loin puisque comme tu le sais on a déjà la police, et ce serait de bon goût parce que ça généraliserait la notion de charset qui est présente actuellement.
Citer : Posté le 14/01/2020 13:24 | #
je vais regarder les syscall en attendant
Citer : Posté le 14/01/2020 19:57 | #
Lors d'une SysERROR, à quoi correspond un "TLB miss write" sur fx9860g ?
Projet de jeu multijoueur : 1V1 3D
Une lib de debug simple : la liblog
Citer : Posté le 14/01/2020 20:00 | #
TLB miss write indique la nature de l'erreur. Ça signifie que tu as fait un accès en écriture à une zone de mémoire qui n'existe pas. Le pointeur fautif (l'adresse qui n'existe pas) est normalement indiqué dans TEA. L'adresse de l'instruction qui fait l'accès fautif est indiquée dans PC. Si tu récupères le fichier de sortie du linker dans ton dossier de build tu peux retrouver dans quelle fonction ça se situe.
Citer : Posté le 14/01/2020 20:01 | #
Je vais regarder ça, mais je sais pas pourquoi je sens que c'est une écriture à 0x00000000
Projet de jeu multijoueur : 1V1 3D
Une lib de debug simple : la liblog
Citer : Posté le 14/01/2020 20:02 | #
Ce ne serait pas une erreur parce que l'adresse 0 est mappée en fait, ce qui est d'ailleurs pas pratique parce que les accès à NULL passent inaperçus...