Comment MS-DOS et d'autres programmes en mode texte peuvent-ils afficher des caractères CJK double largeur?

J'ai vu de nombreux écrans de configuration du BIOS en mode texte en japonais et en chinois. Récemment, j'ai même vu l'installation de Windows XP en japonais. MS-DOS avait également des versions japonaises. Mode DOS réel , pas d'invite de commande Windows!

Un écran de mode texte typique a une taille de 80x25 . Avec un caractère japonais ayant une largeur de double du caractère latin normal, le nombre maximal de caractères japonais pouvant être affichés en même temps à l'écran est d'environ 1000. Nous avons donc besoin de 2000 points de code pour afficher la partie gauche et droite des caractères.

Comme le mode texte par défaut ne peut afficher que 256 caractères, mais les 128 premiers sont utilisés pour ASCII, les caractères utilisables sont donc limités aux 128 points de code élevés. Si nécessaire, nous pouvons l'étendre à 512, mais cela ne peut toujours pas prendre en charge suffisamment de points de code pour l'affichage. Je me demande toujours comment ils ont réussi à afficher le grand jeu de caractères avec un nombre limité de caractères.

[ ] 8]

Le mode texte sous Linux semble utiliser le pilote du mode graphique car il peut afficher Unicode et a beaucoup plus de couleurs. Mais je ne peux pas expliquer comment ils le font dans les écrans de configuration MS-DOS et BIOS.

EDIT: j'ai même trouvé une entrée de texte japonais pour DOS

Il y a aussi le coréen en mode texte!

Le mode "80x25 caractères" normal est en réalité de 720x350 pixels (ce qui signifie que chaque cellule de caractère mesure 9 pixels de large par 14 pixels de haut). Les modes de caractères à double largeur ("40x25") peuvent soit simplement interpoler ceci à la plus grande largeur en doublant chaque colonne pour économiser sur la mémoire de contenu vidéo (en coupant la quantité requise de mémoire de contenu vidéo de moitié), ou utiliser une mémoire de glyphe supplémentaire et une mémoire identique quantité de mémoire de contenu vidéo pour augmenter les cellules de caractères à 18 * 14 pixels.

Assez tôt (je pense que cela a été fait lors de l' introduction d' EGA ), la prise en charge des glyphes de caractères définis par l'utilisateur a été ajoutée au mode d'affichage de texte du PC IBM.

Le mode texte normal du PC IBM est simplement un 4000 séquentiel de RAM de contenu vidéo à une adresse particulière. Ceux-ci sont lus comme un octet d'attributs de caractère (clignotant à l'origine, gras, souligné, etc.; réutilisé plus tard pour les couleurs de premier plan et d'arrière-plan et clignotant / surligné, d'où la limitation à 16 couleurs en mode texte) et un octet décrivant le caractère à être affichée. Le glyphe réel à afficher pour chaque valeur d'octet de caractère est stocké ailleurs.

Cela signifie que tant que vous pouvez vous contenter de 256 glyphes distincts à l'écran à la fois, et que chaque glyphe peut être représenté sous la forme d'un bitmap 9x14 à un bit, vous pouvez simplement remplacer les glyphes en mémoire pour faire apparaître les caractères différemment. . En partie, c'était une partie de ce qui se mode con codepage selectfaisait sous DOS. C'est relativement banal.

Si vous avez besoin de plus de 256 glyphes distincts mais que vous pouvez vivre avec le nombre réduit de glyphes à l'écran, vous pouvez opter pour un schéma 40x25 avec des glyphes double largeur (18 pixels de large). En supposant que la quantité totale de RAM de contenu vidéo est fixe et en supposant que vous pouvez augmenter la mémoire bitmap du glyphe, vous pouvez passer à l'utilisation de deux octets sur quatre pour représenter un glyphe à l'écran, vous donnant accès à 2 ^ 16 = 65 536 glyphes différents (y compris le glyphe vierge). Si vous vous sentez audacieux, vous pouvez même ignorer le deuxième octet d'attribut qui vous donne accès à 2 ^ 24 ~ 16,7 millions de glyphes différents. Ces deux approches reposent sur un support logiciel spécial, mais la partie matérielle et micrologicielle devrait être assez facile à faire. 65 536 glyphes à 18 x 14 pixels à un bit correspondent à environ 2 Mio, une quantité de mémoire importante mais pas insurmontable à l'époque.

L'anglais de base des États-Unis a besoin d'au moins 62 glyphes dédiés (chiffres 0-9, lettres AZ en majuscules et minuscules), vous avez donc quelque chose comme 180-190 glyphes pour jouer si vous voulez également pouvoir afficher le texte en anglais américain en même temps temps et aller avec 8 bits par glyphe. Si vous pouvez vivre sans prise en charge simultanée de l'anglais américain, ce que vous pouvez choisir de faire dans un environnement à ressources limitées tel que la première architecture PC IBM, vous avez accès au nombre complet de glyphes.

Avec une ruse, vous pourriez probablement mélanger et faire correspondre les deux schémas également.

Je ne sais pas comment cela a été fait, mais les deux sont des schémas viables pour obtenir des alphabets "fantaisie" à nombre de caractères particulièrement limité sur un écran PC IBM simple en mode texte que je peux trouver juste assis devant de Stack Exchange pendant un moment. Il est parfaitement possible qu'il existe des modes graphiques supplémentaires qui facilitent cela dans la pratique.

Gardez également à l'esprit la distinction entre le mode texte et le mode graphique affichant du texte . Si vous êtes en mode graphique, peut-être via VESA qui est assez universellement pris en charge, vous êtes seul en ce qui concerne le dessin de glyphes, mais vous avez également beaucoup plus de liberté pour les dessiner. Par exemple, je suis presque sûr que les parties textuelles de Windows NT (qui appartient à la famille de produits à laquelle Windows XP appartient) utilisent un mode graphique pour afficher du texte, y compris l'écran de démarrage de Windows NT 4.0 et les BSOD.

Cela simplifie ce que dit @Michael Kjörling.

En mode texte, vous disposez d'une "mémoire d'écran" de 1 octet par caractère à l'écran qui indique à l'adaptateur quel caractère apparaît à chaque position d'écran. (Il existe également des octets "d'attribut" qui indiquent à l'adaptateur quelle couleur et des choses comme le soulignement, le clignotement, etc.).

L'adaptateur utilise cet octet pour indexer dans une autre "table de caractères" qui a le petit 8x12 ou n'importe quel bitmap du caractère. DOS appelle cette table de caractères une page de codes.

En commençant par CGA, vous pouvez dire à l'adaptateur d'obtenir la table des caractères à un endroit spécifique dans la RAM de l'adaptateur. Chaque adaptateur a une ROM de caractères qui a la "police" par défaut pour cette carte (qui est la police IBM standard), mais vous pouvez dire à l'adaptateur de basculer vers un emplacement dans la RAM et d'y placer vos propres images.

Tant que le logiciel sait ce qui se passe, les codes dans la mémoire d'écran qui pointent vers les images dans la table des caractères ne sont alignés avec aucun code ASCII, mais c'est plus facile s'ils le font. Vous remarquerez qu'il y a des codes de mémoire d'écran (et des formes de table de caractères) pour 1-31 qui sont des caractères ASCII non imprimables - mais en écrivant directement dans la mémoire d'écran (de bons souvenirs DEFSEG = &HB800 : POKE 0,1dans GW-BASIC pour changer le caractère le plus élevé en un smiley l'esprit), vous pouvez toujours les afficher.

L'affichage d'autres langues est donc très bien, si vous pouvez mettre les bonnes images dans la RAM de l'adaptateur et avoir le support logiciel nécessaire.

J'ai trouvé quelque chose dans la page "Mode texte compatible VGA" dans Wikipedia et aussi dans certains livres de programmation VGA:

Les modes texte EGA et VGA autorisent simultanément 512 glyphes à l'écran ou 2 banques de 256 glyphes chacune. Le bit d'attribut 3 (intensité des couleurs de premier plan) peut également choisir entre la banque A ou B. Ce qui se produit normalement est que, par défaut, les registres de polices A et B pointent vers la même adresse, vous donnant seulement 256 glyphes. Donc, pour que cela fonctionne, vous devez définir les registres de polices aux bonnes adresses.

Chaque banque a 8192 octets et chacun des 256 glyphes de la banque a 32 octets (8 pixels de large et 32 ​​pixels de haut). Vous pouvez définir le registre du nombre de lignes de numérisation afin de déterminer la hauteur correcte de vos caractères. Les cartes VGA impriment 400 lignes de numérisation à l'écran tandis que les cartes EGA impriment 350 lignes de numérisation à l'écran.Par conséquent, afin de vous donner 25 lignes de caractères, elles définissent leur hauteur de caractère respectivement à 16 et 14 lignes de numérisation. De plus, en VGA, chaque glyphe peut avoir 8 ou 9 points de large, mais la 9e colonne est soit vierge soit juste une 8e colonne répétée. Tous ces glyphes dans les deux banques peuvent être définis par l'utilisateur.

Comment obtenir plus de 256 caractères différents à l'écran dans certaines langues? Dans les exemples ci-dessus, chaque caractère étranger spécial est composé de deux glyphes (gauche et droite) ou plus. Vous pouvez définir les premiers, disons, 128 glyphes de la banque A en dehors du texte ASCII, et vous aurez toujours 128 glyphes de la banque A + 256 glyphes de la banque B = 384 glyphes à personnaliser.

En outre, vous pouvez combiner différents côtés gauche et droit pour créer un énorme jeu de caractères! Disons, par exemple, que parmi les 384 glyphes définis par l'utilisateur, vous souhaitez réserver 184 pour les côtés gauche et 200 pour les côtés droit: vous pouvez avoir 184 * 200 = 36800 caractères différents! (bien sûr, la plupart d'entre eux seraient probablement des caractères invalides pour cette langue, mais vous pouvez toujours obtenir un bon nombre de combinaisons valides).

Dans l'exemple de langue japonaise ci-dessus, vous avez les caractères "ha" et "ba" partageant le glyphe de gauche. Idem pour les caractères "si" et "zi". "ko" et "ni" les côtés droits sont si similaires qu'ils pourraient partager le même glyphe côté droit. On pourrait dire la même chose des caractères "ru" et "ro". Avec un bon design, vous pouvez très bien étendre votre jeu de caractères. Le glyphe de droite du caractère "le" apparaît en haut à gauche de l'écran (en gris), et dans la barre de défilement verticale, les boutons haut et bas ont également été modifiés, ce qui signifie qu'au moins une partie de la banque A a également été utilisé pour accueillir les nouveaux glyphes.

En conclusion, les fonctions de chaîne du BIOS au début de l'ère PC n'étaient pas compatibles avec Unicode, mais ce n'est pas obligatoire. Tout ce que vous aviez à faire était de personnaliser vos 512 glyphes et de définir les registres EGA ou VGA appropriés. Par exemple, vous pouvez personnaliser les glyphes "! @" "# $" "% ^" "& *" "Çé" "ñÑ" à vos caractères étrangers (dans la banque A ou B), puis faire imprimer le BIOS "! @ # S% ^ & * çéñÑ "chaîne à la fois. Le BIOS ne vérifierait pas les glyphes. Vous ne pouvez pas non plus utiliser les fonctions du BIOS, car vous pouvez écrire directement dans la mémoire vidéo. Pour utiliser un glyphe de la banque B, définissez simplement l'attribut Couleur de premier plan sur une valeur comprise entre 8 et 15 (couleur vive).

(Excusez mon anglais)

J'ai fait quelques recherches et comme je l'avais prévu, vous devez utiliser le mode graphique ou avoir besoin d'un support matériel spécial car il n'y a aucun moyen d'utiliser plus de 512 caractères en mode texte VGA

Eh bien, DOS lui-même ne peut pas imprimer en jeux de caractères au-delà de 1 octet par caractère, car il utilise les fonctions du BIOS qui à leur tour utilisent le matériel VGA qui ne peut pas avoir plus de 2 x 256 polices de taille. Donc, cela ressemble à nouveau à un travail pour un CONDUCTEUR, qui utilise le mode graphique pour rendre des polices étendues. Nous avons déjà pris en charge les polices Unicode dans quelques éditeurs graphiques de texte DOS et similaires (merci :-)) et que DBCS ou UTF-8 soit utilisé, les deux partagent la "taille du caractère peut être un ou plusieurs octets" en gérant "l'anomalie" .

Y aura-t-il jamais un support officiel pour la langue japonaise dans FreeDOS?

La version japonaise de DOS (DOS / V) utilise la première approche et simule le mode texte en rendant les caractères en mode graphique à l' aide d'un pilote spécial. Le pilote suit la norme IBM V-Text qui est un mécanisme pour étendre les capacités d'affichage de texte du DOS. Vous pouvez choisir entre différentes polices 16/24/32/48 points comme celle-ci

Certains autres systèmes en mode texte utilisent également la même technique. Dans FreeDOS, vous pouvez charger un pilote spécial pour le support japonais

Le moteur de rendu interceptera les appels int 10h et int 21h et dessinera le texte manuellement, donc cela fonctionnera même pour les programmes anglais normaux. Mais cela ne fonctionnera pas pour les programmes qui écrivent directement dans la mémoire VGA. Pour l'impression des caractères japonais int 5h et int 17h sont également accrochés.

Selon le manuel DOS / V, le BIOS IBM a également ajouté la prise en charge de V-Text via int 15h avec les 4 nouvelles fonctions ci-dessous

5010H Video extension information acquisition
5011H Video extension function registration
5012H Video extension driver release
5013H Video extension driver lock setting

Je suppose que c'est aussi la raison pour laquelle j'ai vu le support japonais dans les BIOS de mes anciens PC

Néanmoins, la lenteur du mode graphique peut introduire des problèmes lors du défilement qui nécessitent une manipulation particulière

DOS / V est en fait la première solution logicielle pour le mode texte japonais

Pendant ce temps, des recherches sérieuses étaient en cours chez IBM Japon depuis le début des années 80 pour produire une solution logicielle au problème de l'affichage des caractères japonais. Avec l'avènement des moniteurs VGA haute résolution, des processeurs plus rapides et des mémoires et disques durs plus grands, les concepteurs des laboratoires de recherche Fujisawa et Yamato d'IBM ont réalisé que les informations sur la forme et la taille des caractères kanji pouvaient être stockées sur disque, chargées dans une mémoire étendue, et affiché via VRAM en mode graphique. (Le "V" dans DOS / V, en passant, vient du moniteur VGA nécessaire pour afficher les caractères japonais via le logiciel.)

DOS / V: la solution logicielle aux problèmes matériels

Selon le même article, avant l'invention de DOS / V, d'autres systèmes avaient tous besoin d'une mémoire Kanji ROM matérielle

Toutes les marques d'ordinateurs ont utilisé des solutions matérielles pour gérer l'affichage des caractères japonais, stockant les données de tous les caractères sur des puces spéciales appelées ROM kanji. Cette méthode exigeait que le code codé sur deux octets pour chaque caractère d'entrée au clavier soit envoyé à la CPU, qui à son tour récupérait le caractère correspondant de la kanji ROM et l'envoyait à l'écran via la VRAM en mode texte. L'utilisation de kanji ROM signifiait que la forme de chaque caractère était fixe, tandis que l'utilisation de la VRAM en mode texte définissait une taille de point standard de 16 x 16 pour chaque caractère.

Par exemple, IBM Personal System / 55 qui utilise un adaptateur graphique spécial avec une police japonaise, pour qu'ils obtiennent un mode texte réel

Au début des années 80, IBM Japon a lancé deux lignes d'ordinateurs personnels basées sur x86 pour la région Asie-Pacifique, IBM 5550 et IBM JX. Le 5550 a lu les polices Kanji du disque et a dessiné du texte sous forme de caractères graphiques sur un moniteur haute résolution 1024 x 768.

https://en.wikipedia.org/wiki/DOS/V#History

Similaire à IBM 5550, le mode texte était de 1040x725 pixels (police 12x24 et 24x24 pixels, 80x25 caractères) en 8 couleurs, peut afficher les caractères japonais lus à partir de la police ROM

L' architecture AX utilise un adaptateur JEGA spécial au lieu de l'EGA standard

AX (Architecture eXtended) était une initiative informatique japonaise lancée vers 1986 pour permettre aux PC de gérer du texte japonais à deux octets (DBCS) via des puces matérielles spéciales, tout en permettant la compatibilité avec les logiciels écrits pour les PC IBM étrangers.

...

Pour afficher les caractères Kanji avec une clarté suffisante, les machines AX avaient des écrans JEGA (ja) avec une résolution de 640x480 plutôt que la résolution EGA standard 640x350 qui prévalait ailleurs à l'époque. Les utilisateurs pouvaient généralement basculer entre les modes japonais et anglais en tapant «JP» et «US», ce qui invoquerait également l'AX-BIOS et un IME permettant la saisie de caractères japonais.

Les versions ultérieures ajoutent également un matériel spécial AX-VGA / H et AX-VGA / S pour l'émulation logicielle sur VGA

Cependant, peu de temps après la sortie de l'AX, IBM a publié la norme VGA avec laquelle AX n'était évidemment pas compatible (ils n'étaient pas les seuls à promouvoir des extensions "super EGA" non standard). Par conséquent, le consortium AX a dû concevoir un AX-VGA compatible (ja). AX-VGA / H était une implémentation matérielle avec AX-BIOS, tandis que AX-VGA / S était une émulation logicielle.

En raison de moins de logiciels disponibles et d'autres problèmes, AX a échoué et n'a pas pu briser la domination du PC-9801 au Japon. En 1990, IBM Japon a dévoilé DOS / V qui permettait à IBM PC / AT et ses clones d'afficher du texte japonais sans aucun matériel supplémentaire à l'aide d'une carte VGA standard. Peu de temps après, AX a disparu et le déclin du NEC PC-9801 a commencé.

La série NEC PC-98 possède également une ROM de caractères dans le contrôleur d'affichage

Un PC-98 standard possède deux contrôleurs d'affichage µPD7220 (un maître et un esclave) avec respectivement 12 Ko de mémoire principale et 256 Ko de RAM vidéo. Le contrôleur d'affichage maître gère la police ROM, affichant les caractères JIS X 0201 (7x13 pixels) et JIS X 0208 (15x16 pixels)

Je ne connais pas la situation pour le chinois et le coréen mais je pense que les mêmes techniques sont utilisées. Je ne sais pas s'il existe d'autres moyens d'y parvenir ou non

Vous avez besoin d'un mode graphique au lieu d'un mode texte codé en dur pour que les glyphes de texte unicode puissent être affichés. Ensuite, vous définissez MS-DOS pour utiliser une police unicode et modifiez le mappage de langue pour l'utiliser.

http://www.mobilefish.com/tutorials/windows/windows_quickguide_dos_unicode.html