fxSDK, un SDK alternatif pour écrire des add-ins
Posté le 29/08/2014 22:00
Le fxSDK est une alternative au
SDK habituel de Casio. Il permet de développer des add-ins pour la famille de la Graph 35+E et la Graph 90+E, et offre de meilleures performances et plus de possibilités !
Les outils du fxSDK
Le fxSDK marche sous Linux et a été compilé pour Mac OS ; il ne marche pas encore pour Windows mais on peut en discuter.
Il se fonde sur l'indispensable compilateur
gcc et sa suite d'outils :
as,
ld,
objdump,
objcopy (entre autres). Contrairement au vieux compilateur du SDK,
gcc est un compilateur moderne avec beaucoup de possibilités. Il n'est pas fourni avec le fxSDK et fait l'objet d'un
tutoriel d'installation à part.
Côté calculatrice, c'est
le noyau gint qui fait le travail. Il remplace fxlib 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 !
Le fxSDK fournit également des outils spécifiques pour compiler et étudier les programmes de la calculatrice.
fxsdk est un petit gestionnaire de projet qui vous permet de créer et compiler facilement des projets sans vous prendre la tête avec le Makefile. Parfait si vous ne voulez pas connaître toutes les détails compliqués.
fxg1a sert à créer les fichiers g1a finaux à partir du programme compilé. C'est le successeur de mon vieux g1a-wrapper qui était beaucoup moins puissant.
fxconv convertit des données pour vos add-ins, commes vos images ou polices, dans des formats spécifiques de gint. C'est un peu comme le Sprite Coder mais ça vous évite de copier des gros tableaux dans votre programme et surtout le dessin est beaucoup plus performant !
fxos est un désassembleur et manipulateur d'OS capable de retrouver et disséquer des syscalls en un tour de poignet. C'est un outil de reverse-engineering dont l'usage principal est de produire des listings assembleur annotés pour comprendre très rapidement le code.
Il y a pas mal de différences avec le SDK de Casio donc passer au fxSDK nécessite un peu d'adaptation.
Installer le fxSDK sur votre ordinateur
Ça se passe en trois étapes :
1. Compiler un compilateur
gcc à destination de la calculatrice
2. Installer le fxSDK
3. Installer le noyau, gint
Je suppose ici que vous connaissez les bases de la ligne de commande, mais si ce n'est pas le cas, n'hésitez pas à laisser un commentaire pour demander.
La première chose est de vous préparer un
cross-compilateur gcc. Vous pouvez sauter l'installation du g1a-wrapper et venir ici dès que la libgcc est installée. Assurez-vous que le compilateur est dans le PATH est vous serez prêt ! C'est le plus gros morceau donc une fois que vous aurez ça, vous aurez déjà pratiquement fini.
Clônez le dépôt git du fxSDK depuis la forge de Planète Casio (vous pouvez aussi utiliser SSH).
% git clone 'https://gitea.planet-casio.com/Lephenixnoir/fxsdk.git'
Configurez le fxSDK ; vous pouvez taper "
./configure --help" voir les options disponibles. Par défaut, le fxSDK sera installé dans votre dossier personnel (dans "
.local").
% cd fxsdk
% ./configure
Ensuite compilez et installez ! Si vous avez choisi un dossier d'installation différent avec
--prefix ou si vous compilez sous Mac, vous pourriez avoir besoin de
sudo à l'installation.
% make
% make install
Assurez-vous que votre dossier de destination est dans votre PATH, puis vous pouvez installer gint.
Vous êtes alors prêt à partir !
Développer des programmes avec le fxSDK
TODO: Ajouter l'utilisation de
fxsdk.
Toute la partie programmation revient à développer des programmes avec gint. Les
tutoriels d'utilisation de gint couvrent tous ce dont vous aurez besoin, y compris l'utilisation de
fxconv.
Fichier joint
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
So it can get pretty stressful.
That's exactly why PC is such a happy place for meow to be ⭐
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
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
So it can get pretty stressful.
That's exactly why PC is such a happy place for meow to be ⭐
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 ?