Требуется помощь.
Защищённый режим с flat-моделью памяти, OS отсутствует, BIOS недоступен.
Задачи:
1) Определить количество имеющейся в компе памяти.
2) Работа с мышью PS/2 (положение курсора и кнопок)
3) Работа с floppy-диском (чтение/запись 1 сектора)
4) Работа с VGA (установка режима 640х480х4, вывод пикселя)
Помогите пожалуйста.
Начальные условия:
Защищённый режим с flat-моделью памяти, OS отсутствует, BIOS недоступен.
Задачи:
1) Определить количество имеющейся в компе памяти.
2) Работа с мышью PS/2 (положение курсора и кнопок)
3) Работа с floppy-диском (чтение/запись 1 сектора)
4) Работа с VGA (установка режима 640х480х4, вывод пикселя)
Помогите пожалуйста.
Плюнь ты на свои "апрельские тезисы". Используй Big Real Mode (тот же flat, между прочим)
Плюнь ты на свои "апрельские тезисы". Используй Big Real Mode (тот же flat, между прочим)
Никак, всё остальное работает в защищённом режиме...
Никак, всё остальное работает в защищённом режиме...
Поподробнее, пожалуйста. Что это за "всё"? Может, это ещё одна ОС? Я прямо заинтригован. Правда ОСи тоже бывают разные... Вот, к примеру, была одна такая, выводила при загрузке "Doom operating system loading..." Сомнения вызывает разве что подозрительная сама по себе необходимость программирования VGA-адаптера дисплея...
Поподробнее, пожалуйста. Что это за "всё"? Может, это ещё одна ОС? Я прямо заинтригован. Правда ОСи тоже бывают разные... Вот, к примеру, была одна такая, выводила при загрузке "Doom operating system loading..." Сомнения вызывает разве что подозрительная сама по себе необходимость программирования VGA-адаптера дисплея...
Абсолютно верно, я пишу ОС. И мне нужна помощь в создании драйверов PS/2 мыши, флоппика и VGA.
Абсолютно верно, я пишу ОС. И мне нужна помощь в создании драйверов PS/2 мыши, флоппика и VGA.
По поводу VGA: Попробуй VESA стандарт поковыряй, у тут услышал, что они как в PCI разработали интерфейс для вызовов в PM. Т.е. тебе необходимо будет обеспечить доступ к VGA BIOS коду(обычно адреса С0000-СFFFF), определить где находится таблиза вызовов, и вызывать их по мере необходимости (установить видео режим и т.п.). Все это происходит непосредственно в PM, без переходов в Real/VM86 и обратно.
К сожалению это инфа не проверенная, "краем уха" слышал. Еще посмотри Menuet ОС, они как раз этим вроде как пользуются.
Что касается мыши, то там вроде ничего сложного нет, где-то видел описушку, но сейчас нет. Там правтически стаднартный ком, тебе приходит пакет из нескольких байт, говорящий на сколько мышка сместилась и какие клавишы нажаты/отпущены.
Плюс ты можешь задавать чувствительность, отсылая соотвестсвующую команду.
Начальные условия:
Защищённый режим с flat-моделью памяти, OS отсутствует, BIOS недоступен.
Задачи:
1) Определить количество имеющейся в компе памяти.
2) Работа с мышью PS/2 (положение курсора и кнопок)
3) Работа с floppy-диском (чтение/запись 1 сектора)
4) Работа с VGA (установка режима 640х480х4, вывод пикселя)
Помогите пожалуйста.
Начальные условия:
Защищённый режим с flat-моделью памяти, OS отсутствует, BIOS недоступен.
Задачи:
1) Определить количество имеющейся в компе памяти.
2) Работа с мышью PS/2 (положение курсора и кнопок)
3) Работа с floppy-диском (чтение/запись 1 сектора)
4) Работа с VGA (установка режима 640х480х4, вывод пикселя)
Помогите пожалуйста.
Прошу прощения! Может я чего то не понял.
А на кой BIOS отключать?
(В смысле - толку от неё никакого)
>Попробуй VESA стандарт поковыряй, у тут услышал, что они >как в PCI разработали интерфейс для вызовов в PM.
Ну, это правда. Но всё-таки необходимо учитывать, что этот интерфейс предназначен только для вызовов наиболее часто используемых при работе с графикой функций (переключение банка видеопамяти, изменение размера скан-линии, перемещение начала отбражаемой области по видеопамяти); на передачи управления (вход/возврат) при работе с ними в реальном режиме процессор тратит львиную долю времени прорисовки графики. В защищённом режиме специальные интерфейсные вызовы могут пригодиться, только если из-за принципиальной ограниченности возможностей видеокарты для перемещения по видеопамяти приходится использовать, также как в стандартном реальном режиме, окно по адресу A0000h размером со 16-битный сегмент RM (65536байт), в которое через обращение к специальной функции (переключить банк видеопамяти) отображается та или иная область VM. Понятно, что при работе даже в самых примитивных режимах типа 640x480x8 переключать банки видеопамяти приходится не просто часто, а очень часто (в особенности, если иногда кроме горизонтальных ещё и вертикальные линии рисовать ;-) ) и если делать это из-под PM, каждый раз специально для вызова функции переключаясь в RM, а затем возвращаясь обратно в PM, одной прорисовки экрана можно будет ждать часами... Вот для этого и введена эта возможность работы с кодом драйвера ВидеоБИОС платы прямо из-под PM. Но только зачем, спрашивается, это нужно, если можно использовать Линейный Кадровый Буфер (LFB), поддерживаемый абсолютно всеми видеокартами, выпущенными за последние 10 лет ?! Ну есть ещё, правда, некоторая польза от
"перемещения начала отбражаемой области по видеопамяти" - рисуешь в невидимой части видеопамяти, показывая не изменённую пока ещё картинку, потом после записи всего рисунка в невидимую область VM, делаешь её видимой, теперь пользуясь для обновления изображения тем куском, который до этого был видим и содержал "не изменённую пока ещё картинку" - ну так это уже-высший пилотаж, думаю не "оно" человеку нужно на данном этапе. А вот переключить видеорежим из-под PM не удастся - придётся либо временно "деградировать" до RM'а, либо использовать отдельную задачу, работающую в режиме V86.
Последний вариант считаю единственно приемлемым и намерен использовать его сам в своей (а что-то народ участвовать в моём созидательном движении не больно-то стремиться) OS Rosa.
>Еще посмотри Menuet ОС, они как раз этим вроде как >пользуются.
Угу, только выбрать видеорежим они предлагают на всё время работы в ОС в самом начале загрузки - пока в реальном режиме процессора работает ядро и видеорежим перключить не составляет ни малейших проблем. Вот если бы они, находясь уже в PM, могли бы динамически управлять разрешением и "цветностью" экрана - да я бы первый встал в очередь за чудесами на menuetos.org (я их исходники очень неплохо изучил...)
>Т.е. тебе необходимо будет обеспечить доступ к VGA BIOS >коду(обычно адреса С0000-СFFFF)
Ну если не знаешь, зачем нести ерунду в массы, а?
>Что касается мыши, то там вроде ничего сложного нет, где-то >видел описушку, но сейчас нет. Там правтически стаднартный >ком, тебе приходит пакет из нескольких байт, говорящий на >сколько мышка сместилась и какие клавишы нажаты/отпущены.
>Плюс ты можешь задавать чувствительность, отсылая >соотвестсвующую команду.
Приблизительно так. Но вообще-там команд у PS/2 мышиного интерфейса довольно много, вот только опять же - кто и когда ими в последний раз пользовался. Я лично уже давно начхать хотел на контроллер i8242 со всем его обширным джентельменским набором - просто пишу обработчики для IRQ12,
считывая в коде обработчика мышиные пакеты данных из 60h (пока только стандартные 3-х битные), и реагируя так или иначе на изменения состояния мыши в нужный момент. Всё остальное, по моему, легче эмулировать программно...
DRVTiny, я смотрю ты все грузишь и обсераешь, обсераешь и обсераешь, по моему это не совсем культурно и надо вконце концов совесть иметь. Все комментировать не буду, но скажу по поводу сообщения gwg605, в VBE действительно есть интерфейс защищенного режима и не только для переключения банков, а доступ к нему обеспечивает т.н. структура "PMID", но данная часть стандарта не обязательна и поэтому производители не всегда ее соблюдают. А из своего опыта скажу, что не все производители еще и проверяют эту штуку после написания так, что глюков может возникнуть куча.
Возникли вопросы? Задавайте, постараюсь ответить.
И да разверзднутся небеса!!!!!!!!!!!!!!!!!!!!
DRVTiny, я смотрю ты все грузишь и обсераешь, обсераешь и обсераешь, по моему это не совсем культурно и надо вконце концов совесть иметь. Все комментировать не буду, но скажу по поводу сообщения gwg605, в VBE действительно есть интерфейс защищенного режима и не только для переключения банков, а доступ к нему обеспечивает т.н. структура "PMID", но данная часть стандарта не обязательна и поэтому производители не всегда ее соблюдают. А из своего опыта скажу, что не все производители еще и проверяют эту штуку после написания так, что глюков может возникнуть куча.
Возникли вопросы? Задавайте, постараюсь ответить.
Надо же, какие здесь все впечатлительные...
Ну так всё же, можно из-под PM режим экрана переключать или нет? Меня вообще-то этот вопрос очень интересует...
Надо же, какие здесь все впечатлительные...
Ну так всё же, можно из-под PM режим экрана переключать или нет? Меня вообще-то этот вопрос очень интересует...
Да, кстати, я тут в предыдущем сообщении (которое reply для gwg605) очепятался маленько. Пакеты мыши, понятное дело, всё-таки не 3-х битные, а 3-х байтные.
Прошу прощения! Может я чего то не понял.
А на кой BIOS отключать?
При переходе в PM BIOS недоступен
Но только зачем, спрашивается, это нужно, если можно использовать Линейный Кадровый Буфер (LFB), поддерживаемый абсолютно всеми видеокартами, выпущенными за последние 10 лет ?!
Можно, пожалуйста, поподробнее?
Но вообще-там команд у PS/2 мышиного интерфейса довольно много, вот только опять же - кто и когда ими в последний раз пользовался. Я лично уже давно начхать хотел на контроллер i8242 со всем его обширным джентельменским набором - просто пишу обработчики для IRQ12,
считывая в коде обработчика мышиные пакеты данных из 60h (пока только стандартные 3-х битные), и реагируя так или иначе на изменения состояния мыши в нужный момент. Всё остальное, по моему, легче эмулировать программно...
Подробнее, пожалуйста. Что за комманды, почему только стандартные трёхбайтные и что остальное легче эмклировать программно?
//////////////////////
И как насчёт флоппика?
Надо же, какие здесь все впечатлительные...
Ну так всё же, можно из-под PM режим экрана переключать или нет? Меня вообще-то этот вопрос очень интересует...
Отвечу кратко - можно.
Отвечу кратко - можно.
Ваше Величество Ramon I и единственный, Вы пустобрёх, судя по всему... О чём я рад Вам сообщить без обиняков. Пусть мне действительно свойственен критический подход к чужим высказываниям, но при этом моя критика всегда является продуманной и аргументированной. Критику в свой собственный адрес я воспринимаю спокойно, если она является конструктивной. Ваши же оскорбительные измышления, не подкреплённые ничем, кроме безграмотной демагогии (я уж не говорю о том, что "культурные" люди всё-таки должны бы придерживаться нормативной лексики), не более чем пустобрёхство и бахвальство. На чём рад с Вами, Ramon, раскланяться.
P.S. Да, длинноватое получилось сообщение, искренне сочувствую и соболезную, если у Вас, сэр, чтение его спровоцировало очередной приступ "репной" мигрени...
И вообще, почему бы нам не объединиться, коль уж так получилось, что мы, судя по всему, сейчас на одном и том же этапе создания ОС находимся... Нет, ну в саом деле, я ведь и пришёл на CodeNet в поисках единомышленников. А ты вроде как раз идеально подходишь в этом качестве :-)))
Artlav'у: Вот тебе обработчик прерывания мыши PS/2, которым пока что и сам пользуюсь в PM. Там в принципе несколько не очевиден подход к организации кольцевого буфера, но ты спрашивай, уж по собственному коду я всегда смогу дать "высококвалифицированную" консультацию.
И вообще, почему бы нам не объединиться, коль уж так получилось, что мы, судя по всему, сейчас на одном и том же этапе создания ОС находимся... Нет, ну в саом деле, я ведь и пришёл на CodeNet в поисках единомышленников. А ты вроде как раз идеально подходишь в этом качестве :-)))
Что-то файл качаться не хочет - пустой получается.
Насчёт объединения - я, впринципе, мог бы дать много интересных идей и реализаций, но у меня есть большой недостаток: я совершенно не могу работать в команде.
>Т.е. тебе необходимо будет обеспечить доступ к VGA BIOS >коду(обычно адреса С0000-СFFFF)
Ну если не знаешь, зачем нести ерунду в массы, а?
А в чем я ошибаюсь?
А в чем я ошибаюсь?
Не мне вопрос, но я прокомментирую - НИ В ЧЕМ.
Что-то файл качаться не хочет - пустой получается.
Насчёт объединения - я, впринципе, мог бы дать много интересных идей и реализаций, но у меня есть большой недостаток: я совершенно не могу работать в команде.
Ох, как же я ненавижу мразматичекий Internet Explorer!!!!
Вот тебе новый файл. Может, хоть этот нормальным полновесным окажется...
Начальные условия:
1) Определить количество имеющейся в компе памяти.
Имхо, только из реального или 16-ти битного защищенного режима. Согласно BIOS Boot Specification, при передаче управления загрузчику, пара ES : DI указывает на PnP Installation Check Structure. Далее, согласно Desktop Management BIOS Specification, при запросе (Type=5) возвращается информация о количестве установленных слотов памяти (смещение $0E), а запросом (Type=6) можно узнать размер каждого установленного слота памяти. Осталось только просуммировать ;)
3) Работа с floppy-диском (чтение/запись 1 сектора)
Например, через DMA. Пример есть у Зуева (программирование на языке ассемблера). Есдинственная проблема --- что данные читаются в первый мегабайт физической памяти. Поэтому, чтобы их прочитать, тебе надо знать, на какие адреса твоей FLAT-модели проецируется заданый тобою адрес.
4) Работа с VGA (установка режима 640х480х4, вывод пикселя)
Тоже ничего военного. Знай только на какой адрес проецируется видеопамять, остальное все в силе.
(В смысле - толку от неё никакого)
Это была только наводка, и умеющий сможет ее использовать.
Поскольку информация которую вы привели вызвала у меня массу удивления и вопросов, решил посмотреть спеку по VESA.
вызовов наиболее часто используемых при работе с графикой функций (переключение банка видеопамяти, изменение размера скан-линии, перемещение начала отбражаемой области по видеопамяти);
Насколько часто при работе вы меняет размер сканлинии? И зачем переключать банки если видяха может поддерживать линейный видео буффер, о котором вы говорите ниже?
- Ваши доказательства? (с)Красная жара
Почему нельзя? Спека накладывает два ограничения на установку режимов в PM:
- стандартные VGA режимы
- и текстовые режимы
Ну если не знаешь, зачем нести ерунду в массы, а?
Спека рекомендует скопировать область начинающуюся C0000 в реальную память, обычно это 32К, и там юзать. Но насколько я понимаю это не обязательно.
> - Ваши доказательства? (с)Красная жара
Слушайте, gwg605, а Вы, оказывается, смотрели "Красную жару". Ну наконец-то я нашёл человека, у которого можно спросить: послушайте, это не тот ли фильм, где из людей по каким-то необъснимым причинам кровь зелёного цвета начинает вытекать (происки мафии, использующей хим. реагенты в несколько "экстраординарных" целях, насколько я помню). Или тот фильм "Полуденная жара" назывался?
Спека рекомендует скопировать область начинающуюся C0000 в реальную память, обычно это 32К, и там юзать. Но насколько я понимаю это не обязательно.
Сказать по этому поводу нечего - наконец-то хоть один человек нормальный, документацию официальную удосужился почитать и даже всё правильно запомнил. Виват!
Главное из этих затруднений - банальная нехватка "жизненного пространства" для изрядно "раздобревшего" после дополнения "увесистым" кодом VBE модуля ПЗУ - теперь он оказался плотно "зажат" между текстовым видеобуфером и участком памяти, предназначенном для размещения ROM-modules устройств с шиной ISA. Отсюда и проблемы с использованием VBE из-под PM - если для реального режима реализация полного набора стандартных сервисов программного интерфейса VESA - жизненная необходимость (skiped), то для PM, (skiped)- попросту Out OF Memory имеет место быть при попытке пересечения границы 0C8000h модулем ПЗУ БИОС. Поэтому VBE PM ограничивается всего тремя наиболее часто вызываемыми
Насколько я понимаю эту спеку, то ’Protected Mode Entry Point’ это механизм вызова того же самого 16-bits кода в режиме PM. Там в требованиях, сказано что необходимо сделать 16-bits кодовый сегмент, и несколько 16-bits сегментов для данных (BIOSData, A000, B000, B800). Причем если используется указатель на буффер, то он должен быть 16:16. Так что дополнительный код необходимый для работы в PM совсем небольшой.
По поводу необходимого пространства для VideoBIOS кода, то я видел встроенную видяшку у которой код Video был 64К (помойму это был Aser Mate). Как мне кажется, то места достаточно.
Насколько я понимаю эту спеку, то ’Protected Mode Entry Point’ это механизм вызова того же самого 16-bits кода в режиме PM. Там в требованиях, сказано что необходимо сделать 16-bits кодовый сегмент, и несколько 16-bits сегментов для данных (BIOSData, A000, B000, B800). Причем если используется указатель на буффер, то он должен быть 16:16. Так что дополнительный код необходимый для работы в PM совсем небольшой.
По поводу необходимого пространства для VideoBIOS кода, то я видел встроенную видяшку у которой код Video был 64К (помойму это был Aser Mate). Как мне кажется, то места достаточно.
Вот вот все абсолютно верно, я проверял - работает, а некоторых товарищей, которые даже ни удосужились прочитать спецификацию и как видно не имеющих представления о рассматриваемом вопросе, прошу хотя бы не опускаться ниже плинтуса, хотя куда уже ниже, просто некуда, пустозвон хр*нов....
Попробуй на досуге почитать, а не писать романы на тему - "Какой я ламер криворукий"
P.S. Простите, не выджержал(всему есть предел).
Вот вот все абсолютно верно, я проверял - работает, а некоторых товарищей, которые даже ни удосужились прочитать спецификацию и как видно не имеющих представления о рассматриваемом вопросе, прошу хотя бы не опускаться ниже плинтуса, хотя куда уже ниже, просто некуда, пустозвон хр*нов....
Попробуй на досуге почитать, а не писать романы на тему - "Какой я ламер криворукий"
P.S. Простите, не выджержал(всему есть предел).
Начнём хотя бы с того, что вызовы 16bit - кода из-под 32 рзрядного PM - марази по определению (стоило ломать столько дров, чтоб вообще в PM переключиться). Во-вторых, я читал действительно ОФИЦИАЛЬНУЮ документацию, а не руководство типа "хитрости, трюки, секреты" от хакера Васи. Там вообще-то сказано, что специально для PM существует такая комбинация из 3-х пальцев:
xor ebx, ebx
mov eax, 4F0Ah
int 10h
После выполнения функции в регистрах будут размещены следующие значения:
в AX-код возврата
в ES:[DI]-указатель на тfблицу доступа к интерфейсу PM
в CX-размер таблицы доступа в байтах, включая размер кода для работы в PM.
Таблица доступа к интерфейсу PM содержит 4 слова-указателя, вслед за кот.-ми располагается программный код для работы в PM. Указатели размещены в таблице в сл. порядке:
Слово в таблице: Значение слова:
00 Смещение кода функции 05 от начала таблицы доступа
02 Смещение кода функции 07 от начала таблицы доступа
04 Смещение кода функции 09 от начала таблицы доступа
06 Смещение таблицы портов и описателей области памяти, для доступа к которым нужно устанавливать соотв. уровень привилегий, от начала таблицы доступа (Значение 0 указывает на отсутствие таблицы)
Таблица портов и описателей области памяти устроена сл. образом: в начале находиться список 16-разрядных адресов портов ввода-вывода, заканчивающий ся трминатором 0FFFFh. За терминатором списка портов следуют 32-х разрядный базовый адрес области памяти, 16-разрядный лимит сегмента и терминатор описания области памяти 0FFFFh
ДЛЯ ОБЕСПЕЧНИЯ ДОСТУПА К ПРОГРАММНОМУ КОДУ В PM НУЖНО ЛИБО СКОПИРОВАТЬ ВСЁ СОДЕРЖИМОЕ ТАБЛИЦЫ ДОСТУПА В _32-Х_ (!!!!!) РАЗРЯДНЫЙ СЕГМЕНТ, ЛИБО НАСТРОИТЬ СЕЛЕКТОРЫ И ПРАВА ВВОДА-ВЫВОДА ПРЯМО НА СООТВЕТСТВУЮЩУЮ ОБЛАСТЬ ПЗУ.
ЦЕЛЕСООБРАЗНОСТЬ ВВЕДЕНИЯ ФУНКЦИИ 4F0AH НЕ ОЧЕВИДНА, ПОЭТОМУ В ВЕРСИИ VBE 3.0 ОНА НЕ ОТНОСИТСЯ К ЧИСЛУ ОБЯЗАТЕЛЬНЫХ (так что особо умные могут напороться вообще на полное отсутствие поддержки работы с VBE в защищённом режиме)
Да, кстати, может всё же дадите ссылку на своё пособие от "очумелые ручки" от хакера Васи - а то что-то не очень я доверяю твоему, Ramon трёпу... (это ещё мягко говоря)
>Вот вот все абсолютно верно, я проверял - работает,
Ну, знаешь, всё зависит от примитивности твоего кода, работающего в PM - в принципе, если функции VBE для реального 16-битного режима не пытаются грузить "параграфы" в сегментные регистры (т.е вообще ничего туда не помещают по собственой инициативе), то и не мудрено, что этот код работает также и в 16-разрядном коде из-под PM. Тоже мне новость! Только я ж говорю - это не иначе - полный маразм (и , кстати, для разнх видеокарт код функций VBE совершенно разный, так что ещё и здесь можно напороться на проблемы ограниченной совместимости)
Насчёт 64K VideoBIOS - пить надо меньше, тогда и крыша останется цела...
VESA 2.0: программируем в защищенном режиме
С. А. Андрианов
В предыдущей статье ("VESA: стандарт новый, проблемы старые", "Мир ПК", ¦ 7/98) в основном были описаны особенности версии 1.2 стандарта VESA и работа с ним в реальном режиме процессора. Сейчас мы рассмотрим функции стандарта версии 2.0, не вошедшие в предшествующие версии, причем основное внимание будет уделено использованию этих функций в защищенном 32-разрядном режиме.
Практически все прерывания DOS и BIOS предназначены для работы в реальном режиме. Не составляет исключения и сервис VESA. Однако в последнее время все явственнее ощущается тенденция перехода к работе в 32-разрядном защищенном режиме, а программам, работающим с изображением, как правило, необходим объем оперативной памяти, превосходящий размер видеопамяти, который требуется для изображения, последний же может достигать 2, 4, а иногда и 8 Мбайт. Использование для доступа к видеопамяти маленького окошка (размером не более 64 Кбайт) также довольно неудобно при больших изображениях. В новом стандарте VBE 2.0 (VESA BIOS Extension) введена информационная поддержка для линейного буфера (LFB - Linear Frame Buffer), охватывающего весь объем видеопамяти. На первый взгляд это никак не связано с 32-разрядным защищенным режимом, но на практике использование LFB в защищенном режиме с 16-разрядной адресацией не дает почти никаких преимуществ по сравнению со стандартным оконным режимом, а в реальном режиме работы процессора и вовсе невозможно (за исключением уж слишком экзотических случаев).
Новые функции
Стандарт VBE 2.0 вводит две новые функции.
Функция 9 управляет данными регистров палитры. Функция 8, введенная предыдущей версией стандарта, позволяла изменить разрядность регистров палитры, но ничего не говорила о том, как с ними следует работать. Функция 9 восполняет этот пробел и заменяет собой стандартные подфункции 12h и 17h работы с палитрой функции 10h прерывания 10h.
На входе:
AX = 4F09h,
BL = 00h - установить данные палитры;
= 01h - возвратить данные палитры;
= 02h - установить данные дополнительной палитры;
= 03h - возвратить данные дополнительной палитры;
= 80h - установить данные палитры во время импульса
обратного хода луча;
CX - количество изменяемых цветов палитры;
DX - номер первого из изменяемых цветов;
ES:DI - адрес таблицы данных для регистров палитры.
На выходе:
AX - статус завершения.
В отличие от стандартного сервиса, предоставляемого функцией 10h прерывания 10h, один цвет в таблице представлен не тремя, а четырьмя байтами. Согласно описанию стандарта порядок байтов следующий: байт выравнивания, красный, зеленый, синий. Видимо, считается, что информация о цвете хранится в двойном слове и порядок перечисления - от старшего байта к младшему. По крайней мере в памяти байты должны быть расположены в обратном порядке: по младшему адресу - синий, по старшему - байт выравнивания.
На некоторых видеоадаптерах в момент переопределения палитры на экране могут появляться помехи (так называемый "снег"). В этом случае палитру следует менять во время импульса обратного хода луча, установив BL = 80h. Так как прикладная программа сама не может посмотреть на экран, чтобы проверить качество изображения, сообщить ей о "снеге" должен видеоадаптер, использовав бит D2 поля Capabilities в информационном блоке, возвращаемом функцией 0.
Стандарт предусматривает возможность управления дополнительной палитрой, если она поддерживается аппаратно. В случае отсутствия дополнительной палитры при попытке обращения к последней функция возвращает код ошибки 2.
В 6-разрядном режиме палитры значащими являются шесть младших битов, остальные игнорируются аналогично тому, как это реализовано в стандартной функции установки палитры VGA.
При переопределении разрядности регистров палитры (регистров ЦАП (DAC)) текущая ее установка (т. е. цвета на экране) сохраняется. По-видимому, при этом переключении просто изменяется способ подключения регистров ЦАП к шине данных. Это подтверждается тем, что если записать какое-либо число в регистры в 6-разрядном режиме, переключить ЦАП в 8-разрядный, а потом прочитать содержимое регистров, то оно окажется в 4 раза больше первоначально записанного.
Когда мы устанавливаем новый видеорежим с индексным представлением цвета (16- или 256-цветный), разрядность регистров палитры по умолчанию равняется шести битам. Чтобы использовать 8-разрядный ЦАП (если он поддерживается аппаратно), необходимо вызвать функцию 8.
Функция 0Ah запрашивает интерфейс защищенного режима. Она возвращает указатель на таблицу, содержащую адреса функций 32-разрядного защищенного режима для функций 5, 7 и 9, а также таблицу портов и используемых участков памяти. Функции защищенного режима можно либо скопировать в новый кодовый сегмент (для чего возвращается также длина кода), либо вызывать непосредственно из ПЗУ.
На входе:
AX = 4F0Ah;
BL = 00h.
На выходе:
AX - статус завершения;
ES - сегмент таблицы в адресации реального режима;
DI - смещение таблицы;
CX - длина таблицы, включая длину кода.
Формат таблицы следующий:
ES : DI + 00h - смещение точки входа функции 5;
ES : DI + 02h - смещение точки входа функции 7;
ES : DI + 04h - смещение точки входа функции 9;
ES : DI + 06h - смещение таблицы портов и участков памяти.
Все смещения даются относительно адреса начала таблицы.
Следует отметить, что формат параметров функции 7 защищенного режима несколько отличается от такового для реального режима. При вызове 32-разрядной функции в регистре CX следует передавать младшее слово полного 32-разрядного смещения от начала видеопамяти, а в DX - старшее.
Главная цель дублирования функций VESA 32-разрядными эквивалентами - ускорить выполнение прерываний и, следовательно, вызывающей их программы. Поэтому в число дублируемых функций попали только те, которые могут неоднократно вызываться для однажды установленной видеомоды. Однако следует отметить, что такой сервис все же представляется несколько избыточным. И функцию 7 управления положения экранного окна в видеопамяти, и функцию 9 переопределения регистров палитры не имеет смысла вызывать чаще, чем один раз за кадр, т. е. никак не чаще сотни раз в секунду, поэтому потери времени на их вызов можно считать пренебрежимо малыми. Несколько по-другому обстоит дело с функцией 5 переключения банков памяти.
Если программа осуществляет построение изображения непосредственно в видеопамяти (что, кстати, довольно нерационально с точки зрения скорости работы программы, см. С.А. Андрианов, "SVGA: быстрый вывод на экран", "Мир ПК", ¦ 11/97), то вывод каждого графического примитива может сопровождаться переключением (и, возможно, не одним) банков. Поэтому экономия времени на нем могла бы оказаться весьма существенной, если бы не другое новшество, введенное стандартом версии 2.0, - LFB, при использовании которого видеопамять представляет собой один большой нефрагментированный массив, расположенный в адресном пространстве процессора. Следовательно, потребность в переключении банков отпадает сама собой, так же как и необходимость отслеживать их границы, что весьма сказывается на эффективности кода. Правда, поддержка стандарта VBE 2.0 еще не гарантирует аппаратной реализации LFB, но существуют программные средства (например, драйвер UniVBE), позволяющие программно эмулировать его наличие, так что для прикладной программы уже не нужно ни переключать банки видеопамяти, ни даже отслеживать их границы.
Таким образом, наибольший практический интерес вызывает именно использование LFB при работе в 32-разрядном защищенном режиме.
Следует только отметить, что при аппаратной реализации LFB для обеспечения возможности работы с ним необходимо установить соответствующий (D14) бит в номере видеомоды при ее инициализации. Некоторые видеоадаптеры, правда, позволяют в одном и том же видеорежиме работать как с оконным режимом адресации видеопамяти, так и с LFB.
Интересно, что, хотя я раньше и не читал этой статьи, я уже раз 10 умудрился её пересказать...(правда толку-то, у нас же все овладели техникой дизассемблирования в совершенстве, куда уж мне со своей горой книг на всех полках и скачанной с официального vesa.org документацией (я, знаете ли, ещё и по английски иногда читать умею...)) Так что если уж у нас и есть ламеры - то это С.В.Андрианов в первую очередь... В общем, да здравствует хакер Вася - непризнанный гений всекмирного масштаба!
Для особ особо юзанутых:
"Starting with VBE/Core 3.0, all the VBE functions are optionally accessible from 16-bit and 32-
bit protected mode applications and operating systems via a new ‘Protected Mode Entry Point’.
The protected mode entry point defines a special location that can be used to directly call the
VBE functions as 16-bit protected mode code. The application or OS does not call the BIOS
code directly from protected mode, but first makes a copy of the BIOS image in a writeable section of memory and then calls the code within this relocated memory block. The entry point is
located within a special ‘Protected Mode Information Block’, which will be located somewhere within the first 32Kb of the BIOS image (if this information block is not found, then the BIOS does not support this new interface)."
Из официального документа, а не от ламера С. А. Андрианова.
Надеюсь прочитать смог. Еще добавлю эта штука есть и в VBE 2.0, только уже неофициально.
Ну, знаешь, всё зависит от примитивности твоего кода, работающего в PM - в принципе, если функции VBE для реального 16-битного режима не пытаются грузить "параграфы" в сегментные регистры (т.е вообще ничего туда не помещают по собственой инициативе), то и не мудрено, что этот код работает также и в 16-разрядном коде из-под PM. Тоже мне новость! Только я ж говорю - это не иначе - полный маразм (и , кстати, для разнх видеокарт код функций VBE совершенно разный, так что ещё и здесь можно напороться на проблемы ограниченной совместимости)
Насчёт 64K VideoBIOS - пить надо меньше, тогда и крыша останется цела...
Уж кто бы говорил, человек, который пишет DOS Extender и читает ламерские мануалы. Да будет известно, что у меня система FLAT 32, а для выполнения 16 битного кода существует подсистема. "Насчёт 64K VideoBIOS" - вообщето 32K это вершина айсберга, большей частью для совместимости, BIOS то в старших адресах лежит, а 0xС000 это всего лишь отражение его части в первый метр. Да и что мешает производителю занять 0xC800, адрес то свободен. К тому же например ATI Rage128 Fury имеет 48K BIOS. Так что не мути воду.
Уж кто бы говорил, человек, который пишет DOS Extender и читает ламерские мануалы.
Ну, коль у меня мануалы неправильные, так я ж не возражаю, а можно даже сказать - я всеми руками и ногами за использование альтернативных источников (только не от хакера Васи, пожалуйста...) - у тебя же, Ramon, к сожалению, как раз с обоснованной, подкреплённой сведениями из различных источников, аргументацией БОЛЬШИЕ проблемы. Ты только и горазд трепаться, уделяя в своих более чем скромных по объёму сообщениях оргомное место непродуктивным (с точки зр. того, что "в споре рождается истина") эмоциям, но ни слова не говоря о фактической стороне вопроса. Даже затрагивая конкретные проблемы (что бывает крайне редко), ты всегда пытаешься выдать свою точку зрения за истину в последней инстанции. И ладно бы твоя заносчивость была б хотя б в малейшей степени оправдана (может, действительно человек обладает столь огромным "багажом" знаний), но ты же не подкрепляешь свои утверждения ссылками на какие бы-то ни было источники информации (я уж не говорю "надёжные", "проверенные", "заслуживающие доверия" - для тебя эти понятия, судя по всему, вообще - пустой звук). А это уже, знаете ли, в немалой степени способствует тому, что ты производишь впечатление (я думаю и не только на меня) человека не далёкого с явно завышенной самооценкой. Особенно меня "умиляют" твои, видимо,обусловленные многочисленными детскими комплексами попытки отвечать на критику в свой адрес (обоснованную, заметь, и аргументированную) в типично "детсадовском стиле" типа: "Сам дурак!" или "А ты вообще ламер позорный" и т.д. Ясельная группа, чес слово!
Да будет известно, что у меня система FLAT 32, а для выполнения 16 битного кода существует подсистема.[/QUOTE]
Н-да, насчёт "системы FLAT 32" - это, конечно, серьёзная заявка :-)) на создание очередного клона MS-DOS, способного работать в PM. А как там насчёт многозадачности и разделения памяти - может, ты, когда наконец приступишь к решению связанных с этим насущных вопросов, для каждой задачи ещё и свою таблицу страниц регистром CR3 грузить станешь (1024 элемента по 4 байта, каждый ссылается ещё на 1024 элемента по 4 байта, описывающих размещение, тип и состояние 4K страниц ОЗУ). Насчёт 16-ти битного кода и "подсистемы" - а на черта вообще то оно надо? Ну ладно там OS/2 и Windows в своих "переходных" версиях сохраняли такую подсистему для обеспечения совместимости с Программным Обеспечением, написанным для предыдущих версий ОС, работавших на процессорах типа i286 с его "недоразвитым" Защищённым Режимом и мизерными объёмами ОЗУ компьютеров, на базе этого CPU построенных (других тогда ещё попросту и не было). А тебе это зачем, объясни популярно...
"Насчёт 64K VideoBIOS" - вообщето 32K это вершина айсберга, большей частью для совместимости, BIOS то в старших адресах лежит, а 0xС000 это всего лишь отражение его части в первый метр. Да и что мешает производителю занять 0xC800, адрес то свободен. К тому же например ATI Rage128 Fury имеет 48K BIOS. Так что не мути воду. [/QUOTE]
Не, всё, надоело метать бисер перед, извините, свиньями (тем более, если ты, Ramon, перечитаешь мой ответ на сообщ. gwg605, то найдёшь там совершенно конкретный ответ на свой вопрос) Как тут один товарищ (см. ниже) ОЧЕНЬ СПРАВЕДЛИВО И ОЧЕНЬ ВОВРЕМЯ ЗАМЕТИЛ - Книжки Читать Надо! (А ты, небось и не пробовал - а ведь ох как помогает иногда не попадать в нелепые положения). По конкретному вопросу о размещении ROM BIOS видеокарт в адресном пространстве процессора настоятельно рекомендую почитать на досуге: "Аппартные интерфейсы PC" М.Гука, глава 12.9 "Расширения ROM BIOS" (стр. 497-504) Изд.-во "Питер"
Да и вообще, следуя твоей логике, - если по адресу 0xС000 находится "всего лишь отражение его [VideoBIOS] части в первый метр", то для чего вообще-то размещать полный BIOS в старших адресах? (кстати, такой механизм, как "отражение" вообще не предусмотрен архитектурой x86, мы же всё-таки о физической памяти говорим, а не о виртуальной, основанной на страничных преобразованиях, так что два одинаковых куска в физической памяти могут быть только копиями друг друга, если же речь идёт не о копии ПЗУ, а о его _проекции_, то проецирование одного и того же ПЗУ сразу на несколько областей памяти вообще НЕ ВОЗМОЖНО) Ведь в "первом метре" находится по определению находиться та часть ПЗУ, которая обеспечивает набор сервисов для программ реального режима, и, понятное дело, что 99.9% VideoBIOS с его расширениями, стандартизованными VESA занимает именно 16-разрядный код и данные (для внутреннего служебного пользования сервисными функциями), предназначенные для использования в RM. Что же это тогда получается - по твоему, в старших адресах выделяется места >32K только для того, чтобы было куда поместить 0,(... десятых) процента кода, предназначенного специально для PM? Да, кстати, а знаешь ли ты, что функции инициализации ROM BIOS после первой его загрузки (на картах PCI - действительно в верхние адреса памяти) могут освобождать ту часть памяти, которая используется только в процессе инициализации (а это на самом деле зачастую не такой уж и маленький объём - таблицы там всякие, коды самотестирования). Да, и программный код (иногда данные тоже), между прочим, во многих случаях хранится в ROM BIOS в дублированном для использования на разных аппаратных платформах виде... Всё-таки, как известно, на IBM PC-compatible свет клином не сошёлся...
советую купить книжку Кулакова - "Программирование на аппаратном уровне", там все это есть. а если ломает покупать, могу содержание дискеты из этой книги кинуть, там все проги, и про мышь ps2 и про SVGA в PM...
Правильное и своевременное замечание, но только не ко мне - я в своих предыдущих сообщениях тем или иным образом уже неоднократно цитировал (приводил выдержки) именно эту книгу (Ну, понятное дело, и некоторые другие книги тоже ("Программирование SVGA-графики для IBM PC", например)) Но всё равно - Ваше замечание для меня просто "бальзамом на душу" кажется :-))))) Thanks!
Для особ особо юзанутых:
"Starting with VBE/Core 3.0, all the VBE functions are optionally accessible from 16-bit and 32-
bit protected mode applications and operating systems via a new ‘Protected Mode Entry Point’.
The protected mode entry point defines a special location that can be used to directly call the
VBE functions as 16-bit protected mode code. The application or OS does not call the BIOS
code directly from protected mode, but first makes a copy of the BIOS image in a writeable section of memory and then calls the code within this relocated memory block. The entry point is
located within a special ‘Protected Mode Information Block’, which will be located somewhere within the first 32Kb of the BIOS image (if this information block is not found, then the BIOS does not support this new interface)."
Из официального документа, а не от ламера С. А. Андрианова.
Надеюсь прочитать смог. Еще добавлю эта штука есть и в VBE 2.0, только уже неофициально.
Извини, я чего-то это твоё сообщение по порядку последним увидел, так что сейчас только отметил: исправляешься ты помаленьку, в культуру "делового" общения вникать начал. Рад за тебя. Поэтому свои слова насчёт твоей полной необъективности и неадекватности беру обратно. Ещё раз прошу прощения за свою невнимательность...
Далеко не все производители видеокарт посчитали нужным upgrad'ить свои VideoBIOS'ы до VBE3 (так как это стало, к сожалению, очень мало актуальным в современном мире, изнасилованном вызывающими у людей наркотичекую зависимость глюками ядовито-синих форточек), а "посчитавшие нужным" совершенно не обязаны реализовывать все требования спецификации, которая в последней версии приобрела характер "добрых советов производителям видюх", а не обязательных к исполнению в полном объёме рекомендаций (т.е уж коль ты [vendor] этим рекомендациям следуешь, то mandatory - это mandatory, изволь в обязательном порядке исполнять все предписания, кроме optionall-дополнений), как это было в VBE2.0 и 1.2, и уж тем более не жёстких требований совместимости на основе аппаратной стандартизации, какие предъявляла IBM к производителям VGA-карт.
Насчёт VBE2.0 и точки входа PMEntryPoint - честно скажу, не знаю, я неофициальное руководство по нему хоть и читал, но что-то того, о чём ты говоришь, я там не видел. Вот, кстати, моя версия неофициального руководства (качай наздоровье). Но думаю, проблема не в тебе и не во мне, а именно в "неофициальности" документа, информация в котором такая же optionall, как и весь стандарт VBE3...
Ты, кстати, оставь мне свою доку по VBE2.0 - интерсено на самом деле очень почитать, любопытство прямо так и распирает... Или ссылку оставь.
У тебя в PM какая-то графическая прога работает? Или по стопам Вилле Турьянмы с его супер-микро GUI в MenuetOS идёшь? Какой-то ты человек уж очень агрессивно настроенный и малообщительный. Прямо загадка все эти твои "происки" в PM. Может,создашь отдельную тему, да расскажешь хотя бы вкратце, что задумал creativ'ить - а то ведь угробишь многие годы, чтобы сделать чего-нибудь полезное для общества, а оно о твоих стараниях так и не узнает. Да, между прочим, а ты знаешь, что "two head better than one"? :-)))