Эксперимент

[SfS]

. Так что может быть не стоит вот так сразу откидывать идею с GUI? Хотя, вероятно, именно для Спектрума GUI вовсе и не нужен...
Примерно об этом я и писал вот здесь: http://zx.pk.ru/showthread.php?t=168

От ГУЯ отказываться не надо. Просто ГУЙ - это отдельная довеска, которая может быть в ОС, а может ее и не быть. Короче уровень ОС - это драйвер экрана, мыши и клавиатуры. А уровень ГУИ - это просто программа или набор библиотек для рисования окошек, кнопок и так далее. Нужен пользовательской программе ГУЙ - подгружаем этот набор библиотек и используем, не нуже - не надо и память занимать.

В общем ОС - это ядро. А ГУЙ - это пользовательская программа. ИМХО так правильнее.

[Advertiser]

[SfS]

Это как раз идеология унихов - всякие там / и все девайсы как файлы etc. В результате имеем монструозное ядро. Да и к тому же унихам ММУ нужен (ну есть конечно uClinux, но думаешь он спасёт на Z80?).

ММУ - не обязателен, хотя и желателен. Что касается "монстроидности" ядра - все зависит от набора его функций. Если взять минимальный набор - то ядро совсем компактненькое получается. Реально - у меня для ARMа реализация менеджера памяти (кстати - тоже без ММУ) и стандартного интерфейса драйверов - около 5 Кбайт занимает. И это учитывая, что длина команды ARMa - 16 бит всегда (в режиме THUMB, который я использую). Для Z80 - программа явно короче будет.

Ну да - глупость, когда например в винде таски обменивааться месагами могут только через окошки =) Я говорю, что может быть это и глупость, но таки позволила хоть куда-то уехать - мне навскидку трудно прикинуть, с какой скоростью будет работать честная многозадачная ос на спеке и сколько будет жрать ОЗУ, етц.

Основная память и ресурсы - жруться не ядром ОС, а программами пользователя и подгружаемыми драйверами. Отсюда вывод - чем больше у тебя устройств приткнуто к спеку - тем больше памяти драйвера будут занимать. Сколько временннЫх ресурсов ОС жрать будет - это вообще отдельный вопрос. Тут все зависит от того какой тип многозадачности и какими приоритетами обладают задачи. Главное - следует помнить, что большинство функций ОС запускаются не "сами по себе", а только в результате обращения к ОС программы пользователя.
Особенно важно распределить приоритеты задач. Я в свое время писал для AT90S8535 программку для управления тех процессом. У меня была жесткая привязка к реальному времени следующих вещей - 4 7сегментника, три канала АЦП - измерения напряжения трежфазной сети. Молодой был, глупый. Пока приоритеты правильно между задачами не распределил - индикатор маргал неравномерно и ьбезбожно, сеть мерялась ужасно. Думал быстродействия не хватает, а оказалось - приоитеты задач - это не пустой звук. Переделал - все как часы заработало.
С точки зрения программ пользователя - ресурсопрожорливость вообще не оценить - откуда я могу знать какой очередной изврат "крутых хацкеров" пожелают под ОС запустить ? Скорее всего придется делать режим "монопольное использование процессора" для нормального запуска программ, где все привязано к тактам проца.

[Vitamin]

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

1) многозадачность нужна. как показывает практика, большую часть времени процессы проводят в ожидании ввода/вывода, т.е. ожидания чтения с носителей (в случае спека не совсем актуально- чтением занимается процессор) или ввода пользователем чего-нибудь. имеет смысл использовать свободное время с пользой.
2) прошивка ядра ОС вместо ПЗУ (как вариант- кеш), потому что основной памяти и так мало
3) делать ядро из модулей (типа линуха). в начальной поставке идет универсальное ядро, поддерживающее всевозможное железо или минимальную конфигурацию, работающую где угодно. юзер на целевой машине конфигурирует сборщик, определяя нужные ему возможности и выкидывая ненужные. ядро пересобирается. все довольны.
4) графический пользовательский интерфейс (не путать с Hacker User Interface ) возможен, но далеко не обязателен, а в силу ограниченных возможностей и нежелателен. отсюда вытекает невозможность привязки событий и проч. к оконной структуры (как в винде). имхо, следует обратить свой взор к *nix системам (что было сделано в предыдущих постах)
5) если углубляться дальше, то нужно затронуть тему диспетчеризации процессов. с целью уточнения, проконсультировался с преподом у себя в универе. согласно выдвинутым требованиям, он предложил схему с двумя классами процессов- реального времени и разделения времени. процессы реального времени выполняются каждый квант диспетчеризации по цепочке. это могут быть процессы времени, обслуживания ау и проч. остальные процессы распределяются согласно своим приоритетам в оставшееся свободное время.
6) менеджмент памяти. вот тут возникают довольно большие проблемы. в частности изза страничной организации памяти. нижнюю память можно отдать на откуп системы для хранения структур, таблиц и проч. а в верхних страницах хранить процессы. проблема в диспетчере, который должен обеспечивать контроль всей доступной верхней памяти (пусть с точностью до блока в 256 байт)- сложности в ее переменном количестве и возможности разделения одной области памяти несколькими процессами. в принципе эта проблема почти решена, дело за реализацией чтобы проверить идею.

фух. выдохся %)
хочется услышать мнение народа
(2spectrum: я же тебе говорил, что надо делать базу а не оболочку
оболочка без содержания- воздушный шарик, который можно помять)

[SfS]

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

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

2) прошивка ядра ОС вместо ПЗУ (как вариант- кеш), потому что основной памяти и так мало

Однозначно - кэш. Тогда ОС можно апгрейдить и изменять без перепрошивки ПЗУ. Огромный плюс.

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

Ядро и драйвера к нему должно поставляться либо в исходных текстах (для крутых кульхацкеров) либо просто под конкретную конфигурацию, которая в общем определяется набором встроенных- и подгружаемых драйверов. Скажем будет версия "SuperpuperOS v,Pentagon-1024" или версия "SuperpuperOS v,АТМ-7.10". Пользователь ее скачивает, устанавливает и работает - без гребли с компиляцией.

4) графический пользовательский интерфейс (не путать с Hacker User Interface ) возможен, но далеко не обязателен, а в силу ограниченных возможностей и нежелателен. отсюда вытекает невозможность привязки событий и проч. к оконной структуры (как в винде). имхо, следует обратить свой взор к *nix системам (что было сделано в предыдущих постах)

Привязка событий к окошкам - это извратик. Есть понятие "процесс". Есть понятие "сигнал". Несколько "процессов" могут обмениваться "сигналами" межу собой. А рисует процесс окошко или передает данные по модему - не принципиально.

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

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

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

Не вижу больших проблем. Надо хранить таблицу (точнее список) страниц по 16К и свободного места на них. При программировании вся программа разбивается на сегменты длиной не более 16К, что вполне достаточно для весма нехилого куска кода. В начале кажого сегмента программы имеется таблица адресов точек входа. Никакой сегмент программы не может обращаться к другому сегменту иначе, как через эту таблицу. Данными процессы обмениваются через посылку сигналов друг другу, через файлы и через область разделяемых данных в памяти.

Распределение памяти мне видется примерно таким:
------------------------- #FFFF
Пользовательские процессы.
------------------------- #C000
Область разделяемых данных
------------------------- #8000
Системные таблицы+подгружаемые драйвера
------------------------- #4000
Ядро+встроенные драйвера.
------------------------- #0000

Такая схема будет работать минимум на 128к, если есть возможность повешать на NMI таймер (хотя можно и через INT - но повиснуть может). Главное, чтобы имелся порт для включения теневого ОЗУ с адреса #0000.

[random]

в общем я полностью согласен, именно так себе и представляю такую ОСь.

только одно дополнение к таблице памяти - возможное резервирование экрана (пускай даже Ч/Б) максимум 6912 байт.

[CityAceE]

Теоретиков, вижу, много. А где же практики???

[random]

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

[breeze]

Мдя Идей вижу много, идей хороших и неочень, но вот в чем вопрос, а чего всё это грузить? с дискет ? не кажется ли вам, что стоит начать написание оси с начального старта компьютера, с boot-strap'а ?
короче нужна FS! будет FS - будет над чем работать! (я как раз и работаю над этим вопросом )

кста по поводу раздела памяти #4000 - #8000 - таблицы и подгружаемыые драйвера ? по поводу таблиц ничего против не имею, а вот надчет дров, все видимо дружно заб(и/ы)ли что это область slow memory !!! и всё это будет жутко торрмозить! единственное для чего эта область пригодна это для хранения данных!!!

[random]

breeze, не тормози. написание оси да и вообще всего что угодно начинается не с bootstrap'а, а с толкового ТЗ. с чего грузить, с чего грузить. это вообще вопрос десятый.

[CHRV]

breeze, не тормози. написание оси да и вообще всего что угодно начинается не с bootstrap'а, а с толкового ТЗ. с чего грузить, с чего грузить. это вообще вопрос десятый.

Золотые слова. Поэтому скорей всего никогда Оси не появится, ибо во первых делают в одиночку, а во вторых не знают совершенно что делают .
Кстати не раз уже об этом писал!