Obligement - L'Amiga au maximum

Lundi 20 novembre 2017 - 01:03  

Translate

En De Nl Nl
Es Pt It Nl


Rubriques

 · Accueil
 · A Propos
 · Articles
 · Galeries
 · Glossaire
 · Hit Parade
 · Liens
 · Liste jeux Amiga
 · Quizz
 · Téléchargements
 · Trucs et astuces


Articles

 · Actualité (récente)
 · Actualité (archive)
 · Comparatifs
 · Dossiers
 · Entrevues
 · Matériel (tests)
 · Matériel (bidouilles)
 · Points de vue
 · En pratique
 · Programmation
 · Reportages
 · Tests de jeux
 · Tests de logiciels
 · Tests de compilations
 · Articles divers

 · Articles in english
 · Articles in other languages


Twitter

Suivez-nous sur Twitter




Liens

 · Sites de téléchargements
 · Associations
 · Pages Personnelles
 · Moteurs de recherche
 · Pages de liens
 · Constructeurs matériels
 · Matériel
 · Autres sites de matériel
 · Réparateurs
 · Revendeurs
 · Presse et médias
 · Programmation
 · Développeurs logiciels
 · Logiciels
 · Développeurs de jeux
 · Jeux
 · Autres sites de jeux
 · Scène démo
 · Divers
 · Informatique générale


Jeux Amiga

0, A, B, C, D, E, F,
G, H, I, J, K, L, M,
N, O, P, Q, R, S, T,
U, V, W, X, Y, Z


Trucs et astuces

0, A, B, C, D, E, F,
G, H, I, J, K, L, M,
N, O, P, Q, R, S, T,
U, V, W, X, Y, Z


Glossaire

0, A, B, C, D, E, F,
G, H, I, J, K, L, M,
N, O, P, Q, R, S, T,
U, V, W, X, Y, Z


Partenaires

Annuaire Amiga

Amedia Computer

Relec

Hit Parade


Contact

David Brunet

Courriel

 


Dossier : Histoire et spécifications de Tripos
(Article écrit par Stéphane Mayère et extrait d'A-News (Amiga News) - janvier 1990)


Lorsque j'ai acheté mon premier Amiga, il y a bientôt deux ans, j'ai été impressionné par la puissance du système d'exploitation. Ce système, à l'époque la version 1.2, était déjà, hormis quelques défauts de jeunesse, un OS (operating system) perfectionné et performant. Rappelez-vous en comparaison les versions 1.xxx de MS-DOS qui ne géraient pas de répertoires, pas de disques durs et des disquettes de 160 ko (quand on sait que DOS veut dire "Disk Operating System"...). Bref, on pouvait se demander pourquoi l'AmigaDOS était né majeur et qui était MetaComCo, société quasi inconnue qui l'avait créé. Nous verrons également en détail un point spécifique de l'AmigaDOS : la structure des fichiers. Mais tout d'abord...

Un peu d'histoire

MetaComCo est une société britannique, fondée en 1981 et basée à Bristol. Le premier produit de la société fut un interpréteur BASIC portable, écrit en BCPL, un précurseur du C. Cet interpréteur fut ensuite adapté pour le 8086 puis vendu à Digital Research Inc. Les redevances de ce BASIC permirent à MetaComCo de s'installer en Californie et de se faire connaître aux États-Unis.

En 1984, MetaComCo engage Tim King, un informaticien de Cambridge, et commence à s'intéresser au MC68000 que nous connaissons tous et sur lequel Tim King a travaillé depuis 1981. La société produit alors une série d'outils de développements écrits en BCPL : un éditeur, un macro-assembleur et un éditeur de lien. A ce moment-là, il n'y avait pas de système d'exploitation standard établi pour le 68000. MetaComCo décida donc d'en écrire un : Tripos était né.

Le système d'exploitation Tripos était basé sur un noyau multitâche développé à Cambridge en 1976 (c'est vieux...) dans le cadre d'une thèse de doctorat ("Tripos" est le nom familier donné par les étudiants aux examens de fin d'année de Cambridge). Tripos a été écrit en BCPL pour un DEC PDP-11 (mini-ordinateur 16 bits de la société Digital) et a été transformé par King en système d'exploitation multitâche utilisable sur ordinateurs 32 bits.

Tripos ressemble à Unix mais comporte pas mal d'innovations : nous verrons la structure des fichiers plus loin. MetaComCo a également acquis les droits du Cambrige LISP (qu'on retrouvera sur l'Amiga plus tard) développé au départ pour un IBM 370 puis adapté pour le 68000. La société développera un peu plus tard un compilateur Pascal.

Le DOS de trois semaines

L'histoire de l'AmigaDOS commence en novembre 1984. MetaComCo prend contact avec Amiga Corporation (qui venait d'être rachetée par Commodore) pour discuter de la vente de leur compilateur Pascal pour la nouvelle machine d'Amiga Corporation. Pendant ces discussions, il a été révélé que le système d'exploitation de l'Amiga était très en retard par rapport aux prévisions et posait des problèmes (les mauvaises habitudes commençaient... Wait and See pour la version 1.4).

Les spécifications d'Amiga pour le système d'exploitation du Lorraine (c'était le nom du prototype) étaient les suivantes :
  • Il devait être multitâche.
  • Il devait gérer les entrées/sorties synchrones et asynchrones.
  • Les entrées/sorties devaient être continues et indépendantes du matériel.
Toutes ces spécifications reprenaient les caractéristiques de Tripos que MetaComCo commencait à commercialiser sur machines 68000. Amiga accepta de tester le système dans le cas où leur propre OS (CAOS) ne fonctionnerait pas.

En février 1985, l'accord fut donné à MetaComCo et Tripos fut adapté sur le prototype de l'Amiga en trois semaines grâce à la portabilité du BCPL. La démonstration du système fut un succès, l'ancien OS d'Amiga (CAOS) fut abandonné et la conversion de Tripos en AmigaDOS commença. Heureusement pour MetaComCo, l'architecture interne de Tripos correspondait bien à l'architecture prévue pour l'Amiga. Tripos est organisé autour d'un OS classique, avec des commandes en lignes, des pilotes de périphériques, des annexes et des communications systèmes (pour les adressages de coprocesseurs, de périphériques...).

Les programmeurs d'Amiga avaient déjà les ROM contenant les routines d'annexage et les adressages des puces spécialisées, comme le Copper et le Blitter, qui gèrent l'animation, le graphisme et le son. L'équipe de MetaComCo intégra ces routines avec leur système d'entrées/sorties pour disques, fichiers, imprimantes, affichage ainsi que leur interpréteur de commandes pour en faire ce que nous connaissons sous le nom d'AmigaDOS.

L'équipe d'Amiga s'occupa de produire l'interface graphique Intuition, qui s'appuie sur l'AmigaDOS. MetaComCo s'occupa également de la mise au point du CLI comme d'une interface dédiée aux programmeurs et aux utilisateurs expérimentés. Les langages de programmation de MetaComCo furent également implémentés sur l'Amiga : Pascal, Lisp et BASIC.

Le noyau des systèmes - Tripos et AmigaDOS

Le système Tripos comporte quelques nouveautés par rapport à ce qu'on peut trouver sur d'autres OS de micro-ordinateurs, en particulier en ce qui concerne l'organisation des fichiers sur disque, et qu'on retrouve dans l'AmigaDOS. La plupart de ces idées nouvelles viennent de ce que Tripos était au départ un projet de recherche en informatique.

Tripos est basé sur un concept de tâches multiples et de communications. Quand une application (tâche) démarre, elle est informée du nombre des autres tâches qui tournent en même temps qu'elle. Chaque tâche possède donc un numéro. Notre application va donc pouvoir repérer les tâches dont elle a besoin pour communiquer avec les différents périphériques. Certaines de ces tâches sont, dans ce qu'on appelle en jargon informatique, en "hibernation" en attendant d'être "réveillées" par les différents programmes qui auront besoin d'elles. Il y a par exemple une tâche de "débogage" qui tourne perpétuellement, ce qui est un avantage terrible pour les programmeurs.

Tripos

Chaque périphérique est desservi par sa propre tâche. Toutes les tâches tournent en concurrence les unes par rapport aux autres ou, plus exactement, en pseudo-concurrence, car comme il n'y a qu'un processeur central, le 68000, chaque application dispose à tour de rôle des ressources qui lui sont nécessaires en envoyant et en recevant des messages (et oui, l'Amiga n'est pas encore une machine multiprocesseur à architecture parallèle, peut-être qu'avec les transputers...).

Si un programme nécessite 200 octets de stockage sur disque, il envoie un message à ce que j'ai appelé dans la figure la tâche fichier en lui demandant de lui allouer cette place sur le disque. La tâche fichier, de son côté, a son propre cache mémoire et va prendre un secteur (512 octets) dans cette mémoire cache, puis va rentrer en communication avec l'unité disque souhaitée qui a également son propre tampon mémoire (dans ce cas, des pistes sur le disque) et lui transférer ce secteur. De cette façon, toutes les pistes à écrire sont lues en une seule fois. La tâche fichier envoie alors un message au programme de départ pour l'informer que le stockage est maintenant possible (ça va plus vite à faire qu'à dire...).

Une des conséquences de ce système est que, contrairement à des systèmes simples comme MS-DOS ou le défunt CP/M, les accès disques peuvent se faire apparemment aléatoirement sans que l'utilisateur n'intervienne.

La seule limitation au nombre de tâches simultanées est la mémoire disponible, puisqu'il n'y a pas de système de mémoire virtuelle : une mémoire virtuelle utilise temporairement les mémoires de masse (disques) en attendant que la mémoire soit de nouveau disponible. Apple s'y met avec le nouveau système 7.0 du Macintosh, alors monsieur Commodore, et cette version 1.4 ! Pour pallier à cet inconvénient, un système de code partageable est utilisé pour minimiser la place mémoire lors d'appels multiples à des tâches similaires. On peut donner différentes priorités aux tâches, ceux qui ont été fouiner dans la liste de montage (mountlist) s'en seront rendu compte, et chaque application, programme, etc. peut être exécutée en tâche de fond avec la commande "Run <nom de programme>".

Le CLI ou le Shell sont des tâches également, on peut donc en invoquer autant qu'on veut. L'interface système de communication et de message est très semblable à Unix et est identique pour les périphériques et les applications ; elle comporte des messages de type Open, Close, Read, Write, Seek (Ouvrir, Fermer, Lire, Écrire, Chercher).

La structure des fichiers sur le disque

C'est sur le terrain de la structure des fichiers sur disque que Tripos est radicalement différent. Pour commencer, il n'y a pas de pistes de répertoires sur un disque Tripos, et en fait il n'y a pas de répertoire du tout dans le sens habituel de table de nom de fichier. D'ordinaire, un répertoire contient des pointeurs vers des noms de fichiers. A la place Tripos utilise un "Root Block" qui est placé au centre du disque, généralement sur la piste 0. Ce Root Block (ou secteur racine, je garde volontairement les termes anglais pour ceux qui bidouillent avez les éditeurs de piste et de secteurs...) contient le nom du volume ainsi que les dates de création et de dernière modification.

Vient ensuite la "hash table" (table de vérification) par laquelle les fichiers ou les noms de sous-répertoires sont transformés en numéros de secteurs. Chaque secteur ainsi pointé peut donc être un fichier ou un répertoire conduisant à une structure arborescente comme on peut en trouver sous Unix ou MS-DOS. Il peut se produire des collisions : supposons que les deux fichiers "Chorizo_Kid" et "El_Yéti" soit contrôlés par le même secteur. Des secteurs d'extension vont être chaînés sous le secteur de vérification, et la collision sera évitée en chaînant les fichiers !

Tripos

Les sous-répertoires ont la même structure que le secteur racine, alors que les entêtes de fichiers contiennent le nom du fichier, la date, ses attributs (S,H,P,A,R,E,W et D) et une table comportant le nombre de secteurs de données du fichier. La taille d'un secteur est fixée à 512 octets en AmigaDOS (1024 octets sous le système Tripos). Quand un entête de fichier déborde de la place allouée par la table, il se raccorde à un secteur d'extension selon le principe décrit plus haut.

Pour optimiser la vitesse d'accès aux données, les entêtes de fichiers et les sous-répertoires sont assignes d'un côté du Root Block, et les blocs de données de l'autre côté. Ainsi, les secteurs consécutifs d'un même fichier sont regroupés ensemble.

Tripos

Ce système a plusieurs avantages, comparé aux systèmes d'exploitations plus conventionnels. En particulier, il n'y a de limite à rien : les fichiers sont régis par la seule capacité de stockage du disque. De plus, il n'y a pas de distinction entre les fichiers binaires et les fichiers ASCII, car ils ne contiennent pas d'indicateurs de fin de fichiers comme les Ctrl-Z sur d'autres systèmes. Du point de vue du disque, tous les fichiers sont identiques : juste des secteurs de "matière".

Il y a encore plus fort (si, si...). Tous les secteurs constituant un fichier contiennent des pointeurs vers le prochain secteur en ligne (pour un meilleur accès séquentiel) et également un pointeur de retour vers le secteur d'entête de fichier. C'est une trouvaille géniale car même si un entête de fichier est complètement détruit, on peut le reconstruire complètement en lisant ces fameux pointeurs de retour contenus dans les secteurs de données : les secteurs de données contiennent chacun leur propre "carte d'identité". Le diskdoctor du DOS permet selon ce principe de reconstruire complètement et automatiquement un disque, fichiers et répertoires, et ce à presque tous les stades de détérioration.

Tripos

Ce type de stockage est un grand pas en avant dans la sécurité des mémoires de masse comparé à MS-DOS par exemple, où la destruction d'une piste d'un répertoire peut conduire à la perte définitive des données. En contrepartie, le seul défaut imputable au système de l'AmigaDOS est sa lenteur lors des listages de répertoires, et des opérations sur les fichiers en général. En effet, il n'y a pas de FAT (File Allocation Table), c'est-à-dire pas d'endroit unique auquel se référer pour chercher un fichier, toute l'arborescence du disque doit être parcourue pour trouver le nom cherché. On voit désormais, avec le multitâche et les temps d'accès disque assez imprévisibles, la nécessité de traiter les disquettes, en particulier lors des changements, avec beaucoup de douceur !

Tripos (et donc AmigaDOS) garde en mémoire une représentation de l'utilisation du disque (une sorte de FAT donc...) qui comporte un bit pour chaque secteur utilisé. Comme on l'a vu au début (si vous ne l'avez pas oublié !) chaque tâche fichier a son propre tampon en mémoire, et après chaque accès disque, il y a une période de deux à trois secondes pendant laquelle la tâche scrute son tampon mémoire et met à jour le disque d'après sa représentation en mémoire.

Si le disque est enlevé pendant ces quelques secondes (ce que tout le monde a déjà expérimenté au moins une fois), la mise à jour du disque (qui n'est plus là, je le rappelle car j'en vois qui dorment dans le fond) est invalidée, une requête système apparaît et quand le disque est réinséré, une tâche de validation va automatiquement être invoquée pour reconstruire la représentation du disque en mémoire. En fait, la seule façon de perdre de l'information est de retirer un disque quand le lecteur est en train de tourner. A ce propos, il a été question pendant un temps d'avoir un système d'éjection logicielle comme sur le Macintosh d'Apple, mais l'idée a été abandonnée.

L'AmigaDOS reconnaît une disquette par son nom de volume et peut donc la retrouver dans n'importe quel lecteur, ou, demander son insertion dans n'importe quel lecteur. Il est également possible d'enlever un disque avec un fichier encore ouvert, d'utiliser un autre disque, de replacer le premier, et de retrouver le fichier dans le même état. Comme sous Unix, les périphériques sont adressés comme des fichiers, avec un nom de périphérique remplaçant le nom de volume dans les commandes. Par exemple, le périphérique CON: peut être suivi des paramètres : "CON:20/20/100/100/MaFenêtre".

Les sorties série et parallèle peuvent être adressées de la même manière.

C'est fini

Voilà la petite histoire de l'AmigaDOS. On peut comprendre sa maturité et ses innovations techniques par le fait que Tripos existait déjà depuis près de 10 ans à la sortie de l'Amiga et qu'il était issu d'un projet de recherche.


[Retour en haut] / [Retour aux articles]