Каковы должны быть принципы новой ОС?

Я множество раз задумывался над таким вопросом - достаточна ли вычислительная мощность Спектрума для реализации на нем полноценной многозадачной ОС? И вообще, если рассматривать проблему шире, нужна ли новая ОС Спектруму? Для ответа на эти вопросы, давайте для начала постараемся определить для себя - что такое ОС на Спектруме и для каких целей она предназначена (или, дальше, должна быть предназначена)?

Этим вопросам была посвящена масса публикаций в различной прессе и они вызывали (и продолжают вызывать) довольно серьезный резонанс. Например, казалось бы, вполне очевидный вопрос - является операционной системой BASIC48? Можно вступать в продолжительную полемику, спорить об этом, но вывод один: BASIC48 - это язык программирования, в который интегрированы некоторые функции, присущие ОС. Однако сделано это несколько неудобно и, извиняюсь, даже можно сказать, коряво (вероятно, в силу "недописанности" BASIC48).

Теперь второй вопрос: является ли TRDOS полноценной ОС? Во-первых, давайте исходить из того, что это все-таки ОС, а вернее - ИСКЛЮЧИТЕЛЬНО ДОС. На сколько она является законченной, стабильной и "не-сырой" - это вопрос, который, пожалуй, и вызвал широкие дискуссии на эту тему.

То есть, основная проблема ОС-ДОС на Спектруме - это безнадежная устарелость концепций и приоритетов, заложенных в основу BASIC48 и TRDOS. Устарелость - это одно; глючность и недописанность - это то другое, что уже не позволяет молчать...

Цель создания этой темы - определить основные принципы, так сказть, "идеологию" ОС. На мой взгляд, нет необходимости в изначальность ставить графический интерфейс, и т.д. Необходимо создать ОС, ядро которой будет минимально. Ядро, которое посредством инкапсулирования функций распределения памяти (читайте "Менеджер памяти..." в этом разделе), и других, вызывающих конфликт моделей Спектрума, будет по-возможности конфигурированием "сглаживать" чрезмерное обилие стандартов и несовместимость.

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

А что вы думаете по этому поводу?

А вот какие мысли пришли мне:

Помните диалог Алисы и Чеширского кота из «Алисы в стране чудес»?

Алиса спрашивает кота:
- Скажите, пожалуйста, куда мне отсюда идти?
- Это во многом зависит от того, куда ты хочешь прийти,- ответил Кот.
- Да мне почти все равно,- начала Алиса.
- Тогда все равно, куда идти,- сказал Кот.
----------------------------------------------------------

Есть такой стандартный подход, в проектной деятельности, при выработке общего понимания чего-либо (Shared Vision):

1.Описание проблемы (где мы находимся)

2.Цели разработки (куда мы хоти придти)

3.Предлагаемое решение (путь)



Мысли изложенные dwt мне очень понравились взвешенностью, но до тех пор как мы не поймем и четко опишем эти три пункта, даже самые смелые идеи и взвешенные рассуждения могут не дать результата при выработке «принципов новой ОС».


Что бы не провоцировать флейм, скажу лишь что это – IMHO :smile:

Цитата:

---

Сообщение от Conan

А вот какие мысли пришли мне:

Помните диалог Алисы и Чеширского кота из «Алисы в стране чудес»?

Алиса спрашивает кота:
- Скажите, пожалуйста, куда мне отсюда идти?
- Это во многом зависит от того, куда ты хочешь прийти,- ответил Кот.
- Да мне почти все равно,- начала Алиса.
- Тогда все равно, куда идти,- сказал Кот.
----------------------------------------------------------

Есть такой стандартный подход, в проектной деятельности, при выработке общего понимания чего-либо (Shared Vision):

1.Описание проблемы (где мы находимся)

2.Цели разработки (куда мы хоти придти)

3.Предлагаемое решение (путь)



Мысли изложенные dwt мне очень понравились взвешенностью, но до тех пор как мы не поймем и четко опишем эти три пункта, даже самые смелые идеи и взвешенные рассуждения могут не дать результата при выработке «принципов новой ОС».


Что бы не провоцировать флейм, скажу лишь что это – IMHO :smile:

---

Да!
Spectrum (логин такой :) ) предложил создать группу по вопросам ОС. Как вы сотноситесь к тому, что если группа людей, объединившись, выработает концепцию ОС и начент ее создание? Как мне кажется, это будет выходом из ситуации. Кто желает вступить в эту группу?

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

особенно для операционной системы.

Цитата:

---

Сообщение от random

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

---

Работа в текущем режиме, на сколько я смею судить, является лишь разговором. Нет четкой, хотя бы одной концепции.
В принципе, никто не против публичного обсуждения чего-либо. Но предложите концепцию, которую НУЖНО обсуждать, и в которую можно вносить коррективы. А говорить в общих чертах, как это происходит сейчас (извиняюсь, воду в ступе толочь :()...
Нет конкретики... А ограниченному числу людей легче будет договориться... Естественно, это IMHO

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

Просто соедините во едино аргументы всех сторон по интересующему вас вопросу и выложите. Очевидно что кто-то должен контролировать процесс, но не обсуждение. Например делите задачу на недели обсуждения. Если времени не хватает, то продолжаем чуть дольше.

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

Сам бы с удовольствием этим занялся, но одному мне такое дело не поднять. Нужна группа модераторов нового раздела про разработку. У ограничивать число разработчиков только из-за того что хочется побыстрее... Вы куда-то опаздываете? Без толкового ТЗ и постоянного развития это начинание будет обречено на гораздо более быструю смерть нежели DOORS (так и не вышла), не говоря уже о долгожителе IS DOS.

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

А вот ещё немного ИМХО.

При проектировании ОС нужно решить много вопросов. Некоторые из них распадаются на подвопросы. Однако основные это:
-- Модель исполнения. Параллельность и синхронизация.
-- Управление памятью.
-- Ввод-вывод
-- Обработка прерываний (у Speccy их совсем немного)

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

Я вижу только единственный способ движения вперёд. Кто-то должен предоставить РАБОТАЮЩИЙ, ДОКУМЕНТИРОВАННЫЙ, С ЧИТАБЕЛЬНЫМИ ИСХОДНИКАМИ, ПРИГОДНЫЙ К ДАЛЬНЕЙШЕМУ РАЗВИТИЮ прототип. Только вокруг конкретного, а не абстрактного центра кристаллизации могут собраться единомышленники. Именно так разработаны все открытые программные проекты. Другого пути нет.

Теперь немного о культуре обсуждения.

Зачем обсуждать?
Такое ощущение, будто обсуждающие думают, что здесь присутствует большое количество "блестящих кодеров", которые только и ждут, когда им представят "гениальную архитектуру", останется лишь реализовать её и наступит счастье. :)

Зачем обсуждать?
Нужно ли обсуждать то, что давно исследовано, обосновано и изложено в УЧЕБНИКАХ по теории операционных систем? Не полезнее ли прочитать эти учебники? А на досуге изучить архитектуру нескольких конкретных реально существующих операционных систем, не укладывающуюся в прокрустово ложе этих учебников.

Тем не менее, я не против обсуждений. Но настоятельно рекомендую придерживаться правила
ОДНА ВЕТКА ФОРУМА = ОДНО АРХИТЕКТУРНОЕ РЕШЕНИЕ.
Что происходит при невыполнении этого правила вы видели - обсуждается, к примеру, конкретный метод управления памятью, потом вдруг приходит некто и "толкает" свою "идею". После этого некоторые участники продолжают обсуждать первую идею, в то время как другие переключаются на вторую. Через некоторое время возникает полная неразбериха. Создаётся ещё одна тема. В ней снова повторяется эта ситуация. Поэтому, если у кого-то есть конкретная идея архитектурного решения, он ДОЛЖЕН создать для неё новую тему. В этой теме будут обсуждаться достоинства и недостатки ТОЛЬКО одного этого конкретного решения. Такой более систематизированный способ обсуждений будет способствовать большей продуктивности этих обсуждений, и появлению новых, лучших, идей.

Вот что мне "нравится" :( в этом форуме что каждый отвечает так как он хочет... вот conan поставил ряд вполне грамотных вопросов, но никто не торопится на них попробовать ответить...

Цитата:

---

Сообщение от Conan

Есть такой стандартный подход, в проектной деятельности, при выработке общего понимания чего-либо (Shared Vision):

1.Описание проблемы (где мы находимся)

---

Мы находимся в "гудке", причем полном :rolleyes: на данном этапе у нас есть бейсик48, чуть расширенный 128й и эмулятор кассетных образов на диске ! - TR-DOS (именно с этой целью он и создавался)

Цитата:

---

2.Цели разработки (куда мы хоти придти)

---

хотим придти? хотим возможность доступа к HDD и CD-ROM, как на уровне выбора начальной загрузки, так и произвольный доступ к файлам (не знаю конечно, если вдруг кому и понадобится можно и поддержать в basic , типа как rand usr 15619:rem bla-bla-bla); так же хотим иметь возможность запуска одной и более программ в памяти одновременно, хотим переключения между ними.

Цитата:

---

3.Предлагаемое решение (путь)

---

решения два: либо мы переписываем TR-DOS, BASIC и еже с ними (геморно, нудно, долго - но зато будет совместимо со страрым веком ),
либо мы посылаем всё к черту и пишем так как думаем с возможной эмуляцией среды для особо привязванных (программ и игр). Хотя я думаю что если программа ценна то её можно и отучить от того же ПЗУ. Но как мне кажется для новой ос - будут и новые программы...

Цитата:

---

Сообщение от breeze

Вот что мне "нравится" :( в этом форуме что каждый отвечает так как он хочет... вот conan поставил ряд вполне грамотных вопросов, но никто не торопится на них попробовать ответить...

---

Об этом я и хтел сказать - давайте КОНЦЕПЦИИ!!! Ведь ответы на поставленные Conan`ом вопросы - это и будет обобщенная концепция!

Цитата:

---

Сообщение от breeze

Мы находимся в "гудке", причем полном :rolleyes: на данном этапе у нас есть бейсик48, чуть расширенный 128й и эмулятор кассетных образов на диске ! - TR-DOS (именно с этой целью он и создавался)

---

Вот-вот, и я о том же. Тем более, плюс ко всему - обилие стандартов не только памяти и скорости, но и различных других временных характеристиках. То есть все эти неровности должна "сглаживать" ОС. А что у нас?... :(

Цитата:

---

Сообщение от breeze

хотим придти? хотим возможность доступа к HDD и CD-ROM, как на уровне выбора начальной загрузки, так и произвольный доступ к файлам (не знаю конечно, если вдруг кому и понадобится можно и поддержать в basic , типа как rand usr 15619:rem bla-bla-bla); так же хотим иметь возможность запуска одной и более программ в памяти одновременно, хотим переключения между ними.

---

Я думаю, что проблема во многом еще и втом, что мало кто представляетчто именно нужно, что именно необходимо. Говорят, необходимо поступить так-то так-то, как на платформе той-то. Но не будем забывать, что каждая платформа уникальная и то, что, к примеру, пригодно для С64 по каким-то уникальным аспектом не пройдет на Спектруме. Да, необходимо учитывать опыт, но работать надо в сторону своих, спектрумовских интересов. У Спектрума, на мой взгляд, основная "железная" проблема - это обилие различных вариаций схем, откуда, как я уже говорил, чрезмерное обилие стандартов. Поэтому и ОС необходимо ориентировать на сглаживание этих неровностей... Разве это не часть "постановки проблемы"?
Если мы справимся с этим аспектом (предусмотрение в ОС менеджера памяти, ориентированного на работу с драйвером памяти, в принципе подробная концепция изложена на соответствующей теме раздела), то уже тогда можно с помощью модульности и открытости подулючать hdd, реализовывать tcp/ip-стек, и т.д.

Цитата:

---

Сообщение от breeze

решения два: либо мы переписываем TR-DOS, BASIC и еже с ними (геморно, нудно, долго - но зато будет совместимо со страрым веком ),
либо мы посылаем всё к черту и пишем так как думаем с возможной эмуляцией среды для особо привязванных (программ и игр). Хотя я думаю что если программа ценна то её можно и отучить от того же ПЗУ. Но как мне кажется для новой ос - будут и новые программы...

---

Проблематично, на мой взгляд. Я думаю, вполне можно пойти путем, предлагаемым SfS, читай раздел "Менеджер памяти", там выложена интересная концепция.

Цитата:

---

Сообщение от breeze

Мы находимся в "гудке", причем полном :rolleyes: на данном этапе у нас есть бейсик48, чуть расширенный 128й и эмулятор кассетных образов на диске ! - TR-DOS (именно с этой целью он и создавался)


хотим придти? хотим возможность доступа к HDD и CD-ROM, как на уровне выбора начальной загрузки, так и произвольный доступ к файлам (не знаю конечно, если вдруг кому и понадобится можно и поддержать в basic , типа как rand usr 15619:rem bla-bla-bla); так же хотим иметь возможность запуска одной и более программ в памяти одновременно, хотим переключения между ними.

решения два: либо мы переписываем TR-DOS, BASIC и еже с ними (геморно, нудно, долго - но зато будет совместимо со страрым веком ),
либо мы посылаем всё к черту и пишем так как думаем с возможной эмуляцией среды для особо привязванных (программ и игр). Хотя я думаю что если программа ценна то её можно и отучить от того же ПЗУ. Но как мне кажется для новой ос - будут и новые программы...

---

судя по тому "где мы" и "куда хотим прийти", все опять забыли про IS-DOS :D
чего жутко не хватало(ет) исдосу - нормального менеджера памяти. ну да ладно.

А вообще все тут говорят - разные схемы бла-бла-бла. но при этом вообще без оси под дырдосом пишут работающие проги, имея в качестве траблов только memory>128k. короче мысль в том что все эти отличия схем - несущественны, для ОС, на память - менеджер памяти, на диски - драйвера, и все будет работать. Никакой Спек не "особенный", все то же что и для других, тут работать будет. и более того - под исдосом ВСЕ это работает вполне корректно и удобно. вот только память там через одно место...

мысль номер два - отличия базовых архитектур минимальны, а вот перспективных и потенциальных (для которых ОС вроде как и планируется) - существенны, и вот именно БУДУЩИЕ архитектуры и должна корректно поддерживать ОС, даже пока они нам и неизвестны. Т.е. ВМЕСТЕ с ОС надо думать о новом железе (а вот вопрос его целесообразности, вернее экономической хотя бы неубыточности - под вопросом)

мысль номер три - блин забыл, пока думал первые две ;)

а, мысль номер три :) - пора бы обоснованно отваливать местами от асма к тому же си например. Культура программирования, например, структурность и тп, на асме нулевая (хотя тоже возможна). Т.е. пора бы серъезно задуматься о модульности, структурности и ЯВУ.

а что, уже появился приличный C для Z80?
а если в асм добавить IFcond ... ELSE ... ENDIF (кстати в некоторых вариантах асма это даже макросами можно сделать), то код получается вполне даже блочный. Если еще и PROC / EPROC есть, который позволяет ограничивать область видимости локальных меток, то вот вам и модульность. Не ожидаю особой радости от применения ЯВУ на спеке.

Здесь уже пролетал совет (в треде про менеджмент памяти), про то что прежде чем дискутировать на тему, желательно вообще то говоря в теме разбираться.

В любой нормальной книге по ОСям имеется чёткое разделение: для чего нужны ОСи, почему они создаются так, а не иначе.
Каждая ОСь создаёт т.н. виртуальную машину, которая позволяет абстрагироваться от особенностей вашей реальной (физической) машины.
Пример: пусть у вас на машине имеется N-ое количество памяти для работы программ. Тогда за счёт возможностей ОСи (вариант с файлом подкачки) количество доступной для приложения памяти увеличивается.

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

Теперь по задачам.

Задача, которая ставится вообще - создание нормальных средств разработки ПО и залог развития Speccy как платформы с средствами разработки.
Подзадачи: разработка ОСи, ЯВУ (языков высокого уровня)

Т.е. написание ОСи нужно не само по себе (не как самоцель) а как подзадача создания комфортного общения пользователя/программиста с компьютером.

Любое ядро ОС состоит из двух компонентов:
- Менеджер задач (даже для однозадачных систем)
- Менеджер памяти
Т.о. главное для любой ОСи - написать её ядро (менеджеры задач и памяти)

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

Т.о. именно за счёт специфики общей модели Спектрума разработка менеджера памяти и менеджера задач должна вестись параллельно с разработкой всех остальных частей системы (драйверы устройств вввода/вывода).

Цитата:

---

Сообщение от Conan

1.Описание проблемы (где мы находимся)

---

Проблема в отсутствии единой среды разработки и единой среды пользования для компьютера ZX Spectrum любой модификации.

Цитата:

---

Сообщение от Conan

2.Цели разработки (куда мы хоти придти)

---

Хоти придти к созданию указанных средств.

Цитата:

---

Сообщение от Conan

3.Предлагаемое решение (путь)

---

Решение - создать многозадачную ОСь, создать ЯВУ (по крайней мере Си).

1. Физический уровень - драйвера
2. Системный уровень - виртульная машина
3. Пользовательский уровень - консоль/GUI и т.д.

Физический уровень написать несложно (память, FDD, HDD и т.д.)
Пользовательский уровень конечен и вообще говоря пока не важен.
Системный уровень - его собственно и предстоит разработать.

P.S. К уровням не придираться, упростил.

Цитата:

---

Сообщение от GriV

Задача, которая ставится вообще - создание нормальных средств разработки ПО и залог развития Speccy как платформы с средствами разработки.

---

хотел бы отметить что развитие как платформы - в первую очередь аппаратное развитие. т.е., да, таки нет в базовой конфигурации ни таймера на нми, ни хорошей схемы управления памятью. НО если мы рассматриваем развитие - то должны ОЧЕНЬ сильно учитывать существование хотя бы eZ80 (про возможность работы параллельно с ним на периферии скажем ARM или TI пока вообще молчу, а хотелось бы единую среду вобще-то), а там управление памятью несколько иное (24-битное)

Цитата:

---

Сообщение от GriV

Т.е. написание ОСи нужно не само по себе (не как самоцель) а как подзадача создания комфортного общения пользователя/программиста с компьютером

---

и с тем кто эти компьютеры разрабатывает/производит, if будут таковые ;)

Цитата:

---

Сообщение от GriV

Проблема в отсутствии единой среды разработки и единой среды пользования для компьютера ZX Spectrum любой модификации

---

любой МЫСЛИМОЙ модификации тогда уж :-)))))))))

проблема в том, что сначала нужно определить, на какую модель аппаратной архитектуры ориентироваться. если сильно абстрагироваться, то вообще можно занятся портированием *никсов, только результатом будет тормоз и масдай. если же сильно привязаться к архитектуре, результатом будет торможение аппаратного развития платформы. т.е. проблема по-большому счету в том, каким мы видим будущее ZX и какой вообще дорогой идем, товарищи. пока что мы топчемся на месте вокруг да около архитектуры ZX-128k...

но это пожалуй тема отдельного топика...

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

Цитата:

---

Сообщение от dwt

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

---

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

Цитата:

---

Сообщение от Ronin

хотел бы отметить что развитие как платформы - в первую очередь аппаратное развитие. т.е., да, таки нет в базовой конфигурации ни таймера на нми, ни хорошей схемы управления памятью. НО если мы рассматриваем развитие - то должны ОЧЕНЬ сильно учитывать существование хотя бы eZ80 (про возможность работы параллельно с ним на периферии скажем ARM или TI пока вообще молчу, а хотелось бы единую среду вобще-то), а там управление памятью несколько иное (24-битное)

---

Здесь есть множество возражений: любое развитие аппаратной части происходит иммено из-за "завышенных" потребностей к железу от ПО. Мировая практика показывает это. Потом, я бы порекомендовал тебе повнимательней читать все сообщения в этом треде - в виртуальной машине тебя не будут волновать ни таймеры ни память - ничего.
А про eZ80 ARM TI (вначале бы объяснил что это такое - мне например непонятно), все эти тонкости и лягут на плечи системы. Про 24 бита вообще выглядит как бред, это уже не спектрум...

Цитата:

---

Сообщение от Ronin

и с тем кто эти компьютеры разрабатывает/производит, if будут таковые ;)

---

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

Цитата:

---

Сообщение от Ronin

любой МЫСЛИМОЙ модификации тогда уж :-)))))))))

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

---

Вот уж точно имеет тебе смысл про ОСи почитать общие обзоры... чтобы *nix'ы были тормозами и mustdie... :D да тебя любой системщик засмеёт.

Хорошо, пусть не *nix-интерфейс, тогда что ты предлагаешь?

Цитата:

---

Сообщение от GriV

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

---

Да мое высказывание о приближающейся тупиковости и этой темы касалось не Вас, GriV. И говорить конкретно я призываю уже который раз!!! Да, сегодня я постараюсь выстроить свое предложение (КОНКРЕТНОЕ предложение) концепции, чтобы не быть голословным. И если другие будут не против, предоставлю ее для обсуждения.

предполагается стандартная архитектура (вплоть до ZX16).
1. Вытесняющая многозадачность использует прерывания второго рода. Все задачи работают при включенных прерываниях
2. Имеется монопольный режим (отключаются прерывания второго рода или запрещаются прерывания вообще) - в простейшем случае инициализируется командой запрета прерываний, нормально должен быть разрешён системой. Область применения: драйверы блочных устройств, режим совместимости
3. Каждая задача имеет отдельный стек, отдельный heap и т.д.
4. Менеджер задач для каждого процесса выделяет структуру:
4.а) Регистры (в том числе стек)
4.б) Приоритет
4.в) Текущее значение приритета (накопительная часть приоритета)
4.г) Точка прерывания
4.д) Флаги процесса
4.е) Индексы используемых файлов
4.ж) и т.д.

Цитата:

---

Сообщение от GriV

Про 24 бита вообще выглядит как бред, это уже не спектрум

---

это не бред, а реальный проц Zilog (eZ80), наиболее логично развивающий концепции Z80, 8 бит данных и 24 бит на адрес. про ARM, TI вообще забудьте.

Цитата:

---

Сообщение от GriV

Потом, я бы порекомендовал тебе повнимательней читать все сообщения в этом треде - в виртуальной машине тебя не будут волновать ни таймеры ни память - ничего

---

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

Цитата:

---

Сообщение от GriV

Вот уж точно имеет тебе смысл про ОСи почитать общие обзоры... чтобы *nix'ы были тормозами и mustdie... да тебя любой системщик засмеёт

---

давайте тогда портируем линух на z80 3.5mhz и все, чего тут шума нашумели-то :D

Народ!

А где те, кто уже занимался подобными вопросами ?
Давайте спросим у них - пусть чего умного скажут :)

Vitamin что-то когда-то делал. Очень толковое, кстати.

Aqua OS кто делал ? DOORS ? NEOS ?

Может они чего посоветуют умного ?

Вообще делать виртуальную машину, в отдаленном хотя бы подобии виндовой, - боюсь, спек не вытянет по скорости.

Мне, как разработчику хочется, о чем уже говорили: ram manager и файлы.

Вот, кстати в BGE что-то было интересное. Да, это граф редактор и тут ни при чем, но в нем именно реально и неплохо (по скорости, простоте, доступности) реализованы некоторые вещи.

Работа с курсором - отлично
Система прерываний - хорошо. Можно и di:halt и просто к уже имеющемуся обработчику можно присосаться. Это же надо и в оси.

Потом вопрос прошивать ли такую ось в ПЗУ ? Скажем теневое ? Как NEOS ? Есть куча плюсов. Быть может главный - защищенного режима аппаратного нет - значит чуть что не так - всё накрывается. А так, можно сказать, хоть какая-то защита от затирания ядра оси в памяти.

система точно хранится не в ПЗУ. Система должна запускаться даже на 48К а там уж точно нет теневого ПЗУ. В крайнем случае это может быть 128BASIC, но тогда жертвуется парк 48к машин...
Ядро настраивается под тот тип, которые использовать наиболее оптимально.
Минимальным (самым неоптимальным) ограничителем является 48К машина.
От затирания (кстати это чисто техническая деталь) ни одна система не защищена.
Для защиты предлагается как раз использовать два типа приложений: классические (не под ОСь) и оптимальные (специально написанные под ОСь). Последние чисто технически будут ограждены от того, чтобы испортить систему...

Цитата:

---

Сообщение от Знахарь

значит чуть что не так - всё накрывается

---

винт нас спасёт куда лучше чем ПЗУ.
слетел - перезагрузись (пару сек).

Цитата:

---

Сообщение от Ronin

винт нас спасёт куда лучше чем ПЗУ.
слетел - перезагрузись (пару сек).

---

Винт не вписывается в концепцию минимального ядра... Это модуль "extern". На мой взгляд, конечно....

в ПЗУ это чтото не то, сами посудите как надо обновить версию ядра, то надо бежать искать программатор, программировать, а у кого то ПЗУ жёстко запаяно, а как быть владельцам скорпионов, у которых на ПЗУ вся оснастка лежит?

скажем так, с самого начала подразумевалась доработка когда можно в страницу с адресом 0 вписать страничку ОЗУ. если уже сейчас начались вопросы по второму кругу, то надо однозначно создавать ФАК и прибивать гвоздями в этом разделе.

Вот. Значит вывод: в ПЗУ не шьем ?

Griv, ну как ты на ПЦ, к примеру, просто так затрешь ось ? Там это аппаратно невозможно. А тут нужно аккуратненько и программно.

DWT прав. Винт - довесок. К нему надо кучу софта, но опять :( на ПЦ с винта грузиться или не с винта - пофиг. Верно ? А в нашем случае это целое дело! И тут опять как и с ПЗУ: у кого он есть, у кого его нет :( Думаем. Я с винтом не работал на ZX :( Может, кстати с него и можно грузиться как с дискты сразу после ресета. Тогда это уже гораздо лучше. Тогда, как в ПЦ boot сектор какого-то стандарта. и прога смотрит чего откуда и как грузить дальше: хоть linux хоть macOS :))))

Так, страничку ОЗУ с 0 ? Слушайте, народ... А как вообще кто себе представляет процесс загрузки ОСИ ну и по порядку. ? Т.е.

1. reset
2. с адреса 0 начинает работать.... 128 basic ?
3. из TRdos грузим boot - ОСЬ ?
4.

или как ?

идёт следующими этапами.
Оговорка: первоначальная загрузка ОСи должна осуществляться хоть с магнитофонной ленты, поэтому привязка к версии ПЗУ должна быть минимальная.

1. Включение компьютера (аппаратный сброс, RST 0)
2. Загрузка первичного ядра системы в память
3. Первичное ядро производит самоорганизацию в зависимости от того, что имеется в распоряжении (память, FDD, HDD и т.д.)
4. Происходит уничтожение первичного ядра и инициализация системного ядра
5. Загрузка интерфейса (консоль или GUI)
6. Собственно всё :)

Хорошо. Т.е. грузится типа обычный boot стандартными средствами ? Ось висит в ОЗУ как всяка прога, не юзает ПЗУ и полностью напрямую работает с периферией своими средствами ? А сколько она тогда будет жрать памяти ? И как удобно станет кодить ?

Выскажу свои мысли (правда кое-что я подглядел у других).

Три подхода (концепции) к созданию ОС:



Demo-подход.

1.Много всего сделано вокруг, но мне ничего не нравится, а самое главное среди этого нет моего или оно не самое крутое.

2.Хочу самореализоваться, занять место на пати, прописать свое имя… ну, в общем, что бы все удивились, и было круто.

3.Делаем что-то, что называем ОС. Она должна быть многозадачной, многопоточной, многоуровневой, многооконной, многоплатформенной, и еще много-много всего. Работать это должно не обязательно, главное обозначить. Затем выкладываем очередной макет (круто оформленный) на всеобщее обозрение и забываем про это дело навсегда. Какое то время все в отпаде.



iS-DOS-подход

1.Нет прослойки между «разношерстным» оборудованием и… приложениями, которые предстоит разработать и играми, которые предстоит написать или переписать.

2.Нужна универсальная операционная система, без «наворотов», но позволяющая реально задействовать имеющееся оборудование, начиная от различных принтеров и заканчивая жесткими дисками, модемами и CD-драйвами.

3.Собирается команда единомышленников (как правило, на коммерческой основе) и начинает многолетний труд. В процессе реализации приходится идти на массу компромиссов и упрощений. В результате получается OC пригодная для работы с десятком не самых лучших приложений, созданных специально под нее и некоторым количеством портированных игр. Заканчивается все, так же как и с iS-DOS, только намного быстрее, ибо на руках реальных пользователей нет прежнего кол-ва Speccy, а данная ОС делает невозможным запуск большинства игр или Demo. Да и оплачивать труд разработчиков никто не торопится.



Подход супер-загрузчика

1.Есть определенная модель Speccy (клон), у которого масса всяких наворотов в железе, да только вот используются они все разрозненно или не поддержаны вообще.

2.Нужно создать нечто, работающее исключительно с данным клоном, возможно вживив это «нечто» в его архитектуру. При этом в функции этого «нечто» должна входить возможность запуска игрушек для Speccy, ибо без этого клон будет неполноценным.

3.Создаем супер-коммандер с поддержкой HDD, CD и DVD. Забываем про многозадачность и универсальность, зато почти не теряем в совместимости. Такой коммандер живет очень долго (пока жив клон), но не получает сколько ни будь широкого распространения. Даже эмуляторщикам он не очень интересен, поскольку у них уже есть доступ к HDD, CD и DVD и масса других удобств.



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



Если вы знаете о других подходах (уже имевших место быть или реализуемых), поделитесь этими знаниями. Думаю, всем будет интересно.

комбинация из частей:
демо 1 и 3
isdos 2 и 3 (разница не в годах, а в человеко-часах)
супер 2

повторяю, не все целиком, только некоторые моменты с которыми я согласен.

Соглашусь с IS-DOS походом! Конан, давай!

Я только не пойму, Конан, ты реалист или пессимист :)

Цитата:

---

Сообщение от Знахарь

Соглашусь с IS-DOS походом! Конан, давай!

---

Бери сколько хочешь:
http://trd.speccy.cz/sbor/is-dos/ISDBASE1.ZIP
http://trd.speccy.cz/sbor/is-dos/ISDBASE2.ZIP
:wink:

Цитата:

---

Сообщение от Знахарь

Я только не пойму, Конан, ты реалист или пессимист :)

---

Оптимист :wink: - иначе не читал бы километровые треды в надежде на то, что хоть немногое из описанного будет реализовано на практике.

как насчёт драйвер-ориентированой трдос ?
концепт такой :

трдос есть у всех. в неё вносится менеджер драйверов/резидентов которыми может управлять любая трдос программа. т.о. есть у вас расширенный экран - загрузите драйвер вашего экрана и новые программы работающие с моделью драйверов будут его использовать.

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

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

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

Замечательно.
Только это скорее не "драйвер-ориентированная" а "модульная" система.

Цитата:

---

трдос есть у всех. в неё вносится менеджер драйверов/резидентов которыми может управлять любая трдос программа. т.о. есть у вас расширенный экран - загрузите драйвер вашего экрана и новые программы работающие с моделью драйверов будут его использовать.

---

Проблема - разные видеорежимы иогут иметь разное пиксельное и цветовое разрешение, а также пиксели разной степени неквадратности.