MATRIX

[psb]

речь идёт не про ось. а всего лиш про среду разработки.

лол это ты мне говоришь? это я тебе уже несколько постов об этом твержу

и в итоге что? в системе ничего толкового нельзхя написать.

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

сетевого интерфейса на данный момент у спека нет (есть но не в россии). диалапом сам пользуйся!

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

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

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

а я тебе по опыту эксплуатации говорю - ацтой!

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

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

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

пример реализации в студию! иначе это всё трёп.

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

[Zet9]

Можно посторонний взгляд?

Канэшна!

. По-моему, вы делаете Uzix, только хуже (к вопросу об очередях, планировщике задач и т.п.).

Не угадали, больше ориентируюсь на книжки Э.Таненбаума и М.Баха, хотя UZIX и его предшественника UZI изучал маленько 2-3 года назад, а про то, что хуже - могу предложить создать отдельную тему с названием типа "Использование UZIX/UZI на Спектруме" и там обсудим (и про ограничение разделов в 32 Мегабайта со своей файловой системой ufs при том что вот у спектрумистов винты на 40/80/160 Гб c FAT32 подключены и про не "реактивную" скорость работы UZI(X)- так как на Си они написаны и т.д.)

2. На имеющихся железках (ZX128 с одним окном диспетчера в 16к) можно сделать приемлимую по скорости многозадачность (не более сотни-двух сотен тактов на переключение контекста) только для прог размером не более 16к (а с учетом того что проге нужно еще и "кучу" для переменных - то и менее 16к).

Ну почему же, вот можно например для Спектрум-128 иметь две полноценных программы по 40 Кб каждая (при это одна прога занимает 8Кб в нижней памяти и две страницы по 16 Кб), Полноценные я имею ввиду в том смысле, что вот игрушки под Спектрум-48 занимали столько же (ну максимум 41.25 Кб, если не использовали сисперем бэйсика), и при переключении LDIR'ами ничего не переноситься - только страницы переключаються,
или например 2 программы по 26 Кб и одну 42 Кб(опять для Спектрум-128) - каждая будет занимать по 10 Кб в нижней памяти и по одной странице 16 Кб, а третья из них две страницы по 16 Кб, ну а на 256,512,1024 можно больше таких штук запускать (так как у них есть возможность подключения страницы0 в адрес 0, а у других кэш на 32 Кб)

---------- Post added at 17:41 ---------- Previous post was at 17:11 ----------

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

Ну именно так, вот в примере вышеупомянутых прог кусок в нижней памяти в 8-10Кб - это основной код и в нём располагается стэк

да простит меня автор темы - но ИМХО - система баян

На первый раз прощаю(ща истчо вникну,что Вы там дальше наговорили), а то что Вы не будете делать проги для этой системы, это и так понятно, так как каждый разработчик считает свою систему лучшей, и поскольку Вы разрабатываете собственный клон CP/M (на базе Q-DOS/Профи-Дос) - то и проги будете делать только для неё

---------- Post added at 17:57 ---------- Previous post was at 17:41 ----------

Но тогда только ассемблер. Либо делать собственный компилятор с поддержкой железа и непростой модели памяти приложений, что осилить еще сложнее, чем систему. А стек - да, в нижней памяти для обоих вариантов.
В варианте когда "только ассемблер" - это под систему будет рождено три с половиной программы, как к примеру в SymbOS (построенной фактически по этому же ТЗ):

Теперь сравниваете MATRIX с SymbOS, а вначале сравнивали с UZIX - Вы уж определитесь, что такое MATRIX

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

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

---------- Post added at 18:13 ---------- Previous post was at 17:57 ----------

Зачем так сложно? для генерации полноценного интерфейса надо загнать кучу вызовов для заголовка, текста, спрайтов, стандартных элементов управления, а потом каким-то образом еще обрабатывать данные манипулятора? Имхо, это не оптимально. Может упростить? Организовать вектор-описатель окна, где будут присутствовать объекты текста, графики и стандартные элементы управления с точками вызова определенных процедур, типа onrightclick/onleftclick/ondblclick.

Так как Вы предлагаете, уже было (например, в минивиндовс98 из Черной Вороны 2, в ChaOS), как раз наоборот , упрощаем систему,чтобы шустрее работала
А печать заголовка нужна , чтобы можно было обновлять заголовок, например показывать там сколько процентов выполнено (при какой-либо операции), а вариант с описателем не позволяет динамически изменять заголовок

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

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

[Error404]

Канэшна!

Не угадали, больше ориентируюсь на книжки Э.Таненбаума и М.Баха, хотя UZIX и его предшественника UZI изучал маленько 2-3 года назад,

Теперь сравниваете MATRIX с SymbOS, а вначале сравнивали с UZIX - Вы уж определитесь, что такое MATRIX

Нет, уж это Вы определяйтесь, коллега, что такое Матрикс. Пока что видно только нечто размытое, конкретизированное только в части интерфейса с прикладняком (и написанное с позиции прикладного программиста). Какие там функции будут в Матриксе для графики или файловой системы - дело десятое, тем более похоже совместимостью по вызовам с *nix-ами, CPM или VNC тут и не пахнет.
Главное, совершенно не понятно - "за чей счет банкет", т.е. за счет чего вообще что-то будет работать (как будет работать ядро), как все будет увязано в общую систему, а не набор программ, которые работают как хотят (хотят - пишут/читают в/из "ящик", хотят - нет, хотят - сами инициируют переключение диспетчера для работы с другими страницами памяти)

а про то, что хуже - могу предложить создать отдельную тему с названием типа "Использование UZIX/UZI на Спектруме" и там обсудим (и про ограничение разделов в 32 Мегабайта со своей файловой системой ufs при том что вот у спектрумистов винты на 40/80/160 Гб c FAT32 подключены и про не "реактивную" скорость работы UZI(X)- так как на Си они написаны и т.д.)

Да было уже. Года три наза в этом же разделе перетирали, и в теме про SymbOS тоже. И опять повторение распространенной ошибки (я бы даже сказал, ярлыка) - "все тормоза из-за C". Ничуть не бывало, 50% разницы - это не разница, не та цена за кросплатформенную совместимость на уровне исходников, чтобы так просто от нее отказаться ради ассемблерной самодеятельности. Все тормоза из-за больших накладных расходов, алгоритмических, которые как раз в ядре. Я и SymbOS привел в пример исключительно как образец колоссального квалифицированного труда автора, и в целом симпатичную систему, но программ в которой будет ровно столько, сколько успеет написать сам автор. Т.е. катастрофически мало, "поставил-посмотрел-снёс".

32М ограничение на размер FS в юзиксе оттого, что это 16-битная FS - у разработчика UZI в мхомпоросших 80-х годах прошлого века компилятор не умел 32 бит int, а при переводе на Hitech C (т.е. в UZIX) ничего кардинально не переписывалось. Но можно монтировать несколько FS, а еще лучше - переписать в 32 бита. Зато это СИСТЕМА. Мне вот не нужена еще одна прога-запускалка игр, таких уже имеется в наличии - запускают и с винта в сотню гигов (насчет 160 - этого конечно нет, а у вас что, и LBA48 в планах?), и с CD-привода.

[Zet9]

Нет, уж это Вы определяйтесь, коллега, что такое Матрикс.

Это шутка, я ж там смайлик поставил

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

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

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

Ну что тут не понятного -ладно, нарушаю правило не рассказывать про внутреннюю "кухню":
только Вы никому не рассказывайте
правит балом один из процессов, запускаемый самым первым, типа, процесс INIT , вот он и является ядром системы,он организовывает таблицу процессов, в нём переключалка и планировщик процессов,
он загружает процесс с названием ... нет не LOGIN, а с названием XWIND - это типа графическая подсистема (со встроенным драйвером мыши,джойстика и клавиатуры), а потом уже он загружает ... опять не LOGIN, а сразу процесс DESKTOP и регистрирует его в граф.систему(с помощью сообщения в своем почтовом ящике,которое берет XWIND),а DESKTOP кладет в свои почтовые ящики сообщения для граф.системы - создать, показать окна и для ядра системы - загрузить там- чё-нить, типа следующий процесс, который уже является программой пользователя, и а дальше весь свистопляс...
а про страницы памяти, вообще-то официальный способ, положить номер страницы в ячейку, и потом ядро включит это страницу, а насчёт самостоятельного (для скорости) прямого переключения страниц - пока ещё не определено, будет/нужно ли.
ну вот так ,типа того, но как-то невнятно получилось рассказать,
токмо смотрите - никому......

Но можно монтировать несколько FS, а еще лучше - переписать в 32 бита. Зато это СИСТЕМА. Мне вот не нужена еще одна прога-запускалка игр, таких уже имеется в наличии - запускают и с винта в сотню гигов (насчет 160 - этого конечно нет, а у вас что, и LBA48 в планах?), и с CD-привода.

Ну монтировать несколько разных файловых систем не только UZIX умеет
P.S.Винты у меня на 40Гб и на 160 Гб, но конечно же используется LBA28 - только первые 128 Гб,а LBA48 -пока не планируется

[Дмитрий]

Так как Вы предлагаете, уже было (например, в минивиндовс98 из Черной Вороны 2, в ChaOS)

возможно и было. это удобно, поэтому не мудрено, что было. Да, такой подход не позволяет в онлайн выводить инфу в окно, но кто мешает объявить процедуры прорисовки в системных вызовах? если тебе удобно рисовать окно и содержимое динамически посредством API - рисуй, мне больше нравится статический вывод, если что-то надо будет - обращусь по API и поменяю заголовок. Просто статический описатель окна будет компактнее, чем код, вызывающий те же апи-функции для генерации аналогичного окна. А с учетом малого количества непрерывной памяти расточительно ее использовать не хорошо. Кстати идея - принять манеру pc-шных моделей с сегментами кода и данных и размещать код программы в непрерывной памяти, а тексты, графику и прочее - в страницы

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

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

---------- Post added at 20:51 ---------- Previous post was at 20:35 ----------

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

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

[Error404]

Это шутка, я ж там смайлик поставил

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

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

Ну что тут не понятного -ладно, нарушаю правило не рассказывать про внутреннюю "кухню":
только Вы никому не рассказывайте
правит балом один из процессов, запускаемый самым первым, типа, процесс INIT , вот он и является ядром системы,он организовывает таблицу процессов, в нём переключалка и планировщик процессов,
он загружает процесс с названием ... нет не LOGIN, а с названием XWIND - это типа графическая подсистема (со встроенным драйвером мыши,джойстика и клавиатуры), а потом уже он загружает ... опять не LOGIN, а сразу процесс DESKTOP и регистрирует его в граф.систему(с помощью сообщения в своем почтовом ящике,которое берет XWIND),а DESKTOP кладет в свои почтовые ящики сообщения для граф.системы - создать, показать окна и для ядра системы - загрузить там- чё-нить, типа следующий процесс, который уже является программой пользователя, и а дальше весь свистопляс...
а про страницы памяти, вообще-то официальный способ, положить номер страницы в ячейку, и потом ядро включит это страницу, а насчёт самостоятельного (для скорости) прямого переключения страниц - пока ещё не определено, будет/нужно ли.
ну вот так ,типа того, но как-то невнятно получилось рассказать,
токмо смотрите - никому......

Не, ну это понятно. Просто дьявол в деталях. Вот, к примеру, в заглавном посте упоминался FORK (т.е. в понятиях UNIX - дублирование процесса со всем окружением и переменными - как системными, так и стеком и "кучей" процесса и продолжение выполнения с точки fork), а здесь судя по логике, уже EXEC, а не fork. Кстати, как будет с окружением процессов (системными переменным), что наследуется, а что нет, где хранится, как передается.

В-общем, проработка деталей займет много времени.

Ну монтировать несколько разных файловых систем не только UZIX умеет
P.S.Винты у меня на 40Гб и на 160 Гб, но конечно же используется LBA28 - только первые 128 Гб,а LBA48 -пока не планируется

Думаю, нужно как-то заложить (на уровне условной компиляции или еще как) генерацию системы в две версии - одну из них под продвинутое железо. Т.к. никуда не деться - нужно будет работать с диспетчером окном большего размера, только тогда получится достаточное быстродействие при "приемлимо большой" сплошной памяти процесса. Ну и\или закладываться на существующие дополнительные фичи управления памятью какого-то из клонов, например ATM или еще чего из продвинутых. В конце концов даже на стандартный ZX припаять бутербродом две микрухи и кинуть пяток проводов МГТФ эту куда как более реально и доступно в современных реалиях, чем написать систему, пытаясь впихнуть ее в невпихуемое.

Также независимо от того что получится за система, желательно оставить возможность выполняться пользовательскому коду с адреса 0 и выше - это в перспективе даст возможность запускать без переделки как бинарники CPM, так и UZIX. Все же таких системных программ, какие есть в CPM, на 8-битной платформе уже не будет никогда.

[James DiGreze]

Зря вы сразу на окна накинулись. Ни к чему это. По крайней мере пока. Делайте так, чтобы окно программы(не процесса) всегда было на весь экран, если конечно программе требуется отрисовка диалога, в противном случае stdin/stdout.
Такой подход более прагматичен т.к. у нас не 1600х900, а всего лишь 256х192. И заметьте, в большинстве случаев программы на ПЦ под "окошки" всегда раскрыты на полный экран. Я считаю что полноценными окнами можно пренебречь.

[Sayman]

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

[Дмитрий]

Делайте так, чтобы окно программы(не процесса) всегда было на весь экран, если конечно программе требуется отрисовка диалога, в противном случае stdin/stdout.

как вариант экономии памяти и процессорного времени - да, согласен.

[Zet9]

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

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

Там же сказано - ВЫПОЛНЕНИЕ программ в многозадачной системе, а Вы говорите про возможность ЗАПУСКА таких программ
Запускать конечно же можно

загрузчик переделать и хватит. на то это и автономное приложение. выход в ос - через ресет (а дальше зависит от ос, может она до этого сделала hibernate).

Ну да, система уходит в киберночь и оставляет в памяти маленькую программку-запускалку,которая уже и запускает такое автономное приложение
А вот что имелось ввиду про ВЫПОЛНЕНИЕ таких ресурсоемких программ:
вот предположим у нас минимальная конфигурация Спектрум -128 , а такай программа хочет использовать ВСЕ ресурсы компьютера, ну и как, спрашивается система сможет ресурсы программе предоставить? Что касается процессорного времени, тут всё проще, система усыпляет все уже запущенные процессы и сохраняет их во внешней памяти,программа сама будет выводить на экран - она вызывает функцию getscr1,2 и в результате графическая подсистема не нужна, она туже усыпляется и убирается из памяти,итого работают только два процесса - т.е. эта программа и ядро системы,теперь программа допустим вызывает функцию getcpu и система отключает переключение процессов по приходу прерывания и программа сама рулит, и её ничто не прерывает и так до момента пока программе понадобиться выполнить операции с файлами, тогда она вызывает ядро, оно выполняет дисковую операцию и возвращает управление программе.
Всё бы хорошо, но вот программе надо использовать все 128 Кб памяти, а часть памяти (ну как минимум 16 Кб) занимает ядро системы, вот и получается, что не может система обеспечить ВЫПОЛНЕНИЕ таких программ.
P.S. конечно эта задача легко решается при наличии бОльшего количества памяти, чем 128 Кб.
Ну могу изменить эту фразу, добавить там слова "В минимальной конфигурации (Спектрум-128) система не позволяет выполнение программ,которым единолично требуются все ресурсы компьютера"

---------- Post added at 10:18 ---------- Previous post was at 10:02 ----------

да, но в замен система ровно ничего не предоставляет. потому , что все функции по сути возоагаются на разраба

Ну как же ничего не предоставляет, вон в первом посте указаны три десятка функций - берите, пользуйтесь на здоровье

так извините, если система запрещает использование полных ресурсов для одной только задачи (как уже писал Дмитрий напримере игр)

Про это рассказал подробно

лучше всю жизнь в трдосе сидеть)))

Ну,у нас свободная страна, Конституция гарантирует всем гражданам свободу выбора - так что решать Вам

Примеров программ с приоритетным использованием рессурсов компа масса и необходимо учитывать это при создании ОС.

Ну вот же мы их и учитываем, и функции заготавливаем типа getscr и подобные

че вы прицепились к тр-дос? это, я думаю, одна из функций.

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

мы к нему не цеплялись - это афтор, а позднее ты заострил внимание на вытеснении ТР-ДОС.

Ну не надо придумывать - никто и не говорит о вытеснении.
Предлагается "отвязаться" от дискет ТР-ДОС, чтобы они перестали быть единственными носителями информации, а стали просто одними из многих (fdd,hdd,cd,dvd,SD,CF IDE), причем на равных правах - т.е. чтобы вновь разрабатываемые программы могли использовать их все одновременно или в любых сочетаниях и запускаться с них, с любых носителей (а не так, что принес новую прогу на cd-rom-диске,а запустить её не можешь - так как сначала надо прогу скопировать на дискету)

---------- Post added at 10:33 ---------- Previous post was at 10:18 ----------

не надо делать упор на создание многозадачной системы

Ну я уже сказал, у нас свободная страна: каждый делает, что хочет

спектруму не подсилу такое при текущем развитие железа!

Ага, щас - вот помню в 2000-году купил винт на 210 Мб и собрался подключать к Спеку, - рассказал знакомому писишнику (в принципе,не надо было этого делать) - он сделал умное лицо и начал "обьяснять", что Спектрум не потянет и т.д. А позже предлагал подешевке свой винт на 540 метров (я не взял) - и что мы в результате имеем? Спокойно юзаем на Спеке винты на 40, 80 и 160 Гб и радуемся (и не вспоминаем, что кто-то говорил, что Спек "не потянет")