FR 2528595 A1 19831216 FR 8210412 A 19820615 L'invention concerne les périphériques de calculateur du genre terminal de visualisation. On connaît déjà un terminal visuel comportant un écran, du genre écran cathodique, une mémoire dynamique de codes de caractères à visualiser, un circuit de commande de visualisation, capable d'exciter l'écran pour y faire apparaître des caractères correspondant aux codes, ainsi que des moyens de traitement local qui vont remplir la mémoire de codes de caractères selon des informations venues du calculateur "hôte" éloigné, et aussi agir sur le circuit de commande de visualisation pour coordonner la visualisation de ces caractères à l'intérieur du cadre de l'écran compte-tenu du balayage de celui-ci. I1 est connu d'effectuer une visualisation "multi-fenêtres" sur un terminal, mais à partir d'un logiciel assez lourd se trouvant dans la calculaeteur hôte, En plus de l'inconvénient dû à la capacité de mémoire mobilisée à cet effet dans le calculateur hôte cette façon de faire est peu souple, car il faut réécrire le logiciel dans le processeur hôte et l'adapter aux caractéristiques de l'écran sur lequel on veut visualiser. Un des buts de la présente invention est de fournir un terminal visuel capable de lui-même d'une visualisation multi-fenêtres. Un autre but de la présente invention est de permettre la visualisation au choix, en un même emplacement de l'écran, d'une fenêtre ordinaire ou d'une fenêtre-événement, cette dernière correspondant généralement à des informations incidentes qui remplacent les informations normales. L'invention a également pour but de permettre des manipulations des caractères à l'intérieur de la ou des fenêtres, ou des manipulations de zones de caractères, afin de permettre un traitement de texte et/ou une visualisation en "vidéotex", en ajoutant éventuellement un clavier au terminal. D'une manière générale, le terminal selon l'invention est remarquable par le fait que, le format nominal d'écran comportant m.q lignes de n.p caractères chacune, la mémoire de codes de caractères est adressable selon des blocs de n codes de caractères chacun, par le fait qu'il est prévu une mémoire de pointage topographique apte à désigner m.p.q. blocs dans la mémoire de codes de caractères, en correspondance avec une décomposition de chacune des m.q lignes de l'écran en p pavés de n caractères consécutifs chacun, et que les moyens de traitement local possèdent un premier état où la visualisation réunit les m.p.q pavés dans un cadre égal au format de l'écran, et un second état où est désignable au moins une fenêtre ordinaire comprenant au moins un pavé, et assimilable à un écran indépendant. Selon une caractéristique additionnelle, très avantageuse, de l'invention, la mémoire de codes de caractères contient m.p.q+r blocs de n codes de caractères, que la mémoire topographique peut désigner au choix ; la mémoire de travail comporte une zone formant carte de pointage apte à désigner seulement les m.p.q blocs de codes en correspondance avec les m.p.q pavés de l'écran, et une zone formant carte de présence d'événement comprenant, pour chacun des m.p.q pavés de l'écran, un bit qui est 'zéro' ou 'un' selon que la carte de pointage et la mémoire topographique indiquent ou non le même bloc de codes de caractères pour ce pavé, ce qui permet de visualiser des fenêtres-événements substituables réversiblement au contenu de l'écran dans la fenêtre ordinaire oorrespondante. D'autres caractéristiques et avantages de l'invention apparaîtront à la lecture de la description détaillée qui va suivre, ainsi qu'à l'examen des dessins annexés, sur lesquels - la figure 1 est une vue générale illustrant le branche ment d'un terminal sur un calculateur éloigné - la figure 2 est le schéma électrique de principe du terminal selon la présente invention - la figure 3 est un organigramme illustrant le fonc tionnement général du terminal selon l'invention ; - la figure 4 est un autre organigramme illustrant le fonctionnement particulier du terminal selon l'inven tion dans l'un de ses modes de travail - les figures 5A et 5B illustrent le travail de la mémoire topographique et de la mémoire de codes de caractères incorporées au terminal selon l'invention; et - les figures 6A à 6C illustrent le travail de trois mémoires incorporées au terminal selon l'invention. Sur la figure 1, un calculateur éloigné, que l'on appellera calculateur "hôte", noté CE, est relié par une ligne à un terminal de visualisàtion, constitué d'un écran cathodique TC, de moyens électroniques de traitement local notés MTL, et avantageusement d'un clavier CLD. La figure 2 illustre de manière plus détaillée la constitution des moyens de traitement local MTL. Ceuxci s'articulent autour d'un microprocesseur local MP, qui communique avec un bus d'adresse BADR, avec un bus de données BDAT, ainsi qu'avec un bus de contrôle BCONT. L'électronique de traitement MTL comprend en outre une mémoire de travail dynamique notée RAM, de capacité 32KOcts, deux mémoires de programme notées ROM et ROM 1, de capacité chacune 4K Octets, deux organes de liaisons asynchrones UART et UART 1, communiquant respectivement par des interfaces avec le clavier CLD et le calculateur éloigné CE. Les liaisons peuvent être du type connu dans la technique sous la dénomination V24. En partie basse de la figure 2, il s'y ajoute un circuit-de commande de tube cathodique CRTC, une mémoire topographique TOPO, une mémoire de caractères MCAR, une mémoire morte de caractères CAROM, ainsi qu'un circuit logique d'écran LTC, et un circuit de décalage DECL, interposé directement entre la mémoire morte de caractères CAROM et la logique d'écran LTC. De manière connue, la logique d'écran LTC est agencée pour fournir à l'écran cathodique TC deux lignes d'informations vidéo notées VIDEO 1 et VIDEO 2, ainsi qu'une ligne de synchronisation verticale et une ligne de synchronisation horizontale. Le bus d'adresse BADR est connecté à un décodeur d'adresse DA, capable de définir l'adressage global de chacun des constituants, à savoir la mémoire dynamique RAM, la mémoire de caractères MCAR, la mémoire topographique TOPO, les deux mémoires de programme ROM et ROM 1, le circuit de commande de tube cathodique CRTC, ainsi que les deux dispositifs de liaisons asynchrones UART et UART 1. Le bus de contrôle BCONT actionne le décodeur d'adresse DA, ainsi qu:un certain nombre de multiplexeurs qui sont inséras entre le bus d'adresse et certains des constituants, à savoir le multiplexeur de la mémoire dynamique notée MUXRAM, le multiplexeur de mémoire topographique notée MUXTOPO, et le multiplexeur de la mémoire de caractères notée MUXMCAR. Le bus de contrôle peut aussi actionner directement les deux mémoires de programme ROM i et ROM 1, ainsi que les deux dispositifs de Maisons asynchrones UART 0 et UART 1. Enfin, le bus de contrôle peut actionner un amplificateur relais ou tampon TP 1 qui assure la Maison entre le bus de données BDAT et les mémoires topographiques et de caractères ; de même, il pourra actionner une paire d'étages tampon en parallèle notée TP 2 et TP 3, et permettant la connexion du bus de données vers la sortie de la mémoire de caractères et vers l'entrée de la mémoire morte de caractères CAROM. Dans un mode de réalisation particulier de l'invention, l'écran de visualisation est d'un type a très haute définition, sur lequel on visualise 64 lignes de 96 caractères chacune. L'écran peut par exemple être du type vendu par la société MOTOROLA sous la désignation 4408. On observera que ceci correspond à 2 x 32 = 64 lignes de trois fois 32 caractères chacune. La mémoire de codes de caractères MCAR est adressable a travers son multiplexeur MUXMCAR selon des blocs de 32 codes de caractères chacun. Pour pouvoir couvrir tout l'écran, ces blocs sont naturellement au moins au nombre de 192. On verra plus loin que la mémoire de caracteres utilise de préférence un nombre supérieur de blocs, égal par exemple à 256. Dans un mode de réalisation très particulier, chaque caractère de la mémoire de caractères MCAR est défini par 16 bits, répartis de la manière suivante - 7 bits de codes ASCII - 1 bit indiquant si l'on est en mode caractère ou en mode graphique, et - 8 bits d'attribut se décomposant de la manière suivante: - 1 bit indiquant s'il faut souligner le caractère - 1 bit indiquant s'il faut souligner plus intensément le caractère - 1 bit indiquant s'il faut visualiser en vidéo inverse - 1 bit indiquant s'il faut visualiser en sous brillant - 1 bit indiquant s'il faut visualiser en faisant clignoter - 3 bits réservés pour des applications plus complètes. La mémoire topographique TOPO de l'invention est apte à désigner 192 blocs dans la mémoire MCAR, en correspondance avec une décomposition de chacune des 64 lignes de l'écran en 3 pavés de 32 caractères consécutifs chacun. Pour cela, chacune des cases de la mémoire topographique contient l'adresse du bloc correspondant dans la mémoire de caractèresMCAR. On imagine déjà le fonctionnement de base du terminal selon l'invention. Lorsqu'il reçoit des caractères à afficher, le microprocesseur MP les range par blocs dans la mémoire de caractères, en l'adressant convenablement à travers la mémoire topographique, pour l'emplacement qui correspond à ce bloc dans l'affichage. Une fois que le bloc de caractères est complètement rempli, celui-ci sera affiché sous l'action du circuit de commande de tube cathodique RTC, qui délivre à la mémoire topographique des adresses tenant compte du balayage de l'écran cathodique, tandis que celles-ci excitent la mémoire de caractères en synchronisme, afin qu'elle délivre à la logique d'écran LTC les informations vidéo susceptibles de lui faire imprimer Les caractères correspondants.La façon d'aménager les circuits de commande de tube cathodique CRTC ainsi que la logique d'écran LTC pour afficher des caractères correspondants à des codes est considérée comme connue de l'homme l'art. On peut maintenant décrire l'organigramme général de la figure 3. Après le début 300, cet organigramme comprend en 301 une initialisaton des entrées et des sorties, suivie d'une remise à zéro générale et du passage au mode à l'étape 302. Ensuite, l'étape 303 est un test examinant si un caractère a été frappé sur le clavier CLD. Si oui, ce caractère est rangé au pas 304 dans une mémoire tampon circulaire ménagée dans la mémoire dynamique de travail RAM. La longueur de ce tampon circulaire est en principe égale à 16 caractères. Si aucun caractère n'a été frappé au clavier, ou après le rangement d'un tel caractère dans le tampon circulaire, le test 305 consiste a examiner si un octet est reçu du calculateur éloigné. Si non, on retourne l'étape 303, Si oui, le microprocesseur Mp examine le code opération contenu dans cet octet, et choisit alors parmi plusieurs états possibles. Le premier état, noté 310 est la remise a zéro générale et le mode , qui est identique à l'état d'initialisation prevu à l'étape 302. Le second état 311 correspond au passage à un autre mode, que l'on a désigné mode 1, et plus précisément à une première opération notée opération 1, et ainsi de suite jusqu'au bloc 348 oui représente une trente huitième opération. On décrira maintenant à la figure 4 l'organigramme correspondant à l'état noté en 302 ou en 310, et qui s'intitule remise à zéro générale et mode 0* Après le bloc initial 400 de cet organigramme, l'étape 401 consiste en une initialisation qui ramène le terminal dans son état d'affichage sur la totalité de l'écran ("contexte plein écran"), Ensuite, l'étape 402 consiste en une initialisation de la mémoire topographique, puis l'étape 403 en un effacement de l'écran, et l'étape 404 en une initialisation du tampon circulaire qui sert à recevoir les caractères frappés du clavier. Après cela, le test 405 examine si un caractère est frappé au clavier. Si oui, ce caractère est envoyé au calculateur à l'étape 406. Dans les deux cas, l'étape 407 vient ensuite pour examiner si un caractère est reçu du calculateur. Si oui, le test 408 examine s'il s'agit d'un caractère de fin de mode, impliquant donc le passage à un mode suivant. Si non, il s'agit d'un code de caractère , et l'étape 409 produit l'affichage de ce caractère par l'unité centrale, en utilisant le processus déjà exposé plus haut. Après cela, l'étape 410 examine si un caractère de fin de mode a été reçu. Si un tel caractère n'a pas été reçu, soit en venant de l'étape 407, soit de l'étape 408, alors on retourne du test 410 à l'étape 405. Si au contraire un caractère de fin de mode a été reçu, on passe à l'étape 411 qui marque la fin du mode zéro, et le passage dans un mode différent que l'on a nommé mode 1. On voit immédiatement que dans ce mode zéro, le terminal selon l'invention s'initialise avec une seule fenêtre de 64 lignes de 96 caractères, c'est-àdire en fait en visualisatSon plein écran, et qu'il se trouve donc absolument compatible avec un terminal classique, permettant fln dialogue normal avec le calculateur hôte. Ce mode permet, sans utiliser un autre terminal, de faire le lancement du programme d'application. Comme on l'a vu, la sortie de ce mode se fait par réception d'un caractère spécial. Pour limiter le nombre de dessins, on n'a pas représente les autres modes et opérations sous forme d'organigramme, leur description suffisant à les identifier, compte tenu d'un organigramme de base semblable à celui de la figure 4. On suppose donc maintenant que l'on a reçu à la fin de l'organigramme de la figure 4 un caractère de fin de mode, pour le passage au mode 1. Le mode 1 permet de gérer l'écran cathodique en mode multi-fenêtres. Ce mode obéit à des commandes issues du calculateur hotte, commandes qui se décomposent en plusieurs classes. La première classe de commande concerne la définition et l'activation des fenêtres. Elle comprend les commandes suivantes - Création d'un contexte de fenêtre nouveau, en définis sant la taille, l'emplacement, l'apparition ou non de bords sur l'écran, l'attribut du curseur, ainsi que l'attribut du fond et des bords. (L'attribut indique un mode particulier de visualisation). - Initialisation d'une fenêtre ainsi créée pour la valider sur l'écran. Désignation d'un contexte déjà défini pour activer la fenêtre sur laquelle on va travailler. - Disparition et activation d'une fenêtre-événement. Avec la notion de fenêtre-événement, apparaît une autre caractéristique importante de la présente invention. Pour mieux la comprendre, on se référera aux figures 5A et 5B. Pour définir les 192 pavés à afficher, la mémoire topographique comporte 192 entrées, qui adressent chacune une case dans une table de numéros de pavés affichés, ces numéros de pavés affichés étant des adresses de la mémoire MCAR. La distribution de la mémoire topographique est illustrée sur la figure 5A. De son côté, la figure 5B illustre les codes de caractères ou blocs de 32 caractères affichables sous forme de pavés qui peuvent être introduits dans la mémoire de caractères MCAR. Le nombre de ces blocs ou pavés est de 256. On voit immédiatement que 192 empla cements de la mémoire MCAR peuvent être réservés pour des fenêtres ordinaires, correspondant à ce que l'on veut voir afficher normalement sur l'écran. Les 64 blocs ou pavés supplémentaires sont consacrés à des fenêtres- événements, qui pourront venir se substituer chacun à liun des pavés des fenêtres ordinaires. La façon dont ceci est géré par les moyens de traitement local MTL est illustrée schématiquement sur les figures 6A à 6C. Ces figures illustrent 3 cartes de mémoire, contenant chacune 192 cases. La carte de la figure 6A correspond simplement aux cases de la mémoire topographique, qui, on se le rappellera, désigne des adresses dans la mémoire de caractères. Les cases de la figure 6B correspondent à des adresses du même type, mais qui ne peuvent désigner que les 192 pavés de fenêtres ordinaires dans la mémoire de caractères. La carte de pointage de la figure 6B, notée TOPFEN, est contenue dans une zone convenable ménagée dans la mémoire de travail RAM de la figure 2. Enfin, toujours dans la mémoire de travail RAM, est ménagée une troisième carte, illustrée sur la figure 6C, et qui comprend elle aussi 192 cases. Mais les cases de cette mémoire, notée TOPEVT, ne contiennent chacune qu'un bit. Ce bit est à zéro si la case correspondante de la mémoire topographique indique la même adresse que la case correspondante de la mémoire TOPFEN. Cela correspond au cas de l'affichage d'une fenêtre ordinaire. Au contraire, une case de la mémoire TOPEVT est à 1 si la mémoire topographique désigne l'un des 64 pavés de fenêtre-événement dans sa case correspondante, tandis que, naturellement, la carte de pointage TOPFEN continue à désigner le pavé de fenêtre ordinaire pour le même emplacement ou pavé de visualisation. De cette manière, les moyens de traitement local disposent en permanence d'une représentation complète des fenêtres ordinaires dont l'affichage a été demandé, ainsi que des fenêtres-événements que le calculateur éloigné a demandé de substituer à des fenêtres ordinaires. Jusqu'à présent, on a considéré cette répartition en fenêtre au niveau individuel de fenêtre comportant un seul pavé. On voit immédiatement qu'en utilisant des fenêtres de plusieurs pavés, le dispositif de l'invention permet de découper l'écran en autant d'écrans classiques que l'on le désire, la taille de ces écrans étant quelconque, sous réserve du module défini par le pavé élémentaire. Ceci fournit naturellement une très grande souplesse pour le traitement au niveau du calculateur éloigné. On examinera maintenant comment est créé un contexte de fenêtre". Cela se passe en deux temps, le premier consistant à initialiser les paramètres fixes du contexte de fenêtre sans visualiser celle-ci, et le second temps consistant à valider la visualisation de la fenêtre. Création de contexte de fenêtre. Cette création de contexte comprend tout d'abord la désignation d'un numéro de pavé NOPAVE. Dans le cas d'une fenêtre-événement, ce paramètre donne un numéro de O à 63 auquel le terminal rajoutera 192 puisque les 192 premiers pavés sont réservés aux fenêtres ordinaires. Pour une fenêtre ordinaire, l'allocation des pavés est faite automatiquement (le numéro fourra est fictif : supérieur à 64 qui est le numéro relatif mawoal d'une fenêtre évenement). Le paramètre suivant est le numéro absolu YMIN de la première ligne de la fenêtre, le numéro étant affecté à la première ligne de l'écran. (Si la fenêtre doit être visualisée avec un bord haut matérialisé, c'est naturellement la ligne de ce bord et non pas la première ligne utilisable de la fenêtre qui devra être comptée). De la même manière, un paramètre YMAX indique le numéro absolu de la dernière ligne de la fenêtre (ligne du bord bas à visualiser s'il y en a un). Après cela, vient le numéro PCOL32 de la première colonne de 32 caractères constituant la fenêtre. Ce numéro est compris entre 0 et 2, puisque l'écran est subdivise généralement en trois colonnes de 32 caractères. Ensuite vient le numéro MBCOL32, qui désigne le nombre de colonnes de 32 caractères constituant la fenêtre, nombre qui varie naturellement de 1 à 3. On notera là encore que les éventuels bords gauche et droit à visualiser sont tracés à l'intérieur de cet espace. Paramet e de : Il s'agit d'un octet dont les quatre bits de poids fort forment quatre variables Booléennes indépendantes indiquant de gauche à droite si l'on demande le tracé d'un bord haut, d'un bord bas, d'un bord gauche, ou d'un bord droit. Vient ensuite un caractèr CARBOR, qui indique le caractère dont seront constitues les bords éventuels, car un bord peut être constitué de caractères quelconques (X ou autres caractères apprOpriéS). Ensuite vient un octet d'attribut des bords noté rnTBOR, et qui peut être désigné par exemple comme surbrillant (valeur numérique 20H), clignotant (valeur numérique 10H), en vidéoinverse (valeur numérique 8), souligné (valeur numérique 4) ou sursouligné (valeur numérique 2). En faisant la somme de ces valeurs, on pourra demander plusieurs attributs en même temps. D'autres caractères sont enfin prévus, comme ATTCURS, pour définir l'attribut du curseur qui peut être incorporé à la visualisation, ainsi qu'un caractère ATTRAVTR, qui indique l'attribut de fond de la fenêtre. D'une manière générale, sur une fenêtre, la notion de curseur se définit par des bits d'attribut. On peut avoir autant de curseurs que l'on veut, par exemple un par fenêtre, et défini comme on veut : trait de soulignement, carré en vidéo inverse, ou carré clignotant en vidéo inverse, par exemple. Cette commande de création de contexte provoque le calcul d'un certain nombre de paramètres utilisés par la suite dans la gestion de la fenêtre par le microprocesseur MP, en particulier des adresses des cases de mémoire topographique du début de la première et de la derniere ligne utile de la fenêtre. Il n'y a par contre aucune action immédiate sur les pavés visualisés de la fenêtre : on peut donc faire cette opération de création de contexte sur une fenêtre-événement partageant ses pavés avec une autre fenêtre-événement sans perturber le fonctionnement de cette dernière. Par ailleurs, si une fenêtre ordinaire est en cours de lecture ou d'écriture par le terminal, l'apparition d'une fenêtre-événement couvrant tout ou partie de cette fenêtre ne gêne en rien le processus, puisque la zone caractère de la fenêtre ordinaire n'est pas affectée par la fenêtre événement. A partir d'une telle création de contexte, on pourra ensuite désigner un contexte, en l'appelant simplement par son numéro de contexte, noté par exemple NCTX. L'apparition de cette entrée en provenance du calculateur lointain provoque le calcul de l'adresse du contexte de fenêtre courante, évitant d'avoir à passer son numéro et à refaire le calcul d'adresse à chaque commande. On prévoit également dans le mode 1 une commande de réinitialisation de fenêtre, qui a pour effet de placer le curseur en haut et à gauche, d'effacer la fenêtre, et d'en tracer les bords, le cas échéant. D'autres commandes sont par exemple la disparition d'une fenêtre-événement, ainsi que la réactivation d'une fenêtre-événement. La disparition d'une fenêtre événement fait donc réapparaître la ou les portions de fenêtres ordinaires qui étaient oblitérées. Les pavés de la fenêtre-événement ne sont donc plus désignés par la mémoire topographique, mais ils restent dans l'ensemble des 64 pavés réservés aux événements dans la mémoire de caractères. En d'autres termes, la disparition d'un événement consiste pour chaque pavé de la fenêtre-événement à réinscrire le contenu de la case TOPFEN correspondante dans le contenu de la case de la mémoire topographique TOPO correspondante, et à faire retourner à 1 le bit de la case correspondante dans la zone de mémoire TOPEVT. La commande de réactivation d'une fenêtre événément permet de faire réapparaitre une fenêtreévénement dans l'état où elle se trouvait lors de sa destruction, à conditon que ses pavés dans la mémoire de caractères n'aient pas été utilisés par une autre fenêtre, auquel cas une réinitialisaton est obligatoire. Lors de l'apparition d'un événement, les cases correspondantes de la mémoire topographique TOPO sont modifiées, et les cases correspondantes de la zone de carte de présence TOPEVT reçoivent chacune un bit 1. On pourra également faire intervenir un "roll" ou défilement sur une fenêtre - s'il s'agit d'une fenêtre-événement, cela s'effectue en agissant sur l'original, à savoir sur la mémoire topographique TOPO. - s'il s'agit d'une fenêtre ordinaire, on agit tout d'abord sur la carte de pointage TOPFEN, puis on ef fectue une recopie dans la mémoire topographique TOPO, dans les endroits il n'y a pas masquage, c'est-à-dire ceux pour lesquels le bit correspondant de la carte de présence TOPEVT est égal à zéro. La description des instructions du mode 1 qui a été donne plus haut concerne essentiellement la première classe d'instructions, qui vise à définir et activer la fenêtre. Une deuxième classe d'instructions permet des manipulations simples au niveau des caractères à l'intérieur de la fenêtre activée - positionnement du curseur en relatif par rapport au début de la fenêtre, - effacement de la fin de la ligne, - effacement de la fin de l'écran, - différentes flèches de positionnement, - changement de l'attribut du curseur, - changement de l'attribut de travail, - écrasement du texte par un caractère, - écrasement du texte par n caractères identiques, - écrasement du texte par une chaine de caractères - demande de l'emplacement de curseur. On détaillera maintenant certaines de ces instructions de commande. Le positionnement du curseur comporte comme donnée d'entrée la coordonnée XR en horizontal et YR en vertical, prise sous forme de coordonnée relative par rapport à la position du caractère utile situé le plus haut et à gauche de la fenêtre considérée, à l'intérieur du cadre éventuel. Une instruction d'effacement de fin de ligne va effacer la fin de la ligne, y compris le caractère situé sous le curseur, l'ensemble étant remis à blanc. Le même processus s'effectue pour un effacement de fin d'écran. Une commande de flèche basse provoque le déplacement du curseur d'une ligne vers le bas, sauf si celui-ci était déjà en bas d'écran, auquel cas il y a défilement du texte de la fenêtre d'une ligne vers le haut avec création d'une ligne vierge en bas. Inversement, une flèche haute déplace le curseur d'une ligne vers le haut avec défilement vers le bas si on était déjà en haut de l'écran, et création d'une nouvelle ligne vierge en haut de l'écran. Une flèche droite déplace le curseur d'un cran vers la droite, avec cventuellement passage à la ligne et défilement vers 1e haut. Inversement, une flèche gauche provoque le recul du curseur d'une position, avec éventuellement montée d'une ligne et défilement vers le bas. On comprend fmc-lement comment s'effectue le changement d'attribut pour le curseur, ainsi que le changement d'attribut pour le travail sur l'ensemble de l'écran (codesATTCURS, et ATTRAVTR déjà mentionnés). On notera qu'un changement de l'attribut de fond de fenêtre n'affectera que les portions d'écran touchées par les commandes suivantes. Par exemple, si on affiche un texte, si l'on change l'attribut de travail, puis que l'on continue à afficher du texte, le début du texte sera affiché à l'ancien attribut, la fin du texte avec le nouvel attribut. L'écrasement par un caractère consiste à déposer un caractère à l'emplacement du curseur qui est avancé d'une position. On comprend immédiatement comment on peut faire un écrasement par n fois le même caractère, ou encore par une chaîne de caractères, qui doit être terminé par un caractère de code égal à 1, mais peut contenir tous les caractères spéciaux admis dans le mode zéro. On donnera maintenant quelques exemples de tels caractères Caractères spéciaux admis dans le mode O - RC retour chariot : ramène le curseur en début de ligne. - LF ligne feed : passage à la ligne suivante. - flèche à droite. - flèche à gauche. - flèche vers le haut. - flèche vers le bas. - ~ (HOME) : retour en haut à gauche de la fenêtre. - CTRL Z (CLEAR) : idem HOME avec effacement de la fenêtre. - ESC Y : effacement de la fin de la fenêtre. - ESC = X Y : positionnement en absolu du curseur dans la fenêtre. Enfin, on peut effectuer une lecture de la position du curseur, pour laquelle le terminal indique en retour au calculateur hôte les coordonnées relatives XR et YR du curseur par rapport au caractère supérieur gauche de la fenêtre, à l'intérieur des bords éventuels. On comprend bien maintenant que la disposition de l'écran multi-fenêtres, avec des fenêtres ordinaires et des fenêtres-événements, selon la presente invention, s'accompagne d'une possibilité de visualisation de caractèreset de traitement de ceux-ci qui s'effectue de manière totalement indépendante dans chacune des fenêtres. A titre d'exemple, on donnera une troisième classe de commandes sans les décrire en détail, ces commandes étant plus spécialement destinées à des applications en traitement de texte. Ces commandes sont les suivantes - écrasement sans bouger, dans lequel le caractère désigné par le curseur est remplacé par le caractère et l'attribut transmis, le curseur n'étant pas déplacé. - lecture du caractère et de son attribut courant, et renvoi de ces informations vers le calculateur hôte, sans mouvement du curseur. - calcul des marges et normalisation du curseur, ce qui correspond à une lecture de la position des marges. - ouverture et fermeture d'un trou den espaces ou d'une ligne. - déplacement d'une zone. - lecture d'une ligne de la fenêtre par le processus en cours dans le calculateur hôte. - traitement des flèches en mode traitement de texte, dans lequel les caractères sortant de la fenêtre sont envoyés pour être récupérés par le calculateur hôte. Les transmissions de chaînes de caractères avec le calculateur hôte peuvent se faire en format normal, ou bien en format compacté. On s'intéressera maintenant au clavier. En travail normal, celui-ci peut être simplement le com plément de l'écran de visualisation, en permettant seulement l'introduction d'informations à destination du calculateur hôte, lequel renvoie des informations en retour pour la visualisation. L'introduction de carac tères peut se faire sous forme d'une chaine de carac tères, qui est rangée dans la mémoiretampon circulaire d'attente, et ensuite envoyée vers le processeur hôte, ou encore de caractères exprimés un par un, un seul caractère de la mémoire tampon d'attente étant alors transmis à la fois vers le calculateur hôte. Si l'on retourne maintenant à la figure 2, on voit que celle-ci comporte une mémoire morte de carac tères nommée CAROM, et reliée à la logique d'écran LTC par l'intermédiaire dlun circuit de décalage DECL. Cela peut servir avantageusement pour l'affichage des caractères. A cet égard, une application complémentaire de la présente invention permet le travail en mode graphique mosaTque, dans lequel chaque position de caractère est considérée comme une grille de deux colonnes et de trois lignes, suivant le mode alpha mosaïque connu du vidéotex . On peut alors effectuer une commande de tracé d'un point, qui affecte le point de coordonnées relatives XR, YR en fonction du mode de tracé courant. On peut aussi tracer un segment, ainsi que modifier le mode de tracé, qui peut consister soit en un allumage des points, soit en une visualisaton des points en vidéo inverse, c'est-à-dire en une extinction des points, soit au contrairedusune pure et simple inversion de l'état précédent des points concernés. Bien entendu la présente invention n'est pas limitée au mode de réalisation décrit, mais s 'étend à toute variante conforme à son esprit. REVENDICATIONS 1. Terminal visuel, comportant un écran (TC) une mémoire de codes de caractères à visualiser (M CAR), un circuit de commande de visualisation (CRTC) capable d'exciter l'écran pour y faire apparaître des caractères correspondant aux codes, ainsi que des moyens de traitement local (MTL) connectés à l'écran, à la mémoire de codes de caractères et au circuit de commande de visualisation, moyens de traitement local qui comprennent un processeur local (MP) avec au moins une mémoire de programme (ROM , RCM 1), au moins une mémoire de travail (RAM) et une connexion vers un calculateur éloigné, et qui sont capables de remplir la mémoire de codes de caractères selon des informations venues du calculateur éloigné, ainsi que d'agir sur le circuit de commande de visualisation pour coordonner la visualisation de ces caractères à l'intérieur du cadre de l'écran, caractérisé par le fait que, le format nominal d'écran comportant m.q lignes de n.p caractères chacune, la mémoire de codes de caractères est adressable selon des blocs de n codes de caractères chacun, par le fait qu'il est prévu une mémoire de pointage topographique (TOPO) apte à désigner m.p.q. blocs dans la memoire de codes de caractères, en correspondance avec une décomposition de chacune des m.q lignes de l'écran en p pavés de n caractères consécutifs chacun, et que les moyens de traitement local (MTL) possèdent un premier état (MODE ) où la visualisation réunit les m.p.q pavés dans un cadre égal au format de l'écran, et un second état (MODE 1) où est désignable au moins une fenêtre ordinaire comprenant au moins un pavé, et considérée comme un écran indépendant 2.Terminal visuel selon la revendication 1, caractérisé par le fait que la mémoire de codes de carac tères contient m.p.q + r blocs de n codes, que la mémoire topographique (TOPO) peut désigner au choix, par le fait que la mémoire de travail (RAM) comporte une zone formant carte de pointage (TOP FEN) apte à désigner seulement les m.p.q blocs de codes en correspondance avec les m.p.q pavés de l'écran, et une zone formant carte de présence d'événement (TOP EVT) comprenant, pour chacun des m.p.q pavés de l'écran, un bit qui est 'zéro' ou 'un' selon que la carte de pointage et la mémoire topographique indiquent ou non le même bloc de codes de caractères pour ce pavé, ce qui permet de visualiser des fenêtres-événements substituables réversiblement au contenu de l'écran dans la fenêtre ordinaire correspondante. 3. Terminal visuel selon l'une des revendications 1 et 2, caractérisé par le fait que la mémoire de codes de caractères (M CAR) et la mémoire topographique (TOPO) sont directement accessibles par le processeur local (MP), faisant partie de son espace d'adresse. 4. Terminal visuel selon l'une des revendications 1 à 3, caractérisé par le fait que le second état (MODE 1) est sensible au moins à une commande de création de contexte de fenêtre en provenance du calculateur hôte, ainsi qu'à des commandes de désignation d'un contexte de fenêtre déjà crée, et de réinitialisation de fenêtre. 5. Terminal visuel selon la revendication 4, prise en combinaison avec la revendication 2, caractérisé par le fait que le second état (MODE 1} est également sensible à des commandes de disparition de fenêtre événement, ainsi que de réactivation de fenêtre-événement. 6. Terminal visuel selon l'une des revendications 4 et 5, caractérisé par le fait que la commande de création de fenêtre comprend au moins le numéro du premier pavé à occuper (NOPAVE), les numéros des première (YMIN) et dernière (YMAX) lignes de la fenêtre, le numéro (PCOL 32) de la première des colonnes de n caractères constituant la fenêtre, et le nombre de colonnes (NB COL 32) de n caractères constituant la fenêtre. 7. Terminal visuel selon l'une des revendications 1 à 6, caractérisé par le fait que m = n = 32, p = 3 et q = 2. 8. Terminal visuel selon l'une des revendications 1 à 7, caractérisé par le fait que le nombre entier r est égal à environ un tiers de m.p.q. 9. -Terminal visuel selon l'une des revendications 1 à 8, caractérisé par le fait que sont prévues des commandes de manipulations simples de caractères applicables à tout l'écran dans le premier état (MODE ) ou à chaque fenêtre dans le second état (MODE 1). 10. Terminal visuel selon la revendication 9, caractérisé par le fait que sont également prévues des commandes de type traitement de texte et/ou de mode graphique mosaïque du genre vidéotex applicables à tout l'écran dans le premier état (MODE ) ou à chaque fenêtre dans le second état (MODE 1).