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

[Error404]

64k? а какой толк от него будет? прийдется пересылать блоки между страницами только через регистры процессора (которых галяк), ну или через тормознутый i/o... (и тогда надо будет иметь копию кода для этого i/o в каждой странице) или тогда надо будет лепить какой-то еще memory-memory "копировщик" кроме Z80 на шину...

64к это условно.
На Орионе например переключается только 60к (а верхние 4к "склеенные" для всех страниц). Такая же модель памяти была исходной у Кокса при написании FUZIX. Достаточно удобно получается. Учитывая, что Юзиксу надо в общей памяти максимум 1к ("общей памяти"), то окно может быть и до 63кб размером. При этом каждое переключение контекста - это ldir примерно 2х400 байт ОЗУ + сохранение/восстановление регистров ЦПУ. Несравнимо с ldir Nх16к (в случае если делать процессы больше 16к при окне диспетчера 16к).

Но даже если переключать 3 окна по 16к - нижние 48k (а верхние 16к - "склеенные", в них кстати можно разместить непереключаемые общие для всех процессов бинари, тот же libc частично, или эмулятор CP/M), то 48к на процесс - это и то очень прилично.

Удобство в том, что пофиг сколько у тебя окон и какой размер страниц. Например, в моей реализации с 60-к страницами без перекомпиляции прекрасно работают бинарники однатысяча девятьсот мохнатого года от 32к-страничного Юзикса. Т.е. у нас будет кросплатформенность (точнее крос-клоновость) "вопреки всему"

[bigral]

Удобство в том, что пофиг сколько у тебя окон и какой размер страниц. Например, в моей реализации с 60-к страницами без перекомпиляции прекрасно работают бинарники однатысяча девятьсот мохнатого года от 32к-страничного Юзикса. Т.е. у нас будет кросплатформенность (точнее крос-клоновость) "вопреки всему"

А ну так это другое совсем, это "максимальное адресуемое пространство для процесса", ясное дело чем жирнее оно тем проще писать прогу (уже обсосали 100 раз, факт что большенство алгоритмов в литературе и компиляторов в жизни не учитывают лимитов адресного пространства).

К стати тут уже движутся работы в направлении прикручивания link-ера поддерживающего overlays. https://github.com/EtchedPixels/FUZI...oc/SDCCBanking

[CityAceE]

Какой-нибудь прогресс?

[MVV]

Какой-нибудь прогресс?

Да никакой, уже более 30 лет
Запуск на Спектруме мультизадачной операционной системы изначально не возможен без аппаратных доработок и замены процессора на более быстрый. Ну не побежит дедушка Z80 так, как к примеру на FPGA:



Т.к. начало поддержано не было (ссылка) дальнейшая работа над проектом была свернута. Так, что не видать здесь мультизадачной ОС еще н-нацать лет

[Sergey]

Какой-нибудь прогресс?

Пилю printf на асме. Основная проблема, из-за которой встала работа - катастрофическая нехватка памяти. А львиная доля её приходится на printf() и scanf(). Надеюсь, за счет использования асма и упрощения формата хотя бы килобайта 4 выиграть. Думаю, это позволит продолжить работу над портированием, если "портаторы" не потеряют интерес к тому времени.

[bigral]

А львиная доля её приходится на printf() и scanf().

всегда удивлялся нафига такая сложная функция в ядре системы??? неужели обычного putchar() getchar() было им мало для реализации требуемого функционала?

[Advertiser]

[NovaStorm]

А он так или иначе нужен ведь, почему бы и в ядре не попользоваться тогда?

[Error404]

Да никакой, уже более 30 лет
Запуск на Спектруме мультизадачной операционной системы изначально не возможен без аппаратных доработок и замены процессора на более быстрый. Ну не побежит дедушка Z80 так, как к примеру на FPGA:

:

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

[bigral]

А он так или иначе нужен ведь, почему бы и в ядре не попользоваться тогда?

Как по мне дак совсем не обязательно такому куску как ЯДРО, уметь печатать и форматировать текст так круто как может printf() вполне себе элементарного get/put хватало бы в какую-нибудь виртуальную "консоль", а тут выходит вот такой пример (утрированный), есть грубо говоря 3 куска кода занимающих всю память, 1-й ядро, 2-й printf(), 3-й прога LS например... они как не крути всю память зажрали, если printf() часть ядра то ясное дело что для LS нет маневра, даже тогда если LS решит токо половину printf-a использовать... вот и вся логика.

А вообще со времен прочтения про modula2 для pdp11 пришло понимание того что надо "уметь" разбивать прогу любой длинны и сложности на куски размером с 1 страницу (для zx это 16kB), тогда можно будет имея пачку свободных страничек + какой-то рабочий буфер выполнять и код ядра и код задач несмотря на ограниченное адресное пространство.

---------- Post added at 05:45 ---------- Previous post was at 05:16 ----------

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

Я так понимаю что "некоторые" варианты pdp11, (такие как тот же f11 применявшийся в pdp11/23) работают в той же "скоростной категории" что и z80, просто потому что это все те же 5мкм и соответственно примерно равные частоты, а битность на скорость влияет не так сильно как частота и кэши. Так вот многозадачность там работает, в том плане что может сидеть там паралельно человек 5 и набивать текст ed-ом и потом, компилировать его и играть там в rogue... Про графику забудьте, даже в самых простых динамических играх типа manic miner 90% скорости процессора потраченно на графику, так что надо вешать к спектруму еще один Z80 + память (шото типа general sound) и пускать тогда уже unix на нем, такая идея обкатанна на acon bbc b с его tube интерфейсом и множеством видов "second processor"-ов.

[Eltaron]

Между тем, в мире появился первый человек, получающий за разработку FUZIX зарплату
https://github.com/EtchedPixels/FUZI...ment-105659998

А у меня появилось стойкое ощущение, что в ZX128 оно больше не влазит.