Вести с полей: нашелся храбрец, который смог собрать версию под ZX Spectrum 128K + DivIDE и запустить. Краткая инструкция и бинари для желающих повторить в теме https://github.com/EtchedPixels/FUZIX/issues/756
Вести с полей: нашелся храбрец, который смог собрать версию под ZX Spectrum 128K + DivIDE и запустить. Краткая инструкция и бинари для желающих повторить в теме https://github.com/EtchedPixels/FUZIX/issues/756
Den1982(06.11.2019)
С любовью к вам, Yandex.Direct
Размещение рекламы на форуме способствует его дальнейшему развитию
Столько труда чтобы 2/3 команд выдавали "Out of memory". Сразу было понятно, что надо искать другую модель чем где процессы не более 16к. При наличии быстрого нoсителя (IDE) даже классический UZI где каждый процесс при переключении выгружается, и то более пригоден, на MSX работали же в такой архитектуре. Хотя конечно, просто нужно нормальное окно диспетчера. Чего уж не впилить пару МСХ, что-то религиозное что ли, типа как носить вериги?Сообщение от Eltaron
Лучше сделать и жалеть, чем не сделать и жалеть.
Некоторые из моих поделок тут: https://github.com/serge-404
Там 32 кило на процесс (учитывая три страницы под ядро и одну под экран и низкоуровневые процедуры, остатка нам хватает на целых 2 процесса). Процессор LDIRится так, что дым идёт. Ну, по крайней мере так было в v0.2.
Это я в первоначальном порте делал для процессов 7 окон по 16 кило, но Алан с тех пор много перепилил. Он между 0.2 и 0.3 очень много для спектрума там делал.
Сточить ULA и припаяться к транзисторам?Хотя конечно, просто нужно нормальное окно диспетчера. Чего уж не впилить пару МСХ, что-то религиозное что ли, типа как носить вериги?Или делать картридж с RAM, который будет содержать нужный маппер? Если считать, что таргет-платформа - это не обмотанный мгтфом пентагон, а классический спек, то все решения по добавлению маппинга выглядят как жуткие костыли. Ну и в целом, софт без железа (ну то есть не работающий из коробки) - это ничуть не лучше популярного у нас на форуме подхода "железо без софта". Фузих должен работать на любом спектруме, чтобы охватить максимальную аудиторию. В идеале он вообще с кассеты должен уметь грузиться
Но! На самом деле тот маппер, о котором ты говоришь, он уже поддержан. Причем, уже лет пять: https://github.com/EtchedPixels/FUZI...rnel/bank16k.c
То есть если кто-то захочет-таки сделать хардварную доработку, он просто заменит текущий маппер на новый, ну и допишет немного кода переключения. Это ж ерунда по сравнению с необходимостью резать дорожки и клеить дохлых тараканов.
В порте для пентевы именно этот маппер и использован - https://github.com/EtchedPixels/FUZI.../fuzix.lnk#L37
Да, кстати, если кто не следит (будто кто-то следит
Последний раз редактировалось Eltaron; 07.11.2019 в 07:56.
До такой степени конечно нет, но эту тему почитываем, т.ч. релизь новости здесь.
"Во времена всеобщей лжи говорить правду - это экстремизм" - афоризм.
В таком варианте уже как-то можно жить. Один хрен, под большие вещи типа VI не хватает и 60к (ибо большое не значит хорошее как оказалось при ближайшем рассмотрении).
- - - Добавлено - - -
Просто как оказалось, никому кроме 2-3 чудаков оно не надо.
- - - Добавлено - - -
Хомячков оно могло привлечь в виде UZIX где был нормальный TCP/IP, а не обрубок от uIP как в FUZIX, и можно было даже с учетом того что от него утрачены исходники провести реверс (учитывая какие человекочасы уже затрачены на FUZIX, зачастую имея на выходе нечто более негодное).
Лучше сделать и жалеть, чем не сделать и жалеть.
Некоторые из моих поделок тут: https://github.com/serge-404
Эммм, откуда инфа? Сокеты как сокеты, где там обрубок, тем более uIP?
Так там вроде никогда другого и не было? Был обрубок uIP Дункеля, причем прикрученный не в ядро а как-то сбоку. Ну если не считать первых заглушек для программирования верхних уровней стека без наличия нижних. По крайней мере полгода-год назад когда я еще находл в себе силы перекапывать эту слабоструктурированную кучу-малу. Если переписали, то интересно как (не слышал что для 8-биток родили какие-то новые реализации стека в последние год-два). А если нет, и на уровень хидеров выведено нечто а-ля сокеты, уже неинтересно если унутре по-прежнему оно (наелся я этого uIP в свое время, плевались все кому надо было что-то чуть более сложное чем веб-сервер из примеров Дункеля или Контики где оно интегрировано и всё уже написано самим автором).
А обрубок (помимо дикой упрощенности uIP в ущерб функционалу и производительности), потому что IP должен быть в ядре (чего у них не было сделано), а не в либе целиком. Чтобы процессы читая сокет блокируемо или неблокируемо, по этому типу ядром автоматом переводились в саспенд освобождая слайсы ЦПУ, или будились (доставались из свапа) при поступлении данных. А так как было сделано, так это я и сейчас могу прилинковать либу uIP прямо в приложение, благо порт есть, но это совсем не то чего хотелось бы. А нет, не могу, начну писать код под uIP и затошнит.
- - - Добавлено - - -
Это остаточные знания. С интервалом раз в год поглядываю в исходнике на ГИТ как там дело движется с TCP/IP т.к. это единственное что всерьез интересует меня в том проекте на предмет портануть в UZIX, каждый раз дико матерясь т.к. этот модуль лежит как-то хрен сразу найдешь. И в последний раз с год назад там все еще был код от uIP (я его хорошо знаю т.к. портировал на Орион, да и копирайты нам все на месте) и никакого другого я ни разу не нашел (если не считать версию от 2015 года где был только скелет верхних уровней стека с каким-то дурным роутером в PC вместо реализации собственно IP). Сейчас снова полез уточнить, вдруг переписали и убрали uIP, и снова по-быстрому не нахожу там где по логике расчитывал этот модуль найти (постоянная история), чтоб их так перетак.
Последний раз редактировалось Error404; 07.11.2019 в 15:14.
Лучше сделать и жалеть, чем не сделать и жалеть.
Некоторые из моих поделок тут: https://github.com/serge-404
Имея информацию, что оно там не совсем в ядре, я сходу нашёл: FUZIX/Applications/netd
В ядре только драйвера устройств.
По факту там обычные сокеты - bind, listen, connect, recvfrom и т.д. (https://github.com/EtchedPixels/FUZI.../netdev.h#L102)
Всё, я понял. Ты об этом, наверное - https://sites.google.com/site/cocobo...thecoconiccardБыл обрубок uIP Дункеля, причем прикрученный не в ядро а как-то сбоку.
Автор этого дела сам пишет, что это слепленный за вечер хак и что он всё сделает нормально, когда разберется, как писать сетевые драйверы.
Пока ещё не сделал. Вот этот хак - https://github.com/EtchedPixels/FUZI...ns/netd/netd.c
И со стороны ядра фальшивый драйвер сетевого интерфейса - https://github.com/EtchedPixels/FUZI...t/net_native.c
Довольно изящно, кстати
Изящно потому, что не нужно писать под uIP. Крутится там себе где-то, и бог с ним. Код под fuzix работает только с сокетами и знать ничего про uIP не знает.А нет, не могу, начну писать код под uIP и затошнит.
Ну и не стоит думать, что это единственный способ сетевого взаимодействия. Можно не тянуть себе в систему весь этот uIP, а делать всё через "настоящие" драйверы, которые есть, к примеру, для W5x00 и ENC28J60. Всё тут: https://github.com/EtchedPixels/FUZI...Kernel/dev/net
Error404(08.11.2019)
Эту тему просматривают: 1 (пользователей: 0 , гостей: 1)
Ваши права
Ответить с цитированием
