PDA

Просмотр полной версии : FUZIX для Ориона (ПРО)



b2m
02.01.2016, 17:26
Помнится, мы тут пытались портировать FUZIX на ZX, но потом тема заглохла. Да и работало это всё как-то нестабильно. Мне показалось интересным портировать это ещё и на Орион-Про, тем более что раскладка памяти практически идеально подходит под версию для 16Кб диспетчера. Жаль только, что в последнее окно (а оно самое важное), можно мапить только одну четвёртую всей памяти (хотя, при желании можно допилить схему, чтобы использовать, например, старшие 2 бита порта 08 в качестве адресов A14,A15 ОЗУ).

И вот что получилось:
http://bashkiria-2m.narod.ru/files/orion/fuzix1.png

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

Загрузочный диск тут (http://bashkiria-2m.narod.ru/files/orion/fuzix.rar), формат диска 720Кб, т.е. 80x2x9x512, выкладываю в надежде, что кто-то заморочится попробовать это на реале. Вряд-ли заработает, но чем чёрт не шутит...

Дмитрий2012
02.01.2016, 18:30
выкладываю в надежде, что кто-то заморочится попробовать это на реале. Вряд-ли заработает, но чем чёрт не шутит...
Попробовал запустить на реале, вроде грузится, но после подачи любой команды комп зависает, и через некоторое время сбрасывается.

Дополнение 13.03.2016
После исправления найденных ошибок на новодельной печатной плате Орион-Про, FUZIX теперь грузится и не зависает.

b2m
02.01.2016, 20:30
Я кое-что поправил, теперь вроде постабильнее.

Error404
02.01.2016, 23:28
Я кое-что поправил, теперь вроде постабильнее.

Так какая используется модель памяти?
Я не понял что там с 16-к диспетчером.

b2m
03.01.2016, 00:20
Так какая используется модель памяти?
Я не понял что там с 16-к диспетчером.
На данный момент используются первые три окна по 16Кб, последнее фиксировано (не считая, что через него производится доступ к экрану). К сожалению, общую область F000-F2FF, которая теоретически тоже должна переключаться, приходится постоянно (вместе со стеком в адресах EB00-EFFF) перекидывать в область задачи B800-BFFF и обратно. Аналогично мы делали и для ZX.

Основные проблемы:
- в окно C000-FFFF нельзя включить произвольную 16Кб страницу
- ядро вместе с данными примерно 44Кб (плюс 2Кб общая область), пока помещается в три страницы, но на область кучи остаётся очень мало места (хотя я не знаю, используется ли она сейчас)

Что можно сделать. Можно было бы перенести общую область в первое окно 0000-3FFF, тогда не надо было бы копировать её туда-обратно при переключении процессов, но тогда придётся располагать ядро с адреса 4000, т.е. ему достанется максимум 48Кб. Хватит ли?

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

Error404
03.01.2016, 13:45
Думаю надо делать так, как у Алана было сделано в самой первой реализации, до того как он стал пытаться объять необъятное, и как сделано у меня в UZIX - используется диспетчер целых страниц по 64к (порт F9), в одной странице ядро, в остальных - процессы (по странице на процесс). В общей области (F000 и выше) - только UDATA, межстраничный стек и подпрограммы межстраничного вызова. UDATA+стек (всего полторы сотни байт) копируется в пространство процесса ниже F000 при каждом переключении контекста. Это дает более быстрое переключение, и что самое главное - нормальное количество места под процесс. С меньшим местом нечего и затевать, опять все упрется в то что ничего не влезает, особенно если пользовать SDCC.

Диспетчер 16к тоже можно использовать - например сделать libc c оверлеем в области 0000...4000 для тяжелых приложений.

b2m
03.01.2016, 15:11
диспетчер целых страниц по 64к (порт F9), в одной странице ядро, в остальных - процессы (по странице на процесс).
Тогда даже на Орионе-Про - максимум 7 процессов (и то, если совместить экран и пространство ядра, опять максимум 48Кб).


UDATA+стек (всего полторы сотни байт) копируется в пространство процесса ниже F000 при каждом переключении контекста.
Там вроде не полторы сотни, а все четыре. Хотя, на мой взгляд, можно было бы совместить стек ядра и стек прерываний. Просто, если мы уже в ядре, прерывание не должно переключать стек, а если нет, то использовать стек ядра. Я вот всё думаю, как перенести общую область в начало адресного пространства, чтобы использовать возможность включать любую страницу в эту область. Пока всё упирается в размер самого ядра. Если удастся, то можно сделать так, что процессы до 16Кб используют только 16Кб, а остальные - 64Кб.



С меньшим местом нечего и затевать, опять все упрется в то что ничего не влезает, особенно если пользовать SDCC.

Диспетчер 16к тоже можно использовать - например сделать libc c оверлеем в области 0000...4000 для тяжелых приложений.
Я уже думал про разделяемые библиотеки (типа как .so в линуксе). Вот только вся libc (syslib.lib) даже в 64Кб не полезет.


Кстати, раз уж мы затеяли дискуссию о Fuzix на Орионе, может отделишь начиная с моего сообщения со скриншотом в отдельную тему?

Error404
03.01.2016, 16:39
Да, пожалуй, копируется сотни 3-4 байт. Ну как бы там ни было, это меньше чем если копировать 16к, и делается это не так часто. Просто без этого никак, т.к. доступ к UDATA процесса должен быть и из процесса и из ядра, а значит либо держать UDATA в общей области (самый лучший вариант), либо ядру UDATA процесса подключать диспетчером (что наплодит глюков, т.к. надо развести еще с прерываниями, которые могут возникнуть в любом месте).

А вообще мне FUZIX не нравится. Кокс из простого и понятного кода UZI Брауна выродил нечто нечитаемое со своими дефайнами. Да еще этот SDCC

- - - Добавлено - - -

И что характерно, не сделал ничего принципиально нового.
Где TCPIP? Где модульные ФС? Ничего интересного не добавлено, только констант новых налепили и теперь чтобы бэкпортить что-нибудь из того проекта в UZIX, надо чистить от мусора: разбираться что к чему.

b2m
03.01.2016, 19:46
доступ к UDATA процесса должен быть и из процесса и из ядра
На самом деле доступ к UDATA процессу не нужен, более того, вообще должен быть запрещён, т.к. там хранятся данные ядра, которые относятся к этому процессу. На мой взгляд, сделано это для компактности обращения к этим данным. Ядро обращается к ним как к статическим переменным, а не через указатель на данные текущего процесса. Ну и стек ядра, в принципе тоже относится к самому процессу, но процесс волен размещать его где угодно, а ядру нужно в определённом месте.


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


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


Да еще этот SDCC
:)


И что характерно, не сделал ничего принципиально нового.
Где TCPIP? Где модульные ФС?
Я думаю, всё будет, если проект не заглохнет.


только констант новых налепили и теперь чтобы бэкпортить что-нибудь из того проекта в UZIX, надо чистить от мусора: разбираться что к чему.
Ну констант и в UZIX хватает. Просто с ними ты уже разобрался. А я, например, нет.

Error404
03.01.2016, 21:27
И в UZI и в UZIX аппаратнозависимая часть изолирована. Вынесена в отдельные файлы, собирается с минимумом дефайнов. Причем, UZIX куда ближе к исходному материалу, чем FUZIX. То, что сделано с исходниками UZI, отвратительно: разобраться в той каше может только программист (да и то как видим - не сразу), а в исходниках UZI/UZIX - любой с базовыми познаниями в С. Раз Кокс такой любитель накуевертить на дефайнах, пускай брал бы да делал с нуля. А то неспортивно как то. Браун вот помер, не видит. :)

Error404
11.01.2016, 17:41
А вообще, сегодня слазил в проект, чего-то они там пытаются делать самостоятельно на предмет сети, но пока конечно еще конь не валялся: типа верхнего скелета основных функций. Пару лет еще надо подождать пока будет работоспособный TCP/IP. :) Но лично для меня это будет значить, что уже пора переходить на FUZIX. А с компилятором что-нить придумаем.

Что же касается 64к на процесс, то я думаю последнее за что надо переживать - это за количество памяти для процессов. Даже если не делать свап на энергонезависимый носитель, то любому орионщику судя по форуму - явно за счастье будет новые проводнички припаять и расширить память до, скажем, 2-4 МБ. Тем более это на статике сделать очень легко (добавить 3 мсх по 512кб). Какой восторг от любой ничем неподдержанной железки у наших софорумчан-железячников, мне это даже трудно понять, а тут будет внятная доработка под лучшую ОС Ориона - осилим общими усилиями. :)

ksanf(138)
06.04.2016, 02:26
А мне вот чего то тоже стал интересен сей проект.
Одного не понимаю, зачем эти пересылки при переключении процессов если есть непереключаемая область(0f000h-0ffffh)?
Объясните дебилу, пожалста.
Ещё в бытность пользования Орионом-128 чего то задумывался над многозадачностью...
Виделось так-система вызывает процесс, процесс пошёл, приходит прерывание (1/50-1/100 сек.), возвращается системе, система вызывает следующий..
И так по кругу..
А здесь как (в фузиксе)?
зы: Херня! Мы ещё кеды под фузиксом поднимем! ;)
ззы: А процессы в фузиксе с какого адреса стартуют , ежели для кажного страница , с 0 или 100h ?

Error404
07.04.2016, 17:34
Виделось так-система вызывает процесс, процесс пошёл, приходит прерывание (1/50-1/100 сек.), возвращается системе, система вызывает следующий..
И так по кругу..
А здесь как (в фузиксе)?
зы: Херня! Мы ещё кеды под фузиксом поднимем! ;)
ззы: А процессы в фузиксе с какого адреса стартуют , ежели для кажного страница , с 0 или 100h ?

так же и тут - коммутируемая многозадачность с прерыванием, сохранением/восстановлением и переключением контекста.
Процессы стартуют с 100h для совместимости с CP/M (точнее чтобы ничего критичного не класть в область 0..ff - эта область нужна для "имитатора" среды CP/M) - чтобы можно было бинарники CP/M запускать

b2m
07.04.2016, 20:45
Одного не понимаю, зачем эти пересылки при переключении процессов если есть непереключаемая область(0f000h-0ffffh)?
В идеале нужно:
1. непереключаемая область в самом конце (небольшая область)
2. область, где будут стек и данные задачи, к которым обращается ядро (тоже не много), перед областью из пункта 1.
3. остальное должно быть переключаемым

Например:
F000-FFFF непереключаемая общая область
ED00-EFFF тут область памяти задачи, даже если включено ядро
0000-EСFF тут включается либо ядро, либо одна из задач

В Орионе в верхней области можно включить только одну из 8 страниц, отсюда ограничение, максимум 7 процессов (т.к. экран тоже там).
Страницы по 16Кб, т.е. на ядро максимум 48Кб - маловато.

ksanf(138)
09.04.2016, 12:21
Ну хорошо, я это понимаю. Но в Орионе же есть режим с непереключаемой областью (31 сегмент).То есть этот сегмент отображается только до страницы #7?
Нехорошо то как... В идеале-4 МБ ОЗУ, страница 60К на процесс.. А что 4 Килобайт мало для того чтобы разместить в них общую и область задач?

b2m
09.04.2016, 18:22
А что 4 Килобайт мало для того чтобы разместить в них общую и область задач?
Да нет, вполне достаточно. Только область задачи - это кусок памяти самой задачи. Вот его-то мы и пересылаем туда-сюда.

Sayman
09.04.2016, 18:33
когда-нибудь, когда я разберусь с графикой для спринтера (всякие демки, игрушки и прочее) я мутану юзикса или фузикса туда)) уж с 4мя метрами озу и фаст рамой там эээхъ как можно юзикса мутануть. причём не останавливает тема старта с адреса 100h, т.к. ЦПМа там нет)))) и это будет именно ОС, а не приложение для доса/цпма, как это было ранее для других платформ)) хотя, пожалуй, на МСХ там не приложение для доса, а именно ОС. что-то я подзабыл...

ksanf(138)
10.04.2016, 11:54
Да нет, вполне достаточно. Только область задачи - это кусок памяти самой задачи. Вот его-то мы и пересылаем туда-сюда.

Так в том то и вопрос! Неужели нельзя эту область сделать общей? Пусть и несколько побольше... С 0F000h и вверх?
ps:Стек общий ,или у каждого процесса свой?

Error404
10.04.2016, 12:25
Так в том то и вопрос! Неужели нельзя эту область сделать общей? Пусть и несколько побольше... С 0F000h и вверх?
ps:Стек общий ,или у каждого процесса свой?

Стек у каждого процесса вообщето свой, но он должен быть доступен из ядра чтобы работали трапы ОС (сигналы и т.п.). Т.е. система должна уметь переходить в процесс и возвращаться в ядропо стеку процесса вторым уровнем (т.е. безотносительно первого уровня - прерывания и восстановления контекста с возвращением в контекст). Значит, стек выполняемого процесса в момент выполнения трапов должен быть в непереключаемой области (либо какие-то другие меры более заумные). Если эта область большая (как в Орионе-ПРО - 4 кб), то можно задействовать в ней несколько кусков под процессы и обойтись без копирования, но в ядре тогда нужно все обращения туда делать не по абсолютному адресу, а по индексу процесса, т.е. тоже снижение скорости пускай возможно и не такое большое. Если сохранять совместимость с Орионом(128/256/512), то там в непереключаемой области - максимум 1кб и остается только вариант с копированием. Как по мне, LDIR 800 байт (400 на включение нового контекста и 400 сохранение предыдущего) на каждое переключение контекстов - это не так уж и много, для того и разгоняют процы чтобы покрывать такие накладные расходы.

- - - Добавлено - - -



это будет именно ОС, а не приложение для доса/цпма, как это было ранее для других платформ)) хотя, пожалуй, на МСХ там не приложение для доса, а именно ОС. что-то я подзабыл...

На MSX есть оба варианта (UZIX - работает само, FUZIX стартует из-под DOS). Потому что на самом деле это вопрос не "настоящестости" ОС, а теологии (т.е. веры и предпочтений). Никто не мешает мне например драйвер дисков и экрана затащить в ядро и стартовать ОС без CP/M (от которой я использую только загрузчик этих двух драйверов и сами драйверы). Только нафига? Они на асме (и на порядок более функциональные чем простетские дефолтные для UZIX/FUZIX), а ОС - на С, пишутся и отлаживаются обособленно. Пока отладка самой ОС не завершена, склеивать ужа и ежа, усложняя себе сборку и отладку - преждевременно.

Кстати, такой подход весьма распространен в бытовых и промышленных ОС, где есть первоначальный загрузчик-конфигуратор (по сути: маленькая ОС на отдельном разделе или в ПЗУ - для загрузки большой), после загрузки основной ОС не используемый. На вскидку: винда ранних версий (ранее 95), Open-VMS, AIX (и все ОС на базе Power OpenFirmware), IBM I/OS, да даже Linux OrangePI которым я сейчас играюсь - и тот грузит ядро и конфиги с FAT-раздела, а потом уже работает со вторым, линуксовым разделом где все основное лежит (FAT нужен только для загрузки ОС). Да взять тот же UEFI (т.е. большинство x86 серверов) - это что как не оно? На пару порядков посложнее чем CP/M.