Тема >ОС<
----------------------------------------
В ранней юности мышцы своих челюстей
Я развил изучением права,
И так часто я спорил с женою своей,
Что жевать научился на славу!
/Льюис Кэррол/
Редактор: Решились мы все-таки на ор-
ганизацию специального раздела для обсу-
ждения темы, которая, несмотря на смелые
заявления некоторых личностей,тем не ме-
нее очень волнует спектрумистов. В этом
разделе будут помещаться различнейшие
заметки, суждения, примеры, дискуссии,
комментарии, и т.д., касающиеся реализа-
ции на Спектруме новой операционной сис-
темы. Поэтому обращаюсь ко всем небезра-
зличным - ПИШИТЕ!!!
Первая статья в данном разделе -
размышления Владислава Семченко из
г.Харькова о реализации т.н. 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: Спасибо за хорошее письмо.
Ну вот, пожалуй, и все на сегодня.
Очень ждем писем!
- - -
Other articles:
