FUZIX для Ориона (ПРО)

[b2m]

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

И вот что получилось:


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

Загрузочный диск тут, формат диска 720Кб, т.е. 80x2x9x512, выкладываю в надежде, что кто-то заморочится попробовать это на реале. Вряд-ли заработает, но чем чёрт не шутит...

[Advertiser]

[Дмитрий2012]

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

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

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

[b2m]

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

[Error404]

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

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

[b2m]

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

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

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

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

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

[Error404]

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

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

[b2m]

диспетчер целых страниц по 64к (порт F9), в одной странице ядро, в остальных - процессы (по странице на процесс).

Тогда даже на Орионе-Про - максимум 7 процессов (и то, если совместить экран и пространство ядра, опять максимум 48Кб).

UDATA+стек (всего полторы сотни байт) копируется в пространство процесса ниже F000 при каждом переключении контекста.

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

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

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

Я уже думал про разделяемые библиотеки (типа как .so в линуксе). Вот только вся libc (syslib.lib) даже в 64Кб не полезет.


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

[Error404]

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

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

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

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

[b2m]

доступ к UDATA процесса должен быть и из процесса и из ядра

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

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

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

А вообще мне FUZIX не нравится.

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

Да еще этот SDCC

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

Я думаю, всё будет, если проект не заглохнет.

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

Ну констант и в UZIX хватает. Просто с ними ты уже разобрался. А я, например, нет.

[Error404]

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