Ну, скажем так, я же не зря упомянул, что у меня были большие жизненные трудности - у меня на протяжении ряда дет не было возможности регулярно занимться спектрумом, в т.ч. на эмуляторе. Пользоваться-то эмулятором я мог. Но для программирования нужно системное вникание в задачу, изучение материалов, выделение личного времени. Всего этого не хватало. Зайди ко мне на сайт АТМ, посчитай, сколько обновлений в ленте приходится на каждый год. Если в начале нулевых это было 2-3 десятка обновлений в год, то с конца нулевых 0-2. И только в последние годы пошел рост. Это все из-за этого. Я не из тех, которым просто в какой-то момент надоел спектрум, и я вернулся только потом на волне ностальгии. Я со спектрума никогда не уходил. Просто не мог системно им заниматься.Сообщение от Sayman
Ну а эмулятор как раз в этом плане очень пригодился, особенно при отлове багов.
Не весь, но 90% кода пишу на реальном спектруме. Если надо, для этого привожу синтаксис исходников из других асмов в читаемый вид на iS-ASM (например, последний требует для мнемоник и регистров только большие буквы). Программирование на реальной машине доставляет непередаваемое удовольствие. )) К тому же я за годы выстроил для себя удобную среду.
И, кстати, в то время у меня под рукой не было исходников драйверов и ряда иных "железозависимых" утилит, которые надо было переделать. При большом желании их можно было раздобыть у автора ядра TASiS Юрия Корсунина (который тоже из-за своих жизненных обстоятельств в конце нулевых "выпал" из обоймы), но опять-таки - надо было бы из изучать, приводить в удобный для меня видд и т.д. Ну не мог я. А вот сейчас смог, раздобыл, и не торопясь, с апреля довел до определенного результата.
В предложении есть резон. На самом деле в двух дистрибутивах сейчас ОДНО И ТО ЖЕ ЯДРО (так что переключаться между ядрами не надо - надо только просто подгружать разные драйвера - а это можно делать разными BAT-никами), без изменений. Причем именно на флопе. Разница - в наборе утилит - ведь система это не только ядро, а все в совокупности - весь единый комплекс со всеми взаимоувязанными внешними программами и драйверами. Иногда при неизменности самой системы ее возможности можно существенно расширить именно за счет "обвязки". Ядро не изменялось долгие годы (вот только сейчас в него вмешаемся для поддержки портов под 4Мб) - а вот софт развивался.Поэтому и новый дистрибутив. но и дистрибутив отличается только набором драйверов, которые подгружаются в ядро только в процессе инсталляции с флопа, плюс некоторыми программами в дистрибутиве (автозагрузчик с винта - он по своей сути "внесистемный", так как записывается в начальные сектора винта и стартует тогда, когда системы еще нет, настройщики драйверов, которые настраивают драйвера до их загрузки в ядро - т.е. пока они лежат на диске, в виде файлов - т.е. настройщику драйвера винта не нужен установленный в систему драйвер винта, достаточно того, что этот файл лежит "перед ним" - настройщик содержит драйвер "сам в себе", а поэтому железозависим - я переработал исходники дров и подобных утилит под АТМ и сделал их автоматическую компиляцию через BAT-ник по IFам - сразу компилируются дрова под Evo и ATM. Или, например, в дистрибутиве под ZX-Evo есть утилиты работы с CMOS, которых нет в АТМ, так как там нет самого CMOS на плате). В принципе, можно на одной дискете разместить обе версии таких дров и настройщиков на одной дискете, и просто при старте выбирать инсталляцию - под ATM или ZX-Evo. Хорошее предложение. Как накопятся изменения, наверное перевыпущу универсальный дистрибутив.
По задачам - предположение не лишенное оснований. А вот по самой сущности фрагментирования как раз кроется большое недопонимание того, что в данном случае имеется ввиду.
Так вот, когда речь в описании рестартов (да, я в той части дискуссии, что сейчас во флейме, видел разговоры, что "рестарты" - это не "рестарты", а правильней говорить системные функции и вызовы. Согласен. Просто я так привык и пишу на автомате. Просьба не акцентировать внимание, ибо главное - суть) идет об учете фрагментированности файлов, речь вовсе не идет о том, чтобы заставить ПО спускаться на секторный уровень и подсчитывать число фрагментов файла (это действительно было бы нарушением принципа абстрагирования). Ибо согласен целиком и полностью с этим:
Речь идет не о реальном физическом фрагментировании по факту, а о специальном бите в файле атрибутов в описателе файлов.
Ну вот для сравнения в том же MS-DOS в 32-байтном описателе есть байт атрибутов, где каждый бит что-то значит - например, можно объявить файл скрытым, защищенным (от удаления), системным и т.д. Тоже самое и в ФС iS-DOS, только там есть и бит "фрагментированности". Что это такое? поясню на примере с битом защищенности от удаления:
Если этот бит установлен, хоть в MS-DOS, хоть в iS-DOS, то если ПО обратится через штатные функции системы с командой удалить файл, то эти вызовы (в iS-DOS - $erfil (#24) и $erf_(#3C), то функция откажется удалять файл, выдав на выходе флаг и номер ошибки. Другими словами, поднятый в описателе файла бит защищенности отзначает ЗАПРЕТ НА УДАЛЕНИЕ файла.
Тоже самое (с определенным дополнением, о котором отдельно) с битом "сегментированности". Для наглядности, как с удалением файла. Представь, что на совершенно чистую, только отформатированную дискету, хоть в исдосе, хоть в мсдосе записали файл. Так как дискета чистая, никакие файлы, занимая в произвольных местах часть диска, не мешают, запись файла произведена последовательно, и что там, что там представляет собой один сплошной блок данных. Но это, так сказать "техническая несегментированность". потому что просто "вот так получилось". А в последствии все может измениться - если это текстовый файл, то текстовый редактор может добавить что-то там в середину. Или затем при дефрагментации диска программа по кускам перенесет файл для закрытия "дырок" - мало ли что. Так вот, если указанный бит "сегментированности" поднят в байте атрибутов описателя, то это, как и в случае с битом защищенности от удаления означает просто ЗАЩИТУ ОТ СЕГМЕНТИРОВАНИЯ, только и всего - как и в случае с попыткой удаления, при вызове определенных системных функций они откажутся "разбивать" файл на куски (например, добавляя фрагмент в середину), и выйдут со штатным сообщением об ошибке с соответствуюшим номером. Т.е. если мы возьмем ранее рассмотренный непрерывно скопированный файл, где такой бит не установлен, то от для системы будет не непрерывным, а (временно) "односегментным", и с ним можно делать потенциально, что угодно. А если этот бит установить (например, через утилиту переименования - там есть функция работы с рядом служебных байт описателя), то он станет "непрерывным", и тогда его можно будет только последовательно читать или сокращать (добавление длины также считается созданием дополнительного сегмента). При этом если "односегментный" файл уже не "односегментный", а разбит на куски, идущие не подряд, то система не даст этот бит установить штатными средствами. Для этого файл надо сначала привести в "последовательный вид" - например скопировать куда-нибудь на свободное место. Он скопируется последовательно, и его можно сделать непрерывным черех прикладную утилиту, поменяв бит атрибута.
Где это может пригодиться. Бывают случаи, когда надо защитить файлы от случайного сегментирования. Например: те же файлы ядра системы для автозагрузчика (is-dos.rom и is-dos.sys). При создании автозагрузочной записи хоть на винте, хоть на флопе, хоть еще где, в автозагрузчик просто прописывается копия 32-байтного описателя файла, в котором, само собой, есть указатель "физических" (в рамках логического раздела, координаты которого тоже прописываются в загрузчик) координат, с которого он начинается и дина файла. Загрузчик, который грузится процедурами ПЗУ, когда еще нет никакой системы вокруг - длиной несколько сотен байт. Ему надо вместиться в ограниченный объем одного загрузочного сектора и, само собой, нет места для работы с файловой системы, анализа, сколько там сегментов и как они расположены. он тупо берет координаты начала файла и его длину и грузит в нужное место ПОСЛЕДОВАТЕЛЬНО. Если файл будет разбит на куски в результате каких-то перемещений на диске - то система не загрузится из-за нарушения данных и все.
Далее ддля понимания того, почему и как нужны непрерывные и сегментированные файлы, опустимся до нижнего уровня ФС - координат расположения файлов:
Еще очень важно: если в FAT12/16/32 карта диска представляет собой множество 12\16\32-битных "описателей" блоков, которые принимают либо значение, означающее "блок свободен", "блок занят", "бэд-блок" или "следующий блок файла в цепочке чтения", то в исдосе карта диска исключительно однобитная, и указатель на блок может означать только одно - "блок свободен" или "блок занят. Больше ничего не получится. И если в мсдосе фрагментированность файла вычисляется системой (не ПО) анализом цепочки - идут ли описатели подряд или нет, то в iSFS по другому:
Если файл битом сегментированности объявлен непрерывным, то помимо запрета на сегментированность координаты в описателе реально указывают на начало файла. И можно, далее последовательно его читать. если бит запрета на сегментирование сброшен, то даже если файл реально и не разбит на куски, к нему перед началом (условно - т.е. не физически в предшествующий сектор, а логически) "пришивается" один логический блок(256 байт), который содержит карту количества сегментов и их последовательное расположение на диске. А именно, из 256 байт этого блока первый будет означать количество сегментов (кусков) на который разбит файл, а также трехбайтные описатели каждого из таких кусков (до 85 таких кусков в итоге - ибо 1 байт количества + 85 описателей*3 = 256). Эти три байта в каждом описателей означают - 1 байт количества непрерывно идущих блоков в одном сегменте (т.е. от 1 до 255), а два других - координаты начала этого сегмента на диске (номер логического блока). Если файл не непрерывный, а "односегментный", то такой вот "пришитый блок с картой сегментирования" будет содержать в себе первый байт =1 (пока есть только один сегмент), и только одну тройку описателя сегмента. Ну а 32-байтный описатель такого "сегментированного" файла будет указывать координаты не начала самого тела файла, а координаты этого блока с картой сегментирования. И в зависимости от значения бита сегментированности система на уровне вызовов, "прозрачно" для прикладного ПО или видит, что файл непрерывный и последовательно с ним работает (например, читает), или считывает эту кату в буфер и читает куски исходя из ее анализа.
Я так понимаю, эту систему файлов авторы придумали для экономии времени и места для работы системы в минимальной конфигурации. Ибо та же карта флоппи-диска в логических блоках о 256 байт (они в отличие от мсдос - всегда только по 256 байт) размером в 800Кб (3200 блоков) займет только 400 байт, а полный размер раздела в 16Мб на винте - 65520 блоков - 8Кб. Плюс в таком случае установка в файлах атрибутов запрета на сегментированность позволяет экономить место - если файл объявляется непрерывным, то 256-байтный блок с картой удаляется и в описателе файла ставится указатель на реальное начало файла. Т.е. в битовой карте диска появляется один свободный блок. А если таких файлов на диске 100, то 100 блоков по 256 байт - это уже 25Кб - если на винте это несущественно, то на флопе - очень даже. Поэтому все короткие файлы вполне можно объявить непрерывными (если файл и так длиной в несколько секторов, то куда его еще сегментировать?) как непрерывными и подкаталоги, куда не предполагается добавлять новые файлы. Например, если мы создаем под завязку (до последнего сектора) заполненный "системный" диск и хотим вместить туда как можно больше файлов, можно все сделать непрерывным, и сэкономятся десятки килобайт. Плюс - скорость - если системные вызовы, работающие с файлами (прежде всего - чтение файла), видят бит, запрета на сегментированность, они не считывают для анализа битовую карту расположения сегментов для анализа, а сразу начинают грузить последовательно файл - в итоге пропускается куча операций, плюс головка флопа меньше ездит по диску (на винте это незаметно, а в былые времена на флопе было очень даже видна разница).
ну а теперь вернемся обратно на уровень файлов и прикладного ПО. Все, что описано выше - это "потроха" системных вызовов, "внутренняя кухня", идущая вне "глаз" программы пользователя (если пользователь преднамеренно не захочет посмотреть, а что там в этой карте сегментов и не достанет ее, например, через вызовы низовой работы с отдельными блоками - ну например, это может понадобиться диск-доктору для посекторной работы, HEX_редактору, дефрагментатору и проч. - но это специализированные программы, идущие на уровень ниже файловой системы). С точки зрения прикладного ПО есть лишь атрибут файла "разрешение/запрещение фрагментирования", как и атрибут "разрешение/запрещение удаления", при попытке выполнить действия, которые они запрещают, он просто словит ошибку "номер такая-то". Где и как располагаются и фрагментированы или нет файлы прикладному ПО совершенно неважно, ибо "абстрагирование от железа и низовых функций".
Про сущность т.н. "RAM-диска" (беру в кавычки)) я подробнее напишу в следующий раз, если нужно (тогда напиши), если того, что ниже будет недостаточно и потребуются подробности (например, структура КЭШа, как система обрабатывает блоки и проч.). Вкратце - там примерно такое же недопонимание того, что на самом деле имеется ввиду, путаница с понятиями. Потому что во-первых не RAM-диск (который может быть только при инсталляции соответствующего драйвера, и ничем с точки зрения не отличается от флопа и винта, кроме того, что физически располагается не на дискете, а в ОЗУ), а т.н. "электронный диск"(вот так в мануалах его иногда называют, но никак не RAM-диск) или "КЭШ блочных устройств"(что тоже пишут в мануалах и это совсем правильно) - область ядра, размер которого может регулироваться пользователем и прикладным ПО, предназначенный для кэширования операций ввода-вывода с блочных устройств (в том числе и с реального RAM-диска, если его драйвер будет установлен). Позволяет уменьшить при повторяющихся операциях чтения/записи данных количество обращений к диску, что особенно заметно при работе с флопом - чем больше область КЭШа (юзер сам может ее установить, как, например, в винде при разбиении винта или даже в ОЗУ на разделы тоже есть возможность выделить область для кэширования данных), тем реше дергается головка. Размер КЭШа может регулировать как юзер по командам, набрав из командной строки вызов настройщика или прописав его его в autoexec.bat. Тоже самое может делать прикладное ПО - если нужно, увеличит временно КЭШ, если не хватает памяти под ядром - уменьшит временно его (системные вызовы позволяют узнать и запомнить его текущий размер и изменить как угодно в рамках разумного диапазона). И все. Что там происходит в КЭШе, прикладному ПО "до лампочки", ибо абстрагирование от системы. Есть лишь одна рекомендация - если производилась запись на диск через КЭШ, на всякий случай перед выходом из программы сделать "автофлаш" для принудительного сохранения блоков из КЭШа "на своим места" на диске - на тот случай, если автоматически система это еще не сделала как подстраховка. Выяснять, что и как там в КЭШе находится не надо. Просто обращение к системному вызову "на всякий случай".
is-dos.rom - т.н. "неизменяемая" часть ядра - она сидит в ОЗУ вместо ПЗУ по адресу #0000 ниже стартовых адресов ПО (в обычном исдосе эти стартовые позиции начинаются выше экрана, а в TASiS прямо с #4000) и "кушать не просит" - она содержит основную библиотеку процедур, которые меняться не должны. А вот второй файл - is_dos.sys - это как раз "динамическая часть", это дамп всего "верхнего ядра", размер которой зависит от настроек - т.е. сколько и каких установлено драйверов и резидентов, какой установлен размер каналов и того же самого упомянутого КЭШа. Это ядро растет сверху (с адреса #FFFF) вниз, и чем больше всего к ней дров и резидентов присоединяешь, сколько в ней присоединишь уровней (их может быть максимум 8. Сейчас их 5 - от 0 до 4, начиная от уровня низовых операций с дровами, железом в самом верху, и до уровня с оболочкой ниже всего (еще ниже идут подсоединяемые дрова, резиденты, каналы и КЭШ). Уровни тоже в определенном порядке можно снимать (в т.ч. и уровень с оболочкой - но это отдельная тема) и присоединять, в т.ч. своей разработки). Также тм расположены области переменных системы (в каждом уровне по своему блоку), которые можно менять прикладному ПО, указатели на начало подпрограмм вызовов системы (котоыре тоже можно менять, например дровам, если надо переключить какую-то функцию системы на себя). Так что сколько дров навесишь, столько весить и будет. Этот файл как "дамп ядра" создается специальной утилитой-сохранялкой - по сути, она сохраняет систему со всеми сделанными юзером настройками. Когда система устанавливается, загружается этот дамп уже со всеми дровами. Можно удалить какие-то дрова и пересохранить ядро, и тогда оно уменьшится в объеме. А можно сразу записать на диск ядро с минимальной загрузкой (т.е. только с самыми необходимыми дровами - например флопа, вывода символов и клавы), и тогда оно будет совсем маленьким, а дрова навешивать уже в процессе загрузки, например, прописав их "навешивание" в autoexec.bat.
Так что в среднем размер такого файла ядра колеблется в размере от 8 до 13 Кб, ни верхний предел размеров ограниыен только размером основного поля памяти.
Такое деление на "нижнюю неизменяемую" и "верхнюю динамическую" части ядра характерен именно для версии iS-DOS Chic (подвидом именно которой является TASiS), которая была доработана из обычной "Classic-системы" под машины, умеющие отключать ПЗУ. В Classic, рассчитанной на обычные машины с 48Кб-непрерывным полем ОЗУ и ПЗУ внизу, все ядро располагалось сверху и было динамическим. Занимало больше 20КбЮ оставляя для прикладного ПО не так уж много места. Соответственно в ядре все функции последовательно располагались по уровням и полностью. А с разработкой Chic от функций остались только системные переменные, максимум несколько вводных процедур, а затем - JP/CALL в нулевые адреса неизменяемой памяти. В итоге ядро вверху уменьшилось существенно, и 95% прикладного ПО по факту не заметив, что ядро переработано, просто получило в 2 с копейками раза больше свободного пространства "User-Space" - так как нижнюю границу ядра прикладное ПО получает посредством запроса системы через ее вызовы, которые возвращают по запросу эти данные программе, то просто эти данные давали гораздо больше места для ПО - то, что ядро другое, что "внизу" вместо ПУЗ что-то есть для абсолютного большинства программ до лампочки, ибо "абстрагирование от железа" (именно поэтому возможен, в принципе, при переписывании частей ядра, отвечающих за порты и проч.) перенос системы на тот же MSX и Спринтер.
Ядром (именно ядром) занимался не я. Это делал другой человек. И да, что-то он декомпилировал, потому ему какие-то исходники удалось раздобыть. Но пока их держит при себе и не хочет неконтролируемо пускать. Тем более, что это не полная декомпиляция системы. Там не так уж много надо было менять - в основном менять константы ширины окон панелей, низовые процедуры "рисования рамок окон на экране" (заменить оные на работу с текстовой консолью), заменить драйвер вывода символов на вывод их на текстовый экран. И уже впоследствии добавлено было несколько новых вызовов по работе с палитрой АТМ как с атрибутом системы и страничный менеджер. Т.е. глобальной переделки ядра не было. По факту - было несколько заплаток в неизменяемой и динамичной части ядра.
Само ядро (именно ядро) развивать в этом виде за одним исключением не надо. исключение - готовая по сути доработка, позволяющая помимо существующей "неизменяемой" библиотеки по нулевым адресам подсоединять и другие "пользовательские" библиотеки, расширяющие известные функции и вводящие свои. Это версия TASiS v6.00 (текущая опубликованная - 5.41) - вот написание таких библиотек расширения (без изменения базовой системы) - было бы интересно в будущем.
Конечно TASiS бесплатная система. Делать ее свободной - это надо согласовывать с автором. Скорее всего будет так:
Пока "версию 6" я не публиковал, ибо идет "доводка до ума" - это будет последняя доработка собственно ядра, а дальше можно и на гитхам разработчикам. Само ядро будет неизменным как "база" и гарантия от "расползания стандартов". А вот написание подключаемых библиотек расширений - это уже интереснейшая и занятнейшая вещь - к ней было бы неплохо подключить разрабов.
Ну и просто написание прикладного ПО. В принципе, для последнего уже сейчас можно что-то подобное сделать. Только я этим никогда не занимался. Вот, при условии, что нет (у меня действительно нет) полных исходников системы и задача кардинальной переработки ядра ПОКА(!) не стоит, что и как надо размещать на гитхабе, чтобы заинтересовать людей и привлечь к работе на прикладным ПО? Потому что у меня есть задачи и предложения насчет проектов. У кого есть опыт создания таких репозиториев, помогите.
Разве что набор исходников драйверов разных типов и мануалы о том, что это, какова стандартная структура драйверов и резидентных файлов и проч.
Конечно. В свое время "Искра-Софт" даже продавала исходники отдельных утилит, какие-то просто прилагала к дистрибутиву ассемблера (и часть тех и тех исходников удалось и до сих пор удается раздобывать). Но каких-то исходников у них просто не было, так как какие-то программы просто им присылали для включения в дистрибутив без исходников сторонние авторы, которых уже не найдешь и т.д. Но сама по себе работа в этом направлении интересная.
Ответить с цитированием
Размещение рекламы на форуме способствует его дальнейшему развитию 
