Цитата: "Установка видео режима через порты стандартна для всех видео карт"

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

P.S.

Кончаю болтать не по теме: когда начну конкретно работать - создам отдельную тему.
Однако пока-что всё же рассчитываю на ответ

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