Просмотр полной версии : Пишем свою ОС. Практика
Пишем свою ОС.Практика.
(создано по мотивам бесед из удалённой темы Q-DOS).
Лирическое вступление
Если начинающий кодер хочет попробовать научиться писать игры, то он может почитать разные книги , например «Как написать игру для ZX-Spectrum на бэйсике» или более продвинутый вариант «Как написать игру для ZX-Spectrum на ассемблере». Книги на тему "Как написать операционную систему для ZX-Spectrum" к сожалению нет(или мне о такой книге неизвестно).Вот если бы во времена нашей юности у нас была подобная книга...
Так как же быть тем,кто хочет сделать свою операционную систему для нашего любимого Спектрума? Можно конечно обратиться к серьёзной литературе мирового уровня по разработке ОС и потратить несколько лет на изучение книг объёмом в сотни страниц, но к тому времени желание что-либо делать иссякнет,поэтому хочется уже сейчас,прямо сегодня,в крайнем случае в ближайшие выходные приступить к процессу создания «ОС Вашей мечты».Предлагаю не откладывать это дело в долгий ящик, и пока еще чего-то хочется - в этой теме начать учиться. Мы не будем сразу замахиваться на что-то глобальное,ведь все начинали с простых вещей,даже художники,чьи полотна признаны шедеврами,сначала рисовали на маленьких листочках бумаги или в блокноте. Поэтому предлагаю начать на самых простых примерах,и пусть первая версия ос для начала будет очень простая, примитивная, даже можно сказать — игрушечная, но главное не останавливаться на достигнутом, и потом сделать ещё одну версию,уже посложнее, а потом ещё одну и ещё одну и так, продвигаясь небольшими шажками - научиться делать операционные системы и если к тому времени у нас еще останутся силы/желание/свободное время, то мы сможем создать для нашего любимого компьютера свою собственную,и конечно же самую быструю,самую лучшую, НАСТОЯЩУЮ операционную систему, которой будет удобно пользоваться и которой мы все сможем гордиться.
Предлагаю не относиться к нижеизложенному слишком серьезно и воспринимать это обучение в игровой и приколисто-юморной форме.
Хочу обьявить эту тему территорией,свободной от флэйма, и каждому, кто придет сюда просто поразмышлять на тему "разработка ОС для Спектрума",мы скажем - "ну шо ты к нам приштал,эт наша пешошница".И предложим перейти в тему "Пишем свою ОС. Теория" в разделе "Концепции" и уже там высказать всё,что их душа пожелает. А сюда приглашаются те,кто действительно заинтересован сделать что-нибудь реально работающее (а если никто не придёт, буду потихоньку куковать в одиночестве).
Что бы оценить уровень своих познаний, можно поробовать поделиться ими с другими людьми,при этом будут обнаружены неоторые пробелы в тех или иных областях обсуждаемого предмета.
Предлагаю:
1)В процесе обучения сделать хотя бы одну настоящую ОС и больше не сомневаться на тему, есть ОС у Спектрума, или нет ОС. (какого уровня сложности она будет и какие у неё будут возможности — это уже другой вопрос).
2) Излагаемые факты из истории развития ОС,концепции осестроительсва будут максимально упрощены и из них будут выброшены незначащие (на мой взгляд) подробности.
3)Будем использовать технологии open source - т.е. юзать в наших проектах свободно распространяемые программы и драйвера с исходными текстами,а так же свои собственные уже существующие процедуры и старые наработки.
4) Продвинутым кодерам, случайно заглянувшим к нам на огонёк, просьба не удивляться,так как мы будем делать по возможности максимально просто,потому что Спектрум - простой в освоении компьютер, и хотелось бы, чтобы всё на нём было простым и удобным.
/////////////////////////////////////////////////////////////////////
Вообще хотелось бы начать сначала, но раз уже в теме Q-DOS начали обсуждать
быстрый драйвер дисковода, то рассмотрим его
---------- Post added at 21:47 ---------- Previous post was at 21:45 ----------
стоп. для скорпа была своя версия цпм. кроме того, разъясню в чём косяк совместимости. когда я говорил про работу с флопом из диапазона от 0 до 16383 (т.е. проще говоря из пзу или то что сидит на её месте), я имел ввиду довольно простую ситуацию. видиш ли, стартовый адрес для прог цпм = 100h.
так то была от МОА, а это от К.Фролова - я же упоминал:
Есть версия цпм 2.2 от К.Фролова для Пентагона с кеш-памятью от 16К(дополнительно в ней драйвер экрана для режима 512х192), она же работает на KAY-256/Scorpion-256 и в ней драйвер дискеты настроен на форматы цпм от МОА для устройств A и B, для цпм от АТМ на устройстве С и для дискет от Профи-цпм на устройстве D
все эти почти 16к могут быть свободно отведены под прогу юзера, за исключением моментов, когда юзер компилит её на другой адрес используя дерективы phase. но это отдельная песня. так вот. когда прога начинает чтото подгружать своё, какие то свои куски, что она делает? пральна, образщается к функции системы.
dos equ 5
open_f equ 15
ld c,open_f
ld de,myfcb
call dos
т.е. посути обращение идёт снова таки по адресу, который сидит гдето там...в области пзу ну или теневой озу (кэш). т.е. собсвтенно драйвера то там нет, всего лиш начала диспечера посути. окольными путями потом это всё погрузица. зхначит на этих клонах, для того чтобы всё работало нормально, нужно как минимум сохранять стэк пользователя, перекидывать всю юзерскую прогу от 100 до 3fff куда то там на свободное место, перекидывать драйвер дисковода на нужные адреса, отработать, потом всё вернуть на свои места. это как минимум тормоз,
хорошенькие "этюды" получаются :)
как максимум, не уверен что авторы тех версий цпм сталибы так извращаться.
думаю не стали бы.Если бы я делал,то бы сделал так:
1)Имеем "рулез" в виде Пентагона с кэш-памятью 32Кб - можем подключать 2 страницы по 16Кб с адреса 0
---------- Post added at 21:51 ---------- Previous post was at 21:47 ----------
первая страница кеша подключена когда работает программа
при вызове через call 5 происходит подключение 2-й страницы кеша - там все дрова и дискетные в том числе - юзаем прямое программирование ВГ93,грузим сразу весь сектор 1Кб сюда же и потом переносим нужные 128 байт в самый верх памяти, где сидит остатки bdos и bios (таблицы перехода там) - далее перепрыгиваем туда, подключаем первую страницу кэш, копируем эти 128 байт на адрес #0080 и возвращаемя в прогу (в случае если адрес DMA переставлен выше #4000 то сразу из 2-й страницы кеша копируем туда)
а поскоку прога не включаем IM2 - то дисковые операции пройдут успешно.
нет уж...звиняйте. таких тормозов нам ненужно.
не вижу никаких тормозов
---------- Post added at 13:42 ---------- Previous post was at 13:34 ----------
2)Имеем любой любой спек-128, у которого для доступа к ВГ93 нужно лезть к #3d2f, и при этом есть возможность подключить страницу ОЗУ на адрес 0
в этой странице начало проги - , а на #c000 - подключаем страница 1(или другая)
прога делает вызов call 5 - мы переплёвываемся на адрес в конце страницы #ffXX и отключаем страницу 0 - там теперь стандарное пзу
ну а далее обращаемя к #3d2f - таким образом,как это вделано в тысячах прог с турбо-лоадером и выполняем дисковую операцию, читаем сектор сразу в верхнюю страницу, где ядро (при DMA=#0080 или выше #C000 ) или в ниже если DMA от #4000-#BF80
потом принеобходимости переностим 128 байт вниз
И снова никаких тормозов[COLOR="Silver"]
---------- Post added at 22:04 ---------- Previous post was at 21:51 ----------
читаем сектор сразу в верхнюю страницу
нифига. вот тебе пример - если прога весит ну скажем 8 килобайт. дма сидит где то грубо говоря посередине и туда надо чтобы чтото погружалось. ммм?? лишнии проволочки с перемещениями и потом - кто тебе сказал что грузить мы будем немного? какой нить вордстар попросит погрузить килобайт 20 текста, ты что будеш по 128байт бросать туда сюда включая и выключая пзу, перемещая блоки?! вот я тебе и говорю что это тормоз!
ты просто не представляеш что такое грузить по 128 байт или там по сектору, потом махинации с переключениями и перебросками, созранениями всяякие, потом снова погрузка и т.д. я вот проделывал такие операции. я грузил и по 128байт и по 256 и по 512 а потом когда погрузил сразу по 16кб, вот тут то и увидел разницу. хотя она заметна уже на 128байт и на 512байт. приэтом я делал почти теже махинации..не совсем, но их хватало. в итоге файл весом всего то ничего 30 или 40 кб, грузился секунд наверно 10 - 15...а на финише когда переделал всё под корень, секунды полторы. а представь если файл ещё больше?! ну уж нафиг. хотя канечно, на 128м то куда. у стандартной цпм ТПА как правило не менее 50кб..обычно. на 128м наверно ещё меньше будет с учётом трдоса.
Вот смотри самый тяжелый вариант загружает с адреса пусть #0100 кусок длиной 62 Кб - т.е. впритык к TPA.
в случа пентагона с кэшем имеем то что я сказал выше - и после переключения во вторую страничку кеша мы подключаем на #C000 страницу 3 (пустую) и грузим в нее #3F00 байт,
далее подключам на #C000 страницу 0 (принадлежащюю программе и вней же в конце урезанные BDOS и BIOS) и грузим остаток файла 46,25 Кб с адреса #4000
далее включаем на адрес#C000 опять страницу 3, включаем 2-ю страницу кеша (на адрес 0)
и перед возвратом в программу копируем из #C000 на #0100 кусок длиной #3F00 байт (это 15.75 Кб)
Ну наверно надо уже мне сделать драйвер и оценить быстродейтсвие.
(Сделал и оценил(01-02.10) - мои теоретические рассуждения полностью подтвердились - работает БЫСТРО! )
2) В варианте с нулевой страницой чуть сложнее.
после вызова дисковой функции переходим на #FF00 (условный адрес BDOS)
Выполняем всё неоходимые подготовитльные операции по работе с диском.
сначала копируем с адреса #4000 в буфер BDOS кусок длиной 256 байт, на #4000 копируем турболоадер и переключалку страниц и идём туда на кусок по адресу #4000
отключаем страницу 0 с адреса 0 и включаем её на адрес #C000
грузим на адрес #C100 первые 15.75 Кб, далее включаем на #C000 страницу 1(это адресное простанство программы и с адреса #FF00 там BDOS&BIOS) и продолжаем загружать:
один сектор 256 байт во второй буфер в области BDOS и остальные 46 Кб грузим с адреса #4100
---------- Post added at 22:22 ---------- Previous post was at 22:04 ----------
теперь процедура которая была по адресу #4100 сделала своё дело и больше не нужна
переходим на процедуру внутри BDOS из которой мы уходили
далее перекидываем на адрес #4000 кусок длиной 256 байт из второго буфера (а сохранялимы их для случая загрузки выше чем #4000 - тогда бы мы перекидывали на #4000 из первого буфера)
подключаем страницу 0 на адрес ноль и переходим в неиспользованную область в районе до #0080 (там цпм не трогает нескоько десятков байт)
оттуда возврат в программу
итого пересылаем всего 256+256 байт на огромный кусок длиной 62 Кб
Вроде всё правильно
По прежнему не вижу тормозов - где же они?
Зет, ты сначала напиши, очени, а потом опусы составляй...
Хоть и ваша песочница, но действительно:
Сорри, но нужна ли вообще ОС?
Я имею в виду - не лучше ли будет для совместимости просто ХОРОШАЯ надстройка над TR-DOS?
Ну типа как Win3.11 для MS-DOS...
На её ошибках можно избежать лишних траблов...
И никто не запрещает прилепить туда что угодно...
На уровне доп утилит например.
И даже (псевдо) многозадачность...
На мой взгляд - что-то типа MagOs, которая живёт как можно выше.
А ещё лучше - резидент, который по-быстрому разберётся что к чему и загрузит с диска что надо (предварительно сохранив, то что работало. Снапшоты уже дело привычное, их можно дофига держать и довольно сносно коммутировать)
zksystem
17.01.2010, 11:59
Почитал, посмеялсо :)
на проце без MMU ось делают уже :)
oOOo... а что, такого не бывает что ли?? да и страницы с #c000 чем не мму?
zksystem
17.01.2010, 14:28
Уважаемый psb, Вы что такое MMU знаете? При стиле написния программ на спеке без защиты памяти получится не ось, а гамно!
забавно даже:)
давным давно существует и юзается на контролерах uClinux без защиты памяти, и все ок. почему на спеке без защиты памяти будет все критично??
а страницы образуют некое подобие виртуальной памяти. вполне себе может получиться юзабельная система.
Error404
17.01.2010, 16:40
забавно даже:)
да просто классический случай junior-а форума. Только что наблюдал такое же в соседней ветке (и добавить к своему тамошнему ответу мне нечего):
http://zx.pk.ru/showpost.php?p=248997&postcount=17
"я много знаю, чего сам уже давно не могу применить - пороху нет. И чтобы не выглядеть творческим импотентом обосную всякому, что и другим ничего делать не надо, ибо сложно, некрасиво, невыгодно, неоптимально [продолжите сами]."
Уважаемый psb, Вы что такое MMU знаете? При стиле написния программ на спеке без защиты памяти получится не ось, а гамно!
А на Макинтоше до System-X, ОСь стояла на процах без защиты памяти, верно?
Ну все погубили ось на корню зарождения...
Ну все погубили ось на корню зарождения...
Походу дела речь шла тут не об ОС а об каких-то супер хаках CP/M-a которые должны были круто ускорить загрузку с флопаря на спектрумах с бетадиском и нулевой страницей ОЗУ.
Я вообще не представляю ось без винта.
А может всю эту бодягу в ZX концепции? я например ничего общего с программированием не узрел, а вот концепций выше крыши
Splinter
23.01.2010, 16:36
Я вообще не представляю ось без винта.
Согласен. Вот если б как нибудь разбить винт так, что бы трдос его принимал за дискету, и начинал грузить бут, в котором уже собсно сама ос и драйвер для расширенного обращения к остальному пространству на винте - тогда можно было бы грузиться на счет оси )))). Может даже не винт а флешка на 4 гига например ).
Rubts0FF
23.01.2010, 18:46
Ось, кому она нужна, кто под нее (даже не вопрос, кто будет писать её) писать будет ..., ну если только она, ось, будет работать в среде Windows?!
кому она нужна, кто под нее писать будет
если писать под нее будет удобно и понятно, желающие будут. и ОСОБЕННО, если сделать пакет разработчика на пц, включающий редактор, справку по всем функциям, ассемблер и компилятор си.
даже если это будет не ось, а фреймворк - это тоже будет супер, но до этого довести оч сложно.
да зачем под нее писать? надо так что бы она старые проги понимала. и еще винт не везде есть так что можно про нее забыть.
а зачем оси понимать старые проги? чтобы че? они запускаются и работают без оси. а вот новые было бы просто проще писать для нее. а проще писать - больше программ полезных появицца. теоретически:)))
но тема че-то уплыла... какая тут уж практика...
Уважаемый psb, Вы что такое MMU знаете? При стиле написния программ на спеке без защиты памяти получится не ось, а гамно!
А что - если проц без ММУ - ось под него нельзя написать ? :)
ММУ - это обеспечение безопасности и скорости. Но и без него можно ось написать приличную. Даже с отдельными сегментами кода и данных.
Если уж на то пошло - то сегментирование памяти по 16К - вполне себе ММУ. Если же обеспечить впечатывание любой страницы в любое окно - то можно шикарно разделять код и данные.
В принципе - для реализации номальной ОС (с защитой памяти) достаточно:
1. Обеспечить впечатывание любой страницы в любое окно.
2. Обеспечить аппаратную блокировку записи в любое окно.
3. Обеспечить генерацию NMI при записи в заблокированное окно.
Всё. При таком варианте программы не могут случайно повредить друг другу или затереть код ОС. Сбой в программе, пишущей не в своё окно, будет отловлен и обработан.
Не знаю, только, насколько трудоёмко доработать, например, Phoenix под эти требования.
давно пора переместить эту тему в "концепции".
так давайте уже писать! Правда я не умею =))))))))))))))))))))))))))))))))))))))))))))))))) ))))))))))))
Black_Cat
27.01.2010, 07:38
В принципе - для реализации номальной ОС (с защитой памяти) достаточно:
1. Обеспечить впечатывание любой страницы в любое окно.
2. Обеспечить аппаратную блокировку записи в любое окно.
3. Обеспечить генерацию NMI при записи в заблокированное окно.
Всё. При таком варианте программы не могут случайно повредить друг другу или затереть код ОС. Сбой в программе, пишущей не в своё окно, будет отловлен и обработан.
Не знаю, только, насколько трудоёмко доработать, например, Phoenix под эти требования.Да, есть предложение сделать под Феникс (а возможно и под Кай и Скорпион) плату расширения возможностей под слот NemoBus. Из системных возможностей как раз планируется:
- управление режимами чтения/записи в окне CPU0;
- режим совместимости со Спектрумом +128;
- виртуальный ROM-диск в ОЗУ;
- любая страница в любое окно;
- работа в режиме виртуальной машины (ВМ), при этом в ОЗУ можно держать несколько виртуальных Спектрумов не имеющих возможности залезать в адресное пространство других ВМ, и почти мгновенно переключаться между ними;
- работа в режиме главной ВМ ядра ОС, имеющей доступ ко всем ресурсам компьютера и ко всем ВМ.
Этого хватит?
осталось дождаться сие чуда современного прогресса!
Да, есть предложение сделать под Феникс (а возможно и под Кай и Скорпион) плату расширения возможностей под слот NemoBus. Из системных возможностей как раз планируется:
- управление режимами чтения/записи в окне CPU0;
- режим совместимости со Спектрумом +128;
- виртуальный ROM-диск в ОЗУ;
- любая страница в любое окно;
- работа в режиме виртуальной машины (ВМ), при этом в ОЗУ можно держать несколько виртуальных Спектрумов не имеющих возможности залезать в адресное пространство других ВМ, и почти мгновенно переключаться между ними;
- работа в режиме главной ВМ ядра ОС, имеющей доступ ко всем ресурсам компьютера и ко всем ВМ.
Этого хватит?
Лучше так.
- управление режимами чтения/записи в ЛЮБОМ окне;
- генерация NMI при попытки записи в окно, в которое запрещена запись;
давно пора переместить эту тему в "концепции".
Там уже такая есть
так давайте уже писать! Правда я не умею =))))))))))))))))))))))))))))))))))))))))))))))))) ))))))))))))
Ща буду учить.
Приступаем.
Ещё раз напоминаю - будет для начала делать упрощенно - ведь когда ученики приходят в школу, их же не начинают сразу учить решать квадратные уравнения? Их учат рисовать палочки и кружочки.
Вот и мы будем учиться "рисовать палочки".
Начнем с рассмотрения идеологии и разработки концепции.
Придумаем конкретный пример - "любитель "криминального чтива" - у которого имеется LCD-монитор c композитным видеовходом и и подключенный к нему Спектрум с дисководом. А также дискетка с художественными произведениями указанного жанра в виде текстовых файлов. Нам необходимо разработать ПО для обеспечения возможности читать любителем содержимое текстовых файлов на экране LCD-монитора. При этом мы сразу расширим идеологию, для того чтобы полученное ПО можно было использовать и для других "любителей",(пример - начинающий писатель-студент, которому необходима возможность набирать, просматривать и редактировать текстовые файлы на карточке памяти Compact Flash, подключенные к IDE-контроллеру через переходник CF-IDE (при этом у него на компьютере отсутствует контроллер дисковода и сам дисковод и дискеты).
Теперь концепция.
Рассмотрит три основных составляющих нужного нам ПО:
ядро – состоящее из подмножества компонентов,
программа пользователя, тоже состоящая из подмножества компонентов (далее по тексту - задача),
загрузчик ядра.
Начать надо с главного – определиться с распределением памяти компьютера для ядра и задачи.
Для ядра отведём нижние 32 Кб адресного пространства Z80, а для задачи - верхние 32 Кб.К чему это приведёт?
Ограничение такого распределения очевидны , но оставим так,чтобы всё не усложнять на первом этапе. В память ядра войдёт область пзу, экран и системные переменные BASIC и ядро будет под них подстраиваться, а задача будет свободна от этого.
В следующих версиях можно будет "масштабировать" нашу систему, например предоставить задаче возможность использовать страничную организацию области памяти #C000-#FFFF, а ядру "перепадёт" второй экран,а также некоторые страницы памяти в указанном диапазоне,и в результате ядро получить возможность использовать экранную область первого экрана для "не-экранных" целей и т.д.
Далее, распределение процессорного времени.
Ядро запускает задачу.
Задаче предоставляется 100% процессорного времени для выполнения своих операций. Когда задача запрашивает операции, выполняемые ядром она самостоятельно передаёт управление ядру и ядро использует 100 % процессорного времени до завершения требуемой операции. После этого ядро возвращает управление задаче.
Когда задача выполнила все необходимые операции, она запрашивает операцию ядра "завершить задачу".
Теперь кратко рассмотрим основные компоненты ядра.
1)Диспетчер задач - обеспечивает загрузку задачи в её адресное пространство,выполнение и завершение задачи.
1)Драйвер устройства ввода (в данном случае это клавиатура).
2)Драйвер устройства вывода (в данном случае это экран)
3)Файловая система - производит все операции, необходимые для работы с файлами на различных информационных носителях (в данном случае это дисковод). Подразделяется на 3 части:
а) Диспетчер устройств. Он объединяет в единую виртуальную файловую систему компоненты б),в)
б) Драйвера файловых систем (в данном случае одной файловой системе TR-DOS, которая на дискете,)
в) Драйвера дисковых устройств (в данном случае один драйвер дисковода, подключенный к BETA-DISK-INTERFACE).
Программа пользователя будет хранится на диске в виде одного файла длиной не более 32 Кб.
Ядро тоже будет хранится на диске в виде одного файла длиной не более 8 Кб.
Загрузчик сделаем на Бэйсике :).Назовём его boot. Он будет загружать ядро на адрес #6000.
и?
---------- Post added at 16:20 ---------- Previous post was at 16:13 ----------
Программа пользователя будет хранится на диске в виде одного файла длиной не более 32 Кб.
почему именно 32?
Ядро тоже будет хранится на диске в виде одного файла длиной не более 8 Кб.
тоже почему?
Загрузчик сделаем на Бэйсике :).Назовём его boot. Он будет загружать ядро на адрес #6000.[/QUOTE]
почему именно с 6000?
и?
Не надо И (C) Электроник
Сейчас вот подберём подходящие дровишки...
Надо будет их доработать для нашей цели, сделать загрузчики и начать увязывать всё в кучу
Программа пользователя будет хранится на диске в виде одного файла длиной не более 32 Кб.
почему именно 32?
Ядро тоже будет хранится на диске в виде одного файла длиной не более 8 Кб.
тоже почему?
Загрузчик сделаем на Бэйсике .Назовём его boot. Он будет загружать ядро на адрес #6000.
почему именно с 6000? [/quote]
Задача согласно нашей концепции не может занимать в памяти более 32 Кб.
Поскольку мы сейчас рассматриваем конкретную программу пользователя - программу чтения текста - то она точно поместиться в 32 Кб
Ядро длиной до 8 Кб потому что загружаться будет на адрес #6000
В ядре у нас будет мало функций в этой версии - поэтому все они поместяться
---------- Post added at 19:18 ---------- Previous post was at 18:49 ----------
Почему адрес именно #6000 - а мне нравится круглое число 24576
Можно сделать адрес #5D80 (ниже уже сиспеременные, и могут быть проблемы при загрузке ядра из бэйсика, из разных коммандеров)
Ну будет ядро на 640 байт длиннее - нам это ничего сейчас не даёт,
тем более ,что после загрузки ядро сможет использовать больше чем 8 Кб
Теперь кратко рассмотрим основные компоненты ядра.
1)Диспетчер задач - обеспечивает загрузку задачи в её адресное пространство,выполнение и завершение задачи.
1)Драйвер устройства ввода (в данном случае это клавиатура).
2)Драйвер устройства вывода (в данном случае это экран)
3)Файловая система - производит все операции, необходимые для работы с файлами на различных информационных носителях (в данном случае это дисковод). Подразделяется на 3 части:
а) Диспетчер устройств. Он объединяет в единую виртуальную файловую систему компоненты б),в)
б) Драйвера файловых систем (в данном случае одной файловой системе TR-DOS, которая на дискете,)
в) Драйвера дисковых устройств (в данном случае один драйвер дисковода, подключенный к BETA-DISK-INTERFACE).
.
Реализация вышеуказанных компонентов не представляет особой сложности, за исключение аппаратнозависимы драйвером дисковода (порты контроллера закрытые, необходимо переходить в область пзу трдос, плюс нужно знание комманд ВГ93)
Драйвер клавиатуры будет имет только одну функцию - получить код символа
Драйвер экрана - тоже одна функция - вывести строку символов из буфера такой-то длины.
В драйвере файловой системы трдос нужно будет повозиться с произвольным чтением изнутри файла - применим для этого функцию lseek - установить указатель на определённое место в файле
можно получить домашнее задание? где почитать про командыВГ?
Error404
29.01.2010, 16:52
При наличии аппаратной реализации принципа "любая страница в любом окне" нужно планировать под память пользователя (программы/процесса) все 64к адресного пространства. Ядро держать в "теневой" странице и подключать только на время обращения к его функциям. Разница между 32к/64к для процесса критична в том, что в 64к уже достаточно большой простор для длинномерного компилированного С-кода, а в 32к на C разве что только "hello world" запускать.
а в 32к на C разве что только "hello world" запускать.
забыл добавить: "на пц" ;)
Error404
29.01.2010, 18:08
забыл добавить: "на пц" ;)
Я конечно немного утрирую, но по моему опыту, любая более-менее интересная программа (это обычно 1000-2000 строк) у меня получается порядка 36-40к только кода (а ведь нужна еще и куча, и стек). Использую Hitech-C для CPM - пожалуй единственный 32-битный ANSI C для Z80, работающий нативно на Z80 (в отличие от SDCC, IAR и прочего для PC)
Про команды ВГ-93 можно прочитать в книге "ZX-SPECTRUM и TR-DOS для пользователей и программистов". Она есть на сайте Virtual TR-DOS
Вот нашёл эту книжку:
http://trd.speccy.cz/book/ZX_TRDOS.ZIP
---------- Post added at 18:10 ---------- Previous post was at 18:01 ----------
При наличии аппаратной реализации принципа "любая страница в любом окне" нужно планировать под память пользователя (программы/процесса) все 64к адресного пространства. Ядро держать в "теневой" странице и подключать только на время обращения к его функциям.
Так всё и будет
НО!
Не в первом же классе учить детей решать квадратные уравнения
Rubts0FF
31.01.2010, 23:44
Все это мне напоминает ситуацию, а-ля - почему нельзя на площади заняться сексом с женщиной, советами достанут.
Разница между 32к/64к для процесса критична в том, что в 64к уже достаточно большой простор для длинномерного компилированного С-кода, а в 32к на C разве что только "hello world" запускать.
Хорошо, что я об этом не знал и писал на С программки для 8кбайтовых контроллеров :)
На самом деле - современные компиляторы С оптимизируют код хорошо. Сам ты его соптимизируешь ну щё процентов на несколько - не больше.
---------- Post added at 07:35 ---------- Previous post was at 07:32 ----------
Использую Hitech-C для CPM - пожалуй единственный 32-битный ANSI C для Z80, работающий нативно на Z80 (в отличие от SDCC, IAR и прочего для PC)
А! так тебе обязательно НАТИВНО работающий? тады ой.
в принципе, для скорости написания проще использовать кросс-средства.
нативных оптимизирующих компиляторов С для Z80 не знаю.
Хорошо, что я об этом не знал и писал на С программки для 8кбайтовых контроллеров :)
Но согласись что это были довольно простые по логике програмки, далеко не ROM от спектрума и не типичная спектрум игрушка типа exolon. Как показывает практика то длинна кода и скорость при использовании ЯВУ падает в среднем в 3...4 раза так что надо памяти хотябы 256Кб а лучше 512кб частоту не 3Mhz а 20Mhz! И при этом желательно чтоб память была прямоадресуемая без всяких страниц и сегментов (типичный m68000 или mos65816).
Как показывает практика то длинна кода и скорость при использовании ЯВУ падает в среднем в 3...4
ну это зависит от того, как писать, да и от компилятора сильно зависит
если не пользоваться 32х битной арифметикой, вычислениями с плавающей точкой и прочим, чего в процессоре нет, то работать будет быстро, а занимать мало
си - это же, как говорится, ассемблер высокого уровня.. я, например, не представляю, почему Hello, world на си может получиться значительно больше по объему, чем на асме
эксолон-не эксолон, а какой-нибудь maziacs (не менее типичная zx-игра) умять в 32 килобайта компиленного сишного кода вполне реально
Как показывает практика то длинна кода и скорость при использовании ЯВУ падает в среднем в 3...4
Это где такая "практика" ? Давай говорить не о "яву", а о языке С, например. О современных компиляторах, а не о поделках 20-летней давности.
1. Скорость. Для того, чтобы алгоритм был "в 3-4" раза медленне, чем на асме - надо ОООЧЕНЬ постараться. Отключить полностью оптимизацию, писать как попало. Есть, конечно, исключения, но кто мешает сделать ассемблерную вставку ? Как правило, критическая часть кода занимает не более нескольких десятков комманд ассемблера.
Как правило, проигрыш в скорости - проценты. Никак не 3-4 раза.
2. Объём. Язык С позволяет разместить данные не менее плотно, чем ассемблер. Только удобств куда как больше.
3. Скорость разработки. Тут асм явно в проигрыше.
ИТОГ.
Проект лучше делать на С, а потом критические места - переписывать на асме.
Конечно, если программа - расчитана до такта, как некоторые демы - то тут всё на асме пишеться.
Но в свете написания ОС могу сказать, что тут про асм лучше забыть и не вспоминать без крайней нужды. Писал для ARM7 многозадачку потоковую. ядро заняло всего несколько килобайт.А для АРМ7 куда как более жирный, чем для Z80 получается. В ядро вошли - переключатель задач, менеджер памяти (куча), рудиментарная файловая система (для обращения к устройствам), куча сервисных функций.
Ассемблер использовал только для запуска процессора (расставить все стеки, запустить тактовый генератор) - и всё.
Проект лучше делать на С, а потом критические места - переписывать на асме.
плюс мильон
к тому же разработка планируется совместной
читать чужой код не нравится никому, но взглянув на код на си можно хотя бы сразу понять, что он делает - по именам переменных, названиям функций...
а вот чтобы понять, что делает ассемблерная "простыня" придется потратить уйму времени
уж не говорю о том, что над сишным кодом можно написать небольшой win32|POSIX-враппер и отлаживать многие вещи прямо на PC, без эмулятора
Одна ремарка: "3..4 раза" это коэфициент для расчетов ресурсов для реальной комерческой задачи портирования существуещего кода (например игры exolon на ZX) на другую платформу для большенства (99%) случаев. Ясное дело что этот коэфициент имеет "запас" на случай непредвиденного расхода быстродействия и\или памяти. Говорить об коэфициенте в 1.5...2 раза тоже иногда можно, но гораздо в меньшем количестве случаев.
плюс мильон
к тому же разработка планируется совместной
это кем она планируется?
я так понимаю,я буду выкладывать примеры, а остальные будут их изучать и высказывать пожелания, типа "вот здесь надо вот так, а вот это вообще убрать " и т.д.
читать чужой код не нравится никому,
как показывает практика, желающие покритиковать всегда найдутся
---------- Post added at 16:47 ---------- Previous post was at 16:40 ----------
Сейчас вот подберём подходящие дровишки...
Подобрал...
Ну шо, сразу насыпать их сюда или всё-таки есть надежда, что уважаемые "ученички" сами
попробуют чё-нить сделать?
---------- Post added at 16:56 ---------- Previous post was at 16:47 ----------
Драйвер клавиатуры будет имет только одну функцию - получить код символа
Тут есть два варианта - ждать и не возвращаться в задачу, пока пользователь не нажмёт любую кнопку, или же при отсутствии нажатой кнопки сразу возврат в задачу.
Мы остановимся на втором варианте - при не нажатой клавише - установлен флаг NZ, а при нажатой клавише - установлен флаг Z, и в рег. A - будет ASCII-код нажатой клавиши
Драйвер экрана - тоже одна функция - вывести строку символов из буфера такой-то длины.
В этой функции задача дополнительно будет устанавливать 2 флага:
1-й флаг - сброшен - продолжать печатать по текущим координатам,установлен - печатать по новым координатам
2-й флаг - установлен - очистить экран перед печатью, сброшен - не очищать
---------- Post added at 17:08 ---------- Previous post was at 16:56 ----------
В драйвере файловой системы трдос нужно будет повозиться с произвольным чтением изнутри файла - применим для этого функцию lseek - установить указатель на определённое место в файле
Еще нужны функции:
bread - прочить блоки в память из файла (при этом указатель будет перемещаться внутри файла)
bwrite - записать блоки из памяти в файл - аналогично bread
Вот этих функций уже хватит, чтобы загружать длинный текст (длиной больше, чем может поместиться в памяти).
bwrite - понадобиться , чтобы сохранять настройки - и задачи и ядра.
это кем она планируется?
я так понимаю,я буду выкладывать примеры, а остальные будут их изучать и высказывать пожелания, типа "вот здесь надо вот так, а вот это вообще убрать " и т.д.
Сорри что вмешиваюсь, возможно упустив нить рассуждения. Какова цель данного "курса" по написанию оси? Поделиться/обменяться знаниями? Написать ось?
Вмешиваюсь как модератор:
1. Тема находится в разделе программирование - пишите сюда код и критикуйте код; если не увижу далее в теме кода, тема уедет в другой раздел;
2. Много подобных рассуждений уже было и на этом форуме: читаем и ищем в http://zx.pk.ru/forumdisplay.php?f=23 - там рассказывается и про ММУ, и про ядро, и про драйверы, и про файловую систему в т.ч.;
3. Прежде чем продолжать дискуссию не поленитесь заняться ликбезом, например прочитать книгу про то, как создаются ОСи. В качестве рекомендуемого издания: "Сетевые Операционные Системы" В.Г. Олифер, Н.А. Олифер.
я так понимаю,я буду выкладывать примеры, а остальные будут их изучать и высказывать пожелания, типа "вот здесь надо вот так, а вот это вообще убрать " и т.д.
Пока ни одного примера который можно изучить я не увидел. Как от создателя темы требую перевести дискуссию в более соответствующее разделу русло.
Операционная система Микроб :)
Версия 0.00.
Пока только ядро в составе рассмотренных выше драйверов клавиатуры и экрана, плюс исходники этих драйверов и драйвера: файловой системы тр-дос и дисковода (последний в двух вариантах - непосредственно работающий с ВГ93 и работающий через #3D13 - этот будет нужен для ускорения отладки(на винте, на рам-диске и т.д.), плюс лицензия :)
Загружается ядро и пишет на экран приветствие.
---------- Post added at 21:33 ---------- Previous post was at 21:23 ----------
Исходники в формате ассемблера Alasm
Файлы исходников:
DEVKBD - драйвер клавиатуры
DEVSCR32 - драйвер экрана - выводит 32 символа в строке
Материалы для драйверов - требуется "доработка напильником" для превращения в драйвера, пока не входят в состав ядра.
TRD - материал для драйвера файловой системы тр-дос
FDD_3D13 - "ненастоящий" драйвер дисковода, обращается к 3D13
FDD_VG93 - драйвер дисковода, для доступа к ВГ93 использует один из мини-драйверов
FDD_RAM - мини-драйвер ВГ93 - использует точку доступа 3D2F и часть процедур пзу трдос
FDD_CASH - мини-дайвер ВГ93 - напрямую обращается к ВГ93 - должен располагаться в кеше или в свободной области пзу тр-дос.
Изучаем, задаём вопросы,
быстрые ответы не обещаю:)[COLOR="Silver"]
---------- Post added at 21:53 ---------- Previous post was at 21:33 ----------
Сорри что вмешиваюсь, возможно упустив нить рассуждения. Какова цель данного "курса" по написанию оси?
Вроде ж в первых постах этой темы и "Теории" говорил о целях
Ну попробую ещё раз
Поделиться/обменяться знаниями? Написать ось?
Просто хочу поделиться своим видением вопроса.
Предлагаю сделать ось home use only, так сказать чисто для домашнего применения, которая не будет пытаться затмить уже существующее, и не должна распространяться, словно чума, на всё сообщество, а наоборот, призвана решать конкретные задачи её автора - это с одной стороны. А с другой стороны - сделать её достаточно простой и такой, чтобы любой желающий мог,изменив одну или несколько её частей, использовать в своих конкретных целях, без оглядки на "авторитеты", на "концепции и идеологии", так сказать "для себя любимого", ведь платформа Спектрум - это в первую очередь - свобода творчества, здесь можно делать то, что нужно именно тебе,и именно таким образом,которым удобно тебе, И над нами не довлеет человек,указывающий нам единствено верный, с его точки зрения, путь, и свернувший с этого пути У НАС, не будет тут же убит упавшим на него окном "Программа выполнила недопустимую операцию и будет закрыта".
А значит, можно делать что угодно в этом направлении, и в этой теме я хочу осветить некоторые возможности,доступные только на нашей платформе,[COLOR="Silver"]
Но согласись что это были довольно простые по логике програмки, далеко не ROM от спектрума и не типичная спектрум игрушка типа exolon. Как показывает практика то длинна кода и скорость при использовании ЯВУ падает в среднем в 3...4 раза так что надо памяти хотябы 256Кб а лучше 512кб частоту не 3Mhz а 20Mhz! И при этом желательно чтоб память была прямоадресуемая без всяких страниц и сегментов (типичный m68000 или mos65816).
Моя программка на С для AT8535 (память команд - 8К, т.е. 4096 команд) была не "Эхолон".. Это да..
В реалтайме обрабатывала информацию с 30 датчиков и управляла 15 двигателями. Плюс к этому - держала интерфейс пользователя на 7-сегментных индикаторах.
Как думаешь - что сложнее - обработать 5 кнопок ввода пользователем в эхолоне или 30 датчиков? Я уж не говорю про то, что зависание эхолона - никакого вреда, кроме мата пользователя не принесёт.. Чего не скажешь о зависании программы управления очисткой воды, которую я писал...
В принципе вся "сложность" в игре типа эхолон - это скорость перестроения экрана. А никак не логика.
---------- Post added at 01:00 ---------- Previous post was at 00:47 ----------
Операционная система Микроб :)
Версия 0.00.
По-моему вы не с того начали.
Драйвера - это всё хорошо, но! Есоли пишите ОС, то, ИМХО, вначале ответьте на такие вопросы:
1. Как ОС будет взаимодействовать с ПО пользователя. То есть "механизм системных вызовов". Механизм должен быть единым для всех программ, пригодным для любого клона, на котором планируется запуск ОС.
2. Как будет происходить переключение задач. Тип многозадачности, события, переключающие задачи, механизм переключения задач.
3. Как будет органиована совместимость с ПО, не поддерживающим данную ОС (старые программы, игрухи и проч.)
4. Как будет выделяться память. Скажем, учитывая архитектуру спека, можно ограничить максимальный объём памяти, выделяемой за раз - 16К.
5. Список основных системных вызовов. Их функции.
ИМХО, когда ответите на все эти вопросы - только тогда можно браться за написание программы. Иначе - получится нечто кривонесовместимое и непонятноработающее.
Моя программка на С для AT8535
Т.е. всё по-прежнему :)
Вмешиваюсь как модератор:
1. Тема находится в разделе программирование - пишите сюда код и критикуйте код;
модератора не слышим?
Неужели так трудно отвечать на оффтоп в теме "Пишем свою ОС.Теория" (если уж очень хочеться на него отвечать) ?
По-моему вы не с того начали.
Драйвера - это всё хорошо, но!
"Восходящий" метод пользуется популярностью даже у таких ГУРУ,как Кен Томпсон.
Мне тож нравиться :)
Есоли пишите ОС, то, ИМХО, вначале ответьте на такие вопросы:
Почти на все уже отвечал, можете полистать тему, если повезёт - в куче флэйма найдёте ответы - или ждите пока модератор очистит тему от мусора :)
Микроб однозадачный. Переключение задач и многозадачность будем изучать на следующих курсах.Это учебная ОС, поэтому вопрос совместимости в данном слуяае не важен. Впрочем никто не запрещает сделать запускалку для Бэйсиков,кодовых файлов,всяких там TRF-фов.
---------- Post added at 17:23 ---------- Previous post was at 17:14 ----------
Пришло время добавить нашему микробу какие-нибудь конечности, которыми он сможет грести к "светлому будущему"(уши,например).
Сегодня мы займемся файловой системой,ведь пока она не подключена к ядру, мы не можем загрузить ни задачу, ни конфигурационные файлы системы.
Брукс в своей книге "Мифический человеко-месяц" предлагает понаделать заменителей и заглушек, собрать всё в один главный цикл и как можно быстрее получить "Работающую версию программы".А в дальнейшем переделывать заменители на нужные функции, вместо заглушек добавлять модули, и при этом на каждом шаге разработки по-прежнему будет РАБОТАЮЩАЯ версия программы.
Для файловой системы в качестве предлагаемого заменителя будем использовать драйвер дисковода FDD_3D13,который в дальнейшем заменим на FDD_VG93.
Диспетчера виртуальной файловой системы пока у нас не будет, будем сразу обращаться к драйверу TRD,а тот будет вызывать FDD_3D13.
Но сделаем заготовки - обращаться к ним будем не напрямую, а через дополнительные JP XX, в которых сначала лежат адреса ЭТИХ драйверов, а позже будет подставляться диспетчером адреса драйверов для конкретных логических устройств.
Распределим память ядра следующим образом (впрочем это не обязательно окончательное решение):
Стэк пока будет общий для ядра и задачи - длиной 256 байт по адресам #5b00-#5c00.
Шрифт у нас длиной 2 Кб будет по адресу #7800 (это #8000-2Кб).
Буфер файловой системы для каталога длиной 2,25 Кб будет по адресу #6F00 (это #8000-2Кб-2.25Кб).
С адреса #6000 по #6A00 (примерно) сейчас расположен код ядра.
Свободным на данный момент 1,25 Кб после кода ядра и .5 КБ до кода ядра по адресу #5e00.
Драйвер FDD_3D13 принимает номер функции в рег. A,содержит 3 функции:
0-выбрать диск , в рег.C - номер дисковода 0,1,2 или 3
1-прочитать несколько(в рег.B) блоков по 256 байт в буфер по адресу HL',номер блока в рег. DE (младшие байты номера) и в рег. DE' (старшие байты)
2-записать блоки - входные параметры такие же ,как для функции 1
TRD - драйвер файловой системы TR-DOS принимает номер функции в рег. А и пока обрабатывает только функцию 4, это функция чтение части файла в буфер по адресу HL',длина части в блоках по 256 байт в рег.B, а в рег. HL адрес таблицы параметров вызова длиной 32+11. Первые 32 байта будут использоваться для хранения различных данных,необходимых для работы с этим файлом, рассмотрим их позже.Последние 11 байт это имя файла 8 байт+3 байта расширение. В дальнейшем длину имени и расширения можно будет увеличить.
Сделаю отступление насчет функций файловой системы.Мы сейчас не будем использовать OPEN,CLOSE, поскольку во-первых, у нас однозадачная,однопользова ельская система и нет необходимости в захвате файлов одной задачей,для прекращения доступа к этому файлу другими задачами. Во-вторых,у нас чтение и запись будут по блокам напрямую с/на диск, а не по байтам,и не будет системного буфера, в котором могут быть несохранённые данные, и которые надо сохранить, используя CLOSE.
И ещё,если бы мы их использовали, то вот те 32+11 байта должны были бы располагаться в памяти ядра(хотя это можно конечно и обойти), что неминуемо привело бы к ограничению на количество одновременно открытых файлов,в необходимости создания механизма для обработки этих операций - а это не есть очень просто.
Впрочем в будущем можно будет их использовать, а пока наш микроб обойдется без них:)
Теперь рассмотрим способы вызова функций ядра из задачи.
Будем использовать передачу параметров вызова в регистрах для тех функций,в которых параметры помещаються в регистры - сейчас это у нас функции 0 - "вывод строки символов на экран" и 1 - "получить символ с клавиатуры".
И второй способ для тех функций, параметры которой не помещаются в регистры, в котором будем оставшиеся параметры передавать в таблице,а в регистровой паре HL (или в другой) будет адрес этой таблицы. Этот способ используем для рассмотренной выше функции 2 - "чтение части файла".
Номер функции (пока что одной из этих 3-х) будем передавать в рег. A.
Ну и остается определиться,откуда задача узнает адрес точки входа в ядро, на который необходимо передавать управления при вызове функций.
Просто при запуске задачи будем передавать ей этот адрес в рег.HL и задача сохранит его в памяти и будет использовать.
Это даст нам возможность не привязывать точку входа в ядро, и даже в дальнейшем менять его перед запуском программы (например при большой её длине).
Для проверки этих функций будем использовать простейшую программу показа текста AUTOLOAD.MIC.Эту программу ядро загружает и запускает после печати приветствия.Запущенная программа (уже задача) печатает своё название и строку "загружаем текст" - вызывая функцию 0 (вывод строки символов).
Далее с помощью вызова функции 2 (чтение части файла) - задача загружает
текст в память задачи.В случае ошибки - выводит сообщение и ждет нажатие любой клавиши с помощью вызова функции 1 (получить символ с клавиатуры).
После успешной загрузки текста выводит его на экран постранично (функция 0).
(Уже заметна не высокая скорость заполнения экрана).
После каждой страницы ждёт нажатия любой клавиши и выводит следующую страницу.
По окончании текста возврат в ядро с помошью простой команды RET. (В дальнейшем мы добавим функций EXIT и задача будет завершаться,вызывая эту функцию).
И далее ядро перезапускает TR-DOS.
Поскольку книженции в стиле "криминального чтива" сразу не нашлось,на первое время закинул на дискету 1-ю главу книги У.Гибсона "Перегруженная Мона Лиза".
Пример с программой показа текста
Добавились файлы FS.H - это заменитель диспетчера вирт.файл.системы
и AUTOLOAD.H - исходник программы показа
.....Диспетчера виртуальной файловой системы пока у нас не будет, будем сразу обращаться к драйверу TRD,а тот будет вызывать FDD_3D13.А не хочешь в приложении сразу реализовать упрощенное "SAVE 16384,6912" , а потом заниматься уже драйверами? То есть:
LD HL, data;адрес данных
LD DE, lenght; длина
CALL save1;save1-TR-DOS, save2-RAMDISK, save3-MsDOS...
И "шапка" драйвера сама уже все разложит по полочкам, избавляя кодера от расчетов. Мне бы хотелось сделать именно так, разгрузив само приложение.
..Ну и остается определиться,откуда задача узнает адрес точки входа в ядро, на который необходимо передавать управления при вызове функций.
Просто при запуске задачи будем передавать ей этот адрес в рег.HL и задача сохранит его в памяти и будет использовать..У меня чуть по-другому - Положим этот адрес в системные переменные самой задачи, сократив тем самым код приложения и драгоценные такты. Это оптимально, другого способа пока не вижу.
..После успешной загрузки текста выводит его на экран постранично (функция 0).
(Уже заметна не высокая скорость заполнения экрана)...Это нормально, у тебя же не оживленная игра, а операционка. Что-то все равно будет теряться.
У меня чуть по-другому - Положим этот адрес в системные переменные самой задачи, сократив тем самым код приложения и драгоценные такты. Это оптимально, другого способа пока не вижу.
Этот способ ограничивает свободу приложения в плане того , что обязательно должен быть заголовок определенной длины в определенном месте программы - например в начале файла заголовок 100 байт - в результате - этот заголовок нарушает все планы - если код упакован упаковщиком - драгоценной памяти в моем варианте тратиться на 3 байта больше:
LD (OS+1),hl
---------- Post added at 13:42 ---------- Previous post was at 13:34 ----------
А не хочешь в приложении сразу реализовать упрощенное "SAVE 16384,6912" , а потом заниматься уже драйверами? То есть:
LD HL, data;адрес данных
LD DE, lenght; длина
CALL save1;save1-TR-DOS, save2-RAMDISK, save3-MsDOS...
В чем упрощение? Надо смотреть в будущее:)
трдос-дисков и мс-дос-дисков у нас может быть по 4 штуки, рам-дисков до 6 штук (на 4-х метровой Пентеве) - итого уже 14 адресов функций только для записи, потом мы захотим добавить 2 сдрома, 2 сд-карты, 2 винта по 8 разделов - и уже получаем 34 адреса только для save - save1...save34
А ведь нам ещё надо по столько же для функций load,create,delete,rename,cat - сам умножь 34*6 - и ужаснись :)
а если в новой версии ядра адреса изменяться?
Надо делать табличку из двух сотен JP XX - сколько она займет - около 610 байт
а если мы захотим при каждом вызове ядра выполнять одинаковое действие - например ставить свой указатель стэка - перед этим запоминать стэк задачи в ячейке памяти?
простым CALL NEW_STACK - уже не отделаешься!
Предлагаю ученику Vovoi - аргументировать своё предложение
драйвер сам должен распознать тип носителя и его ФС. или ввести код носителя 0 для сменного (дискета) 1 для винтов и цдром, 2 для рамдиска. тогда никаких примудростей с save_x..
драйвер сам должен распознать тип носителя и его ФС. или ввести код носителя 0 для сменного (дискета) 1 для винтов и цдром, 2 для рамдиска. тогда никаких примудростей с save_x..
Это Vovoi - предлагает save X - я на такое не согласен :)
---------- Post added at 13:58 ---------- Previous post was at 13:57 ----------
Это нормально, у тебя же не оживленная игра, а операционка. Что-то все равно будет теряться.
Э не ....
Даду домашнее задание одному из "ученичков" например МИВу - оптимизировать процедуру - чтобы успевало "в один фрэйм"
оптимизировать процедуру - чтобы успевало "в один фрэйм"
ты про вывод на экран? смысл для операционки делать фреймовые выводы? это потеря памяти. зачем?
Аргументация выглядит следующим образом. Да, приложение, к сожалению, имеет заголовок. В этом же заголовке координаты данных, с которыми работает приложение. Например, графический редактор хранит в них адрес и длину спрайта. Командой Save sprite N to disk X, выполняется сохранение. Диспетчер приложений пусть дальше разбирается сам, это задание уже по его части. Рассмотрим два работающих текстовых редактора (блокнота). Результат их работы - текст, адрес и длина которого сидят заголовке. Но, один блокнот-1 может забирать весь или части текста блокнота-2. Любое приложение может пользоваться данными остальных приложений, поскольку заголовки имеют жесткую структуру и хорошо документированы в мануале для разработчика приложений. Это был ответ в защиту "заголовка".
Даду домашнее задание одному из "ученичков" например МИВу - оптимизировать процедуру - чтобы успевало "в один фрэйм"
не ребят извините но я пас. я тут как баран на новые ворота.
не ребят извините но я пас. я тут как баран на новые ворота.
Да у нас тут свободное посещение:)
Про комманды вг93 МИВ прочитал что-нибудь?
Или из книги Олифера (или как там их)?
Ну надеюсь,все уже изучили второй пример, выкладываю следующий.
Ночная сборка.Не тестировалась.Если кто-то из "учеников" найдет ошибку,поставлю пятерку.
Добавлен простейший диспетчер(менежджер) виртуальной файловой системы и таблица логических устройств, которую он использует.В таблице первый байт - кол-во устройств, далее по 6 байт на устройство - адреса драйвера файловой системы и драйвера дискового устройства, номер виртуального диска и резервный байт.Соответственно адреса подставляются куда надо,см. предыдущий урок. И теперь диспетчер передает драйверам номер виртуального диска и этот номер используется
Сейчас там 4 лог.устройства - соответствуют дисководам A,B,C,D.
Но работа пока ведется только с А(ядро уже инициализирует его через диспетчер, но задаче выбор лог.устройств пока не доступен).
Лень на праздниках было делать функцию lseek, поэтому "подключил" функции 4 - create и 3 - save.Что-то там ещё по мелочам - смотрите комменты в исходниках
в программу просмотра текста внес изменения - выход по кнопке е или когда закончится текст, листание по кнопке а,и для проверки вышеуказанныъх функций по кнопке s - создается файл с именем SAVING.TXT и в него записывается 768 байт текста начиная с того который видно на экране. Только первый раз, в след.разы
этот файл уже есть поэтому ничего не записывается.
если его удалить посторонней прогой/коммандером, то опять он будет появляться.
Любое приложение может пользоваться данными остальных приложений, поскольку заголовки имеют жесткую структуру и хорошо документированы в мануале для разработчика приложений. Это был ответ в защиту "заголовка".
О! Т.е. заголовок нужен для взаимодествия задач, т.е. речь уже идет о системе с несколькими задачами.
А поскольку у нам пока что одна задача, значит это сейчас не актуально. Поэтому рассматривать этот вариант будем потом.
А что Vovoi скажет насчет двух сотен адресов (save1...save34,load1...load34 и т.д.)?
ты про вывод на экран? смысл для операционки делать фреймовые выводы? это потеря памяти. зачем?
Это чтобы уважаемые "ученички" не расслаблялись:)
А насчет потери памяти - можно дать задание уложится например в 256 байт:)
А насчет потери памяти - можно дать задание уложится например в 256 байт
фреймовый скрол в 256 байт? жжош...
....А что Vovoi скажет насчет двух сотен адресов (save1...save34,load1...load34 и т.д.)?
Да, вынужден признать, тут наши пути расходятся. Я решил изначально ориентироваться на массовые Спектрумы, чтобы человек снял с полки свой Speccy-48k+TR-DOS или Speccy-48/128k+TR-DOS и запустил менеджер без танцев с бубном. В этом, поддерживаю iskraSoft.
Убежден, что мой путь не пригоден для дальнейшего развития Speccy (CPU 21Mhz, RAM 4-16Mb, 640*480 & 64color, CD-RW drive).
Менеджер рассчитан на обычный дисковод и, далее, уже при подгрузке дополнительных модулей-драйверов, жесткий диск, CD-ROM и, может быть флешка, так что излишнего числа адресов не предвидится.
Сама цель - удобная работа сразу в нескольких программах: Пишу текст проги (напр., игрушки), здесь же спрайт-редактор. Подрисовал спрайт, проверил вывод на экран, пишу прогу дальше. Что-то вспомнил, отвлекся на файловый менеджер, вывел картинку на экран и срезал оттуда спрайт, объявил его доступным (либо передал в RAM-DISK), вернулся в спрайт-редактор, взял спрайт. Переключился на менеджер, стащил в блокнот текст некоего эффекта, выделил, объявил фрагмент доступным, вернулся к кодингу, забрал текст спецэффекта в свою прогу.
По всему видно, что никакой операционной системой это не пахнет, так что назвал сие чудо просто - Менеджер приложений.
Тему покидаю. Спасибо за интересные мысли и хорошую работу, успехов.
так когда можно будет заценить ОС?
Ученик Zet9! прочитали ли Вы список рекомендуемой литературы? Ознакомились ли с рекомендованными ссылками?
Привет, народ!
Как, по-вашему, системные процедуры для ОС следует оптимизировать по размеру кода или по скорости?
Я думаю, что по размеру важнее - ведь вызовы системных функций интенсивностью не отличаются?
Как, по-вашему, системные процедуры для ОС следует оптимизировать по размеру кода или по скорости?
По реентерабельности...
По реентерабельности...
интересно посмотреть реентерабельный malloc:)))
По реентерабельности...
По данному признаку процедуру оптимизировать невозможно: она не может быть "чуть-чуть не реентерабельной".
Вот для Спека с его ограниченным адресным пространством и слабым CPU, что предпочтительней, чтобы, к примеру, захват памяти занимал 100 байт и 400 тактов или же 80 байт и 450 тактов?
интересно посмотреть реентерабельный malloc))
А что, примитивы синхронизации отменили?
По данному признаку процедуру оптимизировать невозможно: она не может быть "чуть-чуть не реентерабельной".
Может. Правда в абсолюте это называется "нереентерабельность".
А что, примитивы синхронизации отменили?
примитивы примитивами, сам алгоритм не может быть реентерабельным. а окружить критическими секциями (или еще чем) можно все что угодно...
А что, примитивы синхронизации отменили?
Если malloc была прервана в момент частичного изменения списков памяти, то другая задача, выполняя malloc, разрушит их.
А если процедуре нужны Forbid() и Permit(), то она уже не реентерабельна.
Не так ли?
Может. Правда в абсолюте это называется "нереентерабельность".
Что и требовалось доказать.
По существу кто-то может высказаться?
по существу я бы сказал так: it depends :)
если у тебя места под код ос полно (например она в странице сидит), тогда по скорости оптимизируй и не парься. если же места мало, то тогда по размеру. ну и зависит еще от типа того, что ты оптимизируешь. если это шедулер, постоянно выполняющийся, то его лучше так и так по скорости, а если это редко запускаемая штука типа создания потока - ее можно сделать медленной. думаю, даже тот же malloc() можно сделать медленным.
примитивы примитивами, сам алгоритм не может быть реентерабельным. а окружить критическими секциями (или еще чем) можно все что угодно...
Реентерабельность в данном случае зависит исключительно от факта использования общих данных. Примитивы синхронизации как раз и предназначены для разделения доступа.
Если malloc была прервана в момент частичного изменения списков памяти, то другая задача, выполняя malloc, разрушит их.
А если процедуре нужны Forbid() и Permit(), то она уже не реентерабельна.
Не так ли?
1) Что делают эти функции?
2) Помимо модели "одна куча на всех", есть еще и другие модели, более ресурсоемкие, но и более безопасные.
1) Что делают эти функции?
Соответственно выключают и включают многозадачность.
2) Помимо модели "одна куча на всех", есть еще и другие модели, более ресурсоемкие, но и более безопасные.
Ну, не знаю.
На спеке всё-равно будет "одна куча на всех".
Vitamin, вот смотри. хочешь ты сделать рекурсию из нереентерабельной функции. КАК?? да никак:) синхронизация тут не поможет, поэтому лучше считать ее вообще отдельной штукой. т.е. она на самом деле не делает функции реентерабельными, она предотвращает конфликты:)
Vitamin, вот смотри. хочешь ты сделать рекурсию из нереентерабельной функции. КАК?? да никак синхронизация тут не поможет
1) Назови хотя бы одну системную функцию, которая рекурсивно вызывает сама себя
2) Мьютексы рекурсивные тоже бывают (это я так, для справки)
Назови хотя бы одну системную функцию
ну это я вообще, про нереентерабельность.
Мьютексы рекурсивные тоже бывают
угу, только в случае рекурсии они-таки не помогут:)
ну т.е. ты не согласен, что средства синхронизации не определяют реентерабельность?
Ну так где прототип то? када посмотреть можно будет?
угу, только в случае рекурсии они-таки не помогут
Помогут. Пока функция окончательно не выйдет, никто другой даже первую итерацию не сделает.
ну т.е. ты не согласен, что средства синхронизации не определяют реентерабельность?
Согласен, что не определяют, но считаю, что могут помочь при грамотном их (средств синхронизации) использовании.
Ну так где прототип то? када посмотреть можно будет?
Это как помогать будешь ;)
---------- Post added at 15:32 ---------- Previous post was at 15:26 ----------
Помогут. Пока функция окончательно не выйдет, никто другой даже первую итерацию не сделает.
Но это, ведь, значит, что эта п/п не реентерабельна?
Но это, ведь, значит, что эта п/п не реентерабельна?
Навскидку, смотрим в википедию на предмет определения реентерабельности:
Компьютерная программа в целом или её отдельная процедура называется реентера́бельной, если она разработана таким образом, что одна и та же копия инструкций программы в памяти может быть совместно использована несколькими пользователями или процессами. При этом второй пользователь может вызвать реентерабельный код до того, как с ним завершит работу первый пользователь и это как минимум не должно привести к ошибке, а в лучшем случае не должно вызвать потери вычислений (то есть не должно появиться необходимости выполнять уже выполненные фрагменты кода).
Какому из этих критериев противоречит реализация реентерабельности на основе примитивов синхронизации?
Навскидку, смотрим в википедию на предмет определения реентерабельности:
...
Какому из этих критериев противоречит реализация реентерабельности на основе примитивов синхронизации?
Вот:
"При этом второй пользователь может вызвать реентерабельный код до того, как с ним завершит работу первый пользователь...".
А в примере получается, что второго пользователя не пускают в процедуру дальше первой итерации, пока "функция окончательно не выйдет", т.е. пока первый пользователь не закончит работу с ней.
А в примере получается, что второго пользователя не пускают в процедуру дальше первой итерации, пока "функция окончательно не выйдет", т.е. пока первый пользователь не закончит работу с ней.
Может вызвать. Никто ж не гарантирует, что функция вернет управление сразу.
Это как помогать будешь ;)
Пальцем не пошевелю
:)
Просто в программировании должны быть программы а не теоретические выкладки
Ничего кроме концепций тут не вижу. Тема едет в соотвествующую ветку.
Ничего кроме концепций тут не вижу.
А сообщение про секс на площади - неужели не видели?
Ой,бедненький... Попробую помочь и показать на сообщения,в которых не только концепции.
Вот по этим ссылкам есть примеры,в них можно поизучать исходный текст, еще там есть реально работающий код,его можно запустить на Спектруме и увидеть результат:
http://zx.pk.ru/showpost.php?p=263857&postcount=56
http://zx.pk.ru/showpost.php?p=259009&postcount=48
Вот есть сообщения с откровенным флеймом:
http://zx.pk.ru/showpost.php?p=252294&postcount=22
http://zx.pk.ru/showpost.php?p=252302&postcount=23
http://zx.pk.ru/showpost.php?p=252351&postcount=24
Если перейдёте по ссылкам - сможете увидеть
Вам ещё показать пальцем на флэйм или сами попробуете его найти :)
Неужели так трудно удалить флэйм? Он засоряет эту тему уже два месяца или даже больше.Я уже намекал не один раз, что пора провести зачистку. Или модератор Griv уже не способен это сделать?
Тема едет в соотвествующую ветку.
Ты ба! Неужели модератор признается в своей профнепригодности?
Похоже на то,что он не в состоянии соблюдать порядок в этой теме - раз он отдал её другим модераторам.
/////////////////////////////////////////////////////////////////////////////
Пока вы тут весилитесь, я даром время не теряю - Микроба развиваю :)
Микроб уже научился ходить, и уже даже говорить:) И конечно первое слово, которое он сказал, было слово "Спектрум".
Добавились функции:
-удалить файл - просто в HL-указываем адрес таблицы параметров длиной 32 байта, после которой идет имя 8 байт и расширение(3 байта) файла, который нужно удалить
-переименование файла - в HL-адрес таблицы, после неё новое имя и расширение ,а в DE - адрес, по которому старое имя 8 байт и расширение 3 байта. Если файл с новым именем уже есть или файла со старым именем нет - то выход со сброшенным флагом Z
-чтение каталога в буфер по указанному адресу - каталог выдается в специальной форме (про неё в следующий раз)
-установить указатель операции внутри файла на нужную позицию(смещение от начала) - в HL- адрес талицы параметров, в BC',DE' - новое смещение в блоках по 256 байт - эта функция только меняет байты 24,25,26,27 в таблице параметров на заданное смещение и в байте 28 устанавливает бит 2 (выполнять операцию с файлом с указанного смещения) - смещение используется только в функциях READ,WRITE
-установить текущий путь/номер устройтсва для работы - эту функцию вызывает процедура INIT
В программе показа текста теперь нужно выбирать файл путем нажатия на соответствующую кнопку, например на кнопку "c" для загрузки файла, видимого на экране c:EVA_00
Выход из программе по кнопке е
По нажатию s - запись видимого куска текста на экране в файл с именем SAVEPART.TXT - если такой есть - он переименовываеться в SAVE_OLD.TXT - а если есть SAVE_OLD.TXT - то он удаляется и опять SAVEPART.TXT переименовывается в SAVE_OLD.TXT - это все для проверки функций удаления и переименования
Изменения в файлах MICROB05.H FS.H TRD.H и в FDD_3D13 - исправил ошибку - в прошлой версии она не проявлялась - проявилась сейчас, при использовании функции установить указатель внутри файла
Чтобы можно было загружать разные тексты и протестировать новые функции закинул на диск 5 файлов с именами EVA_00.TXT...EVA_004.TXT - это несколько глав книги "В Эдеме Евы нет" по жанру она больше подходит для нашего "любителя криминального чтива"
Текст загружается аж за 4 захода,длиной максимум 31 Кб - эти файлы примерно такой длины каждый. После первого захода функцией устанавливаем нужное смещение, и загружаем 2-ю часть текста, далее просто загружаем 3-ю часть текста (указатель ползет сам), а далее опять ставим нужное смещение и загружаем 4-ю часть текста. Такие сложности нужны для проверки этих функций
---------- Post added at 21:12 ---------- Previous post was at 20:48 ----------
От Griv: Ученик Zet9! прочитали ли Вы список рекомендуемой литературы? Ознакомились ли с рекомендованными ссылками?
___________
В этой теме ZET-9 не ученик:) ZET-9 здесь ИЗОБРАЖАЕТ знающего учителя и учит делать учебную ОС для Спектрума, а остальные здесь ИЗОБРАЖАЮТ прилежных учеников и делают вид, что участься делать учебную ОС для Спектрума.
ZET-9 еще 1,5 месяца назад прочитал книженцию Олиферов - не всю, конечно, поскольку "не компьютером единым...", а первую часть. вторую часть, начиная с главы 9,где начинаются загрузы про сетевые прибамбасы, аутентификацию,шифрование и безопасность не читал, глянул одним глазком,пока для этой темы не актуально.
Ну а в первой части все расказано простым и доступным языком,вобщем намана книга
Противоречий тому что я тут расказываю, там нет:)
Надо четко понимать разницу, например между требованиями, предявляемыми к ПО,управляющему двигателем космического корабля, и требованиями, предъявляемыми к ПО, управляющим,например, карманным МП3-плэйером.
И точно также сравнивать требования к Учебной или Домашней ОС для Спектрума с требованиями, предъявляемыми к ОС для "взрослых" компьютеров, по меньшей мере неккоректно, если не сказать глупо.
Так что всё тип-топ:)
По ссылкам сходил - они ведут в раздел ОСи - все темы в этом разделе ZET-9 прочитал (за исключением некоторых неинтересных, их полностью не читал)
А чего это Griv интересуется?
Или может он пропустил букву "И" в конце слова ученик, и фраза должна была звучать
"ученики Zet9, прочитали ли Вы..."
---------- Post added at 21:17 ---------- Previous post was at 21:12 ----------
На вопросы остальных "учеников" (SAYMAN.VOVOI,jerri и т.д) отвечу обязательно,в течение нескольких ближайших дней.
Не переключайте!!!
Не переключайте!!!
реклама!
покупайте только наших микробов! для первых покупателей - бесплатно, остальным вернем деньги в двойном размере!!!
Просто в программировании должны быть программы а не теоретические выкладки
вон вам ссылки на программы в предыдущем моем сообщение
---------- Post added at 11:35 ---------- Previous post was at 11:30 ----------
так когда можно будет заценить ОС?
Вынужден огорчить вас, ответ - никогда
Здесь мы не занимаемся оцениваем ОС,в этой теме мы пробуем определить границы своих возможностей.
Например, ученик Sayman уже понял, что не может сделать фремовый скролл размером в 256 байт, ученик Error404 - жалуется, что не может сделать программу меньше 30 Кб,
а ученик Destr вообще не понимает , "Зачем Спектруму нужна ОС" и предлагает сделать для Спека аналог Windows 3.11
---------- Post added at 11:40 ---------- Previous post was at 11:35 ----------
Гордость нашего класса - ученик Vovoi. Он смело преодолевает "границы непознанного", и невзирая на личности, пробует создать свой проект - менеджер приложений "Prjanika-ZX". К сожалению, он больше не учиться в нашем классе,потому что сдал экзамен "экстэрном" и перешёл в другой класс :)
Впрочем, никто не может запретить ученику jerri попробовать создать свою ОС для Спектрума и оценивать её в своё удовольствие :)
а что значит создать ос и заценить ее? сама ос - это не сложно, а вот софт под нее - вряд ли кто-то напишет.
[/COLOR]
а что значит создать ос и заценить ее? сама ос - это не сложно, а вот софт под нее - вряд ли кто-то напишет.
Не знаю, что имел ввиду ученик jerri под процессом "заценивания ОС" - пусть нам сам об этом расскажет, а мы послушаем :)
---------- Post added at 18:53 ---------- Previous post was at 18:52 ----------
фреймовый скрол в 256 байт? жжош...
__________________
Речь шла не о фрэймовом скролле, а о фреймовом выводе на экран.
Если не получиться в 256 байт, тогда можно в 512 организовать процедуру.
Если есть мотивация, всегда можно что-нибудь придумать - перевести шрифт в
формат экрана, составить таблицу адресов каждой из 24-х строк и расположить её по
адресу, кратному 256 байт, сначала будет 24 младших байта, а по смещению 256 байт
от начала таблицы будут расположены старшие 24 байта адресов строк на экране.
Соответственно не нужно будет считать адрес перед выводом на экран, а просто его брать
из этой таблицы.Ну а код будет в этих двух областях памяти (по 208 байт каждая).
И вообще это не обязательно :)
Просто если кого-то раздражает медленная скорость вывода, он будет ускорять:)
А кому всё равно,тот не обратит на это внимание.
---------- Post added at 19:10 ---------- Previous post was at 18:53 ----------
Да, вынужден признать, тут наши пути расходятся. Я решил изначально ориентироваться на массовые Спектрумы, чтобы человек снял с полки свой Speccy-48k+TR-DOS или Speccy-48/128k+TR-DOS и запустил менеджер без танцев с бубном. В этом, поддерживаю iskraSoft.
Ну можно придумать компромисcный вариант:
Ну например, если приложение всё равно будет знать сколько устройств хранения
данных подключенно и какой номер устройства соответствует рам-диску и дисководу А
(а без этого адрес save X не определить),
то можно передавать номер устройства в одном из регистров.
Тогда адрес процедур load,save,create,delete для всех устройств будет одинаков,а
приложение меняет номер устройства в регистре , в зависимости от того,
что выбрал пользователь в меню этого приложения:)
Сама цель - удобная работа сразу в нескольких программах: Пишу текст проги (напр., игрушки), здесь же спрайт-редактор. Подрисовал спрайт, проверил вывод на экран, пишу прогу дальше. Что-то вспомнил, отвлекся на файловый менеджер, вывел картинку на экран и срезал оттуда спрайт, объявил его доступным (либо передал в RAM-DISK), вернулся в спрайт-редактор, взял спрайт. Переключился на менеджер, стащил в блокнот текст некоего эффекта, выделил, объявил фрагмент доступным, вернулся к кодингу, забрал текст спецэффекта в свою прогу.
Это ты замечательно придумал, не отказался бы от такого, когда менеджер будет готов к употреблению
По всему видно, что никакой операционной системой это не пахнет, так что назвал сие чудо просто - Менеджер приложений.
Та яка ризныця ,як сие ЧУДО называть, главное, чтобы удобно было АВТОРУ этого ПО, судя по вышеизложенному, будет удобно не только ему, так что ждем появления менеджера с нетерпением!!!
Тему покидаю. Спасибо за интересные мысли и хорошую работу, успехов.
И Вам спасибо, если будут вопросы, задавайте (в любой теме или по почте)
Пришлось-таки вмешаться.
..., и невзирая на личности, пробует создать свой проект - менеджер приложений "ZX-ПРЯНИК".Прошу не искажать названия. Пишется строго латинскими Prjanika-ZX.
Кстати, проект давно создан (2003-2009), его осталось отпрограмить в асме. У многих есть готовые проекты на бумаге, только вот нет такого времени, которое позволило бы поробинзонить где-нибудь на острове с реальником, вдали от суеты текущих дней.
а ученик Destr вообще не понимает , "Зачем Спектруму нужна ОС" и предлагает сделать для Спека аналог Windows 3.11Согласен с Destr. При имеющихся в свое время мощностях компа, Майкрософт не стали замахиваться на Win-XP, понимая нелепость проекта. Благодаря этому, Win 1.02 у меня успешно живет на двух дискетах в Amstrad-PC1640.
Ну например, если приложение всё равно будет знать сколько устройств хранения данных подключенно и какой номер устройства соответствует рам-диску и дисководу АНе нравится мне, когда приложение "думает" и, после этого "решает" за программиста, уж извините. А если не позволяю проге напрямую програмить железо, то автоматически "вырезаю" вот это вот "думать и что-то делать без моего ведома", высвобождая RAM. Приятен "метод общения", принятый в iS-DOS:
1. Запуск чек-диска
2. Мессадж - "Памяти мало, позже будет произведен сброс компа, согласны с запуском программы? (Y/N)"
3. Нет. Вернусь и сохраню данные, позже повторю чек-диск.
В системе загружен и активен только один драйвер внешнего устройства, другие подгружаются, затирая его. Выбор хоть любого, из сотни имеющихся, осуществляется в меню.
;)
Это ты замечательно придумал, не отказался бы от такого, когда менеджер будет готов к употреблениюНеправда, это придумано до меня и подробно описано в литературе!
В журнале ZX-Review(могу найти) был описан многооконный GENS. Редактор ACEdit "держит" несколько текстов. Спрайтовые редакторы, как правило позволяют работать сразу с множеством картинок. Нельзя обойти стороной и музыкальные треккеры.
Следует больше читать, при этом "рассуждая" с автором. Вам это совершенно справедливо рекомендовал GriV, только Вы стали спорить и говорить нехорошее. Так с гуру не поступают. Это снижает Ваш рейтинг ;)
Та яка ризныця ,як сие ЧУДО называть, главное, чтобы удобно было АВТОРУ этого ПОМожет быть действительно никакая, был бы в наличии образец. Но на данном этапе это самостоятельный менеджер, к которому допускается "прикрутка" базовых функций ОС.
Zet9, пример процедуры фреймового вывода/скрола в студию..
а вообще смешно)))))))
Я думаю ученику Zet9, стоит объяснить для чего он создал тему "Пишем свою ОС. Практика." и когда же будет написана указанная им ОС. или хотя бы ее ядро. Ведь если пошла практика значит концепция уже есть, так? в противном случае имеет место быть миссабж
Splinter
10.08.2010, 14:24
да зачем под нее писать? надо так что бы она старые проги понимала.
Не проги а целые дискеты ) Скажем поменяли прошиву TRDOS совсем чучуть, что бы изменить системный приоритет на диск C (а не на A), и винт или флеш накопитель посадить на него. Диск A может запускаться из под OC прямо как есть (вся ос из памяти отгружается на винт так, что бы после сброса в тр-дос вернуться к текущему состоянию, либо на момент выключения, либо на момент запуска boot'a диска A). А запуск прог организовать например так: закидываем полный scl образ в виртуальный дисковод, скажем Z (опять колупание в теле DOS))) еще бы намудрить что нибудь, что бы и дос и проги на дискете понимали бы привод как A), и запускаем файл boot ))). Писать и адаптировать такие модули будет крайне просто, меняем имя запускаемого бейсик файла на boot. Образы scl свободно портируются на pc к тому же. В общем пути и решения достаточно обширные. Писать под ось не надо. Как писали под trdos, так и писать дальше...
Вопрос с многозадачностью. Все приложения к ос сохраняют свои текущие состояния на винте, места много же ))).... а при их вызове восстанавливают свое предыдущее значение (даже текст в редакторе, пока не очистим !) ну и тп...
---------- Post added at 16:24 ---------- Previous post was at 16:12 ----------
Привлекает так же возможность использования в os драйверов как существуещих железок, так и возможных расширений в будущем. Например переключение на расширеный видеорежим ) А стандартный в os где нить окошечком в уголке открывается. Еще можно сделать совместимость с каким нибудь pc-шным образом лент. думаю лучше всего tzx. Ось обрабатывает код модуля tzx, и создает где то на винте образ, который просто после окончания "загрузки" надевается на всю требуемую программе оперативную память спектрума с последующей передачей управления....
....Как писали под trdos, так и писать дальше...Вопрос с многозадачностью. Все приложения к ос сохраняют свои текущие состояния на винте... Все очень интересно, пока речь не заходит о кодинге. У меня тоже все было просто сказка. Сел програмить и недосчитался нескольких килобайт, а еще ведь стек нада куда-то пихать, не одно же приложение будет работать, а, скажем два или три. Если этого не отследить, то система будет слетать "по непонятной причине". Либо следить за стеком, либо "договориться", что стек юзать осторожно (проверяя системные ячейки), а переменные хранить в "своих" участках памяти. Но все это приведет к замедлению работы программ и разрастанию кода.
Идея "жизни" программ "в диске" не нова, а в результате выходит сложный механизм размещения такого приложения в памяти. Подпрограмма размещения и обслуживания такого софта, съест почти всю память, значит потребуется что-то свопировать на электронный диск. Программа свопа, для своего запуска тоже потребует RAM, так что можно подумать и, наверное, от этого отказаться :)
Может я не прав и все это легко реализовать, но на практике столкнулся с таким вот выбором. Либо одна прога в банке (классика вытеснения), либо сложный механизм и специфическое написание приложений. Вернее, написание приложений через ж...:v2_conf2:
А вот здесь мы всё-таки приходим к выводу, что нужна ОС. Что программа не может единолично распоряжаться всем ОЗУ, которое ей доступно и т.д. и т.п. Что программа должна исполняться в некотором окружении, что было оговорено в цпм. Позднее в мсдос. Питер Нортон в 80-х, писал, что если бы все программы бы на пц, взаимодействовали с экраном, клавиатурой и мышью через, хотя бы вызовы bios пц, то, проблем с совместимостью бы было мало. Идеально - их бы не было вообще. Но, как в случае с цпм, так и в случае с мсдос программисты обращались напрямую к "железу" компа. ОС служила лишь, как прослойка, для доступа к файлам, не более того. В рамках спектрума, в принципе, нам этого и достаточно, но проблема в том, что пресловутой "ОС" так и нет..... Есть программно-аппаратные эмуляторы существующих систем и не более того..
---------- Post added at 02:47 ---------- Previous post was at 02:40 ----------
А если идея состоит в поддержке (читай в загружаемости и исполнении) ранее созданных программ, то я свои идеи излагал ещё в 1998г. Западные товарищи предложили ещё один вариант - винтовый вариант +3 плюс к нему программно-аппаратное решение DevIDE. Т.е. в рамках нативного доступа к винту мы имеем доступ к ленточнуму софту(конечно только к тому который обращается для загрузки к процедурам ПЗУ). Но и это, согласитесь не решение! Софт трдос я вообще не знаю как классифицировать...
---------- Post added at 02:55 ---------- Previous post was at 02:47 ----------
Может я не прав и все это легко реализовать, но на практике столкнулся с таким вот выбором. Либо одна прога в банке (классика вытеснения), либо сложный механизм и специфическое написание приложений. Вернее, написание приложений через ж...
В MP/M ещё был применён механизм вытеснения, то что ты описываешь может "кооперация"? А при вытеснении мы имеем хоть сколько задач. Каждой дается максимальный квант времени, после чего она прервется. Управление передастся следующей в списке задаче (по приоритету), насколько я знаю, что даже в W95, диспетчер задач вызывался не ранее чем 1/50c.
А вот здесь мы всё-таки приходим к выводу, что нужна ОС. Что программа не может единолично распоряжаться всем ОЗУ, которое ей доступно и т.д. и т.п. Как только речь заходит об осестроении, начинают собираться всё одни и те же :))))))))))))))) так, в скором времени и объединимся.
...В MP/M ещё был применён механизм вытеснения, то что ты описываешь может "кооперация"? А при вытеснении мы имеем хоть сколько задач.... Не-не, я имел в виду "наше классическое" ZX-вытеснение, например MythOS.
Чтобы тут не возникло ненужных постов с уточнением терминов, скажу, что проги пишутся и потом работают только в окне 49192-65535 (последняя 16к банка) и путем переключателя, находящегося в оперативке "ниже", эти банки меняются с частотой, которую настроит осестроитель или юзер (это мелочи, просто два байтика менять). МифОС четко предупреждает при старте, мол, ребята, на Спеке128 тока 3 проги, по числу свободных банок. Теоретически эту память можно систематизировать и поместить туда даже указатель стека, тогда особые проблемы отпадут. Кое-что из общесистемных, либо буфер обмена можно хранить "внизу". Особых заморочек нет, кроме:
* объем проги всего 16к
* трудности использования доп.памяти (хоть нижнюю забирай)
* придется отслеживать ситуевину, когда обе проги запросили дать оперативки или запросили чтение/запись диска.
* если не использовать регулируемую очередь, то вся работа - это постоянное переключение страниц.
Под кооперативной я понимал простейший, тоже можно сказать, классический для бутов движок. Диспетчер "висит" на прерываниях и поочередно запускает проги + играет музычка. Вероятно здесь придется меньше переключать страницы. Но все, в конечном счете зависит от осеписателя. Вот я думал так, а начал делать приложение и вышло хрен знает как. Но лучше обломиться, чем с пеной у рта доказывать, что, например, такая-то ось должна писаться так, а не по другому :D
зы:
Думаю, что у меня уже не хватит времени да и знаний тоже, чтобы сделать образец диспетчера (на работе много дел и проектов с отчетами), так что время от времени вечерами сижу, набирая текст документации и примеров, которые выложу на отдельный сайт. Может быть кто-нить и возьмется за кодинг или найдет там интересные решения. А, может, у меня появится реальник и дела пойдут в гору.
http://www.worldofspectrum.org/forums/showthread.php?t=32785&page=6
кто-то что-то пишет, мне правда еще не совсем понятно, мож боян ваще
Splinter
06.07.2011, 06:11
Надо взять свою железку, сдуть пыль, подключить винт и поэксперементировать )))...
Редактор ACEdit "держит" несколько текстов.
Нет, только один. Многотекстовость никто не просил.
По теме: для истинной многозадачности надо как минимум два окна памяти (программы/стек и их данные). Но при этом будет ограничен размер кода на задачу. Про ограничение на размер стека даже молчу. Для сравнения, в UNIX на PDP-11 было 8 окон, которые делились на код, данные, стек и системные вызовы.
Если пытаться грузить код в нижнюю память, то после нескольких запусков-закрытий программ она превратится в решето, куда уже ничего не влезет.
Короче, если окно одно, то придётся писать с чудовищными ограничениями (например, делить программу на куски по 256 байт и писать данные в стек по 4 байта за раз, т.е. с типом). Или делать Forth-систему.
Только ATM Turbo 2 и ZX Evolution имеют по 4 окна, а NeoGS и Pentagon 1024SL 2.2 с одной из тестовых прошивок - по 2. Впрочем, в NeoGS можно в процессе загрузки системы сменить прошивку на более умную (уже есть прошивка с 4 окнами). Например, она может ловить сегментные префиксы типа ld a,a и включать заданную страницу на время одной команды. Тогда можно хранить данные страницами по 64К даже без дополнительного окна. Правда, для этого нужная страница данных должна быть в физической памяти, а не в свопе - за этим должна следить как процедура задания номера сегмента, так и шедулер.
---------- Post added at 12:43 ---------- Previous post was at 12:32 ----------
1. Скорость. Для того, чтобы алгоритм был "в 3-4" раза медленне, чем на асме - надо ОООЧЕНЬ постараться. Отключить полностью оптимизацию, писать как попало. Есть, конечно, исключения, но кто мешает сделать ассемблерную вставку ? Как правило, критическая часть кода занимает не более нескольких десятков комманд ассемблера.
Как правило, проигрыш в скорости - проценты. Никак не 3-4 раза.
ZXUnRar после полного переписывания кода (изначально это была ручная компиляция с С команда в команду) удалось ускорить в 11 раз. Jpeg viewer - в 3.5 раза. Разница в проценты бывает только на процессорах с кэшами и конвейерами, с которыми только компилятор умеет грамотно обращаться.
NovaStorm
07.07.2011, 11:18
>для истинной многозадачности надо как минимум два окна памяти
Да и с одним окном жить можно. Например виртуализуя это окно для процесса, а при переключении задач копируя всю его память из банков в основное адресное пространство. Но разве ж это жизнь?..
>Но при этом будет ограничен размер кода на задачу.
Ну 16кб банки хватить должно на многое, и никто не мешает задаче свитчить банк самой.
>Про ограничение на размер стека даже молчу.
Тут, я думаю, драматизировать не надо, стека нужно скорее всего не так уж много - 6502 же как то жил.
>системные вызовы
Могут идти через RST или вообще напрямую в ПЗУху(которую делать всё равно придётся - не бейсик же оставлять?) а дальше, если вызов в код вне 0000-4000 танцевать с банками. Так же и с библиотеками.
>Или делать Forth-систему.
VM ,конечно, решение, но уж слишком радикальное. Без JIT будет слишком медленной, особенно при работе с памятью.
Ну 16кб банки хватить должно на многое, и никто не мешает задаче свитчить банк самой.
Мешает то, что стек лежит в основной странице задачи. Если стек размещать в нижней памяти, то получится искусственное ограничение на число задач.
16К - это не так уж много. Писать под ОС будут, естественно, на ЯВУ. А, к примеру, одна только библиотека поддержки FAT32 на C весит 32К. С другой стороны, байт-код оптимальнее по объёму. Вспомним рекордного по размеру Snake на кодах калькулятора. Если взять программы DNA OS, то увидим ряд характерных конструкций:
LD L,(IX+9):LD H,(IX+10)
OR A:SBC HL,DE
LD E,(HL):INC HL:LD D,(HL):INC HL
LD A,(HL):INC HL:LD H,(HL):LD L,A
В байт-коде это весьма неплохо сожмётся.
Только вот ассемблерные вставки в этом случае не сделать никак.
Самостоятельно следить за размером стека программист не может. Компилятор Аласма, например, складирует туда все программные скобки начиная от INCLUDE и кончая макросами. А когда ещё и обращение к TR-DOS...
NovaStorm
07.07.2011, 14:41
>Мешает то, что стек лежит в основной странице задачи.
С GriV'ом давненько это обсуждали кажется, сошлись на том, что третью четверть можно тоже отдать программам как раз для подобных целей. Такие себе сверх-far call'ы получаются вроде или даже RPC =)
>Если стек размещать в нижней памяти, то получится искусственное ограничение на число задач.
Где размещать стек и как им пользоваться надо дать возможность решать конкретной программе. Потому что наверняка будут мелкие процессы, которых влезет кучка в одну банку вместе со всеми сегментами, и большие, которые будут откусывать от третьей четверти(остаток четверти после экрана наверное всё же за системой).
>Писать под ОС будут, естественно, на ЯВУ.
Не с нашим склерозом на 128к =) Хотелось бы конечно, но даже на Си компилятор породит "ряд характерных конструкций" танцев со стекфреймом. Кстати что за кусок? По идее такое восстановление регистров должно быть только в таскменеджере, при работе с процедурами сохранение их пойдёт через стек, а при выходе просто SP меняется на начало фрейма при входе?
Индексные регистры? Это из файловой системы. Вообще так на Z80 выглядит практически любая работа со структурами/объектами. См. Vars.H, там даже макросы для этого есть: GETWORD, PUTWORD.
Писать под 128К не вижу смысла. Это музейный экспонат, который надо кисточкой протирать. А среди нового парка спектрумов больше всего АТМ2-совместимых - более 200 шт.
Black_Cat
07.07.2011, 16:11
А среди нового парка спектрумов больше всего АТМ2-совместимых - более 200 шт.:) Дима, Спектрумов ATM-совместимых не бывает :) . Есть клоны Спектрума, и есть клоны ATM - и это разные компьютеры. Писать под архитектуру ATM - это значит не писать под архитектуру Спектрума. С таким же успехом можно писать под MSX - это куда как круче чем ATM :)
P.S. :) А Спектрумов с архитектурами: Pentagon, Skorpion, KAY - всё равно больше, и больше будет всегда :)
NovaStorm
07.07.2011, 17:11
>Писать под 128К не вижу смысла.
"What is Speccy?" =)
Писать, ориентируясь на более мощные машины, можно, но "программой минимум" на 128к должны пойти несколько довольно тяжёлых процессов. Или например гуй с косынкой...
Если писать под АТМ или ещё что, то это сразу даст нам 4 банка, а это архитектуру затронет очень сильно(uzix - то, чего можно добиться). Но всё равно не даст максимума из Z80. Был же для него сделан Micronix с офигительным железом под него. ЕМНИП там к Z80 был-таки присобачен полноценный MMU с 2kb страницами.
PS:
>Индексные регистры? Это из файловой системы. Вообще так на Z80 выглядит практически любая работа со структурами/объектами.
И с локальными переменными на стеке АФАИК.
Писать под 128К не вижу смысла. Это музейный экспонат, который надо кисточкой протирать. А среди нового парка спектрумов больше всего АТМ2-совместимых - более 200 шт.
В чем состоит "музейность" 128к по сравнению с ATM2? В чем принципиальное преимущество выпустить продукт для ATM2 по сравнению с 128к?
Я бы понял если бы тут речь шла о 24bit прямоадрессуемом пространстве или скорости большей на порядок а так... в чем?
За последние 15 лет ни одна контора не выпускала 128K. Это значит, что срок эксплуатации этого железа уже истёк. Это принципиальная разница.
А разница в 7 лет между двумя стандартами - это непринципиальная разница по сравнению с этим сроком.
На АТМ2, напомню, мегабайт ОЗУ, 4 окна, цвет на точку и IDE-контроллер. И да, таки турбо.
Black_Cat
09.07.2011, 15:31
А разница в 7 лет между двумя стандартами - это непринципиальная разница по сравнению с этим сроком.:) Если не учитывать, что ATM - это не Спектрум вовсе :)
На АТМ2, напомню, мегабайт ОЗУ, 4 окна, цвет на точку и IDE-контроллер. И да, таки турбо.Это всё, кроме 4 окон есть и на клонах Спектрума. А 4 окна на современных клонах на ПЛИС реализуется элементарно.
Вывод: на лицо безуспешные попытки alone обосновать подмену Спектрума на совершенно левый компьютер, дескать бросайте все Спектрум, и начинайте писать под ATM :) .
"Спектрум-совместимый ПК ATM-turbo 2+ (дальше – просто ATM-2+), обладая всеми возможностями данного класса машин, одновременно сильно выделяется из их числа за счет на порядок более гибкой архитектуры и обширного списка внешних устройств, интегрированных в материнскую плату".
Это первый абзац книги "TURBO2+. Внутренняя архитектура и внешние устройства", которую ты не читал. Впрочем, она для тебя сложновата.
Black_Cat
09.07.2011, 21:57
"Спектрум-совместимый ПК ATM-turbo 2+ (дальше – просто ATM-2+), обладая всеми возможностями данного класса машин, одновременно сильно выделяется из их числа за счет на порядок более гибкой архитектуры и обширного списка внешних устройств, интегрированных в материнскую плату".alone не понимает разницы между клоном Спектрума и спектрум-совместимым компом, отсюда у него в голове каша :) . К спектрум-совместимых компам относятся TimexSinclair, SamCoupe, Enterprise, Sprinter, ATM, и все они не являются клонами Спектрума, а являются самостоятельными компьютерами. ATM отличается от других спектрум-совместимым компьютеров только более точной программной совместимостью со Спектрумом - и только, но это вовсе не значит, что он от этого вдруг стал Спектрумом :).
Внутренняя архитектура и внешние устройства", которую ты не читал."NedoATM - большое будущее Спектрума, или большая ложь NedoPC?" (http://zx.clan.su/forum/7-84-1), которую ты не читал :)
Твоё понимание того, что такое Спектрум, не основано ни на каких чётких критериях.
Твой поток поноса я читал. И жалею потерянного времени.
Black_Cat
09.07.2011, 22:39
Твоё понимание того, что такое Спектрум, не основано ни на каких чётких критериях.
Твой поток поноса я читалПлохо читал, потому что там как раз даются чёткие и простые критерии по которым можно легко определить клон это или самостоятельный компьютер.
Исторически, клоном принято называть компьютер, являющийся неполной копией прототипа. При том, неполнота может быть выражена некоторым развитием в сторону усложнения, или упрощения конструкции. Но между прототипом и его клоном всегда существует эволюционная связь, определяющая эволюционные этапы, необходимые для преобразования прототипа в конкретный его клон. При том, каждое приращение архитектуры должно быть много меньше всего объёма архитектуры. Наличие такой эволюционной связи позволяет определять является ли тот или иной компьютер чьим-то клоном, или это независимая, оригинальная конструкция.
Если рассмотреть в этом ключе компьютер ATM, то можно сказать, что он разработан "с нуля" и не имеет прототипа, модификацией которого он мог бы являться.
Т.е., используя предложенные критерии легко понять, что ATM - это самостоятельный компьютер, который Спектрумом никогда не был, и ессно - никогда им не будет :)
Есть чёткие этапы: Пентагон, Пентагон128, АТМ1, АТМ2. Разумеется, для тех, кто учил историю.
Black_Cat
10.07.2011, 01:29
Есть чёткие этапы: Пентагон, Пентагон128, АТМ1, АТМ2:) Оооо!! Все падайте ниц и трепещите! AloneCoder вещает откровения! :) Т.е. следуя откровениям AloneCoder'а, если некая фирмочка сначала производила Пентагон, потом Пентагон-128, потом АТМ1, а потом АТМ2, то АТМ2 - это ни что иное как развитие Пентагона :) . Т.е. применив алковский шедевр мысли к фирмочке Amstrad, которая после Спектрума производила IBM PC совместимые компьютеры, можно сделать эпохальное открытие - оказывается IBM PC - это развитие Спектрума!! :) Ё-ма-Ё!! А мы тут более 20 лет паримся с TR-DOS и 256х192х16 цветов! :)
Нахрен этот ATM!!!
alco - наш пророк! Он открыл нам глаза и указал путь! :)
ВСЕ НА IBM PC!!! :)
P.S. Дима, а ты не блондинко?
multimax
10.07.2011, 10:41
Хе-хе. "А воз и ныне там" ©
Весьма прискорбно, что некоторые, именующие себя кодерами, спасовали перед данной задачей. Видимо, сие сообщество, юзующее писюки, может только ностальгировать о спекки. А что-то сделать - кишка тонка.
NovaStorm
10.07.2011, 12:34
>спасовали перед данной задачей
На спеке есть ОСи, не одна и не две, но вот пользователей для них что-то не видно. Есть пример uzix'а. То, чего можно достичь. И даже если переписать его на асме целиком, врядли результат устроит пользователя.
Если исходить из сугубо практических целей, идеальная ОСь для нашего спека на сегодня - менеджер образов дискеток и запускалка ТР-ДОСного софта.
>спасовали перед данной задачей
На спеке есть ОСи, не одна и не две, но вот пользователей для них что-то не видно. Есть пример uzix'а. То, чего можно достичь. И даже если переписать его на асме целиком, врядли результат устроит пользователя.
Если исходить из сугубо практических целей, идеальная ОСь для нашего спека на сегодня - менеджер образов дискеток и запускалка ТР-ДОСного софта.
+MagOS.
Black_Cat
10.07.2011, 14:00
На спеке есть ОСи, не одна и не двеЧёт кроме CP/M никаких других ОСей на Спектруме не припомню.. если конечно не называть осями всякие оболочки и загрузочные менеджеры. И не говорите мне что iS-DOS - это ОСь! iS-DOS - это гипертрофированный загрузочный менеджер - переросток! Ибо нельзя на базе загрузочного менеджера построить ОСь, получится то, что получилось - именно iS-DOS :) .
Есть пример uzix'а. То, чего можно достичь. И даже если переписать его на асме целиком, врядли результат устроит пользователя.А что ты хотел? Пользователю есть с чем сравнивать! Но тем не менее на MSX - сходному по классу с современными клонами Спека есть и nix-ы и CP/M и графическая оболочка, и Ethernet, и эксплореры и web серверы и терминальные клиенты и т.д. Конечно, во многом это благодаря уже существовавшей базе из коммерческого софта, но важна сама возможность сделать всё это в виде, понятном и удобном современному избалованному пользователю.
Если исходить из сугубо практических целей, идеальная ОСь для нашего спека на сегодня - менеджер образов дискеток и запускалка ТР-ДОСного софта.Во-во, потоиу как чтоб заниматься ОСями, надо быть системным программистом, а на отечественной Спектрумовской сцене их никогда не было, нет, и никогда не будет.. разве токо заграница опять родит какую-то хрень - а-ля надстройку над БЕЙСИКом для 48k :) . Максимум что могут отечественные спековские кодеры - это кодить демки, да и то вставляя надёрганный код двадцатилетней давности - демосцена съела весь моск! Настоящие кодеры есть токо там, где нет демосцены, например на всяких малопопулярных платформах типа Вектора, Ориона, Башкирии и т.д. Я не удивлюсь, если на убогом РК-86 nix-ы появятся раньше чем на Спектруме, т.к. на РК-86 нет демосцены :)
NovaStorm
11.07.2011, 13:55
>iS-DOS - это гипертрофированный загрузочный менеджер - переросток!
Ну с файликами работает - и ладно.
>если на убогом РК-86 nix-ы появятся раньше чем на Спектруме
Nuttx можно хоть сейчас собрать, проблема довести её до юзабельного на практике вида ну и драйвера дописать. А дальше ситуация та же, что и с MSX'овым софтом - он есть, но пользоваться им как-то не тянет...
Black_Cat
11.07.2011, 17:56
Nuttx можно хоть сейчас собрать, проблема довести её до юзабельного на практике вида ну и драйвера дописать.Если бы на Спектруме были системные программисты, то это был бы всего-лишь вопрос времени.
А дальше ситуация та же, что и с MSX'овым софтом - он есть, но пользоваться им как-то не тянет...А вот это уже вопрос концептуальный, требующий понимания что есть Спектрум, и каково может быть его место в современной информационной среде.
Почему не тянет пользоваться на MSX? Причины две:
1) MSX - это старинный, рассыпающийся и глюкающий от времени гроб значительных размеров, с доисторическим монитором, который никому не придёт в голову постоянно держать на столе для работы. В нашем же случае - Speccy 2010 - новый, идеально работающий компьютер, не занимающий вообще места, работающий с VGA монитором и PC клавой и мышой через коммутатор, и применяющийся совместно с PC не занимая дополнительного места.
2) Отсутствие достаточного количества интернет ресурсов доступных для компьютеров такого класса и развитого интернет-сообщества, использующего такие компьюиеры - устраняется со временем, по мере роста количества компьютеров использующих оные возможности.
1) Зачем нужна ОС на Спектруме:
- программная многозадачность
- переносимость кода (т.е. прекращение вариться в собственном соку, возможность использования наработок всего nix-сообщества, и подключения разработчиков с других платформ)
- работа в современной информационной среде - т.е. поддержка современных файловых систем, сетевых протоколов, языков программирования
2) Необходимо понимание узких мест Спектрума, чтоб разделить сферы применения в соответствии с возможностями как существующего, так и перспективного железа. Для понимания перспектив необходимо так же хорошо понимать идеологию развития Спектрума, чтоб знать каким будет это "будущее железо".
а) Можно точно сказать, что будущее спектрумовское железо не будет иметь ничего общего с архитектурой ATM :) , поэтому NedoPC с PentEvo (правильней сказать - NedoATM-3) идёт лесом и больше никаким боком нас не интересует (это я специально для alco акцентирую, чтоб он об этом больше и не заикался :) ).
б) Узких мест у Спектрума много, по сути Спектрум - это сплошное узкое место :) . Поэтому не будем уподобляться западным товарищам, пытающимся всё развитие уложить в очередные надстройки над BASICом, оставляя неизменной аппаратную архитектуру - это путь в никуда.
Поэтому сразу поставим жирную точку в этом вопросе - ВСЁ БУДУЩЕЕ РАЗВИТИЕ СПЕКТРУМА СВЯЗАНО С РАЗВИТИЕМ АППАРАТНОЙ АРХИТЕКТУРЫ! Хотя никто не говорит, об полном отказе от базовой архитектуры, базовая архитектура может присутствовать как самая урезанная, работа с которой теоретически возможна, но неудобна и ограничена в функционале.
Примем как аксиому - владельцам Спектрумов в базовой конфигурации - OS и все проистекающие из под неё возможности не нужны, для работы под OS необходимо в той или иной степени расширять железо.
Итак, об узких местах, уже в расчёте на некоторое развитие архитектуры:
- минимальное экранное рабочее графическое разрешение для VGA - 512x384 (решается установкой видеокарты)
- желательное экранное рабочее графическое разрешение для VGA - 768x512 (решается установкой видеокарты)
- минимальное рабочее текстовое разрешение для VGA - 64х48 (решается установкой видеокарты)
- желательное рабочее текстовое разрешение для VGA - 96х64 (решается установкой видеокарты)
- минимальная рабочая тактовая частота - 3,5 MHz
- желательная рабочая тактовая частота - 14 MHz (решается приобретением современного клона)
- минимальный объём ОЗУ - 1 Mb (решается паяльником)
- желательный объём ОЗУ - 2 Mb (решается приобретением современного клона, или паяльником)
- обязательное наличие SD, IDE HDD - опционально, FDD - не обязательно (решается установкой карты расширения или приобретением современного клона)
- аппаратная архитектура - Хiмеra (т.е. в первую очередь - менеджер и архитектура памяти, архитектура управления видеорежимами, система портов, архитектура обеспечения аппаратной многозадачности) (решается паяльником или приобретением современного клона)
3) Какие узкие места в первую очередь должен устранить софт под ОС:
- работа с общеприменяемыми файловыми системами FAT16/32 (опционально - системами CP/M)
- работа в текстовых клиентских терминальных программах через Internet (почтовые клиенты, IRC клиенты, текстовые WEB браузеры)
- работа в клиентских программах с FTP сервером через Internet
а "Elite" на этом счастье пойдет?
Black_Cat
11.07.2011, 19:38
а "Elite" на этом счастье пойдет?А як жэ! :) Аппаратная архитектура Хiмеra предполагает возможность запуска любого спековского софта из-под ОС в режиме аппаратной многозадачности без необходимости какой-либо переделки оного.
NovaStorm
12.07.2011, 08:21
>Если бы на Спектруме были системные программисты, то это был бы всего-лишь вопрос времени.
Не столько времени, сколько, имхо, целесообразности. Потому как она килов в 50 влезет. Я это вижу как замену ПЗУхи и несколько банков, а вот потом начинаются проблемы с памятью задач, из чего этот очередной концептуальный флейм и вырос. И можно ли будет обойтись одним переключаемым банком, это вопрос, требующий оч-чень обстоятельного подхода, чтобы не корпеть над кодом, который никому не впился.
>переносимость кода
Зачем тогда нужна твоя Химера? Перенесли весь код на писюк и ок, нэ?
>поддержка современных файловых систем
Угу, zfs например, с кэшем на пару гигов.
>языков программирования
C итак есть, а жабы с дотнетом и не надо =)
>обязательное наличие SD...
Если будет ПЗУха с nix'ами или хотя бы их базовой ДОС частью(а остальную память можно и освободить при этом) то пофиг ведь, SD там или флоп.
>работа с общеприменяемыми файловыми системами...
Ну фат ладно, для удобного общения с внешним миром, хотя и без неё можно обойтись, а вот больше врядли что нужно, для ОСи скорее всего выгоднее своя ФС, с минимальным потреблением проца, скорее всего простенькая до ужаса.
А интернет... не верю, что он будет нужен.
Black_Cat
12.07.2011, 12:25
а вот потом начинаются проблемы с памятью задач, из чего этот очередной концептуальный флейм и вырос. И можно ли будет обойтись одним переключаемым банком, это вопрос, требующий оч-чень обстоятельного подхода, чтобы не корпеть над кодом, который никому не впился.Не надо мучиться с одним окном! Именно поэтому ориентируемся не на классику, а на развитие аппаратной архитектуры. 4ре окна - это не проблема, всё это есть в архитектуре Хiмеra. Поэтому, если ты понимаешь требования ОСи к железу - изложи, чтоб определить узкие места - я не системный программист, и представляю механизм работы ОС смутно.
Ещё раз хочу подчеркнуть подход - по возможности, и в рамках идеологии развития Спектрума, делаем железо под ОСь, а не ОСь под ограничения старого железа. Узкие места, о которые обычно спотыкается софтостроение на Спеке я описал, и помоему расширил их до вполне приемлемых возможностей, на которые можно ориентироваться чтоб не приходилось изголяться через задницу.
>переносимость кода
Зачем тогда нужна твоя Химера? Перенесли весь код на писюк и ок, нэ?
Это глобальная идеологическая проблема. Смысл сего - чтоб разорвать замкнутость платформы в себе, путём обеспечения движения софта, а вместе с ним и кодеров. Если этого не сделать - платформа так и останется уделом замкнутой кучки любителей, да ещё и самой низкой квалификации, потому как профессионалам замкнутая в себе платформа не интересна, им именно некогда вникать во все перипетии спековских глюков и ограничений. Хiмеra разрабатывалась именно для разравнивания площадки поля деятельности для профессионалов, чтоб они по минимуму были стеснены ограничениями Спектрума, но при этом чтоб архитектура оставалась именно спектрумовской, а не ATMной, MSXной или ещё какой левой, т.е. чтоб при всём этом сохранялся just for fan и дух спектрумизма, иначе - зачем мы все здесь, если вместо Спектрума втюхивать всякую левизну типа ATM и иже? :) .
Угу, zfs например, с кэшем на пару гигов.Именно поэтому я и говорил, что:
2) Необходимо понимание узких мест Спектрума, чтоб разделить сферы применения в соответствии с возможностями как существующего, так и перспективного железа. Т.е. не надо хвататься за то, что Спеку не по силам. Есть достаточно задач, которые он потянет так, чтоб это было удобно и практично в пользовании, вот на них и нужно сконцентророваться, отложив всё ресурсоёмкое до лучших времён, когда Спектрум сделает следующий шаг в аппаратном развитии. А такое развитие уже сейчас заложено в архитектуру Хiмеra, например переход на eZ80, а это - 50MHz, команда на такт, 16Mb непосредственно адресуемой памяти, при софтовой совместимости снизу - вверх + режим полной совместимости с Z80 по тактам - для старого софта.
C итак естьвот токо все почему-то плюются от того что есть и вообще не используют..
>обязательное наличие SD...
Если будет ПЗУха с nix'ами или хотя бы их базовой ДОС частью(а остальную память можно и освободить при этом) то пофиг ведь, SD там или флоп.Для ОСи - пофиг, но не пофиг для юзера! Это я к тому, чтоб беспощадно пресекать и выжигать калёным железом, всякую ориентацию на умершие стандарты и носители как на базовые! Опционально - пожалуйста, подключайте любую экзотику, но базовая ориентация - только на современное железо!
для ОСи скорее всего выгоднее своя ФС, с минимальным потреблением проца, скорее всего простенькая до ужаса.Это можно рассмотреть, но для начала - нужен FAT, чтоб разорвать информационную замкнутость платформы.
А интернет... не верю, что он будет нужен.:) интернет - это обжитой и огороженный участок центрально регулируемой сети, но не вся сеть :) Сейчас будет развиваться децентрализованная сеть, и Спектрум надо к этому хоть минимально подготовить. Т.е. чтоб был реализован хоть нижний уровень с необходимыми сетевыми протоколами. Чтоб оставалось токо добавить интерфейсную аппаратную часть. FIDONet - возвращается! :v2_dizzy_mutant: :)
Друзья! Вы бы вначале подумали - надо ли оно кому-либо... Большинству надо в игрушки поиграть да демки посмотреть... А тех, кто пишут что-либо на реале, единицы...
Black_Cat
12.07.2011, 12:43
Друзья! Вы бы вначале подумали - надо ли оно кому-либо... Большинству надо в игрушки поиграть да демки посмотреть... А тех, кто пишут что-либо на реале, единицы...
BYTEMAN, дя тех кто токо играет в игрушки есть соответствующая рубрика. Я же не пишу туда концепции :) Давай будем соблюдать установленную сегрегацию, и не лезть со свинным рылом в калашный ряд :) . А игрушки на Хiмеr'е ессно будут работать, даже хоть несколько штук одновременно, если кому такое потребуется :)
NovaStorm
13.07.2011, 09:09
Друзья! Вы бы вначале подумали - надо ли оно кому-либо...
Врядли нужно, но каждый дрочит как он хочет, и БК я, пожалуй, тут, думаю, понимаю, хотя сам и считаю, что вносить такие изменения в архитектуру спека уже поздно. А делать что-то новое на его базе нелогично, получается слишком много костылей. А уж если взять для сравнения систему на каком-нить Cortex-M3 или даже M0, то становится совсем печально.
>чтоб при всём этом сохранялся just for fan и дух спектрумизма
Какой тут дух, если рядом железо(и не обязательно писюк, даже телефоны уже в разы мощнее пней133, на прайсы с которыми лил поток слюны спектрумистов в 90е =) ), на котором то же самое но быстрее и проще?
>>C итак есть
>вот токо все почему-то плюются
Плюются наверное потому, что не все могут нормально писать на Си под голое железо без ОСи, libc и линкеров/загрузчиков/DLL.
На eZ80 лучше не закладываться, в нём куча костылей, черезжопный доступ к памяти с режимами обратной совместимости(причём на разных моделях не всё поддерживается, 16-битный I вроде не везде), геморойное написание кода под часто переключающиеся ADL/Z80 режимы, встроенное железо со своими портами, свой компилятор, который вкупе с 24-битной архитектурой вообще в моём видении делает eZ80 хрен-пойми-кому нужным.
В общем замены Z80 нету =)
А революционным скачком в развитии архитектуры мне видится нормальный MMU с MPU и виртуализацией адресов, который реализовывал хотя бы системный и пользовательский режимы, трапал нелегальные инструкции и обращения к памяти(пусть даже и без свопа, тут ситуация вообще смешная - всё с точностью до наоборот с "большими" системами - адресное пространство маленькое, а памяти дофига). Даа... но такая штука сразу пошлёт лесом весь софт, который заложен на время в тактах. Поэтому и нужно наверное что-то проще, потому как для арма например MMU в размерах сравним с ядром, а это будет 20-30к ячеек в матрице(тут я 0, но пальцем в небо, где-то так наверное).
//Ох, ладно, с утра что-то соображается по этой теме как-то туго =)
тут главное подумать, кому это вообще надо и почему для ЭТОГО будет делаться софт. скока продано пентев? около 200 штук? что-то не видно рвения использовать новые фичи. из этих 200 купивших только человек 5 хоть что-то делают для пентевы.
а химера - не существует, и не будет существовать, потому что БК не асилит. а если бы даже асилил, и ЧУДОМ продал пару сотен штук, все равно бы софта не появилось. для того, чтобы хоть что-то пошло-поехало, нужна очень мощная поддержка эмуляторами и SDK - это очень сложно поднять. и мотивация должна быть у народа, но откуда ей взяться? про армы и пр. выше уже сказали...
Black_Cat
13.07.2011, 13:08
хотя сам и считаю, что вносить такие изменения в архитектуру спека уже поздно. А делать что-то новое на его базе нелогично, получается слишком много костылейВсякие рассуждения о том что поздно - в этой рубрике игнорируются, поэтому просьба - подобное нытьё здесь не постить вааще.
Какой тут дух, если рядом железо(и не обязательно писюк, даже телефоны уже в разы мощнееКакой - никакой, а какой-то есть, раз все здесь тусуются, а раз факт на лицо - то и нытьё по этому поводу неуместно.
Больше эти вопросы просьба не поднимать! Будет расцениваться как троллинг!
>>C итак есть
>вот токо все почему-то плюются
Плюются наверное потому, что не все могут нормально писать на Си под голое железо без ОСи, libc и линкеров/загрузчиков/DLL.помоему косяки были из-за неоптимального кода при переводе из Си в систему команд Z80
На eZ80 лучше не закладываться, в нём куча костылей, черезжопный доступ к памяти с режимами обратной совместимости(причём на разных моделях не всё поддерживается, 16-битный I вроде не везде), геморойное написание кода под часто переключающиеся ADL/Z80 режимы, встроенное железо со своими портами, свой компилятор, который вкупе с 24-битной архитектурой вообще в моём видении делает eZ80 хрен-пойми-кому нужным.Просьба не валить всё в одну голословную кучу.
- Никаких костылей в eZ80 нет ..по крайней мере с т.з. аппаратчика.
- Доступ к памяти нормальный. Нам нужен режим Z80 токо при работе со старым софтом. Переключаться часто туда-сюда не надо будет. Под ОС ессно будет юзаться токо ADL.
- встроенное железо софту не мешает - это проблема аппаратная. В самом худшем варианте, в Z80 режиме могут поехать бордюрные эффекты - да и срать на них, это не демосценерская машина, сценеры пусть Z80 юзают на 3,5MHz.
- 24 битная архитектура это лучше чем 16 битная и юзаться будет токо под ОС
но такая штука сразу пошлёт лесом весь софт, который заложен на время в тактах.Ещё раз напоминаю - под ОС нам насрать на весь старый софт! ОСь нам нужна для СОФТОВОЙ многозадачности под новый софт! А для старого софта в архитектуре Хiмеra предусмотрена аппаратная многозадачность и аппаратная виртуализация, где практически весь старый софт будет работать аутентично.
В общем замены Z80 нету =)
А революционным скачком в развитии архитектуры мне видится нормальный MMU с MPU и виртуализацией адресов, который реализовывал хотя бы системный и пользовательский режимы, трапал нелегальные инструкции и обращения к памяти(пусть даже и без свопа, тут ситуация вообще смешная - всё с точностью до наоборот с "большими" системами - адресное пространство маленькое, а памяти дофига).
А какая тогда разница между PC и ZX который повторит ее?
"В таком случае проще купить мать типа как http://www.asus.com/Motherboards/AMD_CPU_on_Board/E35M1M/, добавить свой BIOS, зашить эмулятор и тогда при включении выбирать или запускать нормальную систему или спек, и в твоем распоряжении и жесткий и пишущий..."
И почему так все еще держаться за ZX? Что в нем такого особенного? (Может из-за того, что он в разы проще и поэтому понятней?) А писать и делать будут тогда, когда это будет выгодно... Или это не так? Создавайте группу профессиональных людей, готовых и понимающих, что и как нужно делать для ZX, и только так (мое мнение) можно еще что-то сделать.
И почему так все еще держаться за ZX? Что в нем такого особенного? (Может из-за того, что он в разы проще и поэтому понятней?)
не скажу за всех, но сейчас проще, понятнее, доступнее и интереснее - микроконтроллеры. на них можно легко свой микрокомп собрать, с дисплейчиком. а то, что происходит со спеком - это фанатство, никакого другого объяснения, наверное нет. и в этом случае не очень понятно желание кого-то изобрести новый комп, который будет круче. круче многоядерного пня все равно не изобрести, т.е. люди банально хотят сделать свой комп, пофиг что он нафиг не нужен большинству. отсюда все эти концепции.
Black_Cat
14.07.2011, 12:42
а то, что происходит со спеком - это фанатство, никакого другого объяснения, наверное нетДа, именно фанатство, но в хорошем смысле. Никак иначе обьяснить поведение людей собирающих Ленинград чтоб тут же начать его апгрейдить я не могу. И таких эдесь большинсво ..за исключением раэве что psb, которому
не очень понятно желание кого-то изобрести новый комп, который будет круче
люди банально хотят сделать свой комп, пофиг что он нафиг не нужен большинству. отсюда все эти концепцииПоскольку такое желание есть у всех здесь присутствующих за исключением psb, а знаний как это сделать правильно как правило нет, то для восполнения этого пробела в знаниях и была создана рубрика "Концепции", которую сразу невзлюбили ламеры, т.к. с появлением этой рубрики их ламерство становилось явным всем. :)
Black_Cat
14.07.2011, 18:11
народ развлекается, а практики нет
если исключить некоторых товарисчей, которые заходят токо чтоб сказать что это никому не надо, то всё остальное - это как раз по теме. Мы щас устраняли точки непонимания программистами как строить ОС и вроде терь всё всем понятно. Но проблема в том, что обычно как токо все глобальные неясности устраняются, и можно беспрепятственно гнать код, желающих программистов не находится, и тема повисает до прихода очередного любопытствующего программиста, которому придётся всё объяснять с нуля, а как только ему станет всё ясно и нужно будет делать код - он пропадает, и дальше наступает GO TO в начало до появления следующего любопытствующего программиста.
Error404
15.07.2011, 11:39
к слову, у меня есть несколько интересных релизов, которыми никто не пользуется, потому что нафиг не надо, только у меня нет баттхерта по этому поводу.
Ну, это как у всех.
Я сугубо от процесса прусь. Даже не очень важно выйдет ли оно когда-то за пределы эмулятора. С этой точки зрения чем дольше тянется процесс - тем лучше. :)
я буду вынужден инициировать удаление твоих постов из топика, т.к. это чистый троллинг.
это не чистый троллинг, это моё имхо. но если кто-то посчитает нужным что-то там удалить - пусть удаляет:) я еще потом нагенерю, как тема будет.
---------- Post added at 15:56 ---------- Previous post was at 15:54 ----------
А что мешает сделать это?
наверное, ничего не мешает, кроме страха, что народ не оценит и не будет юзать. так уже не останется отмазок...
...Мы щас устраняли точки непонимания программистами как строить ОС и вроде терь всё всем понятно. Но проблема в том, что обычно как токо все глобальные неясности устраняются, и можно беспрепятственно гнать код, желающих программистов не находится, и тема повисает до прихода очередного любопытствующего программиста, которому придётся всё объяснять с нуля, а как только ему станет всё ясно и нужно будет делать код - он пропадает, и дальше наступает GO TO в начало до появления следующего любопытствующего программиста.
Стоп стоп стоп, тут или я что-то пропустил или БК выдает желаемое за действительное "по Фрейду". Где это "устраняли точки непонимания программистами"? Зачем вообще учить программиста, можно изложить четкое ТЗ в доке и выложить всем для скачивания. На скоко я представляю понятия о том какой должна быть ОС нету (по крайней мере если речь идет о каком-то стандарте на приложения которые смогут работать и на оригинале 82-го года и на воображаемой будущей "Химере").
а) Можно точно сказать, что будущее спектрумовское железо не будет иметь ничего общего с архитектурой ATM :) , поэтому NedoPC с PentEvo (правильней сказать - NedoATM-3) идёт лесом и больше никаким боком нас не интересует (это я специально для alco акцентирую, чтоб он об этом больше и не заикался :) ).
Это вообще смахивает на какой-то холивар, как мне видится любой клон спека (в том числе и ATM) должен легким движением по замене Z80 на плату с FPGA превращаться в "Химеру". В чем скажем разница в этом плане между Penevo и Ленинград-1?
Читал-читал, так и не понял что хочется от ОСи. Каково тех.задание?
По мне так: драйвера для доступа к железу, причем не важно какой клон у юзера, и какое железо. Прога делает вызов драйвера и просит прочитать 12345 сектор в накопителе №0 и получает его. В независимости что за контроллер стоит стоит у юзера. Плюс нужен репозиторий с либами.
И чё вы привязались к ТР-ДОС забудьте про него. Практически любую прогу можно либо в хобету перевести, либо снап сделать на крайний случай.
По поводу АТМ это вы зря. Очень геморно грутится в одной банке памяти. Я тут компилил FATFS дык она полторы банки съедает. Ща мне тут скажут "Пиши на асме", FATFS на Си писался несколько лет, и повторять такой подвиг чёта не охота.
Black_Cat
24.07.2011, 13:43
можно изложить четкое ТЗ в доке и выложить всем для скачиванияя не открывал этот топик, и он не мой, я всего лишь пытался направить его в конструктивное русло
как мне видится любой клон спека (в том числе и ATM):) в том-то и дело, что АТМ не клон Спека, а совершенно левый самостоятельный компьютер, как и Таймекс, СамКоупе, Энтерпрайз, и Спринтер :) . Я уже устал это повторять и объяснять.
должен легким движением по замене Z80 на плату с FPGA превращаться в "Химеру":) если Спектрум доработан до стандарта NemoBus v.1.2, то легким движением может быть вставлена плата расширения, расширяющая возможности до архитектуры Хiмеra :) . Другого пути нет.
В чем скажем разница в этом плане между Penevo и Ленинград-1?:) в том, что ПентЭво - это название прошивки для НедоАТМ-3, специально так выбранное чтоб вводить в заблуждение публику, а Ленинград - это клон Спектрума :)
Читал-читал, так и не понял что хочется от ОСи. Каково тех.задание?
По мне так: драйвера для доступа к железу, причем не важно какой клон у юзера, и какое железо.да, ты не понял, потому что драйверами ОС заменить нельзя :)
По поводу АТМ это вы зря. Очень геморно грутится в одной банке памятииспользуй спековскую архитектуру Хiмеra, и тебе больше не придётся мучиться и юзать всякую АТМоскую левизну :)
можно ли создать файл прошивки, на основе Unreal Speccy, который сделать базовым для всех клонов ZX?о какой прошивке речь? Если ПЗУ, тоды при чём тут эмулятор?
используй спековскую архитектуру Хiмеra
Это с какого боку она спековская?
Или zx.pk.ru занимается стандартизацией?!
И на чём её можно поиспользовать, в каких спектрумах она реализована?
Теперь по теме (вернее близко к теме).
У меня сейчас возникла необходимость в "длинных"(между страницами) переходах. Может у кого уже есть концепция-алгоритм как это организовать. И как передавать данные в процедуру, причём часто надо передавать указатели на данные.
Black_Cat
24.07.2011, 15:33
Это с какого боку она спековская?:) со всех :) в этом и состоит задача чтоб архитектура развивалась именно как спековская, а не АТМная, или ещё какая левая :)
Или ZX.PK.RU занимается стандартизацией?!ZX.PK.RU ничем заниматься не может, это форум :)
И на чём её можно поиспользовать, в каких спектрумах она реализована?
Black_Cat
24.07.2011, 16:33
И на чём её можно поиспользовать, в каких спектрумах она реализована?для начала я бы рекомендовал реализовать архитектуру в эмуляторе, т.к. как понимаю это самая удобная среда для отладки, а в конце можно перенести и на клоны с FPGA
У меня сейчас возникла необходимость в "длинных"(между страницами) переходах. Может у кого уже есть концепция-алгоритм как это организовать. И как передавать данные в процедуру, причём часто надо передавать указатели на данные.
хе-хе... это самая ЖЕСТКАЯ проблема - 64kb limit. Пока функционал прог можно влепить в этот limit все как бы нормально. Как токо прога начинает быть хоть немного полезной (отвечать современным требованиям) так она уже никак не влазит в 64кб адресного. Многие платформы типа БЭСМ и PDP-11 погибли в основном по причине наличия этого лимита.
Так что выхода тут токо 2:
0. (обычный путь которым прошли все выжившие платформы) переход на процессор с большим лимитом адресного пространства и портирование нужного софта. В случае Химеры это установка ez80 + 16MB RAM.
1. (СЛОЖНЫЙ ДО УЖАСА, реализован в некоторых реальных прогах) разбить функционал проги на куски так чтобы места в памяти хватало! :) Алгоритм такой:
а) написать всю прогу на платформе где нет ограничения памяти;(при этом экран спека можно просто обьявить как массив на 6912 байтов и рисовать в него, при необходимости конвертировать изображение на экран реальной системы 50 раз в секунду).
b) разбить МАССИВ ДАННЫХ написанной проги на куски которые не зависят друг от друга (т.е. сгрупировать куски ДАННЫХ которые используются кодом только ВМЕСТЕ в отдельные группы, тут главное чтобы эти куски ДАННЫХ помещались потом в свободный RAM, (свободный RAM для спекки это = ВЕСЬ RAM(49152байт) - минимальный сегмент кода (16384байта) - экран (6912байт) - STACK (2000 байт???) - KERNEL (856 байт???) и ТОГО ~23000 байт) ). Если вдруг длинна куска ДАННЫХ больше свободной RAM то пытаться переписать прогу так чтоб кусок ДАННЫХ влез!
с) разбить весь код на куски длинной с минимальный сегмент кода (для спекки 16384байта);
d) все межсегментные JMP-ы\CALL-ы, обработку прерываний, проводить через KERNEL - маленький кусочек кода; При этом нужно учесть что этот кусочек должен уметь "включать" нужный массив данных для нужного сегмента кода перед тем как сделать реальный JMP/CALL.
e) если скорость будет все еще приемлемая то все должно получиться. :)
Black_Cat
24.07.2011, 20:28
Речь в теме идет о создании новой операционной системы для всех моделей ZX, где основным фактором, (поправьте меня, если я ошибаюсь!), будет наличие ядра системы, к которой будут подгружаться (или иным способом будут внедрены) конфигурации (можно их называть драйверами, кому как нравиться) для каждой модели отдельно.Ты себе это очень смутно представляешь, т.к. не знаешь основного постулата - на Спектруме невозожно создать ОС, под которой будет нормально работать спековский софт.
Архитектура Хiмеra базируется на этом постулате, и позволяет его обойти путём аппаратного создания виртуальных машин для спековского софта, управляемых ОС.
Поэтому ни о какой "новой операционной системы для всех моделей ZX" и речи быть не может. Многозадачная, и даже реалтайм ОС исполняющая нормально спековскй софт возможна только на архитектуре Хiмеra. Другое дело, что сама архитектура позволяет существовать виртуальным машинам (ВМ) четырёх базовых конфигураций, которые можно выбрать при создании ВМ:
- SKAY (Scorpion+KAY)
- Pentagon
- Profi
- +3.
Black_Cat
24.07.2011, 23:05
Я внимательно прочел всю тему: "ХИМЕРА" - реальная концепция в ZX-строении:) это не то :) , топик Концепция "ХИМЕРА" и аппаратная архитектура Хiмеra не связаны практически никак. Лучше посмотри десяток-два последних страниц этого топика http://www.zx.pk.ru/showthread.php?p=360130#post360130
разбить МАССИВ ДАННЫХ написанной проги на куски которые не зависят друг от друга
Спасибо. Десять слов которые наверно смогут мне помочь. LVD мне уже говорил об этом, но я его не понял.
Независимого кода очень мало, скорей всего придётся дублировать код в страницах. FATFS весит 24кило с драйверами ZSD+NEMOIDE+RTC, без учёта кешей(1.2кило) плюс активно юзается стек (~100-150 байт). По моим прикидкам чисто FATFS займёт 3-4 страницы памяти(с учётом дублирования кода). Опять же нужно место и для читаемого/записываемого файла, а с этим все намного сложнее, особенно при адаптации старых программ под FAT, очень много LDIRить придётся.
Нда гемор ещё тот, скорей всего отложу до лучших времён(реализации Химеры). А пока буду допиливать свой проект под ZX-Евой, там немного по проще с памятью, и всё прекрасно работает. Почаще щёлкаю страничками в трех банках, в четвертой обёртка лежит.
---------- Post added at 09:26 ---------- Previous post was at 09:09 ----------
Как вариант, брать за основу: "KalibriOS" и "MenuetOS".
Там исходники на асме под х86, автоматом никак не переделаешь. Нужно всё руками переписывать, а для этого нужно очень хорошо знать архитектуру и ассемблер одновременно Спекки и РС.
Причём таких людей нужно минимум десяток, что бы распараллелить конвертацию. Что бы понять трудоёмкость процесса, возьми 50 строк кода и попробуй их переписать под Z80.
Error404
25.07.2011, 09:40
FATFS весит 24кило с драйверами ZSD+NEMOIDE+RTC, без учёта кешей(1.2кило) плюс активно юзается стек (~100-150 байт).
Интересно про FATFS. Какой используешь компилятор чтобы получать Z80-код? Ведь нужна нативная поддержка 32-битных типов. И какую версию FATFS? Я в свое время дошел только до 6-й (последней без длинных имен), остальные показались слишком сложными.
NovaStorm
25.07.2011, 10:23
если Спектрум доработан до стандарта NemoBus v.1.2, то легким движением может быть вставлена плата расширения, расширяющая возможности до архитектуры Хiмеra
И что из спековского железа в получившемся Франкенштейне будет использоваться? При том, что хочется и eZ80 и много памяти, остаётся клавиатура что ли?
ZXFanat, Колибри - форк Менуэта, писана на 386 асме, внутри полнейший бардак из наслоений потоков мыслей целой толпы, для спека бесполезна.
---------- Post added at 10:23 ---------- Previous post was at 10:15 ----------
плюс активно юзается стек (~100-150 байт)
Как оценивал?
Почаще щёлкаю страничками в трех банках, в четвертой обёртка лежит.
Как вариант - RPC, но накладные расходы конечно вырастут.
Black_Cat
25.07.2011, 11:42
И что из спековского железа в получившемся Франкенштейне будет использоваться? При том, что хочется и eZ80 и много памяти, остаётся клавиатура что ли?задай вопрос по другому. Из спековского железа будет использоваться абсолютно всё, т.к. архитектура Хiмеra - это абсолютный Спектрум :)
Интересно про FATFS. Какой используешь компилятор чтобы получать Z80-код? Ведь нужна нативная поддержка 32-битных типов. И какую версию FATFS? Я в свое время дошел только до 6-й (последней без длинных имен), остальные показались слишком сложными.
z88dk
Компилил самую последнюю версию(весной) R0.08b (revision ID 8237),LFN отключил, пока не нужно. Весь функционал проверил, работает на сто процентов.
---------- Post added at 12:01 ---------- Previous post was at 11:56 ----------
Как оценивал?
чисто субъективная оценка. Анализировал код после компиляции, т.к. были баги. FATFS писался под GCC, некоторые вещи z88dk неправильно компилились, преобразования типов в нескольких местах подправил и ещё что то, непомню что.
NovaStorm
25.07.2011, 12:03
>Хiмеra - это абсолютный Спектрум
Видать где-то линию логики я теряю, Эва-то по-твоему не спек... Хотя если судить по её истории, то она должна являться апогеем костылестроения, в отличии от стройной химеры.
Да и насчёт реального времени не могу понять, как об этом можно говорить применительно к ВМ? Ведь для обеспечения гарантированного времени реакции надо вешаться на NMI, а в химере это вроде бы отключаемо. Да и время (ну насколько мельком поглядел) захода в обработку ВМ, что-то слишком велико. По идее, что для хоть какого-то практического РВ, что для кучи ВМ, надо дёргать NMI не реже 100гц, ну 50 - с кадровой =)
Хотя если судить по её истории, то она должна являться апогеем костылестроения, в отличии от стройной химеры.
В настоящий момент(по моему мнению) на ZX-Evo лучший диспетчер памяти, другие клоны позволяют лишь в одной банке пейджами оперировать.
В АТМ согласен, довольно сложно включать диспетчер памяти.
Black_Cat
25.07.2011, 12:34
Видать где-то линию логики я теряю, Эва-то по-твоему не спек... Хотя если судить по её истории, то она должна являться апогеем костылестроения, в отличии от стройной химеры.У ПентЭво не только архитектура, но и идеология АТМ - присоединение к себе других платформ. Т.е. костылестроение заложено уже изначально в идеологию развития АТМ, поэтому ПентЭво (т.е. НедоАТМ-3) и не могла быть ничем иным кроме как уродливым сараем со множеством подпорочек-костылей.
Да и насчёт реального времени не могу понять, как об этом можно говорить применительно к ВМ? Ведь для обеспечения гарантированного времени реакции надо вешаться на NMI, а в химере это вроде бы отключаемо. Да и время (ну насколько мельком поглядел) захода в обработку ВМ, что-то слишком велико. По идее, что для хоть какого-то практического РВ, что для кучи ВМ, надо дёргать NMI не реже 100гц, ну 50 - с кадровой =)Так и предполагается. В реалтайме несколько ВМ работают поочерёдно по NMI, с минимальным квантом 20мс. На кадровом гасящем происходит смена ВМ операционной системой.
NovaStorm
25.07.2011, 12:55
>не могла быть ничем иным кроме как уродливым сараем со множеством подпорочек-костылей
А ты смотри глубже, по мнению некоторых, костыли начались прямо со 128го =)
>с минимальным квантом 20мс
Про то и речь, для минимального 20мс - много. Диапазон от 50 до 1000 Гц на мой взгляд предпочтительнее. Ну или плюсом ещё как у одной из атарей, кажется, по строчному ещё инт сделать.
А как грамотней организовать доступ к библиотеке?
я вижу три варианта :
1.В начале либы пачка JP
2.Передавать номер функции через регистр
3.Номер функции в следующем байте после CALL
Black_Cat
25.07.2011, 13:53
по мнению некоторых, костыли начались прямо со 128го =)
:) 128 нелья назвать лучшей концепцией развития Спека, но время вспять не повернуть - что получилось, то и стало Спектрумом128, т.е. стало стандартом Спектрума128, от которого пошли другие клоны :) . ПентЭво к этому никакого отношения не имеет, т.к. является клоном АТМ.
для минимального 20мс - много. Диапазон от 50 до 1000 Гц на мой взгляд предпочтительнееВМ в основном предназначались для спековского софта, т.к. он не может нормально работать под классической ОС. Весь остальной софт не имеет таких ограничений и должен будет работать исключительно из под ОС с софтовой многозадачностью.
Ну или плюсом ещё как у одной из атарей, кажется, по строчному ещё инт сделать.такая возможность предусмотрена
просто ради интереса:
1. когда придет нми - адрес возврата упадет в стек, регистры надо сохранить куда-то. а если нельзя стек портить?
2. как работать с дисководом/магнитофоном, которые требует полный реалтайм? цифровой звук? тут разделение работы вм во времени не покатит.
NovaStorm
25.07.2011, 14:11
DimkaM, Если хочется, как у людей, то "Linkers and loaders".
Если изобретать собственный велосипед, то придётся много думать. Потому как для существования библиотек нужно существование формата исполняемых файлов, а загружать их должна хоть прото-, но ОСь.
А без виртуальной памяти(окно пока не в счёт) и с ограниченным адресным пространством проблем вообще куча выходит.
---------- Post added at 14:11 ---------- Previous post was at 14:09 ----------
1. когда придет нми - адрес возврата упадет в стек, регистры надо сохранить куда-то. а если нельзя стек портить?
Ну в таких случаях обычно подставляют в адресное пространство "системную" память.
Black_Cat
25.07.2011, 14:11
1. когда придет нми - адрес возврата упадет в стек, регистры надо сохранить куда-то. а если нельзя стек портить?а голова зачем? Никто не заставляет всё запускать обязательно в реалтайме
2. как работать с дисководом/магнитофоном, которые требует полный реалтайм? цифровой звук? тут разделение работы вм во времени не покатит.А зачем это делать в реалтайме? Кроме того, при создании ВМ, ей сразу задаются её права на неразделяемые ресурсы. Поэтому пользоваться каждым неразделяемым ресурсом в реалтайме сможет только одна адача, для которой этот ресурс разрешён.
NovaStorm
25.07.2011, 14:45
ПентЭво к этому никакого отношения не имеет, т.к. является клоном АТМ.
А просвети, какие костыли есть в АТМ, что она не подпадает под "концепцию развития"?
Дополнительные неправославные видеорежимы? Палитра? CP/M?
Ну в таких случаях обычно подставляют в адресное пространство "системную" память.
это понятно. вы выше хотели нми не кратный инту. допустим, вы не попортили стек, но чтобы все работало без глюков, восстановить контекст нужно будет точно там, где он был сохранен (время относительно инта). и речь даже не о мультиколорах. геморрой, да и только:)
а голова зачем? Никто не заставляет всё запускать обязательно в реалтайме
причем реалтайм, когда речь шла про инт?
А зачем это делать в реалтайме?
а каким образом ты будешь грузиться с ленты НЕ в реалтайме? там тормозить нельзя, любой нми нафиг собьет синхронизацию. или как это обойти-то?
NovaStorm
25.07.2011, 15:04
вы выше хотели нми не кратный инту. допустим, вы не попортили стек, но чтобы все работало без глюков, восстановить контекст нужно будет точно там, где он был сохранен (время относительно инта). и речь даже не о мультиколорах. геморрой, да и только:)
Это БК хочет =)
А на мой взгляд, тоже, подобная виртуализация малой кровью не дастся. Да и не нужна она мне. Что можно сделать, так это просто перевод в режим совместимости, в котором получим те же спек+костыли.
Error404
25.07.2011, 15:29
а каким образом ты будешь грузиться с ленты НЕ в реалтайме? там тормозить нельзя, любой нми нафиг собьет синхронизацию. или как это обойти-то?
Вообще-то и с дисковода тоже надо успевать прочитывать регистр пока трек разматывается (хотя времени для маневра конечно несколько больше).
Вопрос в другом - а кому нужны все эти магнитофоны, дисководы? Равно как и софт, съедающий все такты и критичный к порче стека, и все лишь для вращения кубика и скролла с факами?
Как я понимаю, концепция строго противоположная строительству "парусника в бутылке" - т.е. демоделанию.
---------- Post added at 15:29 ---------- Previous post was at 15:21 ----------
А как грамотней организовать доступ к библиотеке?
я вижу три варианта :
1.В начале либы пачка JP
2.Передавать номер функции через регистр
3.Номер функции в следующем байте после CALL
Посмотрите как это реализовано в Uzix (подобно же и реализовано). Там тоже диспетчер системных вызовов с номерами функций, система передачи параметров в регистрах, и, кстати, весь LIBC есть в исходниках, и не только libc. Не обязательно же гнаться за многозадачностью, а идеи - они и в Африке...
С многобанковостью есть одна единственная закавыка - как обрабатывать память в другой странице, на которую передан указатель. Медленно (через копирование), или подгонять сегмент данных (чтобы гарантированно попадало в окно диспетчера, но тут надо писать свой компилятор) или как-то еще? Аналогично и со стеком (если пишем на С). Или вообще не использовать передачу указателем (чему, кстати, удовлетворяет большинство вызовов LIBC)?
Я для себя так и не решил.
Black_Cat
25.07.2011, 15:43
какие костыли есть в АТМ, что она не подпадает под "концепцию развития"?
Дополнительные неправославные видеорежимы? Палитра? CP/M?
http://zx.clan.su/forum/7-84-1
причем реалтайм, когда речь шла про инт?
а каким образом ты будешь грузиться с ленты НЕ в реалтайме? там тормозить нельзя, любой нми нафиг собьет синхронизацию. или как это обойти-то?может ты не понял, но мы говорили о реалтайм многозадачности для ВМ, а ты говоришь о монопольном режиме. Нет никакой необходимости пользоваться лентой в режиме реалтайм многозадачности, этот режим вообще не для старого спековского софта. Для старого спековского софта достаточно вытесняющей многозадачности с ручным переключением задач.
Что можно сделать, так это просто перевод в режим совместимости, в котором получим те же спек+костыли.пральна, зачем тебе ОС? Тебе и загрузчика хватит.
NovaStorm
25.07.2011, 16:43
С многобанковостью есть одна единственная закавыка - как обрабатывать память в другой странице, на которую передан указатель. Медленно (через копирование), или подгонять сегмент данных (чтобы гарантированно попадало в окно диспетчера, но тут надо писать свой компилятор) или как-то еще? Аналогично и со стеком (если пишем на С). Или вообще не использовать передачу указателем (чему, кстати, удовлетворяет большинство вызовов LIBC)?
Сделать RPC через прокси-функции, которые, если функции нужны данные из другой страницы, будут копировать эту функцию(можно и данные, но ф-цию наверное удобнее) в 3ю, например, страницу в кэш функций и уже оттуда её вызывать. Но для такого придётся много делать руками, тк даже если переписать так компилятор, чтобы он генерировал вызовы прокси вместо обычных, то всё равно найдётся наверное немало ситуаций, где всё это не поможет.
>http://zx.clan.su/forum/7-84-1
БК, я честно читал эту портянку и раньше. Но так и не понял чем армяне^WХимера лучше Пентэвы, ведь если в
ATM никогда не был развитием Спектрума, и поэтому превратить Спектрум в ATM можно только одним способом - полностью добавив к Спектруму весь ATM заменить АТМ на химеру, на мой взгляд ничего не изменится, да и в пентэве АТМные рудименты поотрывали, что должно было бы привести её в более соответствующий "концепции развития" вид.
А скорпэва в какую кучку? =)
Но так и не понял чем армяне^WХимера лучше Пентэвы
Тоже не догнал.
С многобанковостью есть одна единственная закавыка - как обрабатывать память в другой странице, на которую передан указатель.
У меня (применительно к пентеве и FATFS) это решается распределением банок. В нулевой банке лежит обертка(ядро программы) плюс короткий временный стек для передачи переменных, плюс драйвера накопителей(от Savelij'я) и RTC, плюс драйвер клавиатуры. Во второй и третьих банках функции/процедуры фатфс, а также в третью банку подключается GUI(от Vitamin'а), во вторую буфер GUI(для сейва скрина) и буфер списка файлов. А также первая банка юзается под запись чтение файлов. Причём стек у ГУИ и ФАТФС раздельный.
В настоящий момент мной адаптирована АртСтудия под ФАТ. Причём патч самой АртСтудии весит 60байт. ФАТФС и ГУИ висят резидентом.
А на мой взгляд, тоже, подобная виртуализация малой кровью не дастся.
вот-вот.
Вообще-то и с дисковода тоже надо успевать прочитывать регистр пока трек разматывается (хотя времени для маневра конечно несколько больше).
ну, я очень даже в курсе;) и времени там не сказать чтобы больше, почти впритык на 3.5мгц. просто это менее очевидный вариант, ибо флоп перечитает сектор через 0.2с (ха-ха, а в этот момент снова придет прерывание!).
может ты не понял, но мы говорили о реалтайм многозадачности для ВМ
может быть ты не понял, но у меня специально были разделены вопросы на 2 пункта:)
Нет никакой необходимости пользоваться лентой в режиме реалтайм многозадачности, этот режим вообще не для старого спековского софта.
т.е. есть спец режим, когда ВНЕЗАПНО спек становится нормальным спеком и все работает как и всегда, никто никого не прерывает и т.п.
полная совместимость, отлично! чем плохи остальные? все клоны могут точно так же забыть, что у них больше памяти, могут переиграть времянки и стать пентагоном и т.д.
на кой черт тогда сдались эти ВМ, если обыкновенный спековский софт в них не будет НОРМАЛЬНО работать, а? а вне нормального режима и сейчас все воротят что хотят, лишь бы софт был. думаю, можно и пентеву допилить до состояния, когда можно будет переключать задачи вручную.
и, наконец-то:
Вопрос в другом - а кому нужны все эти магнитофоны, дисководы? Равно как и софт, съедающий все такты и критичный к порче стека, и все лишь для вращения кубика и скролла с факами?
а кому это вообще все нужно-то?:))) зачем вам именно з80? зачем весь старый софт? дисководы-магнитофоны... можно сделать вообще другой, новый современный комп, перенести туда немного программок и на этом успокоиться. общего со спектрумом здесь будет очень мало (имхо).
Black_Cat
25.07.2011, 21:24
А скорпэва в какую кучку?это обычный Скорпион. Ты это разве не знал, или просто хотелось потроллить?
в пентэве АТМные рудименты поотрывалиВсё осталось - менеджер памяи, видеорежимы, иначе это не был бы АТМ. Ты это разве не знал, или просто хотелось потроллить?
я честно читал эту портянку и раньше. Но так и не понялдумаю, просто не хотел понимать, но тут я ничем помочь не могу, я могу помочь токо тем, кто имеет желание понять. Если есть желание разобраться - посмотри мои посты в том обсуждении, что скинули во флейм, там есть ответы на все вопросы. Если желания разобраться нет, а охота токо троллить - не морочь мне голову.
Black_Cat, я хочу разобраться:
т.е. есть спец режим, когда ВНЕЗАПНО спек становится нормальным спеком и все работает как и всегда, никто никого не прерывает и т.п.
полная совместимость, отлично! чем плохи остальные? все клоны могут точно так же забыть, что у них больше памяти, могут переиграть времянки и стать пентагоном и т.д.
на кой черт тогда сдались эти ВМ, если обыкновенный спековский софт в них не будет НОРМАЛЬНО работать, а? а вне нормального режима и сейчас все воротят что хотят, лишь бы софт был. думаю, можно и пентеву допилить до состояния, когда можно будет переключать задачи вручную.
мдэ...18 страниц "бла бла бла".
Там тоже диспетчер системных вызовов с номерами функций, система передачи параметров в регистрах
в юзиксе все функции и их параметры передаются через стек. собственно говоря, у FreeBSD тоже функции передаются номерами и их там примерно 500))) достаточно заглянуть в файлик syscalls.c. у юзикса ближайший подобный файл это syscalls.h в инклудах и dispatch.c в сорцах кернеля.
С многобанковостью есть одна единственная закавыка - как обрабатывать память в другой странице
ну, напрмиер, для получения каких то данных из другой страницы можно использовать системные вызовы самой оси. в качестве парааметра передать указатель на некий буфер, куда будут скопированны нужные данные. так же и для вызова дальней функции, алгоритм go_far. гдето кстати, в кудосе такое уже было... на си такое тоже сделать в целом не сложно, например, написав свою функцию и засунув её в либу или создав свою либу.
NovaStorm
26.07.2011, 08:45
это обычный Скорпион. Ты это разве не знал
Не знал, я про него только название знаю и то, что он на том же железе, что и пентэва. Потому и спрашивал.
Всё осталось - менеджер памяи, видеорежимы, иначе это не был бы АТМ.
У тебя сказано, что CP/M выбросили, вот я и подумал, что вместе с текстовым режимом.
Black_Cat
26.07.2011, 09:17
и то, что он на том же железе, что и пентэваZX Evolurion - это девборда, она как пустое ведро - можно залить и коньяк, и мочу
У тебя сказано, что CP/M выбросили, вот я и подумал, что вместе с текстовым режимом.СР/М выбросили потому, что идеология развития НедоАТМ претерпела изменения относительно идеологии развития компьютера АТМ, который был разработан именно как CP/M компьютер.
Black_Cat, я хочу разобраться:
psb, свежо предание, но верится с трудом, обычно от тебя исходит токо троллинг.
Error404
26.07.2011, 09:51
в юзиксе все функции и их параметры передаются через стек.
Вызов всех процедур ядра через диспетчер (0008h) осуществляется с передачей параметров (и результата) в регистрах. Разве нет?
И правильно, от стека в системных вызовах С надо уходить для многостраничного ПК, т.к. при вызове стек вызывающей программы останется в другой странице. В uzix 1.x все программы работали в одной и той же странице (из-за чего и медленно - их приходится постоянно отгружать в свап). Что в принципе позволяло использовать стек для вызовов ядра, но там все же используется передача данных в регистрах.
ну, напрмиер, для получения каких то данных из другой страницы можно использовать системные вызовы самой оси. в качестве парааметра передать указатель на некий буфер, куда будут скопированны нужные данные. так же и для вызова дальней функции, алгоритм go_far. гдето кстати, в кудосе такое уже было... на си такое тоже сделать в целом не сложно, например, написав свою функцию и засунув её в либу или создав свою либу.
Спасибо, кэп. (с)
Вообщето я так и делал в CP/M, правда на Орионе. И пересылки, и длинный вызов из которого можно было обычным RET возвращаться между страницами. Проблема в том, что это все медленно работает. "Длинные" CALL и RET получаются непростыми (а следовательно медленными) подпрограммами - там многое надо учитывать: автоопределение и сохранение на стеке страницы откуда вызов, определение и сохранение на стеке состояния диспетчеров памяти (т.к. вызываемая п\п может их портить и в итоге RET получится не туда куда надо), куски для обслуги прерываний - чтобы если случится прерывание, ЦПУ по прерыванию попал в нужную страницу - туда где обработчик - а не в ту, где ты ковыряешься в текущий момент. И по RETI вернулся обратно из обработчика прерывания - опять же межстранично. И т.д.
В итоге, CP/M, где у меня все вызовы BDOS/BIOS были векторизированы на межбанковских процедурах, и "прозрачная" для прерываний (http://zx.pk.ru/showpost.php?p=275608&postcount=851) (что позволяло писать драйвер любого устройства и централизованно размещать его в любой странице памяти, эмулировать "многозадачность") получилась в 2 раза более медленной, чем ее одностраничный брат. На что мне тут же указали (еще тогда, в 90-х), не помог никакой "новый сервис ОС"
я незнаю как на орионе, но относительно профи "дальние" вызовы особых проблем не имеют. конечно, есть потеря скорости, однако не критично, особенно если учесть факт наличия турбы. на профи все дрова или их большая часть сидит в 5й странице. особо не замечал каких-либо проблем или тормозов при их вызове. кроме того, дабы избежать потери данных со стека оставшегося в другой странице, никто не мешает переставить стэк в окно, которое не участвует в переключениях страниц. тем более если требуется передать какие либо короткие ответы от функции. несколько байт можно и переставить, разве нет?
а тормознутость юзикса объясняется ещё и тем, что во1х, ты посмотри на библиотечные вызова, тот же fopen, насколько он прожорлив и здоровый. printf и другие. очень много ляпов в системе и лишних условий, которые можно или сократить, упростить или развернуть. а второй юзикс, согласно переписке с автором, большей частью написана с преминением вставок ассемблера. там даже один и тот же файл (программа) занимает меньше места, чем у первого юзикса.
Вызов всех процедур libc через диспетчер (0008h) осуществляется с передачей параметров (и результата) в регистрах
к сожалению не всех.
asm(" psect text,class=CODE");
asm(" global __sys__3");
asm(" global _mount");
asm(" signat _mount,12346");
asm("_mount:");
asm(" pop hl");
asm(" ex (sp),hl");
asm(" push hl");
asm(" ld hl,19");
asm(" jp __sys__3");
...
asm("__sys__3:");
asm(" push bc"); /* the third value is already in stack */
asm(" push de");
asm(" push hl");
dosyscall();
...
#define dosyscall() asm(" call " __str1(SYSCADDR))
...
#define SYSCADDR 8 /* System call routine */
а если говорить непосредственно про библиотечные вызовы, то они диспечер то вобщем и не используют, за редким исключением когда делают вызовы типа открытия файла/потока и подобное. а вот возврат как раз в регистрах:
* System call structure:
* Arguments passed through stack: unix(#,arg1, arg2, ...)
* Result returned in DE:HL (LSB/MSB form)
* If error found then CY=1 and BC=errno
А как грамотней организовать доступ к библиотеке?
я вижу три варианта :
1.В начале либы пачка JP
2.Передавать номер функции через регистр
3.Номер функции в следующем байте после CALL
Мой тебе совет - забей с либами для ZX-a, и линкуй "руками" сразу компилируя под фиксированные адреса.
Потому-что:
1. либы сохраняют место на диске (но по факту сейчас нет проблем с нехваткой места на диске);
2. либы сохраняют место в памяти (но только если система может грузить сразу более одного приложения, по факту для классического спекки это не актуально);
3. либы могут настраиваться на адреса куда они загруженны и позволять делать всякие трюки с релокацией для управления свободной памятью (это для спекки не актуально изза того что алгоритм автоматического распределения памяти сам по себе требует кучу места для для своих кода и данных, короче для спекки он сильно жирный);
4. либы можно поставлять в бинарнике и просто использовать не парясь с компиляцией (это типа удобно но имея либу в исходнике можно ее подхачить легко что более важно!)
ну и это еще не все... это так на вскидку написал
Для большего понимания предложенной мной архитектуры проги я тут примерно интерфейс kernel-a выложу:
/* тут лежит номер текущей, включенной в адресное пространство страницы
в системных переменных басика 128 есть этот байт можно его использовать */
BYTE currenPageNumber;
/* эта функция должна: включить pageNumber, провести операцию обмена содежанием
между областями памяти address1 и address2 длинна блока lenght, включить обратно
currenPageNumber */
void swapDataBlock(BYTE pageNumber, SHORT address1, SHORT address2, SHORT lenght);
/*эта фукция для перехода на код в другой странице, включает pageNumber, обновляет
currenPageNumber, делает jp на address1*/
void jmpFar(BYTE pageNumber, SHORT address1);
/*эта функция для call-a на код в другой странице, включает pageNumber, обновляет
currenPageNumber но сохраняет старое значение у себя на стеке, делает call на address1
по возврату ставит старое значение pageNumber и делает ret*/
void callFar(BYTE pageNumber, SHORT address1);
/*это обработчик int-a, запрещает прерывания, включает нужную сраницу где находится код обработки прерывания но сохраняет старое значение на стеке, вызывает обработчик, после возврата высталяет старый pageNumber разрешает прерывания делает reti*/
void intHandler();
Мой тебе совет - забей с либами для ZX-a, и линкуй "руками" сразу компилируя под фиксированные адреса.
Не получится, либа Сишная, прога на асме. У меня щас примерно так и сделано, под фиксированные адреса, но чуть Си код подправишь и надо EQU'шки в проге обновлять. Не очень интересно.
А я бы обёрточку асмовскою в Си код вставил и ноу проблем. Перемещаемый код мне не нужен. Тока пока немогу определится как будет удобней к ней обращатся.
Аргументы через стек передаю. Либу пока цепляю во 2-3 банки, но скорей всего скомпилю в 0-1, потому что уже некоторые неудобства ощущаются с предачей аргументов. Дальше хуже скорей всего будет.
С многобанковостью есть одна единственная закавыка - как обрабатывать память в другой странице, на которую передан указатель. Медленно (через копирование), или подгонять сегмент данных (чтобы гарантированно попадало в окно диспетчера, но тут надо писать свой компилятор) или как-то еще?
ld a,(hl)
inc l
call z,sys_readblock
ld (de),a
inc e
call z,sys_writeblock
См. ZXUnRar.
При этом в нижней памяти будет лежать только 256 байт данных от каждого файла/пайпа/массива, обновляются через LDIR, что сравнительно быстро.
ld a,(hl)
inc l
call z,sys_readblock
ld (de),a
inc e
call z,sys_writeblock
См. ZXUnRar.
При этом в нижней памяти будет лежать только 256 байт данных от каждого файла/пайпа/массива, обновляются через LDIR, что сравнительно быстро.
alone, я конечно дико извеняюсь но вообще можешь по проще объяснить чтоб даже я понял (и тем более ААА), ато у Вас у гуру типа тебя и Роб.Ф-а вообще "марсианский" язык какой-то. Мне вот интересно друг друга вы понимаете? Прикольно было бы попросить Роб.Ф-а чтоб он это расшифровал...
Что конкретно непонятно?
куда указывают hl и de вначале? что собой представляет часть софта которая имеет в себе вызываемые функции? что ожидалось в результате выполнения этого куска? и самое главное как это решает концептуальную проблему - "работа с данными в странице которая не подключенна в адресное пространство" ?
я бы предположил: hl=адрес буфера откуда копировать, de=адрес буфера куда копировать, оба буфера вне страницы. sys_readblock заполняет source-буфер новыми данными, когда они кончатся, sys_writeblock - сохраняет destination-буфер, когда он заполнится. т.о., подобным методом можно сильно экономить время на переключении банков.
NovaStorm
01.08.2011, 11:43
>обновляются через LDIR
Да можно и не мелочиться, а передавать буфер параметром через стек, тут это вполне себе легитимно =)
буфер, да еще и известного размера - конечно можно. а тот код был, в основном, для файлов/пайпов.
С многобанковостью есть одна единственная закавыка - как обрабатывать память в другой странице, на которую передан указатель.
Просто взять и подключить требуемую стр. в первую банку(#4000) допустим. Указатель трех байтовый должен быть, байт на стр. и два на смещение.
И под глобальные переменные,аргументы и под глобальный стек использовать только одно адресное пространство для всех прог, те же #4000-#7FFF(Я так и делаю впрочем).
Но такой фокус прокатит на малом количестве клонов(АТМ, пентева и т.п. "спектрум-несовместимые").
---------- Post added at 12:24 ---------- Previous post was at 12:12 ----------
Одна(как минимум) пейджа потребуется для таблицы текущих загруженных библиотек, но это уже фундаментальная философия.
---------- Post added at 12:32 ---------- Previous post was at 12:24 ----------
Вызов всех процедур libc через диспетчер (0008h) осуществляется с передачей параметров (и результата) в регистрах
Насчёт регистров очень не согласен, в некоторых случаях может не хватить. Лучше использовать стек. Один фиг часть аргументов, при попадании в функцию, тут же сохраняются на стеке. В регистрах можно передавать номер либы и номер функции в ней. Результат, согласен, однозначно в HL (HLDE если DWORD).
Error404
01.08.2011, 15:50
ld a,(hl)
inc l
call z,sys_readblock
ld (de),a
inc e
call z,sys_writeblock
См. ZXUnRar.
При этом в нижней памяти будет лежать только 256 байт данных от каждого файла/пайпа/массива, обновляются через LDIR, что сравнительно быстро.
Это все понятно. Так я и делаю в Орионе, с учетом различий в расположении и размере некоммутируемых областей (и очевидно - это решение только для ASM). Итог, как и писано парой постов выше, при интенсивном IO имеем замедление в 1,5-2 раза в сравнении с ограниченной по памяти классической 64к-шной моделью. Тут наверное просто надо подойти философски, и заведомо отсечь в игнор выкрики с мест типа "вот! у вас медленно! а мы говорили!", которые совершенно очевидно последуют позже.
---------- Post added at 15:50 ---------- Previous post was at 15:40 ----------
Насчёт регистров очень не согласен, в некоторых случаях может не хватить. Лучше использовать стек. Один фиг часть аргументов, при попадании в функцию, тут же сохраняются на стеке. В регистрах можно передавать номер либы и номер функции в ней. Результат, согласен, однозначно в HL (HLDE если DWORD).
Большое количество параметров процедур чаще всего говорит о неструктурированности кода. Если есть нужда, можно использовать структуры и указатель на них. Т.е. опять мы возвращаемся к "а что делать с указателем на страницу, которая не дай т.н. б-г не включена в 64к адресного пространства", или "а как быть если С-стек или куча после переключения диспетчера остались в страничке, не включенной в 64к адресного пространства" и подобными.
Я вижу решение в разделении кода на модули, сокращении передаваемых между ними параметров и передаче их в регистрах, а при необходимости (когда надо обрабатывать указатели на struct, array) - таки да, межстраничные пересылки во временный буфер (а если надо, то и обратно). Таких мест не будет много, КМК.
Если есть нужда, можно использовать структуры и указатель на них.:v2_conf2:
Интересное замечание. Надо попробовать использовать в своём коде.
По сути достаточно одного аргумента с указателем на переменные.
"а что делать с указателем на страницу, которая не дай т.н. б-г не включена в 64к адресного пространства", или "а как быть если С-стек или куча после переключения диспетчера остались в страничке, не включенной в 64к адресного пространства" и подобными.
под глобальные переменные,аргументы и под глобальный стек использовать только одно адресное пространство для всех прог, те же #4000-#7FFF(Я так и делаю впрочем).В приказном порядке.
Splinter
28.11.2011, 22:32
Прочитал немного, смотрю оживление и сдвиги, но наткнулся на срачь ))), промотал. К чему пришли опорные стандарты машин для ОС всё же ? Было множество предложений, из которых, как мне показалось нужно учесть максимум ).
128 к например 1е ядро кода... Самое нижнее, минималочка... Держит именно одно окно, и именно со стеком в нижней памяти (именно как прозвучало где то на 16й странице). Главная задача (цель поддержки) - успешный запуск образов хранимых на винте. И манипуляции ими. Пусть будет некоторая медлительность, минимум функций, но по сравнению с тапе лодером это ничто ))). Почему то мне кажется, что и запуск с винтов виртуальных TRD будет не намного медленнее, чем с реальных дискет. Даже пусть в 2 раза, это приемлимо. Однако, что важно - пользователи разных пентагонов 128, которых однако немало, и других клонов 128, имея минимальную память СМОГУТ юзать ось, если подключат винт и сменят пзу.
Под более серьезные машины Ось ПРИ УСТАНОВКЕ ) определит карту памяти под конфигурацию с несколькими фреймами (профи, атмки и более новые атм2, пентева) Возможности машины, в частности обьем памяти и скорость сохранения - чтения данных (ведь именно это будет слабым местом оси+128к) возрастут, откроется платформа для написания серьезных приложений, которые не пойдут на 128к возможно, но на пц тоже есть минимальные требования у софта и это нормально.
Расширения и назначения - придерживаюсь всё того же мнения. trd - это 640к образ, который может запускаться как exe, tap это ленточный образ, который тоже может запускаться как exe, в обоих случаях после сброса (физического) нам нужно возвращаться в ось в то же самое состояние откуда мы ушли. Мы нажав так сказать "Закрыли" приложение и продолжаем работу. exe сделать запускаемым файлом в асме со строго регламентированым адресом начала. (естественно выгружаем предварительно ось из памяти в область на винте что бы подготовить к возврату после сброса). И главное - эти приложухи могут юзать абсолютно всё и иметь собственную длинну хоть 200 метров. Но следует жёстко ограничить допуск приложению к областям винта вне области тела приложения. Как это сделать я пока не додумался (((...
Не стоит забывать про виртуальную память, которую необходимо просто (особенно потребуется 128к машинам) регламентировать на винте и использовать и приложениями и осью...)))))))
NovaStorm
29.11.2011, 08:21
>>Не стоит забывать про виртуальную память
Не стоит также путать виртуальную память и подкачку. Если с подкачкой при переключении страниц всё ок, то с остальными плюшками совсем грусть, MMU то полноценного нету.
Если с подкачкой при переключении страниц всё ок
Не всё ок. При подкачке нельзя пользоваться физическими номерами страниц (типа запросил страницу, и тебе дали номер). То есть при каждом обращении к диспетчеру страниц будет ацкий пересчёт по таблице, тактов на 200, а то и 300.
имхо, 200-300 тактов для ос - это вполне нормально. просто нужно на это рассчитывать и проги писать соответственно, уж не копировать 1 байт на 1 переключение странички. да и, так-то, убыстрить можно таблицами, на сколько это вообще возможно.
Splinter
02.10.2012, 15:06
Тема умерла ? Так и не будет видать оси на ZX...
Тема умерла ? Так и не будет видать оси на ZX...
doors/aqua, tasis и ос pinkfloyd же
щас придет Vadim и скажет, что это не оси:)
Прочитав первую и последнюю страницу этой темы, почему-то сразу появляется уверенность, что вся средина излишня :)
Я паридумал название новой ОС для PentEvo - PenDOS :)
research
28.08.2013, 12:01
Будет ось, если я сетевуху доделаю :) без сети она нафиг не нужна, т.к. не решает задач, которые не решены в толковых бутах.
без сети она нафиг не нужна
да и с сетью не нужна тогда.
research
28.08.2013, 12:53
ну почему, свежие картинки качать с фтп
research
28.08.2013, 14:25
и стоит дешевле. но хобби, есть хобби, а ПВЦ есть ПВЦ.
Powered by vBulletin® Version 4.2.5 Copyright © 2026 vBulletin Solutions, Inc. All rights reserved. Перевод: zCarot