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

[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]

[SMT]

слишком сложно. 8-10 байт на стеке достаточно для запуска ос. небольшим количеством программ со стеком в ПЗУ/данных можно пожертвовать. или, как вариант, прерывать программу только после того, как начата обработка обычного INT - весьма вероятно, в этом месте стека достаточно

[Conan]

А как быть с режимом обычных прерываний?

[GriV]

если имеется защита, она должна работать
А раз защита не терпит вмешателства внутрь себя, то просто его и не будет.
Именно для этого имеется режим совместимости: ОСь теряет контроль над машиной за счёт повышения уровня совместимости со старыми программами.
Если не совсем понятно что это значит, то вспомните в версиях 95/98 Windows была такая весчь как "перезагрузить компьютер в режиме MS-DOS".
Насчёт автоматизации: дело в том, что подавляющее большинство старых программ не имеет данных для интерфейса компоновщика (см. http://zx.pk.ru/showthread.php?t=759 а так же http://zx.pk.ru/showthread.php?t=568), потому система сразу может выдать сообщения типа "рекомендуемый режим - режим совместимости" и после согласия соответственно сохранить себя и запускать программу на страх и риск запускающего (о чём собственно тоже предупреждается).

[GriV]

что обеспечивать любую совместимость надо именно программными средствами, а не аппаратными. Т.е. включать новую схему обработки NMI ради не совсем ясной выгоды в виде возможности прерывать защищённые программы не имеет смысла никакого, общественность наверняка это не поддержит, да и боятся владельцы реальных спектрумов (например, я) в живую машину с паяльником лезть. В новых готовых машинах будучи оно реализовано - пусть, но это не та база, на которой должна писаться система.

[SMT]

А как быть с режимом обычных прерываний?

не понял вопрос... как определить режим прерываний, в котором программа, чтобы правильно вернуться?

[Conan]

не понял вопрос... как определить режим прерываний, в котором программа, чтобы правильно вернуться?

Да. Только не теряя на этом время (дожидаясь обычных прерываний).

Именно для этого имеется режим совместимости: ОСь теряет контроль над машиной за счёт повышения уровня совместимости со старыми программами.

То есть ОС превращается в наворочанный загрузчик? Ибо даже если помечтать, что ее реализовали, то уж представить, что под нее переработали значительное число игр и другого ПО, ну просто невозможно.
И становится не понятно, зачем все эти многозадачности, менеджеры памяти и сборщики мусора? Какие такие задачи будут вытесняться, кому будет выделяться память, и за кем будет убираться мусор?



P.S. Греть паяльники не предлагалось, хотелось понять каким еще образом (кроме аппаратного) можно (и можно ли) решить проблемы совместимости ОС и основной массы ПО для Speccy.

[SMT]

Да. Только не теряя на этом время (дожидаясь обычных прерываний).

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

[acidrain]

И становится не понятно, зачем все эти многозадачности, менеджеры памяти и сборщики мусора? Какие такие задачи будут вытесняться, кому будет выделяться память, и за кем будет убираться мусор?

Собственно под старый софт ничего автоматизированного не сделать... так сходу. Но, думаю, все эти "навороты" нужны для успешного развития спека в плане программирования и появления софта. Старый будет, по мере возможности и надобности, адаптироваться и корректироваться под новые реалии. Вспомните, когда трдос появился с кассет быстренько все поскидывали на диски? Понимаю трдос хлам переделать несколько сложнее

[Vovoi]

Некрасиво ворошить старые ветки, но прочитав здесь сообщения, не обнаружил ни слова об эмуляции Z80. На Спектруме-128к пишется программа, которая шаг за шагом выполняет инструкции Z80, находящиеся в любой игрушке для Спекки. Таким образом скорее всего можно запустить почти любой старый софт без переделки. Но вот работать это будет оооооочень мееееедленно.