Win 2.x drivers

[Zelya]

И так, начну новую тему для узкого круга людей.
Для начала, все споем дифирамбы уважаемому SokilOff, который просто-таки маг и чародей.
Теперь по делу.
Что пробовалось:
Собрать классические видео и аудио драйвера. Видео, просто-таки выели мне мозг. Оказалось один bmp из ресурсов почему-то в каком-то странном формате. Как рисунок читается и распознается, а в ресурсы собраться не может. Пришлось его пересейвать и тогда все поехало. Но пока я до этого допер, пришлось написать свой дизассемблер (русурсы в формате вин 2.0 ни одна известная Гуглу тулза не поддерживает). Потом долго и нундо разбирался почему файл в ресурсы не лезет. В конце-концов драйвер собрался. Тут же пошли версии, ЕГА, ВГА, ВЕСА 800х600 - все круто. Правда, увы, предложенные примеры "гвоздями прибиты" к совим карточкам и адаптировать их ох как не легко. Наипростейший ВЕСА драйвер еле-еле склепал, и то не уверен что хитрых ошибок нету. Теперь про планы.
1. Пока играюсь с видео драйверами в трех направлениях:
1а. Универсализация. Чтобы ЕГА-ВГА-ВЕСА драйвер различались лишь набором переменных в памяти. В последствии их можно будет расширить вплоть до переключения режима без перезапуска Винды. Но, пока, это очень отдаленная перспектива, так как все значаения похардкоджены, вплоть до выделения памяти. Не знаю, как отреагирует система, если менять эту чать на лету.
1б. Большие расширения. Превые три режима хороши по двум причинам. Во-первых, все они включаются "старым" методом. Начиная с 1024х768, принцип обращения к БИОСу немного меняется. Но не это главная проблема. Есть еще одно дикое место. Не уверен точно, но скорее всего еще начиная от монохромных драйверов, винда немного нестандартно работает с адресами. Не углубляясь в подробности, лишь скажу, что для существующих методов отрисовки используются переменные, в которые должны влазить количество пикселей, на экране поделенные на 8. Легко посчитать, что 800х600/100 = 60 000 еще влазит в наши родные 16-бит. Любое большее расширение уже вылезет. Стало быть эту фигню придется всю переписывать, а это оооочень долго.
1в. Глубина цвета. Как я и предполагал, Винда 1.х и 2.х работает с 24-битным тру-колором, и ей пофиг, куда она передает изображение. Этим уже занимаются непосредственно драйвера. Хотелось бы для начала расшириться с 8-ми ыветов до 16-ти (так и не понял, пока, поечму Винда ограничина 8-мью цветами. захардкодженные таблицы есть, а пояснений нет). Надеюсь, эта задача не такая уж катастрофически сложная. Второй шаг - это 256 цветов, или же 24-бита. Впринципе, задаи сопоставимые по сложности. Но для этого нужно будет переписать всю рутину отрисовки.
Кстати, по 1-му пункту еще можно добавть, что я, впринципе, могу поменять все кнопочки, чекбоксики и т.д. на более опрятные, но пока, только двухцветные. Можно будет подумать о том, чтобы поправить рутину для поддержки хотя бы 8 цветов, и получить винду 2.х в стиле 3-ки. Но это не так важно.
2. Перспективы аудиодрайвера. Первоначально я просил драйвера для того, чтобы потюнать свой миди-плеер. Но уже получив их, я задумался, что я получу на выходе. Если вынести существующую миди-рутину на аудио драйвер, я получу грустную ситуацию: плеер, для которого нужен специальный дистрибутив и дистрибутив, поддержаный единственной программкой. Грустно немного. Можно, правда пойти двумя другими путями:
2а. Расширить драйвер, согласно более поздним API для мультимедиа. Но, увы, опять же, я не вижу ни одного программиста, который бы взялся писать или адаптировать софт, даже под стандартное API для Вин 2.х. Проблема, описанная выше, не снимается.
2б. Адаптировать существующие методы. Получится немного интерестная фича. Например, тот же биииип Винды, будет уже звучать, как мидишная нотка. Весь существующий софт, использующий бипер, зазвучит по-новому. Только, вот увы, такого софта я не знаю . И вторая, более серьезная проблема, то что классическое звуковое (не мультимедийное) API убого, и проигрывание миди через него будет ужастного качества.
Что посоветуете по этому пункту?
3. Клавитаура. Многоязычность наше все. Но, потом, руссификатор и так существует
4. Память. На пенсии выучить принципы работы DOS4GW и перенести его на Вин2, чтоб под "двойкой" использовать 4 гига оперативки

Как-то так. В аттаче черновая версия дров 800х600.

[Freeman]

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

Боялись, что памяти под буфера не хватит?

[Zelya]

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

Боялись, что памяти под буфера не хватит?

Нет. На кодировку 8-ми цветов, так же как и на 16, тратится байт на 2 пикселя.

[SokilOff]

Теперь про планы
...

Дифирамбы совершенно не нужны.

Глядя на вышенаписанное, я просто снимаю шляпу - это надо быть настоящим фанатом в лучшем смысле этого слова, чтобы настолько глубоко копать в "делах давно ушедших дней".
Бум ждать продолжение

[Zelya]

Недавно получил чуток свободного времени и вплотную занялся видео-дровами. Ну, что я могу сказать... "Треш, угар и содомия!". Для начала, почему только 8 цветов. Дрова работают с так называемыми битовыми плоскостями (не знаю правильно ли перевел bit plane). Грубо говоря, экран состоит из трех монохромных. Один для красного, один для зеленого и один для синего. При выводе, они накладываются друг на друга и получается 8 простых цветов. Почему так было сделано? Скорее всего чтобы проще было переносить код с монохромного драйвера. Кстати, во многих местах присутствует код и для четвертой плоскости - интенсивности, что по идее позволило бы получить 16 цветов. Увы, в некоторых местах код не дописан: кое-где регистров процессора не хватило, чтобы красиво выкрутится, а кое-где просто поленились логику писать. Сейчас логика определения цвета проста как двери. Фактически, кругом участвует только старшый бит каждой из трех составляющих цвета. Грубо говоря, цвет F0F8EF станет FFFF00 (старшие биты 110), а интенсивность нужно высчитывать более хитрыми алгоритмами. Кроме того, если сейчас каждая составляющая цвета либо 00 либо FF, то с интенсивностью нужно еще какую-нибудь 55 вводить.
Какие ужасные ограничения это на нас накладывает? Ну самое главное, очень уж негибкий код. Я очень постараюсь добавить четвертую плоскость (фактически, я ее уже добавил, но с целой кучей багов). Но вот делать что-то более универсальное куда труднее. Теперь представим, что я сильным колдунством поменял код так, чтобы можно было менять количество плоскостей на любое. Что мы получим? Например, для 8-ми плоскостей (256 цветов). Во-первых, формирование цвета прверащается в сущий ад. Во-вторых, вывод на экран теперь занимает не 3, а 8 циклов - более чем в два раза медленнее. Для 24-х бит цвета, "во-первых" - отпадает, но картинка будет выводится медленнее в 8 раз. Хотя, думаю, для компов класа 486 - первопень, это будет уже не критично. Но куда хуже с расширениями. Одна плоскость должна влазить в один стандартный видео-фрейм, а это 64К. Стало быть, максимальное расширение это 800х600. Переключать фреймы во время вывода одной плоскости - это написать тонны г...нокода и убить все быстродействие.
Так что, вот такая вот грустная ситуация. Пока, на ближайшие планы, это дописать 16 цветов, и сделать универсальный драйвер на 640ч480/800х600 с программным переключателем. Для всего остального нужно очень-очень серьезно менять код. Я даже задумываюсь не писать ли драйвер с нуля.

[Nika]

Впечатляет.

[kameleon]

zelya, а нет ли русификации для win 1.x?

[Freeman]

Дрова работают с так называемыми битовыми плоскостями (не знаю правильно ли перевел bit plane).

Да, именно так перевели этот термин в какой-то книжке то ли Нортона, то ли Джордена. Про удобство переноса с монохрома не понял. В EGA же аппаратная реализация такая?

[Zelya]

Да, именно так перевели этот термин в какой-то книжке то ли Нортона, то ли Джордена.

Да, мне тоже так припоминается, что именно этот термин я где-то видел.

Про удобство переноса с монохрома не понял. В EGA же аппаратная реализация такая?

Аппаратная реализация? Вы имеете в виде 6 проводков, RGB и вторичные RGB? Это к программированию видео отношение не имеет. С точки зрения программиста, у нас есть палитра в 16 цветов (из 64 возможных), и каждый байт видеопамяти кодирует два номера цвета из палитры. Теоретически, это могут быть 16 оттенков совершенно без красной состовляющей. Конечно, в Винде цвета подобраны так, чтобы было легче их кодировать, и номер цвета отвечает его RGB битовым значениям. Например (десятичный номер->двоичный номер->RGB):
(Внимание, RGB в Винде инвентирован в BGR!!! тоже для долбанного удобства)
0 -> 000 -> 000000 (black)
1 -> 001 -> 0000FF (red)
2 -> 010 -> 00FF00 (green)
И т.д. для всех восьми цветов.

Но прикол в том, что привязываться к битовым плоскостям не совсем оправданно. Определять номер цвета можно сразу же, и писать его в буфер/видеопамять. А экран поделить не по битовым плоскостям, а по строкам (есть такой термин scanline), тем более это на порядок проще. В нашем же случае, думается, была выбрана такая структура, так как можно использовать более половины кода из монохромных драйверов. А для ситуации в 8 простейших цветов (RGB либо 00 либо FF) битовые плоскости не накладывают никаких серьезных проблем. Зато, если мы захотим усовершенствовать такой драйвер, мы будем плакать горючими слезами (как я).

zelya, а нет ли русификации для win 1.x?

Насколько я помню, то где-то читал статью о первой (не официальной) русификации Винды 2. Из чего я делаю заключение, что первая Винда в те далекие 80-е русифицирована не была. Современников, способных на такой подвиг, можно посчитать по пальцам одной руки, и со всеми из них я был когда-то знаком. Увы, никто из них такой задачи себе никогда не ставил (да и сейчас вряд ли поставит). Так что остается мистическая надежда на неизвестного кулибина из далекой глубинки, который втихаря русифицировал первую Винду, но мы про это, пока, не знаем. Как-то так.

[Freeman]

Аппаратная реализация? Вы имеете в виде 6 проводков, RGB и вторичные RGB? Это к программированию видео отношение не имеет. С точки зрения программиста, у нас есть палитра в 16 цветов (из 64 возможных), и каждый байт видеопамяти кодирует два номера цвета из палитры.

В той книжке про битовые плоскости писалось в контексте программирования EGA на уровне портов. Если в CGA видеопамять просто отражалась на обычную, и достаточно было следить за обратным ходом луча, чтобы не было "снега", то в EGA была какая-то хитрая реализация с защелками и портами. В той книжке объяснялось, как с этим хозяйством работать.

У меня тогда книжка уже была, а компа дома не было, и пощупать не удалось.

[Zelya]

В той книжке про битовые плоскости писалось в контексте программирования EGA на уровне портов. Если в CGA видеопамять просто отражалась на обычную, и достаточно было следить за обратным ходом луча, чтобы не было "снега", то в EGA была какая-то хитрая реализация с защелками и портами. В той книжке объяснялось, как с этим хозяйством работать.

У меня тогда книжка уже была, а компа дома не было, и пощупать не удалось.

Ой, вызовы функций BIOS для рисования?! Это же не наш метод!!! Ни про какое быстродействие и речи быть не может. А в EGA, и в VGA, и даже в SVGA, так же как в CGA, видеопамять тоже мапится на адреса проца, с двумя принципиальными отличиями. Во-первых, в CGA дикий интерлейсинг (через строчная организация памяти), во всех последующих адаптерах милая глазу, линейная структура. А во-вторых, CGA он мааленький и легко влазит в одну страничку (64Кб). А остальным 64Кб не хватает, и приходится использовать окно (а иногда и два) размером в 64Кб, и ездить ними туда-сюда, чтобы заполнить всю видеопамять. Вот именно это одно или два окна, так же мапятся на адерсное пространство процессора, и обеспечивают быстрейший досутп для отрисовки пикселей. Но окна нужно двигать инстркуциями BIOSа, которые, как я уже писал, страх какие медленные. Так что двигать их нужно как можно меньше.

[Freeman]

Ой, вызовы функций BIOS для рисования?! Это же не наш метод!!! Ни про какое быстродействие и речи быть не может.

Не-не-не, там именно про порты было! С быстродействием BIOS всё понятно. Не поленился, нашел книжку. Это всё же Джордейн оказался.

[SergeCpp]

У меня ещё вот такая бумажная книжка есть: Григорьев В.Л. Видеосистемы ПК фирмы IBM. М. Радио и связь. 1993. 192 страницы, цена 65 рублей (ручкой написано сзади).

Книжка хорошая, всё детально рассказано.

Цветовые плоскости там тоже есть, глава 3 "Графические режимы".

[Zelya]

Не-не-не, там именно про порты было!

Да Вы правы, режим записи 0, судя по книжке, как раз то, про что Вы и говорите, в отличие от режима 2, где нужно шифтать маску в порте, но можно писать сразу все плоскости просто посылая 4 бита:

Режим записи 2 предоставляет альтернативный способ установки
отдельных точек. Процессор посылает данные, у которых имеют зна-
чение только 4 младших бита, которые рассматриваются как цвет
(индекс регистра палетты).

"Палетты" каков термин, а?
Так что Ваш аргумент в пользу плоскостей выглядит вполдне логичным. Только вот проверять как оно в коде, мне пока некогда.

[SokilOff]

Насколько я помню, то где-то читал статью о первой (не официальной) русификации Винды 2. Из чего я делаю заключение, что первая Винда в те далекие 80-е русифицирована не была.

Да, собственно, можно даже посмотреть, на что это было похоже.