VESA 1.2

Applications development, KoOS API questions
  • Цитата: "Установка видео режима через порты стандартна для всех видео карт"

    Означает ли это возможность предварительной отладки драйвера с использованием эмулятора (QEMU, например) с последующей адаптацией к конкретной видео карте?

    P.S.

    Кончаю болтать не по теме: когда начну конкретно работать - создам отдельную тему.
    Однако пока-что всё же рассчитываю на ответ :wink:
  • FireWall wrote:Цитата: "Установка видео режима через порты стандартна для всех видео карт"

    Означает ли это возможность предварительной отладки драйвера с использованием эмулятора (QEMU, например) с последующей адаптацией к конкретной видео карте?
    С устройствами работают через их регистры в памти, через порты уже не работают, но регистры у каждой видео карты разные.
    Если нужен доступ ко всем видео картам, то только VESA
  • Не понял ответа ...

    Имеется в виду НЕТ ? (- предварительная отладка на эмуляторе невозможна и/или нецелесообразна, - нужно сразу работать на конкретном железе ?)

    P.S.

    Имеется в виду видео карта только с поддержкой VESA 1.2 , в которой Kolibri OS находит только очень проблематичные видеорежимы
  • Я не понял вопроса, т.е. что вообще требуется, версия VESA не важна, если нужен какой-нибудь видео режим, то средствами VESA перебираешь имеющиеся и если твой есть то установишь его, после чего у тебя будет просто адрес на память экранного буфера в памяти самой видеокарты и рисуй там на здоровье.
    Отлаживать можно в QEMU
  • Исходный контекст:

    Был вопрос:
    (1) Насколько сложно включить линейный фрейм-буфер, управляя портами графической карты (как по In/OUT так и по их отображению в адресное пространство - MMIO)? [возможный конкретный контекст: чип i810, не поддерживающий VBE; но для которого есть Linux драйверы для разрешений >>800x600x16]

    Я имею в виду : в Protected Mode , посредством портов (in/out или MMIO) отобразить область видео-памяти в адресное пространство (в контексте i810 вроде как - просто определить, ибо чип не именет собственной видео памяти) так, чтобы ядро Kolibri OS могла использовать эту область стандартным способом. Подчеркну - сделать это без вызовов функций BIOS.

    (2)
    Я вроде как получил ответ, что это не так уж и сложно, в частности: "Установка видео режима через порты стандартна для всех видео карт." Правда у меня закралось подозрение, что я был неправильно понят ...

    Формулирую вопрос:
    (3) Насколько реален (целесообразен) план с начальным использованием QEMU для написания драйвера Kolibri OS, устанавливающего более приемлемый видео-режим?

    (4) План при этом таков:
    (а) Пишется драйвер Kolibri OS для QEMU (эмулиремой видео-карты), который позволяет изменить видео-режим. Таким образом отлаживаются все детали технического взаимодействия драйвера с ядром Kolibri OS.
    (б) На реальном железе (например, i810) остаётся отладить только специфический код изменения (установки) видео-режима.

    (5) Я предвижу проблемы:
    (i) Уже упоминалось: "С устройствами работают через их регистры в памти, через порты уже не работают" Я это понял как "На реальном железе можно и IN/OUT и MMIO; на эмуляторе - только MMIO" Иными словами: QEMU неадекватна в этом контексте и требует радикально иного подхода (например, поэтому часто не работает дискета в Kolibri OS на QEMU)
    (ii) Если карта не поддерживает VBE , то в ней нельзя установить его аналог (аналог линейного фрейм-буфера) в принципе (а драйвер Linux/Windows, использует принципиально иной подход, который принципиально отличается от подхода Kolibri OS).

    Итак, ещё раз повторяю вопрос:
    Насколько реален (целесообразен) план с начальным использованием QEMU для написания драйвера Kolibri OS, устанавливающего более приемлемый видео-режим?
  • Установить видеорежим через VESA можно только в реальном режиме, а после перехода в защищённый уже нельзя, но дело в том, что этого и ненадо, т.к. получается что нормальный режим только один 1024*786.
    Валялся гдето драйвер для графики через порты на OSDeve, он работал в 90%.
    Если чип не имеет своей видео памяти, то он использует аперативку, а работа с ним идёт так же как и со всеми.
    Современные intel hd4000 тоже могут не иметь свою память, но работают быстро и тянут DirectX11.
  • Вот еще небольшое сообщение в тему http://board.flatassembler.net/topic.php?t=14501
  • В VESA1 - которая писалась во время реального режима - видеопамять была организована не как единое целое, а банками, когда из всей видеопамяти процессор может работать только с окном aka банком размером 64K по адресу A000:0000 - возможны вариации, возможны два окна, подробности в спецификации. Для доступа ко всей видеопамяти нужна была процедура переключения банков, специфическая для видеокарты, которая устанавливает начало банка на указанное смещение. В ранних ядрах были, кажется, три процедуры для трёх разных карт без всякой возможности выбора нужной во время исполнения - только на уровне компиляции ядра. Полноценная поддержка VESA1 потребовала бы либо всевозможных процедур под все видеокарты, либо вызова процедуры, предоставляемой BIOS, через V86 - что требует существенных технических дёрганий, - либо вызова PM-процедуры BIOS, буде таковая существует - что бывает довольно редко. Поскольку полноценной поддержки не было, а код а) место занимал и б) требовал поддержки, в какой-то момент код решили просто закопать.

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

    (1) VESA BIOS Extensions (VBE core) 2.0 [November 1994]
    http://en.wikipedia.org/wiki/VESA_BIOS_Extensions
    (2) Pentium Pro, ... [1995]
    http://en.wikipedia.org/wiki/X86
    (3)
    1993

    FreeBSD
    NetBSD
    Newton OS
    Windows NT 3.1 (First Windows NT kernel public release)
    Open Genera 1.0
    IBM 4690 Operating System
    Novell NetWare 4
    Slackware 1.0
    Spring

    1994

    AIX 4.0, 4.1
    RISC OS 3.5
    NetBSD 1.0 (First multi-platform release, October 1994)

    1995

    Digital UNIX (aka Tru64 UNIX)
    OpenBSD
    OS/390
    Plan 9 Second Edition (Commercial second release version was made available to the general public)
    Ultrix 4.5 (Last major release)
    Windows 95
    http://en.wikipedia.org/wiki/Timeline_o ... ng_systems
    1996 год

    Debian 1.1 (Buzz)
    Debian 1.2 (Rex)
    Windows NT 4.0

    P.S.

    Иными словами, прошло уже явно более 15 лет, как наступила "эра защищённого режима процессора" :)

    В этой связи возникают довольно двоякие чувства:
    - с одной стороны, архитектуры 80486 - Pentium Pro (т.е. - до 1996.года) могут вполне серьёзно рассматриваться в качестве целевой архитектуры (вроде - вдохнуть новую жизнь в старые компьютеры, дать возможность поиграться талантливым детям на "хламе" без страха за его сохранность, ...); другое дело, что как раз на них Kolibri OS либо не работает, либо работает так, что ... то же самое что не работает; (даже 500-й селерон с 128 Мб оперативной памяти запустить полноценно не получается , так как i810 из real mode позволяет установить только VGA режимы);VESA 1.2 была бы хоть каким - то утешением ...
    - с другой стороны, сама по себе установка графического режима при загрузке операционной системы посредством VESA в real mode выглядит явным анахронизмом (особенно если учесть единственность такой установки графического режима); всё это наводит на мысли, уже высказанные в контексте Kolibri-B viewtopic.php?f=25&t=2085
  • Who is online

    Users browsing this forum: Ahrefs [Bot] and 13 guests