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
Citer : Posté le 02/01/2018 22:39 | #
Super, merci pour ce post très complet.
Citer : Posté le 03/01/2018 11:27 | #
Merci beaucoup pour cette explication complète
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
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 :
Est-ce un problème connu et réparable ?
Et le lien du forum pour régler le
Bonne soirée et merci beaucoup pour ce guide !
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.
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 :
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
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 :
Citer : Posté le 25/09/2018 07:10 | #
Mhhh j'ai également libc.a puisque mis à jour avec le paquet de Nemhardy.
Avec un
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
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.
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 !
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.
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...
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.
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
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.
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
Citer : Posté le 25/11/2018 11:05 | #
Non, tu l'installe sur ton ordi
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.
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
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?