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 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 automatique avec plugin VS Code
- Yannis300307 a créé un plugin VS Code Casio Dev Tools qui fonctionne sous Windows (avec WSL) et Debian (probablement les dérivés aussi).
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.
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 16/07/2019 11:35 | #
bah test et si t'as toujours pas <sys/types.h>, je sais pas où est le problème
Citer : Posté le 16/07/2019 11:51 | #
Maintenant je l'ai !
Ca marche
Il y a encore un truc que j'ai pas compris, c'est si il faut installer gint ou pas:
Sur la page du fxsdk -- installer le noyau gint
Sur la page de gint -- gint est fourni avec le fxsdk
Projet de jeu multijoueur : 1V1 3D
Une lib de debug simple : la liblog
Citer : Posté le 16/07/2019 11:56 | #
Gint était fournie avec le fxSDK, mais maintenant, les deux sont indépendants
Pour Gint on fait comme ça maintenant : https://gitea.planet-casio.com/Lephenixnoir/gint#building-and-installing-gint
Citer : Posté le 16/07/2019 13:27 | #
Merci Hackcell pour avoir répondu aux questions pendant que je dormais !
Quelques précisions - la page de gint est la dernière qui n'est pas encore à jour, je m'en excuse. gint n'est plus fourni avec le fxSDK.
Pour GCC, je sais désormais comment compiler un GCC qui fasse à la fois sh3 et un sh4-nofpu qui soit véritablement sans FPU. Cela devrait résoudre un certain nombre de problèmes dans le futur. Je dois d'abord vérifier que ça ne posera pas de problèmes avec les bibliothèques, puis le tester, puis le mettre dans le tuto.
Ajouté le 05/09/2019 à 07:15 :
J'ai corrigé un bug dans l'ordre des flags du fxSDK qui permettait aux libs ajoutées dans le LDFLAGS de project.cfg de remplacer les fonctions de gint.
De plus, comme c'est la deuxième fois que je fais une mise à jour du Makefile, j'ai mis en place une nouvelle commande fxsdk update pour récupérer facilement les nouveaux Makefiles dans vos projets, si vous n'avez pas modifié l'original.
▾ Note importante : vous devrez modifier vos Makefile lorsque vous mettrez à jour le fxSDK ! ▾
Si vous n'avez pas modifié le Makefile de votre projet, placez-vous dans le dossier contenant project.cfg et tapez fxsdk update. C'est tout !
Si vous avez modifié le Makefile de votre projet, vous devez le modifier à la main pour appliquer les modifications de ce commit.
Citer : Posté le 11/09/2019 18:51 | #
J'ai une proposition d'amélioration du programme fxos du fxsdk :
Ce serait cool de pouvoir lister les syscalls d'une ROM et d'afficher la description de ces derniers comme dans la doc
Edit: En gros expliquer la sortie du programme.
Citer : Posté le 11/09/2019 20:36 | #
fxos syscall affiche bien les détails... pris dans cette doc.
Si tu parles d'autre chose, je veux bien des précisions.
Citer : Posté le 11/09/2019 22:04 | #
Alors oui mais donc qu'est-ce qui va mal avec cette commande?
0: df1e mov.l <7c>(#0xfd8001d0), r15
2: d41f mov.l <80>(#0x700000f0), r4
4: 440e ldc r4, sr
6: d11f mov.l <84>(#0xfec10000 BSC.CMNCR), r1
8: e500 mov #0, r5
a: d41f mov.l <88>(#0xa4150020 POWER.STBCR), r4
c: e710 mov #16, r7
e: d21f mov.l <8c>(#0x00010013), r2
10: 4718 shll8 r7
12: de1f mov.l <90>(#0xff000010 MMU.MMUCR), r14
14: e6ff mov #-1, r6
16: 2122 mov.l r2, @r1
18: 2452 mov.l r5, @r4
1a: e508 mov #8, r5
1c: 1474 mov.l r7, @(16, r4)
1e: e7a0 mov #-96, r7
Ajouté le 11/09/2019 à 22:04 :
A ma connaissance le syscall 0x4718 n'existe pas...
Citer : Posté le 11/09/2019 22:05 | #
Rien à vue de nez. Quelque chose te dérange ? :o
Ajouté le 11/09/2019 à 22:06 :
Ça ? Ce n'est pas un syscall, c'est une instruction assembleur. La liste est ici, page 115 : https://bible.planet-casio.com/common/hardware/mpu/sh3_manual.pdf
Citer : Posté le 11/09/2019 22:10 | #
Ok, excuse-moi j'ai mal expliqué le problème, en fait comment faut-il utiliser fxos pour obtenir les syscalls d'une image d'OS ?
Citer : Posté le 11/09/2019 22:14 | #
Juste pour éviter tout malentendu, on est d'accord que les syscalls c'est un tableau d'adresses et du code binaire. Dans l'OS il n'y a ni le nom des syscalls, ni description de leurs arguments, ni documentation.
Comme tu l'as dit la documentation est ici : https://bible.planet-casio.com/simlo/chm/v20/fx_legacy_syscalls.htm
Pour ce qui est de l'OS, fxos info donne quelques informations :
(..)
Syscall information:
Syscall table address (0x8001007c) : 0x801cdd84
Entries that point to valid memory : 0x1034
First seemingly invalid entry : 0x01010000
Syscall entries outside ROM:
%01c6 -> 0xfd800000 (RS memory)
%01c7 -> 0xfd80002a (RS memory)
%01c9 -> 0xfd800054 (RS memory)
%01ca -> 0xfd800184 (RS memory)
Et normalement la commande analyze est capable de donner le prototype (pris dans la doc, s'il existe) pour un syscall ainsi que son adresse, mais je vois que l'interface pour ça n'est pas implémentée car je n'en ai jamais eu besoin. La mention de fxos syscall tout à l'heure remonte à une ancienne version.
À vrai dire il n'y a rien d'autre à voir dans l'OS... que la liste d'adresses, comme les quatre dernières lignes à la fin de fxos info sauf qu'il y en a 4000 au lieu de 4.
Citer : Posté le 11/09/2019 22:17 | #
Ok merci !
Ajouté le 11/09/2019 à 22:19 :
En fait je cherche à récupérer le niveau de la batterie sur une sh4 mais le syscall 0x49c ne fonctionne pas...
Citer : Posté le 11/09/2019 22:45 | #
Je sais que c'est compliqué sur SH4, c'est pas la première fois que j'entends parler de ça. Malheureusement fxos ne peut pas t'expliquer pourquoi...
Ajouté le 12/09/2019 à 14:45 :
Suite aux retours sur le Makefile inflexible du fxSDK, j'ai entrepris d'en écrire une version plus souple.
Cette nouvelle version est disponible sur la branche dev du fxSDK, ce qui signifie que pour l'instant vous ne l'utilisez pas tant que vous ne choisissez pas explicitement de tester cette branche. C'est une période de test, une fois que ça marchera bien je fusionnerai dans la branche principale.
Le Makefile a beaucoup changé et le fichier project.cfg contient maintenant bien plus d'informations utiles. Je conseille d'utiliser le nouveau système surtout pour créer des nouveaux projets. Si vous voulez l'utiliser dans un projet déjà créé, alors...
• Compilez et installez la branche dev.
• Dans votre projet, tapez fxsdk update. Cela remplacera votre Makefile par le nouveau. Si vous avez modifié votre Makefile dans le passé, vous devrez refaire ces modifications, mais il y a de bonnes chances que désormais il suffise de modifier project.cfg.
• Récupérez une copie du project.cfg par défaut dans un nouveau projet et personnalisez à votre convenance pour remplacer l'ancien.
C'est un gros changement, mais je m'attends à ce que cette nouvelle version marche bien mieux que l'ancienne. Parmi les changements importants :
• On linke avec gint avant et après les libs externes, donc on peut utiliser des libs externes qui utilisent gint (eg. libprof) sans risquer que des libs que implémentent plein de fonctions ne viennent écraser celles de gint (eg. fxlib)
• On peut spécifier le compilateur de son choix pour Graph mono et pour Graph 90, ainsi que les options machine qui vont bien (-m3 etc)
• Ajout de règles pour compiler des fichiers assembleur (.s) et assembleurs avec préproco (.S)
• Ajout de règles pour intégrer sans conversion des données binaires avec fxconv -b (depuis assets-{fx,cg}/bin/)
• Bien plus d'options exposées de façon générale, le Makefile ne devrait plus avoir besoin de changer sauf conditions extraordinaires
Vous pouvez tester cette version en utilisant la branche dev dans le dépôt du fxSDK :
fxsdk% git pull
fxsdk% make install
J'envisage d'ajouter aussi un bout de Makefile pour créer des libs comme libprof. Je me souviens que Milang avait eu des problèmes avec ça.
Citer : Posté le 12/09/2019 15:24 | #
Est-ce que t'as ajouté la possibilité de configurer le chemin de build du g1a ?
Parce que personnellement je me suis construis un environnement de dev bien particulier, qui me permet de tester rapidement tester l'add-in sur l'émulteur, et pour ça j'ai modifié le Makefile pour qu'il build dans le dossier SDCard (puis j'ai une macro qui me transfère et run l'add-in depuis le SDK).
Citer : Posté le 12/09/2019 15:25 | #
Ah, je n'ai pas ajouté ça, mais c'est une bonne idée et j'ai justement en tête une façon élégante de le faire. Laisse-moi dix minutes pour écrire ça.
Ajouté le 12/09/2019 à 15:39 :
Voilà, c'est fait dans le commit 15712b4.
Tout ce que tu as à faire est de spécifier TARGET_FX dans project.cfg. Par défaut il est vide, ce qui crée un g1a du nom du projet dans le dossier racine. Si tu veux le produire dans Debug, indique par exemple :
Et voilà
Citer : Posté le 12/09/2019 15:42 | #
Cool ça
Citer : Posté le 12/09/2019 15:57 | #
A propos du makefile, lephenixnoir, j'ai remarqué que le .bin et le .elf apparaissent dans la dossier src a la compilation...
Citer : Posté le 12/09/2019 16:01 | #
Cool ça
Oui, ça redéfinit le nom du g1a. Mais en même temps cette option sert aussi à ça.
A propos du makefile, lephenixnoir, j'ai remarqué que le .bin et le .elf apparaissent dans la dossier src a la compilation...
Je vois vraiment pas comment ça peut arriver, des détails seraient bienvenus. En tous cas je peux garantir que ça ne se produira plus sur la version actuellement en dev.
Citer : Posté le 12/09/2019 16:05 | #
Ah d'accord, je croyais que c'était défini ici
Citer : Posté le 12/09/2019 16:07 | #
Non, ça c'est le nom de l'add-in tel que visible dans l'onglet VERSION de l'application SYSTEM.
(Si TARGET_FX n'est pas défini, NAME est utilisé par défaut. Mais ce n'est pas la même chose.)
Citer : Posté le 12/09/2019 16:44 | #
Lephenixnoir, voici un exemple de sortie de compilation avec le contenu de src/ avant et après:
main.c syscalls.S
$ fxsdk build-fx
:: Making into build-fx
sh4eb-nofpu-elf-gcc -c src/main.c -o build-fx/src/main.o -mb -ffreestanding -nostdlib -Wall -Wextra -fstrict-volatile-bitfields -std=c11 -Os -I/home/user/Documents/src/casio/include -L/home/user/Documents/src/casio/bin -m4-nofpu -DFX9860G -MMD -MT build-fx/src/main.o -MF build-fx/src/main.d -MP
sh4eb-nofpu-elf-gcc -o src/Piles.elf src/syscalls.S build-fx/src/main.o -mb -ffreestanding -nostdlib -Wall -Wextra -fstrict-volatile-bitfields -std=c11 -Os -I/home/user/Documents/src/casio/include -L/home/user/Documents/src/casio/bin -m4-nofpu -DFX9860G -Tfx9860g.ld -lgint-fx -lgcc -Wl,-Map=build-fx/map
sh4eb-nofpu-elf-objcopy -O binary -R .bss -R .gint_bss src/Piles.elf src/Piles.bin
fxg1a src/Piles.bin -o Piles.g1a -i "assets-fx/icon-fx.png" -n "Piles" --internal="@Piles"
$ ls src
main.c Piles.bin Piles.elf syscalls.S
Ajouté le 12/09/2019 à 16:45 :
C'est le problème dont je te parles, mais c'est pas prioritaire parce que ça vient peut-etre de mon Makefile modifié...
Citer : Posté le 12/09/2019 17:50 | #
Hmm, j'ai du mal à voir d'où pourrait venir ce problème. Peux-tu partager ton Makefile modifié pour voir si c'est en cause ?