J'ai (un tout petit) peu avancé ce soir, je n'ai pas importé les fonctions de manipulations des chaînes de LePhenixNoir, je ne sais pas si tu veux les ajouter toi ou...
Ensuite, on parlait de conserver fxlib, mais notamment pour les I/O, vous pensez qu'il est préférable de conserver les syscalls (ou du moins leur usage) comme on l'avait dans fxlib, ou plutôt introduire quelque chose qui ressemblerait plus à du C standard, avec une sorte de gestion des flux, un peu à l'image de la LibFxCG qui, bien que basée sur les syscall propose une gestion des fichiers avec des fopen() / fwrite() et confrères, mais aussi une gestion assez satisfaisant du flux stdout par exemple ? Je pense que c'est réalisable et ça se rapprocherait un peu de "Memory" par exemple, dans le principe de proposer des fonctions plus simple à utiliser, et standards si possibles, mais je ne sais pas ce que vous en pensez.
Ce qui suit est purement facultatif et sans rapport trop direct (ainsi qu'un peu lourd dans l'écriture peut-être), je voulais faire un truc plus court, mais je n'ai pas trop vu les lignes passer :whistle:...

Finalement, (parceque je n'ai que ça à faire à l'instant ou j'écris ), je vais détailler brièvement l'idée derrière ce "simili d'émulateur" évoqué plus haut. En fait, si on arrive à avoir quelque chose de bien standard au niveau de la LibC (notemment pour les I/O), et que par la même on propose une fxlib "maison" qui combinerait peut-être plusieurs libs du site (ML, LibText) (juste une idée pour ça, il faut voir avec les auteurs bien entendus ), il serait je pense envisageable d'obtenir un environnement d'éxécution, pour un code à destination d'une Casio, sur PC.
Je m'explique : au moment de compiler, au lieu d'appeler sh3eb-elf-gcc, on pourrait utiliser gcc en linkant une bibliothèque standard pour pc à la place de celle que l'on réalise actuellement (d'où l'interêt d'avoir quelque chose d'assez standard pour la bibliothèque qui fait l'objet de ce topic de mon point de vue), ainsi qu'une bibliothèque "émulant" en quelque sorte fxlib.h (ou celle que l'on ferait), c'est à dire capable "juste" d'afficher une VRAM (similaire à celle de la Casio) à l'écran (si toute les fonctions de dessin utilisent un "get_vram_adress" ça n'est pas très compliqué à mettre en place) ou de prendre en charge des fonctions comme IsKeyDown() en se basant sur diverses bibliothèques pour PC (SDL par exemple, enfin, je ne suis pas vraiment bon en tout ce qui concerne interface graphique / développement "haut-niveau" (je veux dire gestion du clavier ou autre), donc encore moins à même de savoir ce qui est le plus adapté à ce genre de problèmatique) par exemple.

Je ne sais pas si je suis très clair pour le principe global (probablement non, il est tard, et des phrases longues avec parenthèses imbriquées ne doivent pas très bien passer ), mais en gros on aurait "deux compilations" possibles : une à destination de la casio, en linkant les bibliothèques appropriées, et l'une afin de produire un binaire éxécutable sur PC avec des bibliothèques de substitutions, sans toucher au code initial vu que des bibliothèques différentes prendraient en charge les mêmes fonctions, mais l'une pour la calto, et l'autre pour PC.

Certes, les inconvénients par rapport à un "vrai émulateur" existeraient (et seraient nombreux peut être ?), c'est à dire, abscence de tout développement à plus bas niveau (pas de gestion d'un quelquonque hardware, ou d'ASM SuperH par exemple) que les fonctions proposées (si elles sont complètes pour développer un jeu par exemple, ça peut ne pas poser problème), ou un debug peut-être pas représentatif (vitesse d'éxécution, erreurs spécifiques à Casio...).
Mais je pense que les avantages par rapport à un "vrai émulateur" pourraient aussi laisser envisager sa conception : déjà, la masse de travail serait bien moindre par rapport à celle nécessitée par la mise en place de l'émulation complète du matériel d'une Casio, le debug serait peut-être plus simple, on pourrait profiter d'outils intéressants (profilage de code par exemple ), enfin voilà.

Peut être n'est-ce qu'une divagation d'un soir et une idée peu réalisable, mais ça peut constituer être une alternative à un vrai émulateur et une piste de réflexion vers l'aboutissement d'un SDK "libre". Si vous n'avez rien compris, enfin, pas trop compris le sens / intêret de ce que j'ai raconté, dites le moi, j'ai conscience d'être relativement rapidement flou dans mes explications :sry:, j'essaierai de reformuler et de m'améliorer sur ce point justement :).