Последнее время, судя по различным спековским эхам, чатам, электронной прессе и пр., этот вопрос все больше и больше приобретает актуальность, несмотря на довольно еще сильную "оппозицию" т.н. "сценеров", которые считают, что Спеку достаточно и необходимо оставаться на уровне Пентагона-128 + TR-DOS... Но, в конце-концов - это личное дело каждого - наворачивать дальше свою машину новыми железными и программными примочками или нет. Вот только для того, чтобы оставаться на одном уровне, достаточно просто ничего не делать в этом направлении, а вот для дополнительных наворотов все-таки нужна единая концепция, стандарты и принципы. Поэтому этот свой опус я и посвящаю неугомонным людям (к коим я и себя причисляю), которые не оставляют идею развивать Спекки всеми возможными способами.

"Нужна ось" - раздаются со всех сторон голоса, также как еще недавно взывали - "нужен стандарт!" Но о последнем уже давно забыли - уже столько разных способов адресации не только верхней памяти, но и включения КЭШа, теневого ОЗУ и т.д., что тут остается только бессильно развести руками. И все-таки один стандарт есть - это процессор Z80 с его ситемой команд. Вот от этого и будем плясать. Но для начала задладимся вопросом - а зачем нам так уж требуется ось, да к тому же новая (так как другие есть, и неплохие)? И чем уж так не нравится оставаться с нашей "родной" TR-DOS?

Ну, насчет TR-DOS все укажут на ее негибкость и неспособность работать с другими, кроме флопа, устройствами, да и вообще... Уже из этого ясно, что необходимость новой оси возникает только в том случае, если нам нужно пользоваться не только дисководами, а, к примеру, винчестером. Причем пользоваться полноценно, то есть уметь запускать с этих устройств исполняемые файлы, а не только их хранить.

А другие оси? Среди них самое заметное место по праву занимает iS-DOS. Тут сразу, скорее всего, посыпятся голоса о том, что она устаревшая, тормозная, 48-мая и т.д.. Сразу хочу вступиться за эту систему - если использовать ее с винчестером(а мы уже говорили про необходимость выйти за рамки флопа), то совсем не тормозная, на флопе же любая серьезная система будет медленнее TR-DOS, так как только там есть такой маразм как работа с секторами напрямую, без создания логической структуры из блоков и кластеров, а то и прямое программирование контроллера применяется. Добавьте сюда еще фрагментацию файлов, прямой-последовательный доступ, и сразу станет понятным, что дело не в тормозах, а просто в примитивности TR-DOS, но эта примитивность стоит гибкости, которая очень нужна.

Насчет 48-й памяти - отчасти верно, но все же не до конца - если брать последнюю версию системы - iS-DOS Chic, то та почти все ядро располагается в теневом ОЗУ по нулевому адресу, оставляя всю обычную память программам. К тому же никто не мешает использовать всю имеющуюся верхнюю память под свои нужды, особенно при наличии винчестера, когда RAM-диск становится ненужным (а мы здесь опять-таки уже говорили о принципиальном отказе от монополии дисководов). И это делается в различном софте, например в раззиповщике. Кто-то может покритиковать "нортоновский" интерфейс, так напишите новый, графический - он лишь один из подуровней системы, и его можно заменить. Можно и не заменять, а просто добавить еще один свой, особенно в iS-DOS Chic, где памяти на это больше имеется. Но есть все-таки одно возражение против iS-DOS - народу очень хочется многозадачности, хотя бы урезанной, и совместить это с виндами - то есть иконочно-стрелочным интерфейсом.

Не скажу, что в рамках iS-DOS нельзя что-либо придумать в этом направлении, но все ж таки легче написать новую систему с нуля, чем разбираться в чужой, даже при наличии исходников (которые имеются). К тому же раздаются голоса, требующие обеспечить безболезненную работу новой системы с TR-DOSным софтом, по крайней мере с основной его частью, причем с любого носителя, так как не все можно переделать, например большинство игрушек, а отказываться от них не хочется, а в результате пользователь может так и остаться на TR-DOS, а новая ось останется в гордом одиночестве (что не раз случалось).

Что касается оконочно-стрелочного интерфейса, то такие попытки "сбацать винду на Спеке" предпринимались уже не раз. Тут огромное спасибо NUTSу за их обзор в Adenturer-13. Но, оставив в стороне факт незавершенности многих из этих проектов, надо особо отметить, что полноценными операционными системами они не являются. Прежде всего потому, что у них (например в неплохой разработке ZX-Windows) отсутствует гибкая структура работы с внешними устройствами, а зачастую они просто привязаны к дискам TR-DOS.

То есть вместо необходимой системы устройств/каналов/потоков мы имеем все те же банальные TR-DOSные дисководы ABCD. А при таком подходе, как бы круто и действительно прекрасно не была бы наворочена ось, это будет лишь надстройка над TR-DOS. А раз так, то пользователь всегда будет испытывать неустранимые для этой системы ограничения. В частности - диском в 640Кб. Вот народ хочет с винтами работать. Хорошо. Но при таком подходе это будет о-о-чень затруднительно! Например, как получиться запускать с винта TR-DOS софт, если идет жесткая привязка к его формату на флопе? А если еще сидюк подключат или новый носитель появится? Вообще, на Спеке есть, кроме TR-DOS, всего две полноценно реализованные (я говорю про принцип, а не про кривость той или иной оси - это отдельная дискуссия) системы - уже упомянутая iS-DOS и CP/M (последняя не на всех спеках).

Прежде всего их отличает то, что там возможет гибкий формат дисков - даже слово "диск" не употребляется, а говорится "устройство", управляет которым на низком уровне для каждого конкретный драйвер в соответствии с конкретной таблицей праметров - описателем, где указаны и количество дорожек/головок/секторов/логических блоков(!!!), и структура/размер каталога и т.п.. Например в CP/M в ее версии для имеющейся у меня ATM-turbo стандартный формат дискеты с CP/M(а ось еще работает и с винтом!) полностью совпадает с TR-DOS - 80 дорожек, две головки и 16 секторов по 256 байт.

Естественно, только каталог и системная область устроена по другому. Но путем подключения другого описателя я могу читать диски с CP/M от Профи (80 дорожек, две стороны, 5 секторов по 512 байт), или Роботрона, или другого компа и запускать с них программы. То есть системе все равно, какой физический формат диска (винчестера/сидюка итд), главное, чтобы на нем можно было бы разместить в определенном порядке (но тоде гибко изменяющемся по некоторым принципам) каталог. Очень похоже и в iS-DOS. В TR-DOS же описателей и в помине нет, и все жестко привязано именно к физическому формату, а логического (благодаря которому можно обеспечить гибкость) и в помине нет, не считая возможности выбирать 40/80 дорожек и одну/две стороны. И ограничивая себя рамками TR-DOS, пусть и с DirSYS, мы, практически отказываемся от полноценности системы, превращая ее лишь в еще одну, пусть и первоклассную, с кучей модулей/оверлеев но оболочку.

Например есть довольно хорошая "система" ZX-Windows 1.4 (слышал, что уже есть 1.6, но не видел, а хотел бы). Есть под нее куча программ, в том числе и игровых (адаптированы с TR-DOS). Но все равно, когда надо что-то читать, мы обращаемся куда? Правильно - к стандартной файловой системе TR-DOS, к ее вызовам. Это не ось. Это навороченная программа под TR-DOS, а утилиты под эти винды по своему принципу ничем принципиально не отличаются от плагинов к REAL-командеру. В результате круг замыкается, и мы получаем все ту же TR-DOS на гибком диске, коих у меня сотни, и я в них уже задыхаюсь, что очень обидно при наличии винта, на котором уже удобно разместились CP/M и iS-DOS.

Тут могут сказать - чего это он тут раскритиковался. А просто я восстанавливаю на этих примерах мой ход мыслей, когда рождалась моя концепция оси. Надо самим себе поставить вопрос, зачем тебе, читатель, да, именно и персонально тебе, новая операционка? Какую задачу она должна решить? Можно, конечно реализовать одну, бесспорно нужную задачу, а именно сделать спеку и TR-DOS хороший иконочный графический интерфейс и многозадачность. Что, в принципе, уже реализовано.

Но все-таки, видимо, народ подсознательно понимает всю неполноценность этих "операционных" систем, а попросту очередных бутов с модулями и плагинами, раз не собирается пересаживаться на них. У меня цель принципиально иная - необходимо написать универсальную систему, обеспечивающую гибкий доступ ко всем возможностям и ресурсам Спекки абсолютно любых, самых нестандартных клонов, возможностей как существующих, так и появящихся в будущем. А это значит, что я просто обязан выйти полностью за рамки TR-DOS. Потому что иначе это получится, как я говорил, еще одна оболочка на дискетах(!!!), и не факт, что за нее усядется массовый пользователь - ведь дисков много, их надо менять, а утилиты оси на все диски не запишешь - отсюда масса неудобств и так далее.

Но с другой стороны, ось-то написать теоретически можно. Но надо еще ее и софтом наполнить, что затруднительно. Можно, конечно, написать самые нужные утилиты (копирования/набивания текстов/просмотра и т.д..), адаптировать пару игрушек и так далее (да и не все можно адаптировать, а только самое простое - например как ты "Звездное Наследие" так просто адаптируешь, когда оно вообще работает вне файловой системы с конкретными секторами и дорожками 640Кб-диска?). Все равно Народ забьет на мою супер-пупер ось и будет по прежнему смотреть демки и играться в "Наследие" в TR-DOS. А значит просто и не начнет использовать в полную силу (или вообще не начнет) новую систему. И печальный опыт DOMEN OS, NeOS(вот еще один вариант, жалко не законченный, полноценной в моем понимании системы), ZX-WINDOWS и др. граф. оболочек тому примером.

Поэтому для того, чтобы усадить пользователя за новую ось, надо, чтобы как минимум она позволяла запускать почти любой софт TR-DOS, и без переделки (так как массово адаптировать так как когда-то софт переносился на диски с кассет уже некому), а с другой стороны позволяла бы легко работать с любыми устройствами (в частности с винтом), не обременяя пользователя дополнительными перезагрузками, привязанностью к флопу с утилитами и т.д., а также иметь возможность гибко адаптироваться к разным клонам Спекки (которые отличаются не только стандартом верхней памяти, но и, например, наличием расширенных экранов), а также к появляющимся новым устройствам и наворотам.

Чтобы это сделать, надо не просто уйти от TR-DOS, как в CP/M или iS-DOS, а выйти за ее пределы, оставив ее (TR-DOS) своей незначительной частью, с обной стороны нисколько от TR-DOS не завися, а с другой, полностью держа ее под контролем - что-то типа сессии MS-DOS в виндовском окошке на пЦ. Тогда можно будет исполнять софт написанный под новую ось и запускать, когда надо и программы TR-DOS.

Как вам понравится, например, такой вариант - на винте, рассортированные по подкаталогам лежат в хобетной упаковке или в SCL/TRD спековские стандартные файлы, а рядышком соседствуют уникальные для новой системы программы - ты запускаешь что тебе надо, и компу все равно? И именно это главное, а интерфейс - иконочный он или банальный нортоновский - это дело уже вторичное, хотя я и хочу GUI, но это уже верхний уровень системы, а он не главный. Сейчас надо с основами разобраться.

Если это будет сделано, то, получив возможность в такой оси прозрачно работать со всем софтом TR-DOS с любого устройства, в том числе и с винта, пользователь действительно пересядет за нее, а значит и начнет писать сам (а не только усилиями разработчиков) новый софт именно под новую систему. А теперь о том, как я предполагаю осуществить такой рулез.

Сначала расскажу насчет моих идей про то, как обеспечить совместимость с TR-DOS, а именно сделать две упомянутые ранее вещи - во-первых, сделать TR-DOS лишь частью системы, ее необязательным модулем, а во-вторых, полностью держать ее под контролем подлинной системы.

Самое первое, что надо сделать - это "отвязать" TR-DOS от флопа, то есть заставить ее, если надо, работать не с реальным диском, а эмулировать его в работе с эмуляторным образом TRD. То есть требуется перепахать ПЗУ TR-DOS. Ну и придумать, как ей, и главное куда эти TRD подсовывать незаметно для стандартного софта. Тут надо сказать, что я не первопроходец на этом пути.

Были предприняты по крайней мере две серьезные удачные попытки это сделать.

1. Компьютер KAY-1024.

В нем модифицирован TR-DOS таким образом, что при включении диска "C:"(можно назначить и другую букву) работает не с реальным диском, а с верхней памятью (самыми верхними 640 К-байтами), правда только через точку #3D13, так что всякие мультилоадеры обламываются. Это используется в iS-DOS - для нее сделаны утилиты, которые кидают в то место памяти самые обычные образы TRD, которые преспокойно могут храниться хоть на флопе (с форматом iS-DOS), хоть на винте, после чего устанавливается карта памяти, соответствующая TR-DOS, и делается самый обычный RUN "boot". Выход обратно в iS-DOS по RESET, вход в которую при наличии винта (и загрузчика iS-DOS в ПЗУ TR-DOS) занимает пару секунд.

Это уже где-то третья часть пути, задуманного мной.

2. Скорпион+SMUC(контроллер HDD, и кое чего еще, в данном случае нам не нужного).

Там под этот контроллер тоже переделана TR-DOS при одновременной поддержке этих переделок в знаменитом скорпионовском теневом мониторе. Суть этой доработки (сорри, если это тебе известно) в том, что TR-DOS научена работать не только с реальными флопами, но и с TRD-образами, располагающимися на винте. Эти образы представляют собой что-то вроде файловой системы, и разбиты на коллекции (вроде подкаталогов) по 32 диска. По кнопке MAGIC мы входим в монитор, где можем подключить к TR-DOS к любому устройству (A: B: C: D:) любой образ, или назначить реальный дисковод.

Но что самое главное - это можно делать программно, из своего софта, чем уже воспользовались, сделав плагин для RC, работающий с образами на винте как с подкаталогами. ТУт мы имеем уже отвязку TR-DOS от флопа и даже контроль за ее работой со стороны (так как работу программ можно прервать, а потом или восстановить, или выйти). Также лепту в это дело внесла и такая скорпионовская программа MagOS, которая опять-таки посредством монитора и кнопки MAGIC позволяет "замораживать" в верхней памяти, пока ее хватает, исполняющиеся программы, и переключаться между ними. TR-DOS тут ни при чем, но важен сам принцип - ведь именно по такому принципу и надо будет осуществлять контроль - надо будет иметь возможность в любой момент выйти из TR-DOS программы, и вернуться в нее, изменив настройки (например, подключив новый образ диска).

Кстати, скорпион со SMUC в этом отношении уже "железно" наворочен на 100% для того, чтобы писать вышеупомянутую ось, но тогда она будет работать только на нем, а я хочу - для всех Спектрумов. Кстати, при такой адаптации TR-DOS для работы с ней с винта даже не надо будет писать новую систему - можно использовать ту же iS-DOS также как она работает с виртуальными TRD в KAY, только надо написать спец.утилиту, так называемую Z-машину, которая и будет через теневой монитор, как MagOS контролировать исполнение TR-DOS-программ, и обеспечивать возврат в систему без нажатия RESET.

3. ATM-turbo 1,2,2+

Собственно TR-DOS здесь не дорабатывалась для работы, зато реализован так называемый "резидент", который, будучи определенным образом сохранен в верхней памяти (>128Кб) вызывается при RESET или по переходу в TR-DOS по нулевому адресу, что и использует известный HONEY-сомандер - по RESET мы не выйдем в привычное меню, а вернемся в хонюк. То же самое произойдет, если исполняемая программа сделает RST 0 в TR-DOS. Этот способ, надо использовать при организации внешнего управления процессами и вызова системы, предварительно сохраненной при запуске TR-DOS- приложения либо в верхней памяти, либо на винте.

А теперь о том, как это будет в конечном итоге выглядеть у меня. Для формата дискет/винта/прочих носителей собственно системы я предлагаю взять пЦшный FAT, так что можно будет подцепить винт от Спекки в пЦ, слить на него файлы, например скачанный с сети спековский софт, а потом юзать этот винт на Спекки. Переделкой TR-DOS я уже занялся, об этом я уже писал в десятом АБЗАЦе, хотя и изменил несколько концепцию - теперь я не собираюсь повторять скорпионовский SMUC, а буду ориентироваться на использование доработанной TR-DOS из Z-машины в любой полноценной оси (iS-DOS, CP.M или планируемой здесь). и работа идет полным ходом. Намечено два варианта ПЗУ - работающей с TRD в верхней памяти (минимум мегабайт!), и работающий с TRD на винте, через специальный буфер, выделяемый для этих нужд на жестком диске, где и создается одна или несколько виртуальных дискет.

Для контроля за процессами перерабатывается обработка MAGIC, так как обычные спековские программы используют всю карту памяти и все режимы прерывания, так что это остался единственный ресурс, которым со стороны можно оказывать на них влияние. Сама система будет прятаться на винте, и по этой кнопке будет исполняемы софт "замораживаться" и подгружаться извне из основной оси Z-машина, управляющая всем и вся. Возможно будут предусмотрены в ПЗУ вызовы отдельных функций Z-машины из программы пользователя (например - сменить образ). Это со стороны TR-DOS. Со стороны Новой системы работа Z-машины выглядит так:

Ею будут обрабатываться следующие файлы - TRD - копируется в RAM или буфер на винте (далее просто буфер) используемый переделанной ПЗУ, как виртуальный дисковод, после чего система (по крайней мере ее ядро) сохраняется на винте или в верхней памяти с настройкой подпрограммы обратного вызова. После чего - установка системных переменных TR-DOS (и соответствующей карты памяти) и RUN "boot"(если не указан специально другой файл). Выход - по описанному способу(далее так - везде).

Единственное что, при загрузке TRD подсчитывается контрольная сумма, и если она после не совпадает, то Z-машина предлагает сохранить изменения в TRD-оригинале.

SCL - очищается RAM/буфер с установкой пустого каталога TR-DOS, а затем в нужном порядке заполняется файлами и RUN "первый <B>-файл"(или специально указанный другой). Тоже подсчитывается контрольная сумма, но по отдельным файлам. Возврат аналогично.

Хобетный файл ($n) - очищается буфер, копируется файл, с подсчетом контр.суммы(если изменилась - запрос на перезапись файла), передается ему управление. Если при выходе в образе появились другие файлы запрашивается об их захобечивании на винт.

Группа хобетных файлов - сама по себе не запускается. Но создается текстовый файл (что-то вроде bat-файла в MS-DOS(такой в нашей оси тоже будет, но для Z-машины будет свой отдельный)), например *.zst(Z-code STart), где будут указан путь к каждому хобетному файлу (а они могут располагаться в разных подкаталогах или даже дисковых устройствах!), порядок из расположения в образе/буфере(или даже сразу на нескольких образах(если использовать винт, а не память, естественно) - например часть файлов пойдет на тыр-досный диск A:, а часть - на диск B:), какой файл и с какого образа/буфера запускать, где сохранять возможные новые файлы (вдруг ты запустишь таким макаром ART-STUDIO и создашь картинку!) и т. п.. Далее все как выше.

Теперь о самой системе. Для начала повторю в тезисном виде то, что должна, на мой взгляд, уметь делать система и по каким принципам она должна строиться:

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

Многозадачный - простой графический интерфейс (без динамики) все будет тормозить в зависимости от количества открытых окон
Многопрограммный - динамичный интерфейс с крутящимися иконками переключение между активными задачами так как все задачи будут по сути встраиваться в ось расширяя ее возможности (например при запуске музред - ось станет музред., в общем типа domenOs) правда есть возможность резидентов на Инте.
Монозадачный - примеров думаю не нужно.
На мой взгляд наиболее оптимальный вариант - второй, с использованием монозадачности в т.н. Safemode - при загрузке усеченого ядра с флопа, например в случае краха системы с винта. Естественно в такой псевдомногозадачности надо оставить возможность постоянно действующих фоновых задач, например музыки, но не только. Должна иметься и возможность эту псевдомногозадачность и фоновость выключать, забирая все ресурсы себе: например это нужно будет для Z-машины. необходим также и единый буфер обмена между запущенными задачами для переноса между ними текстов, рисунков и прочих данных.

Касаясь вопроса гибкости к различным наворотам, я опять вернусь к отсутствию, причем уже неустранимому, стандартов на Спекки. Есть много разных вариантов конфигурации адресного пространства, отличных от Пентагона, где страницы меняются вверху(у всех по разным стандартам), внизу ПЗУ, далее - пятая и вторая страница.

Во-первых, бывают клоны, которые позволяют включать вместо ПЗУ - нулевую страницу ОЗУ, а Скорпион - еще и восьмую. или просто есть компы с КЭШем, эмулирующим ПЗУ. Во-вторых - Профи позволяет менять страницу не только по нулевому адресу, но, вроде и по адресу #8000, а в АТМ-1 при включении нулевой страницы вместо ПЗУ, пятая страница по адресу #4000 заменяется на четвертую.

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

Сама система будет при инсталляции настраиваться на конкретное "железо" - тип клона Спекки. И в соответствии с его наворотами будет обеспечивать то или иное количество возможностей. В "навороты" машины будет входить органически связанный комплекс следующих факторов -

количество памяти
наличие/отсутствие КЭШ
возможность дополнительного (кроме как через #7FFD) конфигурирования основного адресного пространства (например возможность полностью вывести из адресного пространства экранную область или отключить ПЗУ. Идеал здесь - наличие диспетчера памяти АТМовского (2-я модель) или Спринтеровского типа)
Наличие адаптированного под винчестер или расширенную память ПЗУ TR-DOS
Наличие в этом же измененном TR-DOS "MAGIC-диспетчера"(разрабатывается) для обеспечения возврата в систему из старого тыр-дос-софта.
(как приятный довесок) - наличие расширенных экранов.
Понятно, что пользователи машин "без наворотов" могут возмутиться - типа куда это он клонит? А мы? Как это чем меньше наворотов, тем меньше функций???!!!

Я отвечу, что никого же не возмущает как на пЦ или на том же Спеке, когда какая-либо программа жалуется на нехватку памяти или не хочет работать в EGA-режиме. Так и тут - не все можно реализовать в ядре системы если часть общего адресного пространства необходимо будет отдать под невыключаемые ПЗУ и экран по адресу #4000, даже если держать систему в страницах, а в основной памяти разместить только вектора и транзитную область (а именно так и планируется сделать), да и еще при возможности щелкать страницами только по адресу #C000. Иначе так и под софт памяти будет вечно не хватать. Придется полностью перейти на оверлеи, а ведь нам еще многозадачность необходима, а значит и диспетчер задач, который должен быть в основной памяти!

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