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

Цитата:

---

Сообщение от Eltaron

В небанкуемой области - в самых верхних 4к. Вроде как с #F200.

---

Но она же должна быть у каждого процесса своя? Или как?
И при межстраничном вызове (из процесса в ядро) копироваться из страницы процесса в страницу ядра. Или как вариант, в общей памяти должно лежать столько udata-ов, сколько процессов в ОЗУ, каждый из процессов пишет в свою по вычисляемому указателю, и при переключении контекста ядро будет брать нужную UDATA по указателю, вычисляемому в зависимости от того в какой 60-к страничке сейчас выполняется код процесса (чтобы избежать межстраничного копирования). Правда не известно что быстрее: скопировать 119 байт между страниц, или работать по указателю и в процессе и в ядре.

Цитата:

---

Сообщение от Error404

Но она же должна быть у каждого процесса своя? Или как?
И при межстраничном вызове (из процесса в ядро) копироваться из страницы процесса в страницу ядра.

---

А, понял, ты про копию? Она называется U_DATA_STASH и лежит в #ED00-#EFFF. Самая вершина банки процесса.
А UDATA c 0xF000, я ошибся.

Загрузчик ядра напрямую с SD-карты (ПЕНТЕВА).
Там же его исходники.

http://forum.nedopc.com/download/file.php?id=2040

В общем - научил вроде пока костыльно видеть FUZIXFS на SD - всегда второй главный раздел. Hello World оттуда запустился. форкается. Остальное - завтра.

Цитата:

---

Сообщение от Sergey

Зависает: кажет на экране мусор и 4 вертикальные полосы, шириной 8 знакомест.
Зависание происходит после загрузки (на экран выводится какая-то таблица).
Причем, если выставить в пентеве 14МГц, то после "матраца" экран очищается и в ЛВУ печатается какое-то слово, затем сразу сбрасывается.

---

Всё робит,- просто, я трдшник не монтировал :)

Непонятки. bank16.c и bank32.c собираются. Но они ж не нужны. может их както выпилить вообще?

Цитата:

---

Сообщение от SfS

Непонятки. bank16.c и bank32.c собираются. Но они ж не нужны. может их както выпилить вообще?

---

Они не линкуются. Все, что линкуется - в uzi.lnk.

Срочно нужен ассемблерный листинг из vfprintf.c для HC08.

ассемблерный листинг из vfprintf.c для HC08

Цитата:

---

Сообщение от Eltaron

Они не линкуются. Все, что линкуется - в uzi.lnk.

---

По-хорошему, то, что не линкуется и собираться не должно. Ну да бог с ним.

Я Makefile немного причесал и добавил скрипт для определения путей SDCC.
Плюс - в libclean вставил автоопределение местоположения z80.lib

Для облегчения жиззни - слей это к себе в репозиторий.

А то SDCC у одних - в /opt у других в /usr/local. - каждый раз ручками пути менять - упаришься.

---------- Post added at 14:11 ---------- Previous post was at 14:09 ----------

Слушай, а для работы инита обязательно нужен tty1 ?

Цитата:

---

Сообщение от SfS

Слушай, а для работы инита обязательно нужен tty1 ?

---

А какие проблемы?
mknod /dev/tty1 20666 257 - и вуаля, создали tty1

---------- Post added at 13:21 ---------- Previous post was at 13:18 ----------

Цитата:

---

Сообщение от SfS

Я Makefile немного причесал и добавил скрипт для определения путей SDCC.
Плюс - в libclean вставил автоопределение местоположения z80.lib

---

Да, я всё хочу это в апстрим запушить.
Один твой коммит уже там :) https://github.com/EtchedPixels/FUZIX/commit/a13208b Вычищать из него, правда, пришлось практически всё - ты одновременно и обрезание \r закоммитил. Это не круто, когда такие принципиально разные вещи в одном коммите пушатся.

Цитата:

---

Сообщение от Eltaron

А какие проблемы?
mknod /dev/tty1 20666 257 - и вуаля, создали tty1

---------- Post added at 13:21 ---------- Previous post was at 13:18 ----------


Да, я всё хочу это в апстрим запушить.
Один твой коммит уже там :) https://github.com/EtchedPixels/FUZIX/commit/a13208b Вычищать из него, правда, пришлось практически всё - ты одновременно и обрезание \r закоммитил. Это не круто, когда такие принципиально разные вещи в одном коммите пушатся.

---

На AIX так:
mknod Name { b | c } Major Minor
т.е. все понятно и логично - класс устройства и экземпляр (индекс). Т.е. мажорный и минорный номера, обычно они небольшого значения (ибо типов и экземпляров устройств немного). А что есть цифры 20666 и 257? Почему такие большие значения?

Цитата:

---

Сообщение от Error404

А что есть цифры 20666 и 257? Почему такие большие значения?

---

20666 - права. Символьное устройство, доступ всем на чтение-запись.
257 = 256 + 1, major = 1, minor = 1

Цитата:

---

Сообщение от Eltaron

Вычищать из него, правда, пришлось практически всё - ты одновременно и обрезание \r закоммитил. Это не круто, когда такие принципиально разные вещи в одном коммите пушатся.

---

Это да. Но вырезание '\r' вещь для линукса необходимая.
Кстати, там кроме вырезания ещё и автоформатирование С-файлов. Иначе некоторые вообще нечитаемы были.

---------- Post added at 14:34 ---------- Previous post was at 14:31 ----------

Цитата:

---

Сообщение от Eltaron

А какие проблемы?
mknod /dev/tty1 20666 257 - и вуаля, создали tty1[COLOR="Silver"]

---

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

Цитата:

---

Сообщение от SfS

Кстати, там кроме вырезания ещё и автоформатирование С-файлов. Иначе некоторые вообще нечитаемы были.

---

Это у тебя длина табуляции стоит неверная :)

Я лично стараюсь вообще эту всю мелочь типа концов строк и форматирования не трогать. Смысла мало - ну, если компилятор не ругается, - а риск нарваться на merge conflict вырастает на порядки.

Подскажите еще вопросик: как (где) в пространстве процесса FUSIХ хранятся:
- пареметры переданные программе (процессу) при запуске (т.е. то, что в CP/M кладется по адресу 0x80..0xFF)
- переменные окружения (environment)

Цитата:

---

Сообщение от Error404

Подскажите еще вопросик: как (где) в пространстве процесса FUSIХ хранятся:
- пареметры переданные программе (процессу) при запуске (т.е. то, что в CP/M кладется по адресу 0x80..0xFF)
- переменные окружения (environment)

---

Судя по всему, прямо под UDATA. Функция wargs их кладет (link). Любопытно, пересекается с UDATA_STASH. Впрочем, она 768 байт, всем хватит.

Цитата:

---

Сообщение от Eltaron

Судя по всему, прямо под UDATA. Функция wargs их кладет (link). Любопытно, пересекается с UDATA_STASH. Впрочем, она 768 байт, всем хватит.

---

вот кстати это тоже зацепило: 768 байт, откуда, зачем? Ведь на UZIX, к примеру, sizeof(udata)=119 байт.
Или он расширил ее на размер стринговых параметров которые в некоторых функциях (в мало каких функциях, иногда, один-два параметра char[]) передаются ядру - чтобы оно сразу копировалось в страницу ядра?

Цитата:

---

Сообщение от Error404

вот кстати это тоже зацепило: 768 байт, откуда, зачем? Ведь на UZIX, к примеру, sizeof(udata)=119 байт.
Или он расширил ее на размер стринговых параметров которые в некоторых функциях (в мало каких функциях, иногда, один-два параметра char[]) передаются ядру - чтобы оно сразу копировалось в страницу ядра?

---

Скрытый текст

Код:

---

/* This is the user data structure, padded out to 512 bytes with the
 * System Stack.
 */
typedef struct u_block {
        u_data u_d;
        char  u_s [512 - sizeof(struct u_data)];
} u_block;

---

[свернуть]

Плюс 256 байт на стек для прерывания (интересно нафига).

Цитата:

---

Сообщение от Error404

вот кстати это тоже зацепило: 768 байт, откуда, зачем? Ведь на UZIX, к примеру, sizeof(udata)=119 байт.

---

Стек процесса ещё рядом лежит.

А вот стек прерывания... Окей, зачем его в common держать - я понимаю. Но зачем копировать туда-сюда?

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

А хотя догадываюсь. Эти 256 байт - это стек прерывания только на время прерывания. В остальное время это как раз хранилище переменных окружения и аргументов командной строки.

Цитата:

---

Сообщение от Eltaron

Это у тебя длина табуляции стоит неверная :)

---

Символ \t - верен по определению)

Читает инит с флешки, выполняет и затыкается на ulink("/etc/mtab"); примерно

Цитата:

---

Сообщение от SfS

Читает инит с флешки, выполняет и затыкается на ulink("/etc/mtab"); примерно

---

Может, на чтении /etc/passwd? Просто у меня дело доходило до спауна шелла. Добавь в passwd строчку root:::/root:/bin/sh

пишет "panic: corrupt inode" хотя сам инит запускает(

Цитата:

---

Сообщение от SfS

пишет "panic: corrupt inode" хотя сам инит запускает(

---

fsck ?

Цитата:

---

Сообщение от SfS

пишет "panic: corrupt inode" хотя сам инит запускает(

---

Я бы драйвер fdd проверял в таком случае. Corrupt inode - это же когда запрошен блок, где должен быть айнод, но его там не оказалось.

Цитата:

---

Сообщение от Eltaron

Я бы драйвер fdd проверял в таком случае. Corrupt inode - это же когда запрошен блок, где должен быть айнод, но его там не оказалось.

---

да я уже башку сломал.

Короче у меня не драйвер ФДД, а драйвер SD.

Там всё что мной написано - это процедуры считывания блока, записи блока и init_sd().

init_sd() - читает mbr и находит первый сектор 2й партиции. Запоминает его. Всё.

Все процедуры - read() и write() пишут-читают по смещению первого сектора второго раздела.

я генерирую образ с нуля и заливаю его на второй раздел.

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

буду дальше копать

---------- Post added at 07:50 ---------- Previous post was at 07:02 ----------

такое ощущение, что что-то с памятью...

Лень было допиливать свой эмулятор, чтобы он читал из файла по обращению к портам, проще оказалось сделать обращение к trdos. Вот выкладываю результаты, в моём эмуляторе работает (загрузка fuzix в мой эмулятор нетривиальна, тут я думаю, как это всё это упростить, в идеале нужно догружать ядро с диска).

Цитата:

---

Сообщение от b2m

Лень было допиливать свой эмулятор, чтобы он читал из файла по обращению к портам, проще оказалось сделать обращение к trdos. Вот выкладываю результаты, в моём эмуляторе работает (загрузка fuzix в мой эмулятор нетривиальна, тут я думаю, как это всё это упростить, в идеале нужно догружать ядро с диска).

---

ЭТОТ инит у меня прекрасно с SD грузится и работает.

Я про ноормальный ИНИТ

Цитата:

---

Сообщение от b2m

Лень было допиливать свой эмулятор, чтобы он читал из файла по обращению к портам, проще оказалось сделать обращение к trdos. Вот выкладываю результаты, в моём эмуляторе работает (загрузка fuzix в мой эмулятор нетривиальна, тут я думаю, как это всё это упростить, в идеале нужно догружать ядро с диска).

---

А орионовский эмулятор твой и допиливать не надо будет! ;) Там с уровнем дисков уже в ажуре всё. :rolleyes:
Подключайся?

Цитата:

---

Сообщение от Error404

Я пользуюсь пока вот таким эмулятором под винду - он умеет возвращать винде код завершения HitechC, что нужно для make.

Среды как таковой я не делал, просто использую ProgrammersNotepad, где в проекте (фактически - списке файлов: UZIX.pnproj) описал используемые файлы и на кнопку F8 настроил сборку по make (Tools->Options->Tools->Scheme C/C++ -> Add)
Но чаще после внесения всех правок в PN просто запускаю make под cmd.

Тут мой рабочий каталог uzix (в нем UZIX.pnproj для примера), и каталог компилятора hitechC - на него должны быть настроены пути в переменных окружения PATH и CPMPATH:

Название: HTC-win.zip
http://rusfolder.com/42355053
Доступен до: 2014-12-24 10:52:46
Размер: 1.06 Мб

---

Для интересующихся сделал сборку UZIX: собрал архив требуемых для компиляции утилит и ядра исходных файлов, добился что все компилируется (это было нетривиально, т.к. компилятор работает на Z80 в 60к ОЗУ и ему его часто не хватает - изначально исходники были несобираемы от слова совсем, видимо крайний раз они шли уже под PC с его ТурбоС), а утилиты еще и все полностью работают. Ядро "hello world" пишет, но ничего относящегося к процессам я пока не делал (там много чего надо доделать). Сборка проходит за 15 секунд. :rolleyes: Собирается так:

• правим мakefile - изменяем так: "DEFINES = -DORI_UTIL", или так: "DEFINES = -DORI_UZIX", в зависимости от того утилиты или ядро компилируется соответственно.
• запускаем cmd, переходим (cd) в каталог где лежат исходники
• cmd> make clean & REM удаляем объектники - их надо пересобрать
• cmd> make kernel & REM ну или "make utils" - смотря что в DEFINES

Исходники библиотек тоже есть, если кому-нибудь будет интересно - выложу. С библиотеками пока не занимался.

Ядро у меня - обычная CP/M-задача, которая будет "крутить" UNIX-процессы в расширенном ОЗУ. Архитектура будет такая:

Код:

---

                CP/M 64k bank      Subsequent 64k banks
        FFFF        +------------+                +------------+
    Common        |  Common  |                |  Common  |+
        F000        +------------+                +------------+|+
                |    CP/M    |                |            |+|+
                +------------+                |  Process  ||+|
    Banked        |  Kernel  |                |    Code    |||+
                |    Code    |                |  & Data  ||||
                |            |                |            ||||
        0100        +------------+                +------------+|||
                |  Reserved  |                |  Reserved  |+||
        0000        +------------+                +------------+|+|
                                        +------------+|+
                                          +------------+|

---

Ядро, кстати, получается 28кб. С дописанными процессами будет, думаю, порядка 30кб (это учитывая, что в UZIX побольше накручено, чем в FUZIX, как я понял) - годится для любого клона Орионовских CP/M. Есть клоны CP/M с TPA до 58 кб, т.е. хватит места и TCP/IP впилить, и поддержку ФС FAT.

В качестве дисков используется IDE/SD через CP/M-овский драйвер "сырого доступа" IDEBDOS, схема MBR-партиций (поддерживаются только 4 основные партиции на двух физических приводах - итого 8 (fd0..fd7) партиций, плюс fd8..fd9 - целые "сырые" диски (от LBA0=MBR до LBAmax)), номер партиции передается в утилиты (проверяемая/копируемая/где создается FS) и в ядро (root-партиция, остальные через mount) как параметр командной строки.

В общем косяк гдето в реализации библиотеки форка чтоли...

простая ассемблерная программа- форкается.
а вот на С - фига.

Цитата:

---

Сообщение от SfS

В общем косяк гдето в реализации библиотеки форка чтоли...

простая ассемблерная программа- форкается.
а вот на С - фига.

---

Может со стеками что-то?

Я вот тоже думаю:
Когда был UZIX или UZI, у которого ядро (верхние 32к от 64к-шного пространства) и текущий обрабатываемый процесс (нижние 32к от 64к-шного пространства) всегда были все же в общем пространстве, то такие вещи как куда установлен стек при вызове unix() и куда установлен стек в момент наступления прерывания - они не имели критического значения (хотя стек и переставляется на временный в определенные моменты). Когда же ядро и процессы разносятся в разные страницы памяти, это уже становится попоболью.

А вот еще вопрос на засыпку. Ну ладно, стек обработчика прерывания можно назначить внутри страницы ядра, при вызове unix() тоже можно запоминать, переставлять и восстанавливать потом стек. Но есть еще сигналы. Процессы регистрируют обработчики, которые вызываются, условно, произвольно. Ядро сделает вызов в другую страницу, но куда-то надо поставить и стек, чтобы он не пересекался с предыдущими двумя.

---------- Post added at 18:20 ---------- Previous post was at 18:17 ----------

У Алана вообще работоспособное то что-то было кроме ядра? В его блоге никаких обновлений. Может еще блог есть, а я и не знаю?

---------- Post added at 18:22 ---------- Previous post was at 18:20 ----------

Кстати, если кто там зареган - черкните пару строк. Человеку надо понимать, что его проект интересен: это стимулирует не бросить всё к такой-то матери.

УРААААА! НАШЁЛЛ!!!
Просто в dofork() я портил регистр а инверсией. Номер страницы инвертировался для вывода в пентевный регистр.
Ещё одна команда cpl спасла меня.

Цитата:

---

Сообщение от SfS

УРААААА! НАШЁЛЛ!!!
Просто в dofork() я портил регистр а инверсией. Номер страницы инвертировался для вывода в пентевный регистр.
Ещё одна команда cpl спасла меня.

---

Ну что, бэйзконфа сыграла с тобой злую шутку? ;)

Цитата:

---

Сообщение от Sergey

Блин, ну чего ты не под тсконфу начал писать!
Нажми Ctrl+Alt+F12. :)))

---

И это было бы смешно, когда бы не было так грустно...

скорее невнимательность. мало ли где как накосячишь.

Цитата:

---

Сообщение от Error404

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

---

Стек прерывания на время обработки сигналов уже не нужен, его можно смело загадить. Так, по-моему, и происходит.

Цитата:

---

Кстати, если кто там зареган - черкните пару строк. Человеку надо понимать, что его проект интересен: это стимулирует не бросить всё к такой-то матери.

---

Я ему пулл-реквесты шлю, это более красноречиво :)
За ходом разработки там же можно наблюдать, он подробные комментарии к ключевым коммитам пишет.

Цитата:

---

Сообщение от Eltaron

За ходом разработки там же можно наблюдать, он подробные комментарии к ключевым коммитам пишет.

---

А как это смотреть?

Цитата:

---

Сообщение от Error404

А как это смотреть?

---

https://github.com/EtchedPixels/FUZIX/commits/master

Цитата:

---

Сообщение от SfS

скорее невнимательность. мало ли где как накосячишь.

---

Не в обиду: мыши кололись, плакали, но продолжали жрать кактус! :)

---------- Post added at 22:10 ---------- Previous post was at 21:55 ----------

Цитата:

---

Сообщение от SfS

УРААААА! НАШЁЛЛ!!!

---

Образ, - образ рабочий давааай!