Просмотр полной версии : Контроллер многозадачной ОС
В разделе «ОСИ» очень бурно обсуждались (правда, сейчас что-то перестали) всякие диспетчеры памяти, вытесняющая и кооперативная многозадачности, и прочие достижения современного программирования. Но вот один вопрос почему то всегда обходили стороной: каким образом гипотетическая ОС должна взаимодействовать с реальными программами, играми, хитрыми защитами и прочим, не переносящим внешнего вмешательства софтом?
Очень хотелось ознакомиться с идеями по прерыванию работы приложений (игр) и переходу в ОС, но к сожалению не нашел ничего детального. Были лишь предложения об использовании 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 на нормальную скорость.
Вот такая была идея. Возможно сейчас она покажется бредовой или непроработанной, но тогда она выглядела вполне живой…
слишком сложно. 8-10 байт на стеке достаточно для запуска ос. небольшим количеством программ со стеком в ПЗУ/данных можно пожертвовать. или, как вариант, прерывать программу только после того, как начата обработка обычного INT - весьма вероятно, в этом месте стека достаточно
А как быть с режимом обычных прерываний?
если имеется защита, она должна работать
А раз защита не терпит вмешателства внутрь себя, то просто его и не будет.
Именно для этого имеется режим совместимости: ОСь теряет контроль над машиной за счёт повышения уровня совместимости со старыми программами.
Если не совсем понятно что это значит, то вспомните в версиях 95/98 Windows была такая весчь как "перезагрузить компьютер в режиме MS-DOS".
Насчёт автоматизации: дело в том, что подавляющее большинство старых программ не имеет данных для интерфейса компоновщика (см. http://zx.pk.ru/showthread.php?t=759 а так же http://zx.pk.ru/showthread.php?t=568), потому система сразу может выдать сообщения типа "рекомендуемый режим - режим совместимости" и после согласия соответственно сохранить себя и запускать программу на страх и риск запускающего (о чём собственно тоже предупреждается).
что обеспечивать любую совместимость надо именно программными средствами, а не аппаратными. Т.е. включать новую схему обработки NMI ради не совсем ясной выгоды в виде возможности прерывать защищённые программы не имеет смысла никакого, общественность наверняка это не поддержит, да и боятся владельцы реальных спектрумов (например, я) в живую машину с паяльником лезть. В новых готовых машинах будучи оно реализовано - пусть, но это не та база, на которой должна писаться система.
А как быть с режимом обычных прерываний?
не понял вопрос... как определить режим прерываний, в котором программа, чтобы правильно вернуться?
не понял вопрос... как определить режим прерываний, в котором программа, чтобы правильно вернуться?Да. Только не теряя на этом время (дожидаясь обычных прерываний).
Именно для этого имеется режим совместимости: ОСь теряет контроль над машиной за счёт повышения уровня совместимости со старыми программами.То есть ОС превращается в наворочанный загрузчик? Ибо даже если помечтать, что ее реализовали, то уж представить, что под нее переработали значительное число игр и другого ПО, ну просто невозможно.
И становится не понятно, зачем все эти многозадачности, менеджеры памяти и сборщики мусора? Какие такие задачи будут вытесняться, кому будет выделяться память, и за кем будет убираться мусор?
P.S. Греть паяльники не предлагалось, хотелось понять каким еще образом (кроме аппаратного) можно (и можно ли) решить проблемы совместимости ОС и основной массы ПО для Speccy.
Да. Только не теряя на этом время (дожидаясь обычных прерываний).
для legacy-приложений переключение только по запросу пользователя, время не критично (переброска базовых страниц памяти из верхних - тоже очень долгое дело). для ось-приложений, понятно, проблема должна быть решена стандартизацией
acidrain
02.06.2005, 10:28
И становится не понятно, зачем все эти многозадачности, менеджеры памяти и сборщики мусора? Какие такие задачи будут вытесняться, кому будет выделяться память, и за кем будет убираться мусор?
Собственно под старый софт ничего автоматизированного не сделать... так сходу. Но, думаю, все эти "навороты" нужны для успешного развития спека в плане программирования и появления софта. Старый будет, по мере возможности и надобности, адаптироваться и корректироваться под новые реалии. Вспомните, когда трдос появился с кассет быстренько все поскидывали на диски? Понимаю трдос хлам переделать несколько сложнее ;)
для legacy-приложений переключение только по запросу пользователя, время не критичноКлассный подход: назовем 99,5% имеющихся программ legacy-приложениями... :confused: Да еще скажем, что небольшая часть из них (внимание мины!) будет невозможно корректно прервать из этой ОС. Ну что же, это тоже подход к решению проблемы.
Собственно под старый софт ничего автоматизированного не сделать... так сходу.А можно объяснить, в чем предложенное решение не рабочее (с технической точки зрения)?
Вспомните, когда трдос появился с кассет быстренько все поскидывали на диски? Понимаю трдос хлам переделать несколько сложнее Вспомнили. Процесс, в котором принимали участие сотни людей по всей стране, затянулся на 4 года (1989-1994). Сейчас это повторить нереально (разве что если автоматизировать адаптацию к новой ОС).
Классный подход: назовем 99,5% имеющихся программ legacy-приложениями... Да еще скажем, что небольшая часть из них (внимание мины!) будет невозможно корректно прервать из этой ОСпочему нельзя прервать? маленькая схемка на генерацию NMI и подмену нулевой банки нужна, но не такие же навороты.... тем более, сколько кадров будет копироваться вся память в верхние банки? imho определение режима прерывания быстрее, чем в один кадр, не стоит такого усложнения
Из-за уже указанной причины (низкий, либо в ПЗУ стек), а кроме того, если не учитывать время (относительно INT) прерывания и возврата, то будет и другая «небольшая часть» программ (особенно демо) которые такого «прерывания» не перенесут.
А зачем каждый раз освобождать всю память? Смысл топика был в том, что бы дать ОС возможность выполнять вспомогательные функции: следить за событиями, которые могут вызвать необходимость прерывания работы приложения.
Что касается «наворотов», то возможно описание выглядит устрашающе, но на практике это реализуется в пяток корпусов мелочевки (если не делать таймер для Turbo, который займет еще три-четыре корпуса).
было время и я проводил подобные эксперименты. кто не знает - есть такие программы MagOS и MemoryCommander последняя идетнична первой только заточена под пент/профи с кешем 8/16кб (написано мной и братом). в ней проводились эксперименты - на Magic по тумблеру подавалась КС (немного смещеный относительно INT). в кеше находился плеер музыки. в принципе это даже работало - можно было например под музыку асмить. схемку для записи PC в регистры при NMI также паял вкупе с моим эмулятором ВГ - при обращениям к ВГ генерилось NMI и работало достаточное кол-во прог с винта - например ЧВ.
Товарищи, а есть ли смысл создавать что-то для совместимости со старым софтом. ZX не та машина, перезагрузка которой занимает бешеное время... А если загрузочный образ ОС "посадить" в верхнюю память (aka MagOS), то перезагрузка вообще займет секунды. И стоит ли напрягаться, когда проще придавить RESET и запустить старый софт?
Товарищи, а есть ли смысл создавать что-то для совместимости со старым софтом.
Конечно же, никто не призывает греть паяльники и переделывать машины. Просто уважаемый jtn и я рассказали о еще одном пути решения проблем, связанных с многозадачностью. Ведь вон какие треды отросли по поводу архитектуры ОС, а мы всего лишь поделились информацией о своем (пусть и невостребованном) опыте в этой области.
ZX не та машина, перезагрузка которой занимает бешеное время... И стоит ли напрягаться, когда проще придавить RESET и запустить старый софт?
Можно конечно и быстро нажимать RESET, имитируя, таким образом, многозадачность. :) Шутка. А если серьезно, то по большому счету кроме старого (однозадачного) софта и нет ничего, и если уж с ним несовместимо…
хорошее или плохое предложение. Смысл в том, что ОСь, буде она с драйверами, будет работать и на предложенном вами варианте (с соответствующим уровнем драйверов), и на старых машинах.
Для меня например, когда я думаю какая ОСь должна быть, минимальное требование к аппаратному обеспечению - ZX 48K и вовсе не обязательно с дисковой ОСью (вплоть до загрузки с ленты). А столь низкие требования обонованы тем, что хочется, чтобы весь парк существующих машин совместимых с ZX, мог работать с ОСью.
Понятно что такое требование достаточно тяжело реализуется, поэтому достаточно сложно и пишется такая система, поэтому и возникают вопросы "а как?..." и т.д.
механизмов, которые бы защищали данные ОС от затирания их программой, которая запущена в legacy режиме: начиная от предложенного копирования в высокую память и заканчивая элементарным сохранением на диск.
механизмов, которые бы защищали данные ОС от затирания их программой, которая запущена в legacy режимеСмысл топика был в другом: избавиться от самого понятия legacy-приложения, и сделать возможной работу всех имеющихся программ под многозадачной ОС. О способах защиты памяти и других механизмах речи не было, ибо до сих пор не предложили решения (кроме топика) позволяющего передавать управление ОС, не повреждая то самое legacy-приложение.
ибо до сих пор не предложили решения (кроме топика) позволяющего передавать управление ОС, не повреждая то самое legacy-приложение.
На базе Z80 оно вообще невозможно. Единственный вариант - NMI, но и он вилами на воде.
На базе Z80 оно вообще невозможно. Единственный вариант - NMI, но и он вилами на воде.Если лениво читать с начала, напомню, что решение, предложенное в первом постинге этого топика именно на NMI. А насчет "вилами по воде", так никто и не привел примера, когда бы указанный контроллер не сработал с реальной программой для Speccy.
acidrain
06.06.2005, 12:34
А можно объяснить, в чем предложенное решение не рабочее (с технической точки зрения)?
Цитата:
Сообщение от acidrain
Вспомните, когда трдос появился с кассет быстренько все поскидывали на диски? Понимаю трдос хлам переделать несколько сложнее
Вспомнили. Процесс, в котором принимали участие сотни людей по всей стране, затянулся на 4 года (1989-1994). Сейчас это повторить нереально (разве что если автоматизировать адаптацию к новой ОС).
Я, вообще-то, не утверждал, что что-то в предложенной вами схеме не рабочее. Я имел ввиду, что некоторые программы без переделки ручками будет не реально заставить работать в новой оси.
Да и потом, все прекрасно понимают, что без переделки спектрума новой оси не жить. Это будет очередной издось. =)
ПС. Судя по датам - не четыре года, а 5 лет ;)))
Я имел ввиду, что некоторые программы без переделки ручками будет не реально заставить работать в новой оси.Про новую ОС ничего не знаю, речь шла о топике.
ПС. Судя по датам - не четыре года, а 5 лет ;)))Границы достаточно условные, определялись массовым (опять же условно) выходом адоптированных дисковых версий. Например, в 1989 году встречались "перцы" торговавшие на играми на дисках, сброшенными через Magic...
А насчет "вилами по воде", так никто и не привел примера, когда бы указанный контроллер не сработал с реальной программой для Speccy.
стек в пзу... и труба... или в жизненно важной области типа таблицы смещений...
если кто не помнит - адрес возврата кладется в стек...
стек в пзу... и труба... или в жизненно важной области типа таблицы смещений...
если кто не помнит - адрес возврата кладется в стек...
Чукча писатель или читатель? :)
Блокировалась запись в ОЗУ, и обрабатывались два цикла в память, путем подстановки двух 8-ми разрядных регистров. В них сохранялся текущий PC.
Писатель-писатель. подумаем следующим образом:
Пусть даже PC сохранен. Но остальные-то регистры тоже куда-то девать надо. Вопрос - куда. Вариантов много - подключать "теневое" ОЗУ и т.д. Но как после этого в прогу вернуться - хоть убей, ума не приложу. Если только опять же "перехватывать" чтение из памяти как для TR-DOS и возвращать установку PC (JP) на исходный адрес, сохраненный в регистрах. Но это уже чересчур...
Но как после этого в прогу вернуться - хоть убей, ума не приложу. Если только опять же "перехватывать" чтение из памяти как для TR-DOS и возвращать установку PC (JP) на исходный адрес, сохраненный в регистрах. Но это уже чересчур...
Отключать теневое озу - по факту исполнения команды RETN, например. Или после аута в спец.порт с задержкой (в расчёте на последовательность out (#xx),a:retn ).
Это варианты 'навскидку'.
в моем варианте было так:
pop af
sv_sp equ $+1
ld sp,#yyyy
out (#b7),a
retadr equ $+1
jp #xxxx
даная конструкция находилась в теневом озу, причем последний OUT вне зависимости от значения рег.A делал задержку выключения этого озу на 1 команду (стробировалось сигналом M1). никакой сложности и нагромождений минимум.
Отключать теневое озу - по факту исполнения команды RETN, например.
RETN куда? Если стек уже восстановлен и находится в ПЗУ...
А для OUT (xx),A нужно повредить регистр A... Если конечно это не "универсальный" порт.
В последнем случае (jtn), с задержкой - нормально. Но насколько легко это "присобачить" к железу?
В принципе, если железная и эмулируемая реализация будут, могу взяться переписать RTK под NMI...
А для OUT (xx),A нужно повредить регистр A... Если конечно это не "универсальный" порт.
В последнем случае (jtn), с задержкой - нормально. Но насколько легко это "присобачить" к железу?
регистр не нужно "вредить", т.к. (я об этом специально написал выше) используется только факт записи - значение А может быть произвольным, еще и к тому же данная команда не портит флаги.
сложного ничего нет, единственно, что на ZX BUS нет сигнала, блокирующего ОЗУ - я для этого ставил резистор в разрыв /WE и выводил на шину.
С возвратом все достаточно просто (lvd и jtn уже рассказали как). Достаточно сразу после выборки RETN подключить (поочередно) два регистра, где хранился SP. Реализуется так: RETN расположена в специально выбранных адресах (ПЗУ), что было легко дешифрировать (переключением одного адреса). Почти весь дешифратор, включая обработчик NMI это небольшая ПЗУ (например РФ2).
Как правильно заметил jtn, кроме сигнала блокировки записи в ОЗУ, на большинстве шин (например, ZX Bus) все сигналы есть.
Почти весь дешифратор, включая обработчик NMI это небольшая ПЗУ (например РФ2).
зачем такой геморрой? мой вариант много проще
зачем такой геморрой? мой вариант много прощеРФ2 занимает относительно мало места, и позволяет по минимуму нагружать шину адреса: какой либо дешифратор порта(ов) все равно нужен, а тут "все в одном флаконе". Кроме того для отладки очень удобно, не надо перепаивать, достаточно прошить... Кроме того в изначальном варианте, нужно было еще управлять TURBO, для того что бы нагонять время, занятое обработкой NMI и иже с ним.
чтобы снять все вопросы привожу свою схему. на самом деле она так и не была собрана =) но прототип, построенный по тем же принципам (только адрес запоминался в жвух ир23) вполне работал себе. Недописишникам тоже думаю будет интересно в свете выхода их эмулятора вг-шки (между прочим выхода которого я уже жду 7 месяцев )
А вот такая схема была у меня (восстановил по памяти). Не нарисовал только герератор NMI. Это либо счетчик, либо одновибратор (АГ3), привязанная к бордюру.
Сигналы управления:
RAM/ROM - отключение чтения из ОЗУ
WPRT - блокировка записи в ОЗУ
ROM SEL - переключение ПЗУ (основного и с обработчиком MNI)
....
Некрасиво ворошить старые ветки, но прочитав здесь сообщения, не обнаружил ни слова об эмуляции Z80. На Спектруме-128к пишется программа, которая шаг за шагом выполняет инструкции Z80, находящиеся в любой игрушке для Спекки. Таким образом скорее всего можно запустить почти любой старый софт без переделки. Но вот работать это будет оооооочень мееееедленно.
:)
Black_Cat
17.09.2009, 03:06
Но вот работать это будет оооооочень мееееедленно.:) ..ну да.. взгляд на многозадачность глазами программиста :)
mastermind
17.09.2009, 16:30
:) ..ну да.. взгляд на многозадачность глазами программиста :)
Кстати, господа железячники, проясните плз, почему даже в современных клонах вы до сих пор ставите железный Z80? Это дешевле или с чем-то другим связано? Ведь "софткорку"-то как раз вполне можно было бы доработать с тем чтобы добавить менеджмент контекста процессора и т.п. :)
:) ..ну да.. взгляд на многозадачность глазами программиста :)
Кхе-хе =)
Эмулятор Z80 на Z80 давно написан.
И это действительно Ооооочень Меееедленнно.
Это дешевле или с чем-то другим связано?
Дешевле. И пока доступней. И паять легче гораздо :)
Кстати, господа железячники, проясните плз, почему даже в современных клонах вы до сих пор ставите железный Z80? Это дешевле или с чем-то другим связано?
Последний пень вроде как не имеет железячного Зет80, там на альтере всё прошито.
mastermind
18.09.2009, 19:57
Дешевле. И пока доступней. И паять легче гораздо :)
Я имел ввиду компы, где все (или почти) на ПЛИС, кроме z80. В этом случае проц уже не обязательно паять :) (если вентилей в плисине достаточно).
В этом случае тоже железный z80 дешевле?
В этом случае тоже железный z80 дешевле?
Если ПЛИС не ниже Циклона, и стоИт там по умолчанию, то проц конечно можно запихнуть, 2000LE всего занимает. Хотя... мне лично это не нравится. "Живой" процессор - это и сердце, и мозги, и душа Спектрума. А так - зомби какое-то получается :)
mastermind
18.09.2009, 21:15
Если ПЛИС не ниже Циклона, и стоИт там по умолчанию, то проц конечно можно запихнуть, 2000LE всего занимает. Хотя... мне лично это не нравится. "Живой" процессор - это и сердце, и мозги, и душа Спектрума. А так - зомби какое-то получается :)
Спасибо за разъяснения. Ну я так и думал, что без вопроса религии тут не обошлось ;)
а тут кругом одна религия... как упихать логику в плис, так это не эмулятор и абсолютно нормально, а как проц...
а как проц...
Тут гораздо проще, корка очень сильно не дотягивает до оригинала по недокументированным приколам
Black_Cat
19.09.2009, 18:35
Тут гораздо проще, корка очень сильно не дотягивает до оригинала по недокументированным приколам..если бы только по недокументированным - то и хрен бы с ними - давно пора программистов бить по рукам за такие дела, но боюсь она и по документированным не дотягивает.. и проблема именно в ловле блох.. вон svofsky до сих пор переписывает 8080 :)
---------- Post added at 17:51 ---------- Previous post was at 17:09 ----------
Ведь "софткорку"-то как раз вполне можно было бы доработать с тем чтобы добавить менеджмент контекста процессора и т.п.тебе лавры Феггина не дают покоя? :) ..тут старые баги ещё не выловлены, а ты предлагаешь ещё и новых добавить.. :)
а вот объясните мне популярно, программисты пишут эмуляторы того же Z80 на си, причем, учитывая все док. и не док. особенности. пусть, возможно, не все учтено (может мы до сих пор чего-то не знаем), но ведь эмуляторы отлично работают. и вопрос у меня в чем: неужели написать эмулятор на HDL принципиально намного сложнее, чем на си? на си писали его уже кучу раз с нуля.
принципиально намного сложнее, чем на си?
думаю никто себе такую цель не ставил, а писать на HDL гораздо сложнее чем на С
проще разбирать тонны кода и втыкать туда костыли? странно все это...
Мож ты не в курсе (а то реплики какие то странные), корку Z80 писали не для спектрума. Делали реализацию Z80 соответствующую спецификациям + добавили самые популярные недокументированные инструкции.
Powered by vBulletin® Version 4.2.5 Copyright © 2024 vBulletin Solutions, Inc. All rights reserved. Перевод: zCarot