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

[Ronin]

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


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

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

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

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

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

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

[Ronin]

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

[Vladimir Kladov]

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

[GriV]

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

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

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

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

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

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

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

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

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

[GriV]

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

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

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

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

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

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

[GriV]

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

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

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

[Advertiser]

[Ronin]

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

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

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

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

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

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

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

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

[dwt]

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

[GriV]

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

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

[GriV]

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

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

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

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

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

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

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

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