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 04/10/2014 10:37 | #
Leffe pas exactement : un fork créé un clone de ton processus (à un détail qui permet de savoir si c'est le fils ou le père). Ils ne partagent rien (les FD, la mémoire, mes ressources sont copiées et chacun a a son propre truc). La famille de fonction "exec" remplace juste le processus actuel par un nouveau processus. Pas de partage de ressource par stack avec l'assembleur ici, tu ne peux communiquer qu'avec les signaux ou les types de fichiers conçus expres comme les pipes.
Ajouté le 04/10/2014 à 10:39 :
Tenez, c'est le lien vers les cours Unix de mon prof : http://pageperso.lif.univ-mrs.fr/~edouard.thiel/ens/unix/index.html
Ça vous aidera très certainement à comprendre quelques trucs!
Citer : Posté le 04/10/2014 10:39 | #
Ok, je vois. C'est bien différent de ce que j'avais imaginé.
Mais du coup ça veut dire qu'on a un OS qui peut gérer plusieurs tâches même s'il n'en exécute qu'une à la fois ?
Citer : Posté le 04/10/2014 10:41 | #
Oui, un OS a un interrupteur qui switche de processus tout les n cycles, c'est le schelduler.
FiXOS est multitâche, mon shell créé deux processus dont chacun va gérer un terminal. Et chacun va créer des fils quand il va falloir appeler des programmes.
Citer : Posté le 04/10/2014 10:43 | #
Est ce que dans l'OS il y a des interruptions ? (si on pouvait les enlever on ferait des meilleurs niveaux de gris )
Car sur TI c'est le cas
Citer : Posté le 04/10/2014 10:45 | #
Si tu les enleves tu n'aurais aucun moyen d'avoir des niveaux de gris avec un timing constant. Concernant de tels interruptions, je ne saurais te dire país il semblerait que FiXOS à l'air de gérer les VBR donc interruptions. Mais j'ai pas vu de syscall user pour les gérer.
Citer : Posté le 04/10/2014 13:00 | #
Tenez, c'est le lien vers les cours Unix de mon prof : http://pageperso.lif.univ-mrs.fr/~edouard.thiel/ens/unix/index.html
Tiens c'est amusant, j'ai exactement le même début de cours que toi (sauf que nous c'est plus pour la manipulation d'Unix), et je suis en première année de DUT informatique
Citer : Posté le 04/10/2014 13:00 | #
J'avais la même chose en DUT, c'est un cours général pour que tout le monde soit au même niveau.
Ajouté le 06/10/2014 à 10:11 :
J'ai eu des news du patron. Pour faire un rapide résumé de la situation :
- Kris aimerait se baser sur une license BSD ou GPL-like mais il a piqué du code GPL de GCC de Linux. Il serait intéressant de nous éclairer à ce sujet et savoir quelle licence prendre.
- Si des gens se mettent à bidouiller davantage le kernel que maintenant, un issue tracker serait une bonne idée à implémenter
Malheureusement j'ai des déboires avec le VPS donc je ne pourrai l'uploader pour le moment. Brimir serait une bonne idée, assez moderne et pas trop degueu selon mon avis. (J'aimerais tout de même programmer le mien, tiens)
- la je cite :
J'en profite pour parler de quelque chose assez important pour maintenir les repos proprement : le prochain objectif pour FiXos va être de séparer les trois éléments que sont le noyau, la bibliothèque C/posix et l'espace utilisateur.
L'idée est que le code de l'espace utilisateur (y compris le init) doit être séparé du noyau, et que la glue entre les deux va devenir la lib C en lieu et place des simples syscalls.
Chaque partie devrait être contenue dans un repo indépendant (la libc en a déjà un : https://www.gitorious.org/fixos/pdclib ), il faudra que j'en prépare un autre pour l'espace utilisateur (disons pour la partie "bas niveau" de l'espace utilisateur, le but étant aussi que les applications plus complexes soient maintenues dans leurs propres dépots, et de manière indépendante). Cette espace utilisateur est à comparer aux coreutils de GNU, ou à busybox par exemple.
Pour l'instant, le gros handicap pour parvenir à cela est l'état de la lib C : elle fonctionne pas mal du tout, n'est pas trop lourde (enfin, surtout si on enlève le support de l'Unicode >_<), mais ne gère que ISO C, et pas Posix, et donc n'est pas du tout adaptée à une utilisation en tant que biblothèque système.
Il va donc falloir bosser pour ajouter progressivement les éléments importants de Posix à la lib C, c'est ce sur quoi je bossais avant de mettre ça en freeze.
Une fois que ce sera fait, les applications utilisateurs dépendront uniquement de la lib C (et pourront s'appuyer sur ce qu'elle définie déjà, ça devrait rendre le boulot beaucoup plus simple!
Je resume : kris ne s'occupe actuellement que du kernel et de la lib C pour FiXOS (Leffe ne me parle pas de ta lib C elle n'est pas compatible pour quelques raisons.); il désire séparer le projet en trois parties, dont le kernel, la lib C et la "busybox", qui va contenir le strict minimum.
La priorité des tâches edt assez simple : la lib C, le kernel et ensuite l'userspace (shell, OS, ce que vous voulez mais du moment que ça utilise le kernel, c'est du userspace)
Le reste des news concerne mon shell mais je peux résumer sur un point très simple : ne pas s'attarder trop sur l'userspace pour le moment, on a un kernel et une lib à finir.
Bobage Invité
Citer : Posté le 09/10/2014 21:20 | #
Mon cher kristaba, mon voeu est exauce :
http://librecalc.com
Cassio c-est de la grose daube!
VIVE LE LIBRE!
Citer : Posté le 09/10/2014 21:43 | #
C'est marrant parceque Jules50 nous a sorti ce lien un peu plus tôt dans la soirée... Peut être est-ce une coïncidence, mais j'y crois pas trop, alors, pourquoi poster en invité ^^. Sinon, c'est un projet sympa c'est vrai ;).
Citer : Posté le 09/10/2014 21:46 | #
@Nemhardy
Sur ce point-là on est d'accord... je suppose que tu sais que ce pseudo était utilisé par Dafp pour poster dans ce topic, mais je ne vois pas, même en supposant que ce message est bien de lui, comment il pourrait tomber par coïncidence sur ce lien... dans ce cas, ça voudrait dire qu'il lit le chat -- ce qui est surprenant.
bobage Invité
Citer : Posté le 09/10/2014 21:52 | #
y a DLFP aussi - arf : http://linuxfr.org/news/une-calculatrice-scientifique-libre-sous-linux-materiel
Citer : Posté le 10/10/2014 14:19 | #
Je me pose une question d'une importance capitale...
Dans l'hypothèse (non vérifiée) ou il est possible de repartionner la calto, je suppose qu'il est théoriquement possible de lancer FiXos en dual-boot, je me trompe ?
Je suis de l'autre coté de la manche maintenant. Yay.
Citer : Posté le 10/10/2014 17:26 | #
Il me semble que kristaba avait dit que ce serait la galère de partitionner un volume aussi petit
Coïncidence ? Je ne pense pas.
Citer : Posté le 10/10/2014 23:24 | #
1.4 Mo, c'est gigantesque, quelqu'un connait les disquettes pro en 512Ko ?
plus serieuxement, n'est il pas possible d en faire un volume ?
Je suis de l'autre coté de la manche maintenant. Yay.
Citer : Posté le 11/10/2014 08:25 | #
À mon avis c'est surtout difficile de le partitionner s'il y a déjà l'OS de Casio dessus. Et puis le bootloader (au secteur 0) ne permet pas forcément de lancer tous les OS... et si ça se trouve, l'OS natif est éparpillé sur toute la mémoire... sans compter la question du système à coller sur la nouvelle partition (même si la question de pose pas trop en fait
Tu le vois comment ça, toi ?
P.S.
Et puis, je te rappelle que la Flash fait 4 Mo... je doute qu'on puisse ne faire un volume que de l'espace utilisateur.
Citer : Posté le 22/10/2014 14:33 | #
Est-ce-que l'OS reprendras des fonctions toute faites de l'OS Casio avec le même interpréteur Basic ?
Citer : Posté le 22/10/2014 14:39 | #
plus puissant j'espere
-Mon Fall Down
-Mon jeu de mains
-Mon starwars
-Mon dessinatout
-Mon niaiseux version 2.0
-Mon niaiseux version 3.0
-Inferno
-Mon super labyrinthe (en cours)
-Mon call of duty en 3D
-Casion (avec Az)
Citer : Posté le 22/10/2014 15:35 | #
Le projet à la base, c'est surtout d'écrire un kernel.
Il me semble pas qu'ils aient dans l'immédiat l'intention d'écrire un OS.
Citer : Posté le 22/10/2014 16:10 | #
Un kernel ?
Citer : Posté le 22/10/2014 16:12 | #
Un noyau.
C'est-à-dire le morceau du système qui gère les périph's, les accès à la mémoire, les processus... je m'avance pas plus parce que j'ai pas envie de lâcher une bêtise, regarde sur Wikipédia pour plus d'infos.
Citer : Posté le 22/10/2014 16:19 | #
Ok, merci