OSDev

Что в подавляющем большинстве случаев не мешает использовать юникод в текстовых режимах, естественно, путем перекодировки в консольную кодировку. В текстовой (да и не только) консоли обычно используется очень небольшое подмножество юникода - ASCII плюс 1-2 символьных (не иероглифических) алфавита. Т.е. часто даже не надо специально формировать шрифт для текстового режима, достаточно выбрать шрифт в какой-либо подходящей консольной кодировке и в процессе вывода выполнять перекодирование из юникода (я использую UTF-16) в консольную кодировку. Т.к. у меня поддерживается одновременный вывод 512 различных символов (2 шрифта по 256 символов), то к примеру один (основной) шрифт можно использовать для какой-то определенной консольной кодировки, а второй (дополнительный) шрифт формировать в процессе перекодировки для "символов-исключений" (если они будут появляться), которым нет соответствия в используемой консольной кодировке, и сразу же обновлять этот шрифт в знакогенераторе.

Любите вы себе создавать трудности, а потом преодолевать их. Гораздо удобнее использовать графический режим. Там нет проблем с юникодом и шрифт можно загрузить любой(8х12, 1х40, и тд). Во вторых сейчас уже все языки программирования используют юникод. Поэтому смешно читать что юникод не нужен, когда он уже признан стандартом более 10 лет назад и поддерживается всем чем только можно.

Всё это уже воплотили в BIOS. Но об этом - отдельная тема.

Терминал нужен для настройки оборудования, системной консоли, средства программирования, текстовых приложений, графических 2D-приложений, графических 3D-приложений. И в каждом случае - свои требования. От любого можно отказаться или объединить с другим. Но не зная, какие терминалы и для чего присутствуют в системе, можно ли говорить о выборе видеорежима и наборах символов?

Терминал - это по русски оконечное оборудование. И если оно поддерживает более широкие возможности, то почему бы их не использовать? Тем более плата за это минимальна.
Что касается вашего перечня. То это классификация протоколов для работы с терминалом. Что является моделью.
Для хорошего управления и построения системы используем принцип разделяй и властвуй. Что известно сто лет в обед. Применительно к программированию шаблоны, к примеру MVC-Model View Controller. Т.е модель отделена от вывода и это правильный подход в проектированию.

В графике сразу возникает забавный вопрос с определением максимального разрешения монитора, например...
А 132x50 - это веса режим, но сейчас его никто, практически, не добавляет... Есть только на довольно древних картах типа ATI8500... На матроксе был даже 132x60.

Это лишь крайняя точка при выборе правильного баланса между гибкостью и эффективностью.


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

Это не крайняя точка. Гибкую программу всегда можно сделать эффективной с минимальными затратами. А эффективную гибкой нет.


А с чего вы взяли что для ЭЛТ не надо учитывать?

Зависит от способностей программиста - как проектировщика и как кодера.

И форму маски? Непросто это...

Параметры современных мониторов определяюся через канал DDC. http://ru.wikipedia.org/wiki/Display_Data_Channel
Для LCD мониторов как правило принимают, что пиксель квадратный. По крайней мере, я не знаю исключений. Поэтому у них не должно быть проблем с геометрией, если удалось считать его характеристики по DDC.

_________________
Yet Other Developer of Architecture.
The mistery of Yoda’s speech uncovered is:
Just an old Forth programmer Yoda was.
<<< OS Boot Tools. >>>

Графический режим 720x480 60Гц на VGA будет работать?
Текстовый вижу работает.
Можно теоритически запрограммировать из 640x480 60Гц, изменив частоту на 28 MHz и тайминги горизонтальные поменять.