W jaki sposób MS-DOS i inne programy trybu tekstowego mogą wyświetlać znaki CJK o podwójnej szerokości?

Widziałem wiele ekranów konfiguracji BIOS w trybie tekstowym w języku japońskim i chińskim. Ostatnio widziałem nawet konfigurację systemu Windows XP w języku japońskim. MS-DOS miał także japońskie wersje. Prawdziwy tryb DOS , a nie wiersz poleceń systemu Windows!

Jeden typowy ekran w trybie tekstowym ma rozmiar 80 x 25 . W przypadku japońskiego znaku o wielkości dwukrotnie większej niż normalna szerokość znaków łacińskich maksymalna liczba japońskich znaków, które mogą być wyświetlane jednocześnie na ekranie, wynosi około 1000. Potrzebujemy więc 2000 punktów kodowych, aby wyświetlić lewą i prawą część znaków.

Domyślny tryb tekstowy może wyświetlać tylko 256 znaków, ale pierwsze 128 jest używane w ASCII, więc użyteczne są ograniczone do wysokich 128 punktów kodowych. W razie potrzeby możemy go rozszerzyć do 512, ale to wciąż nie obsługuje wystarczającej liczby punktów kodowych do wyświetlenia. Zawsze zastanawiam się, jak udało im się wyświetlić duży zestaw znaków przy tak ograniczonej liczbie znaków.

[ ] 8]

Tryb tekstowy w systemie Linux wydaje się używać sterownika trybu graficznego, ponieważ może wyświetlać Unicode i ma o wiele więcej kolorów. Ale nie potrafię wyjaśnić, jak to robią na ekranach konfiguracji MS-DOS i BIOS.

EDYCJA: Znalazłem nawet japoński tekst do DOS-a

Są też koreańskie w trybie tekstowym!

Normalny tryb „80 x 25 znaków” to w rzeczywistości 720 x 350 pikseli (co oznacza, że ​​każda komórka znaku ma szerokość 9 pikseli i wysokość 14 pikseli). Tryby znakowe o podwójnej szerokości („40x25”) mogą albo po prostu interpolować to na większą szerokość, podwajając każdą kolumnę, aby zaoszczędzić na pamięci treści wideo (zmniejszenie wymaganej ilości pamięci treści wideo na pół), lub użyć dodatkowej pamięci glifów i identycznego ilość pamięci zawartości wideo w celu zwiększenia komórek znaków do 18 * 14 pikseli.

Dość wcześnie (myślę, że zostało to zrobione, kiedy wprowadzono EGA ), obsługa trybów znaków zdefiniowanych przez użytkownika została dodana do trybu wyświetlania tekstu na komputerze IBM.

Normalny tryb tekstowy na komputerze IBM PC to po prostu sekwencyjne 4000 bajtów RAM zawartości wideo pod danym adresem. Są one odczytywane jako jeden bajt atrybutów znaków (pierwotnie migający, pogrubiony, podkreślony itp .; później ponownie użyty dla kolorów pierwszego planu i tła oraz migających / podświetlonych, stąd ograniczenie do 16 kolorów w trybie tekstowym) i jeden bajt opisujący znak do być wyświetlane. Rzeczywisty glif wyświetlany dla każdej wartości bajtu znaku jest przechowywany w innym miejscu.

Oznacza to, że tak długo, jak możesz zadowolić się 256 różnymi glifami na ekranie w danym momencie, a każdy glif może być reprezentowany jako bitmapa 9 x 14, możesz po prostu zastąpić glify w pamięci, aby znaki wyglądały inaczej . Po części była to jedna część tego, co mode con codepage selectzrobiło w DOS. To jest względnie trywialne.

Jeśli potrzebujesz więcej niż 256 różnych glifów, ale możesz żyć ze zmniejszoną liczbą glifów na ekranie, możesz wybrać schemat 40 x 25 z glifami o podwójnej szerokości (18 pikseli). Zakładając, że całkowita ilość pamięci RAM na zawartość wideo jest stała i zakładając, że możesz zwiększyć pamięć bitmapy glifów, możesz przejść do używania dwóch bajtów na każde cztery bajty do reprezentowania jednego glifu na ekranie, co daje dostęp do 2 ^ 16 = 65 536 różnych glifów (w tym pusty glif). Jeśli masz odwagę, możesz nawet pominąć drugi bajt atrybutu, który daje dostęp do 2 ^ 24 ~ 16,7 miliona różnych glifów. Oba te podejścia opierają się na specjalnej obsłudze oprogramowania, ale sprzęt i oprogramowanie układowe powinny być dość łatwe do zrobienia. 65 536 glifów przy 18 x 14 jednobitowych pikselach osiąga około 2 MiB, znaczną, ale nie do pokonania ilość pamięci w tym czasie.

Podstawowy angielski w języku angielskim wymaga co najmniej 62 dedykowanych glifów (cyfry 0–9, litery AZ dużymi i małymi literami), więc masz do dyspozycji coś w rodzaju 180-190 glifów, jeśli chcesz mieć możliwość jednoczesnego wyświetlania tekstu w języku angielskim angielskim czas i idź z 8 bitami na glif. Jeśli możesz żyć bez jednoczesnego wsparcia w języku angielskim, co możesz zrobić w środowisku o ograniczonych zasobach, takim jak wczesna architektura IBM PC, masz dostęp do pełnej liczby glifów.

Przy odrobinie podstępu można prawdopodobnie połączyć i dopasować oba schematy.

Nie wiem, jak to się faktycznie zrobiło, ale oba są realnymi schematami, jak uzyskać szczególnie fantazyjne alfabety o ograniczonej liczbie znaków na zwykłym ekranie komputera IBM w trybie tekstowym, który mogę wymyślić, siedząc z przodu Stack Exchange na chwilę. Jest całkiem możliwe, że istnieją dodatkowe tryby graficzne, które ułatwiają to w praktyce.

Pamiętaj też o rozróżnieniu między trybem tekstowym a trybem graficznym wyświetlającym tekst . Jeśli jesteś w trybie graficznym, być może za pośrednictwem VESA, która jest dość powszechnie obsługiwana, jesteś sam, jeśli chodzi o rysowanie glifów postaci, ale masz również dużo więcej swobody w ich rysowaniu. Na przykład jestem prawie pewien, że tekstowe części systemu Windows NT (do której rodziny należy system Windows XP) używają trybu graficznego do wyświetlania tekstu, w tym ekranu rozruchowego systemu Windows NT 4.0 i BSOD.

Upraszcza to, co mówi @Michael Kjörling.

W trybie tekstowym masz „pamięć ekranu”, która ma 1 bajt na znak ekranowy, który mówi adapterowi, jaki znak pojawia się na każdej pozycji ekranu. (Są też bajty „atrybutowe”, które mówią adapterowi, jaki kolor i takie rzeczy, jak podkreślenie, miganie itp.).

Adapter używa tego bajtu do indeksowania do innej „tablicy znaków”, która ma małą 8x12 lub dowolną bitmapę znaku. DOS nazywa tę tablicę znaków stroną kodową.

Począwszy od CGA, możesz nakazać adapterowi pobranie tablicy znaków w określonym miejscu w pamięci RAM adaptera. Każdy adapter ma ROM ROM ze znakami, który ma domyślną „czcionkę” dla tej karty (która jest standardową czcionką IBM), ale możesz nakazać adapterowi przejście do lokalizacji w pamięci RAM i umieszczenie tam własnych obrazów.

Tak długo, jak oprogramowanie wie, co się dzieje, kody w pamięci ekranu wskazujące na obrazy w tablicy znaków nie są zgodne z żadnymi kodami ASCII, choć łatwiej jest, jeśli tak jest. Zauważysz, że istnieją kody pamięci ekranu (i kształty tabel znaków) dla 1-31, które są niedrukowalnymi znakami ASCII - ale pisząc bezpośrednio do pamięci ekranu (miłe wspomnienia DEFSEG = &HB800 : POKE 0,1w GW-BASICU, aby zmienić najwyższy znak na buźkę) umysł) nadal możesz je wyświetlać.

Wyświetlanie innych języków jest więc w porządku, jeśli umieścisz odpowiednie obrazy w pamięci RAM adaptera i będziesz mieć niezbędną obsługę oprogramowania.

Znalazłem coś na stronie „Tryb tekstowy zgodny z VGA” w Wikipedii, a także w niektórych książkach programistycznych VGA:

Zarówno tryby tekstowe EGA, jak i VGA pozwalają na jednoczesne 512 glifów na ekranie lub 2 banki z 256 glifami każdy. Bit atrybutu 3 (Intensywność koloru pierwszego planu) może również wybierać pomiędzy rzędem A lub B. Zwykle zdarza się, że domyślnie rejestry czcionek A i B wskazują na ten sam adres, co daje tylko 256 glifów. Aby więc zadziałało, musisz ustawić odpowiednie rejestry czcionek.

Każdy bank ma 8192 bajtów, a każdy z 256 glifów w banku ma 32 bajty (8 pikseli szerokości i 32 piksele wysokości). Możesz ustawić rejestr Scanline Count, aby podawać prawidłową wysokość twoich znaków. Karty VGA drukują 400 linii skanowania na ekranie, podczas gdy EGA drukują 350 linii skanowania na ekranie, dlatego w celu uzyskania 25 wierszy znaków ustawiają wysokość znaków odpowiednio na 16 i 14 linii skanowania. Również w VGA każdy glif może mieć 8 lub 9 kropek szerokości, ale dziewiąta kolumna jest pusta lub po prostu powtarzana jest ósma kolumna. Wszystkie te glify w obu bankach mogą być zdefiniowane przez użytkownika.

Jak uzyskać ponad 256 różnych znaków na ekranie w niektórych językach? W powyższych przykładach każda specjalna obca postać składa się z dwóch glifów (lewej i prawej) lub więcej. Możesz ustawić pierwsze, powiedzmy, 128 glifów z banku A oddzielnie dla tekstu ASCII, a nadal będziesz mieć 128 glifów z banku A + 256 glifów z banku B = 384 glifów do dostosowania.

Możesz także łączyć różne lewą i prawą stronę, aby stworzyć ogromny zestaw znaków! Powiedzmy na przykład, że z 384 zdefiniowanych przez użytkownika glifów chcesz zarezerwować 184 dla lewych i 200 dla prawych: możesz mieć 184 * 200 = 36800 różnych znaków! (oczywiście, większość z nich prawdopodobnie byłaby niepoprawnymi znakami dla tego języka, ale nadal można uzyskać dużą liczbę prawidłowych kombinacji).

W powyższym przykładzie w języku japońskim znaki „ha” i „ba” dzielą lewy glif. To samo dotyczy charaterów „si” i „zi”. „Ko” i „ni” prawe strony są tak podobne, że mogą dzielić ten sam glif po prawej stronie. To samo można powiedzieć o znakach „ru” i „ro”. Przy dobrym projekcie możesz bardzo dobrze rozbudować swój zestaw postaci. Glif po prawej stronie znaku „le” pojawia się w lewym górnym rogu ekranu (w kolorze szarym), a na pionowym pasku przewijania zmieniono również przyciski góra i dół, co oznacza, że ​​przynajmniej część banku A został również wykorzystany do dostosowania nowych glifów.

Podsumowując, funkcje łańcucha BIOS we wczesnych czasach PC nie były świadome Unicode, ale nie musi tak być. Wystarczyło dostosować 512 glifów i ustawić odpowiednie rejestry EGA lub VGA. Na przykład możesz dostosować glify „! @” „# $” „% ^” ”I *„ „çé” „ñÑ” do swoich obcych znaków (w banku A lub B), a następnie wydrukować BIOS ”! @ # S% ^ & * çéñÑ "naraz. System BIOS nie sprawdza glifów. Nie można również w ogóle korzystać z funkcji BIOS-u, ponieważ można pisać bezpośrednio w pamięci wideo. Aby użyć glifu z banku B, wystarczy ustawić atrybut Kolor pierwszego planu na wartość między 8 a 15 (jasny kolor).

(przepraszam za mój zły angielski)

Zrobiłem badania i, jak się spodziewałem, musisz użyć trybu graficznego lub potrzebujesz specjalnego wsparcia sprzętowego, ponieważ nie ma możliwości użycia więcej niż 512 znaków w trybie tekstowym VGA

Cóż, sam DOS nie może drukować w zestawach znaków przekraczających 1 bajt na znak, ponieważ korzysta z funkcji BIOS-u, które z kolei korzystają ze sprzętu VGA, który nie może mieć czcionek o rozmiarze większym niż 2 x 256 znaków. To znowu brzmi jak praca dla KIEROWCY, który używa trybu graficznego do renderowania obszernych czcionek. Mamy już obsługę czcionek Unicode w kilku graficznych edytorach tekstowych DOS i podobnych (dzięki :-)) i niezależnie od tego, czy używany jest DBCS, czy UTF-8, oba mają „rozmiar znaku może wynosić jeden lub więcej bajtów” obsługujących „anomalię” .

Czy w FreeDOS będzie kiedykolwiek oficjalne wsparcie dla języka japońskiego?

Japońskiej wersji DOS (DOS / V) używa pierwszego podejścia i symuluje tryb tekstowy przez renderowania znaków w trybie graficznym za pomocą specjalnego sterownika. Sterownik jest zgodny ze standardem IBM V-Text, który jest mechanizmem rozszerzającym możliwości wyświetlania tekstu w systemie DOS. Możesz wybierać między różnymi czcionkami 16/24/32/48-kropkowymi, takimi jak to

Niektóre inne systemy trybu tekstowego również używają tej samej techniki. W FreeDOS możesz załadować specjalny sterownik do japońskiego wsparcia

Moduł renderujący przechwytuje połączenia między godzinami 10 i 21 godzin i rysuje tekst ręcznie, więc będzie działał nawet dla normalnych programów w języku angielskim. Ale to nie będzie działać w przypadku programów, które zapisują bezpośrednio w pamięci VGA. W przypadku drukowania japońskie znaki int 5h i int 17h są również zaczepione.

Zgodnie z instrukcją DOS / V później IBM BIOS dodał także obsługę V-Text przez int 15h z następującymi 4 nowymi funkcjami

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

Podejrzewam, że jest to również powód, dla którego widziałem wsparcie japońskie w BIOS-ach moich starych komputerów

Niemniej jednak powolność trybu graficznego może powodować usterki podczas przewijania, które wymagają specjalnej obsługi

DOS / V to tak naprawdę pierwsze oprogramowanie dla japońskiego trybu tekstowego

Tymczasem od wczesnych lat 80. XX wieku w IBM Japan prowadzone były poważne badania mające na celu opracowanie rozwiązania programowego problemu wyświetlania japońskich znaków. Wraz z pojawieniem się monitorów VGA o wysokiej rozdzielczości, szybszych procesorów oraz większych pamięci i dysków twardych, projektanci z laboratoriów badawczych IBM Fujisawa i Yamato zdali sobie sprawę, że informacje o kształcie i rozmiarze znaków kanji można przechowywać na dysku, ładować do rozszerzonej pamięci, i wyświetlane przez VRAM w trybie graficznym. (Nawiasem mówiąc, „V” w DOS / V pochodzi od monitora VGA niezbędnego do wyświetlania japońskich znaków za pomocą oprogramowania.)

DOS / V: Soft (ware) Rozwiązanie trudnych (ware) problemów

Zgodnie z tym samym artykułem, przed wynalezieniem DOS / V inne systemy wymagają pamięci ROM Kanji

Wszystkie marki komputerów korzystały z rozwiązań sprzętowych do obsługi wyświetlania japońskich znaków, przechowując dane wszystkich znaków na specjalnych układach zwanych ROM-ami kanji. Ta metoda wymagała wysłania do procesora dwubajtowego kodu dla każdego znaku klawiatury, który z kolei pobrał odpowiedni znak z pamięci ROM kanji i wysłał go na ekran za pośrednictwem VRAM w trybie tekstowym. Zastosowanie pamięci podręcznej kanji ROM oznaczało, że kształt każdego znaku został ustalony, natomiast użycie pamięci VRAM w trybie tekstowym ustawiało standardowy rozmiar kropki 16 x 16 dla każdego znaku.

Na przykład IBM Personal System / 55, który korzysta ze specjalnego adaptera graficznego z japońską czcionką, aby uzyskać tryb prawdziwego tekstu

Na początku lat 80. firma IBM Japan wydała dwie linie komputerów osobistych z procesorem x86 dla regionu Azji i Pacyfiku, IBM 5550 i IBM JX. 5550 odczytał czcionki Kanji z dysku i narysował tekst jako znaki graficzne na monitorze o wysokiej rozdzielczości 1024 x 768.

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

Podobnie jak w przypadku IBM 5550, tryb tekstowy miał 1040 x 725 pikseli (czcionka 12 x 24 i 24 x 24 piksele, 80 x 25 znaków) w 8 kolorach, może wyświetlać japońskie znaki odczytywane z pamięci ROM czcionek

Architektura AX używa specjalnego adaptera jėga zamiast standardowego EGA

AX (Architecture eXtended) to japońska inicjatywa komputerowa, która rozpoczęła się około 1986 r., Aby umożliwić komputerom obsługę dwubajtowego (DBCS) japońskiego tekstu za pomocą specjalnych układów sprzętowych, jednocześnie umożliwiając kompatybilność z oprogramowaniem napisanym dla zagranicznych komputerów IBM.

...

Aby wyświetlać znaki Kanji z wystarczającą klarownością, maszyny AX miały ekrany JEGA (ja) o rozdzielczości 640x480 zamiast standardowej rozdzielczości EGA 640x350 dominującej gdzie indziej w tym czasie. Użytkownicy zazwyczaj mogą przełączać się między trybami japońskim i angielskim, wpisując „JP” i „US”, co również wywołuje AX-BIOS i edytor IME umożliwiający wprowadzanie japońskich znaków.

Późniejsze wersje dodają również specjalny sprzęt AX-VGA / H i AX-VGA / S do emulacji oprogramowania na VGA

Jednak wkrótce po wydaniu AX firma IBM wydała standard VGA, z którym AX oczywiście nie był kompatybilny (nie tylko one promowały niestandardowe rozszerzenia „super EGA”). W związku z tym konsorcjum AX musiało zaprojektować zgodny AX-VGA (ja). AX-VGA / H była implementacją sprzętową z AX-BIOS, natomiast AX-VGA / S była emulacją oprogramowania.

Z powodu mniej dostępnego oprogramowania i innych problemów, AX zawiódł i nie był w stanie przełamać dominacji PC-9801 w Japonii. W 1990 r. IBM Japan zaprezentował DOS / V, który umożliwił IBM PC / AT i jego klonom wyświetlanie japońskiego tekstu bez dodatkowego sprzętu przy użyciu standardowej karty VGA. Wkrótce potem AX zniknął i zaczął się spadek NEC PC-9801.

Seria NEC PC-98 ma także znak ROM w kontrolerze wyświetlacza

Standardowy PC-98 ma dwa kontrolery wyświetlacza µPD7220 (master i slave) z odpowiednio 12 KB pamięci głównej i 256 KB pamięci wideo RAM. Główny kontroler wyświetlania obsługuje pamięć ROM czcionek, wyświetlając znaki JIS X 0201 (7 x 13 pikseli) i JIS X 0208 (15 x 16 pikseli)

Nie znam sytuacji w Chinach i Korei, ale myślę, że stosowane są te same techniki. Nie jestem pewien, czy istnieją inne sposoby na osiągnięcie tego, czy nie

Potrzebujesz trybu graficznego zamiast trybu tekstowego, aby móc wyświetlać glify tekstu w trybie Unicode. Następnie ustaw MS-DOS na użycie czcionki Unicode i zmień mapowanie języka, aby z niego korzystać.

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