Важная информация

User Tag List

Страница 4 из 4 ПерваяПервая 1234
Показано с 31 по 40 из 40

Тема: TASiS - iSDOS под текстовый экран.

  1. #31
    Moderator Аватар для Максагор
    Регистрация
    16.01.2005
    Адрес
    Москва
    Сообщений
    1,712
    Спасибо Благодарностей отдано 
    21
    Спасибо Благодарностей получено 
    59
    Поблагодарили
    22 сообщений
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)

    По умолчанию

    Цитата Сообщение от Sayman Посмотреть сообщение
    в общем и целом понятно. кроме момента с железной zxevo - уже несколько лет как существует рабочая версия UnrealSpeccy в котором весьма достоверно реализована эмуляция бейзконфы. в часности, текстмод, ИДЕ, память. Т.е. дожидаться железки было не обязательно и накидать (на вентилятор) минималку для включения поддержки эво, предположительно можно было.
    Ну, скажем так, я же не зря упомянул, что у меня были большие жизненные трудности - у меня на протяжении ряда дет не было возможности регулярно занимться спектрумом, в т.ч. на эмуляторе. Пользоваться-то эмулятором я мог. Но для программирования нужно системное вникание в задачу, изучение материалов, выделение личного времени. Всего этого не хватало. Зайди ко мне на сайт АТМ, посчитай, сколько обновлений в ленте приходится на каждый год. Если в начале нулевых это было 2-3 десятка обновлений в год, то с конца нулевых 0-2. И только в последние годы пошел рост. Это все из-за этого. Я не из тех, которым просто в какой-то момент надоел спектрум, и я вернулся только потом на волне ностальгии. Я со спектрума никогда не уходил. Просто не мог системно им заниматься.
    Ну а эмулятор как раз в этом плане очень пригодился, особенно при отлове багов.

    Цитата Сообщение от Sayman Посмотреть сообщение
    ты же не хочешь сказать, что весь код пишешь на реале и прям в Тазисе (в is-asm`е)?
    Не весь, но 90% кода пишу на реальном спектруме. Если надо, для этого привожу синтаксис исходников из других асмов в читаемый вид на iS-ASM (например, последний требует для мнемоник и регистров только большие буквы). Программирование на реальной машине доставляет непередаваемое удовольствие. )) К тому же я за годы выстроил для себя удобную среду.

    И, кстати, в то время у меня под рукой не было исходников драйверов и ряда иных "железозависимых" утилит, которые надо было переделать. При большом желании их можно было раздобыть у автора ядра TASiS Юрия Корсунина (который тоже из-за своих жизненных обстоятельств в конце нулевых "выпал" из обоймы), но опять-таки - надо было бы из изучать, приводить в удобный для меня видд и т.д. Ну не мог я. А вот сейчас смог, раздобыл, и не торопясь, с апреля довел до определенного результата.

    Цитата Сообщение от Sayman Посмотреть сообщение
    Для чего выводить в отдельный дистрибутив версии для атм и эво? в целом, в рамках одного дистриба можно решать задачу по переключению между ядрами для атм и эвы. опять-таки - драйвера... экран, память, ещё что-то. при грамотном подходе будет компактно и быстродействие не пострадает. Я не говорю про случаи, когда требуется именно напрямую работать с аппаратурой (ну там, игры, демки). в рамках консольных утилит хватало бы с головой!
    В предложении есть резон. На самом деле в двух дистрибутивах сейчас ОДНО И ТО ЖЕ ЯДРО (так что переключаться между ядрами не надо - надо только просто подгружать разные драйвера - а это можно делать разными BAT-никами), без изменений. Причем именно на флопе. Разница - в наборе утилит - ведь система это не только ядро, а все в совокупности - весь единый комплекс со всеми взаимоувязанными внешними программами и драйверами. Иногда при неизменности самой системы ее возможности можно существенно расширить именно за счет "обвязки". Ядро не изменялось долгие годы (вот только сейчас в него вмешаемся для поддержки портов под 4Мб) - а вот софт развивался.Поэтому и новый дистрибутив. но и дистрибутив отличается только набором драйверов, которые подгружаются в ядро только в процессе инсталляции с флопа, плюс некоторыми программами в дистрибутиве (автозагрузчик с винта - он по своей сути "внесистемный", так как записывается в начальные сектора винта и стартует тогда, когда системы еще нет, настройщики драйверов, которые настраивают драйвера до их загрузки в ядро - т.е. пока они лежат на диске, в виде файлов - т.е. настройщику драйвера винта не нужен установленный в систему драйвер винта, достаточно того, что этот файл лежит "перед ним" - настройщик содержит драйвер "сам в себе", а поэтому железозависим - я переработал исходники дров и подобных утилит под АТМ и сделал их автоматическую компиляцию через BAT-ник по IFам - сразу компилируются дрова под Evo и ATM. Или, например, в дистрибутиве под ZX-Evo есть утилиты работы с CMOS, которых нет в АТМ, так как там нет самого CMOS на плате). В принципе, можно на одной дискете разместить обе версии таких дров и настройщиков на одной дискете, и просто при старте выбирать инсталляцию - под ATM или ZX-Evo. Хорошее предложение. Как накопятся изменения, наверное перевыпущу универсальный дистрибутив.

    Цитата Сообщение от Sayman Посмотреть сообщение
    Что касается фрагментированных файлов - я смог придумтаь только одну причину по которой фрагментированные файлы выделены в отдельную сущность - это попытка производить запись данных между уже записанных данных. т.е. грубо говоря - "раздвигать" данные файла в стороны. но эта задача настолько не каждодневная и в целом не существенная, что тратить ресурсы машины на акцентирование каких-то рестартов на это, с моей точки зрение кощунство. Это решить можно банальной сторонней утилитой.
    По задачам - предположение не лишенное оснований. А вот по самой сущности фрагментирования как раз кроется большое недопонимание того, что в данном случае имеется ввиду.

    Так вот, когда речь в описании рестартов (да, я в той части дискуссии, что сейчас во флейме, видел разговоры, что "рестарты" - это не "рестарты", а правильней говорить системные функции и вызовы. Согласен. Просто я так привык и пишу на автомате. Просьба не акцентировать внимание, ибо главное - суть) идет об учете фрагментированности файлов, речь вовсе не идет о том, чтобы заставить ПО спускаться на секторный уровень и подсчитывать число фрагментов файла (это действительно было бы нарушением принципа абстрагирования). Ибо согласен целиком и полностью с этим:

    Цитата Сообщение от Sayman Посмотреть сообщение
    на это, с моей точки зрение кощунство. Это решить можно банальной сторонней утилитой. Других причин для выделения фрагментов в сущность я не смог увидеть. И, как я писал ранее, с точки зрения пользователя - файл есть просто файл - поток данных как он выглядит изнутри с позиции ФС, ему плевать.
    Речь идет не о реальном физическом фрагментировании по факту, а о специальном бите в файле атрибутов в описателе файлов.

    Ну вот для сравнения в том же 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_редактору, дефрагментатору и проч. - но это специализированные программы, идущие на уровень ниже файловой системы). С точки зрения прикладного ПО есть лишь атрибут файла "разрешение/запрещение фрагментирования", как и атрибут "разрешение/запрещение удаления", при попытке выполнить действия, которые они запрещают, он просто словит ошибку "номер такая-то". Где и как располагаются и фрагментированы или нет файлы прикладному ПО совершенно неважно, ибо "абстрагирование от железа и низовых функций".

    Цитата Сообщение от Sayman Посмотреть сообщение
    Про сущность рам диска я то же примерно догадываюсь - для того, чтобы быстрее и нагляднее работать с образами дисков. Видимо для этого и система умеет выдать юзеру память, которая уже занята под рам диск.
    Цитата Сообщение от Sayman Посмотреть сообщение
    Про сущность рам диска я то же примерно догадываюсь - для того, чтобы быстрее и нагляднее работать с образами дисков. Видимо для этого и система умеет выдать юзеру память, которая уже занята под рам диск.
    Про сущность т.н. "RAM-диска" (беру в кавычки)) я подробнее напишу в следующий раз, если нужно (тогда напиши), если того, что ниже будет недостаточно и потребуются подробности (например, структура КЭШа, как система обрабатывает блоки и проч.). Вкратце - там примерно такое же недопонимание того, что на самом деле имеется ввиду, путаница с понятиями. Потому что во-первых не RAM-диск (который может быть только при инсталляции соответствующего драйвера, и ничем с точки зрения не отличается от флопа и винта, кроме того, что физически располагается не на дискете, а в ОЗУ), а т.н. "электронный диск"(вот так в мануалах его иногда называют, но никак не RAM-диск) или "КЭШ блочных устройств"(что тоже пишут в мануалах и это совсем правильно) - область ядра, размер которого может регулироваться пользователем и прикладным ПО, предназначенный для кэширования операций ввода-вывода с блочных устройств (в том числе и с реального RAM-диска, если его драйвер будет установлен). Позволяет уменьшить при повторяющихся операциях чтения/записи данных количество обращений к диску, что особенно заметно при работе с флопом - чем больше область КЭШа (юзер сам может ее установить, как, например, в винде при разбиении винта или даже в ОЗУ на разделы тоже есть возможность выделить область для кэширования данных), тем реше дергается головка. Размер КЭШа может регулировать как юзер по командам, набрав из командной строки вызов настройщика или прописав его его в autoexec.bat. Тоже самое может делать прикладное ПО - если нужно, увеличит временно КЭШ, если не хватает памяти под ядром - уменьшит временно его (системные вызовы позволяют узнать и запомнить его текущий размер и изменить как угодно в рамках разумного диапазона). И все. Что там происходит в КЭШе, прикладному ПО "до лампочки", ибо абстрагирование от системы. Есть лишь одна рекомендация - если производилась запись на диск через КЭШ, на всякий случай перед выходом из программы сделать "автофлаш" для принудительного сохранения блоков из КЭШа "на своим места" на диске - на тот случай, если автоматически система это еще не сделала как подстраховка. Выяснять, что и как там в КЭШе находится не надо. Просто обращение к системному вызову "на всякий случай".

    Цитата Сообщение от Sayman Посмотреть сообщение
    Сколько, кстати, сейчас там весит ядро?
    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 и Спринтер.

    Цитата Сообщение от SoftLight Посмотреть сообщение
    У меня вопрос по развитию системы. Я правильно понимаю, что исходников классической iS-DOS так и не удалось достать? То-есть TASiS создавалась и дописывалась путем декомпилляции существующего дистриба iS-DOS?
    Ядром (именно ядром) занимался не я. Это делал другой человек. И да, что-то он декомпилировал, потому ему какие-то исходники удалось раздобыть. Но пока их держит при себе и не хочет неконтролируемо пускать. Тем более, что это не полная декомпиляция системы. Там не так уж много надо было менять - в основном менять константы ширины окон панелей, низовые процедуры "рисования рамок окон на экране" (заменить оные на работу с текстовой консолью), заменить драйвер вывода символов на вывод их на текстовый экран. И уже впоследствии добавлено было несколько новых вызовов по работе с палитрой АТМ как с атрибутом системы и страничный менеджер. Т.е. глобальной переделки ядра не было. По факту - было несколько заплаток в неизменяемой и динамичной части ядра.

    Само ядро (именно ядро) развивать в этом виде за одним исключением не надо. исключение - готовая по сути доработка, позволяющая помимо существующей "неизменяемой" библиотеки по нулевым адресам подсоединять и другие "пользовательские" библиотеки, расширяющие известные функции и вводящие свои. Это версия TASiS v6.00 (текущая опубликованная - 5.41) - вот написание таких библиотек расширения (без изменения базовой системы) - было бы интересно в будущем.

    Цитата Сообщение от SoftLight Посмотреть сообщение
    Какой лицензионный статус TASiS сейчас? Это бесплатное ПО, но не планируется ли его сделать свободным? Возможно, имело бы смысл, создать репозиторий на github и предложить сообществу развивать систему всем вместе, подобно другим хорошим примерам, типа Linux? А NedoPC выступала бы координатором всех работ и занималась бы сборкой релизов. Может быть, тогда и критики iS-DOS смогли бы внести вклад и сделать систему лучше.
    Конечно TASiS бесплатная система. Делать ее свободной - это надо согласовывать с автором. Скорее всего будет так:
    Пока "версию 6" я не публиковал, ибо идет "доводка до ума" - это будет последняя доработка собственно ядра, а дальше можно и на гитхам разработчикам. Само ядро будет неизменным как "база" и гарантия от "расползания стандартов". А вот написание подключаемых библиотек расширений - это уже интереснейшая и занятнейшая вещь - к ней было бы неплохо подключить разрабов.

    Ну и просто написание прикладного ПО. В принципе, для последнего уже сейчас можно что-то подобное сделать. Только я этим никогда не занимался. Вот, при условии, что нет (у меня действительно нет) полных исходников системы и задача кардинальной переработки ядра ПОКА(!) не стоит, что и как надо размещать на гитхабе, чтобы заинтересовать людей и привлечь к работе на прикладным ПО? Потому что у меня есть задачи и предложения насчет проектов. У кого есть опыт создания таких репозиториев, помогите.


    Цитата Сообщение от Azm Посмотреть сообщение
    Для начала можно с каждой версией TASiS выкладывать отдельно архив с её исходниками и кратким описанием по их сборке.
    Разве что набор исходников драйверов разных типов и мануалы о том, что это, какова стандартная структура драйверов и резидентных файлов и проч.

    Цитата Сообщение от Azm Посмотреть сообщение
    Ничто не мешает делать и то и другое
    Хотя, даже наверняка, еще не все программы переведены в исходники
    Конечно. В свое время "Искра-Софт" даже продавала исходники отдельных утилит, какие-то просто прилагала к дистрибутиву ассемблера (и часть тех и тех исходников удалось и до сих пор удается раздобывать). Но каких-то исходников у них просто не было, так как какие-то программы просто им присылали для включения в дистрибутив без исходников сторонние авторы, которых уже не найдешь и т.д. Но сама по себе работа в этом направлении интересная.
    Последний раз редактировалось Максагор; 28.08.2019 в 05:34.
    Максагор, NedoPC group
    ПК ATM-turbo 2+ 1024Kb RAM, 1,7Gb HDD, CD-ROM, Turbo FM, GS-512
    [ZX rulezzz 4reva!!!]
    http://atmturbo.nedopc.com
    http://vk.com/atmturbo
    http://maksagor.livejournal.com
    http://moskprf.ru
    [СССР][Коммунизм][КПРФ] ну [ZX], естественно...

  2. Эти 2 пользователя(ей) поблагодарили Максагор за это полезное сообщение:

    Azm (28.08.2019), SoftLight (28.08.2019)

  3. #31
    С любовью к вам, Yandex.Direct
    Размещение рекламы на форуме способствует его дальнейшему развитию

  4. #32
    Guru Аватар для Sayman
    Регистрация
    16.02.2006
    Адрес
    Новосибирск
    Сообщений
    2,869
    Спасибо Благодарностей отдано 
    3
    Спасибо Благодарностей получено 
    7
    Поблагодарили
    7 сообщений
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    По умолчанию

    Цитата Сообщение от Максагор Посмотреть сообщение
    Ну, скажем так, я же не зря упомянул, что у меня были большие жизненные трудности
    Мой косяк - я не точно выразился. я говорил про период, когда ты уже вернулся к деятельности на Спектруме и АТМ в том числе.
    ...означает просто ЗАЩИТУ ОТ СЕГМЕНТИРОВАНИЯ
    яяясненька...
    Загрузчик, который грузится процедурами ПЗУ, когда еще нет никакой системы вокруг - длиной несколько сотен байт.
    ммм. интересно, сколько места выделено на дискете и винте под размещение загрузочной записи (загрузчика)? объясняю:
    Прямо сейчас у Спринтера загрузчик занимает места примерно 2.4 килобайта. БИОС (оно же ПЗУ) загружает в озу только первые 512 байт. в этих 512 байтах есть дозагрузка остальной части загрузчика. при этом, загрузчик так же не выделяет различия между сменным дискетой и винтом, хотя точно знает с какого диска (логически) производится загрузка. Поскольку тут ФС - FAT, то между первым разделом и mbr существует довольно не маленькое пространство, где и можно расположить загрузчик. поэтому этот загрузчик сам находит в корне диска нужный файл (system.dos), но загружает его согласно цепочке его данных в FAT. Поэтому системный файл может быть так же фрагментирован. От сюда мог бы возникнуть вопрос, даже два:
    1. почему к системному файлу (к ядру) так же не применяется "таблица" блоков (на случай фрагментированности)?
    2. Почему бы не выделить на дискете и винте лишний "пяток" секторов для хорошего и надёжного загрузчика, который был бы поумнее, чем текущий?
    опустимся до нижнего уровня ФС
    и вот тут я бы сразу задал третий вопрос: почему бы не переместить все описатели, по аналогии с ФАТом, куда то в начало диска, перед корнем? Но, вопрос отпал сам по себе благодаря:
    ...is-dos.rom - т.н. "неизменяемая" часть ядра...
    Ядром (именно ядром) занимался не я. Это делал другой человек. И да, что-то он декомпилировал, потому ему какие-то исходники удалось раздобыть
    таким образом, внести существенные правки в ядро системы, не нарушая договорённостей и не применяя дизасмов, не получится (если я верно понимаю). И на сам дизасм придётся потратить много времени. Проще с нуля всё написать... А переписывать там можно много чего.
    Последний раз редактировалось Sayman; 28.08.2019 в 08:21.
    0A заповедей:
    I. Не удаляй каталог свой.
    II. Не удаляй до времени ни одного файла.
    III. Не кради файлы.
    IV. Не желай программы ближнего своего.
    V. Почитай BDOS и BIOS как родителей своих ...

  5. #33
    Moderator Аватар для Error404
    Регистрация
    14.08.2006
    Адрес
    Владимир
    Сообщений
    4,325
    Спасибо Благодарностей отдано 
    3
    Спасибо Благодарностей получено 
    6
    Поблагодарили
    5 сообщений
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    По умолчанию

    Дурная практика писать что-то между первым разделом и МБР, т.к. следом поверх вашей писанины туда ещё кто-то такой же хитрый запишет. Не говоря уже о том, что не запрещено создать на этом пустом месте раздел.

    - - - Добавлено - - -

    Или начать первый раздел сразу вслед за МБР.

    Что описал структурами (в данном случае записями таблицы разделов) - за то уверен. Остальное ненадежно
    Лучше сделать и жалеть, чем не сделать и жалеть.

    Некоторые из моих поделок тут: https://github.com/serge-404

  6. #34
    Guru Аватар для Sayman
    Регистрация
    16.02.2006
    Адрес
    Новосибирск
    Сообщений
    2,869
    Спасибо Благодарностей отдано 
    3
    Спасибо Благодарностей получено 
    7
    Поблагодарили
    7 сообщений
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    По умолчанию

    Error404, когда изобретаешь свой какой-то стандарт или просто не знаешь других, тогда конечно. не надёжно. А если пользуешься уже чем-то устоявшимся, тогда проблем не возникает. никакая мс-дос или винда, линукс, юникс или даже новел - не испортят пространство между разделом и мбр. даже фдиск под какой нить p112 или мсх дос такого не сделают. Если только самому не указать, что туда нужно что-то записать. Всякие виндовсы или фдиск под мс дос тем более не могут размещать раздел следующим сектором после мбр потому, что сами пишут в это пространство свои загрузчики (и не они одни, кстати)! поэтому, это работает и это надёжно. например, винХР и вин 7 размещают первый раздел на 128м секторе. 10ка смещает первый раздел на 2048й сектор. и то это происходит только тогда, когда МБР пустая. Если там уже есть запись. то даже после удаления винда поставит на старое место новый раздел. только после удаления всего мбр передвинет раздел по своему. поэтому, если учесть. что (например) я таскаю файлы именно с ПЦ, то проблем описанных тобой за последние лет 10 (на спринтере, а до этого на профи) у меня не возникало.
    Последний раз редактировалось Sayman; 29.08.2019 в 16:29.
    0A заповедей:
    I. Не удаляй каталог свой.
    II. Не удаляй до времени ни одного файла.
    III. Не кради файлы.
    IV. Не желай программы ближнего своего.
    V. Почитай BDOS и BIOS как родителей своих ...

  7. #35
    Moderator Аватар для Error404
    Регистрация
    14.08.2006
    Адрес
    Владимир
    Сообщений
    4,325
    Спасибо Благодарностей отдано 
    3
    Спасибо Благодарностей получено 
    6
    Поблагодарили
    5 сообщений
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    По умолчанию

    Цитата Сообщение от Sayman Посмотреть сообщение
    Error404, когда изобретаешь свой какой-то стандарт или просто не знаешь других, тогда конечно. не надёжно. А если пользуешься уже чем-то устоявшимся, тогда проблем не возникает. никакая мс-дос или винда, линукс, юникс или даже новел - не испортят пространство между разделом и мбр. даже фдиск под какой нить p112 или мсх дос такого не сделают. Если только самому не указать, что туда нужно что-то записать. Всякие виндовсы или фдиск под мс дос тем более не могут размещать раздел следующим сектором после мбр потому, что сами пишут в это пространство свои загрузчики (и не они одни, кстати)! поэтому, это работает и это надёжно. например, винХР и вин 7 размещают первый раздел на 128м секторе. 10ка смещает первый раздел на 2048й сектор. и то это происходит только тогда, когда МБР пустая. Если там уже есть запись. то даже после удаления винда поставит на старое место новый раздел. только после удаления всего мбр передвинет раздел по своему. поэтому, если учесть. что (например) я таскаю файлы именно с ПЦ, то проблем описанных тобой за последние лет 10 (на спринтере, а до этого на профи) у меня не возникало.
    Хоть это и пошло, ссылаться на Википедию, но все же
    Стандартизация MBR
    Утверждённого стандарта на структуру MBR не существует, однако, есть «сложившиеся традиции», которых придерживаются большинство MBR от разных производителей.
    что другими словами описывает ровно то, о чем я говорил постом ранее.
    Ничто не мешало тем шибко умным производителям, кто использует "межсекторное пространство" бггг между разделами в MBR, добавить в MBR описатель, аналогичный DPB CP/M как делалось за 10 лет до того - десяток байт в MBR нашелся бы (тем более раз уж загрузчик вынесен). Даже именитым производителям религия не помешала завести в FAT-e структуры, читая которые не надо сочинять отсебятины как с МBR. Раз они этого не сделали, значит считали решение временным, а его похеривание- несущественным. Туда им и дорога.

    - - - Добавлено - - -

    И кстати, в стандарте GPT (потребовалось ждать до следующего века, чтобы понять очевидное) так и сделано - в начале структуры, заголовки, описывающие размещение всех данных, потом уже данные. Всё по полочкам. И там по-прежнему (для обратной совместимости) есть MBR, в котором разделу уже "стандартно" разрешено начинаться с сектора с LBA=1.
    Последний раз редактировалось Error404; 29.08.2019 в 17:25.
    Лучше сделать и жалеть, чем не сделать и жалеть.

    Некоторые из моих поделок тут: https://github.com/serge-404

  8. #36
    Guru Аватар для Sayman
    Регистрация
    16.02.2006
    Адрес
    Новосибирск
    Сообщений
    2,869
    Спасибо Благодарностей отдано 
    3
    Спасибо Благодарностей получено 
    7
    Поблагодарили
    7 сообщений
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    По умолчанию

    Цитата Сообщение от Error404 Посмотреть сообщение
    Ничто не мешало тем шибко умным производителям
    в "до МБРную" эпоху туда шлёпать мог кто угодно и что угодно. Но, уже в наше время появились всякие Скорпионы, ис-дос/тазис, профинские cbios5.30 которые не знали или просто игнорировали МБР, а потому и писали туда свободно. Сейчас, когда у 95% "ретрохоббистов" файлики хранятся на ПЦ, можно не переживать за проблему "межсекторного" бгг пространства. Более того, когда я писал первый fdisk, я и тогдашний винт и потом уже CF карту куда только не таскал - no problems!. Более того - я под семёркой и 10кой полностью убивал все разделы, пересоздавал их там же и БАЦ - это самое пространство не затрагивалось совершенно (загрузчик не страдал). Поэтому совершенно точно - проблема эта высосана из пальца.
    И кстати, в стандарте GPT
    он нас не интересует, поэтому опустим его.
    Последний раз редактировалось Sayman; 29.08.2019 в 17:31.
    0A заповедей:
    I. Не удаляй каталог свой.
    II. Не удаляй до времени ни одного файла.
    III. Не кради файлы.
    IV. Не желай программы ближнего своего.
    V. Почитай BDOS и BIOS как родителей своих ...

  9. #37
    Moderator Аватар для Error404
    Регистрация
    14.08.2006
    Адрес
    Владимир
    Сообщений
    4,325
    Спасибо Благодарностей отдано 
    3
    Спасибо Благодарностей получено 
    6
    Поблагодарили
    5 сообщений
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    По умолчанию

    Цитата Сообщение от Sayman Посмотреть сообщение
    в "до МБРную" эпоху туда шлёпать мог кто угодно и что угодно. Но, уже в наше время появились всякие Скорпионы, ис-дос/тазис, профинские cbios5.30 которые не знали или просто игнорировали МБР, а потому и писали туда свободно. Сейчас, когда у 95% "ретрохоббистов" файлики хранятся на ПЦ, можно не переживать за проблему "межсекторного" бгг пространства. Более того, когда я писал первый fdisk, я и тогдашний винт и потом уже CF карту куда только не таскал - no problems!. Более того - я под семёркой и 10кой полностью убивал все разделы, пересоздавал их там же и БАЦ - это самое пространство не затрагивалось совершенно (загрузчик не страдал). Поэтому совершенно точно - проблема эта высосана из пальца.

    он нас не интересует, поэтому опустим его.
    Я просто к тому веду разговор, что совершенно ни к чему повторять чужую когда-то на скорую руку сделанную глупость. Если вы сейчас заново проектируете какое-то размещение данных, до размещайте всё это в разделе, а не за его пределами. В своем же собственном разделе уже можно творить что угодно - хоть завести там еще один описатель (нo завести! а не вот это вот {неназванные «сложившиеся традиции», которых придерживаются}) и в нем описать более мелкое деление раздела на разнотипные кусочки.

    - - - Добавлено - - -

    Что до винды, то она прекрасно обрабатывает разделы сделанные с любого LBA, не ругается. Что о чем-то говорит. Сама создает с отступом, это да.
    Лучше сделать и жалеть, чем не сделать и жалеть.

    Некоторые из моих поделок тут: https://github.com/serge-404

  10. #38
    Guru Аватар для Sayman
    Регистрация
    16.02.2006
    Адрес
    Новосибирск
    Сообщений
    2,869
    Спасибо Благодарностей отдано 
    3
    Спасибо Благодарностей получено 
    7
    Поблагодарили
    7 сообщений
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    По умолчанию

    Цитата Сообщение от Error404 Посмотреть сообщение
    Я просто к тому веду разговор, что совершенно ни к чему повторять чужую когда-то на скорую руку сделанную глупость. Если вы сейчас заново проектируете какое-то размещение данных, до размещайте всё это в разделе, а не за его пределами. В своем же собственном разделе уже можно творить что угодно - хоть завести там еще один описатель (нo завести! а не вот это вот {неназванные «сложившиеся традиции», которых придерживаются}) и в нем описать более мелкое деление раздела на разнотипные кусочки.

    - - - Добавлено - - -

    Что до винды, то она прекрасно обрабатывает разделы сделанные с любого LBA, не ругается. Что о чем-то говорит. Сама создает с отступом, это да.
    глупость или нет - но даже современные компы следуют этой "глупости" и читают сектор lba=1, если это нужно. Спринтер так же читает этот сектор для stage1 загрузчика. не вижу никаких проблем. напоминаю - за всё время существования Спринтера у меня, эта область не страдала как либо. можно поспрашивать у других владельцев (думаю результат будет тот же).
    0A заповедей:
    I. Не удаляй каталог свой.
    II. Не удаляй до времени ни одного файла.
    III. Не кради файлы.
    IV. Не желай программы ближнего своего.
    V. Почитай BDOS и BIOS как родителей своих ...

  11. #39
    Moderator Аватар для Error404
    Регистрация
    14.08.2006
    Адрес
    Владимир
    Сообщений
    4,325
    Спасибо Благодарностей отдано 
    3
    Спасибо Благодарностей получено 
    6
    Поблагодарили
    5 сообщений
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    По умолчанию

    Одно дело не страдало, и совсем другое проектировать правильно, по красоте.

    - - - Добавлено - - -

    Ладно, я сказал, вы услышали, а как будете делать - дело хозяйское.
    Лучше сделать и жалеть, чем не сделать и жалеть.

    Некоторые из моих поделок тут: https://github.com/serge-404

  12. #40
    Guru Аватар для Sayman
    Регистрация
    16.02.2006
    Адрес
    Новосибирск
    Сообщений
    2,869
    Спасибо Благодарностей отдано 
    3
    Спасибо Благодарностей получено 
    7
    Поблагодарили
    7 сообщений
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    По умолчанию

    Error404, на дворе 2019й год и всё ровно выпускаются по сей день материнки с поддержкой именно этого "стандарта", по сей день релизятся ОСи с поддержкой этого "стандарта". может быть, когда-нибудь...
    самое главное то. что твой вариант имеет право на жизнь и имеет свои плюсы. win10 выделяет около 400метров под подобный раздел (скрытый). но он так же стартует с 2048го сектора. на моём компе сектор lba=1 содержит запись EFI (мать asrock AB350 Pro4). При этом мать поддерживает Legacy boot mode. Но, у твоего метода есть и недостатки:
    1. Придя с таким винтом на системы, которые игнорят mbr ты так же рискуешь потерять и загрузочный раздел и саму mbr.
    2. нужно потратить 1 первичную запись из 4х.
    учитывая всё это - проблемы как таковой нет.
    Последний раз редактировалось Sayman; 29.08.2019 в 19:09.
    0A заповедей:
    I. Не удаляй каталог свой.
    II. Не удаляй до времени ни одного файла.
    III. Не кради файлы.
    IV. Не желай программы ближнего своего.
    V. Почитай BDOS и BIOS как родителей своих ...

Страница 4 из 4 ПерваяПервая 1234

Информация о теме

Пользователи, просматривающие эту тему

Эту тему просматривают: 1 (пользователей: 0 , гостей: 1)

Похожие темы

  1. Быстро вывести число 0-255 на экран
    от Aprisobal в разделе Программирование
    Ответов: 7
    Последнее: 26.01.2005, 09:05

Ваши права

  • Вы не можете создавать новые темы
  • Вы не можете отвечать в темах
  • Вы не можете прикреплять вложения
  • Вы не можете редактировать свои сообщения
  •