Forum TI-Planet.org

Pour le linker script : https://github.com/Jonimoose/libfxcg/bl ... in/prizm.x

Quand je parlais du peu de contrôle offert par le SDK de Casio, c'en est un exemple, c'est un combo SDK / IDE en fait (même s'il est assez peu envisageable d'éditer du code en son sein…) ; ce qui pourrait se rapprocher le plus d'un Makefile serait alors ce fichier, je suppose : https://git.planet-casio.com/Nemh/Eigen ... /Eigen.g1w, c'est une sorte de fichier "projet" qu'il suffirait d'importer pour que le SDK sache de quoi on lui parle.

À cause des limitations de ce SDK j'avais justement commencé à travailler au passage du tout sous gcc, c'est le rôle de cette branche : https://git.planet-casio.com/Nemh/Eigen ... liberation, qui a une structure sans doute plus classique. Ça compile mais tourne approximativement : il reste quelques soucis : la transformation de la bibliothèque fournie par le SDK de Casio vers une bibliothèque utilisable avec gcc ne semble pas totalement parfaite, et les fonctions mathématiques notamment posent problème (je ne sais plus exactement quelles avaient été mes conclusions, peut être un problème de convention d'appel, ou de format des flottants, ou autre… :s).

En tout les cas, le code qui est là est destinée aux Graph *5 monochromes, et celui de gbl08ma aux fx-CG10/20 (et donc normalement G90 également), d'où les différences assez flagrantes entre les deux projets. Je n'utilisais pas d'allocateur séparé, mais Eigenmath a tendance à manquer plus rapidement de mémoire sur Graph*5 que sur fx-CG20.
La taille de l'objet memmgr.o vient sans doute de
static byte pool[POOL_SIZE] = {0};, où POOL_SIZE est défini à 128 * 1024 dans le code de gbl08ma (ici et là) ; il doit être envisageable de diminuer cette valeur dans un premier temps.

Merci! J'ai modifie la quantite de ram a 256K. Il me reste a tester si ca marche sur l'emulateur, mais je ne sais pas comment y transferer le fichier .g3a.

Pour l'import, il me semble de mémoire (je n'ai pas la possibilité d'avoir l'émulateur sous les yeux à l'instant, désolé si ce n'est pas ça du coup… ^^') qu'aller dans le programme «Memory» puis l'onglet «PC» puis «Import» convient pour importer des addins au format .g3a.

Oui, merci!
Et ma compilation donne un programme qui tourne, sauf que l'affichage du resultat de factor(x^4-1) affiche mal les entiers et puissances, peut-etre un probleme connu ou un probleme dans les modifs que j'ai faites dans les divers composants de ma toolchain. Ceci dit c'est tres encourageant.

Sur émulateur Graph 90+E, factor(x^4-1) me donne ça avec la version téléchargeable chez nous :


Sur la vraie Graph 90+E, les grandes parenthèses ne sont pas affichées.
Cela fait partie des défauts déjà évoqués pour l'interface.
Certaines des fonctions graphiques utilisées se donnent la peine de récupérer l'adresse VRAM qui a changé sur calculatrices Graph 90+E (mais pas dans l'émulateur), et d'autres incluent l'ancienne adresse VRAM en dur et donc n'affichent rien.

J'ai surement un probleme avec sprintf dans ma libc, car les nombres ne sont pas affiches du tout chez moi.

Si besoin, il ne faut pas hésiter à partager le fichier et on testera.

J'ai reussi a corriger, non pas sprintf, mais en modifiant dans le fichier source mstr.cpp. L'adaptation de l'UI ne devrait pas poser de problemes, en tout cas pour une sortie 1-d.
Je vais me remettre a corriger dans le source de giac pour essayer de le compiler, en esperant qu'on peut faire un addin de plusieurs Mo (ca va etre tres long a charger!).

Point du jour: je n'ai toujours pas repris la compilation de giac, je voulais auparavant avoir une configuration a peu pres utilisable pour eigenmath en partant du source https://github.com/gbl08ma/eigenmath, car il y avait plusieurs anomalies: affichage des flottants et calculs des fonctions transcendantes sur les flottants. Une partie des problemes venait de la libm du PrizmSDK (pas de libm fournie dans libfxcg) et une autre du fichier libfromcasio.a (dont le nom n'inspire pas trop confiance pour utilisation avec gcc). En ajoutant mes propres fonctions pour math.h (fort loin d'etre optimales, mais pour une precision relative de 1e-14 ca suffit) et une implementation de qsort, et en modifiant a la main l'affichage des doubles (non pris en charge par le sprintf de la libc de libfxcg), ca linke sans libm et sans libfromcasio et ca a l'air a peu pres fonctionnel pour le peu que j'ai teste.
Tout ca est disponible sur https://www-fourier.ujf-grenoble.fr/~parisse/casio/. Je ne sais pas si ca resoud les problemes d'affichage sur la calculatrice hardware dont parlait critor, en tout cas ce que je peux dire c'est que tout a ete recompile avec sh3eb-elf-gcc et le SDK de libfxcg qui semble le SDK a choisir pour la graph 90 e.

Ce qui serait pratique, c'est de mettre en place Travis (builds automatique sur les commits github) sur un repo github, car je suis tombé sur ceci : https://github.com/ivmai/libatomic_ops/ ... #L434-L445
Et en fouillant un peu sur kernel.org, même un binaire gcc 8.1 existe pour sh4 : https://mirrors.edge.kernel.org/pub/too ... _64/8.1.0/
Donc ca peut servir pour faire des choses pas mal assez simplement, sans besoin de builder un cross gcc.