OSDev

Так радуйся, что молчат. Если бы не молчали, было бы хуже.

Ты сам вывешивал статью, где рассказывается, как перемещать аппаратные прерывания. А "сместить syscall" означает использовать для него другой вектор. BIOS вешает IRQ0-7 на векторы 8-0Fh, а IRQ8-15 - на векторы 70h-77h, т.е. PS/2-мышь изначально висит на векторе 74h, но ее еще нужно запрограммировать, в том числе и включить генерацию прерываний. Умные люди обычно переносят прерывания 0-15 на векторы 20h-2Fh, перепрограммируя контроллер прерываний, тогда мышка вешается на вектор 2Ch. Компьютер может эмулировать работу контроллера PS/2 с подключенными к нему устройствами, поэтому нет необходимости "pc2 доставать" - достаточно просто включить соответствующую опцию в BIOS Setup. Т.к. 16 аппаратных прерываний - далеко не предел, то лучше зарезервировать, начиная с вектора 30h, некоторый диапазон для расширения числа обрабатываемых аппаратных прерываний. Но можно этого и не делать, т.е. использовать вектор 30h для syscall'а. А если вдруг понадобится расширить число аппаратных прерываний, то сместишь вектор syscall'а (плохой вариант) или будешь использовать для дополнительных аппаратных прерываний векторы выше syscall'а.

Включить генерацию прерываний для pc2, тогда будут сообщения от мышки так же как и от клавиатуры или от таймера?
Подскажите как это сделать? А почему клавиатуру не нужно включать, она тоже ведь эмулируется на свой порт.

Похоже я кое, что нашел тут http://src-code.net/neposredstvennaya-r ... -ps2-tipa/

Здесь я говорил о программном включении прерываний от мышки в контроллере PS/2. За это отвечает бит 1 в "командном байте контроллера".

включаю мышку так, но чтото у меня срабатывает 5 IRQ, это значит ошибка
Может чтото здесь не так?
call mouse_wait

mov al, 0a8h
out 64h, al

call mouse_wait

mov al, 20h
out 64h, al

call mouse_wait1

in al, 60h
or al, 2
mov bl, al


call mouse_wait
mov al, 60h
out 64h, al

call mouse_wait
xchg al, bl
out 60h, al

;; третий шаг


mov edx, 0F6h ; посылка в мышь
call mouse_write
call mouse_read

mov edx, 0F4h
call mouse_write
call mouse_read



jmp end_mouse


mouse_wait:
mov ecx, 100000
@@:
in al, 64h
and al, 2
jz end_wait
loop @B

end_wait:
ret

mouse_wait1:
mov ecx, 100000
@@:
in al, 64h
and al, 1
cmp al, 1
jz end_wait1
loop @B
end_wait1:
ret

mouse_write:
call mouse_wait
mov al, 0D4h
out 64h, al
call mouse_wait
mov ax, dx
out 60h, al
ret

mouse_read:
call mouse_wait1
in al, 60h
ret

end_mouse:

Попробуй повесить обработчик мыши на 5 IRQ, чем чёрт не шутит :)

Мышка заработала!!!!!!!!!!! Перепрограммировал пик.
Не так все и печально оказалось. Я так понял, что клава всегда готова к работе, а мыш надо включать, после чего она читается тоже из 60го порта, но только не один, а три байта или четыре, если включишь колёсико или ещё две кнопки и колесико.
Планирую продумать интерфейс и добавить функции чтения сектора из винта через порты, после чего можно будет разобраться с фат32й.
Кстати что за тема с обратным ходом луча в весе, так можно от мигания избавиться?

Сделал сборку (старт оси), загрузчик загружает несколько метров в верхнюю память, включает видео режим, мышку включает(проверяя есть ли колёсико или колёсико и ещё две кнопки), переходит в защищённый режим, на вектора ставит таймер, клавиатуру, мышку. На экран заливает картинку, ярлычки, пишется текст, отработал перетаскивание ярлычков мышкой по экрану(подобие рабочего стола). Ушло на создание два месяца с нуля.
Если дальнейшее развитие устроить добавлениями блоков, функций, которые знают где в памяти ресурсы и информация, и как врезаться в функции сообщений, добавлять свои вектора в idt и ставить на них свои обработчики?
Например подгружается блок функций для работы с винтом, потом подгружается блок, котрый знает где эти функции и читает файлы с фат32. подгружается блок куртинок часиков, и блок двигающий стрелки, на часиках по времяни, а стандартные функции перемешения объектов по экрану двигают эти часики по экрану. Работает таким способом, в массиве координат расположения на экране объектов берут активный объект и при изменении координат мышки меняют коордиаты объекта и перерисовывают его.
Добавление блоков можно вести без менеджера памяти, только добавляя к переменной размер добавленного блока и следующий грузить дальше.
Каждый сможет докидовать блоки, будь это драйвер, новый векторный шрифт или новая иконка добавленная в меню, панель или рабочий стол, которая запускает игру, просмотр дисков ...
Даже включение мышки и обработчик мышки нужно перевести на отдельный блок, т.к. разные модели мышей обрабатываются по разному, а писать универсальную обработку нет смысла, это затрудняет и замедляет процесс. При смене мышки, менять блоки самому пользователю, не хранить не нужные блоки в системе. На пятикнопочную создать свой блок(подобие драйверов).

Мало конкретики. Это может работать, а может и нет. Если добавлять "блоки" (модули) на уровне исходников, то точки входа в общесистемной таблице (IDT) не нужны - можно обращаться к подпрограммам из других модулей напрямую. Если модули действительно независимы, то в плоской памяти их нужно релоцировать. Нужно иметь возможность проверять, доступен тот или иной сервис или нет. Я тоже использую последовательное размещение модулей ядра в памяти. И также есть возможность вешать сервисные функции непосредственно в IDT, хотя этот способ рекомендуется использовать только для реализации сервиса других ОС. Прикладной сервис ядра реализован через единственную точку входа (точнее их четыре, но они практически эквивалентны), однако в него могут быть встроены сторонние сервисы разными способами. Плюс для каждого модуля ядро может подготовить уникальную, необходимую конкретному модулю, таблицу импорта функций ядра - через эту таблицу модули могут обращаться ко всем экспортируемым функциям ядра (и к user space service, и к kernel space service), а также встроенным в сервис ядра функциям других модулей.

На первом этапе на прямую, для компоновки общего модуля, который будет загружаться при загрузке, дальше уже при работе будут загружаться программы и т.д, там будет другой подход и менеджер памяти.
На первом этапе нужно подсоединить то, что будет загружено в ходе всей работы оси, например функция чтения устройств, а во вторую очередь то, что будет загружено осью, но может быть закрыто, выгружено пользователем, например те же часики.
А в третью очередь то, что пользователь сам открыл, запустил.
Я в первую очередь хочу снабдить систему начальным графическим интерфейсом, оформление, векторные шрифты. Это у меня хорошо получается, и всем понравиться, и дать безграничные возможности, для программирования. Натерпелся я в винде закрытого кода.
Программист сможет, даже, взять адрес LFB и нарисовать на экране то, что захочет, на самом низком уровне, будет иметь доступ ко всем ресурсам в памяти(прописать постоянные адреса системных картинок, иконок в доках к оси), менять можно или у себя на форме рисовать их.

Да, можно скомпоновать единый модуль и из объектных модулей.

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

Ну, здесь у нас подходы совершенно разные. Как я уже сказал, для приложений действует защита. Да и посторонние драйверы не должны лезть напрямую в видеобуфер, даже если знают его адрес. Они это делают от имени какого-либо процесса, обращаясь к видеодрайверу через консольную подсистему. GUI и графический режим я пока не использую (не приоритет). Только текстовые режимы 80x25 и 80x30 знакомест.