Контроллер многозадачной ОС

[Conan]

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

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

• Указатель стека в ПЗУ.
• Очень низкий стек (при NMI наползет на данные).
• Возврат в установленные приложением режимы прерывания (IM0-2).
• Торможение приложения (по сравнению с обычным 3,5МГц режимом) во время выполнения ОС своих функций. Невозможность постоянной работы в Turbo при исполнении приложений (игр).

Много лет назад, когда стала очевидна не универсальность iS-DOS (невозможность запуска и остановки неадаптированных игр), возникла идея сделать некий контроллер, который выполнял бы функции аппаратного диспетчера. Дальше идеи и нескольких экспериментов это не развилось, но кое-какие записи остались, и возможно будут любопытны с точки зрения современных подходов.



Контроллер состоял из следующих блоков:

1. Генератор NMI и обработчик его подтверждения.

2. Логика управления памятью: (ОЗУ) для сохранения стека и (ПЗУ) обработчика NMI

3. Детектор режима прерывания

4. Порт управления TURBO.



Немного подробнее о функционале блоков:

1. (наименее проработанное) Запрос NMI возникал в момент перехода от экрана к нижнему Border, в случае если сигнал DOS был неактивен (не происходило обращение к ПЗУ Beta). Обработчик опрашивал M1, MREQ, RD и после подтверждения MNI вырабатывал сигнал для блока №2 и №4 (переключал компьютер в режим Turbo).

2. Блокировалась запись в ОЗУ, и обрабатывались два цикла в память, путем подстановки двух 8-ми разрядных регистров. В них сохранялся текущий PC. Затем с адреса 0000h подключалась ПЗУ с программой обработчиком NMI. Обработка обязательно включала сохранение значения IFF2. Значения всех регистров и состояния, возможно сохранять либо в NVRAM таймера, либо в незадействованных (принадлежащих ОС) страницах ОЗУ.

Затем устанавливалось значение регистра I, разрешались маскируемые прерывания и выдавался сигнал блоку №3.

3. Блок устанавливал значение шины данных равным EFh (один резистор на D4) и генерировал INT. В зависимости от точки входа в процедуру обработки прерывания (28h, 38h или I+ EFh) определялся и сохранялся текущий режим прерываний. Далее управление передавалось ОС.

4. Выполнение функций ОС происходило в режиме TURBO, при этом возврат в приложение синхронизировался либо с нижним Border, либо время исполнения кода ОС было ограничено 1/3 времени нижнего Border. При возникновении (стандартного) INT, происходило переключение из TURBO на нормальную скорость.



Вот такая была идея. Возможно сейчас она покажется бредовой или непроработанной, но тогда она выглядела вполне живой…

[Advertiser]