Projet FiXos (OS pour casio fx-9860/Prizm)
Posté le 07/11/2011 20:11
maj 14/11/2013 :
un peu d'actualités
maj 03/03/2013 :
mon (presque) dernier pavé
maj 06/03/2015 :
Dépôts GitLab du projet.
Vu que le sujet d'OS unix-like pour nos chères G85 (fx-9860) et dérivées, ainsi que pour la Prizm (fx-cg20) fait réagir pas mal de gens, j'ouvre un topic pour en parler plus en détail
(début du sujet
sur ce topic)
Déjà, quelques précisions, mes posts précédent étaient simplement des idées pour montrer l'utilité et ma vision d'un possible OS, je n'avais pas vraiment pour projet de le concrétiser dans l'immédiat. L'idéal serait de bosser là dessus conjointement avec des gars d'omnimaga, cemetech, et les autres communautés.
Ceci dit, j'ai déjà quelques idées dans la tête, donc autant les faire partager
(au passage, j'en profite pour répondre un peu aux posts de l'ancien topic)
DJ_Omnimaga : sur Casio on a jamais eu l'occasion de créer un OS tiers jusqu'à la fx-9860 (excepté la Graph100 mais c'était loin d'être le modèle le plus répandu), les processeurs étant non documentés. Depuis que tous les nouveaux modèles de Casio utilisent la même architecture plus ouverte, il est possible de créer un OS custom, mais si il n'y a toujours pas eu de projet d'OS c'est entre autre par ce que les addins permettaient déjà de faire des programmes sympa, et probablement aussi à cause du manque de "programmeurs systèmes" dans le monde Casio.
Vdragon.b: Oui, un OS est généralement codé en C (pas une obligation, mais Linux en est un bon exemple ouaip). Ceci dit, vaut mieux "bien coder", par ce que l'expérience permet de d'optimiser le code, d'utiliser des syntaxes très barbares -mais pratiques-, de comprendre la structure générale de l'OS. Après, si il s'agit de code hors-noyau (un petit utilitaire ou autre) bien entendu les performances sont moins critiques, donc si tu te sens tu pourras aider j'imagine.
Pour les grayscales et le multitâche c'est prévu dans mon idée perso effectivement.
(dans un premier temps, multitâche coopératif avant d'écrire un vrai ordonnanceur)
Pour le moment, les idées que j'ai pour le kernel :
- une fonction init pour initialiser le MMU, le cache, créer la pile kernel, initialiser les interruptions, charger le système de fichiers...
- un FS type FAT par exemple, serait potentiellement créé en tant que fichier du FS de Casio (pour permettre la cohabitation des deux systèmes, en évitant de se tapper le FS de Casio complètement en carton *siflotte*)
- système de virtual FS pour permettre une uniformité des API d'écriture de fichiers
- possibilité de lancer un programme binaire "pur" (binaire sans header G*A), un binaire G1A, ou un fichier ELF (ce dernier permettrait l'utilisation de techniques avancées)
- gestion des bibliothèques dynamiques (du .so si le format est pas trop lourd, custom sinon), dont Newlib (lib stdc) pour alléger les addins, profiter de fonctions spécifiques à chaque calculatrice...
- gestion du MMU en mode activé et pour environnement multiprocessus (basculement en monoprocessus si nécessaire pour assurer la retro-compatibilité G*A?)
- évidemment, les addins seraient lancés en mode 'user' pour assurer la sécurité du kernel
- syscalls utilisant l'instruction TRAPA de l'assembleur SH3 (interruption logicielle), pour basculer en mode protégé et accéder à l'espace noyau
- des drivers d'affichage dépendant du modèle de la calculatrice, permettant de gérer un mode "terminal" et un mode "graphique"
Si vous avez des questions, des choses à proposer, des contacts avec des gens intéressés ou quoi que ce soit n'hésitez pas.
Je ne sais toujours pas si je vais vraiment me lancer là dedans (c'est un gros projet encore une fois, peu de chances d'être fini un jour si y'a que moi dessus
), mais dans le pire des cas, les idées présentées serviront bien à quelqu'un, un de ces quatres
Citer : Posté le 09/10/2012 20:39 | #
non non en fait gramaticalement les deux veulent dire la même chose (même si la première peut effectivement porter à confusion), et la première version est la nomination officielle du meme (d\'après les suggestions google)
et non c'était plutôt bien joué Louloux, je ne te critiquais pas (pour une fois)
bon maintenant stop au [HS] avant que Tatayoyo ne fasse encore des siennes
[/HS]
Citer : Posté le 09/10/2012 21:04 | #
Ou moi... /me brings banhammer...
Donc Dafpp, c'est une bonne initiative que tu as là, mais qu'en est-il de tes autres projets?
Invité
Citer : Posté le 10/10/2012 17:54 | #
Donnes la moi dans ce cas, je ne l'ai pas gardé.
Tu penses bien, je ne demanderai pas si je l'avais.
Citer : Posté le 10/10/2012 18:35 | #
J'adore tes manière Dafp
Invité
Citer : Posté le 10/10/2012 22:04 | #
Penses tu donc, je n'avais pas lu la page 6.
Eiyeron, je n'ai pas dis que je voulais continuer le projet. Je veux juste l'adresse de kristaba pour parli. Comme quoi, quand la liste de mails est utile, je ne l'ai plus.
Mais louloux va gentiment me l'envoyer je suppose.
T'as mon adresse mail ?
Citer : Posté le 10/10/2012 22:35 | #
T'envoyer la liste de mails ? je peux pas. L'adresse de kristaba... j'hésite encore.
Ca finit par @hotmail.fr
Citer : Posté le 11/10/2012 07:04 | #
Invité
Citer : Posté le 11/10/2012 07:21 | #
Je préfère que kristaba la donne par lui même, au lieu de jouer à la loterie.
Tiens louloux, pascal a diogoantunes d org, au cas où tu t'en souviendrai subitement.
Citer : Posté le 11/10/2012 14:46 | #
je l'ai son mail si tu veux (je te le passe dès que je suis chez moi)
Citer : Posté le 13/10/2012 13:46 | #
Je l'ai aussi.
Citer : Posté le 03/03/2013 21:41 | #
Hop là, "petit" déterrage de 2013...
J'ai profité de mes -courtes- vacances pour me remettre un peu sur ce vieux projet.
Je ne pense pas que je continuerais longtemps, par manque de temps à passer là dessus (mais qui sait, on verra bien), et je me dit donc qu'il vaut mieux que je partage tant que je suis chaud, sinon ça va encore finir sous le tapis.
Par rapport aux quelques bases que j'avais fait précedemment, j'ai pas mal bossé et le projet devient suffisamment intéressant pour que j'en parle un peu.
Le code actuel permet globalement :
*de gérer le bootstrap pour prendre la place de l'OS casio en RAM
*d'initialiser les périphériques les plus important (MMU, exceptions et interruptions matérielles, mode d'exécution du CPU)
*de gérer la mémoire virtuelle à la fois au niveau physique (TLB et MMU) et logique (noyau lui-même), en répondant aux echec du TLB
*de gérer plusieurs zones de mémoire virtuelles (pour plus tard isoler les processus entre eux)
*de manipuler les interruptions simplement via un enregistrement dynamique des fonctions callback du noyau
*de manipuler la mémoire physique par page (allocation "dynamique" de blocks de 1kio)
*de manipuler plusieurs systèmes de fichiers au travers d'un Virtual File System (permettant à la fois de rendre plus rapide la création de système de fichier et de les mounter n'importe où dans le système de fichier logique)
*de créer et utiliser un système de fichier en RAM très simpliste (seulement des répertoires et des noeuds de périphérique, utile surtout pour créer l'arboressence initiale, et le répertoire /dev)
*d'accéder en lecture seule au système de fichier en mémoire de stockage (SMEM)
*d'interagir un minimum avec un terminal de boot (vraiment minimaliste, juste pour le log, mais bien utile) et avec des fonctions iskeydown (vraiment temporaire, dès qu'il y a mieux ce sera remplacé)
Pour l'instant, seul le noyau s'exécute (il s'initialise, effectue quelques tests, puis attends un reset manuel), donc pas de programmes utilisateur, pas de gestion des processus, et pas grand chose de visuellement évoquant
Le projet est disponible sur gitorious :
https://www.gitorious.org/fixos#more
Comme précisé sur cette page, le projet utilise GCC (la plus part des toolchain GCC pour prizm devraint fonctionner) et l'outil make.
Le header G1A est généré par un wrapper que j'avais conçu y'a un moment, disponible sur GitHub (j'aime bien varier les hébergeurs apparemment
Mon wrapper si besoin : https://github.com/Kristaba/C-G1A-Wrapper
Maintenant que les détails sont posés, quelques précisions :
1) Je n'ai pas mis de G1A déjà compilé à disposition par ce que je ne veux pas que n'importe qui le lance et se retrouve avec une calto foirée par ce qu'il ne savait pas ce qu'il faisait. Si le projet devient un peu plus mature, je mettrais quelques protections supplémentaires, et cela posera moins de problème. De plus, ce n'est pas un projet traditionnel, il y a très peu à voir juste en l'exécutant (limite je ferais des screens pour les curieux).
2) Si vous pensez avoir compris les enjeux et que vous voulez compiler le bouzin mais que vous avez des problèmes, je serais ravi, dans la mesure du possible, de répondre aux questions sur le sujet. Cependant, dans l'état des choses, les sources sont bien plus intéressantes que le binaire (je me répète je crois là
3) Essayez aussi de comprendre le but du projet. Si vous avez envie de faire un OS meilleurs que celui de Casio pour lancer des supers jeux en 3D, connecter votre calculatrice à Internet, ou encore avoir une interface plus jolie que ce bon vieux menu de nos Casio, ce n'est PAS le but premier du projet.
Si cette dernière phrase vous concerne, soyons clairs, mes sources sont là pour être lues, copiées, utilisées dans d'autres projet (tant que vous distribuez les sources à un moment *siflotte*). Ca ne me dérange pas et ça me ferais même très plaisir. Mais s'il vous plait, comprenez que je ne suis pas entrain de faire le système dont vous avez besoin, ce n'est pas mon objectif ni le genre de chose que j'ai envie de coder actuellement.
4) Désolé pour le vocabulaire technique, mais si le thème vous intéresse n'hésitez pas à faire quelques recherches. Pas mal de chose sont assez bien présentées sur Wikipedia, et pour le reste vous devriez trouver des infos sur des sites spécialisés sur le développement du noyau linux ou de noyaux unix-like en général (en anglais bien souvent par contre).
Citer : Posté le 04/03/2013 20:16 | #
Super cool!
J'ai plus qu'à apprendre vraiment l'assembleur pour comprendre le code
I own a graph 3575+.
Citer : Posté le 04/03/2013 21:50 | #
Il y a très peu d'assembleur dans le projet, le bootstrap, qui est assez petit, et une 10aine de lignes pour l'initialisation de la pile.
Il y a aussi 5 fichiers pour avoir des fonctions optimisées de type memcpy, strcpy & co, mais qui ne sont pas de moi (ils viennent de Newlib), mais il n'est pas réellement utile de comprendre comment ces fonctions sont optimisées.
Après, il y a parfois une ou deux ligne d'assembleur inline (GCC permet d'écrire du code assembleur au milieu d'une fonction C), mais uniquement dans quelques fonctions d'abstraction de l'architecture.
Même les gestionnaires d'interruptions materielles sont actuellement écris en C
Pour le moment j'essaye de faire quelque chose de fonctionnel, et l'écrire en C permet un gain de temps (et de santé mentale, lors d'un debug) appréciable. Ce qui n'empêche pas que si le projet évolue un peu, je prendrais le temps de réécrire quelques sections très utilisées en assembleur pour être sûr des performances de ces portions de code.
Sinon, le problème qui risque de se poser si tu regarde un peu les sources, c'est plus la façon d'utiliser le C, qui est assez souvent plus "freestyle" que dans une application traditionnelle.
Bref, faut pas avoir peur de croiser des defines de partout, du cast à foison, des unions de structures d'unions (j'exagère un peu mais c'est pas loin des fois)...
Ceci étant dis, je pense que toute la partie qui n'est pas "arch-specifc" est compréhensible avec des notions correctes en C et un peu de patience. Ca demande d'être à l'aise avec les pointeurs par contre.
(juste pour illustrer mes dires sur les parties spécifiques à l'architecture, dans ce petit header on trouve déjà des bitfields et des fonctions extern inline...)
Citer : Posté le 04/03/2013 22:40 | #
En tout cas ça a l'air prometteur!
Au niveau application tu penserait obtenir quoi de la communauté précisément?
Citer : Posté le 05/03/2013 17:59 | #
Kristaba, pendant que tu es là, tu voudrais pas nous fixer la gestion du gris une bonne fois pour toute?
J'avais trouvé une solution qui me semblait prometteuse qui conscistait à, au lieu de remplacer le gestionnaire d'interruption casio par notre interruption de gris, écrire un gestionnaire d'interruption qui marche comme celui de casio (ou redirige vers lui), et fait l'interruption de gris si c'est le bon evènement. j'avais trouvé de la doc et vu que ça ne pouvait se faire qu'en assembleur (à cause de l'appel d'interruption qui nécessite une gestion différente de la stack et autres), mais je n'ai pas les compétences requises.
Citer : Posté le 05/03/2013 20:24 | #
Siapran:
Au niveau application utilisateur?
Franchement je ne sais pas ce qui sera faisable facilement, ou en tous cas qui ait plus d'intérêt à être fait sur ce système plutôt que directement pour "l'OS" Casio.
A vrai dire, les gros avantages d'un système d'exploitation, c'est la sécurité, la fiabilité, l'API (syscall) mise à disposition et l'abstraction du matériel.
Pour la majorité des projets sur calc, seul les deux derniers points pourraient avoir une utilité directe. Et encore, si les syscall sont assez proche d'un UNIX standard, ce n'est pas directement utile pour de l'affichage (pour un jeu), et en plus cela réduirait probablement les performances des programmes utilisants beaucoup d'I/O (cas typique d'un jeu, donc...).
Après, tout dépend de l'implémentation, mais je pense que c'est plus des fonctionnalités "secondaires" qui pourraient intéresser les développeurs (bibliothèque partagée, système de fichier unifié, portabilité entre les différents modèles, implémentation en interne de pilotes USB...), mais c'est loin d'être à l'ordre du jour.
Pour finir, le fait d'avoir un terminal pourrait être sympathique pour certains utilitaires, les développeurs qui ne programment pas encore sur Casio pourraient faire cette transition plus simplement car le système serait UNIX-like, et surtout, si FiXos devient mature et respecte relativement POSIX, on peut imaginer la facilité de portage des millions d'application UNIX existantes (à condition qu'elles ne soient vraiment pas gourmandes...).
A plus court terme, j'espère que certaines personnes seront intéressées par le noyau lui-même, l'ajout ou la correction de fonctionnalités, l'écriture de pilotes de périphériques, etc... Mais je ne suis pas sûr que PC soit le bon endroit pour cela (ici la communauté est plus spécialisée dans le haut niveau, les jeux et autres utilitaires, et je comprend parfaitement que tout le monde n'ait pas envie de lire des docs de 300 pages pour faire mumuse avec le processeur
Vebveb:
Franchement, j'avais passé pas mal de temps sur ce casse-tête à l'époque, mais c'est vrai que je connaissais moins le proco qu'aujourd'hui.
Je ne suis pas sûr que ton idée empêcherait tous les problèmes, à tenter quand même (à vrai dire c'est étrange que sans cette technique la calto plante aussi peu avec les grayscales activés Oo). Mais sans mentir je n'ai pas la motivation de voir ça tout de suite.
Sinon, as-tu vérifié si des changements sont effectués par l'OS dans les registres d'interruptions?
Il suffit de comparer, juste avant d'enlever les grayscales, si les valeurs des registres sont bien identiques à ce que tu y avais assigné après la sauvegarde de leur ancien état.
Il n'est pas impossible que des changements soient effectués par les syscall, et que certains d'entre eux influent le comportement de l'OS à la fin de l'exécution (moins probable que ton idée, mais pas impossible).
Citer : Posté le 05/03/2013 22:26 | #
J'ai fait de nombreux tests, et je suis sûr et certain que cela enlèverait plus de la moitié des bugs.
En effet lors de l'entrée dans l'interruption, on peut tester une variable pour savoir pourquoi l'interruption est appelée, et si elle est appelée pour une autre raison que le grayscale, ça plante tout le temps (exemple de raison d'un tel appel: clavier. Fix: je change le contenu de certaines autres variables pour que le clavier n'appelle plus d'interruption. J'avais aussi testé un moment d'appeller la syscall de gestion du clavier, et ça marchait presque bien).
De plus quelques fonctions, comme sprintf si je me souvient bien, ne marchent pas si l'interruption casio n'est pas en place (j'ai testé en laissant le tmu mais en mettant le vbr de casio et non du gris et ça marchait).
Pour toutes ces raisons, je pense que ça résoudrait beaucoup de problèmes de faire ça. En plus on pourra utiliser getkey.
Citer : Posté le 06/03/2013 03:00 | #
(ici la communauté est plus spécialisée dans le haut niveau, les jeux et autres utilitaires, et je comprend parfaitement que tout le monde n'ait pas envie de lire des docs de 300 pages pour faire mumuse avec le processeur
Quoique, je pense que certains programmeurs pourraient être tenté... (je dois dire que j'aime bien le C, mais parfois, j'aimerais tenter de comprendre comment marche la machine qui interprète le C que je crée...)
-en C:
-Un pong.
-Un projet en pause. Je compte le reprendre de temps en temps: Summer Cursed
-mon tuto sur les Str
Mes calto: G25+, G75
Mon minecraft en dévelopement
-Portal2D de JavierXD
-CalCraft de Wime
-GeekBros du groupe GeekBrothers (Eiyeron,Siapran,KevKevVTT,Adbook,LIMachi)
Citer : Posté le 15/03/2013 18:00 | #
Content de voir que ça avance! N'oublie pas la bouteille de champ' ne sera à toi que quand tu auras terminé!
Citer : Posté le 04/04/2013 21:13 | #
Sh3 only? c'est la loose...
Minecraft de limachi
Yu-gi-oh! de intelligide
Fix-os de kristaba
Baston!
Citer : Posté le 05/04/2013 17:41 | #
Avec ça, y'a plus de SH3 ou pas, c'est carrément un nouvel OS
Plus de problèmes du genre
Mais c'est très long à faire, et ça demande d'être passionné par ça (à ce niveau là, faut pas compter que sur la motiv', je pense).