[Le projet OS-9] OS9 sur TO9p

[jb_jb_fr]

Bonsoir à tous

Je suis heureux de vous faire part que OS9 sur TO9+ est enfin opérationnel.
J'ai beaucoup rammé ces temps ci car je me suis battu contre le 6846.
Je n'avais pas compris qu'il y a un bit qu'il faut absolument mettre à 0 pour pouvoir accéder aux registres du port
Et puis après c'est avec le driver de disque virtuel avec lequel je me suis battu.

Mais tout est rentré dans l'ordre, et ça marche super bien.

Pour ceux que ça intéresse, je mets ici les 3 ROM du TO9 qui permettent de faire tourner OS9
- La ROM IW12, contient le Noyau d'OS9, la table ASCII d'affichage, et 2 petit programmes pour checker les IRQS utilisées, et les Driver chargés dans le noyau
- La ROM IW13 contient dans sa partie basse (16 1er Ko) tous les driver OS9 (SCF, RBF, IOMAN, CLOCK, SYSGO INIT) et des commandes de base avec le shell bien. sur.
Les 16 autre Ko contiennent le début du disque virtuel (/R1)
- La ROM IW14 contient les 32 derniers Ko du disque virtuel

Grâce a tout çà on est capable de se logger, et d’exécuter des commandes OS9.
Il est également possible de lancer un 2eme process de login sur le terminal série qui utilise le module Thomson RF57932 (a base de MC6551) (pour lancer le process il suffit de faire : tsmon /ts & )

Bien sur je vais continuer d'améliorer certaines commandes d'OS9 (l'éditeur par exemple qui n'est pas vraiment au point) et surtout je vais enfin pouvoir me remettre à mon projet favori : Faire une tête de NanoReseau a base de TO9+ + OS9

Jacques

[Totor le Butor]

Chapeau bas, j'en reste sans voix

[__sam__]

Je suis heureux de vous faire part que OS9 sur TO9+ est enfin opérationnel.

Bravo, félicitations!

Aurais tu une vidéo où l'on voit tout ça fonctionner ?

[jb_jb_fr]

Merci

Non, je n'ai pas de vidéo.
Par contre, je peux mettre des screens shot.
Car bien sur j'utilise énormément XEmul56 qui me permet de faire tous mes tests avant de griller un ROM

[jb_jb_fr]

Voila quelques aperçus des commandes

1ere étape : le login

Login_os9.jpg (63.85 Kio) Consulté 7408 fois

Commandes disponible sur le disque virtuel

comandes_sur_r1.jpg (68.89 Kio) Consulté 7408 fois

Formatage du RAM disque

format_r0.jpg (71.78 Kio) Consulté 7408 fois

[__sam__]

Waou, le mode 80cols rend bien. Un editeur pleine page dans ce mode serait super.

Un vieux projet de Fabrice Bellard etait un clone emacs tout petit: http://bellard.org/qemacs/. Je presume que c'est trop gros pour to9p (un process peut "voir" combien de ram contiguë?)

[Papy.G]

Excellent tout ceci!
Quels sont les paramètres de terminal série pris en charge?

[jb_jb_fr]

Un vieux projet de Fabrice Bellard etait un clone emacs tout petit: http://bellard.org/qemacs/. Je presume que c'est trop gros pour to9p (un process peut "voir" combien de ram contiguë?)

Il existe déjà sous OS9-6809 un éditeur qui s'appel uemacs pour Micro-emacs.
Il est également dans mes projets de le faire fonctionner.
J'ai déja essayé, mais le probleme est qui est prévu pour OS9-Level II
Et pour l'instant nous n'avons que OS9 Level I

Donc faudra attendre encore

Quels sont les paramètres de terminal série pris en charge?

Pour paramétrer le terminal série tu peux passer par la commande XMODE:

Code : Tout sélectionner

OS9:xmode /TS
 nam=TS mgr=SCF ddr=mc6551 hpn=00 hpa=E7E8 upc=00 bso=00 dlo=00
 eko=01 alf=01 nul=00 pau=00 pag=19 bsp=08 del=18 eor=0D
 eof=1B rpr=04 dup=01 psc=17 int=03 qut=05 bse=08 ovf=07
 par=00 bau=07 xon=00 xof=00 col=84 row=32

Tu peux ainsi choisir les différentes vitesses : de 50 bauds à 19200 bauds
Choisir 5,6,7,8 bits
Parités: paires, impaires, sans, Mark ou Space.
Tu peux également choisir le nombre de ligne de ton écran pour que OS9 fasse une pause automatiquement
Le protocole XON/XOFF n'est pas géré

[Fool-DupleX]

@Jacques : un dir e aurait été encore plus impressionnant qu'un dir x ...

J'ai été le témoin privilégié des développements de Jacques ces derniers deux mois et le boulot qu'il a abattu est assez formidable. La gestion des pages de ROM et de RAM avec le gate-array MO6/TO8/9+ est un véritable casse-tête et la mise au point du noyau pour le TO9+ a été coton. C'est lui qui a tout fait et il est passé par plusieurs moments d'abattement et d'agacement. Mais au final le résultat est là et il est magnifique.

On nous a reproché de ne pas communiquer assez et cette critique est fondée. Comme je lui ai suggéré en privé, je propose, avec l'accord des modérateurs du forum, que ce fil de discussion devienne le lieu officiel de notre communication sur le projet os-9. Qu'en pensez-vous ?

[__sam__]

Il existe déjà sous OS9-6809 un éditeur qui s'appel uemacs pour Micro-emacs.
Il est également dans mes projets de le faire fonctionner.

Ah je le connais celui-là: il était livré sur l'une des diskettes systèmes de mon Amiga500

J'ai déja essayé, mais le probleme est qui est prévu pour OS9-Level II
Et pour l'instant nous n'avons que OS9 Level I

Donc faudra attendre encore

En effet.

Peux tu en dire plus sur les aspects technique de cet OS: les programmes peuvent voir et occuper combien de mémoire sur to9+ ? Est-ce l'OS qui fournit des points d'entrées pour appeler une routine située dans une autre banque ram ? etc.

[Papy.G]

jb_jb_fr> Ca supporte donc à peu près tout type de terminal du moment qu'on peut afficher 80 colonnes.
Quand tu dis "nous n'avons que OS9 Level I", il s'agit du code/sources, ou de l'autorisation de travailler dessus?
Tu auras à tout refaire, ou seules quelques parties seront différentes et nécessiteront des adaptations?

Fool-Duplex> Le travail accompli par certains contributeurs de ce forum semble tellement naturellement fait qu'on en oublie souvent la complexité du truc. Il est compréhensible de ne pas toujours avoir eu le temps ni l'envie, selon les moments, de communiquer, et les simples spectateurs curieux et impatients que nous sommes ne vous en tiendrons pas rigueur, mais devrions plutôt nous excuser de vous avoir bousculé.
Bien que ces deux projets soient intimement liés pour vous, le NR n'intéressant pas forcément autant de monde, faire ce sujet dédié à OS9 apportera plus de lisibilité, bien évidemment.
Doit-on rapatrier les réponses de l'autre fil ici? (Je ne sais pas comment l'antériorité des messages sera supportée, de toutes façons, seul Fabien peut le faire)

[jb_jb_fr]

Actuellement, la version OS9 Level I, ne sait gérer que 64Ko à plat.
Donc, un fois les IO, Vidéo, et Rom retiré, OS9 ne voit que 32 Ko de RAM ($6000-$DFFF)
Sur ces 32 Ko, il faut retirer toutes les variables OS qui vont de $6000-$64FF
Il ne reste donc plus que 31488 octets
Et toute cette ram est visible par tout le monde.
Des qu'un process est lancé, la table de ram est mise à jour en fonction de la demande du process.
Donc plus les process sont gourmand en mémoire et moins on peut en lancer
Ce qui est normal

Sachant que OS9 ne gère pas la mémoire par octets mais par page de 256 octets, on peut au mieux lancer 123 process en même temps

J'ai commencé à regarder le fonctionnement de OS9 Level II.
Effectivement il y a une gestion des pages mémoires, que l'on pourrait essayer d'adapter aux différentes pages mémoires du TO9
Mais c'est super compliqué, et pour l'instant j'ai abandonné.
Peut-être un jour si j'ai rien d'autre à faire.

Mais en regardant cette gestion de la mémoire dans OS9 Level II, j'y ai vu 2 point noir :
- Une augmentation non négligeable de la taille du noyau (par exemple pour le MO5/MO6, ca ne tiendrait plus entre F000-FFFF. Ce qui est ennuyeux car c'est tout de même un zone qui ne switch pas).
- Un ralentissement de OS9, car il y a beaucoup plus d'opération et surement beaucoup de switching inter process. On retrouverait la joie de Windows et son switching à donf. Et pour notre pauvre machine à 1MHz, je trouve que c'est bête.
OS9 Level II a été adapté pour le COCO 2 et 3, qui sont des machines plus performante que nos pauvre petit Thomson.

Jacques

[jb_jb_fr]

Quand tu dis "nous n'avons que OS9 Level I", il s'agit du code/sources, ou de l'autorisation de travailler dessus?

Pour ce qui est de l'utilisation, nous avons les autorisations. FollDuplex c'est renseigné auprès de Microware/RadiSys, et il a obtenue l'accord.
Donc de ce que coté pas de soucis

Pour les sources, je me référence au site de Nitros OS9, ou dessus il y a vraiment tout en libre accès.
Et donc j'ai également récupéré le Noyau de OS9 Level II

Jacques

[Papy.G]

Comment est géré le multi-tâche? On ne peut pas envisager de n'avoir qu'un pointeur dans la mémoire principale, qui switche le bloc nécessaire à l'accès à son code, et qui remet le bloc principal avant de rendre la main? Les interruptions lancent elles-même des process et ne pourraient alors se dérouler normalement? (Et un retour au bloc principal avec mémorisation du bloc courant ralentirait sans doute trop celles-ci)

Ok, donc la complexité du Level II ne serait ni nécessaire ni appropriée aux limites matérielles de MO5/MO6.

[Fool-DupleX]

Le pape du micro-noyau d'os-9 c'est Jacques. Ce que je sais pour ma part, c'est que le noyau gère préemptivement les tâches et s'occupe du context switching. Le mo5 ne dispose que d'une clock fixe à 50 Hz, chaque process dispose donc d'environ 20 ms à tour de rôle. Les tâches peuvent être sleeping/idle. Dans ce cas, elles ne consomment pas de CPU. Une tâche qui attend sur le clavier par exemple, ne va pas betement tourner en boucle, elle demande à l'os de scruter le clavier et le noyau lui rendra la main quand la touche sera pressee. Durant l'intervalle, d'autres taches vont s'executer et celle qui attend la touche ne consommera pas de cpu. Sur TO, la préemption est cadencée par le 6846. On peut donc programmer le slice à autre chose que 20 ms.

Le noyau fournit des services tres interessants comme le timing et les virq. virq = interruption virtuelle, soit une interruption déclenchée logiciellement à intervalle régulier ou sur un event soft. Nous avons utilisé une telle virq pour le clavier sur le mo5, car celui-ci n'a pas d'intelligence ; il faut scruter les lignes de la matrice. Une conséquence intéressante est que grâce à ce mécanisme, il y a un buffer clavier, puisque la virq scrute régulièrement les lignes et stocke les touches en attendant que le gestionnaire de flux les dispatche vers les processes. Sur un Thomson "normal", quand le cpu travaille a autre chose, le clavier ne repond pas.

Le noyau distribue aussi la mémoire et il y a notamment un puissant mécanisme, le gestionnaire de link, qui décide automatiquement s'il est nécessaire de charger certains modules en mémoire en fonction des besoins. Par exemple si je veux lire le disque /d0, os-9 va chercher le descripteur de périphérique correspondant dans sa table de modules et charger le pilote à la volée, si celui-ci n'est pas déjà actif en RAM. Mieux : si le module est present en ROM, il ne le charge pas en RAM, mais va executer depuis la ROM. Lors de l'init du module, le noyau va allouer la place necessaire en RAM pour les variables pour le bon fonctionnement du code en ROM. Tout ceci de manière totalement transparente pour l'utilisateur. On peut comparer ca avec les insmod/modprobe/lsmod etc. de Linux.

Les utilisateurs de Linux ne seront pas depaysés sous os-9, ex de commandes dans le shell :

- procs est equivalent de ps
- link/unlink equivalent de insmod/rmmod
- dir equivalent de ls
- chd = chdir, makdir = mkdir, rmdir = rmdir ...
- & pour lancer en tache de fond, > et | pour les pipes, tous les peripheriques sont accessibles par un chemin e.g. /d0 pour la disquette, /t0 pour la fenêtre d'affichage principale ...
- attrb equivalent de chmod
- et j'en oublie.

Toutes ces notions sont terriblement banales sur un OS moderne, mais on peut dire que sur Thomson, c'eût été révolutionnaire à l'époque. D'ailleurs, le prototype de TO16 à base de 68000 tournait sous OS-9/68K ; C'est un petit peu comme si Thomson avait sorti une machine grand public tournant Linux en 1987.

OS-9 Lvl II est effectivement beaucoup plus complexe. Selon moi, il ne se justifie pas sur un MO5 ou un TO9+. Mais OS-9 Lvl I a un handicap de taille, il n'a pas la notion de mémoire par banque. Globalement, avec OS-9 Lvl I sur mon MO5 dans son état actuel, je peux faire 100 fois plus de choses qu'avec le BASIC de Microsoft, mais je suis limité à 32 Ko de RAM et c'est malheureusement aussi le cas sur le TO9+, alors que ce dernier possède physiquement 512 Ko.

La solution qui semble la plus simple a ce probleme serait de rétroporter le mécanisme de gestion mémoire d'OS-9 Lvl II vers notre variante d'OS-9, mais ca reste d'une complexité folle.