Как MS-DOS и другие программы в текстовом режиме могут отображать символы CJK двойной ширины?

3393
phuclv

Я видел много экранов настройки BIOS текстового режима на японском и китайском языках. Недавно я даже видел установку Windows XP на японском языке. У MS-DOS были и японские версии. Настоящий режим DOS, а не командная строка Windows!

Japanese BIOS setup

Japanese MS-DOS 6.2

Один типичный экран текстового режима имеет размер 80x25 . Поскольку японский символ занимает целую двойную ширину латинского символа, максимальное количество японских символов, которое может отображаться одновременно на экране, составляет около 1000. Поэтому нам нужно 2000 кодовых точек для отображения левой и правой части символов.

По умолчанию текстовый режим может отображать только 256 символов, но первые 128 используются для ASCII, поэтому используемые можно ограничить до 128 кодовых точек. При необходимости мы можем расширить его до 512, но он по-прежнему не может поддерживать достаточное количество кодов для отображения. Мне всегда интересно, как им удалось отобразить большой набор символов с таким ограниченным количеством символов.

[ Japanese XP installer] 8]

Текстовый режим в Linux, кажется, использует драйвер графического режима, потому что он может отображать Unicode и имеет намного больше цветов. Но я не могу объяснить, как они это делают на экранах настройки MS-DOS и BIOS.


РЕДАКТИРОВАТЬ: я даже нашел японский ввод текста для DOS

Japanese IME

В текстовом режиме тоже есть корейский!

Korean

VMWare Korean DOS

7
Вы, вероятно, смотрите не на японские «иероглифы», то есть * кандзи *, а скорее * хирагана * или * катакана *, которые имеют сопоставления Unicode. sawdust 10 лет назад 0
@sawdust: посмотрите на картинку выше, и вы увидите, что она может отображать не только все кана, но и кандзи phuclv 10 лет назад 0
Обратите внимание, что [страница, с которой вы, вероятно, взяли снимок экрана установщика OS / 2] (http://www.os2museum.com/wp/?p=1700), прямо рядом со снимком экрана сказано, что «поддержка графического текстового режима была инициализирована почти сразу при загрузке OS / 2 ". Ключевое слово * графический *. a CVn 9 лет назад 1
@ MichaelKjörling, это не только OS / 2, но и программы установки MS-DOS и BIOS имеют эту возможность и в текстовом режиме phuclv 9 лет назад 0

4 ответа на вопрос

4
a CVn

Обычный режим «80x25 символов» на самом деле составляет 720x350 пикселей (это означает, что каждая ячейка символа имеет ширину 9 пикселей и высоту 14 пикселей). Символьные режимы двойной ширины («40x25») могут либо просто интерполировать это на большую ширину, удваивая каждый столбец, чтобы сэкономить на памяти видеоконтента (сокращая необходимый объем памяти видеоконтента в два раза), либо использовать дополнительную память глифа и идентичный объем памяти видеоконтента для увеличения ячеек персонажа до 18 * 14 пикселей.

Довольно рано (я думаю, что это было сделано, когда была представлена EGA ), в режим текстового отображения на IBM PC была добавлена ​​поддержка пользовательских глифов символов.

Обычный текстовый режим IBM PC - это просто 4000 байтов ОЗУ видеоконтента по определенному адресу. Они считываются как один байт символьных атрибутов (первоначально мигающий, полужирный, подчеркивание и т. Д .; затем повторно используется для цветов переднего плана и фона и мигающий / выделенный, отсюда ограничение до 16 цветов в текстовом режиме) и один байт, описывающий символ для отображаться. Фактический глиф, отображаемый для каждого значения байта символа, хранится в другом месте.

Это означает, что до тех пор, пока вы можете обойтись с 256 различными глифами на экране в любое время, и каждый глиф может быть представлен как однобитное растровое изображение 9x14, вы можете просто заменить глифы в памяти, чтобы символы выглядели по-разному, Частично это была одна часть того, что mode con codepage selectделали в DOS. Это относительно тривиально.

Если вам нужно более 256 различных символов, но вы можете жить с уменьшенным количеством символов на экране, вы можете использовать схему 40x25 с символами двойной ширины (18 пикселей в ширину). Предполагая, что общий объем ОЗУ видеоконтента фиксирован, и предполагая, что вы можете увеличить объем памяти растрового изображения глифа, вы можете перейти к использованию двух байтов из каждых четырех байтов для представления одного экранного глифа, предоставляя вам доступ к 2 ^ 16 = 65 536 различных символов (включая пустой символ). Если вы чувствуете смелость, вы можете даже пропустить второй байт атрибута, который дает вам доступ к 2 ^ 24 ~ 16,7M различным символам. Оба этих подхода основаны на специальной поддержке программного обеспечения, но часть аппаратного и встроенного программного обеспечения должна быть довольно простой. 65 536 символов с разрешением 18x14 однобитных пикселей занимают около 2 МБ, что является значительным, но не непреодолимым объемом памяти в то время.

Базовому американскому английскому языку нужно как минимум 62 выделенных глифа (цифры 0-9, буквы AZ в верхнем и нижнем регистре), поэтому у вас есть что-то вроде 180-190 глифов для игры, если вы также хотите иметь возможность отображать текст на английском языке США время и идти с 8 битами на глиф. Если вы можете жить без одновременной поддержки американского английского, что вы можете сделать в среде с ограниченными ресурсами, такой как ранняя архитектура IBM PC, у вас есть доступ к полному количеству глифов.

С некоторой хитростью вы могли бы, вероятно, смешать и сопоставить две схемы тоже.

Я не знаю, как это было на самом деле, но обе они являются жизнеспособными схемами для того, чтобы вывести «причудливые» алфавиты с особенно ограниченным числом символов на простой экран IBM PC в текстовом режиме, которые я могу придумать, просто сидя впереди. стек обмена на мгновение. Вполне возможно, что есть дополнительные графические режимы, которые делают это проще на практике.

Также имейте в виду различие между текстовым режимом и графическим режимом отображения текста . Если вы работаете в графическом режиме, возможно, с помощью VESA, который довольно универсально поддерживается, вы можете самостоятельно рисовать глифы символов, но у вас также есть гораздо больше свободы в их рисовании. Например, я уверен, что текстовые части Windows NT (к которому относится семейство продуктов, к которому относится Windows XP) используют графический режим для отображения текста, включая загрузочный экран Windows NT 4.0 и BSOD.

Вы можете видеть, что латинские символы нормальной ширины помимо японских / корейских символов двойной ширины, поэтому это не может быть режим двойной ширины 40x25. Поэтому вы не можете объединить 2 байта каждые 4 байта для представления глифа. Используя бит 3 цвета переднего плана, вы можете представить 512 символов одновременно, но этого недостаточно, если символы заполняют большую часть экрана https://en.wikipedia.org/wiki/VGA-compatible_text_mode#Fonts phuclv 10 лет назад 0
@ LưuVĩnhPhúc Вы можете повторно использовать старший бит или использовать любое количество возможных других приемов для смешивания многобайтовых символов с однобайтовыми. Я все еще думаю, что ответом является признание заявления, сделанного в первом абзаце: даже при отображении символов на каком-то уровне вы все еще имеете дело с пикселями, и с этими пикселями можно работать, даже если, возможно, не напрямую. a CVn 10 лет назад 0
Я знаю все о текстовом и графическом режиме отображения текста, просто путаю, как у них достаточно кодовых точек для многобайтовых данных, так как левая и правая части требуют 2 кодовых пункта. Но из того, что ты сказал, я подумал о другом способе сделать это. Я думаю, что ваш ответ приемлем phuclv 10 лет назад 0
1
LawrenceC

Это упрощает то, что говорит @Michael Kjörling.

В текстовом режиме у вас есть «экранная память», которая имеет 1 байт на экранный символ, который сообщает адаптеру, какой символ появляется в каждой позиции экрана. (Существуют также байты «атрибута», которые сообщают адаптеру, какого цвета и что-то вроде подчеркивания, мигания и т. Д.).

Адаптер использует этот байт для индексации в другую «таблицу символов», которая имеет маленькую 8x12 или любую другую битовую карту символа. DOS называет эту таблицу символов кодовой страницей.

Начиная с CGA, вы можете сказать адаптеру, чтобы он получал таблицу символов в определенном месте в оперативной памяти адаптера. У каждого адаптера есть символьное ПЗУ, в котором есть «шрифт» по умолчанию для этой карты (который является стандартным шрифтом IBM), но вы можете указать адаптеру переключиться в какое-либо место в ОЗУ и поместить туда свои собственные изображения.

Пока программное обеспечение знает, что происходит, коды в экранной памяти, которые указывают на изображения в таблице символов, не совпадают с какими-либо кодами ASCII, хотя легче, если они это делают. Вы заметите, что есть коды экранной памяти (и формы таблиц символов) для 1-31, которые являются непечатаемыми символами ASCII, но записывая их непосредственно в память экрана (любящие воспоминания DEFSEG = &HB800 : POKE 0,1в GW-BASIC для изменения самого верхнего символа на смайлик приходят к ум) вы все равно можете их отобразить.

Поэтому отображение других языков - это хорошо, если вы можете поместить нужные изображения в оперативную память адаптера и иметь необходимую программную поддержку.

Это было уже в CGA? Должно быть, я старею. (В свою очередь, я написал этот ответ в основном по памяти и фактически никогда не использовал эти приемы даже для развлечения, как всегда.) a CVn 10 лет назад 0
Я думаю, что вы сразу после того, как изучили это, это было EGA. LawrenceC 10 лет назад 0
Я знаю, что мы можем изменить шрифт текста, изменив указатель, я узнал, как это сделать много лет назад, просто не знаю, как они могут представлять двухбайтовый набор символов, поскольку 256 или 512 кодовых точек не могут даже удерживаться достаточно максимального количества разных символов на экране, не считая всей сложной кодировки phuclv 10 лет назад 0
0
phuclv

Я провел некоторое исследование, и, как я и ожидал, вы должны использовать графический режим или специальную аппаратную поддержку, потому что в текстовом режиме VGA невозможно использовать более 512 символов.

Что ж, сама DOS не может печатать в кодировках, превышающих 1 байт на символ, потому что она использует функции BIOS, которые, в свою очередь, используют аппаратное обеспечение VGA, которое не может иметь шрифты размером более 2 x 256 символов. Так что это снова звучит как работа для ДРАЙВЕРА, который использует графический режим для рендеринга обширных шрифтов. У нас уже есть поддержка шрифтов Unicode в нескольких графических текстовых редакторах DOS и аналогичных (спасибо :-)), и независимо от того, используются ли DBCS или UTF-8, оба имеют общий «размер символа может составлять один или несколько байтов» для обработки «аномалии» ,

Будет ли когда-нибудь официальная поддержка японского языка во FreeDOS?

Японская версия DOS (DOS / V) использует первый подход и имитирует текстовый режим с помощью визуализации символов в графическом режиме, используя специальный драйвер. Драйвер следует стандарту IBM V-Text, который является механизмом расширения возможностей отображения текста в DOS. Вы можете выбрать один из 16/24/32/48-точечных шрифтов, как этот

DOS/V font

Некоторые другие системы текстового режима также используют ту же технику. В FreeDOS вы можете загрузить специальный драйвер для поддержки японского языка.

FreeDOS Japanese driver

Рендерер будет перехватывать вызовы int 10h и int 21h и рисовать текст вручную, поэтому он будет работать даже для обычных программ на английском языке. Но это не будет работать для программ, которые записывают в VGA-память напрямую. Для печати японских символов int 5h и int 17h также подключены.

Согласно руководству по DOS / V позже, IBM BIOS также добавил поддержку V-Text через int 15h с помощью 4 новых функций, указанных ниже.

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

Я полагаю, что это также причина, по которой я увидел поддержку японского в BIOS моих старых ПК

Тем не менее, медлительность графического режима может вызвать сбои при прокрутке, что требует особой обработки

DOS / V на самом деле является первым программным решением для японского текстового режима

Между тем, с начала 1980-х годов в IBM Japan проводились серьезные исследования, направленные на разработку программного решения проблемы отображения японских символов. С появлением VGA-мониторов с высоким разрешением, более быстрых процессоров, больших объемов памяти и жестких дисков дизайнеры исследовательских лабораторий IBM Fujisawa и Yamato поняли, что информация о форме и размере символов кандзи может храниться на диске и загружаться в расширенную память. и отображается через графический режим VRAM. (Кстати, буква "V" в DOS / V исходит от монитора VGA, необходимого для отображения японских символов с помощью программного обеспечения.)

DOS / V: Мягкое (изделие) решение для аппаратных проблем

Согласно той же статье, до изобретения DOS / V для всех других систем требовалось ПЗУ Кандзи в аппаратном обеспечении.

Все бренды компьютеров использовали аппаратные решения для обработки отображения японских символов, сохраняя данные для всех символов на специальных чипах, известных как ПЗУ кандзи. Этот метод требовал отправки двухбайтового кода для каждого символа ввода с клавиатуры в ЦП, который, в свою очередь, извлек соответствующий символ из ПЗУ кандзи и отправил его на экран через VRAM в текстовом режиме. Использование Кандзи ПЗУ означало, что форма каждого символа была фиксированной, в то время как использование текстового режима VRAM устанавливало стандартный размер точки 16x16 для каждого символа.

Например, IBM Personal System / 55, которая использует специальный графический адаптер с японским шрифтом, чтобы они получали реальный текстовый режим

В начале 1980-х годов IBM Japan выпустила две линейки персональных компьютеров на базе x86 для азиатско-тихоокеанского региона: IBM 5550 и IBM JX. 5550 считывал шрифты кандзи с диска и рисовал текст в виде графических символов на мониторе высокого разрешения 1024 x 768.

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

Аналогично IBM 5550, текстовый режим был 1040x725 пикселей (шрифт 12x24 и 24x24 пикселей, 80x25 символов) в 8 цветах, может отображать японские символы, считанные из ROM-шрифта

Архитектура AX использует специальный адаптер JEGA вместо стандартного EGA

AX (Architecture eXtended) - это японская компьютерная инициатива, начавшаяся примерно в 1986 году, которая позволила ПК обрабатывать двухбайтовый (DBCS) японский текст через специальные аппаратные микросхемы, обеспечивая совместимость с программным обеспечением, написанным для иностранных компьютеров IBM.

...

Чтобы отображать символы кандзи с достаточной четкостью, машины AX имели экраны JEGA (ja) с разрешением 640x480, а не стандартным разрешением EGA 640x350, распространенным в то время в других местах. Пользователи обычно могут переключаться между японским и английским режимами, набирая «JP» и «US», что также вызывает AX-BIOS и IME, позволяющие вводить японские символы.

Более поздние версии также добавляют специальное оборудование AX-VGA / H и AX-VGA / S для программной эмуляции на VGA.

Однако вскоре после выпуска AX IBM выпустила стандарт VGA, с которым AX явно не был совместим (они были не единственными, кто продвигал нестандартные расширения «super EGA»). Следовательно, консорциум AX должен был разработать совместимую AX-VGA (ja). AX-VGA / H был аппаратной реализацией с AX-BIOS, тогда как AX-VGA / S был программной эмуляцией.

Из-за менее доступного программного обеспечения и других проблем AX не удалось и не смог сломить доминирование PC-9801 в Японии. В 1990 году IBM Japan представила DOS / V, которая позволила IBM PC / AT и его клонам отображать японский текст без какого-либо дополнительного оборудования с использованием стандартной карты VGA. Вскоре после этого AX исчез, и начался упадок NEC PC-9801.

Серия NEC PC-98 также имеет символьное ПЗУ в контроллере дисплея

Стандартный PC-98 имеет два контроллера дисплея µPD7220 (главный и подчиненный) с 12 КБ основной памяти и 256 КБ видеопамяти соответственно. Главный контроллер дисплея обрабатывает ПЗУ шрифтов, отображая символы JIS X 0201 (7x13 пикселей) и JIS X 0208 (15x16 пикселей)

Я не знаю ситуацию для китайского и корейского, но я думаю, что используются те же методы. Я не уверен, есть ли другие способы достичь этого или нет

-1
headkase

Вам нужен графический режим вместо жестко закодированного текстового режима, чтобы можно было отображать текстовые символы Юникода. Затем вы устанавливаете MS-DOS для использования шрифта Unicode и изменяете отображение языка, чтобы использовать его.

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

Нет, посмотрите на изображения, которые я выложил, это настоящий режим DOS, а не командная строка в Windows phuclv 10 лет назад 0