Seuls les membres ayant 30 points peuvent parler sur le chat.

Forum Casio - Vos tutoriels et astuces


Index du Forum » Vos tutoriels et astuces » Prizm (fx-CG10/20), G90 et fx-CG50, environnement de dévelop
NemhardyHors ligneGrand maître des Traits d'EspritPoints: 1235 Défis: 54 Message

Prizm (fx-CG10/20), G90 et fx-CG50, environnement de dévelop

Posté le 02/01/2018 22:21

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 :


PrizmSDK-0.3
├── README.txt
├── bin
├── common
├── include
├── lib
├── libexec
├── projects
├── sh3eb-elf
└── share


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 :

#include <stdio.h>
#include <string.h>
#include <math.h>


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 :

#include <fxcg/keyboard.h>
#include <fxcg/display.h>



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 :


projects/example
├── Makefile
├── Makefile.old
├── clean.bat
├── make.bat
├── selected.bmp
├── src
│   └── example.c
└── unselected.bmp


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

#include <display_syscalls.h>
#include <keyboard_syscalls.h>

par

#include <fxcg/display.h>
#include <fxcg/keyboard.h>

À 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


Pages : 1, 2Suivante
CritorEn ligneAdministrateurPoints: 1495 Défis: 18 Message

Citer : Posté le 02/01/2018 22:39 | #


Super, merci pour ce post très complet.
Suruq gameHors ligneMembre de CreativeCalcPoints: 619 Défis: 20 Message

Citer : Posté le 03/01/2018 11:27 | #


Merci beaucoup pour cette explication complète
There is only one thing that makes a dream impossible to achieve : the fear of failure
LephenixnoirHors ligneAdministrateurPoints: 16477 Défis: 140 Message

Citer : Posté le 05/01/2018 09:48 | #


Joli boulot. J'ai configuré tout ça, fait quelques tests de compil', et ça marche pas mal ; sauf mkg3a dont les fonctions de lecture de bitmaps sont pas encore au point semble-t-il. Rien de catastrophique !

Je commence à avoir une petite idée de ce qu'on sait faire sur cette plateforme, c'est pas mal
Sheep_kHors ligneMembrePoints: 4 Défis: 0 Message

Citer : Posté le 03/09/2018 19:59 | #


Bonjour
Après la mise à jour du SDK avec les paquets fournis en V0.4, il semble que les fonctions des bibliothèques stdio.h et stdlib.h (comme le malloc) soient inaccessibles :
example.c:(.text.startup+0xf0): undefined reference to `_malloc'

Est-ce un problème connu et réparable ?
Et le lien du forum pour régler le
WARNING: Couldn't compute FAST_CWD pointer.
a l'air de ne plus offrir la version nécessaire du cygwin.dll, y-a-t-il une alternative ?
Bonne soirée et merci beaucoup pour ce guide !
LephenixnoirHors ligneAdministrateurPoints: 16477 Défis: 140 Message

Citer : Posté le 03/09/2018 20:21 | #


Typiquement malloc() est défini dans libc.a. Est-ce que tu peux nous partager les commandes de compilation que tu as utilisées et l'arborescence des répertoires pour s'assurer que tu as bien linké avec cette bibliothèque ? N'hésite pas à modifier le Makefile, il n'y a rien de "crucial" dedans.
Sheep_kHors ligneMembrePoints: 4 Défis: 0 Message

Citer : Posté le 24/09/2018 20:25 | #


Désolé du temps de réponse, un autre projet m'avait sorti mon Addin de la tête
Effectivement le Makefile me semble être le problème, j'utilise celui du PrizmSDK 0.3 et j'utilise le make.bat pour compiler (Si ça marchait par défaut, pour quoi le réparer...). Enfin bref, mon Makefile est ici :

#---------------------------------------------------------------------------------
# Clear the implicit built in rules
#---------------------------------------------------------------------------------
.SUFFIXES:
#---------------------------------------------------------------------------------
# Set toolchain location in an environment var for future use, this will change
# to use a system environment var in the future.
#---------------------------------------------------------------------------------
ifeq ($(strip $(FXCGSDK)),)
export FXCGSDK := $(abspath ../../)
endif

include $(FXCGSDK)/common/prizm_rules


#---------------------------------------------------------------------------------
# TARGET is the name of the output
# BUILD is the directory where object files & intermediate files will be placed
# SOURCES is a list of directories containing source code
# INCLUDES is a list of directories containing extra header files
#---------------------------------------------------------------------------------
TARGET        :=    $(notdir $(CURDIR))
BUILD        :=    build
SOURCES        :=    src
DATA        :=    data  
INCLUDES    :=

#---------------------------------------------------------------------------------
# options for code and add-in generation
#---------------------------------------------------------------------------------

MKG3AFLAGS := -n basic:serial -i uns:../unselected.bmp -i sel:../selected.bmp

CFLAGS    = -Os -Wall $(MACHDEP) $(INCLUDE)
CXXFLAGS    =    $(CFLAGS)

LDFLAGS    = $(MACHDEP) -T$(FXCGSDK)/common/prizm.ld -Wl,-static -Wl,-gc-sections

#---------------------------------------------------------------------------------
# any extra libraries we wish to link with the project
#---------------------------------------------------------------------------------
LIBS    :=    -lfxcg -lgcc

#---------------------------------------------------------------------------------
# list of directories containing libraries, this must be the top level containing
# include and lib
#---------------------------------------------------------------------------------
LIBDIRS    :=

#---------------------------------------------------------------------------------
# no real need to edit anything past this point unless you need to add additional
# rules for different file extensions
#---------------------------------------------------------------------------------
ifneq ($(BUILD),$(notdir $(CURDIR)))
#---------------------------------------------------------------------------------

export OUTPUT    :=    $(CURDIR)/$(TARGET)

export VPATH    :=    $(foreach dir,$(SOURCES),$(CURDIR)/$(dir)) \
                    $(foreach dir,$(DATA),$(CURDIR)/$(dir))

export DEPSDIR    :=    $(CURDIR)/$(BUILD)

#---------------------------------------------------------------------------------
# automatically build a list of object files for our project
#---------------------------------------------------------------------------------
CFILES        :=    $(foreach dir,$(SOURCES),$(notdir $(wildcard $(dir)/*.c)))
CPPFILES    :=    $(foreach dir,$(SOURCES),$(notdir $(wildcard $(dir)/*.cpp)))
sFILES        :=    $(foreach dir,$(SOURCES),$(notdir $(wildcard $(dir)/*.s)))
SFILES        :=    $(foreach dir,$(SOURCES),$(notdir $(wildcard $(dir)/*.S)))
BINFILES    :=    $(foreach dir,$(DATA),$(notdir $(wildcard $(dir)/*.*)))

#---------------------------------------------------------------------------------
# use CXX for linking C++ projects, CC for standard C
#---------------------------------------------------------------------------------
ifeq ($(strip $(CPPFILES)),)
    export LD    :=    $(CC)
else
    export LD    :=    $(CXX)
endif

export OFILES    :=    $(addsuffix .o,$(BINFILES)) \
                    $(CPPFILES:.cpp=.o) $(CFILES:.c=.o) \
                    $(sFILES:.s=.o) $(SFILES:.S=.o)

#---------------------------------------------------------------------------------
# build a list of include paths
#---------------------------------------------------------------------------------
export INCLUDE    :=    $(foreach dir,$(INCLUDES), -iquote $(CURDIR)/$(dir)) \
                    $(foreach dir,$(LIBDIRS),-I$(dir)/include) \
                    -I$(CURDIR)/$(BUILD) -I$(LIBFXCG_INC)

#---------------------------------------------------------------------------------
# build a list of library paths
#---------------------------------------------------------------------------------
export LIBPATHS    :=    $(foreach dir,$(LIBDIRS),-L$(dir)/lib) \
                    -L$(LIBFXCG_LIB)

export OUTPUT    :=    $(CURDIR)/$(TARGET)
.PHONY: $(BUILD) clean

#---------------------------------------------------------------------------------
$(BUILD):
    @[ -d $@ ] || mkdir $@
    @make --no-print-directory -C $(BUILD) -f $(CURDIR)/Makefile

#---------------------------------------------------------------------------------
export CYGWIN := nodosfilewarning
clean:
    $(RM) -fr $(BUILD) $(OUTPUT).bin $(OUTPUT).g3a

#---------------------------------------------------------------------------------
else

DEPENDS    :=    $(OFILES:.o=.d)

#---------------------------------------------------------------------------------
# main targets
#---------------------------------------------------------------------------------
$(OUTPUT).g3a: $(OUTPUT).bin
$(OUTPUT).bin: $(OFILES)


-include $(DEPENDS)

#---------------------------------------------------------------------------------
endif
#---------------------------------------------------------------------------------


Me donnant toujours le message :

sh3eb-elf-gcc  example.o -mb -m4a-nofpu -mhitachi -nostdlib -TF:/PrizmSDK-0.4/common/prizm.ld -Wl,-static -Wl,-gc-sections  -LF:/PrizmSDK-0.4/lib -lfxcg -lgcc -o F:/PrizmSDK-0.4/projects/serial/serial.bin
example.o: In function `_main':
example.c:(.text.startup+0x260): undefined reference to `_memset'
collect2: ld returned 1 exit status
make[1]: *** [F:/PrizmSDK-0.4/projects/serial/serial.bin] Error 1

LephenixnoirHors ligneAdministrateurPoints: 16477 Défis: 140 Message

Citer : Posté le 24/09/2018 21:22 | #


Dans mon environnement (qui est intouché depuis installation), j'ai libc.a juste à côté de libfxcg.a. Tu peux confirmer que toi aussi ?

Si oui, alors tu n'as qu'à modifier la ligne qui mentionne LIBS de cette façon :

LIBS := -lc -lfxcg -lgcc
Sheep_kHors ligneMembrePoints: 4 Défis: 0 Message

Citer : Posté le 25/09/2018 07:10 | #


Mhhh j'ai également libc.a puisque mis à jour avec le paquet de Nemhardy.
Avec un
-lc
dans le Makefile me résultat est... mitigé.
sh3eb-elf-gcc  example.o -mb -m4a-nofpu -mhitachi -nostdlib -TF:/PrizmSDK-0.4/common/prizm.ld -Wl,-static -Wl,-gc-sections  -LF:/PrizmSDK-0.4/lib -lfxcg -lgcc -lc -o F:/PrizmSDK-0.4/projects/serial/serial.bin
F:/PrizmSDK-0.4/lib\libc.a(stdlib.o): In function `_strtod':
/home/nemo/dev/prizmaj/libfxcg/libc/stdlib.c:144: undefined reference to `___muldf3'
/home/nemo/dev/prizmaj/libfxcg/libc/stdlib.c:144: undefined reference to `___floatsisf'
/home/nemo/dev/prizmaj/libfxcg/libc/stdlib.c:144: undefined reference to `___floatsidf'
/home/nemo/dev/prizmaj/libfxcg/libc/stdlib.c:144: undefined reference to `___adddf3'
/home/nemo/dev/prizmaj/libfxcg/libc/stdlib.c:144: undefined reference to `___divsf3'
/home/nemo/dev/prizmaj/libfxcg/libc/stdlib.c:144: undefined reference to `___extendsfdf2'
/home/nemo/dev/prizmaj/libfxcg/libc/stdlib.c:144: undefined reference to `___mulsf3'
F:/PrizmSDK-0.4/lib\libc.a(printf.o): In function `__v_printf':
/home/nemo/dev/prizmaj/libfxcg/libc/printf.c:238: undefined reference to `___movmemSI12_i4'
F:/PrizmSDK-0.4/lib\libc.a(printf.o): In function `__printf_do_udecimal.isra.0':
/home/nemo/dev/prizmaj/libfxcg/libc/printf.c:34: undefined reference to `_(short, double, int, void, short, int, _i4, int)'
collect2: ld returned 1 exit status
LephenixnoirHors ligneAdministrateurPoints: 16477 Défis: 140 Message

Citer : Posté le 25/09/2018 07:21 | #


Attention, l'ordre des options de linker compte. Le linker lit les fichiers objets et les archives de gauche à droite, comme il y a une dépendance de libc sur libgcc, il est important que -lgcc soit après -lc. En l'ocurrence -lgcc doit toujours être à la fin.

J'ai plus ou moins deviné que -lc serait mieux avant -lfxcg par heuristique, parce que je n'avais pas d'exemple sous les yeux, si tu vois que dans une fonction de libfxcg.a il y a un symbole de la lib standard irrésolu, intervertis les deux.
Sheep_kHors ligneMembrePoints: 4 Défis: 0 Message

Citer : Posté le 25/09/2018 15:38 | #


Oh c'était si simple, une erreur de débutant...
Merci beaucoup pour ton aide, je vais enfin pouvoir continuer à bidouiller !
LephenixnoirHors ligneAdministrateurPoints: 16477 Défis: 140 Message

Citer : Posté le 25/09/2018 19:13 | #


Au plaisir ! N'hésite pas à nous partager tes créations, on n'en a pas encore beaucoup.
OzihsubHors ligneMembrePoints: 5 Défis: 0 Message

Citer : Posté le 29/10/2018 18:58 | #


Super, tout fonctionne! (en tous cas pour l'instant ) Existe-t-il une documentation avec le SDK? j'ai cherché sur les wikis d'ici et de cemetech mais j'ai pas trouvé grand chose...
LephenixnoirHors ligneAdministrateurPoints: 16477 Défis: 140 Message

Citer : Posté le 29/10/2018 23:01 | #


La référence c'est le WikiPrizm de Cemetech, sinon tu as la doc bas-niveau des syscalls de Simon Lothar. Il s'agit d'un fichier chm (les vieux fichiers d'aide de Windows) disponible sur Casiopeia, on a aussi un miroir web sur Planète Casio.

Le lien précédent c'est la liste des fichiers, si tu vas sur start.htm tout en bas tu auras la version "bien présentée". Je trouve plus facile de naviguer avec la liste, c'est personnel.

Enfin, tu peux regarder les en-têtes de la libfxcg, même s'ils ne sont pas très documentés.

Si tu veux quelque chose de plus spécifique, on pourra peut-être t'aiguiller plus précisément.
OzihsubHors ligneMembrePoints: 5 Défis: 0 Message

Citer : Posté le 30/10/2018 14:43 | #


Merci beaucoup ! Pour l'instant j'ai fait que du basic sur ma CG50, et je voulais m'initier au développement d'addins. Pour commencer et comprendre comment ça marche je vais faire des programmes de base puis pourquoi pas des choses un peu plus graphiques .C'était surtout pour cet aspect-là que je me pose des questions car les tutos du WikiPrizm n'ont pas l'air très remplis... Enfin bon tout ça c'est pas pour tout de suite
LephenixnoirHors ligneAdministrateurPoints: 16477 Défis: 140 Message

Citer : Posté le 30/10/2018 14:48 | #


Il n'y a pas trop de concurrence sur la Graph 90 pour l'instant, alors n'hésite pas à partager ce que tu fais (même modeste !), tu n'auras pas de mal à te faire une place.
Maxipoint14Hors ligneMembrePoints: 244 Défis: 0 Message

Citer : Posté le 25/11/2018 10:50 | #


Est ce que le sdk on le mets sur la g90? Si oui ou svp répondez vite j'en ai besoin
Mon moral de programmation:
   80%

avancée de la maj 1.15 de fortcalc
   5%
HackcellHors ligneMembrePoints: 1155 Défis: 10 Message

Citer : Posté le 25/11/2018 11:05 | #


Non, tu l'installe sur ton ordi
I usually spend meow time cosplaying as a diligent student...
So it can get pretty stressful.
That's exactly why PC is such a happy place for meow to be ⭐
Maxipoint14Hors ligneMembrePoints: 244 Défis: 0 Message

Citer : Posté le 25/11/2018 11:06 | #


Oki mrc

Ajouté le 28/11/2018 à 11:26 :
Je n'ai meme pas le lecteur de fichiers C help plz.
Mon envie de programmer sur c
   50%

Mon moral de programmation:
   80%

avancée de la maj 1.15 de fortcalc
   5%
Dark stormEn ligneMembre d'honneurPoints: 10870 Défis: 176 Message

Citer : Posté le 28/11/2018 11:35 | #


Liste d'éditeurs de texte.
N'importe lequel fer l'affaire pour écrire du C dans de bonnes conditions
Finir est souvent bien plus difficile que commencer. — Jack Beauregard
Maxipoint14Hors ligneMembrePoints: 244 Défis: 0 Message

Citer : Posté le 28/11/2018 11:35 | #


Oki merci dark storm

Ajouté le 28/11/2018 à 11:39 :
Kequel est le plus adapté pour w10?
Mon moral de programmation:
   80%

avancée de la maj 1.15 de fortcalc
   5%
Pages : 1, 2Suivante

Planète Casio v42 © créé par Neuronix et Muelsaco 2004 - 2019 | Il y a 58 connectés | Nous contacter | Qui sommes-nous ? | Licences et remerciements

Planète Casio est un site communautaire non affilié à Casio. Toute reproduction de Planète Casio, même partielle, est interdite.
Les programmes et autres publications présentes sur Planète Casio restent la propriété de leurs auteurs et peuvent être soumis à des licences ou copyrights.
CASIO est une marque déposée par CASIO Computer Co., Ltd