Какой скриншот? я на реальной пентеве его мучаю. Фото чуть раньше кидал.Цитата:
Сообщение от Sergey
Вот новые)
Какой скриншот? я на реальной пентеве его мучаю. Фото чуть раньше кидал.Цитата:
Сообщение от Sergey
Вот новые)
Кому многозадачность?
http://dl.dropboxusercontent.com/u/2...zx/fuzix_3.png
fork() реализован, переключение процессов тоже. Осталась фигня - как-то скомпилировать системные утилиты.
(в аттаче форкующийся инит, который на скрине)
А либы есть?
Я почему с юзикса пытаюсь начать - там они много функций реализовали в либах, приложения их соответственно используют, без либ не собирутся.
только syslib. Она собралась, но в ней остались символы, которых нигде нет, и без которых сборка самих утилит падает. Подозреваю, что почему-то не прилинковываются либы от sdcc - потому что символы примитивные, memcpy всякий и __modslonglong.Цитата:
Сообщение от Error404
longlong - это не про int64? И пусть бы с ним, в тех проектах длинее long (int32) нигде не используетсяЦитата:
Сообщение от Eltaron
Используется - хваленый коксовый "настоящий" time_t, решающий проблему 2038-го года... Из за него даже ls не собирается.Цитата:
Сообщение от Error404
Ну таперича мне её проще впилить будет, спасибо :)Цитата:
Сообщение от Eltaron
чтото не нравится мне, что при переключении каждый раз копируется по 768 байт в обе стороны.
Если я правильно понимаю, то U_DATA - это область, через которую ядро взаимодействует с процессором.
Она лежит по адресу 5B00.
У каждого процесса имеется копия этой области, лежащая в окне процесса по адресу FD00 и обзываемая U_DATA__STASH.
При входе в процесс - происходит копирование 786 байт из U_DATA в U_DATA__STASH.
При выходе в ядро - обратно - из U_DATA__STASH в U_DATA.
то есть полтора килобайта копируется кждые 20 мс.
Если ядро влазит в 48к, то смысла такого копирования я не вижу. Проще сразу задать U_DATA=FD00 и щёлкать страницы.
Единственный случай, когда на 128к может понадобиться копирование U_DATA в ядро и обратно - это написание модульных драйверов - т.е. когда драйвер не в ядре, а в иной странице памяти.
В Pentevo - ещё проще. Можно, например, процессы так и оставить в 0xC000, а драйвера включать в доп. страницы с 0x8000. Тогда копирование вообще не понадобится.
В чём я не прав?
---------- Post added at 13:25 ---------- Previous post was at 13:08 ----------
И ещё вопрос - что за запись по адресу #0000 происходит в lowlevel-z80.s ?
Что за флаг такой?
---------- Post added at 13:27 ---------- Previous post was at 13:25 ----------
Кстати, а что за PID у инита такой хитровыделанный? 25907 ?
Алан любит "бантики", похоже. "проблема 2038" (дожить бы!), удлиннение имен файлов, еtс :biggrin:Цитата:
Сообщение от Eltaron
В том, что ядро не влазит в 48к, конечно :)Цитата:
Сообщение от SfS
---------- Post added at 13:24 ---------- Previous post was at 13:23 ----------
Вообще, я изначально так и собирался сделать. И оно даже реализуемо, если хорошо раскидать сегменты по памяти. Но пока что решил, что это преждевременная оптимизация и корень всех зол.
---------- Post added at 13:30 ---------- Previous post was at 13:24 ----------
ну а прикинь завтра фюьзикс в космос надумают отправлять, а в нём y38k не решен! :v2_rolley и отправят ELKS какой-нибудь. Позор на всю жизнь же!Цитата:
Сообщение от Error404
---------- Post added at 13:32 ---------- Previous post was at 13:30 ----------
http://imgs.xkcd.com/comics/2038.png
---------- Post added at 14:26 ---------- Previous post was at 13:32 ----------
Это на деле оказался не PID, а указатель на структуру описателя процесса. Надо убрать, это мой отладочный kprintfЦитата:
Сообщение от SfS
ЗЫ я знаю, почему у тебя нижний правый квадратик - белый ;)
Кто знает - вот это вот:
https://plus.google.com/+AlanCoxLinux/posts/a2jAP7Pz1gj
это единственный блог проекта? А то чего-то там никаких движений не происходит. Где отчеты автора? Хочется почитать.
Проверка, не испортилась ли память (например, если писали по нулевому указателю). Если там всё равно ПЗУ, её можно закомментировать.Цитата:
Сообщение от SfS
Вообще-то у init-а PID должен равняться 1, в doexit даже проверка есть, если завершился процесс с номером 1, то ядро паникует.Цитата:
Сообщение от SfS
Про то, что это "не горит" - согласен. Но раз ты об этом думал, значит у нас мысли идут в похожем направлении.Цитата:
Сообщение от Eltaron
Честно говоря, не вижу проблем запилить в либы свои несколько функций работы с 64-битной арифметикой. Больше разговоров, ИМХО.Цитата:
Сообщение от Eltaron
Ну я твой код не правил шибко. Пока больше читаю, чем пишу :)Цитата:
Сообщение от Eltaron
А почему?)
Да просто лишнее это. На дефайнах заменить нафиг на 32-разрядный. Т.к. 64-разрядный вариант работать будет медленее, а у нас не Т80 на сотне мегагерц. В Юзикс всего одна (одна!) функция где используется 32-разрядный параметр, во всех остальных местах все 16-разрядное. А тут какие-то 64-разрядные излишества.Цитата:
Сообщение от SfS
если сделать вот так:Цитата:
Сообщение от Error404
то проигрыш с переходом на 64 бит переменную - минимальный (если вообще есть )Код:inc_64_value:
;hl - указатель на 8-байтовую переменную
dup 7
inc (hl)
ret nz
inc hl
edup
inc (hl)
ret
надо использовать adc (учитывать перенос), а не inc, чтобы был не инкремент 8 байтов, а 8-байтного числа. Или я что-то не догоняю.Цитата:
Сообщение от shurik-ua
Кроме того, инкремент - это частный случай (и то вдвое больший по коду и вдвое меньший по скорости аналогичного 32бит), а когда зайдет речь про арифметику с двумя операндами, да передачу всего этого на стеке, да загрузку по индексному регистру - там будет медленно и объемно. Плюс на регистрах это не сделать в принципе (нету у Z80 столько регистров), а только в памяти (как в примере), а для к примеру 16-битной арифметики, при желании все делается на регистрах, да и для 32-битной многое тоже.
---------- Post added at 17:57 ---------- Previous post was at 17:53 ----------
Потому что там в лдире очистки экрана не зря BC был именно 1800 :)Цитата:
Сообщение от SfS
Ты его на единицу уменьшил, а вот DE и HL соответственно увеличить забыл. В итоге у тебя атрибуты начинаются с 57FF.
Я потому 1800 и поставил. Одно лишнее обращение к памяти один раз при инициализации - фигня. А вот два лишних INC - это два занятых байта драгоценного _COMMONMEM.
Короче SD-карта начала читать.! И писать тоже, по идее должна.
Твой образ прочитала. И запустила Hello World. Только вот многозадачный образ почемуто форкаться отказался... Сцука!
Пишет всё время один процесс.
Это ты очень правильно спросил! У меня из-за этой проверки ядро в определенный момент решало, что всё плохо, и слало процессу SIGSEGV. Добавил jp 3 по адресу 0, чтоб проверка проходила - счас форкнутые процессы уже минут 20 крутятся, полёт нормальный!Цитата:
Сообщение от SfS
Блин, не представляю, как ты на реальном железе отлаживаешься :) Я на вышеописанный баг убил весь вечер, и это притом, что у меня-то и отладчик есть, и эмуль лог M1-чтений пишет.
---------- Post added at 03:11 ---------- Previous post was at 03:08 ----------
Если всегда пишет process 2 (это сам инит), то смотри прерывания, если process 1 (форк), то переключение банок.Цитата:
Сообщение от SfS
Off:
make для CPM (нативного - для Z80 и 60к ОЗУ) есть у кого-нить? Он в природе для CPM есть вообще?
УРА! https://github.com/salextpuru/FUZIX/...55d6666c3d1fea
ЗАРАБОТАЛО!
Всё дело в том, что в пентеве в порты надо кидать ИНВЕРСНЫЕ номера страниц. И я кое-где накосячил.
ФОРКАЕТСЯ!
---------- Post added at 11:13 ---------- Previous post was at 11:10 ----------
Вопрос - почему через пару минут второй процесс исчезает?
можешь дать исходы своего "инита с форком" ?
Через время и первый исчезает. Выше написано, почему. Вот, cherry-pick'ни этот коммит - http://github.com/atsidaev/FUZIX/com...64e3b05623b44dЦитата:
Сообщение от SfS
Сорцы погибли в пучине git clean :( Можешь дизассемблировать, там сотня байт всего. Весь код сводится к syscall 1 (open), syscall 8 (write) и syscall 32 (fork).
потихоньку.. сначала накидал простенький принтф и разобрался с маппером памяти. потом - написал приём байтов с ком-порта и распихивание их по страничкам.Цитата:
Сообщение от Eltaron
ну а теперь - всё довольно просто.
Reset, загрузка с SD загрузчика FUZIX по ком-порту и запуск простенького скрипта на компе, который передаёт FUZIX по ком-порту в виде 4х страниц с паузой между ними по 2 секунды (чтобы загрузчик сообщения на экране выводить успевал).
Сейчас надо всётаки сделать загрузчик фузикса с TRD-диска.
на спекки2010 не пробовали портрировать?
Кстати, а как на эмуле отладить пентевовскую SDшку? я не знаю.
Но за день я добился на реале её работы. Пока, правда, раздел FUZIXFS начинается с сектора 2048 флешки - прибито гвоздями. Но - работает же!)
---------- Post added at 16:11 ---------- Previous post was at 16:10 ----------
у меня нет спекки 2010. только пентева и пентагон1024.Цитата:
Сообщение от palsw
если на пентеве система встанет, то попробую и на пентагоне её запустить.
SfS, тс-конфа же работает на спекки2010 - использовать готовый скелет .железо то позволяет.
Это на ARM7-то? :v2_conf2:Цитата:
Сообщение от palsw
---------- Post added at 15:23 ---------- Previous post was at 15:21 ----------
Если мне кто-нибудь задонейтит speccy2010, я с удовольствием портирую туда ядро в нынешнем виде и оба крайне полезных процесса :cool:
я работал с baseconf.Цитата:
Сообщение от palsw
но ничего не мешает тебе взять сырки и поправить порты менеджера памяти как хочешь. там всего то в 4-5 местах они есть.
---------- Post added at 16:39 ---------- Previous post was at 16:37 ----------
Цитата:
Сообщение от Eltaron
ты лучше с тем же удовольствием пропатчи либы и утилзы, чтобы собирались. :)
если будет минимальная система - то её можно уже будет и на пентагон 1024 перетащить (он есть у меня) и на другие спекомпы.
считаю до того, как можно будет набрать make и собрать все утилиты - дальнейшее ядропортирование на 100500 платформ несколько бессмысленным.
Eltaron, арм там вообще не каким боком.советую почитать в теме последние 5 стр примерно.все делает ФПГА
Кажется, palsw говорит о том, чтобы запилить новую конфу для Speccy2010, чисто под фузих. По-моему, это самый тупиковый путь из возможных.Цитата:
Сообщение от SfS
Eltaron, зачем новую конфу.
раз на пентеве работает то на спекке есть конфа которая эмулит тс-конфу.
лучше обьясните для обычных людей как оно вообще работает - алгоритм.
Либа-то собирается. Да и программы собираются - в sdcc из репозитория бага с __modslonglong пофикшена. Не все - некоторым нужен unix.h, которого нет (а kernel.h на замену не тянет), но собираются. Но выходной файл мало похож на программу для fuzix. Что-то линкер мутное творит, надо поразбираться.Цитата:
Сообщение от SfS
---------- Post added at 15:54 ---------- Previous post was at 15:49 ----------
Для обычных людей, которым лень прочитать две страницы, но которые гонят других читать аж пять - оно не работает ВООБЩЕЦитата:
Сообщение от palsw
У нас ситуация даже хуже, чем у Торвальдса в 1991 - у него хоть кроме ядра был загрузчик с диска. У нас нет и этого, есть только ядро и драйвер экрана/клавы. Напомню, что линукс к виду, пригодному для обычного человека, пришел лишь в 1993 (а некоторые утверждают, что до сих пор не пришел) - это через джва года упорной работы кучи людей. О каком портировании куда-нибудь вообще можно речь вести в такой ситуации?
Eltaron, ясно,будем ждать :).
Цитата:
Сообщение от Eltaron
А ты crt0.s поправил?
там в начале 0x100 байт тупо резервируются.
в нашем случае этого не надо, как я понимаю (PROGBASE=0x100 заменён на PROGBASE=0xC000)
что ещё там не так?
---------- Post added at 17:03 ---------- Previous post was at 17:00 ----------
А у нас уже есть загрузчик по COM-порту) Кстати, скоро он и с диска начнёт грузить. TR-DOS то никто не отменял.Цитата:
Сообщение от Eltaron
Плюс у нас УЖЕ есть линукс, баш и мильён удобных тулз, которых в 90м не было)
Eltaron,Цитата:
Если мне кто-нибудь задонейтит speccy2010
Скрытый текст
нет возможности донатить (
могу только из конструктора собрать, с удовольствием,платку на шару.Осталось ,что бы кто то задонатил платку и детальки :)[свернуть]
Ага, я C000 байт резервирую :) Обрезать-то не проблема. Но беда - в этих C000 встречается что-то кроме 0xFF. Я вчера это увидел и с горя спать пошел, надо на ясную голову поглядеть.Цитата:
Сообщение от SfS
Тр-дос проектировали слишком *beep* (аккуратные) люди. Там прямой доступ к портам возможен только если включена страница TR-DOS, а она включается только если кто-нибудь начнет исполнять шрифт (M1 в 3D00-3DFF). Как это обходить - ума не приложу. На пентеве-то хорошо, да и мне на Кворуме без проблем, а вот в общем пентагоно-128K-образном случае что делать - непонятно. Нужен более умный линкер и много костылей...Цитата:
Кстати, скоро он и с диска начнёт грузить. TR-DOS то никто не отменял.
У них тоже был вполне рабочий миникс и куча софта GNU. Ну да это я так, нагнетаю, на самом деле свет в конце туннеля уже вполне виден.Цитата:
Плюс у нас УЖЕ есть линукс, баш и мильён удобных тулз, которых в 90м не было)
Подумалось - черт побери, а ведь UZI старше Linux! Он же в 1989-м написан или около того.
А с #3D2F в чем сложности? С прерываниями?Цитата:
Сообщение от Eltaron
Так-то и #3d13 наверное подойдет - нам из всех операций с диском нужны только чтение/запись двух подряд идущих секторов. Главная проблема в линкере. Нет возможности сказать линкеру от sdcc, чтоб в 3D00-3DFF не размещал ничего, в области системных переменных тоже, а остальные линкуемые файлы распихал по всей оставшейся памяти.Цитата:
Сообщение от NovaStorm
Ну и хочется универсального решения, ВГ93 не только в бетадиске.
А что там с богомипсами - кажет что нибудь ?)
Теперь приложения собираются как надо, те, что без time_t. https://github.com/salextpuru/FUZIX/tree/apps-fixed
получается красивый бинарь)
---------- Post added at 18:30 ---------- Previous post was at 18:29 ----------
пока не до богомипсов)Цитата:
Сообщение от shurik-ua
А какая стабильная версия SDCC работает с long long нормально? тыкните меня, пожалуйста.