MATRIX

[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 программы)