Алан Кокс представил Unix-подобную ОС Fuzix, ядро которой потребляет около 40 Кб ОЗУ

[Error404]

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

Если, конечно, права имеешь)

Не пишите "как хочешь", пишите как принято.
Может это и не очевидно, но написанное "как хочешь" потом все одно придется переделывать, собственно это и зацепило напоспорить. Если хочется графики, можно использовать, например, ncurses для ASCII, VNC для графики, и даже мапить память чтобы туда писать, но не каждым процессом как попало. И то и то уже реализовывалось для Z80, надо только руки приложить и портировать когда движок заработает. Что-то массово и быстро выводить на экран в графике нужно только играм, а там прослойка UZIX вообще ни к чему, лоадеры (буты\трдосы и и т.п.) уже написаны.

---------- Post added at 00:53 ---------- Previous post was at 00:47 ----------

Большую флэш пока не потянет - максимальный объем накопителя = 65536 блоков по 512 байт = 32 мегабайта.

Но ничто не мешает накопители монтировать один к другому.

На "больших" объемах, приближающихся к 32М ядро _очень_ медленно работает, заметно подтормаживают даже РС-версии fsck, mkfs, ucp. Кокс, кстати, писал об этом в блоге. Да и всего "богатства" бинарей в UZIX наработано на 4-5 Mb (а в Fuzix пока хорошо если 10% от этого). Тут надо смотреть на доработку ядра для во-первых модульно подключаемых библиотек сторонних ФС, и во-вторых к первому - имплементировании такого модуля для портированной FatFS. Вот на ней то и хранить любые объемы, работает по скорости приемлимо, проверял. А ФС типа "uzi" оставить только для rootfs.

---------- Post added at 00:58 ---------- Previous post was at 00:53 ----------

Мне в этом свете не понятно зачем в TODO у Алана числится допиливание ФС uzi до 32битных inod-ов, учитывая что обрабатывать long-и ядро будет еще в пару раз медленнее.

[Eltaron]

Ура, смог загрузить init. Ну, не настоящий init, а пример /Applications/ASM/init.s. Но процессы создаются и смена банок ядро<->процесс вроде бы отрабатывает корректно.
Образ дискеты (init + /dev/tty0) в аттаче на всякий случай.

Мне в этом свете не понятно зачем в TODO у Алана числится допиливание ФС uzi до 32битных inod-ов, учитывая что обрабатывать long-и ядро будет еще в пару раз медленнее.

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

[SfS]

Но процессы создаются и смена банок ядро<->процесс вроде бы отрабатывает корректно.
Образ дискеты (init + /dev/tty0) в аттаче на всякий случай.

А какая там файловая система?
Я так понял, что ты вместо ТРД-образа чтото подсунул.

[SfS]

Я подумал - наверное и вправду на первых порах впилю виртуальный диск по RS232.

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

1. Какая ФС используется в FUZIX?
2. Какими утилитами можно создать образ этой ФС и записать на неё файлы?

Я думал, что тот образ, что ты приложил - UZIXовый, но UZIXовые утилиты его не поняли.

[Sergey]

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

Предлагаю образ FUSIX хранить на TRDOS-дискете с 01 дорожки. 0-я дорожка стандартная, и пусть содержит единственный файл "boot" с загрузчиком. Так для эмулей, да и для реала удобней будет.

2. Какими утилитами можно создать образ этой ФС и записать на неё файлы?

Если знать формат, думаю смогу на REXX написать.

Кстати, неплохо было бы ассемблерные файлы просмотреть на предмет оптимизации - можно больше места под процессы выделить

[SfS]

Предлагаю образ FUSIX хранить на TRDOS-дискете с 01 дорожки. 0-я дорожка стандартная, и пусть содержит единственный файл "boot" с загрузчиком. Так для эмулей, да и для реала удобней будет.

Это не проблема.

Если знать формат, думаю смогу на REXX написать.

именно тип ФС я и спрашивал.

ИМХО, Раз Eltaron создал образ - то он знает тип ФС и у него есть утилиты..

Кстати, неплохо было бы ассемблерные файлы просмотреть на предмет оптимизации - можно больше места под процессы выделить

Там под процесс выделяется окно 16К. Оптимизация нужна скорее по скорости.

В принципе, на пентеве можно и 48 К на процесс выделять - три окна по 16К.

теоретически - ОС занимает 48К (три окна). Под процессы остаются 253 окна по 16 К.

То есть - или имеем 253 процеса по 16 К или 84 процесса по 48К.

И то и другое - более чем достаточно для сепктрума.

[Advertiser]

[Eltaron]

А какая там файловая система?
Я так понял, что ты вместо ТРД-образа чтото подсунул.

Да, от TR-DOS там только структура 256x16x80x2.
ФС на неё хорошо ложится, одно надо учесть - в TR-DOS сектора в 256 байт, а в fuzix блок - 512 байт. Поэтому на каждый блок нужно читать два сектора.

Сама ФС fuzix-овая стандартная. Она же UZIX-овая стандартная и (судя по словам Error404) UZI-ховая стандартная.
Тулзы для её создания лежат в /Standalone, собираются под хост.
Создание файловой системы под стандартную TR-DOSную разметку:

./mkfs fuzix.trd 64 1280
./ucp fuzix.trd
  > get init
  > chmod 777 init
  > mknod /dev/tty0 20666 257
  > exit

init.s компиляется zmac. Я там у себя поменял tty1 на tty0 зачем-то, поэтому и создавать пришлось нод /dev/tty0.

[SfS]

Моё видение из разряда пожеланий:

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

2. Реализация драйвера работы с FLESHкой. (тупо флеш делить на N образов по 32Мбайта для начала можно).

3. Реализация драйвера RAM-диска динамического объёма.

Но пока это мечты...

---------- Post added at 16:23 ---------- Previous post was at 16:19 ----------

Сама ФС fuzix-овая стандартная. Она же UZIX-овая стандартная и (судя по словам Error404) UZI-ховая стандартная.
Тулзы для её создания лежат в /Standalone, собираются под хост.

Тогда почему утилиты с сайта UZIX-утилиты http://prdownloads.sourceforge.net/f...ar.gz?download её не понимают?[COLOR="Silver"]

[Eltaron]

Тогда почему утилиты с сайта UZIX-утилиты

Без понятия. Собери свои, они в один make собираются.

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

Это в bank16.c или нет?

Нет, все эти bank*.c - это файлы операционки, их желательно не трогать. Вся работа в platform-*.

Вообще, bank16.c - это для архитектур, у которых 4 банки по 16 килобайт, и в которых любую страницу можно включать в любое окно. Поскольку банкомат именно так и работает, то со временем ты на bank16 код и переделаешь.
Но пока что используется bankfixed.c. Это архитектура, в которой процесс лежит весь полностью в одной банке, но размер самой банки не оговаривается. 16 кб, 60 кб - не важно, главное, что один процесс - одна страница. (Есть одно НО - предполагается, что банка включается с адреса 0. Я поправил для zx128, но Алан этот коммит не взял, т.к. ломает прочие архитектуры. Значит, придется делать свой банкинг в platform-zx128.)

Так вот, тыкаю носом:
Если посмотришь все эти bank*.c, увидишь, что они реализуют набор одних и тех же функций. pagemap_add, pagemap_free, pagemap_alloc, pagemap_realloc. Указание менеджеру памяти на то, какие страницы есть - это pagemap_add. Она вызывается из pagemap_init в platform-zx128/main.c. У меня сейчас, к примеру, задаются только две свободные банки - 1 и 3 (ссылка на код)

[SfS]

Да я уже разобрался, спасибо.

По-хорошему твой коммит нужен в основной ветке. Не все ж ахитектуры именно с адреса 0 банки переключают.

Для z80, кстати нелогично с 0 банку включать. Там же рядом вектора лежат.

Может просто в конфиге ядра какой символ предусмотреть? Если он не определён - компилить как раньше. Если определёно - то как в твоём коммите.

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