То есть надо вместо di вызывать irq_store=di()?
А вместо ei - irq_restore(irq_store)?
---------- Post added at 16:48 ---------- Previous post was at 16:44 ----------
Но если "прерывания всегда запрещены" - то зачем вообще их разрешать?
То есть надо вместо di вызывать irq_store=di()?
А вместо ei - irq_restore(irq_store)?
---------- Post added at 16:48 ---------- Previous post was at 16:44 ----------
Но если "прерывания всегда запрещены" - то зачем вообще их разрешать?
Этот DI был фиксом к чему-то. Без него не работало. Ну а EI в пару к нему.Цитата:
Сообщение от SfS
Сейчас, правда, есть подозрение, что вылечил я тогда только один симптом, а причина была эта же самая, что и сейчас.
глядя на функции map_kernel() других архитектур - я вообще там чтото не вижу поигрывания прерываниями.
На других архитектурах есть возможность узнать, какая банка включена в данный момент (нужно для map_store). У нас нет, и поэтому вывод в порт и сохранение в current_map надо делать в рамках одной "критической секции". Ну и пошло-поехало.Цитата:
Сообщение от SfS
Но, повторюсь, сейчас, когда DI нет, но всё переделано на стек, те глюки, что были, не вернулись. Поэтому и кажется, что то, что тогда di/ei что-то починили - это было всего лишь совпадением.
Я делаю так: у меня все переключаемые банки в самом теле страничек последовательно пронумерованы перед стартом ядра значением, соответствующим коду порта переключения страниц: в служебной области выше UZIXBASE кроме служебных процедур и структур типа GotoUnix, GotoExit, UDATA_STASH, еще есть байтовая ячейка с номером страницы. Когда мне надо прочитать состояние порта переключения страниц (аппаратно он только на запись), я читаю ту ячейку (позже старта никогда туда более не записывая). Соответственно, нет необходимости в лишнем DI/EI и работает на несколько тактов быстрее. :)Цитата:
Сообщение от Eltaron
Дурацкая ошибка - https://github.com/atsidaev/FUZIX/co...3c658c0a5665bd, починил. Все программы с SfS-овского образа стартуют, никаких багов в работе не замечено. Медленно только всё.Цитата:
Сообщение от Eltaron
Спасибо огромное. Засунул в пентевную архитектуру стековый вариант переключалки - и ура! работать стало стабильно.Цитата:
Сообщение от Eltaron
На реальной пентеве даже копирование проходит и симлинки создаются!
Добавил в тырдосный драйвер от b2m запись. ln проходит, rm проходит. cp и touch валятся.Цитата:
Сообщение от SfS
http://dl.dropboxusercontent.com/u/2...zx/fuzix_5.png
А в какой ветке у тебя этот правленный шелл лежит? Хочу пересобрать юзерспейс с оптимизированной либой.Цитата:
Сообщение от SfS
А его вообще в репозиториях нет. потому как просто кромсанул - удалил чуть не половину...Цитата:
Сообщение от Eltaron
кстати, ls тоже не собирается в 16 К
Прицепил сюда.
Отлаживал урезанный вариант ls, нашёл неслабую ошибку в библиотеке. Файл readdir.c должен оканчиваться так:
Раньше обнулялся байт по смещению len-1, в результате портилась цепочка свободной памяти.Код:strncpy(buf->d_name, (char *) direntry.d_name, len - 2);
buf->d_name[len - 2] = 0;
return buf;
Прикладываю также свои варианты ssh и ls. Шелл на пару Кб больше, чем у SfS, зато функциональность не пострадала. В ls закомментировал сортировку и вывод времени.
Ого, классная бага! Запушил Алану http://github.com/EtchedPixels/FUZIX/pull/22Цитата:
Сообщение от b2m
Если честно, я бы вместо len-2 поставил константу MAXNAMLEN - и быстрее, и надёжнее. Мало ли что вернёт система :) Сейчас она всегда возвращает 32.
Глядя на то, как медленно и печально грузится ls, мне пришла в голову мысль, что основную часть библиотеки libc нужно бы разместить в ПЗУ. Варианта, естесственно, три:
1. вместо BASIC48
2. вместо TRDOS
3. вместо RESET SERVICE
В первом варианте теряем возможность запускать игрушки, во втором - запускать дисковые игрушки, третий вроде подходит, но нужно будет обращаться через 3Dxx, к тому-же будут открыты порты BDI.
Что думает по этому поводу уважаемый Eltaron? :)
Я ничего не знаю про RESET SERVICE, но идея разделяемой либы, конечно, хорошая. С точки зрения маппинга будут проблемы - нужно сохранять/восстанавливать не только страницу ОЗУ, но и ПЗУ. Но это решаемо.Цитата:
Сообщение от b2m
У меня была другая идея - выделить под либу одну из страниц ОЗУ. Но тут не только с маппингом пришлось бы попрыгать, но и с вызовом библиотечных функций. Новый RST городить, или ещё какую-нибудь точку входа ниже #C000.
Это когда ставятЦитата:
Сообщение от Eltaron
256Кб64Кб ПЗУ, в которой и BASIC48, и BASIC128, и TRDOS в одной м/с. Насколько я понял, там остаётся ещё одна свободная страница, которая включается после сброса, если BDI настроен на автоматическое включение TRDOS после сброса.
Там всё просто: для ядра - ядро, для режима пользователя - либа. RST, конечно, надо в либе реализовать, также как и обработку прерывания в режиме пользователя.Цитата:
Сообщение от Eltaron
А как быть с адресами данных, которые по любому в другой странице ОЗУ вместе с программой?Цитата:
Сообщение от Eltaron
У меня была аналогичная идея, но я думал освободить непереключаемое ОЗУ для libc и других разделяемых библиотек, практически полностью перенеся ядро в переключаемые страницы. Много занимают буфера, но перенеся их в другие страницы мы усложняем загрузку файлов в область программы. А если, например, код ядра и буфера будут в разных страницах, то тут могут другие сложности возникнуть.
Вобщем libc в ПЗУ - наиболее простое решение.
ну ПЗУ ставят на самом деле 64кб (27С512), 4 страницы по 16кб. первые 16 кб или свободны или используются под свои нужды - командеры, менюшки, либы как в вашем случае, вторая страница используется под ТРДОС, третьи 16кб используется под бейсик 128, который часто меняют опять же на командеры или какой-то альтернативный менюшке софт, и последняя 4я страница это прошивка бейсик 48кб для 128 машин, его менять само собой нельзя. т.е. если разобраться в вашем распоряжении могут быть две страницы по 16 кб - это 1я и 3я (считаем с 1й).Цитата:
Сообщение от b2m
Ой, пардон, разрядность зашкалила :)Цитата:
Сообщение от solegstar
---------- Post added at 22:34 ---------- Previous post was at 22:30 ----------
Ту страницу, что под бейсик 128, мы уже используем как часть ядра. Остаётся самая первая страница (её обычно вроде reset service называют?)
Я, конечно, не отказываюсь от идеи переписать либы на асме, но всё-таки. Может быть попробовать скомпилить FUZIX IAR`ом?
Кстати, кто-нибудь объяснит, где взять правильный stdint.h и почему его нет в дистрибутиве?
Муторно это, всю инфраструктуру переделывать надо. И все .s фиксить.Цитата:
Сообщение от Sergey
Это часть sdcc. /opt/sdcc/includeЦитата:
Кстати, кто-нибудь объяснит, где взять правильный stdint.h и почему его нет в дистрибутиве?
Досадно. В IAR такого файла нет.Цитата:
Сообщение от Eltaron
Сколько памяти под стек нужно ядру? Хотя бы порядок - 100 байт, 256, килобайт... сколько?
Можете поглядеть на работающей системе (в эмуляторе к примеру)?
За пару минут работы самое большее, что отхапывало - 160 байт.Цитата:
Сообщение от Error404
Алан запилил микродрайв!
https://github.com/EtchedPixels/FUZI...c519c8f6c75330
А с +2 микродрайв несовместим.:(Цитата:
Сообщение от Eltaron
На очереди карт-пунчер и карт-ридер? :)Цитата:
Сообщение от Eltaron
Тогда как народ страдает без TCP/IP и FAT!
ОФФТОП) Еду заватра домой. Надеюсь включусь в доработки через несколько деньков
Робяты, а что тут тишина? ) никто не пилит FUZIX?)
Алан пилит :)Цитата:
Сообщение от SfS
Лично у меня всяческие отчеты и прочая декабрьская рутина, не до фузихов.
Анал огично)Цитата:
Сообщение от Eltaron
приехал, буду ещё неделю мудохаться минимум. но есть желание продолжить фузикс.
Чего там у Алана, какие новости? Кто-нибудь мониторил?Цитата:
Сообщение от Eltaron
Шибко интересно про TCP/IP.
Как-то на евоном CVS собирать инфу по крохам из комментов к правкам модулей - весьма неудобно.
Надеемся и верим, что после праздников работы по теме "ФУЗИКС" возобновятся с новой силой!:)
TCP ещё нету. Запилили поддержку Z180, счас там чел, который socz80 разработал, коммитит активно.Цитата:
Сообщение от Error404
Поковырялся немного в коммитах ихнего CVS, составить представление чего там творится почти не возможно: коммитится много всякой мелочевки, комментится скудно. Нужны дайджесты! Чтобы не пропустить что-то интересное.
Обратил внимание, что у FUZIX 62 функции ядра, тогда как у UZIX v1.0, более развитого чем UZI который по сути и есть FUZIX, их только 40 (и что характерно - на все хватает). Чего там добавлено при более чем вдвое большем количестве функций? У Юзикс такие функции:
Скрытый текст
Код:GBL char *disp_names[] = {
/*00*/ "access",
"alarm",
"brk",
"chdir",
"chmod",
/*05*/ "chown",
"close",
"getset",
"dup",
"dup2",
/*10*/ "execve",
"exit",
"fork",
"fstat",
"getfsys",
/*15*/ "ioctl",
"kill",
"link",
"mknod",
"mount",
/*20*/ "open",
"pause",
"pipe",
"read",
"sbrk",
/*25*/ "seek",
"signal",
"stat",
"stime",
"sync",
/*30*/ "time",
"times",
"umount",
"unlink",
"utime",
/*35*/ "waitpid",
"write",
"reboot",
"symlink",
/*39*/ "chroot"
};
[свернуть]
В отпусках все что ли?
Все во флейме :)Цитата:
Сообщение от Error404
ну на работе я ОСью заниматься не могу, а пару постов во флейм - завсегда)
На сегу мегадрайв ещё не компилировали эту ОС ?
Или 68k в пролёте ?
На 68k можно и что-то более полноценное взгромоздить. Благо адресное пространство позволяет.
Можно то оно можно. Но вряд ли кто-нибудь займётся подобным.Цитата:
Сообщение от NovaStorm
Только конкретно в мегадрайве это адресное пространство представляет из себя ПЗУ.Цитата:
Сообщение от NovaStorm
оперативки же всего 128 кб.