Просмотр полной версии : TASiS - iSDOS под текстовый экран.
какая версия последняя, является ли tasis бесплатной системой. если нет, откуда можно скачать этот варез
какая версия последняя, является ли tasis бесплатной системой. если нет, откуда можно скачать этот варез
На данный момент TASiS является бесплатной (договоренность с Е.Илясовым достигнута). По поводу последней версии, то это к Максу Тимонину и Юре Корсунину вопросы...
Планируется сделать небольшую книжку по TASiS.
TASiS работает только на АТМ!
на atmturbo.narod.ru скачать нельзя. тогда где?
Максагор
02.08.2005, 00:24
на atmturbo.narod.ru скачать нельзя. тогда где?
Дистрибутивы TASiS и iS-DOS Chic (ATM-version) находится в процессе формирования. Пока все не будет отшлифовано и отлажено, на сайт выложено не будет. Особенное внимание уделяется отладке процесса установки систем на винт - видели в соседней дискуссии, сколько эмоций было из-за установки на винт ОС CP/M (пр установке которой вроде бы и книжка написана)? Так что пока я сам уверенно и с закрытыми глазами не буду в полпинка ставить систему (чтобы написать грамотную доку, и уметь если что все пояснить другим), народ систему не увидит. Сейчас она доступна нескольким людям (в основном членам NedoPC group) для тестирования. В принципе, тебе, SMT, тоже могу кинуть образ для просмотра на эмуле (я смотрел. Под UNREAL в режиме ATM запускается на отлично) с условием никому больше пока не давать.
Остальным: кроме спектрумовских дел на мне сейчас висит еще и научная (надо заканчивать диссертацию, да и еще закончить пару научных статей) и общественная (статьи в партийные газеты - кто не знает, я человек партийный). Примерно через неделю я уезжаю до конца августа, беря с собой научные материалы. В форум вылезать буду, но от реального спектрума буду временно отрезан. Так что закончу формирование дистрибутивов Chic/TASiS не раньше конца сентября - начала октября. Наберитесь терпения. Пока что xBIOS (ее-то дождались ведь?) осваивайте, ибо возможности там бездонные. А сегодня или завтра я вам новые CPM-утилитки под нее подкину и подправленную доку.
Наверно никто не обратил внимания, но дистрибутив TASiS уже лежит на http://atmturbo.nedopc.com.
ОСь сильно выиграла за счет использования текстового режима 80x25.
Сегодня ко мне заходил Макс и показывал различные фишки, честно говоря приятно был удивлен возможностям.
Вообще на месте господ-обладателей Профи, я бы задумался над портацией. Остальные - завидуйте что нет текстового режима :).
Вообще на месте господ-обладателей Профи, я бы задумался над портацией. Остальные - завидуйте что нет текстового режима
Надо срочно делать V9990 и под него портировать.тогда и завидовать ни кому не придётся!
Максагор
27.11.2005, 03:24
Наверно никто не обратил внимания, но дистрибутив TASiS уже лежит на http://atmturbo.nedopc.com.
ОСь сильно выиграла за счет использования текстового режима 80x25.
Сегодня ко мне заходил Макс и показывал различные фишки, честно говоря приятно был удивлен возможностям.
Вообще-то, когда дистрибутив в начале ноября увидел свет, я давал на форуме официальное сообщение в разделе "события". Так что если кто не обратил внимания, то я даже не знаю, что сказать...
Вообще на месте господ-обладателей Профи, я бы задумался над портацией. Остальные - завидуйте что нет текстового режима :).
Скорее писать нужно свою собственную локализацию исдоса, так как у Профи все-таки не текстовый экран, а аппаратный мультиколор 512х240. Поэтому просто сменой номеров портов и косметическими подправками не обойтись - полностью переделывать надо всю систему вывода на экран: в текстовой консоли ведь каждый байт на экране отображается как символ (или цвет всего знакоместа). В Профи же придется по старинке выводить символы из загружаемого фонта побайтно, и опять-таки побайтно их окрашивать. Более того, этот экран,при условии совпадения атрибутов со знакоместами для символов, позволит получать матрицу 64х30 символов, но никак не 80х25 как в TASiS. Так что придется по новой перелопачивать уровень SHELL и оконных менюшек на предмет правки вывода окошек и панелей под нужный резолюшн. Плюс радикально надо переписать кучу дров.
Я не говорю, что это все невозможно. Наоборот. Просто проблема стоит не в портировании TASiS на Профик, а в переделке исдоса под него с нуля. Иначе никак. А это титаническая работа, и Корсунина вы явно не заставите это делать, тем более, что и Профика у него нет. А сами... Хорошо, если кто отыщется, который не просто желает это делать, но и в достаточной степени знает устройство ядра iS-DOS. Что ж... "Безумству храбрых поем мы песню!" (и от себя - желаем удачи!).
Надо срочно делать V9990 и под него портировать.тогда и завидовать ни кому не придётся!
Да сам хочу, тем более есть устная договоренность с некоторыми игрописателями!
Но это в другую тему :)
Максагор
28.11.2005, 02:40
Сегодня выложил на сайт http://atmturbo.nedopc.com новую, чуть подправленную версию v1.01 дистрибутива операционной системы OS TASiS v5.40. Дистрибутив v1.00 удален с сайта за ненадобностью. Отличия двух дистрибутивов минимальны и заключаются в примерно в десятке-другом файлов, преимущественно настроечных, а также в новом драйвере slv1_HDD.blk для SLAVE-устройств IDE. Тем, кто уже установил дистрибутив v1.00 на винчестер, но хочет обновить его до версии v1.01, совсем не нужно переставлять всю систему. Достаточно заменить (или добавить) файлы, указанные в текстовом файле history.txt, присутствующем в архиве с системой.
to Максагор....
Макс, все ниже сказанное из раздела "Повторяю еще раз, для особо умных, радиостанция "на паравозе"". Дело в том, что я, например, выпал из рядов спектрумистов лет этак на 10 и мне не до конца понятен принцип работы Спека с HDD во всех трех операционках (ТР-ДОС, СР-М, ИсДОС). Когда я занимался спеком вся эта беда была to be implemented.....
Дак вот, нельзя ли по подробнее описать для таких, как я, установку на жесткий диск и работу с системами? Естественно я имею ввиду ТаСИС, xbiosdos....
Те описания, которые лежат у тебя на сайте, конечно же достаточно полно описывают принципы работы систем, но, я считаю, что они для аудитории с углубленным изучением предмета...
to Максагор....
Макс, все ниже сказанное из раздела "Повторяю еще раз, для особо умных, радиостанция "на паравозе"". Дело в том, что я, например, выпал из рядов спектрумистов лет этак на 10 и мне не до конца понятен принцип работы Спека с HDD во всех трех операционках (ТР-ДОС, СР-М, ИсДОС). Когда я занимался спеком вся эта беда была to be implemented.....
Дак вот, нельзя ли по подробнее описать для таких, как я, установку на жесткий диск и работу с системами? Естественно я имею ввиду ТаСИС, xbiosdos....
Те описания, которые лежат у тебя на сайте, конечно же достаточно полно описывают принципы работы систем, но, я считаю, что они для аудитории с углубленным изучением предмета...
Рекомендую покопаться в диске дистрибутива TASiS, там есть подробные описания именно как устанавливать.
Я Максу говорил что лучше доку написать, но отмазался - сказал что все в дистрибутив включил!
Рекомендую покопаться в диске дистрибутива TASiS, там есть подробные описания именно как устанавливать.
А покопаться в дистрибутиве легко можно с помощью Far Manager + xFAR плагины.
Максагор
16.12.2005, 04:50
Рекомендую покопаться в диске дистрибутива TASiS, там есть подробные описания именно как устанавливать.
Я Максу говорил что лучше доку написать, но отмазался - сказал что все в дистрибутив включил!
Роман, прекрати тупить. Какие отмазки? ДОКУ Я НАПИСАЛ! И лежит она на диске дистрибутива. Неужели есть принципиальная разница для понимания - там она, или в виде вордовского файла?
Максагор
16.12.2005, 05:00
to Максагор....
Макс, все ниже сказанное из раздела "Повторяю еще раз, для особо умных, радиостанция "на паравозе"". Дело в том, что я, например, выпал из рядов спектрумистов лет этак на 10 и мне не до конца понятен принцип работы Спека с HDD во всех трех операционках (ТР-ДОС, СР-М, ИсДОС). Когда я занимался спеком вся эта беда была to be implemented.....
Дак вот, нельзя ли по подробнее описать для таких, как я, установку на жесткий диск и работу с системами? Естественно я имею ввиду ТаСИС, xbiosdos....
Те описания, которые лежат у тебя на сайте, конечно же достаточно полно описывают принципы работы систем, но, я считаю, что они для аудитории с углубленным изучением предмета...
Вопрос очень обширный. Даже не знаю с чего начать разъяснения. Потому что в любом случае в ответ на запрос типа "Нифига не понял" следует вопрос "не понял где именно?". Не писать же новую доку с нуля, а если и переписывать, то по каким принципам, чтобы была понятнее?
Поэтому, для начала почитай имеющуюся документацию по установке вышеназванных систем, а потом по непонятным местам конкретно сформулируй свои вопросы - или тут, или по мылу. Буду рад ответить.
Дока по установке OS CP/M лежить здесь: http://atmturbo.nedopc.com/inf/books/nedopc/install.zip
xBIOS/vTR-DOS инсталляции не требует, ибо напрямую с винтом не работает, а образы подгружаются/сохраняются обычными утилитами в среде CP/M и TASiS.
Дока по установке OS TASiS на винт и флоп лежит в самом дистрибутиве в каталоге HELP в файле install.txt
Ее также можно вызвать через меню пользователя по клавиш F1 на пЦ-клавиатуре или SS+1 на механической. Откроется менюшка с различными пунктами документации (по горячим клавишам, по разъяснению номенров ошибок, как пользоваться оболочкой и т д.), где есть и пункт вызова доки по установке.
Если же смотреть хочешь на пЦ, то тебе тут уже советовали воспользоваться для просмотра FARом с ZX-плагинами. С его помощью можно залезть в образ дистрибутива как в обычный подкаталог.
В общем, жду конкретных вопросов. Не стесняйся, что они могут получиться ламерскими. Отвечу на все подробно. Главное, чтобы был конкретный предмет вопроса.
Всем бальшой СПАСИБ за разьяснение.
С СР/М я сам ступил :mad: вчера покопался в доках присланных Романом вместе с АТМ и нашел описашку.
С TASIS проблем был такой: с одной стороны я все никак не соберусь упаковать АТМ в АТ корпус, достаю её и раскладываю вечерком на столе в дивном беспорядке... руки бы себе оборвать :mad: .... соответственно подгрузить ОСь на реале всё никак недооборванные руки недоходят. С другой стороны, я пользуюсь на ПЦ Total Commander а не FAR, а на тотале нет просмотрщика fdi :( придется загрузить ФАР....
Про xbiosdos позже вопросики позадаю, надо сначала АТМку упаковать и ПЗУ новую прошить....
С СР/М я сам ступил :mad: вчера покопался в доках присланных Романом вместе с АТМ и нашел описашку.
Давай ее в студию :).
Роман, прекрати тупить. Какие отмазки? ДОКУ Я НАПИСАЛ! И лежит она на диске дистрибутива. Неужели есть принципиальная разница для понимания - там она, или в виде вордовского файла?
Где нить я говорил, что ты ее не написал :). НА самом деле мой опыт показывает, что пользователю нужна дока аналогичной СП/Мной типа делай раз делай два. Можно даже туда же в тот файл включить ее. Но зная твою текущую занятость я этого не требую.
Москвичи могут получить ПЗУ с ХБИОС для Турбо у меня сдав старую ПЗУ и доплатив 35 рублей. Единственное требование для нормальной работы, это устранение перепутывание памяти (см. у меня на сайте).
Давай ее в студию .
Да вон она у Макса в посте лежит.
Да вон она у Макса в посте лежит.
А ты под описашкой понимал описание :), а я под описашкой понял дословно - что мы там описки какието сделали, т.е ошибок насажали. Не вьехал просто, сорри!
Максагор
16.12.2005, 12:11
Где нить я говорил, что ты ее не написал :). НА самом деле мой опыт показывает, что пользователю нужна дока аналогичной СП/Мной типа делай раз делай два. Можно даже туда же в тот файл включить ее. Но зная твою текущую занятость я этого не требую.
А она именно в таком стиле и написана! Роман, зная твою занятость, я к тебе претензии по поводу того, что ты доку по TASiS, несмотря на имеющийся у тебя сабж как на дискете, так и на винте, все еще не прочитал, тоже не в претензиях. :)
Но все-таки, будет время, ознакомься - вопросов меньше станет.
Максагор
16.12.2005, 12:15
Про xbiosdos позже вопросики позадаю, надо сначала АТМку упаковать и ПЗУ новую прошить....
Дока по xBIOS лежит здесь:
http://atmturbo.nedopc.com/inf/books/nedopc/xbiosdoc.zip
Приятного чтения!
Но все-таки, будет время, ознакомься - вопросов меньше станет.
Да с этим я разберусь и даже сам ее включу в файл "Инструкции по установке", еще туда планирую включить раздел по работе с дисками на ПЦ - тоже у пользователей вопросов много возникает.
Может тупой вопрос задам, ибо не изучил ещё все архивы. А языки более высокого уровня чем ASM под тазис есть? Типа Си. Или на крайняк паскаль? И где найти описание системы для программистов, системные вызовы там и т.п.? Кроме того не совсем понятно - реализована ли возможность запуск системы в zxevo с флешки, при это не портящая и не мешающая fat32, чтобы можно было переткнув флеху перенести данные с PC?
Максагор
22.08.2019, 02:39
Может тупой вопрос задам, ибо не изучил ещё все архивы. А языки более высокого уровня чем ASM под тазис есть? Типа Си. Или на крайняк паскаль? И где найти описание системы для программистов, системные вызовы там и т.п.? Кроме того не совсем понятно - реализована ли возможность запуск системы в zxevo с флешки, при это не портящая и не мешающая fat32, чтобы можно было переткнув флеху перенести данные с PC?
Есть iS-forth. Но я в этом языке не копенгаген, хотя говорят, что сам по себе язык хороший - но как он хорошо реализован в исдосе, не знаю, не работал с ним. Как достоинство отмечу, что создает при компиляции промежуточные объектные файлы, совместимые с такими же от ассемблера - и их можно в итоге объединять вместе при линковке. Но опять-таки, я не экспериментировал.
По поводу работы с флэшки, а точнее - с SD-карточки - проект начат, как только система была перенесенана ZX-Evo - раньше, на ATM, при отсутствии на этой машине SD-контроллера, было не с руки экспериментировать. Также прорабатывается проект создания Partition-manager для создания разных разделов на винте, не портящих как FAT, так и существующие варианты разделов CP/M и iS-DOS/TASiS.
Максагор
26.08.2019, 19:48
Переместил весь массив срача во флейм (да-да, с сегодняшнего дня я тут модератор). Кто хочет резвиться, резвитесь там. Но так как переместил весь массив, ввиду практической невозможности вычленить конструктив (а он имеется, в т.ч. и у Vadimа, и у Saymanа), допускается возникающие конструктивные вопросы транслировать оттуда сюда заинтересованным авторам, которые самостоятельно очистят их от переходов на личности (все, перелистнули страницу - кто не успокоился - тема во флейме доступна) и сформулируют в виде, удобном для ответа.
В частности обращаюсь к Saymanу:
зачем ты цитируешь древнюю фразу, за которую (в том числе)
я в те же года (примерно) уже получал по шапке?!
Ну, во первых, просто для показа того, что с 2011 года ничего не изменилось, а оскорблять можно не прямо в стиле "Ты - х..." и просто песня в чужой теме на оффтопик "Это ОСь или не ОСь" старая и ничего не изменилось. А оскорбляются там авторы системы ("ее наверное писали в пьяном виде"" и прочее и прочее), с которыми я в свое время лично переписывался и оскорблять не дам. И вы и Vadim, действуя вместе, по факту стали переозвучивать в манере, воспринимаемой мной как хамская те же эпитеты и утверждения, как и много лет назад. При том, что тема конкретного топика не предполагала срача на тему ОС - не ОС, я прямо попросил покинуть ее (хотя бы элементарно, чтобы не засорять дискуссии по теме) и создать соседний топик, но был проигнорирован. Причем после того, как модератор вычистил одну тему от вашего оффтопика, вы вместо того, чтобы создать свой, просто залезли в другой. Кто из вас двоих так решил, знать не знаю. Я не призывал скопом баннить в том числе и из-за этого. Но флейм был налицо. Далее все заверте... со взаимным накалом эмоций и эпитетов. Vadim опустился до площадной брани и немотивированной политоты и был забанен (не мной), вы - нет, вы продолжаете дискуссию. В любом случае приветствуется стремление разобраться, а не продавить свое видение.
Надеюсь, вам моя мотивация и ход мыслей в течение развития событий понятен. Теперь все перемещено во флейм. Кто не успокоился - резвитесь.
Теперь о дискуссии. Как я сказал, в перемещенном скопом массиве был конструктив, который просто вычленить было трудно. Авторы конструктива, которым просто предлагаю оставить эмоции либо в теме флейма, либо в прошлом, могут самостоятельно копировать его сюда в стиле "вопрос - ответ". Готов ответить последовательно на все поступающие вопросы. Но с одним большим НО (и это особенно относится к Saymanу). У меня нет времени и возможности отвечать на длиннющие портянки из сотен вопросов - чисто физически. Что-то я упущу (на что сразу скажут - Тимонин ушел от ответа!!!!), а еще мне надо работать, есть, спать и заниматься семьей. Ну и иметь время в т.ч. для того, чтобы кодить на Спекки, а не сидеть вместо этого пол ночи на форуме, разбирая портянки с о смесью собственно конструктивных вопросов с дикой хренью и холиваром пополам. Предлагаю последовательно разбирать вопрос за вопросом, и как будет снят или хотя бы разъяснен один пункт, переходить ко второму и так далее. Срач "ОС - не ОС" здесь под запретом - это во флейм. Любые вопросы в стиле "Я прочитал, что в исдосе вот так, а почему? Это неправильно, должно по идее быть так", изложенные в корректной и конструктивной форме, приветствуются. Оффтопичные придирки типа "Мануал кривой - значит ОС - г...но" - порицаются (тем более мануал писал не я, да и к тому же как "кривость" мануала что-то говорит о коде ядра системы). "Вкусовщина" - тоже. "Нравится или не нравится" - это вопрос личных пристрастий, ибо попробуйте где-нибудь найти мои утверждения, что "TASiS - самая лучшая система, бросайте свои ОСи и все пересаживайтесь под "мою прррелесть!" - нет даже близко. Есть лишь информирование спектрум-пользователей, что есть система, есть новый дистрибутив, есть такой-то софт под нее, такого-то нет или пока нет и т.д.. Тогда более понятным будет степень оффтопичности того, что было понаписано вами двоими в темах под эту ОСь.
Надеюсь, такие правила всех устроят: Тогда вэлком.
Учитывая, что я могу отвечать только на последовательно поступающие вопросы, остановлюсь на одном из первых по счету в последней "портянке" Saymanа. Давайте полностью обсудим их:
УУтутутууу, стопэ стопэ, не гони гусей. Требуется доработка ты говоришь. начнём с того, что даже на твоём сайте я вижу минимум 2 доработки памяти. по одной схеме (от Тимона) до 2 метров памяти, по второй, если я верно понимаю, до 4х (но тут я мог ошибиться). Таким образом минимум 2 мегабайта озу система должна уметь адресовать.
Есть древнющщая доработка памяти от TiM0Nа по внедрению портов Профи к АТМ (те самые 2Мб, о которых ты пишешь выше). Она использовалась только им самим, может еще парой человек в Новосибе, откуда он родом. Требовала существенной работы паяльником для внедрения в существующие на то время платы АТМ (в частности, напайки SIMM_модуля). Больше никакой информации об этом нет. Этот стандарт не поддерживается и поддерживаться не планируется как боковая "отсохшая" ветвь. TASiS - система для линейки ATM/ZX-Evo как есть и потенциально для машин, где есть на уровне портов т.н. "диспетчер памяти" - т.е. хардверная возможность включать любую страницу в любую четверть адресного пространства (так что теоретически (только теоретически) возможен перенос системы на MSX, Sprinter, Ts-Conf, но невозможен, к примеру, на такие хорошие спектрум-клоны как ZX-Profi и Scorpion+GMX).
Есть 4Мб ОЗУ в ZX-Evolution. Система их не может видеть по одной простой причине - ядро TASiS было создано задолго до появления ZX-Evolution. 1 Мб в ATM управляется портом #xFF7 и все. Иных портов нет. ZX-Evolution/BaseConf, совместимый с ATM по принципу "сверху-вниз" имеет два типа портов - то же #xFF7, которым можно адресовать не более 1Мб ОЗУ, и новый порт #x7F7, через который доступны ВСЕ 4Мб.
Ядро TASiS создавалось задолго до появления этого дополнительного порта и просто о нем не знает (а в соответствии с принципами абстрагирования от железа только ОС, его подпрограммы должны обращаться к портам. Прикладное ПО пользователя должно видеть только системные вызовы с их входными/выходными данными, если надо - системные переменные для настроек и проч.).
С этой точки зрения вот те самые рестарты работы со страницами просто на будущее построены так, чтобы потенциально могли бы "прозрачно" для прикладного ПО работать с ОЗУ до 4Мб. А именно - на входе они принимают любой номер страницы от 0 до 255 (есть особенности с адресацией конкретных страниц 0dec и 255dec, так как это в данном случае неважно для понятия общего принципа, намеренно опускаю), плюс есть битовая таблица занятости страниц на 32 байта (256 битов). Но так как АТМ просто не знает, что физически могут существовать порты под 4Мб, и система была изначально написана под именно эту машину и использует в процедурах порт #xFF7, то все номера выше 63 процедура обработки входящих в рестарт данных режет по маске. А в битовой таблице все страницы выше 1Мб помечены как "занятые", так что любой поиск свободных страниц для их занятия прикладным ПО выше 1Мб не поднимется. Но задел для адресации всех 256 страниц, как видите, уже создан. Требуется только переписать процедуру обработки рестарта под порты #x7F7, снять "блокировочные" биты в таблице для ОЗУ выше 1Мб и "резание номера страницы" по маске. Прикладное ПО просто автоматом получит расширенные возможности по поиску страниц в диапазоне до 256, а не 64-х. Никаких переделок в самом ПО не потребуется. Ибо абстрагирование от железа.
Ближайшая аналогия (грубая. Просьба не придираться - стараюсь донести общий смысл) - много лет назад (году в 2012-м) покупал ноут с ОЗУ 6Gb. Так мне посоветовали отдельно доплатить за 64-разрядную винду, мол там сейчас стоит 32-разрядная, и без костылей она выше 4Gb не увидит.
Почему в TASiS за 14 лет это не было сделано раньше? Потому что сначала ZX-Evolution с его стандартами портов не существовало вовсе. А затем потому, что я по жизненным обстоятельствам, во-первых, почти не мог заниматься спектрумом вообще, и уж тем более таким большим проектом, как развитие ОСи (понемножку разными энтузиастами, и даже мной писались или совершенствовались отдельные утилитки, причем разрозненно - поэтому и пришлось пока выпустить НОВЫЙ дистрибутив со СТАРЫМ недоработанным еще ядром, где все новинки включены, взаимоувязаны в файлах ассоциаций и настроек и т.д.), плюс у меня не было под рукой работающего реального ZX-Evolution, чтобы проводить эксперименты (поэтому я и драйверами не занимался - если я что и мог делать, то под АТМ, под ZX-Evo надо было переделать как минимум все, что связано с IDE(так как порты другие) - драйвера, настроечные утилиты для дров, загрузчики с винта (потому что прописанный в ПЗУ загрузчик с винта тоже другой - нежели в АТМ) - т.е. основные низкоуровневые железозависимые части не внедренные непосредственно в ядро - те же драйвера могут маунтиться и удаляться). Для переделки страничной процедуры надо было непосредственно заниматься ядром. Сейчас, в 2019 году, занявшись системой после перерыва во много лет, я это оставил на потом, после того как система сначала заработает на ZX-Evolution в том виде как есть. Системой в этом плане занимаюсь с апреля.
Вот такой вот пример вопроса-ответа. Отсюда мой вопрос к Saymanу.
Видите, сколько текста мне пришлось потратить для подробного ответа только на один вопрос. А теперь представьте, могу ли я ответить на поток вопросов и претензий (в т.ч. с моей точки зрения глупых) сыплющихся во-первых длинными списками, а во-вторых сразу от двух людей? Я должен всю свою жизнь посвятить их комментированию? Представьте себя чисто физически на моем месте.
Мой ответ по этому вопросу достаточен? Такой подход к дискуссии удовлетворяет? Есть вещи, которые надо уточнить? Есть вещи, которые вы вроде бы поняли, но сомневаетесь, что может где-то могли понять неправильно? Если есть, пишите уточняющие вопросы.
Если нет, то предлагаю вам самому констатировать прямым текстом, что данный вопрос можно закрыть и переходить к следующей теме. Например, там у вас был вопрос про "сегментированные файлы и электронный диск". Если вы готовы переходить к нему (но только если готовы), просьба скопипастить то, что вам нужно для вопроса из флейма, а лучше пересформулировать вопрос как можно подробнее (это если закрыт предыдущий вопрос) и четче.
Вот такой вот конструктив.
Вот такой вот пример вопроса-ответа.
да. интересно было почитать. в общем и целом понятно. кроме момента с железной zxevo - уже несколько лет как существует рабочая версия UnrealSpeccy в котором весьма достоверно реализована эмуляция бейзконфы. в часности, текстмод, ИДЕ, память. Т.е. дожидаться железки было не обязательно и накидать (на вентилятор) минималку для включения поддержки эво, предположительно можно было. Но, я повторюсь - предположительно. Понятное дело, кроме Спектурма и атм есть и другие, более реальные проблемы и потребности. Но каждый раз возвращаюсь к допилу системы этот момент так же можно учитывать (эмулятор). ты же не хочешь сказать, что весь код пишешь на реале и прям в Тазисе (в is-asm`е)?
что касательно ещё поддержки железа и, в том числе, своего рода абстракции, на который ты обратил внимание в своём определении (уж не буду его снова приводить), есть ещё интересное наблюдение. Для чего выводить в отдельный дистрибутив версии для атм и эво? в целом, в рамках одного дистриба можно решать задачу по переключению между ядрами для атм и эвы. опять-таки - драйвера... экран, память, ещё что-то. при грамотном подходе будет компактно и быстродействие не пострадает. Я не говорю про случаи, когда требуется именно напрямую работать с аппаратурой (ну там, игры, демки). в рамках консольных утилит хватало бы с головой!
Что касается фрагментированных файлов - я смог придумтаь только одну причину по которой фрагментированные файлы выделены в отдельную сущность - это попытка производить запись данных между уже записанных данных. т.е. грубо говоря - "раздвигать" данные файла в стороны. но эта задача настолько не каждодневная и в целом не существенная, что тратить ресурсы машины на акцентирование каких-то рестартов на это, с моей точки зрение кощунство. Это решить можно банальной сторонней утилитой. Других причин для выделения фрагментов в сущность я не смог увидеть. И, как я писал ранее, с точки зрения пользователя - файл есть просто файл - поток данных как он выглядит изнутри с позиции ФС, ему плевать. Пользователю важно, что бы система умела быстро и с минимальными телодвижениями (пользователя) работать с этими файлами. Можно, конечно, предположить некоего искушённого юзера (кодера), прошаренного такого, которому вынь и положи работу с фрагментами файла. но, выдать ему такую тулзу и пусть (падёт ниц) будет рад.
Про сущность рам диска я то же примерно догадываюсь - для того, чтобы быстрее и нагляднее работать с образами дисков. Видимо для этого и система умеет выдать юзеру память, которая уже занята под рам диск. Конечно, так быстрее дописать данные в файл, который сидит в памяти (в рам диске). но, это не совсем корректно. Опять-таки - вспоминаем определение и абстракцию. Система явно это нарушает. В Estex рам диски как отдельная сущность существует ТОЛЬКО в рамках драйвера под саму дос и на уровне биоса (про биос мы ничего не говорили, а говорили только про дос). Сама дос про рамдиск ничего не знает (и знать не хочет). И значит кога я хочу дописать в файл который уже сидит в рам диске, то я просто пишу как в обычный файл, без всяких заморочек. и лично я в рамках Estex рам дисками не пользуюсь вообще. только когда дело идёт к включению трдоса и режима "пня", тогда запускаю spectrum.exe который умеет монтировать трд образы, а в трдосе он уже примонтирован на А. Есть "слэшь" команды (в трдосе) для ручного монтирования образов с винта.
Т.е. я ещё раз повторюсь - не нужно заставлять юзера "потеть". Всё должно быть максимально прозрачно. Без выдачи лишней нагрузочной информации (а в тазисе эта нагрузка велика).
Представь себе - систему пилят из расчёта 48кб минимум и до... фиг знает каких размеров. Нагромождают ядро просто всем, ну чтобы на всякий пожарный. Сколько, кстати, сейчас там весит ядро? is_dos.rom 16кб (исходя из того файла, что я в образе вижу) и второй ещё на 14кб. нормально так. На самом деле можно сократить размер ядра в двое и ещё в производительности прибавить. Да, совместимость с классиком нас (или вас) покинет. Печально, но факт ещё и то, что при наличии всех (или почти всех) утилит, их придётся пересобрать под новое, вот такое нормальное ядро. Самое интересное тут то, что половина этих утилит просто станет не нужной и переносить их не будет иметь смысла. И скорей всего, это будет уж ене is-dos based система, это будет уже действительно !новая! система. Жаль только, что никто за это не возьмётся.
SoftLight
27.08.2019, 11:27
У меня вопрос по развитию системы. Я правильно понимаю, что исходников классической iS-DOS так и не удалось достать? То-есть TASiS создавалась и дописывалась путем декомпилляции существующего дистриба iS-DOS? Какой лицензионный статус TASiS сейчас? Это бесплатное ПО, но не планируется ли его сделать свободным? Возможно, имело бы смысл, создать репозиторий на github и предложить сообществу развивать систему всем вместе, подобно другим хорошим примерам, типа Linux? А NedoPC выступала бы координатором всех работ и знаималась бы сборкой релизов. Может быть, тогда и критики iS-DOS смогли бы внести вклад и сделать систему лучше.
Для начала можно с каждой версией TASiS выкладывать отдельно архив с её исходниками и кратким описанием по их сборке.
Error404
27.08.2019, 13:07
Для начала можно с каждой версией TASiS выкладывать отдельно архив с её исходниками и кратким описанием по их сборке.
КМК, для таких вещей лучше использовать публичные SVC - например GIT(hub/lab).
КМК, для таких вещей лучше использовать публичные SVC - например GIT(hub/lab).
Ничто не мешает делать и то и другое :)
Хотя, даже наверняка, еще не все программы переведены в исходники
Максагор
28.08.2019, 05:25
в общем и целом понятно. кроме момента с железной zxevo - уже несколько лет как существует рабочая версия UnrealSpeccy в котором весьма достоверно реализована эмуляция бейзконфы. в часности, текстмод, ИДЕ, память. Т.е. дожидаться железки было не обязательно и накидать (на вентилятор) минималку для включения поддержки эво, предположительно можно было.
Ну, скажем так, я же не зря упомянул, что у меня были большие жизненные трудности - у меня на протяжении ряда дет не было возможности регулярно занимться спектрумом, в т.ч. на эмуляторе. Пользоваться-то эмулятором я мог. Но для программирования нужно системное вникание в задачу, изучение материалов, выделение личного времени. Всего этого не хватало. Зайди ко мне на сайт АТМ, посчитай, сколько обновлений в ленте приходится на каждый год. Если в начале нулевых это было 2-3 десятка обновлений в год, то с конца нулевых 0-2. И только в последние годы пошел рост. Это все из-за этого. Я не из тех, которым просто в какой-то момент надоел спектрум, и я вернулся только потом на волне ностальгии. Я со спектрума никогда не уходил. Просто не мог системно им заниматься.
Ну а эмулятор как раз в этом плане очень пригодился, особенно при отлове багов.
ты же не хочешь сказать, что весь код пишешь на реале и прям в Тазисе (в is-asm`е)?
Не весь, но 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 и Спринтер.
У меня вопрос по развитию системы. Я правильно понимаю, что исходников классической iS-DOS так и не удалось достать? То-есть TASiS создавалась и дописывалась путем декомпилляции существующего дистриба iS-DOS?
Ядром (именно ядром) занимался не я. Это делал другой человек. И да, что-то он декомпилировал, потому ему какие-то исходники удалось раздобыть. Но пока их держит при себе и не хочет неконтролируемо пускать. Тем более, что это не полная декомпиляция системы. Там не так уж много надо было менять - в основном менять константы ширины окон панелей, низовые процедуры "рисования рамок окон на экране" (заменить оные на работу с текстовой консолью), заменить драйвер вывода символов на вывод их на текстовый экран. И уже впоследствии добавлено было несколько новых вызовов по работе с палитрой АТМ как с атрибутом системы и страничный менеджер. Т.е. глобальной переделки ядра не было. По факту - было несколько заплаток в неизменяемой и динамичной части ядра.
Само ядро (именно ядро) развивать в этом виде за одним исключением не надо. исключение - готовая по сути доработка, позволяющая помимо существующей "неизменяемой" библиотеки по нулевым адресам подсоединять и другие "пользовательские" библиотеки, расширяющие известные функции и вводящие свои. Это версия TASiS v6.00 (текущая опубликованная - 5.41) - вот написание таких библиотек расширения (без изменения базовой системы) - было бы интересно в будущем.
Какой лицензионный статус TASiS сейчас? Это бесплатное ПО, но не планируется ли его сделать свободным? Возможно, имело бы смысл, создать репозиторий на github и предложить сообществу развивать систему всем вместе, подобно другим хорошим примерам, типа Linux? А NedoPC выступала бы координатором всех работ и занималась бы сборкой релизов. Может быть, тогда и критики iS-DOS смогли бы внести вклад и сделать систему лучше.
Конечно TASiS бесплатная система. Делать ее свободной - это надо согласовывать с автором. Скорее всего будет так:
Пока "версию 6" я не публиковал, ибо идет "доводка до ума" - это будет последняя доработка собственно ядра, а дальше можно и на гитхам разработчикам. Само ядро будет неизменным как "база" и гарантия от "расползания стандартов". А вот написание подключаемых библиотек расширений - это уже интереснейшая и занятнейшая вещь - к ней было бы неплохо подключить разрабов.
Ну и просто написание прикладного ПО. В принципе, для последнего уже сейчас можно что-то подобное сделать. Только я этим никогда не занимался. Вот, при условии, что нет (у меня действительно нет) полных исходников системы и задача кардинальной переработки ядра ПОКА(!) не стоит, что и как надо размещать на гитхабе, чтобы заинтересовать людей и привлечь к работе на прикладным ПО? Потому что у меня есть задачи и предложения насчет проектов. У кого есть опыт создания таких репозиториев, помогите.
Для начала можно с каждой версией TASiS выкладывать отдельно архив с её исходниками и кратким описанием по их сборке.
Разве что набор исходников драйверов разных типов и мануалы о том, что это, какова стандартная структура драйверов и резидентных файлов и проч.
Ничто не мешает делать и то и другое
Хотя, даже наверняка, еще не все программы переведены в исходники
Конечно. В свое время "Искра-Софт" даже продавала исходники отдельных утилит, какие-то просто прилагала к дистрибутиву ассемблера (и часть тех и тех исходников удалось и до сих пор удается раздобывать). Но каких-то исходников у них просто не было, так как какие-то программы просто им присылали для включения в дистрибутив без исходников сторонние авторы, которых уже не найдешь и т.д. Но сама по себе работа в этом направлении интересная.
Ну, скажем так, я же не зря упомянул, что у меня были большие жизненные трудности
Мой косяк - я не точно выразился. я говорил про период, когда ты уже вернулся к деятельности на Спектруме и АТМ в том числе.
...означает просто ЗАЩИТУ ОТ СЕГМЕНТИРОВАНИЯ
яяясненька...
Загрузчик, который грузится процедурами ПЗУ, когда еще нет никакой системы вокруг - длиной несколько сотен байт.
ммм. интересно, сколько места выделено на дискете и винте под размещение загрузочной записи (загрузчика)? объясняю:
Прямо сейчас у Спринтера загрузчик занимает места примерно 2.4 килобайта. БИОС (оно же ПЗУ) загружает в озу только первые 512 байт. в этих 512 байтах есть дозагрузка остальной части загрузчика. при этом, загрузчик так же не выделяет различия между сменным дискетой и винтом, хотя точно знает с какого диска (логически) производится загрузка. Поскольку тут ФС - FAT, то между первым разделом и mbr существует довольно не маленькое пространство, где и можно расположить загрузчик. поэтому этот загрузчик сам находит в корне диска нужный файл (system.dos), но загружает его согласно цепочке его данных в FAT. Поэтому системный файл может быть так же фрагментирован. От сюда мог бы возникнуть вопрос, даже два:
1. почему к системному файлу (к ядру) так же не применяется "таблица" блоков (на случай фрагментированности)?
2. Почему бы не выделить на дискете и винте лишний "пяток" секторов для хорошего и надёжного загрузчика, который был бы поумнее, чем текущий?
опустимся до нижнего уровня ФС
и вот тут я бы сразу задал третий вопрос: почему бы не переместить все описатели, по аналогии с ФАТом, куда то в начало диска, перед корнем? Но, вопрос отпал сам по себе благодаря:
...is-dos.rom - т.н. "неизменяемая" часть ядра...
Ядром (именно ядром) занимался не я. Это делал другой человек. И да, что-то он декомпилировал, потому ему какие-то исходники удалось раздобыть
таким образом, внести существенные правки в ядро системы, не нарушая договорённостей и не применяя дизасмов, не получится (если я верно понимаю). И на сам дизасм придётся потратить много времени. Проще с нуля всё написать... А переписывать там можно много чего.
Error404
29.08.2019, 15:18
Дурная практика писать что-то между первым разделом и МБР, т.к. следом поверх вашей писанины туда ещё кто-то такой же хитрый запишет. Не говоря уже о том, что не запрещено создать на этом пустом месте раздел.
- - - Добавлено - - -
Или начать первый раздел сразу вслед за МБР.
Что описал структурами (в данном случае записями таблицы разделов) - за то уверен. Остальное ненадежно
Error404, когда изобретаешь свой какой-то стандарт или просто не знаешь других, тогда конечно. не надёжно. А если пользуешься уже чем-то устоявшимся, тогда проблем не возникает. никакая мс-дос или винда, линукс, юникс или даже новел - не испортят пространство между разделом и мбр. даже фдиск под какой нить p112 или мсх дос такого не сделают. Если только самому не указать, что туда нужно что-то записать. Всякие виндовсы или фдиск под мс дос тем более не могут размещать раздел следующим сектором после мбр потому, что сами пишут в это пространство свои загрузчики (и не они одни, кстати)! поэтому, это работает и это надёжно. например, винХР и вин 7 размещают первый раздел на 128м секторе. 10ка смещает первый раздел на 2048й сектор. и то это происходит только тогда, когда МБР пустая. Если там уже есть запись. то даже после удаления винда поставит на старое место новый раздел. только после удаления всего мбр передвинет раздел по своему. поэтому, если учесть. что (например) я таскаю файлы именно с ПЦ, то проблем описанных тобой за последние лет 10 (на спринтере, а до этого на профи) у меня не возникало.
Error404
29.08.2019, 17:23
Error404, когда изобретаешь свой какой-то стандарт или просто не знаешь других, тогда конечно. не надёжно. А если пользуешься уже чем-то устоявшимся, тогда проблем не возникает. никакая мс-дос или винда, линукс, юникс или даже новел - не испортят пространство между разделом и мбр. даже фдиск под какой нить p112 или мсх дос такого не сделают. Если только самому не указать, что туда нужно что-то записать. Всякие виндовсы или фдиск под мс дос тем более не могут размещать раздел следующим сектором после мбр потому, что сами пишут в это пространство свои загрузчики (и не они одни, кстати)! поэтому, это работает и это надёжно. например, винХР и вин 7 размещают первый раздел на 128м секторе. 10ка смещает первый раздел на 2048й сектор. и то это происходит только тогда, когда МБР пустая. Если там уже есть запись. то даже после удаления винда поставит на старое место новый раздел. только после удаления всего мбр передвинет раздел по своему. поэтому, если учесть. что (например) я таскаю файлы именно с ПЦ, то проблем описанных тобой за последние лет 10 (на спринтере, а до этого на профи) у меня не возникало.
Хоть это и пошло, ссылаться на Википедию, но все же
Стандартизация MBR
Утверждённого стандарта на структуру MBR не существует, однако, есть «сложившиеся традиции», которых придерживаются большинство MBR от разных производителей.
что другими словами описывает ровно то, о чем я говорил постом ранее.
Ничто не мешало тем шибко умным производителям, кто использует "межсекторное пространство" бггг между разделами в MBR, добавить в MBR описатель, аналогичный DPB CP/M как делалось за 10 лет до того - десяток байт в MBR нашелся бы (тем более раз уж загрузчик вынесен). Даже именитым производителям религия не помешала завести в FAT-e структуры, читая которые не надо сочинять отсебятины как с МBR. Раз они этого не сделали, значит считали решение временным, а его похеривание- несущественным. Туда им и дорога.
- - - Добавлено - - -
И кстати, в стандарте GPT (потребовалось ждать до следующего века, чтобы понять очевидное) так и сделано - в начале структуры, заголовки, описывающие размещение всех данных, потом уже данные. Всё по полочкам. И там по-прежнему (для обратной совместимости) есть MBR, в котором разделу уже "стандартно" разрешено начинаться с сектора с LBA=1.
Ничто не мешало тем шибко умным производителям
в "до МБРную" эпоху туда шлёпать мог кто угодно и что угодно. Но, уже в наше время появились всякие Скорпионы, ис-дос/тазис, профинские cbios5.30 которые не знали или просто игнорировали МБР, а потому и писали туда свободно. Сейчас, когда у 95% "ретрохоббистов" файлики хранятся на ПЦ, можно не переживать за проблему "межсекторного" бгг пространства. Более того, когда я писал первый fdisk, я и тогдашний винт и потом уже CF карту куда только не таскал - no problems!. Более того - я под семёркой и 10кой полностью убивал все разделы, пересоздавал их там же и БАЦ - это самое пространство не затрагивалось совершенно (загрузчик не страдал). Поэтому совершенно точно - проблема эта высосана из пальца.
И кстати, в стандарте GPT
он нас не интересует, поэтому опустим его.
Error404
29.08.2019, 17:53
в "до МБРную" эпоху туда шлёпать мог кто угодно и что угодно. Но, уже в наше время появились всякие Скорпионы, ис-дос/тазис, профинские cbios5.30 которые не знали или просто игнорировали МБР, а потому и писали туда свободно. Сейчас, когда у 95% "ретрохоббистов" файлики хранятся на ПЦ, можно не переживать за проблему "межсекторного" бгг пространства. Более того, когда я писал первый fdisk, я и тогдашний винт и потом уже CF карту куда только не таскал - no problems!. Более того - я под семёркой и 10кой полностью убивал все разделы, пересоздавал их там же и БАЦ - это самое пространство не затрагивалось совершенно (загрузчик не страдал). Поэтому совершенно точно - проблема эта высосана из пальца.
он нас не интересует, поэтому опустим его.
Я просто к тому веду разговор, что совершенно ни к чему повторять чужую когда-то на скорую руку сделанную глупость. Если вы сейчас заново проектируете какое-то размещение данных, до размещайте всё это в разделе, а не за его пределами. В своем же собственном разделе уже можно творить что угодно - хоть завести там еще один описатель (нo завести! а не вот это вот {неназванные «сложившиеся традиции», которых придерживаются}) и в нем описать более мелкое деление раздела на разнотипные кусочки.
- - - Добавлено - - -
Что до винды, то она прекрасно обрабатывает разделы сделанные с любого LBA, не ругается. Что о чем-то говорит. Сама создает с отступом, это да.
Я просто к тому веду разговор, что совершенно ни к чему повторять чужую когда-то на скорую руку сделанную глупость. Если вы сейчас заново проектируете какое-то размещение данных, до размещайте всё это в разделе, а не за его пределами. В своем же собственном разделе уже можно творить что угодно - хоть завести там еще один описатель (нo завести! а не вот это вот {неназванные «сложившиеся традиции», которых придерживаются}) и в нем описать более мелкое деление раздела на разнотипные кусочки.
- - - Добавлено - - -
Что до винды, то она прекрасно обрабатывает разделы сделанные с любого LBA, не ругается. Что о чем-то говорит. Сама создает с отступом, это да.
глупость или нет - но даже современные компы следуют этой "глупости" и читают сектор lba=1, если это нужно. Спринтер так же читает этот сектор для stage1 загрузчика. не вижу никаких проблем. напоминаю - за всё время существования Спринтера у меня, эта область не страдала как либо. можно поспрашивать у других владельцев (думаю результат будет тот же).
Error404
29.08.2019, 18:25
Одно дело не страдало, и совсем другое проектировать правильно, по красоте.
- - - Добавлено - - -
Ладно, я сказал, вы услышали, а как будете делать - дело хозяйское.
Error404, на дворе 2019й год и всё ровно выпускаются по сей день материнки с поддержкой именно этого "стандарта", по сей день релизятся ОСи с поддержкой этого "стандарта". может быть, когда-нибудь...
самое главное то. что твой вариант имеет право на жизнь и имеет свои плюсы. win10 выделяет около 400метров под подобный раздел (скрытый). но он так же стартует с 2048го сектора. на моём компе сектор lba=1 содержит запись EFI (мать asrock AB350 Pro4). При этом мать поддерживает Legacy boot mode. Но, у твоего метода есть и недостатки:
1. Придя с таким винтом на системы, которые игнорят mbr ты так же рискуешь потерять и загрузочный раздел и саму mbr.
2. нужно потратить 1 первичную запись из 4х.
учитывая всё это - проблемы как таковой нет.
Powered by vBulletin® Version 4.2.5 Copyright © 2024 vBulletin Solutions, Inc. All rights reserved. Перевод: zCarot