К видеорежимам современных видеокарт

Разработка операционной системы рано или поздно доходит до интерфейса взаимодействия с пользователем. Это взаимодействие подразумевает как ввод, то есть клавиатуру и мышь (не обязательно), так и вывод, то есть видео и аудио. 90% информации человек получает визуальным путем, поэтому и мы подробнее остановимся на нем.

Ещё хочу высказать свое мнение по поводу разработки ОС. Мне кажется, что если и решать рано или поздно в своих планах доходить до процесса разработки интерфейса взаимодействия с пользователем, то делать это следует все-таки рано. Почему? Хотя бы для предотвращения различного рода опасных влияний на разработчиков. Ведь именно разработчики проводят с будущей ОС на страпелях большое количество времени, и так уж получается, что большое количество этого большого количества времени проводится за компьютером. Разумеется есть время проектирования архитектуры, когда за компьютером сидеть даже вредно, гораздо приятнее и полезнее прогуляться по природе и подметить заодно у неё несколько фенечек, которые очень даже неплохо смотрелись бы в приложении к компьютерам, порисовать диаграммы и графы и вообще предаться гуманитарной литературе, однако реальность берет свое и вот уже надо писать исходный код.

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

Никто не смеет умолять и разработку таких вещей как управление памятью, планирование заданий (если ОС многозадачна, если она однозадачна, то задания планирует пользователь). Однако и не надо сосредотачиваться лишь на них одних, паралелльно с ними должна вестись разработка интерфейсов ввода вывода.

Как уже говорилось добрый разработчик ОС должен закладываться не только на технические параметры будущей ОС, но и на многие другие, в том числе везде знать свою меру в общем, и свои бюджеты в частности. Мало того технология --- лишь интструмент в руках зодчего и не самый важный. Уильям Гейтс заботился о бюджете собственной ОС и добился успеха. Линус Торвальдс и иже с ним заботились о социальных аспектах жизни разработчиков ОС и также добился успеха. Андрю Танненбаум не заботился ни о том ни о другом и остался не у дел. Об этом сказано.

А раз так, то наилучшим выбором для видеоинерфейса на начальном этапе создания исходного кода является стандарт VESA. Его поддерживают почти все видеократы, поэтому пока можно не заботится о драйверах, которые могут своим дурным и невообразимым количеством сломать или/и разбалансировать архитертуру будущей ОС. Итак об этом видеорежиме.

В стандарте VESA выделим пока две версии: 1.2 и 2.0.

Версия 1.2 предназначена для работы в реальном режиме процессора. Доступ к видеопамяти осуществляется через так называемое окно памяти --- область размером (в нашем случае) 65535 байт. Дело в том, что при режиах современных мониторов, таких как 1024х768х32бита память видеобуффера существенно больше --- около 4 Мбайт. А надо сохранить совместимость с 16-разрядным DOS и режимом VGA. Поэтому доступ к памяти осуществляется в два шага: 1) накладываем окно и 2) меняем память в пределах окна. Потому можно наложить окно в другое место и т. д. Это --- неудобно, однако для работы в реальном режиме на мой взгляд нет другого выбора.

Версия 2.0 поддреживает работу в защищеном режиме. Для этого специальной функцией прерывания (0Ah) запрашивается интерфейс защищенного режима. Этот интерфейс представляет собой таблицу указателей на функции, порты и участки памяти. Более подробно о формате таблицы описано в [1]. Вот пример кода:

mov ah, 4Fh ; Признак SVGA
mov al, 0Ah ; Получить интерфейс для защищенного режима.
xor bl, bl ; bl=0
int 10h ; прерывание 10h
; Теперь в AX --- статус
; ES - сегмент таблиы
; DI - адрес таблицы
; CX - длина таблицы

Таким образом получаем абслоютный адрес, который буцдет правильным в защищеном режиме.

Другой особенностью версии 2.0 является линейный кадровый буфер (LFB). Он позволяет представить видеобуффер как линейное адресное пространство и не обращаться к нему посредство окон памяти, что просто хорошо.

Таким образом стандарт VESA предоставляет нам интерфейсы как дляреального режима, так и для защищенного, что позволяет работать с ним с самого начала разработки ОС.

В [2] описан стандарт VESA 1.2 по-человечески, однако на английском языке. Там же приведен алгоритм построения программы, которая будет работать с этим стандартом.

Список литературы:

1. http://www.codenet.ru/progr/video/vesa201.php
2. ftp://binboy.sphere.pl/specifications/graphics/vesasp12.zip

>>В моем релизе появилось ядро .

ГДЕ ЯДРО??? Один джамп это еще не ядро.... А где системныефункции, которые вызывает программа пользователя? Где собсно программа пользователся?

Самый главный недочет: ваше "ядро" не вызывает программ пользователя. Оно сразу после загрузки предлагает выключить компьютер... Когда ж программа пользователя при таком раскладе успеет вызвать системную функцию ядра?

PS Вызов из юзермода системных функция ядра - по меньшей мере нестабильно. Опыт 95 винды ничему не научил?

Интересно узнать, и какие же у вашегр ядра системные фунуции?

Уважаемый тов. Горлов, А где же русские коментарии на русском языке для русских разработчиков?

В моем релизе появилось ядро . Теперь программа пользователя вызывает системные функции ядра .


CODESEGM SEGMENT PARA ''CODE''
ASSUME CS:CODESEGM,DS:CODESEGM,ES:CODESEGM,SS:CODESEGM

ORG 100H
START: JMP MAIN
;----------------------------------------------------------------------------

;----------------------------------------------------------------------------
MAIN PROC NEAR
CALL KERNEL
CALL USER_TASK
MAIN ENDP
;----------------------------------------------------------------------------
KERNEL PROC NEAR
JMP METKA2
;----------------------------------------------------------------------------

;----------------------------------------------------------------------------
CALL INIT_INT_F0H
RETN
KERNEL ENDP
;----------------------------------------------------------------------------
INIT_INT_F0H
TAKE_INT_FUNC
OUT_TEXT
SOUND
CHECK_KB
POWER_OFF
;----------------------------------------------------------------------------
USER_TASK PROC NEAR
;----------------------------------------------------------------------------
TEXT_1 DB ''PRIVET$''
TEXT_2 DB ''POWER_OFF$''
;----------------------------------------------------------------------------
LEA BX,TEXT_1
MOV AX,0001H
INT F0H ;OUT_TEXT
MOV AX,0002H
INT F0H ;SOUND
LEA BX,TEXT_2
MOV AX,0001H
INT F0H ;OUT_TEXT
MOV AX,0003H
INT F0H ;CHECK_KB
MOV AX,0004H
INT F0H ;POWER_OFF
RETN
USER_TASK ENDP

CODESEGM ENDS
END START

Мужики! Вы реальные вещи делаете! Я не умею программировать операционные системы и языки программирования! Но рад Вы это умеете! Если операционная система будет лучше windows и проста в использовании! Я обязательно куплю её! Обязательно лицензионную! Да даже сам фактор того что она русская будет меня к ней тянуть! :) Удачи ВАМ!

>>Это исходник моего релиза .

ЭТО вы называете ОС?

>>3. вызовы своих процедур без системных функций
Не понял.

>>6. передача данных в стек и возврат их из стека делается при отлюченном прерывании
При каком? Все прерывания отрубаются?

>>7. Формат программы - сом с возможностью тестирования в ДОСе
Так я не понял - мы делаем свою ОС или программы под ДОС?

> часто переработка архитектуры в ходе реализации приводит к кашмару, анархие и бардаку.

Да, вы правы. Это происходит довольно часто. Просто в жизни все несколько сложнее. Может так получиться что есть не очень опытный архитектор и достать другого нету никакой возможности. Тогда возможно внесение изменений в изначально дурную архитектуру в процессе разработке окажется и не так уж плохо.

Другой случай может быть когда сам проект достаточно сложен, сложен так, что продумать его архитектуру без реализации очень сложно. Например, разработка ОС. Понятно, да?

Новости для тех кто желает разрабатывать дополнения моего релиза .
1. Модульная структура .
2. Объявление в начале переменных , констант , буфера под временные переменные .
3. вызовы своих процедур без системных функций
4. вызов системных процедур через системное прерывание
5. код должен быть понятным при минимальных комментариях , использование аналогов команд для оптимизации и быстродействия недопустимо
6. передача данных в стек и возврат их из стека делается при отлюченном прерывании
7. Формат программы - сом с возможностью тестирования в ДОСе
8. прилагать хелп с комментириями о программе .
Хорошо ?

Новости .
1. Формализация данных
- глабальные переменные и константы
- локальные переменные и константы
- временные переменные .
Хранение данных
- глабальные в начале программы
- локальные в начале каждой процедуры
- временные в стеке
Модели абстракции
- системная абстракция
- процедурная абстракция
- временная абстракция
- аппаратный уровень

Это исходник моего релиза .


CODESEGM SEGMENT PARA ''CODE''
ASSUME CS:CODESEGM,DS:CODESEGM,ES:CODESEGM,SS:CODESEGM

ORG 100H
START: JMP MAIN
;------------------------------------------------------
;это область для глобальных констант и переменных

;------------------------------------------------------
;это область для сообщений
TEXT_1 DB 10,10,07H,''ВАС ПРИВЕТСТВУЕТ РУССКАЯ ОПЕРАЦИОННАЯ СИСТЕМА$''
TEXT_2 DB 15,10,07H,''ВЫ ХОТИТЕ ВЫКЛЮЧИТЬ КОМПЬЮТЕР? ДА(ENTER)$''
;------------------------------------------------------
MAIN PROC NEAR

CALL SET_VMODE
LEA AX,TEXT_1
CALL OUT_MESS
CALL SOUND
LEA AX,TEXT_2
CALL OUT_MESS
CALL CHECK_KB
CALL POWER_OFF
MAIN ENDP
;------------------------------------------------------
;это область для вызывемых процедур

SET_VMODE
OUT_MESS
SOUND
CHECK_KB
POWER_OFF
;------------------------------------------------------
CODESEGM ENDS
END START

>>Если есть желающие улучшать мой релиз - приглашаю .

Я желаю. Но как мне ео улучшать, если я его не вижу? Хотя бы мало-мало описание напишите-то. Из вашего сайта можно понять только, что релиз состоит из "имитатора загрузчика" и все. Что еще вы уже сделали?

>>Таким образом полная открытость позволяет оптимизировать и дорабатывать архитектуру проекта в процессе разработки.

Гнать надо таких архитекторов )
часто переработка архитектуры в ходе реализации приводит к кашмару, анархие и бардаку.

>Открытось, закрытость.

Для модульности, открытость или закрытость не так уж важна.

В первую очередь важно разработать интерфейсы модулей, и строго использовать только эти интерфейсы.

>Открытось, закрытость.
яб сюда добавил индивидуальность.
Предположим есть человек пишет окончательную версию.
И есть какое то кол-во программистов которые по задумке того же архитектора пишут различные части системы и передают код вот этому человеку, он в свою очередь изучает этот код, вносит если нужно в него свои изменения и добовляет в окончательный вариант.