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

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

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

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

Сообщение отредактировал mantech - Feb 21 2014, 18:36

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

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


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


Вы уж определитесь 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 было в свое время. Только мне это не подходит - пользователи аппаратов в случае повреждения винды или диска не смогут сами так все доработать. Мое видение таково - чем проще система - тем стабильнее работа! Согласитесь, куда прощеформатануть флеху, скопировать туда прогу плюс каталог с картинками, вставить в плату промкомпа и включить! Что тут можно испортить?

Сообщение отредактировал mantech - Feb 23 2014, 07:32

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


Что касается 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 ГГц !

Сообщение отредактировал mantech - Feb 23 2014, 19:10

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

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

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

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

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

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