Просмотр полной версии : Алан Кокс представил Unix-подобную ОС Fuzix, ядро которой потребляет около 40 Кб ОЗУ
CityAceE
01.11.2014, 09:21
Алан Кокс представил Unix-подобную ОС Fuzix, ядро которой потребляет около 40 Кб ОЗУ
Алан Кокс (Alan Cox (http://en.wikipedia.org/wiki/Alan_Cox)), известный разработчик ядра Linux, удостоенный в 2003 году престижной премии Free Software Awards за вклад в разработку ядра, в свое время основавший компанию Etched Pixels Digital Design (http://www.etchedpixels.co.uk/), занимающуюся выпуском моделей поездов, представил (https://plus.google.com/111104121194250082892/posts/a2jAP7Pz1gj) проект Fuzix (https://github.com/EtchedPixels/FUZIX) по созданию новой Unix-подобной минималистичной операционной системы. Целевой аудиторией нового проекта являются разработчики, которые устали от обилия усложнений, неуклонного роста размеров и требований современного ПО, и с тоской вспоминают о старых былых временах, когда каждый по имени знал коллег по сообществу, вся работа могла уместиться на дискету и главным мотивом было получение удовольствия от создания чего-то нового.
Целью Fuzix OS является возрождение принципа "just for fun" и создание достаточно полной реализации System 5 Unix, потребляющей минимальный объём ресурсов. В текущем виде ядро новой ОС потребляет всего 40 Кб ОЗУ и поддерживает работу на процессорах на базе архитектуры Zilog Z80 (https://ru.wikipedia.org/wiki/Zilog_Z80). Система может быть запущена на широком спектре систем, основанных на клонах и вариантах Z80, в том числе на платах с T80 FPGA. При этом система изначально рассчитана на обеспечение переносимости, например, в коде уже обеспечена базовая поддержка 8-разрядных процессоров Motorola 6809 (https://ru.wikipedia.org/wiki/Motorola_6809) и MOS 6502 (https://ru.wikipedia.org/wiki/MOS_Technology_6502), что теоретически позволяет запустить ОС и для этих систем.
Порт для процессоров Intel 8086 пока отсутствует, но его создание является делом времени, так как основная проблема заключается в отсутствии пригодного к использованию открытого ANSI C компилятора для CPU 8086 (предприняты попытки задействовать pcc (http://pcc.ludd.ltu.se/)). Процессор Z80 выбран в качестве начальной основы их-за того, что несмотря на обилие для данного CPU различных операционных систем, среди них до сих пор отсутствует полноценно переносимая ОС, способная работать на других типах процессоров. Как и ядро Linux, код новой ОС распространяется под лицензией GPLv2.
Код Fuzix скомпонован из элементов, собранных из разных форков операционной системы UZI (http://www.z80.info/z80os.htm#OS_MT_UZI) и объединённых в единую платфору, расширенную поддержкой Unix-технологий и POSIX. По сравнению с UZI добавлена расширенная поддержка мультипроцессности, появилась возможность использования раздела подкачки, переработан код управления памятью, расширен допустимый размер имён файлов, добавлена поддержка сигналов System 5, Posix termios, архитектура переработана для простого переноса на новые типы процессоров без создания отдельных форков, API расширен вызовами open с 3 аргументами, mkdir, rmdir, rename, chroot, fchdir, fchmod, fchown, fstat, fcntl, setpgrp, sighold and friends, waitpid, setpgrp, nice O_NDELAY, O_CLOEXEC, F_SETFL, F_DUPFD.
Из планов на будущее отмечается поддержка TCP/IP-стека, ptrace, core-дампов, ulimit, uptime, резервирования блоков на диске для пользователя root, вызовов select/poll(), /dev/tty, файловых систем размером более 32 Мб, нового планировщика задач, символических ссылок, загружаемых драйверов, оптимизации подсистемы работы с блочными устройствами, портирование эмулятора CP/M.
Источник (http://www.opennet.ru/opennews/art.shtml?num=40984)
Вау. sdcc, makefiles и платформо-зависимый код, отделенный от основного. За одно это уже можно памятник ставить, учитывая, что из себя представляли исходники UZI.
BlastOff
01.11.2014, 11:11
Дождались таки нормальной ОС, а не командер. :)
CityAceE
01.11.2014, 11:36
Дождались таки нормальной ОС, а не командер. :)
К сожалению, на стандартной архитектуре не взлетит:
First 64k Subsequent 64k banks
FFFF +------------+ +------------+
Common | Common | | Task Store |+
F000 +------------+ +------------+|+
| | | |+|+
| Kernel | | Process ||+|
Banked | Code | | Code |||+
| | | & Data ||||
| | | ||||
0100 +------------+ +------------+|||
| Reserved | | Reserved |+||
0000 +------------+ +------------+|+|
+------------+|+
+------------+|
К сожалению, на стандартной архитектуре не взлетит
На стандартной архитектуре и смысла нет. А вот на эве/спекки2010... Сам Алан разрабатывает под 128-мегагерцовый комп на T80, так что мало надежд на комфортную работу на 3.5.
На чем это работает? x86, arm? как же 68к :)
в редми вижу 6502 :)
CityAceE
01.11.2014, 12:26
На чем это работает?
Разрабатывалось для Z80, но с учётом переносимости на другие архитектуры.
aGGreSSor
02.11.2014, 02:32
Проблемы адаптации судя по z80pack те же что и у CP/M. Значит это можно как-нибудь через попу адаптировать к какому-нибудь ATM и сказать: вот вам - спектрум.
Как прекрасен мир, когда из всего написанного понимаешь только связующие слова )))
Error404
02.11.2014, 18:08
Клево конечно... Через пару лет Алан допишет FUZIX до уровня UZIX если раньше не потеряет интерес. :) И опять этот ужасный SDCC.
CityAceE, откуда схема мапера ОЗУ? Я по ссылкам походил, не нашел.
BlastOff, там работающего экземпляра нет даже у автора, т.к. он разобрал на своей девборде маппер, под который написано.
В-общем, через пару лет станет ясно, уже можно это портировать к себе на Орион, или нет.
shurik-ua
02.11.2014, 18:43
Может и мне попробовать также с ReVerSE-U16?
Я вот тоже присматриваюсь к этой теме - думаю когда-нибудь вернуться к проекту Ultimate на u8. Вот только со временем сейчас сплошной аврал.
Скомпилял ради интереса под org #5CCB. Даже выкинув все устройства не влезло :( Так что классические ZX48/ZX128 в пролёте. А вот клоны с теневым ОЗУ с fuzix подружить теоретически можно, надо только научить линкер обходить нашу дыру в памяти (экран). Места под юзерспейс останется порядка 10 килобайт. Ну хоть что-то.
CityAceE
03.11.2014, 03:05
откуда схема мапера ОЗУ? Я по ссылкам походил, не нашел.
Вот отсюда (https://github.com/EtchedPixels/FUZIX/blob/master/Kernel/README).
Вот отсюда (https://github.com/EtchedPixels/FUZIX/blob/master/Kernel/README).
Это для z180, который в fuzix даже пока не поддержан. Для z80pack (единственной архитектуры, для которой проходит сборка из коробки) распределение сейчас такое:
F000-FFFF common - список процессов, их аттрибуты, стек ядра
A81A-F000 свободно (18406 байт)
0088-A819 ядро fuzix
0000-0088 вектора прерываний и код инициализации
глупости это всё. или вы ради просто пофантазировать? :)
Error404
03.11.2014, 17:41
глупости это всё. или вы ради просто пофантазировать? :)
Я например давно хожу вокруг UZIX (примерно c 2008 года) - задачка то очень интересная, но все подходы разбивались о весьма капризный компилятор Hitech C. Точнее, вообще о проблему отсутствия надежного ANSI С-компилера под Z80, хоть нативного, хоть с PC.
C fuzix все не намного проще будет, т.к. SDCC глючен. Да, допустим что-то там им собирается. SDCC и у меня собирал тот же код, что и Hitech C, причем делал бинарь в полтора раза больше чем Hitech (уже после всех танцев с бубном с оптимизацией) и собранный им код непредсказуемо глючил. Демотивирует ожидание того, что угробишь время на выяснения глюков компилятора.
Кстати, автор пишет какой версией SDCC у него гарантировано собирался работоспособный код fuzix?
---------- Post added at 17:41 ---------- Previous post was at 17:09 ----------
Вот отсюда (https://github.com/EtchedPixels/FUZIX/blob/master/Kernel/README).
Маппер от Z180. Т.е. это не тот маппер, под который текущие искодники fuzix? Как понять?
Error404, какие компиляторы, люди, вы о чём вообще?? под спектрум на можно писать только на чистом асме, да и то возможности на уровне плинтуса.
чем вас не устраивает встроенный в ПЗУ родной интерпретатор бэйсика? :)
или очень охота вывернуться, чтобы в итоге получить то же консольное окно с теми же функциями? :)
это не для тех компьютеров.
Error404
03.11.2014, 20:21
или очень охота вывернуться, чтобы в итоге получить то же консольное окно с теми же функциями? :)
так да, об этом и речь.
или очень охота вывернуться, чтобы в итоге получить то же консольное окно с теми же функциями? :)
это не для тех компьютеров.
Юникс может дать
1) Совместимость всех существующих дискетных форматов. TR-DOS <-> CP/M <-> IS-DOS <-> whatever. Причем универсальным образом, а не в виде очередного коммандера. mount то, mount сё, cp, готово.
2) Совместимость с POSIX-ным софтом, которого тьма.
3) Эмуляция CP/M (не шутка, она в верхних строчках TODO листа Алана) - это тоже тьма софта.
4) Совместимость на уровне исходников с другими z80-based компьютерами, поддерживающими fuzix.
На реальном zx это всё без толку, слишком медленно и слишком мало памяти. Но на FPGA-клонах это же безграничные возможности открываются.
К тому же это ж, блин, Алан Кокс. Я уже два дня проснувшись сразу иду в эту тему, чтоб проверить, не приснилось ли мне. Торвалдс, Кокс и Столлмен в мире Linux - это как Синклер, Альтвассер и Викерс мира ZX. В голове до сих пор не укладывается. Если у него в голове есть замысел архитектуры ОС, значит можно заранее быть уверенным, что это не туфта, а что-то продуманное. А раз он уже занимается этим полгода и всё ещё не бросил - значит велика вероятность, что доведет до конца.
---------- Post added at 00:42 ---------- Previous post was at 00:41 ----------
Кстати, автор пишет какой версией SDCC у него гарантировано собирался работоспособный код fuzix?[COLOR="Silver"]
Ниже 3.4 вообще никакой не собирает, валится.
s_kosorev
03.11.2014, 22:42
Да, допустим что-то там им собирается. SDCC и у меня собирал тот же код, что и Hitech C, причем делал бинарь в полтора раза больше чем Hitech (уже после всех танцев с бубном с оптимизацией) и собранный им код непредсказуемо глючил.
Интересный поворот, а можно одним глазком на такой исходник посмотреть?
Маппер от Z180. Т.е. это не тот маппер, под который текущие искодники fuzix? Как понять?
Этот README - это сборник README всех проектов, части которых использованы в fuzix. z180 не поддержан вообще, потому что под него нет свободного компилятора, как я понимаю.
NovaStorm
03.11.2014, 23:55
Юникс может дать
1) Совместимость всех существующих дискетных форматов. TR-DOS <-> CP/M <-> IS-DOS <-> whatever. Причем универсальным образом, а не в виде очередного коммандера. mount то, mount сё, cp, готово.
Неа. Слишком разные ФС. А Hobeta - это нифига не универсально и не прозрачно.
2) Совместимость с POSIX-ным софтом, которого тьма.
В 64к адресном пространстве даже coreutils не заработает =)
На реальном zx это всё без толку, слишком медленно и слишком мало памяти.
Если делать posix систему - да, но если обгрызть и оставить только минимум, а писать на асме, я верю, что-то сделать можно и на 128к. Есть же RTOS на 8мибитках по 20к.
Но на FPGA-клонах это же безграничные возможности открываются.
Ага, например прошить что-то помощнее z80. А если мы уж в него рогом упёрлись, то гораздо проще(а может и эффективнее) будет сгородить поверх него мааасенькую вм с виртуальной памятью с адресом в 32 бита шириной.
Неа. Слишком разные ФС. А Hobeta - это нифига не универсально и не прозрачно.
А jffs и ntfs - это очень похожие ФС? Но mount-mount-cp почему-то работает.
Ага, например прошить что-то помощнее z80. А если мы уж в него рогом упёрлись, то гораздо проще(а может и эффективнее) будет сгородить поверх него мааасенькую вм с виртуальной памятью с адресом в 32 бита шириной.
А компилятор под это дело кто писать будет?
NovaStorm
04.11.2014, 11:18
А jffs и ntfs - это очень похожие ФС?
Гораздо более похожие чем TRDOS и CP/M, даже NTFS'ные ACL в линуксе можно использовать.
А компилятор под это дело кто писать будет?
Если оно будет нужно, то компилятор для плоской модели памяти написать будет всё-таки проще. Для AVR'ки вообще ARM сэмулировали полностью. Хотя вот думаю - 32 бит адрес, 32 бит арифметика, щёлканье страницами... Это будет конечно быстрее эмуляции полной системы, но тоже не особо хорошо. Остаётся только ручками =\
Может кому будет интересно
ммu от z180 есть,
http://opencores.org/project,mmu180
но вот толку от него не много, переключаем банки с грэйдом 4k,
есть компилятор С, который может использовать более 64к, https://www.google.ru/url?sa=t&rct=j&q=&esrc=s&source=web&cd=2&cad=rja&uact=8&ved=0CCQQFjAB&url=http%3A%2F%2Fwww.zilog.com%2Fforce_download.ph p%3Ffilepath%3DYUhSMGNEb3ZMM2QzZHk1NmFXeHZaeTVqYjI wdlpHOWpjeTk2TVRnd0wzTnZablJ2YjJ4ekxuQmtaZz09&ei=CodYVI6zCcHaOJeVgbAE&usg=AFQjCNF2U2z78tfp3qtayRBf0wXpu_7Esg&sig2=1es8Q2Mh-uhdYVwE45n_IQ&bvm=bv.78677474,d.ZWU
платный вроде, таблетки не искал, к нему.
HD64180Z и Z180, вполне доступны и сейчас, у меня пара штук есть :),
в планах борда, под z80 и z180, пока в процессе "причесывания"
http://s020.radikal.ru/i709/1411/d6/39a90e23f42f.jpg
http://i079.radikal.ru/1411/3e/f7ae89c94806.jpg
для z180
есть бесплатный
Zilog ZDS
и не совсем
IAR
калькулятор ММU
http://z80cpu.eu/mirrors/www.vegeneering.com/z180_mmu_calculator/z180mmucalcv12.zip
Требует VB.
Error404
04.11.2014, 14:24
Интересный поворот, а можно одним глазком на такой исходник посмотреть?
В данном случае я описывал мой реальный опыт по портированию uIP (микро стек TCP/IP) на Орион. Сил хватило на сам стек и 2 приложения (httpd, telnet). Код который комипилировался Hitech C и работал, компилировался и SDCC, но не работал, точнее делал вид что работал (что надо выводить на экран - выводил), но где-то внутри движка сам TCP/IP в версии от SDCC не работал. Я не разбирался отчего так. Ну и размер бинаря был не в пользу SDCC примерно на 40-50%%.
---------- Post added at 14:19 ---------- Previous post was at 14:16 ----------
К тому же это ж, блин, Алан Кокс. Я уже два дня проснувшись сразу иду в эту тему, чтоб проверить, не приснилось ли мне. Торвалдс, Кокс и Столлмен в мире Linux - это как Синклер, Альтвассер и Викерс мира ZX. В голове до сих пор не укладывается. Если у него в голове есть замысел архитектуры ОС, значит можно заранее быть уверенным, что это не туфта, а что-то продуманное.
Собственно это пока главный и основной (чуть не написал - единственнный) плюс. Ибо это человек вокруг которого может сформироваться хотя и тощее и гиковатое, но коммунити. Как показывает тот же ZX-PK, без коммунити, на одиночках - ничего не развивается.
---------- Post added at 14:24 ---------- Previous post was at 14:19 ----------
Этот README - это сборник README всех проектов, части которых использованы в fuzix. z180 не поддержан вообще, потому что под него нет свободного компилятора, как я понимаю.
Просто, страничная адресация целыми страницами по 64к, и размещение в одной странице ядра, а в остальных - процессов, это как раз та архитектура, на которую я планировал переделывать UZIX, и которая хорошо аппаратно "ложится" но Орион. Но руки не дошли.
Зато у меня есть собранный мной из исходников UZIX приклад для формирования образов дисков (mkfs, ucp, fcsk) в виде Win32-ехешников. У них с UZI как я понимаю одна и таже ФС. Вот тот же Алан ХЗ как формирует диски. Он ядро выложил, а с чего это ядро запускать?, с какой ФС? Скомпилировать то его скомпилируем, а дальше крутитесь как хотите. :)
Максагор
04.11.2014, 18:47
это как раз та архитектура, на которую я планировал переделывать UZIX
Кстати, народ, никто не подскажет, есть еще где-нибудь в сети хоть какая-то инфа по UZIX (скриншоты, описалово, видео - наподобие того, что существует по OS SymbOS), кроме официального давно не обновлявшегося сайта http://uzix.sourceforge.net ??? А то даже статьи на Вики по сабжу нет...
Кстати, народ, никто не подскажет, есть еще где-нибудь в сети хоть какая-то инфа по UZIX (скриншоты, описалово, видео - наподобие того, что существует по OS SymbOS), кроме официального давно не обновлявшегося сайта http://uzix.sourceforge.net ??? А то даже статьи на Вики по сабжу нет...
Есть такая вещь
SUZI - Spectrum UNIX Z-80 Implementation
Проект портирования OS UZI(X) на платформу ZX-SPECTRUM.
На данный момент на основе ядра UZIX1.0 сделан программа-эмулятор (для системы DNA).
Для её запуска нужен ZX-Spectrum-256k (Пентагон)+CASH 32k+Nemo-IDE+небольшой lba-винт
(подключенный, как мастер и на нем должены быть записаны с самого начала(с сектора 0)
данные из файла-образа UZIX.hdd).
В архиве suzi.zip в образе дискеты DNA0459S.TRD версия эмулятора от января 2010 г. -
при работе ядра UZIX,обращения от ядра к дискете эмулятор перенаправляет на hdd(на нем
rootfs uzix) с помощью вызовов системы DNA.
Соответственно запускается ядро, загружается процес INIT,инициализируется, далее
загружается процесс LOGIN.
Можно залогиниться без пароля(набирать имя root,user или guest), и работать в стандартной
юниксовой консоли.При запуске программы top для обновления экрана нажимать пробел (потому
что таймер не работает), и монтировать другие диски нельзя.
Можно посмотреть в эмуляторе Unreal с настройками Пентагон-256 или выше,
cash=32K,в качестве образа hdd подключить файл UZIX.hdd , в качестве диска
для дисковода для А подключить DNA0459S.TRD.
В образе дискеты unix_emu.TRD - скриншоты при запуске разных программ UZIX
В каталоге 0_scr можно посмотреть скриншоты от более старой версии от августа 2009
(в формате стандартного спектрумовского экрана).Ошибки возникали в результате ручного
вмешательства)
Так же вместо LOGIN вручную (через отладчик) загружался процесс BOGOMIPS, но он
скорость он не показывает, точнее показывает 0.000, возможно потому, что таймер не
срабатывает, либо округление при печати только до 4-х знаков.
http://zx-matrix.nm.ru/SUZI/suzi.txt
http://zx-matrix.nm.ru/SUZI/suzi.zip
http://dl.dropboxusercontent.com/u/20289147/zx/fuzix1_t.png (http://dl.dropboxusercontent.com/u/20289147/zx/fuzix1.png)
CityAceE
09.11.2014, 03:56
Eltaron, круто! Как удалось?
Eltaron, круто! Как удалось?
Реализовал примитивы, через которые работает виртуальный терминал, плюс раскидал код вокруг экрана. Нижние 16 кб сидят в ПЗУ вместо BASIC128, верхняя часть грузится откуда-нибудь (пока что грузится из ниоткуда через хак эмулятора)
Свободной памяти осталось 6 килобайт, так что 48к-совместимость отметается. А в 128 можно класть пользовательский софт в верхнюю страницу памяти, так что 5 программ по 16 килобайт сделать можно.
гы. а процедуру вывода на печать на экране спектрума ты сам писал? :)
Или 10 по 8! ;)
Это сложнее, придётся таблицу релокейшенов хранить. Да и куда нам 10, всю жизнь 1 процесса хватало :)
---------- Post added at 12:03 ---------- Previous post was at 12:01 ----------
гы. а процедуру вывода на печать на экране спектрума ты сам писал? :)
Ну да. А шрифт 8x8 в fuzix уже был.
Реализовал примитивы, через которые работает виртуальный терминал...
Дружищще, а не научишь как это всё в SDCC скомпилить, и куда драйвер экрана прикручивать?
Дружищще, а не научишь как это всё в SDCC скомпилить, и куда драйвер экрана прикручивать?
Вот сорцы https://github.com/atsidaev/FUZIX/tree/zx128-clean
Со сборкой беда, под линуксом собирается, вот виндой под cygwin не хочет. Не разбирался, в чём дело, может быть, что это просто лечится.
Для сборки нужен sdcc 3.4. В Makefile меняешь платформу на zx128, make, готово.
---------- Post added at 16:27 ---------- Previous post was at 15:09 ----------
Алан принял pull request, так что теперь сорцы есть и в апстриме
http://github.com/EtchedPixels/FUZIX/
Error404
13.11.2014, 19:53
Часто вижу у автора такой код:
int lpr_open(uint8_t minor, uint16_t flag)
{
minor; flag; // shut up compiler
udata.u_error = ENODEV;
return (-1);
}
Не понятно что это за шиза? ANSI такое позволяет?
Не понятно что это за шиза? ANSI такое позволяет?
minor; flag; // shut up compiler
Это для того, чтобы sdcc не выдавал "Warning : var not used".
Error404
13.11.2014, 23:20
minor; flag; // shut up compiler
Это для того, чтобы sdcc не выдавал "Warning : var not used".
Ну, я как-то так и предполагал.
Интересно во что это компилируется. :)
Конечно, не настолько интересно, чтобы ставить SDCC.
По теме, портирование автором описано, но как-то странно: очевидные вещи, типа нижнего уровня доступа к блочным девайсам (примитивные подпрограммы, которые можно взять от Uzix практически один в один, благо в Uzix вся аппаратнозависимая часть изолирована, более скоромная по количеству кода кстати) - разжеваны, а то что уникальное он сам там насочинял, типа менеджеров памяти (коих там распланировано аж 5 штук, видимо чтобы нескучно было разбираться) - с пятого на десятое, надо лезть в код. За это ему жирный минус. Будем ждать имплементацию TCP/IP, только это перевесит. Делать еще один "хело ворлд" в виде ядра, нет сил. :)
minor; flag; // shut up compiler
Это для того, чтобы sdcc не выдавал "Warning : var not used".
А зачем автор так делает?
Я понимаю, когда я пишу функцию на асме, я не могу в ней использовать имена аргументов, поэтому упоминаю их таким образом перед ассемблерным блоком. А здесь же он умышленно написал функцию, не использующую ни один своих аргументов.
Предполагаю, это фейковая функция - затычка.
---------- Post added at 10:18 ---------- Previous post was at 10:11 ----------
Ну, я как-то так и предполагал.
Интересно во что это компилируется. :)
Ни во что не компилируется.
А здесь же он умышленно написал функцию, не использующую ни один своих аргументов.
Да,
просто реализацию функции он ещё не написал.
Другое дело, что вероятно было-бы более разумно в sdcc,
чтобы можно было выключить этот Warning, как-то через pragma.
И не добавлять в код, "пустые" по смыслу строки, но пока - вот так только.
Ни во что не компилируется.
Подтверждаю.
Другое дело, что вероятно было-бы более разумно в sdcc,
чтобы можно было выключить этот Warning, как-то через pragma.
В качестве информации: в SDCC любое предупреждение можно отключить.
--disable-warning <nnnn> Disable specific warning with number <nnnn>
В качестве информации: в SDCC любое предупреждение можно отключить.
--disable-warning <nnnn> Disable specific warning with number <nnnn>
Там ещё 6502 и 6509, так что нужно кроссплатформенное решение
Короче, захотел я собрать..
SDCC : mcs51/z80/z180/r2k/r3ka/gbz80/tlcs90/ds390/pic16/pic14/TININative/ds400/hc08/s08/stm8 3.4.1 #9108 (Nov 16 2014) (Linux)
А оно как сругается!
sdcc -c --std-sdcc99 --no-std-crt0 -mz80 -I/home/salex/work-zx/FUZIX/Kernel/cpu-z80 -I/home/salex/work-zx/FUZIX/Kernel/platform-zx128 -I/home/salex/work-zx/FUZIX/Kernel/include --max-allocs-per-node 30000 --opt-code-size --Werror --stack-auto --constseg CONST --codeseg CODE2 syscall_proc.c
Internal error: validateLink failed in SPEC_NOUN(type) @ SDCCcse.c:1667: expected SPECIFIER, got DECLARATOR
Makefile:125: ошибка выполнения рецепта для цели <<syscall_proc.rel>>
make: *** [syscall_proc.rel] Ошибка 1
Как жить с этим?! Как побороть?
Хочу в итоге на Пентеве FUZIX. При её 4Мб можно не ограничиваться 5 задачами) даже есть по 16 кб на задачу - то 128 влезет)
s_kosorev
16.11.2014, 23:41
К примеру взять релиз а не ночную сборку
К примеру взять релиз а не ночную сборку
Именно
https://github.com/EtchedPixels/FUZIX/issues/10
---------- Post added at 02:09 ---------- Previous post was at 02:03 ----------
Хочу в итоге на Пентеве FUZIX. При её 4Мб можно не ограничиваться 5 задачами) даже есть по 16 кб на задачу - то 128 влезет)
На пентеве же крутой банкинг, как я понимаю, можно в любую банку включать что угодно. Поэтому под задачу можно исхитриться выделить 60 с лишним килобайт - всю память за вычетом лишь udata, стека и таблицы рестартов и прерываний.
Банкинг, конечно "крутой" в том смысле, что "любая страница в любое окно".
Но окна - всёж по 16К. Потому, чтобы избежать копирования - лучше 16/32/48К на задачу.
попробую релиз SDCC 3.4.0-rc3
В принципе - задача-минимум сделать загрузчик для Pentevo и менеджер памяти для неё же. Пока, для совместимости с 128мым пусть одно приложение будет не более 16 К.
Вдруг получится:)
Скомпилировать получилось.
Создал отдельную платформу для zxpentevo.
Что плохо - пути к библиотекам SDCC прибыты гвоздями. Прилагаю скрипт, который умеет спрашивать у SDCC пути к инклюдам и либам и выводить их в поток стандартного вывода.
Вечером, я надеюсь, буду пробовать запилить на живой пентеве загрузчик.
Что плохо - пути к библиотекам SDCC прибыты гвоздями. Прилагаю скрипт, который умеет спрашивать у SDCC пути к инклюдам и либам и выводить их в поток стандартного вывода.
Запуши лучше Алану. Надо пользоваться тем, что у проекта есть живой мейнтейнер.
Или хотя бы в комменты к http://github.com/EtchedPixels/FUZIX/pull/4
Хотя один фиг для этого тоже надо на гитхабе регаться :)
---------- Post added at 12:56 ---------- Previous post was at 12:52 ----------
Но окна - всёж по 16К. Потому, чтобы избежать копирования - лучше 16/32/48К на задачу.
Всё копирование будет сводиться к переброске 256 байт udata. Счас все платформы через такой LDIR и работают.
Хотя я не знаю, как на пентеве переключается экран. Если он "прибит" к текущей банке в #4000, то его тоже надо копировать, а это уже да, не круто.
Идеальный вариант, наверное - это переключить экран на #C000 (если возможно в ATM-режиме) и щелкать только нижними тремя страницами. Тогда копирование сведется к однократному копированию таблицы векторов при старте нового процесса.
Error404
17.11.2014, 14:23
Но окна - всёж по 16К. Потому, чтобы избежать копирования - лучше 16/32/48К на задачу.
Всё копирование будет сводиться к переброске 256 байт udata. Счас все платформы через такой LDIR и работают.
Хотя я не знаю, как на пентеве переключается экран. Если он "прибит" к текущей банке в #4000, то его тоже надо копировать, а это уже да, не круто.
Идеальный вариант, наверное - это переключить экран на #C000 (если возможно в ATM-режиме) и щелкать только нижними тремя страницами. Тогда копирование сведется к однократному копированию таблицы векторов при старте нового процесса.
Прошу прощенья за пионерские вопросы - где в исходниках описываются аппаратные диспетчеры памяти? Осмотр "по диагонали" выявил только какие-то абстракции на тему простейшего управления памятью страничками по 4к. Как-то всё неочевидно, покрайней мере для непрограммиста - не просматривается прямая корреляция между аппаратными диспетчерами и дефайнами, которые там Алан сочинил и типа описал.
Всё копирование будет сводиться к переброске 256 байт udata. Счас все платформы через такой LDIR и работают.
Вай-вай, дорогой, - зачем какой-то "лдир-шмир", когда есть ПДП 143кб/фрейм.
:)
Хотя я не знаю, как на пентеве переключается экран. Если он "прибит" к текущей банке в #4000, то его тоже надо копировать, а это уже да, не круто.
На пентеве можно юзать расширенную графику, доступ к которой можно организовать через любое окно CPU, или блоками пересылать туда из основной памяти с помощью ПДП.
Прошу прощенья за пионерские вопросы - где в исходниках описываются аппаратные диспетчеры памяти? Осмотр "по диагонали" выявил только какие-то абстракции на тему простейшего управления памятью страничками по 4к. Как-то всё неочевидно, покрайней мере для непрограммиста - не просматривается прямая корреляция между аппаратными диспетчерами и дефайнами, которые там Алан сочинил и типа описал.
Те диспетчеры, которые bank16, bankfixed - они занимаются только выделением свободной страницы создаваемому процессу. И даже не самой страницы, а её номера. Тупо отслеживают, что занято, а что нет, больше ничего не делают.
А код, переключающий задачи (=переключающий страницы) платформно-специфичен и вынесены в ассемблерные файлы.
Это, по-сути, пять функций:
switchout - выполняется после того, как у процесса отбирается процессорное время.
swithin - выполняется перед тем как процессу выдается процессорное время
map_kernel - вернуть маппинг ядра
map_process - подключить страницы, занятые указанным процессом
do_fork - создать копию текущего процесса
От их реализации и зависит всё поведение системы.
---------- Post added at 17:02 ---------- Previous post was at 16:59 ----------
На пентеве можно юзать расширенную графику, доступ к которой можно организовать через любое окно CPU, или блоками пересылать туда из основной памяти с помощью ПДП.
Ну тогда дело за малым.
Error404
17.11.2014, 15:16
Те диспетчеры, которые bank16, bankfixed - они занимаются только выделением свободной страницы создаваемому процессу. И даже не самой страницы, а её номера. Тупо отслеживают, что занято, а что нет, больше ничего не делают.
Я потерялся в поиске примера где в коде Алана используется архитектура вот с этой картинки:
First 64k Subsequent 64k banks
FFFF +------------+ +------------+
Common | Common | | Task Store |+
F000 +------------+ +------------+|+
| | | |+|+
| Kernel | | Process ||+|
Banked | Code | | Code |||+
| | | & Data ||||
| | | ||||
0100 +------------+ +------------+|||
| Reserved | | Reserved |+||
0000 +------------+ +------------+|+|
+------------+|+
+------------+|
Т.е. именно как оно (в каких функциях) использует диспетчер по 64к (он же 60к) для доступа к данным в другие страницы. В моем представлении это должны бы быть какие-то ассемблерные вставки, чтоли...
А код, переключающий задачи (=переключающий страницы) платформно-специфичен и вынесены в ассемблерные файлы.
Это, по-сути, пять функций:
switchout - выполняется после того, как у процесса отбирается процессорное время.
swithin - выполняется перед тем как процессу выдается процессорное время
map_kernel - вернуть маппинг ядра
map_process - подключить страницы, занятые указанным процессом
do_fork - создать копию текущего процесса
От их реализации и зависит всё поведение системы.
C этим более-менее понятно. Аналогично было и на UZIX, только функции по-другому назывались. Для UZIX эти модули я вчерне уже начинал писать, тогда не хватило упорства победить компилятор (это самая засада в программировании для Z80 на C).
Запуши лучше Алану. Надо пользоваться тем, что у проекта есть живой мейнтейнер.
Или хотя бы в комменты к http://github.com/EtchedPixels/FUZIX/pull/4
Хотя один фиг для этого тоже надо на гитхабе регаться :)[COLOR="Silver"]
Попробую.
---------- Post added at 12:56 ---------- Previous post was at 12:52 ----------
Хотя я не знаю, как на пентеве переключается экран. Если он "прибит" к текущей банке в #4000, то его тоже надо копировать, а это уже да, не круто.
Идеальный вариант, наверное - это переключить экран на #C000 (если возможно в ATM-режиме) и щелкать только нижними тремя страницами. Тогда копирование сведется к однократному копированию таблицы векторов при старте нового процесса.
Если я начну всё и сразу делать - то точно нифуя не получится.
Сначала - загрузчик. Как загрузчик заработает и на консоль будет пукать, что ОС загрузилась - можно о чёмто другом говорить.
Наполеоновские планы обычно кончаются маниловскими делами...
Т.е. именно как оно (в каких функциях) использует диспетчер по 64к (он же 60к) для доступа к данным в другие страницы. В моем представлении это должны бы быть какие-то ассемблерные вставки, чтоли...
Не, это не менеджер памяти в таком понимании. В fuzix каждый процесс фиксирован и за пределы 64к выходить не может - соответственно, никакого доступа к данным в других страницах нет.
Единственное исключение - вызов функций ядра через RST 30H (syscall). В этом случае процесс обращается к ядру, которое может быть расположено в других банках памяти. Это специфический случай и ради него те пять функций и сделаны.
---------- Post added at 17:40 ---------- Previous post was at 17:34 ----------
Если я начну всё и сразу делать - то точно нифуя не получится.
Сначала - загрузчик. Как загрузчик заработает и на консоль будет пукать, что ОС загрузилась - можно о чёмто другом говорить.
Естественно. К тому же драйвер ВГ93 и для zx128 пригодится. У меня счас упрощенный вариант, работающий через хаки эмулятора. Бьюсь над тем, чтобы заставить грузиться init.
Бьюсь над тем, чтобы заставить грузиться init.
Не забывай постить скриншоты и видео! Интересно же. ;)
что такое за команды out (21) ?
вроде такого порта в 128 спеке нет?
---------- Post added at 22:44 ---------- Previous post was at 22:40 ----------
Насколько я помню - в спеке 128 память так распределена:
Окно 0 - ПЗУ
Окно 1 - стр 5
ОКНО 2 - стр 2
Окно 3 - СТР 0..7
Где в ядре указано, что стр. 5 и 2 - заняты под ядро? В каком файле?
что такое за команды out (21) ?
вроде такого порта в 128 спеке нет?
Если ты про lowlevel-z80, то это Алан сегодня какую-то отладочную хрень закоммитил. #21 и #1 - это порты маппера и терминала на z80pack, но не помню, какой чей :)
А если про zx128, то там все эти команды или закомментированы, или в начале функции ret стоит.
Где в ядре указано, что стр. 5 и 2 - заняты под ядро? В каком файле?
В zx128? Я там маппинг ещё не дописал. А так это должно быть в функции pagemap_init. Для страниц 2 и 5 не должна вызываться pagemap_add.
Не забывай постить скриншоты и видео! Интересно же. ;)
Да там немногое изменилось-то :)
http://dl.dropboxusercontent.com/u/20289147/zx/fuzux_2.png
Ещё чуток вопросов.
sdldz80 -n -k /usr/share/sdcc/lib/z80 -k /home/salex/apps-zx/sdcc/bin/../share/sdcc/lib/z80 -k /home/salex/apps-zx/sdcc/share/sdcc/lib/z80 -f platform-zx128/uzi.lnk
tools/analysemap <uzi.map
Code1: 15764 bytes
Code2: 16081 bytes
Code: 31845 bytes
Data: 2992 bytes
BSS: 0 bytes
Initialized: 5387 bytes
Free memory begins at: c817
Common is at: f000
Space: 10217 bytes
Work room: 4830 bytes
cp hogs.txt hogs.txt.old
tools/memhogs <uzi.map |sort -nr >hogs.txt
head -5 hogs.txt
7611: _memcpy
1663: __execve
1062: _writei
996: _readi
951: _tty_inproc
makebin -s 65536 -p uzi.ihx >uzi.tmp
tools/binman uzi.tmp uzi.map fuzix.bin
Code at 0x0000 (15764 bytes)
Code2 at 0x5b00 (16081 bytes)
Const at 0xa142 (538 bytes)
Data at 0xa75c (8379 bytes)
Common at 0xf000 (2492 bytes)
Font at 0xa35c (1024 bytes)
Video at 0x99d1 (1024 bytes)
Discard at 0x9dd1 (881 bytes)
End at 0xfdbc
1. У тебя в комментах написано, что ты снёс вё ядро ниже 0xC000. Что для 128К и нужно. Common at 0xf000 (2492 bytes) - это выше 0xC000. Так и надо?
2. Какая страница должна быть впечатана в окно 4 при инициализации ядра?
3. Задача загрузчика - просто включить RAM в 0x0000 - 0xFFFF, поместить бинарь с адреса 0x0000 и сделать jp 0x0000 ? Или через регистры какието параметры ядру передаются?
Eltaron, ты не закоммитил platform-zx128/devfd.h
без него ветка мастер не компилится.
У тебя свой репозиторий на https://github.com/atsidaev, как я понимаю?
Может создадим там же отдельную ветку для пентевы, а ты в мастер будешь сливать по своему усмотрению?
Я уже прикинул, что надо отделять конфиг от мэйкфайла. плюс скрипты и platform-zxpentevo.
1. У тебя в комментах написано, что ты снёс вё ядро ниже 0xC000. Что для 128К и нужно. Common at 0xf000 (2492 bytes) - это выше 0xC000. Так и надо?
Не, чуть не так.
Ядро занимает всё пространство 0000-FFFF за вычетом экрана. При создании нового процесса, ему выделяется очередная страница верхней памяти, которая подключается в C000 (заменяя собой страницу ядра), туда кладется бинарник процесса и запускается. Никаких проблем из-за того, что кусок ядра недоступен нет, потому что все вызовы ядра процесс выполняет через RST 30. Первое, что делает RST 30 - это возвращает в C000 страницу ядра. Потом он отрабатывает вызов, возвращает страницу процесса обратно и передает управление обратно процессу.
Common - это кусок памяти, общий для всех процессов и ядра. В z80pack это верхние 4 килобайта. Они не меняются при переключении банок, отсюда и название. У нас же наоборот, не меняются данные ниже C000, поэтому common нужно опускать туда. В своей ветке я это уже начал, но для полноценной отладки надо сначала научиться запускать процессы.
2. Какая страница должна быть впечатана в окно 4 при инициализации ядра?
Нулевая. 0 - страница ядра, 5,2 - страницы нижней RAM. Для процессов остаются 1, 3, 4, 6, 7.
3. Задача загрузчика - просто включить RAM в 0x0000 - 0xFFFF, поместить бинарь с адреса 0x0000 и сделать jp 0x0000 ?
Да.
Или через регистры какието параметры ядру передаются?
Как-то можно передавать, но я это ещё не копал. Можно передать устройство загрузки, например, чтобы не вводить каждый раз его с клавы.
---------- Post added at 14:03 ---------- Previous post was at 13:54 ----------
Eltaron, ты не закоммитил platform-zx128/devfd.h
без него ветка мастер не компилится.
У тебя свой репозиторий на https://github.com/atsidaev, как я понимаю?
Закоммитил файлик. Но от моего репозитория без моего хаканного эмулятора толку мало - там всё через этакий наколеночный DMA работает. Просто хочу сначала отладить переключение процессов, а загрузчиками и дровами заниматься потом.
Может создадим там же отдельную ветку для пентевы, а ты в мастер будешь сливать по своему усмотрению?
Я уже прикинул, что надо отделять конфиг от мэйкфайла. плюс скрипты и platform-zxpentevo.
Я могу создать ветку, но ты не сможешь в неё коммитить. Гитхаб не так работает. Тут все коммиты в чужие репозитории осуществляются как pull request'ы. Это когда форкаешь чужое репо, коммитишь в него изменения, а потом создаешь pull request - просьбу свои изменения включить в основной репозиторий. Можешь меня форкнуть, можешь сразу Кокса.
Спасибо.
Я с гитхабом не работал. Зарегистрировался - буду разбираться по мере.
Как сделаю, что на пентеве в режиме 128 запустится ядро - так и форкну:)
Сейчас пилю загрузку по RS232. На скорости 115200 - это всего 5 сек и не надо с флешкой морочится. Для отладки удобно.
Может создадим там же отдельную ветку для пентевы...
Если для Пентевы делать - тогда раскладку памяти другую надо:
Не нужна эта "дырка" в 6,75кб под спектрумовский экран. Нужно обеспечить "безболезненное" включение в какое-нибудь окно страниц экранной области, чтобы процесс мог туда быстро напрямую писать/читать.
Как вариант, в верхней памяти зарезервировать фиксированное место для размещения подпрограмм "рисования", тогда они могут, хоть все 3 остальных окна использовать. Либо автор программы на этапе сборки определит сколько и с какого адреса ему нужна память в 3-м окне.
Можно даже свободно пользоваться TR-DOS при необходимости.
Если для Пентевы делать - тогда раскладку памяти другую надо:
Не нужна эта "дырка" в 6,75кб под спектрумовский экран. Нужно обеспечить "безболезненное" включение в какое-нибудь окно страниц экранной области, чтобы процесс мог туда быстро напрямую писать/читать.
Как вариант, в верхней памяти зарезервировать фиксированное место для размещения подпрограмм "рисования", тогда они могут, хоть все 3 остальных окна использовать. Либо автор программы на этапе сборки определит сколько и с какого адреса ему нужна память в 3-м окне.
Можно даже свободно пользоваться TR-DOS при необходимости.
Я сначала хочу запустить хоть в режиме 128. А там уж "будем пилить.
Сейчас пилю загрузку по RS232. На скорости 115200 - это всего 5 сек и не надо с флешкой морочится. Для отладки удобно.
Тогда и виртуальный дисковод тоже можно через RS232 запилить.
Error404
18.11.2014, 17:59
Не нужна эта "дырка" в 6,75кб под спектрумовский экран. Нужно обеспечить "безболезненное" включение в какое-нибудь окно страниц экранной области, чтобы процесс мог туда быстро напрямую писать/читать.
Тока это не юникс уже будет. В Юниксе для записи в экранную область процессы используют функцию putchar/putc. :) И даже через либы они туда не пишут напрямую, а все заруливается через ядро.
Задачка на воображение: два процесса выполняются и оба параллельно лезут в экран. Что будет на экране? Даже не беря во внимание что все это происходит по прерыванию (и они переписывают порт считать который нельзя, т.е. состояние порта будет не детерменировано).
Тока это не юникс уже будет. В Юниксе для записи в экранную область процессы используют функцию putchar/putc. :) И даже через либы они туда не пишут напрямую, а все заруливается через ядро.
Слой абстракции в графике - это лишнее. И так всё еле ползать будет :)
Нам нужно что-то вроде фреймбуффера, куда пишут как раз напрямую. Даже фреймбуффер слишком сложно. Нам тупо нужен мьютекс, захватив который, процесс получает эксклюзивное право писать в экран.
Но т.к. мьютексов в фузихе ещё нету, то о графике думать вообще рано :)
Слой абстракции в графике - это лишнее. И так всё еле ползать будет :)
На пентеве есть аппаратный текстмод, так что хотя бы скорость самого вывода на экран не пострадает. Но для тектмода, всё равно, надо будет паги врубать в какое-нибудь окно. Хотя системе-то можно всё! :)
Запустилось на реальной пентеве!
Карту памяти такую сварганил:
win0 - page7
win1 - page5
win2 - page2
win3 - page0
---------- Post added at 23:27 ---------- Previous post was at 23:25 ----------
Тогда и виртуальный дисковод тоже можно через RS232 запилить.
Да нет. Я за поддержку реальной флеши и трдос-образин.
Просто для отладки, чтобы флешку не дрюкать - сварганил простеннькую прогу.
ну теперь можно дальше мучать!
---------- Post added at 23:29 ---------- Previous post was at 23:27 ----------
Тока это не юникс уже будет. В Юниксе для записи в экранную область процессы используют функцию putchar/putc. :) И даже через либы они туда не пишут напрямую, а все заруливается через ядро.
Задачка на воображение: два процесса выполняются и оба параллельно лезут в экран. Что будет на экране? Даже не беря во внимание что все это происходит по прерыванию (и они переписывают порт считать который нельзя, т.е. состояние порта будет не детерменировано).
Юниксоиды, млин... Да можно в юниксе напрямую с видеопамятью работать. фреймбуфер мемапнул - и привет. Пиши как хочешь.
Если, конечно, права имеешь)
Да нет. Я за поддержку реальной флеши и трдос-образин.
Большую флэш пока не потянет - максимальный объем накопителя = 65536 блоков по 512 байт = 32 мегабайта.
Но ничто не мешает накопители монтировать один к другому.
Error404
19.11.2014, 00:58
Юниксоиды, млин... Да можно в юниксе напрямую с видеопамятью работать. фреймбуфер мемапнул - и привет. Пиши как хочешь.
Если, конечно, права имеешь)
Не пишите "как хочешь", пишите как принято. :)
Может это и не очевидно, но написанное "как хочешь" потом все одно придется переделывать, собственно это и зацепило напоспорить. Если хочется графики, можно использовать, например, 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-и ядро будет еще в пару раз медленнее.
Ура, смог загрузить init. Ну, не настоящий init, а пример /Applications/ASM/init.s. Но процессы создаются и смена банок ядро<->процесс вроде бы отрабатывает корректно.
Образ дискеты (init + /dev/tty0) в аттаче на всякий случай.
Мне в этом свете не понятно зачем в TODO у Алана числится допиливание ФС uzi до 32битных inod-ов, учитывая что обрабатывать long-и ядро будет еще в пару раз медленнее.
Ну, это ж наши трехмегагерцовые проблемы. А для T80 падение скорости будет не очень заметно.
Но процессы создаются и смена банок ядро<->процесс вроде бы отрабатывает корректно.
Образ дискеты (init + /dev/tty0) в аттаче на всякий случай.
А какая там файловая система?
Я так понял, что ты вместо ТРД-образа чтото подсунул.
Я подумал - наверное и вправду на первых порах впилю виртуальный диск по RS232.
там функций то всего две - запись блока, чтение блока.
1. Какая ФС используется в FUZIX?
2. Какими утилитами можно создать образ этой ФС и записать на неё файлы?
Я думал, что тот образ, что ты приложил - UZIXовый, но UZIXовые утилиты его не поняли.
Я подумал - наверное и вправду на первых порах впилю виртуальный диск по RS232.
там функций то всего две - запись блока, чтение блока.
Предлагаю образ FUSIX хранить на TRDOS-дискете с 01 дорожки. 0-я дорожка стандартная, и пусть содержит единственный файл "boot" с загрузчиком. Так для эмулей, да и для реала удобней будет.
2. Какими утилитами можно создать образ этой ФС и записать на неё файлы?
Если знать формат, думаю смогу на REXX написать. :)
Кстати, неплохо было бы ассемблерные файлы просмотреть на предмет оптимизации - можно больше места под процессы выделить
Предлагаю образ FUSIX хранить на TRDOS-дискете с 01 дорожки. 0-я дорожка стандартная, и пусть содержит единственный файл "boot" с загрузчиком. Так для эмулей, да и для реала удобней будет.
Это не проблема.
Если знать формат, думаю смогу на REXX написать. :)
именно тип ФС я и спрашивал.
ИМХО, Раз Eltaron создал образ - то он знает тип ФС и у него есть утилиты..
Кстати, неплохо было бы ассемблерные файлы просмотреть на предмет оптимизации - можно больше места под процессы выделить
Там под процесс выделяется окно 16К. Оптимизация нужна скорее по скорости.
В принципе, на пентеве можно и 48 К на процесс выделять - три окна по 16К.
теоретически - ОС занимает 48К (три окна). Под процессы остаются 253 окна по 16 К.
То есть - или имеем 253 процеса по 16 К или 84 процесса по 48К.
И то и другое - более чем достаточно для сепктрума.
А какая там файловая система?
Я так понял, что ты вместо ТРД-образа чтото подсунул.
Да, от 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.
Моё видение из разряда пожеланий:
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/foca/UXU-1.0.tar.gz?download её не понимают?[COLOR="Silver"]
Тогда почему утилиты с сайта UZIX-утилиты
Без понятия. Собери свои, они в один make собираются.
Eltaron, пожалуйста, ткни меня носом, где я могу прописать, какие именно старницы памяти используются ядром.
Чтобы менеджер памяти их не пытался использовать.
Это в bank16.c или нет?
Нет, все эти bank*.c - это файлы операционки, их желательно не трогать. Вся работа в platform-*.
Вообще, bank16.c - это для архитектур, у которых 4 банки по 16 килобайт, и в которых любую страницу можно включать в любое окно. Поскольку банкомат именно так и работает, то со временем ты на bank16 код и переделаешь.
Но пока что используется bankfixed.c. Это архитектура, в которой процесс лежит весь полностью в одной банке, но размер самой банки не оговаривается. 16 кб, 60 кб - не важно, главное, что один процесс - одна страница. (Есть одно НО - предполагается, что банка включается с адреса 0. Я поправил для zx128, но Алан этот коммит не взял (https://github.com/atsidaev/FUZIX/commit/f0343a92021f6c5c9f9c94cf0cce876d28b6419f), т.к. ломает прочие архитектуры. Значит, придется делать свой банкинг в platform-zx128.)
Так вот, тыкаю носом:
Если посмотришь все эти bank*.c, увидишь, что они реализуют набор одних и тех же функций. pagemap_add, pagemap_free, pagemap_alloc, pagemap_realloc. Указание менеджеру памяти на то, какие страницы есть - это pagemap_add. Она вызывается из pagemap_init в platform-zx128/main.c. У меня сейчас, к примеру, задаются только две свободные банки - 1 и 3 (ссылка на код (http://github.com/atsidaev/FUZIX/blob/master/Kernel/platform-zx128/main.c#L10))
Да я уже разобрался, спасибо.
По-хорошему твой коммит нужен в основной ветке. Не все ж ахитектуры именно с адреса 0 банки переключают.
Для z80, кстати нелогично с 0 банку включать. Там же рядом вектора лежат.
Может просто в конфиге ядра какой символ предусмотреть? Если он не определён - компилить как раньше. Если определёно - то как в твоём коммите.
ничего не поломается, зато всё в одной ветке.
Для z80, кстати нелогично с 0 банку включать. Там же рядом вектора лежат.
Вектора копируются при создании нового процесса, там даже специальная функция для этого предусмотрена, _program_vectors. Мне больше интересно, как все эти архитектуры с RAM в самом низу умудряются грузиться? Им кто-то копирует код в ОЗУ при ресете?
Может просто в конфиге ядра какой символ предусмотреть? Если он не определён - компилить как раньше. Если определёно - то как в твоём коммите.
Да, я так и сделаю.
#define CONFIG_BANK_FIXED_START 0xC000, в таком духе
Вектора копируются при создании нового процесса, там даже специальная функция для этого предусмотрена, _program_vectors. Мне больше интересно, как все эти архитектуры с RAM в самом низу умудряются грузиться? Им кто-то копирует код в ОЗУ при ресете?
Копировние = лишние 256 байт занятого ОЗУ
Да так же грузятся, как я пентеву гружу... В момент включения с адреса 0 - ПЗУ. Потом всё копируется куда надо и переключается на ОЗУ.
Эта схема стандартная. Она и ARM и ещё много где.
---------- Post added at 17:49 ---------- Previous post was at 17:30 ----------
Eltaron
struct devsw dev_tab[] = /* The device driver switch table */
{
// minor open close read write ioctl
// -----------------------------------------------------------------
Мелкий косяк. Номер устройства в таблице - MAJOR, а не minor.
---------- Post added at 17:59 ---------- Previous post was at 17:49 ----------
Кстати, в структуре struct devsw вообще ни major ни minor не указан.
Это плохо.
Модульные драйвера в произвольных страницах сложнее сделать будет.
Error404
19.11.2014, 15:09
Сама ФС fuzix-овая стандартная. Она же UZIX-овая стандартная и (судя по словам Error404) UZI-ховая стандартная.
Тулзы для её создания лежат в /Standalone, собираются под хост.
Алан в бложике писал, что в fuzix он уже внес "усовершенствования" в ФС от UZI - например, увеличил длину имен файлов (вот зачем?). Насколько после этого сохранилась совместимость с утилитами от UZIX - ХЗ. Кстати, и в UZIX не в чистом виде ФС от UZI: разрабы UZIX писали что в классической UZI в коде ФС есть ошибки, иногда приводящие к крашу ФС, и они якобы их исправили (исправил ли их Алан?). Что там при этом поменялось - структура ФС (и соответственно совместимости с UZI нет) или только функции ядра (и совместимость с UZI осталась) не описывалось. Для UZIX я собирал утилиты для себя из исходников UZIX, для win32. Те что под Linux - не пробовал.
Мелкий косяк. Номер устройства в таблице - MAJOR, а не minor.
Да там вообще жесть. Добавил устройство в верх таблицы - переделывай всё вплоть до файловой системы. Зато скорость доступа растет, не надо всё таблицу оббегать.
Копировние = лишние 256 байт занятого ОЗУ
На фоне выигрыша в 16 килобайт? :)
И даже не 256, а 104. Выше NMI (0x66) ничего нет, ни векторов, ни рестартов.
Error404
19.11.2014, 15:27
Да там вообще жесть. Добавил устройство в верх таблицы - переделывай всё вплоть до файловой системы.
Почему? По uzix не припоминаю такого. Впрочем, не пробовал таблицу менять.
Почему? По uzix не припоминаю такого. Впрочем, не пробовал таблицу менять.
Потому что номер устройства в таблице - это его major. Скажем, я сначала выкинул всякие дисководы и параллельные порты, оставил один терминал. Терминал получил major = 0. Потом добавил дисковод в верх таблицы - дисковод стал 0, терминал стал 1.
И пошло-поехало. Дефайн BOOT_TTY поменяй, номер устройства у /dev/tty1 поменяй... Не то, чтобы это большая проблема была, но всё же.
Заколебался с менеджером памяти пентевы. Чтото я делаю не так.
Грузится, запускается - и потом рушится тут же. только стартовое сообщение и вижу.
А казалось бы - поменяй в паре мест 7FFD на порт пентевы и инвертируй биты...
А казалось бы - поменяй в паре мест 7FFD на порт пентевы и инвертируй биты...
Как и какие порты юзаешь? Архитектуру бэйзконфы не ведаю, зачем инвертировать биты? Скинь кусок этого менеджера подивиться.
Как и какие порты юзаешь? Архитектуру бэйзконфы не ведаю, зачем инвертировать биты? Скинь кусок этого менеджера подивиться.
Тут подробно. http://nedopc.com/zxevo/rom/zxevo_base_configuration.pdf
Просто я ещё не все фишки за 3 дня разборов с пентевной памятью просёк.
Там портов всяких... Как у дурака махорки...
Есть и режим пентагон1024 и АТМ и свой пентевовский. Две карты памяти, которые можно переключать и не дай бог это сделать, если в другой карте памяти в этом окне другая страница впечатана...
Причём влияние одних портов управления памяти на другие определяется третьими портами:)
Видеорежимов 7 штук.
Есть NMI - ловушка, срабатывающая по адресу..
В обещем - почти "воплощение всех мечт". А теперь я со всей этой хренью взлететь пробую:)
В общем я примерно идею как правильно сделать уяснил. теперь дело за малым - сделать:)
Там портов всяких... Как у дурака махорки...
Причём влияние одних портов управления памяти на другие определяется третьими портами:)
Это я в курсе. Дока-то есть и даже распечатана, но слишком слаб умом, чтобы вникнуть :)
Пиши не под BASE- , а под TS-Config! - там все очень просто:
порты 0x10af, 0x11af, 0x12af, 0x13af для окон 0, 1, 2, 3 соответственно. И доступны всегда без всяких фокусов. Пишешь туда номер паги, и всё!
Только для окна 0 есть нюансы связанные с мапом ПЗУ.
Регистры Page0-Page3. Номер страницы задается линейно 0-255. Для страниц ПЗУ используются только биты 4:0, биты 7:5 игнорируются.
Q: Что творится в в окне #0000, как использовать регистр MemConfig?
А: Отображаемая страница в окне #0000 задается в регистре Page0.
MemConfig указывает что и каким образом там отображать.
W0_RAM: что отображать - 0 - ПЗУ, 1 - ОЗУ
W0_WE: 0 - запись запрещена, 1 - разрешена. Для ПЗУ - это соответствующая ножка чипа EEPROM. Для ОЗУ - просто запрет записи. Нужно для правильной работы прошивки бейсика из ОЗУ, поскольку бейсик пишет в адреса ПЗУ и портит прошивку.
!W0_MAP: включает "маппинг" четвертинок ПЗУ в окне 0. При этом номер страницы образуется так: биты 7:2 (или 4:2 для ПЗУ) берутся из Page0, а биты 1:0 заменяются на то, что должно быть в окне 0 в зависимости от бита 4 из #7FFD и включенности TR-DOS:
00 Service
01 DOS
10 128
11 48
Это позволяет загрузить в ОЗУ прошивку ПЗУ (64кБ) и использовать например для отладки.
ROM128 - копия бита 4 из #7FFD.
Да и видео-режимы по-быстрее и по-удобней для кодинга.
ссылка на полный FAQ: http://forum.tslabs.info/viewtopic.php?f=35&t=157
ссылка на памятку по портам: https://zx-evo-fpga.googlecode.com/hg/pentevo/docs/TSconf/TSconf.xls
ссылка на эмулятор: http://zx-evo-fpga.googlecode.com/hg/pentevo/unreal/Unreal/bin/unreal.7z
Хотя, если под бэйз напишешь, тебе потом пожизни ничего страшно не будет :)
Error404
20.11.2014, 10:07
Хотя, если под бэйз напишешь, тебе потом пожизни ничего страшно не будет :)
Не, сектанты заклюют. :)
shurik-ua
20.11.2014, 11:17
Не, сектанты заклюют
Лучше буду летать на самолёте с тремя бассейнами ))
Написал.
Вот загрузчик. печатает всю информацию по памяти.
Работает в 3 банке ОЗУ.
Сам переносит себя в страницу 64,
Потом настраивает ОЗУ 0,5,2,64 на обоих картах.
Грузит из компорта файлы блоками по 16к. Первые 2 байта - длина файла, потом до 4 блоков по 16К.
Между блоками - нужны промежутки.
там скрипт для передачи файла прилагается.
После загрузки - переход по адресу 0.
Ealtron, а у тебя в githube рабочая версия лежит FUZIXа?
Я что-то смотрю - там какието закомментированные функции с retом вначале.
Или я ветку не ту гляжу?
Если inita нет, то он и должен никак не реагировать на клавиатуру?
Ealtron, а у тебя в githube рабочая версия лежит FUZIXа?
Я что-то смотрю - там какието закомментированные функции с retом вначале.
полурабочая - грузит и запускает псевдо-init из образа дискеты, что я выкладывал
init выводит строку Hello, world, потом di:halt
ret'ами забиты функции, отвечающие за многозадачность - её ещё нет.
Если inita нет, то он и должен никак не реагировать на клавиатуру?
Он у тебя запрашивает bootdev? Как тут (http://zx-pk.ru/showpost.php?p=752082&postcount=31)
У меня в этот момент клава работает, нужно ввести 0 и enter.
После этого пройдет ещё сколько-то сообщений, и будет panic: no /init
Потом настраивает ОЗУ 0,5,2,64 на обоих картах.
5-ю пагу с переменным бэйсика и трдоса лучше сохранять. ибо потом можешь врубать из верхней памяти пзу и 5-ю пагу и пользоваться тр-досом для загрузки.
NovaStorm
20.11.2014, 13:34
>5-ю пагу с переменным бэйсика и трдоса
А где взять карту памяти с этими переменными? Хочется знать, как много нужно сохранять чтобы иметь возможность читать/писать посекторно.
>5-ю пагу с переменным бэйсика и трдоса
А где взять карту памяти с этими переменными? Хочется знать, как много нужно сохранять чтобы иметь возможность читать/писать посекторно.
Не совсем понял вопрос.
К моменту загрузки фузикса эти переменные в 5-й паге созданы basic`ом и TR-DOS`ом. остаётся эту пагу убрать из адресного пространства и заменить любой другой. Врубить в окно №1 другую страницу, а эту не трогать.
в ней же и буферы для чтения/записи с дискеты держать.
P.S. речь идет о пентеве, - там любую пагу в любое окно можно включать
Вот так он выводит. Не совсем как у тебя.
Вот так он выводит. Не совсем как у тебя.
И на "bootdev:" не ждет? Странно
После последнего паника там di:halt, по-моему, клава не должна уже обрабатываться. Но в процессе загрузки есть часто-часто (автоповтора ещё нет) нажимать какую-нибудь кнопку, она пару раз на консоли проскочит.
И на "bootdev:" не ждет? Странно
После последнего паника там di:halt, по-моему, клава не должна уже обрабатываться. Но в процессе загрузки есть часто-часто (автоповтора ещё нет) нажимать какую-нибудь кнопку, она пару раз на консоли проскочит.
ну я ещё попробую - солью твой мастер, поправлю порты и запущу. там всего то пара мест.
NovaStorm
20.11.2014, 20:20
Не совсем понял вопрос.
Я хочу писать/читать сектора на BDI так, чтобы использовать на это минимум памяти. Мне это для игрушки, но, думаю, для ОС на обычный 128й тоже надо будет. Так чтобы прошить её код вместо 128го бейсика. (Так 128й по-моему ещё останется "обычным" 128м, каким он уже наверное не будет, если мы прошьём свой код вместо TRDOS, или в 4ю страницу ПЗУ.)
Я не знаю, нужна ли для TRDOS память(для посекторного доступа, без ФС, сами найдём куда писать), используемая бейсиком, не знаю какую память использует сама TRDOS для своих переменных и буферов. Что по минимуму(а не целиком страницу) нужно сохранять? Или, как вариант, можно ли затереть эту память, а потом подёргать процедуры её инициализации(если при этом надо будет дёргать дисковод, уже плохо).
Тут лежит для ZX-Pentevo. Пока что грузится только по ком-порту и не видит ещё дисков.
https://github.com/salextpuru/FUZIX
Error404
20.11.2014, 22:22
А я вообще не планирую дисководы поддерживать. Нафига они? Оставлю только IDE и SD. Зато будут поддерживаться MBR-партиции, до 4х на устройство, несколько физ. устройств - т.е. партиций будет 8 или больше (выбирать минорным номером). Т.е. можно будет такую SD-карту переставлять из Ориона в PC и все будет совместимо. У меня сейчас так под CP/M - схема с MBR-разделами, довольно удобно: разделы можно подмонтировать/отмонтировать "на лету".
---------- Post added at 22:22 ---------- Previous post was at 22:18 ----------
Утилиту BD (block dump) кто-нить собирал? Что она выводит на экран (по свой сборке не пойму никак)? Если запустить к примеру так "bd 0: 1".
Никак не пойму, а описания нет.
Утилиту BD (block dump) кто-нить собирал? Что она выводит на экран (по свой сборке не пойму никак)?
У меня утилиты вообще не собираются, жалуются на отсутствие __modslonglong
Error404
20.11.2014, 23:11
У меня утилиты вообще не собираются, жалуются на отсутствие __modslonglong
Я от Юзикс сейчас собираю. При помощи CPM-овского Hitech C. :)
Т.е. на волне интереса к FUZIX предпринимаю очередной заход на Uzix (как на данный момент более полный дистрибутив). PogrammersNotepad, проект, makefile - пытаюсь делать как принято, чтобы потом не только мне было понятно что да как. От него, набравшись шишек и отладив низовые платформеннозависимые вещи, уже к FUZIX попробую. Только я наверное в оконцовке опять попробую Hitech C использовать и для FUZIX тоже - он более эффективный код дает.
Думаю, в версии для FUZIX и в версии для Uzix утилиты на экран должны одно и то же выводить, почему и спрашиваю.
---------- Post added at 23:11 ---------- Previous post was at 23:07 ----------
Кстати, дистрибутив UZIX, гуляющий в интернетах -несобираемый. Т.е. какие-то небольшие вещи HitechC не воспринимает в принципе, надо править (ассемблерные вставки, етс). Не знаю - может у авторов была не бесплатная V3.09, а какая-то чуть более другая, например платная HitechC более старших версий.
Нашел полную херню.
Почему в crt0.s секция _INITIALIZER копируется вдруг в _COMMONMEM ?!
Это ж полная х%::%:я!
; move the common memory where it belongs
ld hl, #s__INITIALIZER
ld de, #s__COMMONMEM
ld bc, #l__COMMONMEM
ldir
По всем правилам надо так.
; move the common memory where it belongs
ld bc, #l__INITIALIZER
ld a, b
or a, c
jr Z, gsinit_next
ld de, #s__INITIALIZED
ld hl, #s__INITIALIZER
ldir
gsinit_next:
Я хочу писать/читать сектора на BDI так, чтобы использовать на это минимум памяти. Мне это для игрушки, но, думаю, для ОС на обычный 128й тоже надо будет. Так чтобы прошить её код вместо 128го бейсика. (Так 128й по-моему ещё останется "обычным" 128м, каким он уже наверное не будет, если мы прошьём свой код вместо TRDOS, или в 4ю страницу ПЗУ.)
Я не знаю, нужна ли для TRDOS память(для посекторного доступа, без ФС, сами найдём куда писать), используемая бейсиком, не знаю какую память использует сама TRDOS для своих переменных и буферов. Что по минимуму(а не целиком страницу) нужно сохранять? Или, как вариант, можно ли затереть эту память, а потом подёргать процедуры её инициализации(если при этом надо будет дёргать дисковод, уже плохо).
Я так подробно не разбирался с этим вопросом. Но все переменные TR-DOS занимают 133 байта с 23734.
http://zxpress.ru/book_articles.php?id=1353
Еще здесь посмотри, может найдёшь ответ. http://zx-pk.ru/archive/index.php/t-7056.html
Почему в crt0.s секция _INITIALIZER копируется вдруг в _COMMONMEM ?!
Это всё часть великого колдунства. Вторая половина в tools/binman. Там явно надо что-то чинить для zx128, т.к. у нас нет дыры между основной частью и commonmem, и какая-то специальная обработка не нужна. А то счас интересные эффекты - если удлинить commonmem на 1 байт, то образ удлиняется на два. А если удлинить достаточно сильно (байт на 100), то отваливаются прерывания и клава перестаёт работать.
Это всё часть великого колдунства.
Секция INITIALIZED, по мнению компилятора SDCC, располагается в ОЗУ и её нужно инициализировать из кода, который может быть и в ПЗУ (из INITIALIZER).
Поскольку ядро грузится в ОЗУ, данное копирование излишне и данные из секции INITIALIZER утилита binman копирует сама (тут надо отметить, что после преобразования .ihx в .bin все сегменты располагаются на своих местах, а утилита binman пытается сжать слепок памяти, убрав дырки). На освободившееся место, которое обычно в самом конце кода ядра, и откуда будет начинаться распределяемое в процессе работы ядра ОЗУ, binman копирует данные секции COMMONMEM, которые располагаются отдельно от кода ядра в непереключаемой области. Именно они и копируются потом при запуске ядра на своё место, т.е. из секции INITIALIZER в секцию COMMONMEM.
Секцию DISCARD можно расположить где-нибудь в конце кучи и копировать туда перед запуском. Соответственно в binman нужно добавить копирование её в конец COMMONMEM.
мда. нескоро оно ещё работать начнёт)
мда. нескоро оно ещё работать начнёт)
А что такое?
Кстати, на тсконфиг возможен вывод текста непосредственно в экран вне адресного пространства, не требующий каких-либо буферов.
Error404
21.11.2014, 15:33
А можно пионерский вопрос участникам забега (мне простительно, я не программист же :) )?
Имеется код:
#define NBUFS 2
typedef struct s_blkbuf {
.........................
} blkbuf_t, *bufptr;
blkbuf_t bufpool[NBUFS];
.........................
bufptr bp = bufpool;
while (bp < bufpool+NBUFS) {
.........................
++bp;
}
В приведенной конструкции чему равно (bufpool+NBUFS)? "bufpool+2" или "bufpool+2*sizeof(blkbuf_t)"?
И "++bp" увеличивает значение указателя (по факту, адрес) на единицу или на sizeof(blkbuf_t)?
Как вообще они сравнивают указатель на структуру с массивом? По абсолютным величинам адреса? Или как?
Когда к указателю прибавляют еденицу, то получается указатель на следующий элемент, а не следующий байт.
А можно пионерский вопрос участникам забега (мне простительно, я не программист же :) )?
В приведенной конструкции чему равно (bufpool+NBUFS)? "bufpool+2" или "bufpool+2*sizeof(blkbuf_t)"?
И "++bp" увеличивает значение указателя (по факту, адрес) на единицу или на sizeof(blkbuf_t)?
Как вообще они сравнивают указатель на структуру с массивом? По абсолютным величинам адреса? Или как?
В Си так:
1) Массив - это де факто указатель на первый элемент массива.
2) Прибавление числа к указателю прибавляет sizeof(тип, на который указываем)
Поэтому
int array[10];
int* array2 = array; // работает без проблем
print(array2[5]) - пятый элемент массива. Ну и что, что указатель.
array2 + 3 // указатель на третий элемент массива
array + 3 // то же самое
bufpool+NBUFS адрес конца буфера
Единственная разница между массивом и указателем - это sizeof. sizeof массива - объем занятой массивом памяти, sizeof указателя - размер указателя (обычно разрядность архитектуры)
массив - константный адрес
указатель - переменная, хранящая адрес
---------- Post added at 18:12 ---------- Previous post was at 18:09 ----------
адреса сравниваются также, как и беззнаковые целые
Ну вот! https://github.com/salextpuru/FUZIX/commit/909e61049e6e2b01b732663c1ca93060e89df206
Стабильно запускается. Показывет 1Мбайт (64 страницы) для процессов + 64 для ядра.
Теперь приступим к ваянию виртуального диска.
Ну вот! https://github.com/salextpuru/FUZIX/commit/909e61049e6e2b01b732663c1ca93060e89df206 Стабильно запускается. Показывет 1Мбайт (64 страницы) для процессов + 64 для ядра.
Скриншоооот, дай скриншоооооут!
Скриншоооот, дай скриншоооооут!
Какой скриншот? я на реальной пентеве его мучаю. Фото чуть раньше кидал.
Вот новые)
Кому многозадачность?
http://dl.dropboxusercontent.com/u/20289147/zx/fuzix_3.png
fork() реализован, переключение процессов тоже. Осталась фигня - как-то скомпилировать системные утилиты.
(в аттаче форкующийся инит, который на скрине)
Error404
22.11.2014, 00:40
А либы есть?
Я почему с юзикса пытаюсь начать - там они много функций реализовали в либах, приложения их соответственно используют, без либ не собирутся.
А либы есть?
Я почему с юзикса пытаюсь начать - там они много функций реализовали в либах, приложения их соответственно используют, без либ не собирутся.
только syslib. Она собралась, но в ней остались символы, которых нигде нет, и без которых сборка самих утилит падает. Подозреваю, что почему-то не прилинковываются либы от sdcc - потому что символы примитивные, memcpy всякий и __modslonglong.
Error404
22.11.2014, 00:55
только syslib. Она собралась, но в ней остались символы, которых нигде нет, и без которых сборка самих утилит падает. Подозреваю, что почему-то не прилинковываются либы от sdcc - потому что символы примитивные, memcpy всякий и __modslonglong.
longlong - это не про int64? И пусть бы с ним, в тех проектах длинее long (int32) нигде не используется
longlong - это не про int64? И пусть бы с ним, в тех проектах длинее long (int32) нигде не используется
Используется - хваленый коксовый "настоящий" time_t, решающий проблему 2038-го года... Из за него даже ls не собирается.
Кому многозадачность?
http://dl.dropboxusercontent.com/u/20289147/zx/fuzix_3.png
fork() реализован, переключение процессов тоже. Осталась фигня - как-то скомпилировать системные утилиты.
(в аттаче форкующийся инит, который на скрине)
Ну таперича мне её проще впилить будет, спасибо :)
чтото не нравится мне, что при переключении каждый раз копируется по 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 ?
Error404
22.11.2014, 11:01
Используется - хваленый коксовый "настоящий" time_t, решающий проблему 2038-го года... Из за него даже ls не собирается.
Алан любит "бантики", похоже. "проблема 2038" (дожить бы!), удлиннение имен файлов, еtс :biggrin:
Если ядро влазит в 48к, то смысла такого копирования я не вижу. Проще сразу задать U_DATA=FD00 и щёлкать страницы.
В чём я не прав?
В том, что ядро не влазит в 48к, конечно :)
---------- Post added at 13:24 ---------- Previous post was at 13:23 ----------
Вообще, я изначально так и собирался сделать. И оно даже реализуемо, если хорошо раскидать сегменты по памяти. Но пока что решил, что это преждевременная оптимизация и корень всех зол.
---------- Post added at 13:30 ---------- Previous post was at 13:24 ----------
Алан любит "бантики", похоже. "проблема 2038" (дожить бы!), удлиннение имен файлов, еtс :biggrin:
ну а прикинь завтра фюьзикс в космос надумают отправлять, а в нём y38k не решен! :v2_rolley и отправят ELKS какой-нибудь. Позор на всю жизнь же!
---------- 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 у инита такой хитровыделанный? 25907 ?
Это на деле оказался не PID, а указатель на структуру описателя процесса. Надо убрать, это мой отладочный kprintf
ЗЫ я знаю, почему у тебя нижний правый квадратик - белый ;)
Error404
22.11.2014, 12:51
Кто знает - вот это вот:
https://plus.google.com/+AlanCoxLinux/posts/a2jAP7Pz1gj
это единственный блог проекта? А то чего-то там никаких движений не происходит. Где отчеты автора? Хочется почитать.
И ещё вопрос - что за запись по адресу #0000 происходит в lowlevel-z80.s ?
Что за флаг такой?
Проверка, не испортилась ли память (например, если писали по нулевому указателю). Если там всё равно ПЗУ, её можно закомментировать.
Кстати, а что за PID у инита такой хитровыделанный? 25907 ?
Вообще-то у init-а PID должен равняться 1, в doexit даже проверка есть, если завершился процесс с номером 1, то ядро паникует.
Вообще, я изначально так и собирался сделать. И оно даже реализуемо, если хорошо раскидать сегменты по памяти. Но пока что решил, что это преждевременная оптимизация и корень всех зол.
Про то, что это "не горит" - согласен. Но раз ты об этом думал, значит у нас мысли идут в похожем направлении.
ну а прикинь завтра фюьзикс в космос надумают отправлять, а в нём y38k не решен! :v2_rolley и отправят ELKS какой-нибудь. Позор на всю жизнь же!
Честно говоря, не вижу проблем запилить в либы свои несколько функций работы с 64-битной арифметикой. Больше разговоров, ИМХО.
ЗЫ я знаю, почему у тебя нижний правый квадратик - белый ;)
Ну я твой код не правил шибко. Пока больше читаю, чем пишу :)
А почему?)
Error404
22.11.2014, 15:06
Честно говоря, не вижу проблем запилить в либы свои несколько функций работы с 64-битной арифметикой. Больше разговоров, ИМХО.
Да просто лишнее это. На дефайнах заменить нафиг на 32-разрядный. Т.к. 64-разрядный вариант работать будет медленее, а у нас не Т80 на сотне мегагерц. В Юзикс всего одна (одна!) функция где используется 32-разрядный параметр, во всех остальных местах все 16-разрядное. А тут какие-то 64-разрядные излишества.
shurik-ua
22.11.2014, 16:04
Т.к. 64-разрядный вариант работать будет медленее,
если сделать вот так:
inc_64_value:
;hl - указатель на 8-байтовую переменную
dup 7
inc (hl)
ret nz
inc hl
edup
inc (hl)
ret
то проигрыш с переходом на 64 бит переменную - минимальный (если вообще есть )
Error404
22.11.2014, 17:57
если сделать вот так:
inc_64_value:
;hl - указатель на 8-байтовую переменную
dup 7
inc (hl)
ret nz
inc hl
edup
inc (hl)
ret
то проигрыш с переходом на 64 бит переменную - минимальный (если вообще есть )
надо использовать adc (учитывать перенос), а не inc, чтобы был не инкремент 8 байтов, а 8-байтного числа. Или я что-то не догоняю.
Кроме того, инкремент - это частный случай (и то вдвое больший по коду и вдвое меньший по скорости аналогичного 32бит), а когда зайдет речь про арифметику с двумя операндами, да передачу всего этого на стеке, да загрузку по индексному регистру - там будет медленно и объемно. Плюс на регистрах это не сделать в принципе (нету у Z80 столько регистров), а только в памяти (как в примере), а для к примеру 16-битной арифметики, при желании все делается на регистрах, да и для 32-битной многое тоже.
---------- Post added at 17:57 ---------- Previous post was at 17:53 ----------
Ну я твой код не правил шибко. Пока больше читаю, чем пишу :)
А почему?)
Потому что там в лдире очистки экрана не зря BC был именно 1800 :)
Ты его на единицу уменьшил, а вот DE и HL соответственно увеличить забыл. В итоге у тебя атрибуты начинаются с 57FF.
Я потому 1800 и поставил. Одно лишнее обращение к памяти один раз при инициализации - фигня. А вот два лишних INC - это два занятых байта драгоценного _COMMONMEM.
Короче SD-карта начала читать.! И писать тоже, по идее должна.
Твой образ прочитала. И запустила Hello World. Только вот многозадачный образ почемуто форкаться отказался... Сцука!
Пишет всё время один процесс.
И ещё вопрос - что за запись по адресу #0000 происходит в lowlevel-z80.s ?
Это ты очень правильно спросил! У меня из-за этой проверки ядро в определенный момент решало, что всё плохо, и слало процессу SIGSEGV. Добавил jp 3 по адресу 0, чтоб проверка проходила - счас форкнутые процессы уже минут 20 крутятся, полёт нормальный!
Блин, не представляю, как ты на реальном железе отлаживаешься :) Я на вышеописанный баг убил весь вечер, и это притом, что у меня-то и отладчик есть, и эмуль лог M1-чтений пишет.
---------- Post added at 03:11 ---------- Previous post was at 03:08 ----------
Твой образ прочитала. И запустила Hello World. Только вот многозадачный образ почемуто форкаться отказался... Сцука!
Пишет всё время один процесс.
Если всегда пишет process 2 (это сам инит), то смотри прерывания, если process 1 (форк), то переключение банок.
Error404
23.11.2014, 02:39
Off:
make для CPM (нативного - для Z80 и 60к ОЗУ) есть у кого-нить? Он в природе для CPM есть вообще?
УРА! https://github.com/salextpuru/FUZIX/commit/e9ca8761fe2a22c1bbd827a00755d6666c3d1fea
ЗАРАБОТАЛО!
Всё дело в том, что в пентеве в порты надо кидать ИНВЕРСНЫЕ номера страниц. И я кое-где накосячил.
ФОРКАЕТСЯ!
---------- Post added at 11:13 ---------- Previous post was at 11:10 ----------
Вопрос - почему через пару минут второй процесс исчезает?
можешь дать исходы своего "инита с форком" ?
Вопрос - почему через пару минут второй процесс исчезает?
можешь дать исходы своего "инита с форком" ?
Через время и первый исчезает. Выше написано, почему. Вот, cherry-pick'ни этот коммит - http://github.com/atsidaev/FUZIX/commit/dd4713e70c80f071e70457d8c564e3b05623b44d
Сорцы погибли в пучине git clean :( Можешь дизассемблировать, там сотня байт всего. Весь код сводится к syscall 1 (open), syscall 8 (write) и syscall 32 (fork).
Блин, не представляю, как ты на реальном железе отлаживаешься :) Я на вышеописанный баг убил весь вечер, и это притом, что у меня-то и отладчик есть, и эмуль лог M1-чтений пишет.
потихоньку.. сначала накидал простенький принтф и разобрался с маппером памяти. потом - написал приём байтов с ком-порта и распихивание их по страничкам.
ну а теперь - всё довольно просто.
Reset, загрузка с SD загрузчика FUZIX по ком-порту и запуск простенького скрипта на компе, который передаёт FUZIX по ком-порту в виде 4х страниц с паузой между ними по 2 секунды (чтобы загрузчик сообщения на экране выводить успевал).
Сейчас надо всётаки сделать загрузчик фузикса с TRD-диска.
на спекки2010 не пробовали портрировать?
Кстати, а как на эмуле отладить пентевовскую SDшку? я не знаю.
Но за день я добился на реале её работы. Пока, правда, раздел FUZIXFS начинается с сектора 2048 флешки - прибито гвоздями. Но - работает же!)
---------- Post added at 16:11 ---------- Previous post was at 16:10 ----------
на спекки2010 не пробовали портрировать?
у меня нет спекки 2010. только пентева и пентагон1024.
если на пентеве система встанет, то попробую и на пентагоне её запустить.
SfS, тс-конфа же работает на спекки2010 - использовать готовый скелет .железо то позволяет.
на спекки2010 не пробовали портрировать?
Это на ARM7-то? :v2_conf2:
---------- Post added at 15:23 ---------- Previous post was at 15:21 ----------
Если мне кто-нибудь задонейтит speccy2010, я с удовольствием портирую туда ядро в нынешнем виде и оба крайне полезных процесса :cool:
SfS, тс-конфа же работает на спекки2010 - использовать готовый скелет .железо то позволяет.
я работал с baseconf.
но ничего не мешает тебе взять сырки и поправить порты менеджера памяти как хочешь. там всего то в 4-5 местах они есть.
---------- Post added at 16:39 ---------- Previous post was at 16:37 ----------
Если мне кто-нибудь задонейтит speccy2010, я с удовольствием портирую туда ядро в нынешнем виде и оба крайне полезных процесса :cool:
ты лучше с тем же удовольствием пропатчи либы и утилзы, чтобы собирались. :)
если будет минимальная система - то её можно уже будет и на пентагон 1024 перетащить (он есть у меня) и на другие спекомпы.
считаю до того, как можно будет набрать make и собрать все утилиты - дальнейшее ядропортирование на 100500 платформ несколько бессмысленным.
Eltaron, арм там вообще не каким боком.советую почитать в теме последние 5 стр примерно.все делает ФПГА
но ничего не мешает тебе взять сырки и поправить порты менеджера памяти как хочешь. там всего то в 4-5 местах они есть.
Кажется, palsw говорит о том, чтобы запилить новую конфу для Speccy2010, чисто под фузих. По-моему, это самый тупиковый путь из возможных.
Eltaron, зачем новую конфу.
раз на пентеве работает то на спекке есть конфа которая эмулит тс-конфу.
лучше обьясните для обычных людей как оно вообще работает - алгоритм.
ты лучше с тем же удовольствием пропатчи либы и утилзы, чтобы собирались. :)
Либа-то собирается. Да и программы собираются - в sdcc из репозитория бага с __modslonglong пофикшена. Не все - некоторым нужен unix.h, которого нет (а kernel.h на замену не тянет), но собираются. Но выходной файл мало похож на программу для fuzix. Что-то линкер мутное творит, надо поразбираться.
---------- Post added at 15:54 ---------- Previous post was at 15:49 ----------
лучше обьясните для обычных людей как оно вообще работает - алгоритм.
Для обычных людей, которым лень прочитать две страницы, но которые гонят других читать аж пять - оно не работает ВООБЩЕ
У нас ситуация даже хуже, чем у Торвальдса в 1991 - у него хоть кроме ядра был загрузчик с диска. У нас нет и этого, есть только ядро и драйвер экрана/клавы. Напомню, что линукс к виду, пригодному для обычного человека, пришел лишь в 1993 (а некоторые утверждают, что до сих пор не пришел) - это через джва года упорной работы кучи людей. О каком портировании куда-нибудь вообще можно речь вести в такой ситуации?
Eltaron, ясно,будем ждать :).
Либа-то собирается. Да и программы собираются - в sdcc из репозитория бага с __modslonglong пофикшена. Не все - некоторым нужен unix.h, которого нет (а kernel.h на замену не тянет), но собираются. Но выходной файл мало похож на программу для fuzix. Что-то линкер мутное творит, надо поразбираться.
А ты crt0.s поправил?
там в начале 0x100 байт тупо резервируются.
в нашем случае этого не надо, как я понимаю (PROGBASE=0x100 заменён на PROGBASE=0xC000)
что ещё там не так?
---------- Post added at 17:03 ---------- Previous post was at 17:00 ----------
У нас ситуация даже хуже, чем у Торвальдса в 1991 - у него хоть кроме ядра был загрузчик с диска. У нас нет и этого, есть только ядро и драйвер экрана/клавы.
А у нас уже есть загрузчик по COM-порту) Кстати, скоро он и с диска начнёт грузить. TR-DOS то никто не отменял.
Плюс у нас УЖЕ есть линукс, баш и мильён удобных тулз, которых в 90м не было)
Eltaron,
Если мне кто-нибудь задонейтит speccy2010
нет возможности донатить (
могу только из конструктора собрать, с удовольствием,платку на шару.Осталось ,что бы кто то задонатил платку и детальки :)
А ты crt0.s поправил?
там в начале 0x100 байт тупо резервируются.
Ага, я C000 байт резервирую :) Обрезать-то не проблема. Но беда - в этих C000 встречается что-то кроме 0xFF. Я вчера это увидел и с горя спать пошел, надо на ясную голову поглядеть.
Кстати, скоро он и с диска начнёт грузить. TR-DOS то никто не отменял.
Тр-дос проектировали слишком *beep* (аккуратные) люди. Там прямой доступ к портам возможен только если включена страница TR-DOS, а она включается только если кто-нибудь начнет исполнять шрифт (M1 в 3D00-3DFF). Как это обходить - ума не приложу. На пентеве-то хорошо, да и мне на Кворуме без проблем, а вот в общем пентагоно-128K-образном случае что делать - непонятно. Нужен более умный линкер и много костылей...
Плюс у нас УЖЕ есть линукс, баш и мильён удобных тулз, которых в 90м не было)
У них тоже был вполне рабочий миникс и куча софта GNU. Ну да это я так, нагнетаю, на самом деле свет в конце туннеля уже вполне виден.
Подумалось - черт побери, а ведь UZI старше Linux! Он же в 1989-м написан или около того.
NovaStorm
23.11.2014, 14:34
а вот в общем пентагоно-128K-образном случае что делать - непонятно.
А с #3D2F в чем сложности? С прерываниями?
А с #3D2F в чем сложности? С прерываниями?
Так-то и #3d13 наверное подойдет - нам из всех операций с диском нужны только чтение/запись двух подряд идущих секторов. Главная проблема в линкере. Нет возможности сказать линкеру от sdcc, чтоб в 3D00-3DFF не размещал ничего, в области системных переменных тоже, а остальные линкуемые файлы распихал по всей оставшейся памяти.
Ну и хочется универсального решения, ВГ93 не только в бетадиске.
shurik-ua
23.11.2014, 15:14
А что там с богомипсами - кажет что нибудь ?)
Теперь приложения собираются как надо, те, что без time_t. https://github.com/salextpuru/FUZIX/tree/apps-fixed
получается красивый бинарь)
---------- Post added at 18:30 ---------- Previous post was at 18:29 ----------
А что там с богомипсами - кажет что нибудь ?)
пока не до богомипсов)
А какая стабильная версия SDCC работает с long long нормально? тыкните меня, пожалуйста.
А какая стабильная версия SDCC работает с long long нормально? тыкните меня, пожалуйста.
Любая начиная с ревизии 9088 в их svn
http://sourceforge.net/p/sdcc/bugs/2301/
Но не знаю, починили ли они то, что свежие версии не собирают ядро.
---------- Post added at 18:04 ---------- Previous post was at 17:34 ----------
Теперь приложения собираются как надо, те, что без time_t. https://github.com/salextpuru/FUZIX/tree/apps-fixed
C unix.h всё равно не собираются. Но да, мусора ниже C000 счас нет, спасибо.
---------- Post added at 18:51 ---------- Previous post was at 18:04 ----------
Прикрутил binman к утилитам
https://github.com/atsidaev/FUZIX/commit/a33c011aef268aa89b5951135b9127d15ef0173e
init пошел. Но даёт ввести только две буквы.
http://dl.dropboxusercontent.com/u/20289147/zx/fuzix_4.png
Главная проблема в линкере. Нет возможности сказать линкеру от sdcc, чтоб в 3D00-3DFF не размещал ничего
Перекинь что-нибудь из сегмента CODE в CODE2, чтобы меньше 3D00 был, а на месте 3D00-3FFF сделай новый сегмент (FDDCODE например), адрес для него задай также как и для COMMONMEM. Ну и в crt0.s добавь сегмент FDDCODE после CODE.
Перекинь что-нибудь из сегмента CODE в CODE2, чтобы меньше 3D00 был, а на месте 3D00-3FFF сделай новый сегмент (FDDCODE например), адрес для него задай также как и для COMMONMEM. Ну и в crt0.s добавь сегмент FDDCODE после CODE.
Да, это всё понятно. Но это требует вмешательства в платформо-независимый код и может порушить остальные архитектуры, поэтому это костыль.
Но это требует вмешательства в платформо-независимый код
Можно обойтись локальными изменениями. Я для примера перенёс devtty.c в сегмент CODE2, при этом CODE сократился до 3СА2. Изменил только твой локальный Makefile:
CSRCS = devfd.c
CSRCS += devices.c main.c
CSRCS2 = devtty.c
ASRCS = crt0.s zx128.s zxvideo.s
ASRCS += tricks.s commonmem.s
COBJS = $(CSRCS:.c=.rel)
COBJS2 = $(CSRCS2:.c=.rel)
AOBJS = $(ASRCS:.s=.rel)
OBJS = $(COBJS) $(COBJS2) $(AOBJS)
JUNK = $(CSRCS:.c=.lst) $(CSRCS:.c=.asm) $(CSRCS:.c=.sym) $(ASRCS:.s=.lst) $(ASRCS:.s=.sym) $(CSRCS:.c=.rst) $(ASRCS:.s=.rst)
all: $(OBJS)
$(COBJS): %.rel: %.c
$(CROSS_CC) $(CROSS_CCOPTS) -c $<
$(COBJS2): %.rel: %.c
$(CROSS_CC) $(CROSS_CCOPTS) $(CROSS_CC_SEG2) -c $<
$(AOBJS): %.rel: %.s
$(CROSS_AS) $(ASOPTS) $<
clean:
rm -f $(OBJS) $(JUNK) core *~
image:
Добавить своих сегментов можно сколько угодно, всё равно crt0.s локальный, как и uzi.lnk
А вот два лишних INC - это два занятых байта драгоценного _COMMONMEM.
Борющимся за место под солнцем в _COMMONMEM.
; printing
ld c, #8
plot_char_loop:
ld a, (hl)
ld (de), a
inc hl ; next byte of char data
inc d ; next screen line
dec c
jr nz, plot_char_loop
ret
почему dec c/jr nz вместо djnz? :)
Борющимся за место под солнцем в _COMMONMEM.
А это _VIDEO :)
---------- Post added at 20:55 ---------- Previous post was at 20:54 ----------
Но согласен :)
---------- Post added at 22:42 ---------- Previous post was at 20:55 ----------
Баг с клавой поборол, теперь корректно отрабатывает
Но вот засада - в 16 килобайт командный интерпретатор не влазит :(
Фокус не удался, кароч.
[/COLOR]
Но вот засада - в 16 килобайт командный интерпретатор не влазит :(
Фокус не удался, кароч.
Насколько не влазит? Может, ручками заоптимизить? Не хочешь сам, скинь асмовский исходник, хотя бы на посмотреть, что можно сделать.
Насколько не влазит? Может, ручками заоптимизить? Не хочешь сам, скинь асмовский исходник, хотя бы на посмотреть, что можно сделать.
На два-три килобайта не влазит.
Проще кусок функционала прямо из сишного кода выкинуть.
На два-три килобайта не влазит.
Проще кусок функционала прямо из сишного кода выкинуть.
Для теста как такового можно и выкинуть. SDCC в процессе геренит асмовские файлы. Дай асмовский файл этого интерпретатора, пожалуйста
Для теста как такового можно и выкинуть. SDCC в процессе геренит асмовские файлы. Дай асмовский файл этого интерпретатора, пожалуйста
Да толку-то, он в скомпилированном виде меньше 3 килобайт весит. Всё остальное - статически прилинкованная библиотека.
Держи в аттаче.
Всё остальное - статически прилинкованная библиотека.
Неужели, все функции этой либы используются?! Может воспользоваться "умной линковкой?" .Я разрежу эту либу на кучу файлов по одной функции и SDAR`ом соберу либу, из которой линковаться будут только задействованные функции.
Как тебе идея?
Неужели, все функции этой либы используются?! Может воспользоваться "умной линковкой?" .Я разрежу эту либу на кучу файлов по одной функции и SDAR`ом соберу либу, из которой линковаться будут только задействованные функции.
Как тебе идея?
Это же стандартный путь. Там так и сделано.
http://github.com/EtchedPixels/FUZIX/tree/master/Library/libs
Там так и сделано.
http://github.com/EtchedPixels/FUZIX/tree/master/Library/libs
Засада! :(
Error404
24.11.2014, 02:25
Конечно это из серии "переписать все" совет, но я по своему опыту, использую HitechC:
HI-TECH C COMPILER (CP/M-80) V3.09
Copyright (C) 1984-87 HI-TECH SOFTWARE
Он на 30-40%% более компактный код делает, чем SDCC
Вот, собрал утилиты в CP/M и для CP/M, вроде все работает. А это как-никак до 70% ядра (все что кроме процессов). Т.е. для сборки (F)UZI(X) он вполне пригоден. Можно прям на Орионе все собирать. :)
Но собираю под Виндой, для удобства редактирования (исп. ProgrammersNotepad, проект - удобно) и компилирования:
# Makefile for UZIX modules
.SUFFIXES: .c .obj .as .lib
CC = cpm -h c
AS = cpm -h zas
LINK = cpm -h link
LIBR = cpm -h libr
OBJHEX = cpm -h objtohex
M80 = cpm m80n
L80 = cpm l80m
RM = rm
DEFINES = -DORI_UTIL
#DEFINES = -DORI_UZIX -DNO_ASM
CFLAGS = -O -x
ASFLAGS = -N
OBJ_MKFS = MACHDEP.obj fs.obj dmisc.obj diskio.obj dio.obj dflop.obj dtty.obj sc1.obj
OBJ_BD = MACHDEP.obj fs.obj dmisc.obj diskio.obj dio.obj dflop.obj dtty.obj sc1.obj
OBJ_FSCK = MACHDEP.obj fs.obj dmisc.obj diskio.obj dio.obj dflop.obj dtty.obj sc1.obj
OBJ_UCP = MACHDEP.obj fs.obj XFS.obj ucs.obj dmisc.obj diskio.obj dio.obj dflop.obj dtty.obj sc1.obj sc2.obj
.c.obj :
$(CC) $(CFLAGS) $(DEFINES) -c $*.c
.as.obj :
$(AS) $(ASFLAGS) -L$*.lst $*.as
# devmisc.obj must be compiled without optimization (-O) because optimizer spoiling #asm blocks!
dmisc.obj : dmisc.c
$(CC) $(DEFINES) -x -c dmisc.c
idebdos.com :
$(M80) idebdos,=idebdos
$(L80) /p:100,idebdos,idebdos/n/e
bd.com : $(OBJ_BD) bd.c
$(CC) $(CFLAGS) $(DEFINES) bd.c $(OBJ_BD)
fsck.com : $(OBJ_FSCK) fsck.c
$(CC) $(CFLAGS) $(DEFINES) fsck.c $(OBJ_FSCK)
mkfs.com : $(OBJ_MKFS) mkfs.c
$(CC) $(CFLAGS) $(DEFINES) mkfs.c $(OBJ_MKFS)
ucp.com : $(OBJ_UCP) ucp.c
$(CC) $(CFLAGS) $(DEFINES) ucp.c $(OBJ_UCP)
all : idebdos.com bd.com fsck.com mkfs.com ucp.com
clean :
$(RM) $(OBJ_UCP) bd.obj fsck.obj mkfs.obj ucp.obj
Конечно это из серии "переписать все" совет, но я по своему опыту, использую HitechC:
Лично, я готов переписать все либы на асме :) Там даже то, что изначально на асме, как будто, нарочно писалось, чтобы памяти больше занимало :)
Токо это долго будет, не меньше месяца (если загонюсь).
HI-TECH C COMPILER (CP/M-80) V3.09
Copyright (C) 1984-87 HI-TECH SOFTWARE
Хорошая весчь.
Но собираю под Виндой, для удобства редактирования (исп. ProgrammersNotepad, проект - удобно) и компилирования:
Будь добр, поделись образом "среды" с хайтеком. Кстати, может ли он ассемблерный файлы выдавать, или сразу непосредственно в бинарники компилит?
Кстати, наверное, можно будет этот CP/M HiTech и к Code::Blocks прикрутить.
Error404, как кросс средство (полукросс) хорошо использовать этот эмуль:
http://homepage3.nifty.com/takeda-toshiya/cpm/index.html
он под винду. в нём сборка многих исходников hitech-c просто в пару секунд пролетает. при этом есть исходники, можно допиливать на своё усмотрение. удобна!
да, зачисти свою личку, а то даже сообщение не отправить тебе.
---------- Post added at 11:05 ---------- Previous post was at 11:00 ----------
Лично, я готов переписать все либы на асме :) Там даже то, что изначально на асме, как будто, нарочно писалось, чтобы памяти больше занимало :)
Токо это долго будет, не меньше месяца (если загонюсь).
Хорошая весчь.
Будь добр, поделись образом "среды" с хайтеком. Кстати, может ли он ассемблерный файлы выдавать, или сразу непосредственно в бинарники компилит?
Кстати, наверное, можно будет этот CP/M HiTech и к Code::Blocks прикрутить.
HiTech-C 3.09 это древний компилятор под CP/M. однако, он ansi c совместимый. чтобы его прикрутить к какой-то среде, надо иметь хороший эмуль. если code::blocks под венду, то ссылка выше на эмуль. если под линь, для себя я определил только один достойный эмул цпма - zxcc:
http://classiccmp.org/cpmarchives/cpm/mirrors/www.seasip.info/Unix/Zxcc/index.html
0.5.7 я собрать не смог, 0.5.6. вроде без проблем собирается.
---------- Post added at 11:08 ---------- Previous post was at 11:05 ----------
некое подобие make файла для сборки под вышеприведённым виндоэмулем:
@echo off
if "%1" == "" goto error
if not exist %1.c goto nofile
if exist %1.asm del %1.asm
if exist %1.obj del %1.obj
if exist %1.com del %1.com
if exist %1.map del %1.map
@echo on
cpm cpp -DHI_TECH_C -Dz80 -I %1.c C1.T
cpm p1 C1.T C2.T C3.T
cpm cgen C2.T %1.asm
cpm zas -N -o%1.obj %1.asm
cpm link -Z -M%1.map -C100H -O%1.com crtcpm.obj %1.obj libс.lib
del *.T
@echo off
goto end
:nofile
echo Source file does not exist.
goto end
:error
echo usage: ucc sourcefile [-o] [library1] [library2...]
echo source filename must be supplied without extension.
echo option -o disables code optimization.
echo library1, library2, etc are other libraries to link
echo map file is automatically generated (sourcefile.map)
:end
ещё есть батник для сборки libc. если надо, есть исходники libc.
Вот интересно, почему во многих функциях параметр, представляющий собой одиночный символ, указывают как "int"?!
void *memccpy(void *d, const void *s, int c, size_t n)
Вот интересно, почему во многих функциях параметр, представляющий собой одиночный символ, указывают как "int"?!
void *memccpy(void *d, const void *s, int c, size_t n)
если я верно понял (сам этой функцией не пользовался), то третий аргумент (int c) это триггер, код при котором операция будет прервана. поскольку число знаковое, то от -32768 до +32767. потому и int. надо тебе прервать в какой-то момент копирование, ставишь ему параметр. например, у тебя какой- то код есть, число 1024, для примера. вот его и поставил. было бы char пришлось бы извращаться.
вообще, некоторые стоковые операции из Libc я заменил на подобные из файла machdep.c у uzix. bcopy, bfill, bzero.и места меньше и работает быстрее, чем стоковая memcpy, например.
если я верно понял (сам этой функцией не пользовался), то третий аргумент (int c) это триггер, код при котором операция будет прервана. поскольку число знаковое, то от -32768 до +32767. потому и int. надо тебе прервать в какой-то момент копирование, ставишь ему параметр. например, у тебя какой- то код есть, число 1024, для примера. вот его и поставил. было бы char пришлось бы извращаться.
вообще, некоторые стоковые операции из Libc я заменил на подобные из файла machdep.c у uzix. bcopy, bfill, bzero.и места меньше и работает быстрее, чем стоковая memcpy, например.
Странно, по описанию, копирует строку не более n или пока не встретится символ с.
http://all-ht.ru/inf/prog/c/func/memccpy.html
Главное, указывают, что массив БАЙТОВЫЙ, а int - это минимум 16 бит. Мне со стека слово снимать или байт?!
Буду тут выкладывать оптимизированные функции по мере написания. Просьба, по возможности, оперативно делать тестовые сборки интерпретатора. Ну что бы хоть-какой прогресс наблюдать, есть разница в размере или нет.
Главное, указывают, что массив БАЙТОВЫЙ, а int - это минимум 16 бит. Мне со стека слово снимать или байт?!
void *memccpy(void *d, const void *s, int c, size_t n)
слово. потому что описано как int - при вызове на стеке будет слово.
а массив - да, байтовый.
параметр с описан как инт с простой целью - ты можешь указть его равным -1 и тогда ни один символ строки не будет равен c.
Error404
24.11.2014, 10:54
Error404, как кросс средство (полукросс) хорошо использовать этот эмуль:
http://homepage3.nifty.com/takeda-toshiya/cpm/index.html
он под винду. в нём сборка многих исходников hitech-c просто в пару секунд пролетает. при этом есть исходники, можно допиливать на своё усмотрение. удобна!
да, зачисти свою личку, а то даже сообщение не отправить тебе.
Я пользуюсь пока вот таким эмулятором под винду (http://zx-pk.ru/showpost.php?p=751217&postcount=5) - он умеет возвращать винде код завершения HitechC, что нужно для make.
Личку с дикими сожалениями почистил, т.к. похоже увеличения ящика не дождаться.
Лично, я готов переписать все либы на асме :) Там даже то, что изначально на асме, как будто, нарочно писалось, чтобы памяти больше занимало :)
Токо это долго будет, не меньше месяца (если загонюсь).
ASM-оптимизацию для либ я думаю все равно когда-то делать придется даже если и не из-за размера кода, то из-за быстродействия. Только бы ошибок не наделать. :)
Будь добр, поделись образом "среды" с хайтеком. Кстати, может ли он ассемблерный файлы выдавать, или сразу непосредственно в бинарники компилит?
Кстати, наверное, можно будет этот CP/M HiTech и к Code::Blocks прикрутить.
Среды как таковой я не делал, просто использую ProgrammersNotepad (http://www.pnotepad.org/download/), где в проекте (фактически - списке файлов) описал используемые файлы и на кнопку F8 настроил сборку по make (Tools->Options->Tools->Scheme C/C++ -> Add)
Но чаще после внесения всех правок в PN просто запускаю make под cmd.
Тут мой рабочий каталог uzix (в нем UZIX.pnproj для примера), и каталог компилятора hitechC - на него должны быть настроены пути в переменных окружения PATH и CPMPATH:
Название: uzix-wrk.zip
Размер: 830.08 кб
Доступен до: 2014-12-24 10:52:45
http://rusfolder.com/42355049
Название: HTC-win.zip
http://rusfolder.com/42355053
Доступен до: 2014-12-24 10:52:46
Размер: 1.06 Мб
А вот уж кто делал среду из ProgrammersNotepad - так это b2m: и экранный отладчик, и вообще всё. Чуть не хватило чтобы взлететь (из-за кривого SDCC).
А вот уж кто делал среду из ProgrammersNotepad - так это b2m: и экранный отладчик, и вообще всё.
Делать среду из ProgrammersNotepad - тупиковый путь. Слишком уж закрытый интерфейс к кишкам, всё приходится делать черезж. Я сейчас присматриваюсь к Eclipse, плагин для прикручивания sdcc в инете есть, но он датируется 2006-м годом, т.е. не актуальный (там даже манифестов нехватает, чтобы он нормально запустился в последних версиях Eclipse). Но с помощью напильника его можно прикрутить. У меня даже получилось собрать fuzix под виндой, пришлось однако править Makefile и собрать под винду binman.
Кстати, виндовая версия sdcc ругается на конструкции типа: (char*)statloc, если statloc определён через #define statloc (int *)udata.u_argn1, такое встречается однажды в syscall_proc.c в процедуре waitpid.
То ли препроцессор дурит, то ли компилятор не может обработать (char*)(int*)udata.u_argn1.
Лично, я готов переписать все либы на асме :) Там даже то, что изначально на асме, как будто, нарочно писалось, чтобы памяти больше занимало :)
Вот список всех используемых интерпретатором библиотечных функций c размерами. Я, честно говоря, вообще не вижу смысла переписывать мелочь. Всякие "вечные" вещи типа memcmp ещё может быть - ради скорости. Но ради объема надо резать malloc, vprintff и vfscanf.
3224: _vfscanf
2007: _vfprintf
1328: _malloc
658: _exit
641: _putenv
595: _fflush
512: _strerror
463: _isatty
413: _fread
351: _fgets
331: _fgetc
326: _readdir
285: _fputc
251: _opendir
243: _free
205: _ungetc
205: _memset
196: _atoi
189: __modulong
167: _getenv
129: _getcwd
128: __divulong
126: _memcmp
115: _itoa
114: _closedir
110: _ultoa
110: ___mini_malloc
100: _on_exit
98: _strncpy
93: _strchr
84: _calloc
82: _stat
82: _perror
82: _ltoa
81: _lseek
79: _memcpy
69: ___do_exit
67: ___stdio_close_all
66: _strcmp
61: _fstat
49: _sscanf
43: _strcat
39: ___stdio_init_vars
37: _printf
36: _toupper
36: _tolower
23: _wait
15: _atexit
Ну, vfprintf и vfscanf это классика, это они ещё наверное floating point не прицепили :)
Я, честно говоря, вообще не вижу смысла переписывать мелочь. Всякие "вечные" вещи типа memcmp ещё может быть - ради скорости. Но ради объема надо резать malloc, vprintff и vfscanf.
Понятное дело. Но мне надо "разогнаться", поэтому начинаю с маленьких процедур. В конечном итоге, их надо будет ВСЕ переписать на асм. Кроме того, выигрыш в memcmp составил 94(!) байта, - дюжина таких мелких п/п - вот и килобайт освободится.
Error404
24.11.2014, 16:42
Понятное дело. Но мне надо "разогнаться", поэтому начинаю с маленьких процедур. В конечном итоге, их надо будет ВСЕ переписать на асм. Кроме того, выигрыш в memcmp составил 94(!) байта, - дюжина таких мелких п/п - вот и килобайт освободится.
Только надо смотреть как написаны исходные процедуры. Например, копирование блока памяти можно делать простое (выразится только в LDIR), а можно с учетом перекрытий исходного и приемного блоков - и там по условию уже будут и LDIR и LDDR,
---------- Post added at 16:27 ---------- Previous post was at 16:26 ----------
Вот список всех используемых интерпретатором библиотечных функций c размерами. Я, честно говоря, вообще не вижу смысла переписывать мелочь. Всякие "вечные" вещи типа memcmp ещё может быть - ради скорости. Но ради объема надо резать malloc, vprintff и vfscanf.
И exit какой-то большеватый ИМХО.
---------- Post added at 16:42 ---------- Previous post was at 16:27 ----------
Делать среду из ProgrammersNotepad - тупиковый путь. Слишком уж закрытый интерфейс к кишкам, всё приходится делать черезж. Я сейчас присматриваюсь к Eclipse, плагин для прикручивания sdcc в инете есть, но он датируется 2006-м годом, т.е. не актуальный (там даже манифестов нехватает, чтобы он нормально запустился в последних версиях Eclipse). Но с помощью напильника его можно прикрутить. У меня даже получилось собрать fuzix под виндой, пришлось однако править Makefile и собрать под винду binman.
И fuzix и сборка с помощью SDCC усложнены даже в сравнении с Uzix/HiTech (не говоря уж об Uzi). Я поэтому пока к fuzix не подступался. Лично мое мнение: не должен быть компилер таким корявым и недружелюбным как SDCC.
Но еще до эпопеи с ProgrammerNotepad я стваил и Эклипс и плагин для SDCC. Ну что сказать: громоздко и минимум возможностей, фактически нечто демонстрационное как к Эклипсу прикручивать компилятор. Тут кто-то должен серьезно приложить руки, чтобы этим можно было пользоваться. И оно потом еще и развалиться будет с выходом каждой очередной "улучшенной" SDCC, 146% даю.
И оно потом еще и развалиться будет с выходом каждой очередной "улучшенной" SDCC, 146% даю.
Не должно - от sdcc требуется только выводить варнинги/ошибки в стандартном виде. Этот функционал там испокон веков, и не менялся вроде бы вообще.
С Eclipse хуже другое - он слишком умный. Я пытался его скрестить с gdb-z80 и gdbserver, но не вышло оттого, что эклипс лезет и пытается самостоятельно распарсить выходной бинарник, прежде чем отдать его gdb. Причем, собака, из форматов понимает только PE и ELF.
По поводу шелла ssh: первое, что надо сделать - выкинуть sscanf, она используется только как делитель строки на подстроки идущие через пробел. Буферы cmd и arg заменить на указатели, строку делить прямо в буфере buf (он потом используется, но аргументы там уже не нужны). Сэкономим порядка 3Кб.
Кому интересно - вот загрузчик для пентевы и образ с ядром.
Ядро должно иметь имя fuzix.b.
Загркзчик - обычный хобетный файл, который пентева умеет по Enterу запускать.
Зависает: кажет на экране мусор и 4 вертикальные полосы, шириной 8 знакомест.
Зависание происходит после загрузки (на экран выводится какая-то таблица).
Причем, если выставить в пентеве 14МГц, то после "матраца" экран очищается и в ЛВУ печатается какое-то слово, затем сразу сбрасывается.
У меня конфигурация baseconf 0.55b версия вроде. Так?
yurymerkulov
25.11.2014, 12:19
Мужики, программировать совершенно не умею, но люблю Linux, поэтому слежу за веткой с предыханием :) Можете считать, что пока вы запускаете ОС, как минимум, один человек-фанат стоит у сцены и машет зажигалкой. :)
Ото всей души желаю вам запустить нормально Fuzix на Z80-железе.
как минимум, один человек-фанат стоит у сцены и машет зажигалкой. :)
+1 c фонариком :)
CodeMaster
25.11.2014, 13:43
программировать совершенно не умею, но люблю Linux
Программировать умею совсем чуть-чуть, Linux не понимаю совсем, но зажигалкой машу ;-) Мне всегда интересно наблюдать за подобным, всегда возникает мысль, "а если..." это было бы 20-25 лет назад, железо-то по сути тоже.
как минимум, один человек-фанат стоит у сцены и машет зажигалкой.
+1 На дню раз 20 страничку с этим тредом обновляю.
У меня конфигурация baseconf 0.55b версия вроде. Так? Не знаю :)
Блин, ну чего ты не под тсконфу начал писать!
Нажми Ctrl+Alt+F12. :))).
---------- Post added at 16:22 ---------- Previous post was at 16:20 ----------
Начал переписывать vfprintf. Страшно.
SfS, +1 за тс конфу
да какая разница какая конфа? там отличие всё пока - каким портом страницы щёлкать. будет по запускаться - толгда можно хоть ТС хоть в лес...
а то это всё равно что обсуждать какие шторы на окна повешать в доме, в котором ещё фундамента нет и незнамо когда будет.
Реал, ERS 0.55f, конфа 2в1 - кернел грузится, полет нормальный.:v2_thumb:
Error404
25.11.2014, 18:42
Где в процессах размещается udata (по карте памяти)?
Интересует более версия 60к-процессов, но и другие примеры тоже интересны
Где в процессах размещается udata (по карте памяти)?
Интересует более версия 60к-процессов, но и другие примеры тоже интересны
В небанкуемой области - в самых верхних 4к. Вроде как с #F200.
Error404
25.11.2014, 19:17
В небанкуемой области - в самых верхних 4к. Вроде как с #F200.
Но она же должна быть у каждого процесса своя? Или как?
И при межстраничном вызове (из процесса в ядро) копироваться из страницы процесса в страницу ядра. Или как вариант, в общей памяти должно лежать столько udata-ов, сколько процессов в ОЗУ, каждый из процессов пишет в свою по вычисляемому указателю, и при переключении контекста ядро будет брать нужную UDATA по указателю, вычисляемому в зависимости от того в какой 60-к страничке сейчас выполняется код процесса (чтобы избежать межстраничного копирования). Правда не известно что быстрее: скопировать 119 байт между страниц, или работать по указателю и в процессе и в ядре.
Но она же должна быть у каждого процесса своя? Или как?
И при межстраничном вызове (из процесса в ядро) копироваться из страницы процесса в страницу ядра.
А, понял, ты про копию? Она называется U_DATA_STASH и лежит в #ED00-#EFFF. Самая вершина банки процесса.
А UDATA c 0xF000, я ошибся.
Загрузчик ядра напрямую с SD-карты (ПЕНТЕВА).
Там же его исходники.
http://forum.nedopc.com/download/file.php?id=2040
В общем - научил вроде пока костыльно видеть FUZIXFS на SD - всегда второй главный раздел. Hello World оттуда запустился. форкается. Остальное - завтра.
Зависает: кажет на экране мусор и 4 вертикальные полосы, шириной 8 знакомест.
Зависание происходит после загрузки (на экран выводится какая-то таблица).
Причем, если выставить в пентеве 14МГц, то после "матраца" экран очищается и в ЛВУ печатается какое-то слово, затем сразу сбрасывается.
Всё робит,- просто, я трдшник не монтировал :)
Непонятки. bank16.c и bank32.c собираются. Но они ж не нужны. может их както выпилить вообще?
Непонятки. bank16.c и bank32.c собираются. Но они ж не нужны. может их както выпилить вообще?
Они не линкуются. Все, что линкуется - в uzi.lnk.
Срочно нужен ассемблерный листинг из vfprintf.c для HC08.
ассемблерный листинг из vfprintf.c для HC08
Они не линкуются. Все, что линкуется - в uzi.lnk.
По-хорошему, то, что не линкуется и собираться не должно. Ну да бог с ним.
Я Makefile немного причесал и добавил скрипт для определения путей SDCC.
Плюс - в libclean вставил автоопределение местоположения z80.lib
Для облегчения жиззни - слей это к себе в репозиторий.
А то SDCC у одних - в /opt у других в /usr/local. - каждый раз ручками пути менять - упаришься.
---------- Post added at 14:11 ---------- Previous post was at 14:09 ----------
Слушай, а для работы инита обязательно нужен tty1 ?
Слушай, а для работы инита обязательно нужен tty1 ?
А какие проблемы?
mknod /dev/tty1 20666 257 - и вуаля, создали tty1
---------- Post added at 13:21 ---------- Previous post was at 13:18 ----------
Я Makefile немного причесал и добавил скрипт для определения путей SDCC.
Плюс - в libclean вставил автоопределение местоположения z80.lib
Да, я всё хочу это в апстрим запушить.
Один твой коммит уже там :) https://github.com/EtchedPixels/FUZIX/commit/a13208b Вычищать из него, правда, пришлось практически всё - ты одновременно и обрезание \r закоммитил. Это не круто, когда такие принципиально разные вещи в одном коммите пушатся.
Error404
26.11.2014, 11:26
А какие проблемы?
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? Почему такие большие значения?
А что есть цифры 20666 и 257? Почему такие большие значения?
20666 - права. Символьное устройство, доступ всем на чтение-запись.
257 = 256 + 1, major = 1, minor = 1
Вычищать из него, правда, пришлось практически всё - ты одновременно и обрезание \r закоммитил. Это не круто, когда такие принципиально разные вещи в одном коммите пушатся.
Это да. Но вырезание '\r' вещь для линукса необходимая.
Кстати, там кроме вырезания ещё и автоформатирование С-файлов. Иначе некоторые вообще нечитаемы были.
---------- Post added at 14:34 ---------- Previous post was at 14:31 ----------
А какие проблемы?
mknod /dev/tty1 20666 257 - и вуаля, создали tty1[COLOR="Silver"]
да я сейчас на работе, так что просто исходники рассматриваю) про mknod мы знаем. нас етому учили)
Кстати, там кроме вырезания ещё и автоформатирование С-файлов. Иначе некоторые вообще нечитаемы были.
Это у тебя длина табуляции стоит неверная :)
Я лично стараюсь вообще эту всю мелочь типа концов строк и форматирования не трогать. Смысла мало - ну, если компилятор не ругается, - а риск нарваться на merge conflict вырастает на порядки.
Error404
26.11.2014, 13:07
Подскажите еще вопросик: как (где) в пространстве процесса FUSIХ хранятся:
- пареметры переданные программе (процессу) при запуске (т.е. то, что в CP/M кладется по адресу 0x80..0xFF)
- переменные окружения (environment)
Подскажите еще вопросик: как (где) в пространстве процесса FUSIХ хранятся:
- пареметры переданные программе (процессу) при запуске (т.е. то, что в CP/M кладется по адресу 0x80..0xFF)
- переменные окружения (environment)
Судя по всему, прямо под UDATA. Функция wargs их кладет (link (http://github.com/EtchedPixels/FUZIX/blob/master/Kernel/syscall_exec.c#L220)). Любопытно, пересекается с UDATA_STASH. Впрочем, она 768 байт, всем хватит.
Error404
26.11.2014, 13:20
Судя по всему, прямо под UDATA. Функция wargs их кладет (link (http://github.com/EtchedPixels/FUZIX/blob/master/Kernel/syscall_exec.c#L220)). Любопытно, пересекается с UDATA_STASH. Впрочем, она 768 байт, всем хватит.
вот кстати это тоже зацепило: 768 байт, откуда, зачем? Ведь на UZIX, к примеру, sizeof(udata)=119 байт.
Или он расширил ее на размер стринговых параметров которые в некоторых функциях (в мало каких функциях, иногда, один-два параметра char[]) передаются ядру - чтобы оно сразу копировалось в страницу ядра?
вот кстати это тоже зацепило: 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 байт на стек для прерывания (интересно нафига).
вот кстати это тоже зацепило: 768 байт, откуда, зачем? Ведь на UZIX, к примеру, sizeof(udata)=119 байт.
Стек процесса ещё рядом лежит.
А вот стек прерывания... Окей, зачем его в common держать - я понимаю. Но зачем копировать туда-сюда?
---------- Post added at 16:05 ---------- Previous post was at 16:01 ----------
А хотя догадываюсь. Эти 256 байт - это стек прерывания только на время прерывания. В остальное время это как раз хранилище переменных окружения и аргументов командной строки.
Это у тебя длина табуляции стоит неверная :)
Символ \t - верен по определению)
Читает инит с флешки, выполняет и затыкается на ulink("/etc/mtab"); примерно
Читает инит с флешки, выполняет и затыкается на ulink("/etc/mtab"); примерно
Может, на чтении /etc/passwd? Просто у меня дело доходило до спауна шелла. Добавь в passwd строчку root:::/root:/bin/sh
пишет "panic: corrupt inode" хотя сам инит запускает(
Error404
27.11.2014, 00:47
пишет "panic: corrupt inode" хотя сам инит запускает(
fsck ?
пишет "panic: corrupt inode" хотя сам инит запускает(
Я бы драйвер fdd проверял в таком случае. Corrupt inode - это же когда запрошен блок, где должен быть айнод, но его там не оказалось.
Я бы драйвер 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 в мой эмулятор нетривиальна, тут я думаю, как это всё это упростить, в идеале нужно догружать ядро с диска).
Лень было допиливать свой эмулятор, чтобы он читал из файла по обращению к портам, проще оказалось сделать обращение к trdos. Вот выкладываю результаты, в моём эмуляторе работает (загрузка fuzix в мой эмулятор нетривиальна, тут я думаю, как это всё это упростить, в идеале нужно догружать ядро с диска).
ЭТОТ инит у меня прекрасно с SD грузится и работает.
Я про ноормальный ИНИТ
Error404
27.11.2014, 15:19
Лень было допиливать свой эмулятор, чтобы он читал из файла по обращению к портам, проще оказалось сделать обращение к trdos. Вот выкладываю результаты, в моём эмуляторе работает (загрузка fuzix в мой эмулятор нетривиальна, тут я думаю, как это всё это упростить, в идеале нужно догружать ядро с диска).
А орионовский эмулятор твой и допиливать не надо будет! ;) Там с уровнем дисков уже в ажуре всё. :rolleyes:
Подключайся?
Я пользуюсь пока вот таким эмулятором под винду (http://zx-pk.ru/showpost.php?p=751217&postcount=5) - он умеет возвращать винде код завершения HitechC, что нужно для make.
Среды как таковой я не делал, просто использую ProgrammersNotepad (http://www.pnotepad.org/download/), где в проекте (фактически - списке файлов: 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
Исходники библиотек тоже есть, если кому-нибудь будет интересно - выложу. С библиотеками пока не занимался.
Error404
27.11.2014, 15:24
Ядро у меня - обычная 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) как параметр командной строки.
В общем косяк гдето в реализации библиотеки форка чтоли...
простая ассемблерная программа- форкается.
а вот на С - фига.
Error404
27.11.2014, 18:22
В общем косяк гдето в реализации библиотеки форка чтоли...
простая ассемблерная программа- форкается.
а вот на С - фига.
Может со стеками что-то?
Я вот тоже думаю:
Когда был UZIX или UZI, у которого ядро (верхние 32к от 64к-шного пространства) и текущий обрабатываемый процесс (нижние 32к от 64к-шного пространства) всегда были все же в общем пространстве, то такие вещи как куда установлен стек при вызове unix() и куда установлен стек в момент наступления прерывания - они не имели критического значения (хотя стек и переставляется на временный в определенные моменты). Когда же ядро и процессы разносятся в разные страницы памяти, это уже становится попоболью.
А вот еще вопрос на засыпку. Ну ладно, стек обработчика прерывания можно назначить внутри страницы ядра, при вызове unix() тоже можно запоминать, переставлять и восстанавливать потом стек. Но есть еще сигналы. Процессы регистрируют обработчики, которые вызываются, условно, произвольно. Ядро сделает вызов в другую страницу, но куда-то надо поставить и стек, чтобы он не пересекался с предыдущими двумя.
---------- Post added at 18:20 ---------- Previous post was at 18:17 ----------
У Алана вообще работоспособное то что-то было кроме ядра? В его блоге (https://plus.google.com/111104121194250082892/posts/a2jAP7Pz1gj) никаких обновлений. Может еще блог есть, а я и не знаю?
---------- Post added at 18:22 ---------- Previous post was at 18:20 ----------
Кстати, если кто там зареган - черкните пару строк. Человеку надо понимать, что его проект интересен: это стимулирует не бросить всё к такой-то матери.
УРААААА! НАШЁЛЛ!!!
Просто в dofork() я портил регистр а инверсией. Номер страницы инвертировался для вывода в пентевный регистр.
Ещё одна команда cpl спасла меня.
УРААААА! НАШЁЛЛ!!!
Просто в dofork() я портил регистр а инверсией. Номер страницы инвертировался для вывода в пентевный регистр.
Ещё одна команда cpl спасла меня.
Ну что, бэйзконфа сыграла с тобой злую шутку? ;)
Блин, ну чего ты не под тсконфу начал писать!
Нажми Ctrl+Alt+F12. :)))
И это было бы смешно, когда бы не было так грустно...
скорее невнимательность. мало ли где как накосячишь.
Но есть еще сигналы. Процессы регистрируют обработчики, которые вызываются, условно, произвольно. Ядро сделает вызов в другую страницу, но куда-то надо поставить и стек, чтобы он не пересекался с предыдущими двумя.
Стек прерывания на время обработки сигналов уже не нужен, его можно смело загадить. Так, по-моему, и происходит.
Кстати, если кто там зареган - черкните пару строк. Человеку надо понимать, что его проект интересен: это стимулирует не бросить всё к такой-то матери.
Я ему пулл-реквесты (https://github.com/EtchedPixels/FUZIX/pulls?q=is%3Apr+is%3Aclosed) шлю, это более красноречиво :)
За ходом разработки там же можно наблюдать, он подробные комментарии к ключевым коммитам пишет.
Error404
27.11.2014, 19:59
За ходом разработки там же можно наблюдать, он подробные комментарии к ключевым коммитам пишет.
А как это смотреть?
А как это смотреть?
https://github.com/EtchedPixels/FUZIX/commits/master
скорее невнимательность. мало ли где как накосячишь.
Не в обиду: мыши кололись, плакали, но продолжали жрать кактус! :)
---------- Post added at 22:10 ---------- Previous post was at 21:55 ----------
УРААААА! НАШЁЛЛ!!!
Образ, - образ рабочий давааай!
https://github.com/EtchedPixels/FUZIX/commits/master
запустил шелл, предварительно удалив из него сканф и кучу другой фигни. работает, но почемуто не пишет подказку sh#.
Что-то с флушем наверное.
Не в обиду: мыши кололись, плакали, но продолжали жрать кактус! :)
Знаешь.. Мне кажется, что твоя ненависть к инверсии бит - это уже проблема более медецины, чем техники:)
Образ, - образ рабочий давааай!
Да. Вот.
Инструкция:
1. Взять флешь и создать ДВА раздела.
- Раздел 1 основной - FAT32.
- Раздел 2 основной - Linux. Обязательно НЕ-FAT32!
2. Скопировать ядро и загрузчик на раздел 1 (fusix-boot.$C fuzix.bin)
3. Залить на раздел 2 ФС FUZIX. Например, если флешка - устройство /dev/sdb, то делаем это так:
sudo dd if=fuzix.img of=/dev/sdb2 bs=512
Все.
Далее втыкаем флешь во пентеву и запускаем fusix-boot.$C
Жмём:
bootdev: 0
login:root
ssh# printenv (это пример, печатает переменные окружения)
многие команды ещё не работают (типа ls)
Команды, которые уже есть:
basename cat chmod cp date du false init ll mkdir more od printenv pwd rmdir ssh sync tr uue which
bd chgrp chown cut dirname echo id kill ln mknod mv patchcpm prtroot rm sleep su touch true wc whoami
Короче - надо разработать модульные драйвера. Иначе памяти не будет.
Просто у меня есть полный драйвер PS2 клавы. С поддержкой режимов и раскладок. но там таблиц много. Только отдельная страница спасёт.
CityAceE
28.11.2014, 10:21
Затаив дыхание слежу за темой. Но до конца пока не могу понять, сможет оно в итоге полноценно взлететь на стандартной конфигурации (128k+TR-DOS) или нет?
Затаив дыхание слежу за темой. Но до конца пока не могу понять, сможет оно в итоге полноценно взлететь на стандартной конфигурации (128k+TR-DOS) или нет?
Да, если перешить ПЗУ.
На клонах с отключаемым ПЗУ (типа Скорпиона) сможет, думаю, и так.
Ну и попробую на +3 портировать. Там сложнее, там ПЗУ отключается, но при этом банкинг в верхнем окне не работает.
Затаив дыхание слежу за темой. Но до конца пока не могу понять, сможет оно в итоге полноценно взлететь на стандартной конфигурации (128k+TR-DOS) или нет?
Пилим либы. Надеемся. ;)
Error404
28.11.2014, 12:04
Это ж С. Там "Hello world" компилируется в несколько килобайт (если без шаманства). Поэтому для стандартного 128к оно хотя и будет, но с окном 16к (с ограничением 16к на процесс) - это не жизнь. На клонах с окном 48к..64к оно уже может быть полноценной ОС (одним окном или несколько окон по 16к - не суть), где портируя код с "больших систем" не надо будет выкидывать все printf и scanf.
Короче - надо разработать модульные драйвера. Иначе памяти не будет.
Просто у меня есть полный драйвер PS2 клавы. С поддержкой режимов и раскладок. но там таблиц много. Только отдельная страница спасёт.
Саму инфраструктуру разрабатывать гемор, конечно. Но для единичного случая же все очень просто-
Перемещаешь devtty куда-нибудь ниже #C000.
Выкидываешь весь код опроса спектрумской клавы, пишешь переключение банки и вызываешь свой.
...
Профит!
---------- Post added at 14:10 ---------- Previous post was at 14:09 ----------
где портируя код с "больших систем" не надо будет выкидывать все printf и scanf.
Видится реальным выкинуть либу в отдельную страницу(-цы).
Error404
28.11.2014, 12:33
Видится реальным выкинуть либу в отдельную страницу(-цы).
Что-то типа shared lib с поздним связыванием?
Или либа-wrapper с функциями-пустышками, единственная цель которых сделать вызов в другую страницу странслировав туда параметры, а оттуда - код завершения. Можно, накладные расходы правда будут как на переключение, так и на обслуживание указателей на массив оставшийся в странице процесса (для тогоже sscanf), но не такие критичные в сравнении с тормозными п\п вывода на экран.
Если получится, то это будет полезно и для реализаций с 48..64к страницами.
Или либа-wrapper с функциями-пустышками, единственная цель которых сделать вызов в другую страницу странслировав туда параметры, а оттуда - код завершения.
Да, вот это. В этом случае даже не требуется править ядро.
Powered by vBulletin® Version 4.2.5 Copyright © 2024 vBulletin Solutions, Inc. All rights reserved. Перевод: zCarot