Пишем свою ОС. Теория

[Black_Cat]

По всем остальным пунктам - это UZIX

Интересно, а что меньше рихтовать напильником нужно UZIX или СР/М? И вот ещё, хотелось бы понимать аппаратные требования к этим системам и экспертная оценка сравнительного быстродействия.

---------- Post added at 20:11 ---------- Previous post was at 19:59 ----------

По пункту 1 - это не задача ОС и его бы по-хорошему вообще сюда не выносить. Точнее, для выполнения п.1 от ОС требуется только перекинуть блок данных с диска в память и сделать jmp в этот код. Всё! Никакого окружения воспроизводить не надо

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

[Advertiser]

[Error404]

Интересно, а что меньше рихтовать напильником нужно UZIX или СР/М? И вот ещё, хотелось бы понимать аппаратные требования к этим системам и экспертная оценка сравнительного быстродействия.

UZIX будет, может, чуть медленнее (т.е. не в разы), чем стандартная CP/M 2.2 (хотя правильнее сравнивать с MPM). Которая как известно тоже написана на ЯВУ, и в более поздние времена для CP/M были написаны замены для BDOS, написанные на АСМ и более быстро работавшие. В-общем, все решаемо (до приемлимого и даже лучше) тупо допустимым разгоном процессора.

Рихтовать примерно одинаково сложно - что MPM, что UZIX (если решить некоторые "проблемы стартапа" - я тупо не смог запустить компилятор). Исходники есть и там и там, и инструкции по портации с примерами.

Тут в обоих случаях (MPM/UZIX) главный вопрос за счет чего решать переключение контекстов процессов. Если есть диспетчер, который позволяет работать большим окном (48к или более) как к примеру в Орионе или ATM (про другие клоны не в курсе), то переключение контекстов будет происходить быстро. Со стандартным маленьким окном в 16к (и соответственно кучей LDIR) - медленно.

[/COLOR]А как у тебя при этом многозадачность будет реализовываться? Ведь для многозадачности нужен планировщик, являющийся функцией ядра и распределяющий время и память между задачами, а так же контролирующий ротацию задач. Нужно так же обрабатывать внешние вызовы и т.д., чем собсно ОС и занимается..

C многозадачностью в случае работы систему в варианте пункта 1 врядли что-то путное выйдет без существенного изменения аппаратной части - ведь особенность кода из наследства Спектрума (наиболее интересного) в том, что он работает "по железу". Поэтому для него и не нужно окружение ОС (API). Ну и что? Кому интересна многозадачность во время, к примеру, игры? Я на РС то этим не пользуюсь когда завожу игруху, система в этот момент всегда становится "однозадачной" сугубо по моему пользовательскому желанию.