Несколько вопросов начинающего

TermoSINteZ
Спасибо! А по поводу одинаковых возвращённых значений EBX что можете сказать?

 

s3dworld

Это внутренее значение биоса. Зависит от его реализации и вас его анализировать ни кто не просит.

 

Для эмуляции я использую Bochs. Настройки памяти там у меня стоят следующие:



То есть я использую 32 МБ памяти ОЗУ. Не знаю для чего там другие 32 МБ. Вызываю функцию девять раз. Картина следующая:



Если перевести всё в адреса, то получаются такие вот участки:

1. 0x00000000 - 0x0009EFFF. Можно использовать в ОС. Размер 651264 байта (636 КБ).
2. 0x0009F000 - 0x0009FFFF. Нельзя использовать в ОС. Размер 4096 байт (4 КБ).
3. 0x000E8000 - 0x000FFFFF. Нельзя использовать в ОС. Размер 98304 байта (96 КБ).
4. 0x00100000 - 0x01FEFFFF. Можно использовать в ОС. Размер 32440320 байт (31680 КБ).
5. 0x01FF0000 - 0x01FFFFFF. Нельзя использовать в ОС. Размер 65536 байт (64 КБ).
6. 0xFFFC0000 - 0xFFFFFFFF. Нельзя использовать в ОС. Размер 262144 байта (256 КБ).

Доступная память составляет 33091584 байта (651264 байта + 32440320 байт), то есть 32316 КБ (что практически является 31.5 МБ).

Не доступная память составляет 430080 байт (4096 байт + 98304 байта + 65536 байт + 262144 байта), то есть 420 КБ.

То есть всего у нас 33521664 байта (33091584 байта + 430080 байт), то есть 32736 КБ (практически 31.9 МБ).

Хорошо, большая часть мне доступна для использования. А вот адрес видеоадаптера 0x0000B800 лежит в пределах от 0x00000000 до 0x0009EFFF. Так что же это получается? Это ведь ОЗУ, а не видеопамять, спроецированная на адресную память.

Или я чего-то не понимаю? Может в реальном режиме (R-Mode) адрес 0x0000B800 и будет началом видеобуфера, а в защищённом режиме (P-Mode) это будет память ОЗУ. То есть придётся вывод на экран обрабатывать через порты.

В общем, я запутался. Подскажите мне истину во всём этом. Я ведь ОЗУ же определял, причём тут видеопамять.

 

Адрес видео адаптера не 0x0000B800, а 0x000B8000 и он не попадает ни в один из диапазонов. И это окно видео памяти спроецированное вниз для использования в старых режимах работы. Если использовать VESA то даже при 32 Мб на машине тебе могут вернуться адрес видеобуфера где-то в конце 3-го Гб

 

max7C4
А как адрес видеобуфера узнать?

 

max7C4,

Если VBE скажет что через окна можно, тогда 0xA0000 и 0xB0000 весьма рабочи. А линейный фрэйм-буфер да, может оказаться недоступен в чистом real-address mode.

----8<----
s3dworld,

Штука в том что BIOS запрограммировала контроллер памяти определённым образом. Тут варианта два: использовать то, что получилось, или (при знании северного моста/SMBus/etc.) сделать себе красиво.

Адрес видеобуфера? VBE, или знание чипа видеоконтроллера.

 

baldr
Если честно, то я сам не знаю что хочу. Я знаю чего хочу добиться, но какими средствами - это я не знаю.

Первым что я хочу, так это просто устанавливать различные текстовые режимы, выводить символы с атрибутами на экран и переключаться между страничками (по моему, максимум может быть 8 страничек). И всё это делать не через BIOS, делать это в защищённом режиме (а в последующем и в длинном режиме - так как он и является моей конечной целью).

Вторым делом я хочу устанавливать графические режимы и выводить точки на экран (думаю тут уже нескольких страничек/экранов нету). Да и не уверен можно ли тут текст выводить как текст, а не как набор точек (которые я могу сам построить). И опять же, всё без BIOS.

Слышал про стандарт VESA (1.0, 2.0). Вроде бы это самое то, что мне бы было и нужно, но смущает меня одно. Например, операционные системы Minuet и Kolibri. Они для GUI используют VESA. Но я вот не знаю из-за чего (архитектура операционной системы, кривизна рук разработчиков или тупость самой VESA), но GUI в операционной системе работает не идеально (мерцает, как-то замедленно). Как я уже сказал, что не знаю из-за чего это, поэтому и не знаю что делать.

Кто-то ведь и вообще драйвера делает для видеокарт (для NVIDIA GeForce не слышал, а вот для ATI Radeon делают), но ведь для всех видеокарт всё не сделаешь (все черты не охватишь), поэтому всё равно же мне по какому-то стандарту делать нужно.

В общем я не знаю через что делать, но сделать хочу)))

 

Лучше с видео не заморачиваться -- пожалуй, это наиболее сложный аспект низкоуровневого программирования вообще. Установить нужный режим в реальном режиме соответствующим вызовом БИОС, а затем прямо работать с видеопамятью, ничего больше не трогая. Лишь когда всё остальное будет сделано должным образом, можно возвращаться к видео.

 

SII
Пожалуй я с Вами соглашусь.

Думаю для меня будет достаточно использовать 80 столбцов и 25 строк, при 16 цветах и 8 страничками. Видимо видеобуфер будет начинаться с адресной памяти 0x000B8000.

Каждый символ кодируется двумя байтами: 1 байт (символ) + 2 байт (атрибут).

Страничек у нас 8.

То есть в моём случае нужен будет диапазон в 32000 байт (это будет 0x000B8000 - 0x000BFCFF).

Но как же тогда переключать странички из защищённого режима (длинного режима), не переходя в виртуальный режим?

 

s3dworld

Напрашивающиеся два тривиальных решения:

0) А зачем их переключать вообще? Нужно обязательно рисовать на нескольких экранах? Можно копировать целиком экраны на одну страницу - все равно счас вы ничего не заметите; 1) Немного покурить порты VGA, должно быть несложно;

Чуть менее тривиальные:

2) Поискать PM call вход в BIOS'е, может быть VESA; 3) Прологгировать один вызов int 10h при переключении страниц - лог обращения к портам - один раз снял - можно повторить и забыть.

 

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

 

baldr

Я не имел в виду автоматизировать процесс переключения через там какие-то сначала трапы в DRx регистрах а потом повторение лога внутри самой проги Это будет уже нетривиальное решение

Я имел в виду ручатами лог снять и отладить процедурки а потом уверовать что на всех видеокартах это будет работать. Скорее всего будет так как например знакогенератор (загрузка шрифта) всюду где я пробовал - работал хотя лог был снят с одного BIOS.

 

Ну так VGA стандартизирован де-факто, поэтому, пока не выходишь за его рамки, всё будет работать.

 

Для переключения страниц в текстовом режиме есть регистры контроллера CRT, задающие начало отображаемой на экране области в видеопамяти. Ну вот хотя бы: http://www.frolov-lib.ru/books/bsp/v03/ch7_3.htm - индекс регистра записывается в порт 3D4h, значение пишется/читается из 3D5h. Регистры с индексом 0C/0D задают 16 бит смещения начала отображаемой области. Ну и ещё при изменении начала курсор стоит подвинуть, там же регистры с индексом 0E/0F.

Известна проблема с мерцающим курсором при интенсивном выводе графики, и проистекает она от метода вывода курсора в Kolibri (унаследованном от Menuet): перед выводом графики курсор отключается, после вывода включается назад, отсюда мерцание. Проблемы с "как-то замедленно" неизвестно, ввиду неконкретной формулировки могу разве что ответить "скорость нормальная".

 

Всем доброго дня!

Продолжаю составлять для себя справочник по процессору x86. Хочу чтобы Вы скачали его, посмотрели и написали мне в чём я не прав или просто дали бы свои комментарии.

И хочу спросить на счёт глобальной таблицы дескрипторов (LDT - Local Descriptor Table). Скорее всего я её использовать не буду, но знать про неё не помешает. Как я понимаю, это всего лишь часть глобальной таблицы дескрипторов (GDT - Global Descriptor Table). Или не так?

Регистр LDTR (Local Descriptor Table Register) содержит 16 бит доступных для системного программиста. Эти 16 бит должны содержать селектор, в котором в поле TI (Table Indicator) будет стоять значение 0 (выбирать из глобальной таблицы дескрипторов). Таким образом, регистр локальной таблицы дескрипторов будет указывать на элемент глобальной таблицы дескрипторов (то есть LDT будет являться частью GDT).

А что из себя будет представлять этот самый элемент глобальной таблицы дескриптора, на который указывает регистр LDTR? Я нашёл следующее:



Но почему написано "Формат дескриптора таблицы LDT"? Я не понимаю чем должен являться элемент таблицы GDT, на который указывает регистр LDTR и что должно содержаться в сегменте, который описывается этим дескриптором.

Большое спасибо за внимание!

 

LDT -- отдельная таблица, а не часть GDT (в GDT содержится дескриптор LDT -- т.е. ссылка на эту таблицу, а не сама LDT). Использовать не обязательно. Собственно, от неё польза только в том случае, если виртуальная память строится на основе сегментов, а не страниц -- тогда у каждой задачи своя LDT.

 

То есть получается что в таблице GDT, под элементом, куда указывает регистр LDTR, будет содержаться дескриптор формата, который на рисунке выше. Этот дескриптор будет определять сегмент, в котором будут располагаться такие же дескрипторы. Всё так или что-то я не так понял?

А какое исключение будет вызвано если у меня не будет использоваться LDT, но программа пользователя загрузит в сегментный регистр в поле TI значение 1?

 

LDTR содержит селектор сегмента данных, который содержит LDT. Чтобы всё было гладко, сегмент должен быть описан как присутствующий (P==1), остальные атрибуты по вкусу (granularity, expand-down, writable, DPL). Структура LDT совпадает со структурой GDT, так что понимаешь верно.

Если LDTR не загружен правильным селектором (это состояние по умолчанию, или если загружен селектор с нулевыми битами 15…2), обращение к сегменту с селектором у которого TI==1 вызывает #GP(селектор). Это не относится к инструкциям, которые проверяют доступ: lar, lsl, verr и verw.

 

Не такие же. В LDT находятся дескрипторы обычных сегментов, дескрипторы других LDT там находиться не могут. И вообще, в мануале написано всё и достаточно ясно. Учите английский.