omega/oSDK - un (autre) unikernel pour Graph 90+E
Posté le 24/03/2024 23:15
Pour programmer sur les calculatrices Casio, la solution la plus simple a souvent été le Basic Casio. Bien que très utilisé au cours du temps - et Planète Casio en est un bon exemple -, c'est un langage vraiment lent, et plutôt pauvre en possibilités. La solution du Python s'est incorporée progressivement : c'est mieux, mais pas idéal.
Enfin, il a - quasiment - toujours été possible d'utiliser le SDK de Casio. Ce SDK - kit de développement - permet de développer des add-ins, c'est-à-dire des applications natives.
Mais en 2015,
Lephenixnoir crée sa propre solution :
gint, et son acolyte
le fxSDK. Permettant toujours de programmer des add-ins, c'est aujourd'hui la solution la plus répandue.
C'est ici que j'arrive. Fin 2023, je regarde le code de gint de près : je me découvre un intérêt pour la programmation bas niveau et la compréhension de ce genre de systèmes. C'est donc dans l'optique de toucher ça d'un peu plus près que je me lance dans omega.
Mon but n'est pas de concurrencer gint - je n'en ai ni l'envie ni les capacités - : je veux simplement m'amuser et découvrir des choses.
omega est un
unikernel. Cela veut dire qu'à l'intérieur de chaque add-in réalisé avec omega, se trouve le kernel qui le lance. Le but est de ne pas utiliser l'OS de Casio, et de créer le nôtre, en quelque sorte. Ce fonctionnement est aussi celui de gint.
Avec omega vient l'oSDK, mon kit de développement.
Les sources sont sur le
dépôt git d'omega ainsi que sur le
dépôt git du oSDK
Principales fonctionnalités
omega est actuellement en cours de développement. Voici une liste des principales fonctionnalités gérées :
- Driver de l'écran, fonctions basiques de dessin et de texte (printf-like, fonctions de dessins de ligne/rectangles...) ; avec, bien sûr, mise en place d'une VRAM
- Conversion d'images .png - oconv - et fonctions d'affichage de ces images
- Gestion basique du clavier : keydown() et keypressed() actuellement
- Gestion des interruptions : je gère les interruptions, les exceptions (souvent appelées System ERROR) et les interruptions du TMU
- Gestion de timers : possibilité de gérer 3 timers en simultané, ce qui est surtout utile pour garder un nombre constant de FPS (possibilité d'attendre la fin d'un timer)
Installation du oSDK et d'omega
Il est nécessaire au préalable d'installer sh-elf-gcc et sh-elf-binutils via
GiteaPC.
Compilons et installons ensuite omega :
% git clone https://git.planet-casio.com/Potter360/omega/
% make
% sudo make install
Enfin, installons l'oSDK :
% git clone https://git.planet-casio.com/Potter360/osdk
% chmod +x install.sh
% ./install.sh
Et voilà ! On peut maintenant créer un nouveau projet avec :
% osdk new [<nom du projet>]
Démonstration(s)
Il n'existe pour l'instant pas de démonstration. J'aurai pu joindre quelques photos d'un projet minimal (texte, image) créé avec omega, mais je préfère attendre d'avoir un "vrai" jeu ou projet codé avec omega. J'en profite pour dire que si ça vous tente d'utiliser omega pour votre prochain projet, ce serait avec plaisir !
En attendant quelques projets arrivent...
stay tuned !
Citer : Posté le 24/03/2024 23:28 | #
Hey, extrêmement cool, bien joué d'avoir poussé le projet de pouvoir l'annoncer ! On n'y arrive pas tous les jours
En question un peu concrète, pourquoi avoir choisi de découper Omega et oSDK en deux dépôts plutôt qu'un ? Tu comptes rendre l'oSDK utilisable avec d'autres projets, par exemple gint, ou est-ce que ça ne vaudrait pas le coup de merge les deux pour pouvoir par exemple proposer directement un oSDK imbriquant Omega dans l'exécutable pour une installation plus facile ?
De mon point de vue de non partie prenante au projet, bien que je ne doute pas qu'il s'agisse d'un projet super intéressant pour toi, je trouve ça un peu dommage de juste viser le gint bis en moins optimum. Est-ce que ça ne vaudrait pas le coup de viser une autre direction, par exemple mettre en place un userspace avec un multiprocessing pré-emptif et un IPC un peu innovant, ou mettre en place le bare minimum en C/asm pour faire tourner un système entièrement dans un autre langage type Lua, Python, ou même FORTRAN (ok je suis peut-être un peu warpé par mon expérience de thox) ? Ou viser le remplacement de l'OS de CASIO pour avoir un système davantage tourné game station que calculatrice, juste pour qu'on atteigne enfin le niveau de la communauté de TI qui a fait KnightOS ?
Mon blog ⋅ Mes autres projets
Citer : Posté le 24/03/2024 23:36 | #
Hey, merci pour ton retour !
Pour la première question : well, je trouvais ça plus simple en fait x)
Dans l'état actuel je suis totalement d'accord la distinction est plutôt floue, mais mon but est d'incorporer le build directement dans osdk, avec une commmande du style osdk build (au lieu du make actuel) - comme le fxSDK peut le faire.
Pour la deuxième question, je suis totalement d'accord avec toi. Mon idée est de commencer par l'étape actuelle - gint bis en moins optimum - et ensuite de me spécialiser quelque part. Je n'en ai pas parlé dans le topic parce que je ne sais pas encore vers quelle direction j'irai ; cependant le remplacement de l'OS me tente bien, il faudrait que je me penche sur la façon dont cela se fait techniquement. Mais en tout cas oui, le but du projet n'est pas de stagner en tant que "gint en moins bien".
Citer : Posté le 25/03/2024 12:47 | #
Palalala qu’est-ce que ça fait plaisir de voir des projets comme ça arrivé !
Loin de moi de vouloir signaler ma vertue, mais peut-être que mon petit retour d'expérience pourrait t’aider à ne pas te retrouver dans la même situation que moi.
J’avais tenté un projet similaire il y a quelques années, ce qui a abouti a pas grand-chose de concret fautes a beaucoup, beaucoup d’erreurs qui, pour une grande majorité d’entre elles, n'était pas technique.
N'oublie pas que l’architecture visée (SuperH) n’est plus d’actualité aujourd’hui et que l’utilisation des calculatrices en mode “hack” a perdu de son souffle. Ce que j’essaie de dire ici, c’est que, quand j’explique à quelqu'un que je développe des kernels pour calculatrice, on ne me prends pas au sérieux (et dit toi que je travaille dans une école de cybersécurité). Et ça peut être assez déroutant au début quand on sort la tête du guidon (et oui, ça prend énormément de temps d'écrire un kernel), mais la réalité est ce qu’elle est : on développe sur du matériel obsolète, ce qui implique que nos connaissances sont obsolètes. Vois ce genre de projet comme “Je vais apprendre à parler couramment latins”...c’est stylé…mais inutile dans la majorité des scénarios.
Essaie vraiment de te fixer un objectif final (exemple : lancer un executable ELF), et avance petit pas par petit pas. Je vois sur la shout que tu prévois de vouloir écrire un OS qui remplacera celui de Casio ce qui peut être parfaitement accessible, mais il y a beaucoup de problème à résoudre avant (au piff, pouvoir mettre a jours ton OS de test ce qui implique soit un moyen de flasher facilement la ROM, soit un driver USB suffisamment évolué pour t’”auto-remplacé” (ce que fait Casio)). Honnêtement, je t’invite a lire le chapitre 5 du livre “The mythical Man-Month” appelé “The Second-System Effect” pour éviter de voir trop gros trop vite.
Et le dernier “conseil”, qui est enclavé au paragraphe précédent, serait de ne pas chercher à sortir de l’ombre de Gint trop vite. Pour le coup, ce projet couvre excellemment la majorité du matériel et des concepts techniques très poussés (comme les world-switch par exemple) et si tu veux pouvoir sortir des pas de Gint, il faudra d’abord réussir à couvrir autant de matériel qu’il le fait avant de pouvoir ce dire d’aller dans la conception d’un OS (et oui, Gint ne fait "rien d'autre" que de fournir des drivers, hors c'est la base d'un OS) (D'ailleurs, pour l'histoire, je me suis cassé les dents sur mon premier OS parce que j’ai absolument voulus faire autre chose que ce que faisais Gint et j’ai implémenté le multi-processus en hâte. Sauf qu’ajouter le fait de pouvoir exécuter plusieurs entités à la fois sur la machine demande que les drivers soient capable de le supporter, ce qui n’etais pas le cas, car j’avais jamais pensé a ca).
J’essaie absolument pas de te démotiver avec ce post, mais juste pour te mettre en garde que ce type de projet peut vraiment être très compliqué.
Dans tout les cas, j'ai hate de voir l’évolution du projet !
NdA: (Bon, j'aime pas du tout le ton du message, j’espère que ca ne sera pas mal pris, mais j'ai plus trop de temps pour polir le message o(x_x)o)
Citer : Posté le 25/03/2024 21:25 | #
Hello, retour d'expert !
Tu as totalement raison pour le fait que l'architecture visée n'est plus reconnue aujourd'hui, et je suis - plus ou moins, je ne pensais pas à ce point là quand même x) - conscient du fait que mes (futurs) travaux sur omega ne seront pas réellement reconnus.
Mais en vrai, j'avoue que c'est pas ma priorité. Je suis assez jeune pour ce genre de projets, donc mon but actuel n'est pas de le faire pour une quelconque reconnaissance scolaire ou pro - j'ai juste envie de m'amuser, en découvrant les facettes sombres de ce genre d'architectures x).
Pour l'objectif, ouaip bien sûr je vais resserrer. Je parlais sur la shout du remplacement de l'OS comme un goal à vraiment long terme, mais pour l'instant j'ai des buts plus "petits" : gérer un peu le système de fichiers, l'USB...
Au passage, merci pour la réf du livre ! Je vais lire ça
Enfin, pour gint, oui tu as raison. Je vais rester dans les "pas" de gint au moins jusqu'à avoir quelque chose de vraiment complet.
Le problème c'est que j'ai parfois l'impression de trop m'inspirer de gint... j'ai peur que ce soit trop visible dans mon code, et mon but est évidemment pas de plagier gint... donc j'avoue que je suis un peu embêté par rapport à cela.
En tout cas merci pour tous ces conseils ! C'est vraiment de l'or d'avoir un retour d'une personne qui est déjà passée par là.
NdA : ahah t'inquiète pas j'avais compris pour le ton ! Je ne l'ai pas ressenti d'une mauvaise manière.
Citer : Posté le 09/04/2024 15:18 | #
Oplà, @RDP si c’est pas trop tard.