Эволюция ZX в XXI веке

[psb]

несомненно, если подходить к вопросу по дилетантски

а я че? я всего лишь выразил свою точку зрения, она не обязана быть истиной в посл. инстанции.

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

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

psb, ты подходишь к вопросу с конца, пытаясь рассуждать о каких-то сетевых решениях, игнорируя то, что это надстройка над ОС.

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

[Black_Cat]

а я че? я всего лишь выразил свою точку зрения, она не обязана быть истиной в посл. инстанции.

я не наезжаю, я констатирую факт

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

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

какая надстройка? о чем речь?

psb, не тупи. Я говорил, что нечего вообще заикаться о сети вне привязки к ОС, надстройкой над которой она является.

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

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

[psb]

практически весь существующий спековский софт может работать под управлением ОС.

только на спеке-переростке. это уже не "мой" спек. поэтому я такой вариант не рассматриваю.

Я говорил, что нечего вообще заикаться о сети вне привязки к ОС, надстройкой над которой она является.

и это я-то не тупи?)))) сеть - надстройка ос?)))) прикольно

Где сетевые приложения? Нет и быть не может!

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

Встраивать функции ОС в каждое сетевое приложение - это бред и онанизм!

во-первых, я тебе все-таки предлагаю отделить сеть от ос. ос может быть и без сети, и сеть может быть без ос. они не связаны!
во-вторых, 27 лет люди на спеке только и занимаются "бредом и онанизмом". у нас так принято, понимаешь ли. любой софт несет с собой все, что ему нужно. одинаковые загрузчики, одинаковые плееры, одинаковые упаковщики, работа с винтами и т.п... почти ни где не юзается ос, но все как-то работает и всех устраивает. и сеть может так же. а "правильную" систему надо было начинать строить в 1990-1992 годах, когда клоны тока начали появляться и была просто куча народу.

[Black_Cat]

только на спеке-переростке. это уже не "мой" спек

почти все современные клоны - переростки, и никого это не смущает.

сеть - надстройка ос?)))) прикольно

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

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

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

и никакие концепции этого не изменят

Почему же? Как раз концепция предполагающая использование нормальной ОС всё решает

во-вторых, 27 лет люди на спеке только и занимаются "бредом и онанизмом". у нас так принято

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

[AlexeyAS]

Похоже пропустил сообщение Ваше.

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

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

Поэтому искать в рубрике "Оси", "Программирование" или "Железо" адекватные задаче решения - бесполезно, их там нет.

Часть просмотрел, но тяжело это, мысль сосредотачивается как правило в первых постах, а дальше вылавливать осколки не просто.

ZX-Reverse - довольно громоздкий и страшноватый проект, со многими некорректными решениями.

Вы бы не могли назвать наиболее некорректные и то как бы Вы видели эти решения.

Особой заинтересованности автора в разборе и обсуждении проекта не замечено.

Т.е. автор и сам не рад что начал? Работает команда? Или опять в одиночку?

Есть разные идеологии развития, но только одна направлена на введение Спектрума в каком-либо виде в повседневный бытовой оборот. Все остальные идеологии куцы и однобоки и поэтому глобально не интересны.

Но как точки зрения имеют право существовать, нравится человеку экстремально кодировать - "нихай" кодирует.

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

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

..кстати речь идёт об аппаратных ресурсах, а не об ОС

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

---------- Post added at 12:52 ---------- Previous post was at 12:35 ----------

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

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

"таймер" - это громко сказано , есть кадровое прерывание (т.е. ~20mS), но оно жёсткое и не меняется, а Zet9 говорил об программируемом интервальном таймере.

Ага я вспомнил. Честно говоря видел очень мало шедуллеров использующих переменный квант времени задачи, помоему это было реализовано в BeOS со старым ядром, но как выяснилось в новом ядре для Haiku (core NewOS) от этого отказались. Или квант слишком велик, Вы считаете?

---------- Post added at 13:23 ---------- Previous post was at 12:52 ----------

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

Продемонстрируете на примере обсуждаемой темы? Это было бы интересно.

---------- Post added at 13:40 ---------- Previous post was at 13:23 ----------

а я че? я всего лишь выразил свою точку зрения, она не обязана быть истиной в посл. инстанции.

Замечательно что она есть. Но согласитесь если остается базовый функционал 48К можно сколько угодно экстремально кодировать не обращая внимание на расширение?

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

По моему тут все отвергли идею замены PC и тем более современного компьютера. Да и по слову современный прокатились не по разу, БК-0010 конечно ввел меня в небольшую прострацию своим видением интеграции ZX в современную информационную среду, но под этим он совершенно точно не имел ввиду современный компьютер. Конечно софт написанный под расширения платформы может стать частично несовместимым с 48К, но как я понял из обсуждения очень многое написанное для Пентагона например, на 48К работать не будет, или для того же ZX-Reverse. Хорошо то что код ОС будет по возможности абстрактным и кроссплатформенным, если он будет написан на ЯВУ. Это даст возможность повторного применения модулей и в целях экстремала на 48К. Согласны? Это могут быть и библиотеки и драйвера устройств, исходники есть исходники чем ближе они к ЯВУ тем менее зависимы от изменений даже в вычислительном ядре.

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

Тут я думаю БК-0010 не доразвил свою мысль. Я думаю что он имел ввиду следующее:

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

[psb]

почти все современные клоны - переростки, и никого это не смущает.

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

правильней было бы сказать что сеть является подсистемой ядра ОС.

может и подсистемой, но не ядра. сеть - это самостоятельный модуль в ос, он может быть, а может не быть. а может быть и БЕЗ ос.

ага, которые способны создавать приложения, каждое из которых по уровню сложности и функционалу заложенному в него сопоставимо с ядром ОС . На Спектруме прям куда не плюнь - всюду Торвальдсы..

ты правда не улавливаешь? давай еще раз. вот есть плееры музыки, в каждой деме, например. этот плеер для каждой демы пишут каждый раз с нуля??? нет? а зачем ядро каждый раз писать с нуля??? зачем сеть каждый раз писать с нуля? зачем драйвер винта каждый раз писать с нуля? да никто так не делает!
вон есть для МК ядра ос. берешь это ядро и на основе него пишешь свой софт. хочешь - добавляй сбоку сеть.

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

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

Или квант слишком велик, Вы считаете?

и квант велик, и еще есть одна "проблемка". взять 2 задачи, например, которые занимают 90% кванта. естественно, что ядро не в состоянии узнать, сколько % они занимают. поэтому получится, что 1я задача будет занимать 90% каждого кванта, а 2я - 10% каждого. не красиво. я делал "изврат" по определению того, как задача прервалась. т.е. если она успела сама отдать управление системе, то все ок, следующей задаче дается лишний квант (если она прервется, то ее запустят еще раз). а если задачу прервала ос, то, соотв-но, если ей не было выделено лишнего кванта (или он кончился уже), т.е. она явно превысила свой порог в 1 квант, тогда пропустить её запуск на след. цикле. так времени достанется всем.

Но согласитесь если остается базовый функционал 48К можно сколько угодно экстремально кодировать не обращая внимание на расширение?

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

интеграции ZX в современную информационную среду

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

Это даст возможность повторного применения модулей

ну, вообще-то так и делают нормальные люди

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

то, что один и тот же драйвер/плеер/... находится физически в каждой программе, а не в длл, это не большая проблема. нехватки дискет нет, а в памяти один фиг одно и то же в обоих вариантах никто без необходимости не пишет то же самое по 100 раз.

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

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

3. Разделение системного и прикладного уровня.

да в любой нормально структурированной программе и так есть это разделение.

[Advertiser]

[sergey2b]

Синклер не может конкурироват с PC и игровыми приставками и не сможет так как если его довести до их уровня от Спектрума не чего не останеться.

Возможно стоит орентироваться на радиолюбителей:
не очень жалко сжечь если стоимоть меньше 100$
простота программирования напрямую железа (хотя под MS DOS не сложней)
возможность модификации (открытая шина и вместе с платой продавать слепыши которые можно использовать с этой шиной) и компактность по сравнению с стандарной PC

[Black_Cat]

Мне кажется что дело в том что обсуждение начинается или сваливается в специфичные детали связанные с кодированием. Все равно что лошади шоры на глаза надеть.

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

Вы бы не могли назвать наиболее некорректные и то как бы Вы видели эти решения.

Проекту более 10 лет, т.е. он начинался ещё в доинформационную эру, когда каждый ваял в изоляции, не ведая что делают другие. Именно так в тёмные, доисторические времена множились несметные вариации клонов. Т.е. разнообразие клонов у нас, это не от большого ума, а скорее наоборот. Но если в доинтернетовские времена это можно было списать на слабость коммуникаций, то сейчас вести разработку с таким подходом уже не хорошо. Проект делается исходя из представлений 20летней давности, давно уже не актуальных. И половины из того что есть в этом проекте, сейчас уже не нужно, а то что остаётся следует сделать по другому, в соответствии с современными представлениями. Я не хочу опускаться в разборе до уровня аппаратных решений, таких как например выбор портов и т.д., т.к. косметическими изменениями тут всёравно ничего не решить - проект требует переделок сопоставимых с разработкой с нуля.

Т.е. автор и сам не рад что начал? Работает команда? Или опять в одиночку?

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

Не совсем понял, не могли бы Вы раскрыть мысль.

подразумевалось создание необходимых аппаратных инструментов, необходимых для выполнения ОС возложенных на неё задач.

Раскройте тему, так как видите ее Вы?

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

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

ну это очень просто разрешить, если представить такой переменный супер квант в качестве суммы N элементарных квантов, являющихся собсно истинными квантами

берешь это ядро и на основе него пишешь свой софт.

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

[AlexeyAS]

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

Собственно БК-0010 пока еще ничего не предложил конкретного. Скажите а вот прозвучавшие тут "современные" архитектуры такие как ZXpoly, Pentagon 2.666LE, AEON - это все переростки и Вы конкретно у себя на столе их не видите?

может и подсистемой, но не ядра. сеть - это самостоятельный модуль в ос, он может быть, а может не быть. а может быть и БЕЗ ос.

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

а зачем ядро каждый раз писать с нуля??? зачем сеть каждый раз писать с нуля? зачем драйвер винта каждый раз писать с нуля? да никто так не делает!

Да ответ то прост как дверная ручка прикладная задача и системная совершенно разные вещи. Прикладнику интересней сосредоточится на алгоритмическом решении и видел он где подальше спецификации на железки. А особенно если этих железок пруд пруди. Тот же майл-клиент, нужно сосредоточиться на решение вопросов редактирования, хранения, сортировки, но ему (прикладнику) придется еще реализовывать POP3, SMTP, IMAP. Ну и до кучи придется изучить очередной врапер COM-ETH который в настоящее время в фаворе у большинства пользователей платформы.
Ну а по поводу что мол есть библиотеки и пожалуйста используй их, а так ли хорошо на спектруме с библиотеками? Они динамические? Они храняться в исходниках? А не запутается обычный пользователь захотевший по программировать ведь репозитария как в Linux откуда быстренько можно черпануть измененный *.so нет. А интерфейсы модулей? На чем написано большинство программ под ZX? А вопросы распространения новых библиотек под новое железо? Документирование?

вон есть для МК ядра ос. берешь это ядро и на основе него пишешь свой софт. хочешь - добавляй сбоку сеть.

О каких ядрах идет речь, об AVR которые редко дотягивают до совокупных объемов памяти ZX? Большинство из так называемых для них ОС жуткое зрелище, ИМХО. А для ядер посерьезней ucLinux - там уже по взрослому. И потом часть ОС для МК это RTOS для встраиваемого применения там не позабавишься особо, поэтому никто и не заморачивается интерфейсами и ядрами.

и квант велик, и еще есть одна "проблемка". взять 2 задачи, например, которые занимают 90% кванта. естественно, что ядро не в состоянии узнать, сколько % они занимают. поэтому получится, что 1я задача будет занимать 90% каждого кванта, а 2я - 10% каждого. не красиво.

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

а если задачу прервала ос, то, соотв-но, если ей не было выделено лишнего кванта (или он кончился уже)

А назовите случаи когда задачу прерывает шедуллер? Как правило это либо смена приоритета, либо разновидность детача. На каких основаниях шедуллер должен прерывать задачу досрочно? Пользователь не почувствует +/- 20ms, которые у него отберут потому что он схватился за мышь. Или Вы рассматриваете случаи когда управления перехватывает ядро уходя в прерывание? Тут уж стоит рассуждать так что ядру видней - отобрала так отобрала, время ядра включено в время задачи.

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

Вдруг Вам концепция придется по вкусу? Ну никто ж насильно не заставляет. Вы думаете если БК-0010 перестанет задумываться над концепциями то обязательно его энергия пойдет в русло экстремального кодирования?

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

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

то, что один и тот же драйвер/плеер/... находится физически в каждой программе, а не в длл, это не большая проблема. нехватки дискет нет, а в памяти один фиг одно и то же в обоих вариантах никто без необходимости не пишет то же самое по 100 раз.

Проблема в отсутствии стандартов на интерфейсы, пришел человек со стороны - Вы предлагаете изучить ему все то богатство кода которое накоплено предыдущим поколением? Выбрать понравившиеся куски кода и попытаться воткнуть их в свое видение программы? А где тогда совершенствование кода? В настоящий момент существуют библиотеки под ZX с полным описанием интерфейса к ним - соглашение о вызовах? Контроль версий?

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

И много на форуме программистов которые могут дописать драйвер написанный другим человеком, без помощи этого человека? Наверное просто пишут заново? И что программа повиснет на полинге ETH? А если захотеть поработать с N разных задач одновременно и у каждой свой врапер?

да в любой нормально структурированной программе и так есть это разделение.

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

---------- Post added at 00:42 ---------- Previous post was at 00:15 ----------

Возможно стоит орентироваться на радиолюбителей:
не очень жалко сжечь если стоимоть меньше 100$

А много сейчас радиолюбителей? На них ориентироваться стоит всегда, они... то есть мы всегда были открыты для любых идей в мире радио.

простота программирования напрямую железа (хотя под MS DOS не сложней) возможность модификации (открытая шина и вместе с платой продавать слепыши которые можно использовать с этой шиной) и компактность по сравнению с стандарной PC

Время старта. А что за "слепыши" Вы имеете в виду?

---------- Post added at 00:55 ---------- Previous post was at 00:42 ----------

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

Несколькими постами раньше я спрашивал Вас о том видете ли Вы вирутализацию ресурсов будущей платформы. Тогда Вы как то не очень нажимали на это, видимо мы не поняли друг друга? Т.е. фактически как я понимаю из вышесказанного поточной многозадачности не будет, будет понятие изолированного процесса в некотором смысле многопользовательская система? Если ВМ = обычный ZX 48K то какое кол-во одновременно работающих задач Вас бы устроило? Или будет виртуализироваться в том числе и память? Супервизор в этом случае ответственен за между ВМ-ные коммуникации? Переброска данных я полагаю будет в этом случае эффективна только если у памяти страничная организация, дабы обойтись без "тупого" копирования, нет?

ну это очень просто разрешить, если представить такой переменный супер квант в качестве суммы N элементарных квантов, являющихся собсно истинными квантами

Для этого интервальный таймер разве нужен?

[sergey2b]

Время старта. А что за "слепыши" Вы имеете в виду?

макетная плата