В ранние годы развития персональных компьютеров приложения не нуждались в сложных посредниках. Они обращались к аппаратной части напрямую. Программист загружал регистры процессора нужными значениями и вызывал прерывание. Машина сразу выполняла требуемую операцию. Такой подход давал ощущение полного контроля. Несколько инструкций могли изменить изображение на экране или прочитать данные с диска. BIOS хранил готовые процедуры в постоянной памяти. DOS добавляла удобный слой сверху. Вместе они создавали надежную систему общения. Разработчики ценили эту простоту. Код получался компактным а результаты появлялись мгновенно.
Многие отмечали как такая близость к железу меняла процесс создания программ. Если бы пришлось вручную настраивать каждый контроллер то даже простая утилита заняла бы месяцы. Прерывания выступали готовыми мостами. Они брали на себя различия между адаптерами. Производители оборудования подстраивали свои решения под общий стандарт. Программисту оставалось только правильно подготовить вызов. Результат всегда возвращался в тех же регистрах. Эта предсказуемость экономила время и силы.
Механизм программных прерываний как фундамент взаимодействия с аппаратной частью
Процессор получал команду INT с определенным номером. Он автоматически сохранял флаги и адрес возврата. Затем смотрел в таблицу векторов прерываний. Эта таблица располагалась в начале памяти с адреса 0000:0000 и занимала ровно 1024 байта. Каждый вектор состоял из четырех байт два для сегмента и два для смещения. По найденному адресу находился код обработчика. BIOS заполнял таблицу еще на этапе загрузки. Вектор 10h отвечал за видео. 13h за диски. 16h за клавиатуру. DOS перехватывала вектор 21h и расширяла возможности.
Когда программа выполняла вызов процессор переходил по адресу и запускал процедуру. После завершения состояние восстанавливалось. Такая схема работала очень быстро по меркам того времени. Никаких очередей. Никаких лишних проверок. Если AH содержал 00h а AL код режима экран мгновенно переключался. Разработчики любили эту скорость. Они знали что один верный вызов открывает доступ ко всей периферии. Неправильное значение в регистре могло остановить машину. Но именно эта ответственность заставляла писать код с особой аккуратностью. Каждый бит имел значение. Каждый вызов проверялся на реальном оборудовании.
Управление видеоадаптером с помощью функций прерывания INT 10h
Видео прерывание 10h становилось главным инструментом для работы с экраном. Оно поддерживало множество функций. Каждая решала конкретную задачу. Для смены режима AH получал значение 00h а AL номер режима. Режим 03h открывал текстовый формат 80 столбцов на 25 строк с 16 цветами. Режим 13h давал графику 320 на 200 точек с 256 цветами. После вызова экран очищался и становился готов к использованию.
Чтобы установить позицию курсора применяли AH равный 02h. Регистр BH выбирал страницу обычно ноль. DH задавал строку от нуля до 24. DL столбец от нуля до 79. Курсор сразу перемещался в нужное место. Функция с AH равным 03h позволяла узнать текущую позицию. Это помогало в текстовых редакторах где точность имела решающее значение.
Вывод символа в текстовом стиле выполняла функция с AH равным 0Eh. Она работала как телетайп. Символ из AL появлялся на экране а курсор сдвигался дальше. В графическом режиме та же функция выводила буквы уже как набор пикселей. Для прямой записи точки служила функция AH равный 0Ch. Координаты попадали в CX и DX. Цвет в AL. Точка загоралась точно там где нужно.
Многие программы сначала настраивали режим через INT 10h. Затем переходили к прямой записи в видеопамять для максимальной скорости. BIOS выступал надежным инициализатором. Он скрывал различия между CGA EGA и VGA. Разработчик получал одинаковый результат на любом компьютере. Прокрутка экрана тоже входила в набор. AH равный 06h сдвигал окно вверх. CH и CL задавали верхний левый угол. DH и DL нижний правый. AL указывал количество строк. Пустые строки заполнялись заданным атрибутом. Так создавались окна и меню без лишних усилий.
Сервисы DOS для работы с файлами и вводом через прерывание INT 21h
DOS поднимала уровень удобства еще выше. Ее прерывание 21h объединяло множество повседневных операций. AH указывал номер функции. Остальные регистры несли параметры. Все работало стабильно и предсказуемо. DOS сама вызывала BIOS когда требовался низкоуровневый доступ. Получалась плавная цепочка от высокого уровня к железу.
Вот список часто применяемых функций DOS:
AH равный 01h чтение символа с клавиатуры с отображением на экране
AH равный 02h вывод одиночного символа
AH равный 09h вывод строки завершающейся знаком доллара
AH равный 3Dh открытие файла по имени
AH равный 3Fh чтение данных из файла
AH равный 4Ch завершение программы с кодом возврата в AL
Такие вызовы освобождали разработчиков от рутины. Программа могла сосредоточиться на своей логике. Для работы с файлами хватало нескольких шагов. Сначала открытие. Затем чтение блоками по 512 байт. После записи закрытие. Если файл не найден DOS возвращала код ошибки в регистре AX. Разработчик сразу видел проблему и мог вывести сообщение пользователю. Эта система делала приложения доступными для обычных пользователей. Файловая система становилась понятной через простые номера функций.
Доступ к дискам клавиатуре и периферийным устройствам через BIOS прерывания
Дисковые операции шли через прерывание 13h. AH равный 02h означал чтение секторов. AL задавал количество. CH номер цилиндра. CL сектор. DH головку. DL номер диска. BIOS самостоятельно разбирался с контроллером и возвращал данные в буфер по адресу ES BX. Ошибки приходили в регистре AH.
Клавиатура отвечала на прерывание 16h. Функция с AH равным 00h ожидала нажатия. В AX возвращался скан код и ASCII значение. Это позволяло ловить даже специальные комбинации. Функция 01h проверяла буфер без ожидания. Программы реагировали мгновенно.
Принтер обслуживало прерывание 17h. Последовательный порт 14h. Каждое устройство имело свой канал. Общая схема подготовки регистров сохранялась везде. Это делало систему цельной. Аппаратные сигналы от устройств сначала попадали в BIOS. Он обрабатывал их и делал данные доступными через программные прерывания. Нажатие клавиши генерировало аппаратное прерывание 09h. BIOS сохранял код в буфере. Программа потом читала его через 16h. Так разделялись задачи и снижалась нагрузка на код приложения.
Преимущества прямого доступа к железу и связанные с ним риски
Близость к аппаратным компонентам приносила реальную мощь. С несколькими сотнями байт кода получались полноценные игры и утилиты. Минимальные накладные расходы позволяли использовать каждый такт процессора. Программы работали быстро даже на машинах с 640 килобайтами памяти.
Вместе с тем свобода требовала точности. Одно неверное значение в регистре могло перевести систему в нерабочее состояние. Отсутствие защиты между программами делало каждый запуск ответственным событием. Разработчики тестировали код на разных конфигурациях. Они знали что мелкие различия в BIOS могут повлиять на результат. Совместимость оставалась ключевой. Стандарт прерываний позволял одной программе работать на тысячах машин. Производители подстраивали свое железо под общие правила. Это сохраняло экосистему живой долгие годы.
Наследие подхода BIOS в современных компьютерных системах
Методы тех лет продолжают жить. В эмуляторах энтузиасты снова вызывают INT 10h и видят мгновенный отклик. В низкоуровневом программировании для встроенных систем похожие принципы работают до сих пор. Таблица векторов эволюционировала но суть осталась. Современные драйверы выполняют те же задачи по абстрагированию сложного железа только внутри защищенного пространства ядра.
Каждый раз когда приложение быстро рисует графику или читает файл оно опирается на идеи тех первых прерываний. Они показали как стандартизировать доступ к разнообразному оборудованию. Без этого шага индустрия не выросла бы так быстро. Знание тех приемов помогает глубже понимать сегодняшние системы. Почему драйверы живут в ядре. Почему прямой доступ теперь ограничен. И как баланс между скоростью и безопасностью определяет успех любой платформы.
Та эпоха учит что простые и открытые механизмы способны объединять разное оборудование в одну мощную платформу. Каждый быстрый отклик на экране сегодня несет в себе отголосок тех прямых разговоров с железом. Это наследие продолжает вдохновлять новых разработчиков и напоминать о фундаменте на котором выросла вся индустрия.
Канал сайта в Telegram
Канал сайта на YouTube