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 11/02/2015 00:01 | #
Le message en question, c'était Intelligide disant "Intel core" => on m'appelle ?
Bref, rien de bien intéressant...
Citer : Posté le 11/02/2015 09:55 | #
Dooonc, DS, le port série, c'en est où?
Ajouté le 23/02/2015 à 19:21 :
Bah du coup, j'ai rencontré Kristaba en personne et du coup on n'a parlé que peu de FiXos. Voui, on est passés par tous les problèmes actuels comme le port série, la mémoire ou les libs dynamiques; ces dernières seront à retravailler donc rien de stable à leur sujet. On a dit quoi d'autre? Je me souviens plus entre la bière et le pinard (le pâtes étaient très bonnes). Voui!
- Je pense que je (ou Kris) vais mettre en place un système de build automatique de GCC avec la libc de FiXos pour simplifier la mise en touche avec le kernel pour tous même si on n'a rien de fixe ou user-friendly pour le moment.
- Le wiki du projet pourra servir à préciser davantage les structures du kernel, ce que le Grand Manitou n'a pas pu faire à présent. Donc Darkyz, on pourrait commencer à le remplir et le G.M. pourra corriger ou approuver nos infos. Ca évitera de lui faire faire ça aussi.
- Je sais plus ce que le G.M. a dit au sujet du caractère privé du site, sauf que l'adresse (privée) sur laquelle les projets sont dispos est temporaire. Il avait parlé de faire u miroir sur GitHub pour l'accessibilité et l'intérêt qu'un tel projet pourrait récupérer depuis les membres de ce site.
- Le G.M. est trop humble concernant son projet. Il n'a pas encore réalisé qu'il faisait un boulot de titant comme Linus a pu le faire auparavant.
- The Game.
- Des initiatives de tests pourraient être mis en place. Je tiens à noter aussi que Kristaba trouverait une énorme utilité à ce qu'on lui envoie une ou des caltos de différents modèles (SH3/SH4, et éventuellement, différents modèles des mêmes familles d'archi). Le fait que quasiment un proco différent par modèle SH3 est utilisé ne nous va pas nous aider.
- Du travail sur le système d'architecture sera à faire pour rendre le kernel indépendant de la famille des SuperH, même si ce n'est pas à l'ordre du jour.
- Le port série est en cours de dèv', vu que Dark Storm planche dessus pour le moment mais c'est pas encore à l'ordre du jour.
- Je vous conseille le resto "Le 15" sur le Cours Julien si jamais vous descendez sur Marseille. Ne vous vexez pas si la serveuse parle de juger la tête des clients !
- Les champis, c'est à éviter.
- La prochaine fois, on devrait éviter de s'arrêter en plein milieu d'un trottoir pour parler et plutôt s'arrêter pour boire un énième coup.
- Redescends quand tu veux, Kris! Mes parents seront habitués de voir des aliens débarquer à la maison vu qu'ils sont passés par Siapran et une connaissance un tantinet excentrique (elle était intriguée par Bust-A-Move à l'époque). Du moment que t'as de bonnes manières!
Ajouté le 23/02/2015 à 19:21 :
Et putain, je deviens comme le G.M., je fais vraiment de plus en plus souvent de gros posts.
Citer : Posté le 23/02/2015 20:52 | #
- Je pense que je (ou Kris) vais mettre en place un système de build automatique de GCC avec la libc de FiXos pour simplifier la mise en touche avec le kernel pour tous même si on n'a rien de fixe ou user-friendly pour le moment.
Sympa ! (surtout que j'ai toujours pas réussi à le compiler entièrement avec un sysroot
- Du travail sur le système d'architecture sera à faire pour rendre le kernel indépendant de la famille des SuperH, même si ce n'est pas à l'ordre du jour.
Euh, j'ai raté quelque chose ?
Coïncidence ? Je ne pense pas.
Citer : Posté le 24/02/2015 14:58 | #
Sympa ! (surtout que j'ai toujours pas réussi à le compiler entièrement avec un sysroot
Est-ce que tu suis bien la procédure du tutoriel pour compiler un GCC pour SH?
Euh, j'ai raté quelque chose ?
Nan, il voulait ça au début mais pour le moment, le kernel n'est adapté que pour les SH3. Si je cite grossièremenrt ce qu'il m'a dit vendredi, actuellement le port sur SH4 pourrait être faisable mais cette adaptation ne serait pas des plus propres. Il désirerait développer de meilleures méthodes pour simplifier l'adapation du kernel sur d'autres familles d'archi.
Citer : Posté le 25/02/2015 13:27 | #
Sympa ! (surtout que j'ai toujours pas réussi à le compiler entièrement avec un sysroot
Est-ce que tu suis bien la procédure du tutoriel pour compiler un GCC pour SH?
Oui, sauf que je rajoute un paramètre --with-sysroot=*un sysroot contenant la libc au préalable compilée avec un gcc pour sh3 normal*
Et j'ai pas réussi à compiler la libgcc mais je vais voir ce qui buggue
Coïncidence ? Je ne pense pas.
Citer : Posté le 25/02/2015 13:42 | #
T'as bien le paquet build-essential(s) d'installé ?
Citer : Posté le 25/02/2015 13:55 | #
Non mais sous arch, le contenu de ce paquet est déjà installé par défaut
Et j'ai déjà installé un gcc pour sh3 et ça marchait très bien donc le problème vient du sysroot...
(plus d'info sur les options à la compilation de gcc ici : https://gcc.gnu.org/install/configure.html )
Coïncidence ? Je ne pense pas.
Citer : Posté le 25/02/2015 22:07 | #
Je n'utilise pas de sysroot pour ma part et ça marche très bien. Je n'ai juste qu'à rajouter le libc de FiXos par la suite.
Citer : Posté le 27/02/2015 12:26 | #
Je crois que je vais faire ça aussi ! (après avoir encore fait un peu joujou avec les options à la compil de gcc...
Coïncidence ? Je ne pense pas.
Citer : Posté le 02/03/2015 10:49 | # |
Fichier joint
PROOF OF CONCEPT : shell avec builtins (ici, il n'y a que ls pour le moment). C'est surtout pour montrer qu'on peut commencer à avoir quelque chose d'intéressant sur ce kernel.
Pour le moment, je ne peux pas afficher d'autres dossiers vu qu'ils sont en minuscules (/mnt, /dev) et que le texte tapé est uniquement en majuscules (/MNT), argh. Je vais bosser sur une manière d'entrée de texte qui permettra de switcher Min/Maj à la Ti (alpah : casse défaut, double Alpha : changer casse, triple : retour à la normale).
Ajouté le 02/03/2015 à 10:50 :
D'ailleurs, il semblerait que perror déconne, je n'ai uniquement que des ERANGE comme erreurs...
Citer : Posté le 02/03/2015 10:58 | #
Salut,
Serais-tu dans combien de temps environ on pourra commencer à développer des add-ins pour ce nouvel OS ?
Mieux, les add-ins qui existe déjà seront-ils compatible ? Si non, y aura t-il moyen de créer un outil comme le SH4 compatibility tool ?
Merci
Citer : Posté le 02/03/2015 11:17 | # |
Fichier joint
Pour les addins existant, vaut mieux oublier car ils dépendent d'accès directs à du hardware (KeyDown, RTC, ML, etc..), ce qui n'est pas supporté sur FiXos qui offrira des accès comme sur Linux (/dev/display pour l'écran par exemple) ou des syscalls propres à l'OS Casio ( os dont on en veut s'en débarrasser). Un portage sera à faire pour adapter lesdits addins. Bien entendu, une fois que le kernel supporte les librairies dynamiques, je porterai MonochromeLib pour qu'on puisse en servir sans avoir à gérer trentes versions qui trainent sur internet.
En théorie on peut déjà programmer dessus mais le kernel est encore assez fragile, il a tendance à se bloquer à la moindre erreur non gérée.
Citer : Posté le 03/03/2015 20:01 | # |
Fichier joint
Suis en train de patcher le kernel pour rajouter les minuscules, du coup, je peux faire enfin un ls dans le système de fichiers! (Il est case-sensitive, donc...)
Ajouté le 03/03/2015 à 21:16 :
BOn, j''ai implementé une gestion à la Ti.
Alpha : cycle normal | alpha Majuscule| alpha minuscule
Shift+alpha : alpha lock ensuite
- Alpha : cycle normal | alpha Majuscule| alpha minuscule
Sur le papier, c'est pas facile mais à la longue on s'y fait (testé et approuvé par moi). J'ai aussi mis de côté une méthode comme EDIT (F6 = changer casse).
Donc, faut que je contacte le Grand Manitou pour savoir comment je vais envoyer l'état du clavier vers d'autre système (notamment le terminal pour afficher l'état soit en changeant le curseur soit en rajoutant un indicateur en haut à droite).
Citer : Posté le 03/03/2015 22:26 | #
Pas de commit ?
J'aimerai bien forker pour tester une methode de saisie personnelle
Et puis ça me changera de la doc et des registres...
Ajouté le 03/03/2015 à 22:27 :
En fait j'ai rien dit
Citer : Posté le 04/03/2015 11:38 | #
Bon, j'ai un peu documenté le kernel dans le wiki. Pour le moment, y'a pas mal de vides dans ce que je sais et il faudrait que j'approfondisse mes recherches pendant que je trouve un moyen d'obtenir l'état du clavier et l'afficher.
Citer : Posté le 06/03/2015 14:07 | # |
Fichier joint
J'ai eu nouvelles de Kris concernant le repo de FiXos : j'ai le droit d'en publier l'adresse. GitLab forçant l'inscription à tous ceux qui passent par la page d'accueil, je vous refile temporairement l'adresse du repo directement et je nettoierai le post original juste après.
J'en profite pour annoncer mon nouveau projet (un de plus! une de plus!) : FXSH, FiXos SHell. (Cette fois, c'est officiel) Un shell textuel pour les jôlis terminaux qu'on a plus ou moins en place. Actuellement, il fait une partie du job que le kernel devrait faire, notamment gérer les variables d'environnement. On peut (il semblerait, j'ai réussi à lancer le shell depuis le shell en tapant le nom d'exécutable) executer des programmes, se déplacer (cd, cd path, cd /path (chemin absolu) mais pas encore de cd ..) et lister les fichiers dans le dossier courant ou un dossier de son choix (je viens de voir qu'il faut que je rajoute la gestion des sous-dossiers ici encore, du coup c'est ls ou ls /path (chemin absolu)).
Ajouté le 06/03/2015 à 16:32 :
MàJ : J'ai lié cd à la fonction chdir du kernel, du coup, je sais quand un dossier existe, il déplace le dossier actuel du processus au bon endroit et j'ai eu comme effet de bord un chouette truc :
Du coup, pour l'instant:
#Tout ça va marcher
$ ls
$ ls path
$ cd # Renvoi à /
$ cd relative/path
$ cd /absolute/path
#Tout ça va retourner une erreur prévue
$ ls dossier/inexistant (relatif ou absolu)
$ cd dossier/inexistant (relatif ou absolu)
#Tout ça ne marche pas encore
$ cd ..
$ cd ./machin...
$ ls fichier/existant (il part du principe que je veux lister un dossier et pas un fichier, j'avais pompé la fonction à Kristaba)
Ajouté le 06/03/2015 à 16:32 :
Et bien entendu, ça devrait aussi marcher sur Linux.
Ajouté le 11/03/2015 à 13:14 :
Eh hop, des nouvelles du front :
- J'ai commencé à corriger les errno envoyés par le système pour avoir des résultats plus convainquants.
- J'ai noté l'absence de . et ;; dans les FS, donc je devrai les parser manuellement...
- j'arrive pas à programmer un cat. un simple putchar(fgetch(file)) provoque un oops (crash du kernel).
- Le kernel est compilé en C99 par défaut
- getenv et setenv sont ajoutés dans la libc (suite à mon travail sur eux dans FXSH puis dans la libc)
Et concernant FXSH:
- J'ai programmé un exécutable init dans le projet. Celui-ci étant lancé par le kernel au démarrage de ce dernier, il va gérer les sessions des terminaux et ainsi les signaux tels que ^C (SIGINT si je ne m'abuse) seront transmis aux processus de FXSH et de ses fils. Init va aussi éviter que FXSH ne soit quitté en le relançant, vu qu'on n'a pas de vrai système de session ni d'utilisateurs.
- FXSH donc va gérer les signaux et éviter de se retrouver court-circuité par eux en les redirigeants vers une fonction actuellement vide (je pourrais y mettre des infos de debug mais c'est aps prévu).
- Les programmes fils peuvent à présent être coupés lors de l'envoi d'un signal (EXIT pour envoyer un ^C).
Liste des builtins supportés par FXSH
ls
cd
uname (obtenir le nom et infos du kernel)
clear
cat (est sévèrement cassé pour des raisons inconnues relatives au kernel/libc)
Citer : Posté le 11/03/2015 17:13 | #
les signaux tels que ^C (SIGINT si je ne m'abuse)
Ce serait pas SIGTERM plutôt ?
Sinon, ça fait plaisir de voir que tu arrives à avancer. Un peu moins de savoir que certaines choses continuent de crasher...
Citer : Posté le 11/03/2015 17:41 | #
Je crois aussi que c'est SIGINT.
Citer : Posté le 11/03/2015 17:49 | #
Nan, c'est bien SIGINT.