fxSDK, un SDK alternatif pour écrire des add-ins
Posté le 29/08/2014 22:00
Cette page sert d'index pour la série de topics du fxSDK.
Le fxSDK est une collection d'outils permettant de développer des add-ins pour les calculatrices Casio des séries Graph. C'est une alternative au
fx-9860G SDK et
PrizmSDK qui ne sont plus activement maintenus, et le compagnon classique de mon noyau
gint.
Index des topics
Ce projet existe depuis 2015, alors il y a pas mal de topics liés. En voici une liste complète !
Topics principaux
Installation du fxSDK
Tutoriels
Compatibilité sur calculatrice et PC
Côté PC, le fxSDK est compatible avec
Linux, Mac OS, et WSL pour Windows ; normalement tout le monde peut l'utiliser. Je teste constamment sous Linux, et WSL est un Linux donc c'est testé aussi. Je n'ai pas de Mac OS donc il peut y avoir quelques surprises, mais en général c'est l'affaire de corriger un bug ou deux.
En termes de calculatrices, le fxSDK supporte :
Calculatrices monochromes
Graph 35+E II
Graph 35+ USB / Graph 35+E (SH3/SH4)
Graph 75/75+/75+E
Graph 85/85 SD/95 (SD) (pas activement testé)
Calculatrices couleurs
Graph Math+ (avec MPM)
Graph 90+E / fx-CG 50
Prizm fx-CG 10/20
Comment installer le fxSDK et coder des add-ins
Le fxSDK s'installe à partir de dépôts Git sur la
forge de Planète Casio (par exemple
Lephenixnoir/fxsdk). Il y en a un peu beaucoup, donc manuellement c'est assez long. Pour que ça aille plus vite et pour simplifier le travail des débutants, il y a un outil appelé
GiteaPC qui peut faire ça pour vous.
Si vous utilisez Windows, vous aurez besoin de WSL pour accéder à un système Linux dans Windows. Heureusement, Microsoft a fait ça bien et c'est facile à faire. Voyez le
tutoriel d'installation de WSL 2 (et l'explication rapide de
ce que WSL 2 est).
Si vous utilisez Mac OS, ouvrez l’œil en lisant les topics pour ne pas manquer les informations supplémentaires et éventuelles déviations par rapport à la procédure normale sous Linux.
Méthode automatique avec GiteaPC (plus rapide / recommandée pour les débutants)
- Suivez le tutoriel d'utilisation de GiteaPC, qui explique comment obtenir le fxSDK.
Méthode AUR pour les utilisateurs Arch/Manjaro/dérivés (ils se reconnaîtront)
- Dark Storm maintient MiddleArch, un dépôt de paquets précompilés qui a entre autres le fxSDK.
Méthode manuelle (plus fine / classique pour les habitués)
- Compilez et installez le cross-compilateur GCC pour SuperH.
- installez (dans cet ordre) les dépôts fxSDK, OpenLibm, fxlibc, gint ; en option, Slyvtt/µSTL_2.3.
Méthode automatique avec plugin VS Code (plus maintenu)
- Yannis300307 a créé un plugin VS Code Casio Dev Tools qui fonctionne sous Windows (avec WSL) et Debian (probablement les dérivés aussi). Il n'est plus maintenu mais vous pouvez quand même tenter votre chance !
Description sommaire du fxSDK
Pour une introduction à l'utilisation du fxSDK qui montre comment utiliser les outils pour développer un add-in, lisez plutôt les
tutoriels d'utilisation de gint. Cette section est juste une description sommaire.
Le cœur du fxSDK est un cross-compilateur GCC pour SuperH, habituellement nommé
sh-elf-gcc. Bien sûr on a avec toute la suite d'outils, dont
as,
ld,
objdump,
objcopy (entre autres). Contrairement au vieux compilateur du SDK, GCC est un compilateur moderne avec beaucoup d'options et capable de très solides optimisations.
Sur la calculatrice, c'est
le noyau gint qui fait la majorité du travail. Il remplace fxlib/libfxcg et une partie de l'OS pour vous offrir des fonctionnalités plus cool et plus rapides. Les add-ins développés avec le fxSDK utilisent gint toutes les trois lignes !
Il y a enfin plusieurs outils utiles sur le PC qui sont utilisés durant le développement ou l'utilisation des add-ins :
- fxsdk est un script shell qui permet de créer et compiler les projets sans se prendre trop la tête. Le système de compilation officiel pour les add-ins est CMake, mais un système plus ancien de Makefile est encore supporté.
- fxconv est un outil très polyvalent qui convertit à la compilation les assets (images, polices, maps....). Il permet de travailler avec des logiciels et formats de fichiers normaux sur le PC et d'avoir automatiquement un format optimisé sur la calculatrice. fxconv est extrêmement extensible et chaque projet peut ajouter des conversions personnalisées.
- fxgxa crée les fichiers g1a (format des add-ins pour Graph monochromes) et g3a (format des add-ins pour Graph couleurs) à partir des programmes compilés.
- fxlink est un outil de communication qui peut transférer des fichiers vers les Graph 35+E II et Graph 90+E en ligne de commande, mais aussi échanger interactivement avec les add-ins gint par le câble USB, et est couramment utilisé pour réaliser des captures d'écran ou captures vidéo des add-ins.
Changelog et informations techniques
Ci-dessous se trouve la liste des posts annonçant les nouvelles versions du fxSDK, ainsi que des liens vers les instructions/tutoriels supplémentaires publiés avec.
Citer : Posté le 12/08/2025 16:46 | #
Oui en effet. Je vais t'en créer un. Pseudo M.machine et avec le même email que ton compte Planète Casio, ça te va ? Sinon envoie-moi ton email voulu par MP.
Citer : Posté le 12/08/2025 16:47 | #
Le même email ça me vas très bien merci !
Citer : Posté le 12/08/2025 16:48 | #
Ok, MP envoyé avec ton mot de passe à usage unique. Pense à baser ta PR sur la branche dev
Citer : Posté le 12/08/2025 16:49 | #
Merciii :DDD
Citer : Posté le 12/08/2025 22:13 | #
Ok alors la je galère vraiment...
J'essaye de convertir en gardant la toolchain de base (sh-elf) et le model cg, ce qui fonctionne parfaitement, il y a ducoup une erreur du linker qui me dit que c'est pas le bon format... j'ai pour information une table de symbole comme ceci :
build/assets/player-sheets/player_idle_sheet.png.o: format de fichier elf32-big
SYMBOL TABLE:
00000000 l d .text 00000000 .text
00000000 l d .data 00000000 .data
00000000 l d .bss 00000000 .bss
00000000 l d .rodata 00000000 .rodata
00000000 g .rodata 00000000 _img_player_idle_sheet
RELOCATION RECORDS FOR [.rodata]:
OFFSET TYPE VALUE
0000000c UNKNOWN _img_player_idle_sheet
mais si je met la toolchain vide, une architecture x86-64 et un outputtarget avec elf64-x86-64 (qui n'intervient a aucun moment dans l'assemblage), j'obtient un fichier "corrompu" avec les symboles suivants :
build/assets/player-sheets/player_idle_sheet.png.o: format de fichier elf64-x86-64
SYMBOL TABLE:
0000000000000000 g .rodata 0000000000000000 _img_player_idle_sheet
RELOCATION RECORDS FOR [.rodata]:
OFFSET TYPE VALUE
000000000000000c R_X86_64_32 _img_player_idle_sheet+0x0000000000000014
Ici, je pense que le fait que le format de fichier sois elf64-x86-64 est juste que "as" detecte tout seul mon OS...
Et le linker me donne un autre type d'erreur :
/usr/bin/ld: attention: build/assets/player-sheets/player_run_sheet.png.o: l'absence de la section .note.GNU-stack implique une pile exécutable
/usr/bin/ld: NOTE: Ce comportement est déprécié et sera supprimé dans une version ultérieure de l'éditeur de liens
Ce qui est compréhensible car la plupart des symboles sont manquants...
Et ducoup le lien se termine par une erreur comme ceci :
/usr/bin/ld : build/src/game_data.o:(.data.rel+0x8) : référence indéfinie vers « img_player_idle_sheet »
Même en ayant lancé fxconv en mode debug je ne comprend pas ce qui se passe pour que ça ne fonctionne pas, je n'ai pas vu de changement dans la lecture et la convertion en binaire de l'image, pas de paramètre à "as" qui changes...
J'espere que j'ai été assez explicite !
Citer : Posté le 12/08/2025 22:46 | #
Euuuh non mais ça va presque. L'erreur vient du fait que sur SuperH y'a un underscore au début des noms de symboles et pas sur x86. Le quick fix brutal c'est de déclarer ta variable comme _img_player_idle_sheet dans le code C ; sinon faut modifier la logique de fxconv pour pas ajouter l'underscore.
Par contre le gros, gros red flag c'est le mélange d'ABI. J'émets de trèèès gros doutes sur le fait que tu puisses mélanger des données/du code calto et PC.
Du reste, ton fichier "corrompu" il a l'air très bien. Je vois pas le souci. Le format elf64-x86-64 n'est pas "détecté", c'est juste que ton as supporte plusieurs cibles et celle-là est par défaut (tape juste objcopy et tu verras une liste de cibles pour ton binutils à la fin du message d'aide, elf64-x86-64 est probablement en premier). Si tu veux autre chose comme format faut ajouter une option à l'invocation de as dans fxconv.
Citer : Posté le 12/08/2025 23:01 | #
D'accord ! Je test ça vite fait puis dodo :OO
Par contre le gros, gros red flag c'est le mélange d'ABI. J'émets de trèèès gros doutes sur le fait que tu puisses mélanger des données/du code calto et PC.
C'est pas un probleme ici, j'ai prevu de faire un truc un peu cracra :
l'outil sert a transformer plein de fichier json et des images et tout plein d'autres chsoes en un fichier binaire que mon moteur de jeu 2d vas pouvoir lire ensuite, car comme tu me l'avait appris, la taille de l'executable ne dois pas depasser je ne sais plus trop quelle taille... (je sais qu'il existe surement d'autre moyen plus rapide et peut-être plus logique mais j'aime bien cette maniere de faire !)
Citer : Posté le 12/08/2025 23:04 | #
Si c'est un binaire pur (Python génère un bytes) y'aura pas trop de problème d'ABI alors. C'est juste si tu utilises les fonctionnalités pour générer des pointeurs, chaînes de caractères etc. alors c'est tendu (en gros si fxconv passe par as au lieu de objcopy).
Note que fxconv va générer du big-endian.
Citer : Posté le 13/08/2025 11:38 | #
Oui okkk
Note que fxconv va générer du big-endian.
D'accord ! Je note
ça marche nickel par contre ! juste le petit warning du linker que je vait enlever rapidement...
par contre j'ai été obligé de compiler le projet avec l'option --no-pie, car le linker n'était pas content des objets convertis par fxconv...
Citer : Posté le 13/08/2025 21:58 | #
Ah bonne remarque le PIE, sur SuperH c'est pas activé par défaut, mais sur ta cible x86 ça le sera... c'est compliqué et je maîtrise pas totalement donc si tu arrives à le faire marcher tant mieux.
Citer : Posté le 14/08/2025 23:20 | #
Ouai j'avais compris ça ducoup.
Mais en gros les programmes compilés avec l'option PIE sont techniquement "plus lent" car les addresse memoires sont generées aléatoirement (alors techniquement sans aussi mais me demande pas je ne m'y connais pas trop non plus...) ducoup c'est plus sécurisé...
Et sur calculatrice on s'en fiche un peu de la securité (enfin pour l'instant j'ai vu personne se connecter a internet avec
PS : sur pc le PIE est activé par default par preference a la securitée
Citer : Posté le 14/08/2025 23:24 | #
Oh wow alors oui l'ASLR c'est pour la sécurité mais c'est que la moitié de l'histoire, le PIC vient des libs dynamiques surtout. Aucune raison de faire de l'ASLR sur la calto.
Citer : Posté le 14/08/2025 23:27 | #
A ouai ! Tu me l'apprend mdr
Et oui ducoup aucune raison de le faire pour un hardware pareil
Citer : Posté le 19/08/2025 20:08 | #
Euh, pour l'instant j'essaie de comprendre pourquoi, mais la conversion a l'aire d'avoir un probleme... je détail pas plus j'esaye de trouver par moi-même pour le moment mais j'ai une color_count égale à -1 pour la conversion de mon image sur le PC comme sur la calto... mais dans le code source il n'y a rien d'écrit pour une valeur comme celle-ci...
/* Number of colors in the palette; this includes alpha for transparent
images, as alpha is always the first entry.
RGB16: 0
P8: Ranges between 1 and 256
P4: 16 */
int16_t color_count;
Edit : le probleme est juste pour la conversion pour le PC.
Citer : Posté le 19/08/2025 20:13 | #
Essaie de dump les données générées avec objdump -s sur les fichiers objets à la fois sur calto et sur PC. Tu verras vite s'il y a une différence dans le binaire ou si c'est dans la façon dont le code lit le fichier.
Attention, comme j'ai mentionné précédemment, à cause des différences d'ABI la structure sera pas lue pareil sur toutes les machines. Vérifie que offsetof(color_count, image_t) vaut bien 2 on sait jamais. Et c'est little-endian sur le PC bien sûr.
Citer : Posté le 19/08/2025 20:16 | #
Et c'est little-endian sur le PC bien sûr.
Citer : Posté le 19/08/2025 20:18 | #
D'accord ! Je note
Bas aparament non xD
Citer : Posté le 20/08/2025 11:42 | #
Bon alors la j'ai une réelle question sur le sdk, je vient de lire dans attributes.h que les define pour selectionner la zone de ram GILRAM, GXRAM et GYRAM, et il y a écrit ceci :
#define GXRAM __attribute__((section(".xyram")))
#define GYRAM __attribute__((section(".xyram")))
Est-ce normal d'avoir xyram pour xram et yram ?
Citer : Posté le 20/08/2025 12:17 | #
Oui. À l'origine ces deux zones mémoires étaient manipulées via des blocs d'adresse différents qui ne s'intersectent pas, chacun de 8 kio. Plus tard j'ai trouvé un moyen d'y accéder par un unique bloc de 16 kio, ce qui élimine le besoin de distinguer les deux. J'ai gardé deux macros pour ne pas casser le code existant.
Citer : Posté le 20/08/2025 12:19 | #
Et comment peut-on utiliser la ilram, xram et yram avec malloc ou kmalloc ?
Citer : Posté le 20/08/2025 12:25 | #
Tu peux réserver un bloc de mémoire via une variable globale et ensuite créer une arène dessus. Regarde kmalloc_{init,add}_arena() dans <gint/kmalloc.h>. Selon comment tu configures ton arène malloc() va, ou pas, aller piocher dedans. Mais en général tu voudras pouvoir contrôler exactement ce qui va dedans ou pas donc il vaut mieux l'utiliser exclusivement avec kmalloc().