Приветствую. Собственно встал вопрос, как правильно работать с весовскими режимами(0х112, 0х115 и 0х118) под чистым досом?

Пользуюсь watcom C под98й виндой (в ХР он не работает), работают все 256и цветные режимы, на остальных пишет неверный видеоконтроллер. Сначала думал, что эти режимы просто не работают, но в инете нашел прогу VESA16M, в которой все прекрасно работает. Ответ - сам дурак! Может у кого есть какие-нить исходники под это дело?

странно. гугл выдает на первом месте: http://sources.codenet.ru/download/1062/VESA16M.html Только не надо говорить, что там асм+кубасик, а надо на си.

Да мне все-равно на чем - лишь бы исходники были рабочие и работали c PM(dos4gw).
ЗЫ. И там по этой ссылке только готовый бинарник - исходников нет.

а для чего?
правда очень интересно.

Тоже интересно для чего?
Ведь гораздо проще писать под виндоус.


Сразу не правильно. Забудьте нет фиксированных режимов. Режимы надо перебирать и искать подходящий.


Вы уж определитесь win98 или чистый DOS. Просто под VDM будет чуть по сложнее.

dos4gw с этой штукой почти не работал не помню, что к чему.
http://www.tenberry.com/dos4g/faq/video.html
Обращаю внимание что для работы с VESA в dos4gw нужно вызывать функции через DPMI.

Если под чистый DOS читай VESA спецификацию. Есть статьи их куча к примеру вот.
http://www.osp.ru/pcworld/1998/07/159374

А теперь про сложности.
1. Графическую библиотеку надо будет создавать или портировать.
2. Баги в железе.

Не удобно работать с банковым режимом, лучше работать с линейным буфером.
Нужно будет отобразить, а это зависит от DPMI и dos4gw реализации. Тут свои тараканы так как под дос одна реализация DPMI под виндоус другой.

По поводу портирования я бы остановился на AGG хотя тут надо смотреть может что по лучше по проще есть.

Ребят, я конечно это понимаю
Почему? Всеочень просто, пишу программу для промавтоматики, работающей в режиме 24х7 без участия оператора. Сейчас все работает под винду ХР и 7. С самой программой и подключенными к ней контроллерами проблем нет,а вот винда.... Постоянно что-то с ней не так, то экран внезапно "засыпает", хотя все настройки сделаны в режим "никогда", то отваливается усб порт, иногда просто перезагруз или вдруг трей вылезет поверх программы, ну и напоследок - включение-отключение компа - раз 20-30 все проходит на ура, а потом либо не выключится или при включении запускается безопасный режим... вобщем достала меня эта винда!



А чего тут неопределенного? Программа под чистый дос, а иде у ваткома под дос нет, поэтому работаю из 98й винды

была библиотека allegro, что-то вроде SDL, старые версии поддерживали DOS. что-то умела с графикой, гляньте, может поможет.

но имхо Linux, *BSD и даже QNX, а то и вообще странные варианты вроде reactOS или haiku.
даже при отсутствии вообще каких-либо знаний об этих ОС, выглядят куда более адекватно чем попытка сделать графику под DOS.
да и описанные проблемы под windows выглядят странно, и вполне решаемо.
на решения beckhoff с их twincat посмотрите, вполне под windows живут и ничего, даже с каким-то realtime.

Вы для музея чтоли пишете

Я не спорю, может и живут, только там скорее всего винда очень урезана и допилена, как например для mach 3 было в свое время. Только мне это не подходит - пользователи аппаратов в случае повреждения винды или диска не смогут сами так все доработать. Мое видение таково - чем проще система - тем стабильнее работа! Согласитесь, куда прощеформатануть флеху, скопировать туда прогу плюс каталог с картинками, вставить в плату промкомпа и включить! Что тут можно испортить?

Была такая контора SciTech, делала SVGAKIT - эту библиотеку использовало множество разработчиков досовых игр.
В принципе, там только инициализация видеорежима и эмуляция части функций VESA BIOS для старых карт,
которые этих функций не имеют. У меня есть сам SDK и демы к нему, к сообщению прикрепил лишь инсталлятор от
SciTech с исходниками, остальное не влезло.
Нажмите для просмотра прикрепленного файла

Что касается Watcom, до того, как он стал open-source - у него была IDE под Дос.
И замените сам DOS4GW - уж больно он большой. Я использовал "ZRDX by Sergey Belyakov".

Спасибо, посмотрю обязательно. А если еще скините хоть один-два рабочих примера - буду очень признателен.

ЗЫ. Режим вроде запустил, единственное - работа через int 10h уж очень медленно...



А чем это грозит в защищенном режиме? Просто этот экстендер уже проверен десятилетиями

Если будете рисовать через БИОС - и должно быть жутко медленно.
Вам проще использовать любой 256-цветный палитровый режим (1 байт на точку).
Устанавливаете требуемый режим (он должен иметь поддержку линейного режима - там бит где-то об этом говорит).
Далее отображаете область памяти видеоадаптера на память вашего процесса средствами дос-экстендера (в защищенном режиме).
И потом устанавливаете значение пиксела (Х,У) по адресу (byte*)base_addr+Y*stride+X, где stride - количество байтов в одной строке,
а base_addr - указатель на начало области памяти (видеоадаптера...).
Палитру либо загружаете через порты, либо средствами БИОС.
Как-то так, за давностью лет все уже смутно помнится.

Что касается экстендера - дело ваше. Наверное, у вас нет проблем с размером ПО.
ZRDX, насколько я помню, не обеспечивал полной совместимости с ДОС4ГВ.
Просто он раз в 10 меньше. Плюс я в него еще пихал некоторые свои функции.

В приложении - демы от SciTech SVGAKIT.

Дак вот в том-то и дело, что 256 не подходит - заказчику нужно полноцветные PNG картинки, с самим форматом проблем нет особых, а вот с видеокартой, совсем другое. Та скорость, с которой отрисовывается через int 10h - 2 сек кадр - тут никуда не годится.
Причем я бы понял, еслиб это был какой-нить 486 проц, а тут все-таки pentium M-1,5 ГГц !

Любой HiColor или TrueColor режим. При линейном доступе разница лишь в адресации.
Адрес пиксела задается как (byte*)base_addr+Y*stride+X*byteperpix, где byteperpix - количество байт на один пиксел.
TrueColor в использовании проще, да и цветов больше (по байту на каждый цвет).

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

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

Есть еще всякие средства ускорения типа VBE/AF, но вам это не нужно. Сложности добавит, а на результате не особо скажется.

В общем, если откажетесь от работы через БИОС - раз в 20 как минимум быстрее будет.

Видимо так и нужно. Посмотрел демки, там почти всепод старую винду, но есть одна под дос, и там как раз то, что нужно - работа с 16м цветов через linear frame buffer по времени укладывается в задачу. Будем копать в эту сторону

PS. Посмотрел я на эти исходники есть одно НО -

Can also be compiled to use the UVBELib linkable library
* version of UniVBE for direct device support. Contact
* SciTech Software for licensing information on this library.

И где брать эти либы?

Исходники SVGAKIT были в моем первом посте.
Непосредственно библиотеку смотрите здесь.

Спасибо большое. Я вроде как разобрался, скачал в инете какие-то малоизвестные исходники realtech, там всего 5 файлов, и работает!! Заполнение экрана 800х600х32 за 0.05 сек!!
Осталось гуй прикрутить...

Ну так поделись с этими малоизвестными исходниками)

Да, и не забудьте для видеобуфера включить режим кэширования Write Combine! Скорости записи в видеопамять может легко раз в 20 возрасти на Pentium M

Вместо ДОС предлагаю рассмотреть Kolibri OS должна перекрыть ваши потребности программирования Пром Автоматики где варианты её
использования тоже были. На форуме Kolibri OS могут помочь ответами.
Ядро ОС пишется на ассемблере, но также используются разные кросс компиляторы и портированные инструментальные средства.

P.S. Vesa в впилена в ядро. Правда ядро стартует от P100 процессора, но есть возможность и изменить ядро на более ранние и экзотичные CPU
ДОС Box для неё тоже есть