Salut, le wiki étant down pour l'instant, et vu qu'il y a eu quelques demandes récentes, je fais ce post pour expliquer deux trois trucs sur le développement pour Prizm (fx-CG10/20), et sa consœur la Gnonante (G90 / fx-CG50).
Ce qui est ici, s'adressera principalement aux gens sous Windows ; les autres devraient arriver à se débrouiller de leur côté (et sinon on peut en parler et je pourrai adapter s'il le faut).

L'idée est ici d'arriver à avoir un environnement correct pour développer sur ces machines.

Le SDK de base

Le tout sera construit sur le PrizmSDK qui tourne déjà depuis un moment. Il est à récupérer ici (le format d'archive importe peu tant que vous savez l'ouvrir). Il suffit de décompresser l'archive et placer le répertoire PrizmSDK-0.3 quelque part sur le disque, de telle sorte que le chemin ne soit pas trop exotique (i.e. sans parenthèses ou espaces par exemple). Typiquement à la racine d'une partition, je suis sûr que ça fonctionne bien.

Vous obtenez donc le répertoire suivant :



Outre les divers dossiers qui correspondent à GCC qui compile pour l'architecture SuperH (bin, libexec, sh3eb-elf, share), les dossiers qui correspondent à ce qu'on pourrait véritablement appeler «le SDK» (c'est à dire plus spécifique aux machines que sont Prizm et Gnonante) sont common, include, lib et projects.

- common contient le fichier prizm.ld qui est le linker script fourni par le SDK (pas grand besoin d'y toucher normalement, même si c'est possible et on doit en parler à divers endroits sur le forum), ainsi que le fichier prizm_rules, qui correspond aux règles de compilation utilisées par le Makefile «automatique» également fourni. Normalement si vous ne savez pas vraiment ce que sont ces fichiers, pas besoin d'y toucher, et sinon, et bien les ouvrir vous apportera les infos sur ce qu'ils font !
- lib contient (à la manière de /usr/lib sur un Gnunux) les bibliothèques utilisables pour développer des addins à destination de la machine. On y retrouve entre autre les traditionnelles libc.a (bibliothèque standard C), libm.a (bibliothèque mathématique), ainsi que libfxcg.a qui contient des fonctions spécifiques à la machine.
- include contient (toujours à la manière de /usr/include) les fichiers d'en-tête associés à ces bibliothèques.
- projects est enfin le dossier dans lequel la plupart des choses se passent côté programmeur, puisque c'est là qu'il est le plus simple de manipuler… ses divers projets !

Mise à jour du SDK

Le SDK récupéré ci-haut est cependant un peu vieux (2011 tout de même !), et entre temps, les choses ont pu un peu évoluer. Notamment, il y a eu quelques réorganisations des bibliothèques. C'est ce qui explique que le wiki de Cemetech dédié à la machine (qui fait référence en terme de documentation technique, avec la doc de Simlo, un peu moins accessible sûrement), semble un peu incohérente avec ce que l'on peut trouver dans le SDK (notamment au niveau des fichiers d'en-tête).

En effet, les bibliothèques ont continuées d'être développées, incluant entre autres de nouveaux syscalls au fur et à mesure qu'on les apprivoisait. Le développement de la bibliothèque “fondamentale”, à savoir la libfxcg, avec la libc qui l'accompagne se localisant ici. Intitialement, je souhaitais détailler la démarche pour compiler ça avec le PrizmSDK de base ; en pratique il y un point un peu pénible, mais pas insurmontable (à savoir du renommage de 250+ fichiers d'un coup pour pallier le fait que Windows ne tient pas compte de la casse dans certains cas) et je ne trouvais pas ça hyper intéressant.
Du coup j'ai compilé ça de mon côté (si vous avez besoin de recompiler ça, pour une raison ou pour une autre, le plus simple est de trouver quelqu'un qui a un sh3eb-elf-gcc de dispo sous Linux, ça lui prendre 30s à faire), et mets un lien vers ce qui est nécessaire pour mettre à jour : disponible ici. (version du 2 Janvier 2018 , compilé sur le commit bec812fa56128d8856664d1a50dab017ac4c8147)

Dans cette archive, vous trouverez deux fichiers libc.a, libfxcg.a, ainsi qu'un répertoire include. Pour mettre le SDK à jour, il suffit de :
- Remplacer les fichiers libc.a et libfxcg.a du SDK (donc dans libs) par ceux de l'archive précédente.
- Remplacer le dossier include du SDK par le dossier include de l'archive.

Normalement c'est tout bon.

Quelques changements qui vont avec la mise à jour

La version plus récente de la libfxcg a l'avantage d'être un peu plus organisée que ce qui existait avant. Notamment au niveau des fichiers d'en-tête. Dorénavant, les en-têtes correspondants aux bibliothèques standards (libc, libm) sont à la racine du dossier include, et s'utilisent donc de manière classique :



Pour les fonctions propres au développement Casio, qui sont majoritairement des appels systèmes, il faudra aller consulter les en-têtes disponibles dans include/fxcg. La documentation d'un certain nombre des syscalls qu'on y retrouve est disponible sur le Wiki de Cemetech, dont les conventions vont normalement de pair avec la dernière version de ces bibliothèques : http://prizm.cemetech.net/index.php/Category:Syscalls.
Il y a des fichiers qui semblent avoir un rapport avec les Casios à la racine de include : ils sont principalement là à des fins de compatibilités, font souvent doublon avec le contenu de include/fxcg mais de manière moins organisée et plus brouillonne, des conventions un peu différentes de celles de la documentation parfois, et sont, de manière générale, à éviter, au profit des fichiers de include/fxcg.
Si vous utilisez malgré tout certains de ces fichiers alors qu'un équivalent est disponible dans include/fxcg, il est possible qu'une erreur apparaisse à la compilation, et vous indique d'utiliser plutôt un fichier de include/fxcg.

Ils sont donc à inclure de la manière suivante :


Pour le reste, parcourez les fichiers d'en-tête, le wiki de Cemetech pour plus d'infos une fonction précise, et ça devrait rouler pour l'utilisation de ces bibliothèques je pense.

Structure d'un projet, projet example

Comme je l'avais précisé, la majeure partie du temps se passe dans projects. L'organisation proposée par ce SDK est celle d'un répertoire par projet distinct.
D'origine, seul se trouve dans le dossier projects un répertoire example, qui est une sorte de projet “standard”, dont l'organisation est la suivante :



On y trouve :
- Les fichiers selected.bmp et unselected.bmp, qui correspondent à l'image associée à l'addin qui apparaîtra dans le menu principal, dans sa version sélectionnée et déselectionnée. Malheureusement, les chartes graphiques utilisées soit par la Prizm, soit la G90 diffèrent, et il sera peut être nécessaire de produire deux couples d'images pour plus de cohérence avec chacune des machines si c'est ce qui est souhaité. Sinon, on pourra trouver quelques informations sur les anciens styles utilisés sur Prizm ici.

- Les fichiers make.bat et clean.bat. Ce sont des fichiers qui permettent de simplifier l'appel de l'utilitaire make, en évitant d'avoir à lancer une invite de commande pour faire cela, ce qui sous Windows ne serait pas très pratique, à mon sens. Concrêtement, lancer make.bat lance make sur le Makefile et s'occupe normalement de compiler tout comme il faut. clean.bat appelle une règle de nettoyage (clean en l'occurence), et supprime donc les résidus de compilation.

- Le fichier Makefile, qui est un Makefile au sens classique du terme. Si ça ne vous parle pas, ce que fournit le SDK fait en sorte que l'utilisation du Makefile se résume globalement à de la description de projet. Je pense que tout redécrire ferait doublon avec ce post d'Eiyeron, qui même si un peu lacunaire sur le reste décrit assez bien ce Makefile. J'ajouterai juste que contrairement à ce qu'il dit, la ligne LIBS peut être intéressante à modifier, notamment pour y rajouter -lc et -lm (avant -lgcc de préférence) lorsque l'on souhaiter utiliser des fonctions de la bibliothèque standard C et de la bibliothèque mathématique, et donc les linker. (C'est un coup classique que d'oublier ça sinon ! ).

- Le fichier Makefile.old est un exemple de Makefile se passant de certaines commodités offertes par le SDK (notamment l'utilisation des règles disponibles dans common/prizm_rules) ; si faire un Makefile maison vous intéresse, il est sûrement moins cryptique que l'autre, et donc plus simple à prendre comme base. Je vous laisse juge.

- Enfin le dossier src qui, comme indiqué par défaut dans le Makefile, contiendra les sources de l'addin. Le projet example étant un projet de “démo” si l'on veut, il n'y a pas grand chose à y voir : simplement la fonction main qui affiche son équivalent de Hello world…

Il est à noter que après la mise à jour du SDK, le projet example risque de ne pas compiler : en effet, il utilise d'anciens fichiers d'en-tête. Le message d'erreur doit normalement indiquer de remplacer dans src/example.c les lignes

par

À partir de là, tout doit rouler.

Le projet example peut donc servir de base pour de nouveaux projets : il suffit de dupliquer le répertoire, le renommer, modifier le Makefile pour spécifier les quelques informations relatives au projet, ajouter ses sources à la place de example.c, éventuellement changer les images, et ça devrait fonctionner.

Question de la compatibilité entre Prizm (fx-CG20) et G90

Comme précisé à plusieurs moments, le SDK permet aussi bien le développement à destination des anciennes Prizms, que des nouvelles G90. Cependant certains jeux qui l'utilisaient ne sont pas compatibles d'une machine à l'autre.

En fait, un code utilisant uniquement des syscalls (i.e. en pratique, dans la plupart des cas, les fonctions disponibles dans include/fxcg, en plus des fonctions des bibliothèques standards) sera compatible sans questionnement : c'est là l'intérêt d'un syscall, le code qui dépend du materiel et de l'OS est contenu dans l'OS, et donc “automatiquement à jour” si l'on veut.

Sauf que, notamment pour des aspects graphiques, qui ont besoin de plus de performance que ce que les syscalls permettent, on a parfois besoin de faire autre chose. Cet autre chose passe, dans le cas de fonctionnalités graphiques, par de l'écriture “à la main” dans la mémoire vidéo. En théorie aucun soucis, on sait bien faire ça, sans risque, donc c'est ok. Sauf qu'il faut bien savoir où trouver cette mémoire ; on en connaissait l'adresse, et pas mal de programmeurs ont considéré que cela suffisait et écrit à cette adresse, codée en dur dans leurs addins. Malheureusement, elle a changé avec les nouveaux modèles, d'où une part des soucis de compatibilité rencontrés.
Mais heureusement, on dispose d'un syscall GetVRAMAddress déclaré dans fxcg/display.h qui permet, de manière dynamique, de récupérer cette adresse et donc éviter ces soucis.

La morale c'est donc qu'on peut faire pas mal de choses en restant compatibles, tant qu'on s'appuie sur du code qui prend en compte de potentielles différences entre les modèles là où elle peuvent survenir. (Par exemple dans le cas de la VRAM, une fois qu'on en a l'adresse dynamiquement, on peut la modifier à la main comme on souhaite, la mémoire vidéo étant organisée pareil sur les différents modèles).

Il doit exister d'autres différences subtiles, mais tant que vous ne faites pas de trop bas niveau (type overclocking, manipulation des registres internes, etc), il ne devrait pas y avoir de soucis majeurs (pour preuve, Prizoop, émulateur de Gameboy qui fonctionne sur Prizm et Gnonante a juste dû s'inquiéter de l'overclocking et de cette question de mémoire vidéo pour assurer la compatibilité, à en croire l'auteur, vu que c'est quand même un programme qui fait pas mal de choses, on peut supposer que pour des programmes pas trop démesurés, ça devrait aller.

Il doit tout de même pouvoir rester des subtilités qu'on ne comprend pas bien encore (cf Eigenmath), ça serait intéressant d'en parler si vous rencontrez un problème non documenté pendant le développement justement. Eigenmath est dur à attaquer car c'est déjà un gros programme, et l'endroit d'où peut provenir le problème n'est pas très clair…


Quelques problèmes connus avec le SDK

- Il est apparemment possible sur des versions récentes de Windows de rencontrer des erreurs de type Couldn't compute FAST_CWD pointer. lors de la compilation de projets (même très simples) via le SDK. Il semble que cette erreur puisse se résoudre en mettant à jour une DLL (cygwin1.dll), cf https://tiplanet.org/forum/viewtopic.php?f=24&t=20631&start=10#p223617 qui évoque cette solution !
- ?

Voilà, j'espère que ça répond à quelques questions que j'ai pu voir passer ; normalement ça permet de pouvoir développer sans trop de heurts. J'avais envie d'expliquer certains trucs, par forcément utile immédiatement, mais qui permettent peut être de mieux comprendre ce qu'est ce «SDK» dont on parle. J'ai peut être trop détaillé ou pas assez par moment, je ne sais pas exactement à quel public je m'adresse notamment, le tout peut être ammené à évoluer de toute manière !

Fichier joint