Posté le 30/05/2018 18:37
Planète Casio v4.3 © créé par Neuronix et Muelsaco 2004 - 2024 | Il y a 86 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
Citer : Posté le 30/05/2018 18:55 | #
Vaaaste sujet !
Je vais être un peu rapide mais @Nemhardy en dira sûrement plus. Commence par regarder son petit topic :
Prizm (fx-CG10/20), G90 et fx-CG50, environnement de développement
Cela te mettra sur les rails pour utiliser le PrizmSDK. Si tu es un peu touche-à-tout et Linuxien, tu n'auras peut-être pas envie d'utiliser le compilateur qu'ils fournissent ; il y a des instructions pour compiler le tien ici :
Compiler sous Linux avec un cross-compilateur gcc
Si tu vises exclusivement la Graph 90, tu peux choisir la target sh4eb-nofpu-elf qui est plus appropriée ; la sh3eb-elf est là par compatibilité avec les processeurs SH3 qui équipaient certains (maintenant vieux) modèles de calculatrices monochromes.
Ça fait extrêmement plaisir de voir des gens intéressés par la G90 (surtout Linuxiens), alors n'hésite pas à demander en cas de soucis ou à partager tes projets sur la section appropriée du forum. Good luck!
pixel Invité
Citer : Posté le 30/05/2018 19:11 | #
Merci pour la réponse rapide. Je pense ne viser que la G90 pour le moment oui. Je n'ai qu'une autre Casio trop ancienne je pense.
J'hésiterais pas à poser des questions quand j'aurais tout lu et testé, je n'aurais physiquement la machine que dans quelques jours.
Citer : Posté le 30/05/2018 20:44 | #
Salut, je pense qu’en attendant tes retours et interrogations, LePhenixNoir t’as aiguillé là où il faut !
Si tu as un peu d’expérience, tu devrais arriver à adapter ce qui est expliqué dans le premier lien donné par LePhenixNoir à un environnement Linux (c’est globalement moins douloureux que sous Windows de toute façon !), après avoir suivi le lien donné en second tutoriel… Mais encore une fois n’hésite par à dire si ça coince à un endroit…
En tout cas oui, c’est chouette de voir des gens s’y intéresser, tu vas voir : il y a de quoi faire et s’amuser…
Citer : Posté le 31/05/2018 16:56 | #
Merci pour votre accueil, en tout cas.
J'ai installé la toolchain, tout s'est bien passé. J'ai reçu la machine ce matin, pas encore déballée, je devrais pouvoir y consacrer du temps ce weekend et taper quelques lignes de code pour tester tout ça. Vous devriez avoir de mes nouvelles bientôt, soit en mode content, soit en mode pénible, on verra
Mais je suis plutôt confiant, même si mon C doit être bien rouillé.
Citer : Posté le 31/05/2018 17:32 | #
D'ici là n'hésite pas à te présenter sur le topic approprié ; si tu as le C un peu ancien alors tu vas probablement élargir le spectre des profils du forum...
Citer : Posté le 31/05/2018 23:39 | #
Salut !
J'ai regardé ça d'un peu plus près. Ça marche pas fort.
J'ai essayé de compiler le petit projet d'exemple fourni dans l'étape 7 du guide de Lephenixnoir (Duphenixnoir, du coup ?). Pour ça j'avais installé le kit sh4eb-nofpu-elf (gcc + binutils) fourni avec ma distrib (Manjaro). J'ai compilé en utilisant la commande
de la même étape 7. L'option -m3 à déçu gcc donc je l'ai juste virée. Ça à compilé avec un warning.
Un coup de objcopy plus tard (en respectant la commande du guide), je constate que je ne vise pas un .g1a, mais un .g3a.
Je farfouille dans AUR et me rabat sur mkg3a. Je créè deux jolies petites icones en 92x64 PNG8 et donne tout ça à manger à mkg3a
Failed to open input file for reading!
Operation failed. Output file is probably broken.
J'ai dû faire une bêtise quelque part du coup 8)
D'accord je vais penser à aller me présenter
Citer : Posté le 01/06/2018 05:50 | # |
Fichier joint
Salut, je pense qu'en changeant la commande que tu utilises de $ mkg3a -n:test -i uns:unselect.png sel:select.png addin.bin à $ mkg3a -n:test -i uns:unselect.png -i sel:select.png addin.bin ça devrait aller un peu mieux… Pour l'instant mkg3a essaie d'utiliser sel:select.png comme fichier binaire d'entrée…
De plus il faut voir que le processus pour compiler sur prizm et sur monochrome n'est pas exactement le même, en amont de l'utilisation de mkg3a : tu ne peux pas juste prendre le binaire issu du tutoriel de LePhenixNoir et en faire un .g3a. En gros une fois que tu as un compilateur qui fonctionne, ainsi qu'un wrapper qui fonctionne (mkg3a donc…), l'idée c'est d'adapter ce que tu peux lire sur cette page pour te faire un genre de SDK qui tournera chez toi. Pour info, chez moi mon dossier "sdk" ressemble à ça :
├── include
│ ├── APP_syscalls.h
│ ├── CONVERT_syscalls.h
│ ├── LineEditors.hpp
│ ├── ListView.hpp
│ ├── MCS_syscalls.h
│ ├── RTC_syscalls.h
│ ├── STATUS_ICONS.hpp
│ ├── SYSTEM_syscalls.h
│ ├── StrList.hpp
│ ├── UI.hpp
│ ├── alloca.h
│ ├── app.h
│ ├── asm.h
│ ├── assert.h
│ ├── color.h
│ ├── ctype.h
│ ├── disp_tools.hpp
│ ├── display.h
│ ├── display_syscalls.h
│ ├── errno.h
│ ├── fxcg
│ │ ├── app.h
│ │ ├── display.h
│ │ ├── file.h
│ │ ├── heap.h
│ │ ├── keyboard.h
│ │ ├── misc.h
│ │ ├── registers.h
│ │ ├── rtc.h
│ │ ├── serial.h
│ │ └── system.h
│ ├── fxcg.h
│ ├── fxcg_display.h
│ ├── fxcg_keyboard.h
│ ├── fxcg_registers.h
│ ├── fxcg_stdlib_syscalls.h
│ ├── keyboard.h
│ ├── keyboard.hpp
│ ├── keyboard_syscalls.h
│ ├── locale.h
│ ├── math.h
│ ├── mcs.hpp
│ ├── rtc.h
│ ├── setjmp.h
│ ├── sprite.h
│ ├── stddef.h
│ ├── stdio.h
│ ├── stdlib.h
│ ├── string.h
│ ├── sys
│ │ └── types.h
│ ├── system.h
│ ├── time.h
│ └── unistd.h
├── lib
│ ├── libc.a
│ └── libfxcg.a
├── out
├── projects
│ └── pong
│ ├── Makefile
│ ├── pong.bin
│ ├── pong.g3a
│ ├── selected.png
│ ├── src
│ │ └── main.c
│ └── unselected.png
│ └── …
└── toolchain
├── Prizm.cmake
├── prizm.x
└── prizm_rules
Je te mets pong en pièce jointe, je m'en sers de projet rapide de "test" pour vérifier que tout marche bien, si un make fonctionne avec, tu dois être bon. De plus tu pourras jeter un œil au makefile pour voir un peu comment ça se passe (tu verras que ça reste assez proche de ce qui se fait pour les monochromes tout de même…).
Citer : Posté le 01/06/2018 08:46 | #
L'option -m3 veut dire "processeur SH3", le vieux processeur qui est la raison pour laquelle on utilise le sh3eb-elf. La G90 a toujours un SH4, c'est pour ça que tu as un sh4eb-nofpu-elf, mais du coup l'option associée pour toi c'est plutôt -m4 (ou aucune, tout simplement) !
Du reste, bien que Nemhardy ait raison pour les projets plus développés, je pense que tu as quasiment tout eu juste. Bien joué !
Le problème c'est que tu ne peux pas utiliser libfx.a de mon tutoriel de compilation de GCC car c'est un port de fxlib... pour calculatrices monochromes ! Cherche du côté de Nemhardy, la lib que tu dois utiliser à la place est libfxcg. Avec ça tu devrais pouvoir rouler !
Citer : Posté le 01/06/2018 13:13 | #
Salut, je pense qu'en changeant la commande que tu utilises de $ mkg3a -n:test -i uns:unselect.png sel:select.png addin.bin à $ mkg3a -n:test -i uns:unselect.png -i sel:select.png addin.bin ça devrait aller un peu mieux… Pour l'instant mkg3a essaie d'utiliser sel:select.png comme fichier binaire d'entrée…
Tout à fait, j'ai oublié un -i
... le reste de ta réponse ...
Ah d'accord. En lisant la 1ère réponse de Lephenixnoir, j'avais bêtement compris que c'était ou l'un, ou l'autre. J'ai pas tilté vu que la compil à réussi. Bref, ça devrait aller mieux avec ces explications complémentaires, merci.
L'option -m3 veut dire "processeur SH3", le vieux processeur qui est la raison pour laquelle on utilise le sh3eb-elf. La G90 a toujours un SH4, c'est pour ça que tu as un sh4eb-nofpu-elf, mais du coup l'option associée pour toi c'est plutôt -m4 (ou aucune, tout simplement) !
Ah, je croyais qu'elle servait à selectionner une variante du SH3, donc j'ai cherché à la remplacer, sans succès. Tant mieux si ça roule comme ça .
Bon merci encore, je désespère pas d'arriver à compiler un truc d'ici ce weekend
Mise à jour :
Ça marche presque, ou presque pas suivant le niveau d'optimisme.
Voilà ce que j'ai fais pour installer le SDK (les tests de compilations se font sur le projet "pong" de Nemhardy):
J'ai téléchargé le PrismSDK-0.3 chez Cemetech que j'ai décompressé disons dans ~/PrizmSDK-0.3
J'ai téléchargé le fichier mise_a_jour_libfxcg-15023.zip fourni dans le guide de Nemhardy, j'ai copié le repertoire include qu'il contient dans ~/PrismSDK-0.3, remplaçant les fichiers communs, ainsi que les fichiers libc.a et libfxcg.a dans ~/PrizmSDK-0.3/lib.
A ce point, le compilo se plaint de ne pas trouver ../../toolchain/prizm.x. je clone donc à part le dépot https://github.com/Jonimoose/libfxcg.git, et copie le repertoire toolchain qu'il contient dans ~/PrizmSDK-0.3.
Youpi, ça compile. Mais au lancement, une fenêtre "System ERROR" et la machine reboot en repassant par toute la phase de première configuration.
Je soupçonne d'avoir raté une étape propre à la 90 (?).
Citer : Posté le 01/06/2018 20:24 | #
Sache que si tu as une System ERROR, tu peux appuyer sur MENU pour revenir au menu et lancer une autre application, ce qui évite le reboot, lent sur G90.
On peut savoir ce que affiche la System ERROR ? Nemh, tu te souviens comment marche le système d'init de la Prizm ? Le crt0.s de mon tuto est bon pour le linker script naïf de la monochrome, peut-être pas pour la Prizm.
Citer : Posté le 01/06/2018 22:22 | #
tu peux appuyer sur MENU pour revenir au menu
Cool ça marche, merci du tuyau. Ça risque pas de laisser le système dans un état instable plantogène ?
On peut savoir ce que affiche la System ERROR ?
Toutafé. Ça dit
TARGET=00000000
PC =00000000
Citer : Posté le 01/06/2018 22:36 | #
Ah, visiblement ton compilo a généré une instruction assembleur que la calculatrice ne connaît. Habituellement c'est du FPU. Essaie la commande suivante pour en avoir le coeur net :
Citer : Posté le 01/06/2018 23:01 | # |
Fichier joint
Ça ne renvoie rien.
Edit: J'ai mis en pièce jointe le fichier objet généré par gcc, si tu veux y jeter un oeil.
Citer : Posté le 02/06/2018 10:04 | #
Le compilateur a généré des instructions FPU. As-tu essayé le switch -m4 ? Je sais que j'ai déjà eu ce problème quand j'ai compilé le sh4eb-elf-gcc au lieu du sh4eb-nofpu-elf-gcc, et je ne suis pas totalement au point.
Par exemple si je fais sh4eb-nofpu-elf-gcc -m4-nofpu, il me dit qu'il ne supporte pas -m4-nofpu, ce qui est quand même inattendu - j'ai peut-être oublié un switch à la compilation de gcc. En tous cas j'arrive à compiler de façon à ne pas générer de code FPU, tu devrais pouvoir aussi.
Using built-in specs.
COLLECT_GCC=sh4eb-nofpu-elf-gcc
COLLECT_LTO_WRAPPER=/home/rook/opt/sh4eb-elf-2.30-8.1.0/libexec/gcc/sh4eb-nofpu-elf/8.1.0/lto-wrapper
Target: sh4eb-nofpu-elf
Configured with: ../gcc-8.1.0/configure --prefix=/home/rook/opt/sh4eb-elf-2.30-8.1.0 --target=sh4eb-nofpu-elf --disable-nls --disable-werror --enable-libssp --enable-lto --enable-languages=c,c++ --without-headers --with-mpfr=/usr
Thread model: single
gcc version 8.1.0 (GCC)
Citer : Posté le 02/06/2018 12:12 | #
Ahah, la bonne blague.
-m4-nofpu ne fonctionne pas ici non plus.
après compilation avec le flag -m4 j'ai toujours des fpscr dans mon objet
252: 02 6a sts fpscr,r2
25e: 42 6a lds r2,fpscr
294: 01 6a sts fpscr,r1
29c: 41 6a lds r1,fpscr
2de: 01 6a sts fpscr,r1
etc... y'en a une tartine.
et même erreur sur la machine.
pour la version j'ai ça :
Using built-in specs.
COLLECT_GCC=sh4eb-nofpu-elf-gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/sh4eb-nofpu-elf/8.1.0/lto-wrapper
Target: sh4eb-nofpu-elf
Configured with: ../configure --prefix=/usr --program-prefix=sh4eb-nofpu-elf- --target=sh4eb-nofpu-elf --host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --disable-shared --disable-nls --disable-tls --disable-threads --enable-languages=c,c++ --enable-multilib --with-system-zlib --with-local-prefix=/usr/sh4eb-nofpu-elf --with-as=/usr/bin/sh4eb-nofpu-elf-as --with-ld=/usr/bin/sh4eb-nofpu-elf-ld --disable-libgomp --enable-interwork --enable-addons --enable-sjlj-exceptions --disable-hosted-libstdcxx --with-gnu-as --with-gnu-ld --disable-libssp --disable-__cxa_atexit
Thread model: single
gcc version 8.1.0 (GCC)
si tu vois un flag qui devrait pas être là je devrais pouvoir recompiler le paquet en l'enlevant. Je regarderais ça mieux ce soir au pire. C'est déjà une belle avancée pour moi de savoir d'où viens le problème
Merci vraiment pour votre aide, j'ai vraiment l'impression d'être un boulet
Edit : J'ai laissé un commentaire sur AUR pour le mainteneur du paquet, Il pourra peut-être m'en dire plus.
Edit-bis : Pour info, j'ai viré les paquets Manjaro et me suis compilé les outils en userland en suivant le guide (gcc 8.1.0 et binutils 2.30). Même problème
Ajouté le 02/06/2018 à 15:20 :
Ça y est ! Ça marche.
Il manquait un
Maintenant le flag -m4-nofpu fonctionne, et le programme se lance.
Bon ceci dit, ça ressemble pas vraiment à un jeu de pong fonctionnel, je sais pas si quelque chose d'autre a foiré ou si c'est normal.
Edit-ter : La compilation de Gravity Duck produit un executable qui fonctionne comme le binaire fourni, donc je pense que c'est bon.
Merci encore à tous !
Citer : Posté le 02/06/2018 15:22 | #
Ooh, bien vu. J'avais oublié que multilib servait à ça. J'ai plus qu'à recompiler le mien du coup
Bienvenue dans le développement stylay sur Graph 90
Si tu veux on peut t'en montrer des vrais boulets, on en croise assez souvent, mais ils sont pas comme toi.
Citer : Posté le 02/06/2018 15:28 | #
Cool, bien joué, welcome on board !
Pour le côté non fonctionnel, il y a des chances qu'il soit dans un état un peu expérimental effectivement (typiquement le temps arrêté tant que tu ne touches à rien ou des trucs du style, je ne sais plus vraiment… x)), c'est juste que j'avais ça comme "projet" pas trop gros et qui compilait normalement avec la libfxcg installée, donc ça permettait de tester si tout marchait de ton côté, après, c'est pas censé être un jeu jouable en l'état…
Citer : Posté le 07/06/2018 13:57 | #
Salut !
Je progresse dans la découverte de la machine, c'est plutôt cool. Je profite que le site soit tombé en marche pour poser une question d:
Quand mon programme termine, impossible de le relancer derrière, je dois pas quitter proprement j'imagine ? Il y a une instruction magique à placer avant la sortie ?
Citer : Posté le 07/06/2018 14:52 | #
Si tu utilises GetKey() et que ton utilisateur quitte le programme en appuyant sur MENU pendant un appel à GetKey(), alors il pourra revenir. Dans l'idéal tu ne dois jamais sortir de la fonction main().
Citer : Posté le 07/06/2018 15:34 | #
D'ailleurs question complexe: comment fonctionne GetKey() ? (juste le fonctionnement de la touche MENU)