Тема >ОС< ---------------------------------------- В ранней юности мышцы своих челюстей Я развил изучением права, И так часто я спорил с женою своей, Что жевать научился на славу! /Льюис Кэррол/ Редактор: Решились мы все-таки на ор- ганизацию специального раздела для обсу- ждения темы, которая, несмотря на смелые заявления некоторых личностей,тем не ме- нее очень волнует спектрумистов. В этом разделе будут помещаться различнейшие заметки, суждения, примеры, дискуссии, комментарии, и т.д., касающиеся реализа- ции на Спектруме новой операционной сис- темы. Поэтому обращаюсь ко всем небезра- зличным - ПИШИТЕ!!! Первая статья в данном разделе - размышления Владислава Семченко из г.Харькова о реализации т.н. ZerOS. Предоставляем ему слово: - - - ZerOS ---------------------------------------- Владислав Семченко Поскольку адресное пространство памя- ти Z80 ограничено 16-ю разрядами или бЧКб, то заполнение этого минимума еще и OS'ью крайне нежелательно с точки зрения программиста на ассемблере. По моему скромному мнению именно проблема нехват- ки памяти и является причиной, по кото- рой на Speccy не прижилась ни одна из ОSей, предложенных в свое время програм- мистами. Конечно можно возразить, что на Speccy можно установить 128Кб и более, но не следует забывать, что это будет отображаемая память в отличие от бЧКб памяти прямого доступа. Иначе говоря, у процессора нет средств эффективного обращения к памяти свыше бЧКб. Доступ к остальному объему производится через механизм подмены страниц памяти, то есть - через очень быстрое блочное устройст- во. Линейное адресное пространство свыше бЧКб, которое имеется у Z380 и eZ80, не в счет, поскольку пока базовым процессо- ром Speccy является только Z80. Описываемая ниже идея позволяет отдать в распоряжение задачи пользователя прак- тически все бЧКб адресного пространства памяти процессора, и при этом достаточно комфортно разместить OS. Итак, к сути идеи. Для простоты изло- жения материала считаем, что компьютер содержит две области памяти, назовем их полями (field), объемом по бЧКб каждая. Каждое из полей в равной степени принад- лежит процессору, располагается во всем его адресном пространстве и не пересека- ется со своим дублером. Эти две области памяти располагаются как бы на двух сто- ронах одной монеты никогда не встречаясь друг с другом. Последнее утверждение не совсем верно, но об этом чуть ниже. Одно из полей закреплено за ОSью, а второе за задачей/задачами пользователя. Система взаимоотношения полей напоми- нает механизм подмены страниц памяти, но во-первых производится замена не 1бКб страницы, а сразу всех бЧКб, во-вторых переключение полей осуществляется не че- рез порт, а через команду проца RST 0, которая почти никогда не используется. Такое решение позволяет упростить и ускорить механизм обмена полей, а в дальнейшем избавит от головной боли при переходе на Z380 или eZ80. Как известно, по команде RST 0 и по RESET (а также по TRAP в Z380 и eZ80) процессор производит выборку команды с адреса #0000, устанавливая все разряды шины адреса в "0". Это свойство мы ис- пользуем для управления работой триггера переключения полей. А теперь настало время объяснить - как это все работает на практике. Предполо- жим, что процессор выполняет программу, находясь в поле field0. Встречая команду RST 0 процессор кладет содержимое регис- тра РС на вершину стека и переходит к выполнению команд, начиная с адреса #0000. В тот момент, когда все разряды шины адреса устанавливаются в "0", со- провождаемые активными сигналами MREQ, RD и М1, происходит переключение тригге- ра и подмена поля field0 на field1. При этом процессор продолжит выполнение про- граммы, находясь уже в поле field1. Возврат в поле field0 также производится по команде RST 0 (см.рис.). +->#0000+-------+ +->#0000+-------+ | |field 0| | |field 1| | | |-+ | |----+ | +-------+ +-------+ | +--------------------------------------+ Основная проблема при переключении по- лей - сохранение и запись содержимого регистра указателя вершины стека. Дело в том, что производя обмен полей мы теряем стек! Каждое поле будет вынуждено иметь свой стек. Кроме того, из этого следует и то, что передача параметров через стек также оказывается невозможной - парамет- ры необходимо передавать в регистрах. Процедура обслуживания стека может иметь примерно такой вид: 0000 LD (nn),SP ;сохранение SP ;"старого" поля 0003 LD SP,(mm) ;восстановление SP ;"нового" поля 0006 RET ;переход к под- ;программе Данный фрагмент должен присутствовать в начале обоих полей. Это позволит рабо- тать OSu и задаче пользователя дополняя друг друга. Важно только чтобы OSb перед окончанием своей работы кидала на свой стек адрес обработчика программных пре- рываний и только потом передавала управ- ление задаче пользователя. Если Вас та- кой вариант не устраивает, то в поле OSu можно разместить такую процедуру обслу- живания стека: 0000 LD (nn),SP ;сохранение SP ;"старого" поля 0003 LD SP,(mm) ;восстановление SP ;"нового" поля 0006 JR 0008 ; 0008 .......... ;обработчик преры- ;ваний Как уже было сказано, поля field 0 и field1 независимы друг от друга и в при- нципе не должны пересекаться, но абсолю- тная ортогональность полей невозможна. Дело в том, что поле OSu должно иметь доступ к полю задачи ну хотя бы с целью установки процедуры обслуживания стека, не говоря уже о том,что все процедуры по загрузке/выгрузке массивов памяти поля задачи пользователя, а также выполнению ряда других задач, должна выполнять OSb из своего поля. Для программистов, которые пожелают воспользоваться данной идеей и быть мо- жет напишут OSb для Spectruma, хотелось бы порекомендовать придерживаться следу- ющего назначения при использовании реги- стров при передаче параметров, которое во многом совпадает с предложенным Zi- logom для макрокоманд процессора: I - номер программного прерывания IX/IY - функция прерыания А/А' - аргумент ВС/ВС' - счетчик DE/DE' - приемник HL/HL' - передатчик F/F' - флаги РС - счетчик команд SP - указатель вершины стека R - счетчик В заключении хотелось бы сказать, что данная фишка не носит вредного атависти- ческого действия и софт написанный под нее не потребуется переделывать при пе- реходе на Z380 и eZ80. Кроме того, при переходе на новые процессоры само устро- йство автоматически исчезает! Все дело в том, что при использовании Z380 и eZ80 меняется обработчик по адресу #0000, ко- торый уже будет не только сохранять и восстаавливать значение SP,но и при каж- дом обращении по RST 0 сменять адрес пе- рехода процессора в диапазоне 1бМб. - - - Редактор: А следующий материал предос- тавил для публикации ставший в последнее время "неимоверно" плодовитым автор - KilleRam (целых две!!! статьи за неделю! Если учесть, что я одну несчастную заме- тку из него "выбивал" несколько месяцев, то это "пришествие мыслей" просто удив- ляет:)))). Статья KilleRam'а соединяет в себе не- сколько тем, непосредственно связанных с проблемой ОС на Спектруме. Возможно не- которые темы покажутся уж больно неправ- доподобными (как и мне), но как утверж- дает сам Коля, все вполне реализуемо! - - - Почему??? ---------------------------------------- Николай Дворник /К!LleR@М/ Вы спросите:"почему статья называется "ПОЧЕМУ?!!". Отвечаю - потому что в ней я расскажу про то, что меня бесит. А на данный момент меня раздражают две вещи: 1. Отсутствие нормальной ОС на SPECCY: а) отсутствие многозадачности; б) неудачно организованое дисковое пространство; в) закрытая архитектура; г) отсутствие развитой системы драйве- ров; 2. Проблема "SPECCY INTERNET EXPLORER". Вопрос первый --------------- Многозадачность и ОС Я уже не могу молчать, так как в ред- акцию газеты пришло огромное количество несколько некорректных откликов по пово- ду статей про ОС и реализацию многозада- чности... Если кто-то думает, что SPECCY в этом вопросе проигрывает иным платфо- рмам, то предлагаю либо прекратить чи- тать эту статью, либо ознакомиться с ни- жеприведенным текстом, где я постараюсь изложить свою позицию по этому поводу. Во-первых, я допускаю, что многозадач- ность будет и не realtime, но зато она серьезно облегчит работу на нашем ТИТА- НЕ, хотя, на системных задачах realtime просто-напросто ZARULIT!!! Как я себе это представляю: ----------------------------- 1. Идет исполнение программы: а) программа написана специальным стилем. Точнее - все на JR'ах и мы спокойно, в любой момент вре- мени кидаем ее в свободную память и продолжаем исполнение; б) прога написана стандартно, но ее длина указана с учетом стека ис- пользуемых ячеек памяти. Ясно, что при этом стек и ячейки лежат "недалеко" от основной программы. 2. Пришли прерывания. Ясно, что не IM2, а специальные (например, "при- ручим" NMI, или контроллер прерыва- ний, что-то вроде IM2, но с возмож- ностью задания временных интерва- лов) идем на обработчик, ДИСПЕТЧЕР ЗАДАЧ, он программу останавливает, сохраняет РС в таблицу (RELOCATION TABLE, о формате позднее), длина в ней уже записана изначально, запи- сывает в какой банк она будет рез- мещена (разбивать MEMORY на банки по 1бкб или блоки переменной длины (256-16384Ь - еще не решено), в ка- ком банке она должна исполняться и с какого адреса должна размещаться записано изначально. При переключе- нии между задачами текущая приоста- навливается по вышеуказанной схеме, а та, на которую переключились, в соответствии с RT перебрасывается и запускается с адреса последнего ос- танова. 3. Весь процесс повторяется занаво. Задачи не могут пересекаться областями данных, совместно можно использовать буфер и экран:), все это контролирует- ся ДИСПЕТЧЕРОМ и СИСТЕМНЫМ МОНИТОРОМ. Хочу всем "несогласным" сказать, что это все не чес - все написано и проверено, работает, как говорит VNN - "чикы-пы- ки!". Вопрос второй --------------- SPECCY INTERNET EXPLORER Вы, наверное, скажете, что это бред и от части будете правы (поймете почему). Я хочу заметить, это один из проектов над которыми я работаю. На данный момент я изучаю по-немногу ТСР/IP-протоколы (уж больно их плохо расписали на CODENET.RU). Я не предлагаю сделать копию mustdie' евского. Напротив - я предлагаю отка- заться от HTML, JAVA, FLASH (хотя со временем HTML можна зафигачить), и соз- дать свой формат гипертекста, основанно- го на управляющих кодах (по типу неско- лько дополненного формата текста, кото- рый ТЫ сейчас читаешь) с поддержкой за- качки и т.д. Вы спросите - почему INTERNET, а не FIDO, ZX-NET и т.д.? Да потому что они не такие глобальные и организация в них WEB-структуры будет затруднительна. Как вы уже поняли I-NET в описанной мной системы используется как поисковик и никто не сможет просматривать SPECCY- сайты на других платформах (они ж тупые уроды:)). Вы скажете, что Z80 не потянет скорости I-NET'а? Решение такое: ставим DMA и модем с АТМ'а (тот, что сделан как ЦАП-АЦП) и получаем такие скорости, что даже ZyXEL Prestige DeLUXE будет со- сать:), нам-то всего-то надо текст в спец.формате перетянуть с сервака, а Z80 его обработает, а файл закачать - вообще ерунда!!! Главная проблема: создать свой сервак (идеал - LINUX) и размещать на нем стра- ницы за небольшую плату. Почему за плату вы наверное поняли. Почему не на халявных серваках? Да по- тому что они размещают рекламу на твоей странице, а в таком формате страницы это не реально. - - - Редактор: Я нарочно не комментирую статью KilleRam'а, хотя у меня прямо-та- ки язык чешется:)... Хочу чтобы вы, чи- татели, сами высказали свое мнение обо всем вышесказанном. И последнее, что я хотел сделать - это произвести небольшой обзор писем, пришедших в редакцию, касающихся ОС и многозадачности. Одним из первых по этому поводу напи- сал Михальченков Дмитрий: МД:"1. На счет статьи о ОСке. Дело в том, что убить БасикЧ8 в пользу ОСи не удастся! Да действительно басик уже из- жил себя, на нем сейчас практически нет программ, но... Когда я начинал кодить, то обильно юзал подпрограммки из ПЗУ ба- сика, а вы не такие были? И что мы полу- чим, если грохнем его? Получим более 50% нерабочего софта..." DWT: Скажу даже больше - не пойдут все 90% программ! Интересно, где я пред- лагал убивать BASIC48?!! Я всего лишь писал о том, чем служит BASIC48 совреме- нному (подчеркиваю - СОВРЕМЕННОМУ) Спек- труму. И, повторюсь, он служит запускал- кой программ в машинном коде. Но идти на такую радикальную меру, как устранение BASIC48 - это более чем глупо и недаль- новидно. Ведь это породит не только лиш- ний, извиняюсь, геморрой (придется хотя бы основные системки переделывать под нужды новой ОС), но и тотальную несовме- стимость - что вызовет полную апатию к новой ОС у пользователя. МД:"Есть два выхода: 1) Писать так, чтоб все процедуры оста- лись на своих местах... - маразм! Это просто адское мучение! А выигрыш все од- но получится нулевой, практически. Такая история была уже с ПЗУ TR-DOS для Бай- тов. У нормальных Байтов ТР-ДОСи нет, они поставлены на СР/М, да и порты на контроллере совсем другие - так что просто так ПЗУ ТРДОС не поставишь... Что делать? Находчивые спектрумисты ухищри- лись и написали новую ПЗУ ТР_ДОС, где все адреса портов переводятся из станда- ртных для ТРДОС под адреса своего конт- роллера. При этом заработала лишь 70-80% из всего софта, что ни делай, а предска- зывать трудно..." DWT: А по сему - BASIC48 оставим в полном покое! Мы не в коем случае не должны терять совместимость с программа- ми, написанными под TRDOS&BASIC48! МД:"2) Не трогать ПЗУ БейсикЧ8, а посмотреть в сторону ПЗУ Б128..." DWT: Именно это я и предлагаю! МД:"...либо придумать что-то ориги- нальное. Ведь нормальную ОСь в 16к не заткнешь, по любому придется дрова гру- зить, а лучше всего оставить в ПЗУ толь- ко универсальные дрова, тест компа, ка- кой-нибудь дебагер-монитор и загрузчик ОСи..." DWT: Можно и так. А лично я считаю, что в ПЗУ должны находиться только важ- нейшие и неменяющиеся со временем проце- дуры (допустим, обращение с дисководом, драйвер клавиатуры, и другое), а также "механизм" обращения к ресурсам системы, также желательно независимый от "манев- ров времени". Все остальное - на внешних накопителях либо на ROM-диске. МД:"...Мне кажется второй способ бу- дет выгоднее. Что мы получим прописав ОСь в ПЗУ - очередную ТРДОС или хуже то- го - бейсикЧ8-2! Я не любитель ИС-ДОСа, но она отличалась особой универсаль- ностью уже тем, что не зависела от ПЗУ, не считая hdd версии, но и там был толь- ко загрузчик, который можно было заме- нить загрузкой с дискеты... Для начинаю- щих ПЗУ бейсика - это важнейшая база!" DWT: Нет, не получим бейсикЧ8-2. Хотя бы из-за того, что сейчас цели несколько другие. Да и средства их достижения (технологии кода) тоже несколько выше. Следующее, довольно интересное и кон- структивное письмо прислал Дмитрий Те- рентьев (DEMON/DPC): ДТ:"...Меня как и всех волнует судь- ба всеми нами любимого Speccy, поэтому я вам и пишу. Давно стало всем понятно, что на одном тр-досе далеко не уедешь, прогресс ид т впер д, а мы стоим на мес- те (мы - это спектрумисты), точнее, на фронте операционных систем подвижек нет. Вот этот-то вопрос меня больше всего и волнует. Медленно, но уверенно растут аппаратные возможности нашего Speccy. Память метр и больше, кмос часы, звуко- вые карты (General и DMA USC), аппарат- ный мультиколор и многое другое. Да только тр-дос с флоповодами на 5 и 3.5 дюйма, предел которой 800 кило, то есть менее, чем 1 мегабайт, что согласитесь, не есть хорошо..." DWT: Тут Дмитрий затронул весьма ин- тересную и очень спорную тему. Проблема "роста железа без роста программных тех- нологий" на мой взгляд является одной из самых острых. И это касается не только Спектрума. Вернее даже Спектрума в мень- шей степени. Ведь он смог продемонстри- ровать очень и очень многое как раз не развиваясь в техническом плане. Имея в своем арсенале оригинальный экран 256х192, быстродействие 3.Sмгц и память в 128кб наши программисты смогли выжать из Спектрума казалось бы просто не- вероятные вещи. Что касается других платформ (РС например), то "у них" рост "железячных технологий" всегда опережал рост технологий программирования (далее ТП). Я боюсь ошибиться, но по-моему эти самые ТП переживают "обратный процесс", то есть по-просту - деградируют. "Ихним" производителям легче (и, вероятно, де- шевле) увеличить тактовую частоту и па- мять, нежели вылизать программный код. То есть, если бы "потолком" "у них" на протяжении допустим 7-8 лет был бы Pentium-100 с 8 мегабайтами ОЗУ и увели- чивать эти показатели было бы ой-как до- рого и бесперспективно, то ТП значитель- но выросли бы на несколько лет. Ведь "выше крыши" не полезешь, а по сему просто пришлось бы искать какие-то пути оптимизаций. Что касается Спектрума, то у нас все с точностью до наоборот - в плане ТП развитие если не стопроцентное, то уж точно больше, чем пятидесятипро- центное. Следовательно, пора наращивать железо. Но внутренняя организация Спек- трума, его схематическое решение, а так- же особенности, в которых он появился на территории современного СНГ не позволяют серьезно и, что главное, безглючно на- растить его технические характеристики. Но тем не менее, память, звук и некото- рые другие характеристики удалось более или менее успешно нарастить. Однако, стала актуальна проблема стандартизации. ОС Спектрума не предусматривала дальней- шего "апгрейда железа" и тем более в та- ких "особенных" условиях как у нас - только стандартов расширенной памяти с десяток! Из которых как минимум один (Pentagon-1024) обнаружить невозможно, если только не знаешь, что этот мегабайт у тебя есть (из-за "защелки 48"). Вывод? Нужна новая ОС и она была нужна еще лет шесть назад!.. ДТ:"...Вывод: нужна новая операцион- ная система! И ОС которая будет обслужи- вать, как дисковые накопители (FDD, HDD, CD-ROM), так и память компьютера, задача программистов сразу упростится, им не надо будет ломать голову над тем какие порты расширения памяти на том или ином компе и как определить сколько там кило- байт, ОС предоставит эти сведения ему (конечно при наличии драйвера)..." DWT: Как мне кажется, сведения о компьютере должны быть сформулированы (сконфигурированы) самим пользователем при начальной инициализации ОС (допус- тим, что эти сведения и драйвера будут прошиты либо в самой ОС, либо в ROM-дис- ке). Просто у запускаемых программ не будет возникать каких-либо вопросов по- поводу "железа", а следовательно - проб- лема стандартизации будет исчерпана. ДТ:"...Сразу решится проблема диско- вой памяти, винт на 1Г сейчас стоит не более 300р. CD-ROM - музыку послушать, и на болванках архив спектрумовских про- грамм в TRD-образах хранить. Некоторые скажут, CD - это лишнее, но CD х2, х4, х8 тоже недорого стоят, а интерфейс вс равно тот же - IDE. Теперь о файловой системе. Файловая система должна быть FAT32 (на винте, на дискетах FAT12), а тр-досовая система тоже должна поддержи- ваться (ну куда без этого), но для поль- зователя она должна быть прозрачна, то есть он может о ней и не знать, но вс должно работать..." DWT: По-поводу FAT32 и FAT12. На мой взгляд, нет смысла использовать эти структуры для Спектрума. Ему необходима несколько другая, рассчитанная, если можно так сказать на спектрумовский "ме- нталитет" система. Естественно "апгрей- дить TR-DOS" дело бесперспективное, но разработать нечто более подходящее по духу для него вполне возможно. Ведь чи- тать и "понимать" MS-DOS на Спектруме все-таки "тормозно" - там много такого, что Спектруму просто не нужно. Однако, упрощать FAT12 не следует - это будет лишь мутацией. ДТ:"...На CD-ROMax файловая система не FAT, а какая-то другая (по слухам), но я не уверен, если кто-то что-то знает, то просьба кинуть на мыло (demon_zx@fromru.сом). Впрочем все эти идеи не мои - это концепция NeOS, может кто слышал, но по- хоже этот проект заглох. ВНИМАНИЕ!!! Если этот текст читают авторы этой системы - просьба отклик- нуться или хотя бы исходники прислать, если вы не хотите этот проект продол- жать. Мораль сей басни такова: нужна новая операционная система, чтобы Спектрум жил, и участие в е создании должны при- нять все спектрумисты, не кодом - так идеей. Предлагаю в ZX-Time ввести отдельный раздел для обсуждения этого вопроса, в котором будет оттачиваться концепция ОС. Также идеи можете присылать на мой адрес: demon_zx@fromru.сом. Да и не только идеи по этому вопросу, можно про- сто так писать, хоть буду знать что не только я один остался на Спектруме. А в Курске похоже все кроме меня за- били на Спектрум :..-(, если это не так, адрес выше." DWT: Спасибо за хорошее письмо. Ну вот, пожалуй, и все на сегодня. Очень ждем писем! - - -