ПЭВМ АГАТ: Антология Бейсика и Дос

Я бы не стал писать этот текст, если бы не одна проблема: совместимость программ и операционных систем Агата. Вроде бы существует Бейсик, вроде бы рядом с ним есть ДОС. Есть программа, которую можно запустить командой BRUN. Но после загрузки программы в память машина зависает. И хорошо, если её можно вернуть в русло конструктивного диалога комбинацией УПР-СБР. А если нет ?

Возвращаемся к началу. Операционка есть и работает. Бейсиковские программы есть и работают. Программы, которые шли с машиной тоже есть и тоже работают. Но какая-то новая программа, которая работает на другом компе у соседей, на этом вешается. Это не сбой. Это просто разные версии Бейсика или ДОС. Причем настолько разные, что если ковырнуть внутри, то вообще друг на друга не похожи. Хотя внешне всё одинаково - и курсор и приглашение комстроки и команды. Только несколько признаков, видных вооруженным глазом, позволяют отличить одну систему от другой. Почему-то так сложилось, что базовые агатовские системы крайне немногословны. Даже сообщить номер версии им, часто, было лень.

Всё дальнейшее в этом разделе - мои художественные домыслы. Я не знаю - как было на самом деле, но предполагаю. Наверняка, тут будут ошибки, но в целом, надеюсь, угадал.

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

Бейсик

APPLESOFT II BASIC

С него всё и началось. Как известно, во времена проектирования Apple ][, микросхемы ПЗУ стоили заметно дешевле ОЗУ при том же объёме. И была такая тенденция, даже на IBM-PC, что базовое программное обеспечение не загружали с дисков или лент, а просто зашивали в ПЗУ, а ПЗУ запаивали в комп. Дискеты были не очень ёмкими, медленными, Интернета не было - даже если выпустить обновление - как пользователь его получит? А тут всё удобно - ПЗУ надежные, дешевые, да и возможности сразу включить комп и увидеть готовую к работе ОС - это даже и нынешние пользователи бы не отказались.

Поэтому в Apple ][ бейсик хранился в ПЗУ. Вместе с системным монитором. Какой либо поддержки дискет он не имел, программы хранились на магнитной ленте, на кассетнике.

Потом (а может и не потом, а почти сразу) для Apple ][ был сделан контроллер 140 кб дисковода, и желающие могли его приобрести вместе с дисководом и тем, что называлось DOS3.3. Может сначала и не 3.3, а поменьше номер, но когда проектировали Агат, была именно DOS3.3.

Что мы сейчас понимаем под ДОС ? Это такая вполне самостоятельная программа, даже набор программ, плюс некоторое ядро - вроде тоже программа, но специальным образом записанная на диск и специальным же образом компилируемая. Ядро загружается первым, потом запускается оболочка, которая ведёт диалог с пользователем. Из этой оболочки пользователь может загружать другие программы, тот же Бейсик, например.

Но в Apple ][ Бейсик уже был. В ПЗУ. И он запускался первым. Как тут выкрутится ? Как вообще сделать эту связку таким образом, чтобы Бейсик мог быть и самостоятельным и, при необходимости, взаимодействовать с ДОС ? Причем, видимо, с разными версиями ? Т.е. нужно максимально унифицировать и упростить интерфейс между этими двумя компонентами.

Сделали так: при включении системный монитор ищет в слотах расширения что нибудь, что напоминает контроллер дисковода (или вообще, любого устройства, которое хочет что-то сделать само). Если не находит - передаёт управление Бейсику и тот работает в штатном режиме.

Если находит - передаёт ему управление. Устройство загружает операционную систему и она перехватывает два (буквально - всего два) вектора, которые указывают на процедуру ввода символа и вывода символа, после чего отдаёт управление Бейсику. Для удобства эти вектора вынесены в область RAM и инициализируются системным монитором сразу при включении машины.

И всё ! Бейсик продолжает работать, не догадываясь, что в памяти сидит шпион и слушает все, что выводится на экран и вводится с клавиатуры. А операционке нужно обращать внимание ещё на один признак: находится ли Бейсик в режиме непосредственной интерпретации команд или выполняет пользовательскую программу.

Если идёт непосредственный диалог, ДОС слушает поток ввода (нажимаемые клавиши) и после нажатия Enter анализирует введенную строку. Если строка начинается с ключевого слова (их около двух десятков) - ДОС воспринимает её как команду, выполняет и очищает общесистемный буфер ввода - Бейсику достаётся пустая строка, которую он просто игнорирует. Если ключевого слова не обнаружено - ДОС тихо молчит и строка передаётся на анализ Бейсику.

Если идёт исполнение программы, ДОС слушает поток вывода (т.е. то, что программа выводит через операторы PRINT и INPUT ""). Если в потоке появляется последовательность символов #13 #4 (перевод строки и следующий за ним специальный символ) - последующие символы анализируются как команда. Единственное отличие - в случае синтаксической ошибки ДОС реагирует на это явно: SYNTAX ERROR.

Очевидно, что раз синтаксические анализаторы и ядра у ДОСа и Бейсика раздельны - то есть и отдельные списки ошибок. В том числе "SYNTAX ERROR". Но отличить ошибки Бейсика от ДОС несложно - Бейсиковский текст ошибки предваряется символом "?".

Перехватывая ввод/вывод, ДОС может не только анализировать его, но и подменять. Зачем ? Во первых - для управления Бейсиком (и собой) из файла. Получается аналог командных файлов. Во вторых - для чтения/записи пользовательских файлов данных. Причем можно с эхом, а можно и без него.

Просто и изящно ! Заметьте: ни ДОС ни Бейсик почти ничего не знают о реализации друг друга, но при загруженном ДОС пользователь может оперировать с файловой системой, в т.ч. из своих программ, и даже может записывать/считывать собственные файлы данных. Причем здесь даже не пахнет необходимостью знания Ассемблера и прочих премудростей.

Файлы в ДОС3.3 были трех типов: текстовые (которые читались/писались посимвольно, и, поэтому, довольно медленно), двоичные (адрес и длинна такого файла задавались явно в команде записи, адрес загрузки можно было задать в команде загрузки) и бейсик-программы - адрес загрузки фиксирован, длинна при записи узнаётся у Бейсика (ещё один интерфейсный узел), при чтении - возвращается Бейсику.

Для полноценной работы ДОС должна была знать ещё три вектора: точку входа для полного сброса Бейсика ($E000), точку входа аварийной остановки без сброса Бейсик-программы ($E003) и точку входа с запуском программы (после загрузки командой RUN).

Да, ещё такая мелочь: после загрузки ДОС, она самостоятельно вызывала у себя самой команду RUN HELLO (HELLO - это имя указывалось в команде форматирования дискеты, при выполнении которой ДОС записывала себя сама на свежий диск). Под именем HELLO обычно скрывалась небольшая Бейсик-программка. Она загружалась и запускалась сразу после загрузки ДОС и могла либо делать что-то полезное или запустить другую - более крупную программу. Что было удобно: вставил дискету с игрушкой, включил комп - и всё само запускается: Бейсик, ДОС, HELLO, игрушка.

Метка тома

Это не чёрная метка и не хижина дяди Тома. Это число, записанное во все поля адреса всех секторов дискеты (тома), а также в системную структуру VTOC (Volume Table Of Content - таблица содержимого тома).

По задумке Apple-овских разработчиков оно должно идентифицировать конкретную дискету среди валяющихся на столе у пользователя. Смысл в том, чтобы анализируя это число при каждом запросе данных из открытого файла, ДОС могла проверять - не сменил ли пользователь случайно дискету. Ну или не случайно. Если сменил, а программа хочет что-то прочитать из файла, находящегося (и открытого !) на другой дискете - операционка сообщает об ошибке VOLUME MISMATCH.

Задать метку тома можно при форматировании, используя необязательный ключ V: INIT HELLO,V240. По умолчанию было выбрано число 254. Т.е. при открытии файла ДОС запоминает том дискеты (беря его из VTOC), а затем отдаёт драйверу дисковода, с просьбой следить - и драйвер может опознать подмену при чтении любого участка дискеты.

Благими намерениями выстлана дорога в ад ? Что только не делали в дальнейшем отечественные разработчики с бедной меткой...

Агат-7 и официалы

Когда разрабатывался Агат, создавать новый интерпретатор и операционку было лень. А может и наоборот - очень хотелось. Но всё равно - это затраты. Решили адаптировать программное обеспечение Apple ][. Вроде ничего сложного - системный монитор подправить - он обеспечивал взаимодействие с дисплейным контроллером, который в Агате совсем не похож на эпловский. Скорректировать процедуры управления графикой в Бейсике - по той же причине. Да, и ещё мелочь такая: научить всё, что получилось, загружаться с дискеты. От Бейсика в ПЗУ решили отказаться. Учитывая тенденции того времени (Агат делался не сразу по следам прообраза, а со вполне солидной задержкой) - вполне логично.

Но возникла заковыка - как загрузить в память Бейсик ? Вроде на обычных компах это делает ДОС, но здесь ДОС сама является как бы плагином к Бейсику - использует его процедуры для работы с экраном и клавиатурой, собственной командной оболочки не имеет...

И вот здесь разработчики пошли довольно кривой дорожкой, чем и обеспечили мировые запасы проблем для последующих пользователей и программистов Агата: системный монитор оставили в маленькой ПЗУ на два Кб, команду RUN HELLO заменили на BRUN HELLO, Бейсик залили в файл HELLO, но перед ним пристегнули небольшую программку, которая ищет модуль Эмулятора ПЗУ и по частям переносит уже загруженное в память тело транслятора в соответствующие части ЭмПЗУ. Затем инициализирует некоторые структуры данных Бейсика и передаёт управление внутрь ДОС, на не очень красивый адрес, с тем, чтобы ДОС подумала, что её только что загрузили (ведь Бейсик при своей инициализации будет перебивать вектора ввода/вывода).

Во первых - ДОС приходится реинициализировать, никакого специального входа в ней для этого не предусмотрено. Перекомпиляция ДОС потребует соответствующей смены вектора в Бейсике. Вроде мелочь. Но уже начало.

Во вторых - пропала автоматически загружаемая Бейсик-программа HELLO.

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

В четвертых - в случае разрушения некоторых структур Бейсик пытается реинициализироваться, чем опять таки отключает ДОС. Выглядит это так: после очередного зависания нажатие УПР-СБР приводит к очистке экрана, появлению надписи ** Агат ** и приглашения бейсика. Все команды бейсика исполняются, но ДОСвоские признаются синтаксической ошибкой.

Но, тем не менее, это работало. Загрузка при этом выглядит так: через 5-10 секунд после включения машины надпись ** Агат ** пропадает, внизу появляется звездочка. Это - приглашение системного монитора, оно сигнализирует о том, что ДОС вроде бы загрузилась, но сразу после загрузки она вновь перехватывает управление и начинает выполнять команду BRUN HELLO. Шуршание дискеты продолжается ещё секунд 10-20, после чего дисковод замирает. 2-3 секунды ожидания - это Бейсик копирует себя из основной памяти в ЭмПЗУ. И затем - вот оно - долгожданное приглашение к диалогу.

Эта версия Бейсика (вместе с ДОС) условно называется "Бейсик-60". Цифра 60 - число блоков, занимаемых файлом HELLO - 59 блоков кода + 1 блок TSL. Около 15 Кб. ДОС - (хранится на первых трех дорожках диска) - 37 блоков - около 9 Кб. Для большей ясности я буду называть эту версию Бейсика именно так, а ДОС - ДОС3.3. Не путайте её с ДОС3.3 на Apple ][ - у них общие корни, но есть и, пока немногочисленные, отличия, о которых сказано выше.

Опознать "Бейсик-60" легко: во первых - он не выводит никаких заставок и фраз, во вторых - ничего не пытается загружать после своего запуска, на диске обязательно присутствует здоровенный файл HELLO, наконец, команда CATALOG предваряет свой вывод строкой "DISK VOLUME" с номером метки тома (вот мы и встретились) - точно так же как в Apple ][.

Агат-7 и косметологи

Не знаю - почему, но общение с дисководом у ДОС3.3 было мучительно долгим. Теоретически, дискета вращается со скоростью 200 мс/оборот и за этот оборот вполне можно успеть считать дорожку. У дискеты 140 кб всего 35 дорожек и одна сторона, таким образом, добавив ещё десяток (да хоть сотню) миллисекунд на перемещение головки, можно оценить теоретическую скорость: 35 * (0.2 + 0.1) = 10 секунд на чтение всей дискеты. Накинем ещё 10 на то, что не все дорожки прочитаются с первого оборота. Пусть будет 20 секунд. Практика это подтверждает, но ДОС3.3 работала медленнее раз в пять. Может быть это было связано с каким-то задержками, которые приводили к влиянию фактора чередования секторов, да и скорость движения головки у неё тоже была весьма медленной.

Кроме того, загрузка Бейсика из файла - это тоже не очень оперативный подход - сначала нужно двинуть головку в район середины дискеты - там каталог. Потом передвинуть её к файлу. А он может быть раскидан по дискете - никто фрагментацию не отменял.

Наконец, довольно странное решение эпловских программистов: стандартными командами ДОС нельзя узнать объём свободного места на диске.

Первая ласточка возникла почти сразу: ALV Super DOS. У неё появилась заставка, извещающая пользователя о том, что это:

Почему я назвал этот раздел "косметологи" ? Дело в том, что ни в какой документации к Агату эта ОС не отражена даже намёком - т.е. официальной как будто не является. Даже в статьях по агату я этого названия не видел. В то же время - географическая близость указанного адреса к ЛЭМЗ (где разрабатывали Агаты) и сам факт наличия этого диска вблизи купленной машины косвенно намекал на то, что диск и ОС пришла вместе с Агатом из общего источника. Вокруг не было людей, которые бы ради этого диска поехали куда-нибудь в командировку или написали этот мод сами. Т.е. вроде как диск от производителя, но как бы не очень официальный. Позже выяснилось: ALV Super Dos - родилась в компьютерном клубе ЛЭМЗ.

Так что, собственно, представлял из себя этот ALV Super Dos ? Похоже, это был бинарный патч "Бейсика-60" и ДОС3.3. Структура, адреса памяти, входные точки, порядок загрузки - всё это было сохранено. Было изменено следующее:

Главное достоинство этой связки было в скорости загрузки - авторы утверждали его как 7 секунд и, хотя я не проверял с секундомером, истина была где-то рядом.

Александр Голов комментирует: Кто-то принёс SuperDOS для Эппла, меня он сразил своими возможностями скорости и я туда полез исследовать. Быстренько сляпал агатовский вариант, а - главное - перенял скоростную читалку для своих прог.

Там ведь в сектор содержит две части, так называемая систма 6 & 2, сначала идут 256 байтов, содержащих 6 разрядов данных и потом ещё 86, содержащих 2 оставшихся бита (ещё раньше была система 5 & 3, так называемый 13-секторный DOS). Всё это читается в буфер, а потом перепаковывается и укладывается куда заказали. Так вот, понимая, что перепаковка занимает время и к началу следующего сектора не успеть, программер ДОСа (Возняк?) придумал при разметке секторы кидать через один (0, 2, 4, 6...E, 1, 3, 5...F), что должно было обеспечить чтение дорожки за два прохода. Но они просчитались (и даже с этим не разобрались!) и перепаковка не успевала выполниться и при чтении через один, в результате трек полностью читался за 16 оборотов. Была такая программка - Locksmith - которая очень быстро читала диски, но там секрет был в том, что они ничего не перепаковывали, а просто сохраняли инфу как считали, плюс читали не конкретные секторы, а те, что едут под головкой (как потом это сделал Филиппов уже на нормально ДОСе). Так вот чуть позже кто-то из импортных людей придумал как читать и распаковывать сектор налету, т.е. там сначала читается первая 6-разрядная часть, а потом с помощью специальных таблиц перепаковка идёт прямо по ходу считывания. И всё сразу быстро забегало.

Главный недостаток - модифицированный Бейсик, распухший на несколько Кб, причём не помню - была ли от этого хоть минимальная польза. А вот глюков в нём добавилось изрядно - работал он только демонстрационной моделью.

Любопытно то, что интерфейс взаимодействия между Бейсиком и ДОС практически не изменился и это позволило сделать простой финт ушами: объединив ALV Super Dos и старый Бейсик-60, я получил вполне стабильную и шуструю систему, которую использовал несколько лет. Совместимость с оригинальным "Бейсик-60" у неё была вполне на уровне, а скорость общения с дисководом радовала глаз и другие органы чувств.

Были и другие моды/патчи. ASP Super Dos - пришла с игрой Lode Runner:

Позднее, уже после 2000-го года, разбирая полученные по Интернет образы дисков, я находил и более серьёзные модификации ДОС3.3. Но неизвестно насколько они были распространены. Точно знаю лишь одно: всё это - большие или меньшие патчи основной версии, т.к. характерные точки входа, расположение на диске, буфера - у этих систем совпадает.

ДОС3.3 в качестве прослойки

Пытаясь позиционировать компьютер как нечто узкоспециализированное и очень простое в использовании, нужно избавить пользователя от любых действий, которые компьютер может сделать самостоятельно. Если продавать Агат как пишущую машинку или музыкальный редактор - нужно чтобы при включении сразу появлялся мигающий курсор, предлагающий набирать текст или вводить ноты. Пользователю может не знать о тонкостях реализации операционной системы, её связи с прикладной программой, он оценивает компьютер в целом по миганию курсора. Но автор программы вынужден думать обо всём.

В том числе о том - как бы так сделать, чтобы ничего не делать ? Вот например: как бы так сделать, чтобы его текстовый редактор был бы автономен от другого программного обеспечения, вплоть до самостоятельного форматирования дискет, и в то же время был простым в освоении и вместе с тем - чтобы не слишком много времени ушло на его разработку ?

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

Они взяли переделанную под Агат ДОС3.3 и внесли в неё ряд изменений: подправили логику работы некоторых операций (команда ЗТ, ИНИЦИАЛИЗАЦИЯ), изменили таблицу ключевых слов (INIT на ИНИЦИАЛИЗАЦИЯ, CATALOG на КАТАЛОГ), перевели на русский сообщения об ошибках, добавили возможность выбора файла из списка. А само ядро Агат-Автора назвали AGAWT и подставили его вместо файла HELLO.

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

Т.е. существовали ветки развития ДОС, предназначенные для решения конкретных задач, можно сказать - встраиваемые.

Примерно также отделённую от Бейсика ДОС (только другую версию - более позднюю, похожую на ИКП-шную) использует ранняя версия Системы Численного Моделирования, разработанная (или откуда-то адаптированная ?) для семёрки.

Часто полным стандартным ДОС-ом (с Бейсиком) комплектовались "как бы автономные" программы - СУБД Эврика, MUSICEDITOR. Эти программы были обычными приложениями стандартной ДОС, но запускались при её загрузке автоматически и поэтому могло сложится впечатление, что от самого включения машины загружается именно та программа, имя которой написано на этикетке дискеты.

Тайны 840 кб дисковода

Для Агата был разработан 840 кб дисковод. Разработка была собственная, точнее - собственным был контроллер 840, а дисковод вполне стандартный.

Но новый, объёмный, накопитель вызвал новые проблемы. У него было две стороны и 80 дорожек. А у 140кб - одна сторона и 35 дорожек. Куда девать номер стороны - решили сразу - в отличие от мира PC, где до появления LBA-адресации (Large Block Address) накопителей использовали CHS (Cylinder/Head/Sector) на Агате сразу и прочно закрепилась адресация TS (Track/Sector), а головку просто спрятали в младшем бите номера трека, предварительно сдвинув остальные биты влево. Т.е. драйвер дисковода принимает на входе номер трека в диапазоне от 0 до 159 включительно, при этом трек 1 соответствует нулевому физическому цилиндру, но головке # 1. Трек 2, соответственно - первый цилиндр, головка 0. И т.д..

Но возникла и вторая - более сложная проблема: VTOC - системная структура, в которой, помимо прочего, хранятся маски занятых/свободных секторов - рассчитан, максимум, на четыре десятка дорожек - на большее просто места нет (хотя, любопытно, что эпловские программисты предусмотрели во VTOC место для целых 32-х секторов на дорожку, хотя в 140кб дискете их всего 16).

И вот здесь возникает тайна. Все, кто работал с девяткой или хотя бы с 840кб дисководами на семёрке, знают, что есть такая штука - ИКП - инструментальный комплекс программиста. Он вполне неплохо общается с 840кб дискетами, равно как и куча других программ и специализированных ОС. Но однажды мне досталась программка, записанная на дискете со странной операционкой, которая сперва совершенно не хотела работать в эмуляторе. Она просто зависала в самом начале загрузки.

Сначала я решил, что это - порождение тьмы и, конечно, окропивши всё вокруг святой водой, принялся искать таблетки от жадности. Не в интернете, но в коде системы. Полученный диагноз был весьма удивительным - похоже, это не была очередная защита от копирования: передо мной пыталась работать операционная система, являющаяся неизвестным (для меня) переходным звеном от ДОС3.3 к ИКП-ДОС (а ей будет посвящен раздел далее по тексту).

Т.е. с точки зрения внутренней организации - это было что-то среднее между ДОС3.3 и ALV Super DOS, но из её тела был хирургически точно извлечён драйвер 140 кб дисковода и заменен драйвером 840 кб. При этом ничего больше задето не было! А как он работал - логично было бы спросить, учитывая проблемы с размером VTOC ?

А очень просто: он оперировал как бы с четырьмя дискетами в одной. Это напоминало таблицы разделов на современном HDD, только не было таблицы разделов, а деление происходило строго по границам, кратным 40 трекам: 0..39, 40..79, 80..119, 120..159. Номер "субдискеты" ("раздела") передавался драйверу ... где бы вы думали ? В виде метки тома ! Причем интерпретация была такая: число в пределах [1..4] - указание на субдискету, 0 - любой том, другие числа - заданный том. Смысла в значениях 0, 5..255 не было никакого, ну а 1..4 воспринимались как указание на субдискету - одну из четырех частей реальной дискеты. В каждой субдискете был свой каталог, свой VTOC, ... всё своё.

А в эмуляторе она не работала просто потому, что загрузчик пытался читать тело ДОС из первой субдискеты и явно указывал номер тома #1, но проверку на номера томов (ещё в том смысле, в котором они были приняты в Apple ][) никто не отменял, а эмулятор для обычных дискет возвращает драйверу номер тома по умолчанию - 254. Ошибку Volume Mismatch загрузчик получал, но мозгов сообщить о ней у него уже не хватало.

Техническая проблема была решена, ОС заработала в эмуляторе, но исторические загадки остались: была ли эта ДОС официальной, если нигде в документации на Агаты не упоминается о таком странном делении дискеты на разделы ? Если она не была официальной - то кто и когда её выпустил ? Где он взял железо - новый контроллер и почему к этому железу ещё не было ИКП - официальной ОС ? Или почему он взялся за такую переработку старой ОС если уже была новая ? Или это всё таки официальная ОС, поставлявшаяся с ранними экземплярами контроллеров, ограниченным тиражом ?

Это была модификация Андрея Филиппова(FVS Dos 3.3), предназначенная для демонстрации винчестера (которого для производства так и не нашли) и проверки 840кб контроллера.

Система Численного Моделирования и ДОС

С классом Агатов в нашей школе шли дискеты, одна из которых содержала Систему Численного Моделирования (электронная таблица). Набор файлов на дискете был довольно любопытен - помимо файлов документации и примеров там находилось ещё три двоичных файла разного размера. Вряд ли случайно, тем более у них были заковыристые имена, содержащие не только буквенные символы. Очевидно - раз есть файлы - значит поблизости есть и операционка, которая их зачем-то читает. И хотя СЧМ загружалась самостоятельно и вполне могла быть полностью законченной закрытой программой, включающей в себя драйвера дисковода и файловой системы (как, например, графические редакторы Alv Graf, MouseGraf, Малая бухгалтерия...), тем не менее что-то подсказывало, что не всё так просто... Вот и звездочку выводит при загрузке, только вверху экрана... Что будет, если с диска убрать файлы и попробовать загрузить машину с этой дискеты ?

Ага, она смогла не просто удивится, но даже выразить это фразой ФАЙЛ НЕ НАЙДЕН ! Нет, простые загрузчики на такое не способны, это уже реально начинает пахнуть самой настоящей законченной операционкой.. Интересно поискать - какой из трех файлов ей нужен ? А что будет, если вместо него подоткнуть стандартный HELLO ? Зависла :(( А что у тебя внутри ? Системные таблицы на месте ? Опа2 ! А структура -то совсем другая ! И вектора входов процедур ввода/вывода смотрят не в область 9A00..BFFF, а в 0400..04FF и заголовок при выводе каталога очень похож на ИКПшный, только три цифры в указателе свободно пространства вместо четырех.. Да и таблица заданий для драйвера дисковода не на привычном месте - с $B5B7 сиганула аж на $4AE (у ИКП-бейсика - $557). Вот только в ИКП бейсик и дос слиты во едино, а тут - дос без бейсика ? Так что ж ты за зверь промежуточный, опять неизвестный науке ?

Светлое будущее: ИКП, КПОН

Одна из проблем постепенно увеличивающегося в количестве агатовского софта состояла в том, что каждый автор своего крупного пакета старался сделать его автономным - т.е. достаточно было одной дискеты с программой, которую вы приобретали, чтобы ПЭВМ могла загрузится и работать. Это избавляло от всяких требований, на манер нынешних: "Windows XP, видеокарта с объёмом памяти не меньше чем ..., CD-ROM не хуже чем...". С другой стороны, авторы часто, стараясь добиться максимальной эффективности и надёжности своих программ делали их совершенно не стыкуемыми друг с другом. Они совпадали только форматом файловой системы - т.е. данные одной программы можно было хранить на одной дискете с файлами другой. Но других совпадений было мало.

С другой стороны - появление 840кб дисководов вызвало острое желание пользователей иметь на одной дискете разные прикладные программы и свои файлы данных. Первая такая попытка - ИКП - Инструментальный Комплекс Программиста. Вторая - КПОН - Комплекс Программ Общего Назначения. КПОН был объединением под одной крышей таких программ как "Агат-Автор" (со второй версии КПОН заменен "Текстовым Оконным Редактором"), "Система численного моделирования", база данных, позднее - в четвертой версии КПОН был добавлен также графический редактор MouseGraph. Про него - в другой раз. Следует только отметить, что хотя это был стандартный пакет программ - он продавался за отдельные деньги.

ИКП - штука более интересная. Он являлся стандартным пакетом и шёл вместе с машиной, объединяя в себе РАПИРУ, Копировщик, Диалоговый Отладочный комплекс, Apple Soft (программное обеспечение для эмуляции Apple ][) или "Агат-Автор" в семерочной версии и Бейсик. И вот отсюда - подробности.

Выпуск ИКП, вероятно, был приурочен к выпуску Агат-9. Мне не доводилось видеть какой либо версии DOS3.3 или ранних версий Бейсика для этой машины. В то же время, ИКП существует и в версии для Агат-7.

Самое интересное в ИКП (с точки зрения этого текста) - это Бейсик. Начнем с того, что хотя он и является наследником эпловского бейсика, но был значительно переработан, настолько значительно, что возникает предположение, что у разработчиков уже были причёсанные исходники и они могли не только менять десяток-другой байт в разных местах, но и просто полностью перекомпилировать всю систему, не переживая о съехавших входных точках, векторах и прочем. Причем это впечатление складывалось и из знакомства и с транслятором и с ДОСом, которые теперь были слиты в единое целое. Ну может не совсем единое, но так легко разделять их, как было в ранних версиях - простым колдовством с файлами - уже не получалось. Весь код грузился с абсолютных адресов дискеты и никаких обязательных системных файлов уже не было. Получившийся конгломерат обладал следующими принципиальными нововведениями:

Так как получившийся комплекс формально поддерживал старые Бейсик-программы (формат файлов не сменился, синтаксис тоже почти не пострадал), кроме того был полностью сохранён функционал двоичных процедур для любителей ассемблера (но обращаться к ним теперь было нужно по другим адресам) - эту версию Бейсика и ДОСа можно было бы назвать продолжением, но, всё же, реальные программы, написанные для DOS3.3 и ALV Super DOS (если они не были совершенно автономными, что часто бывает с игрушками), хотя и загружались, но работать, как правило, не могли. Требовалась, как минимум, перекомпиляция. Или залезание в них отладчиком.

Обратите внимание: таким образом, ИКП-бейсик существует по крайней мере в четырех явных видах: для агат-7 и агата-9 входящим в ИКП и автономным. Плюс к тому, у меня в коллекции лежит ещё один странный диск - на вид это ИКП-бейсик девятки на 840кб дискете, но сильно отличающийся от часто встречающегося оригинала - если сравнивать побайтно. Хотя внешне - в работе - никаких отличий не заметно.

Как сказано выше - ИКП - комплекс из нескольких пакетов + меню загрузки. Автор Бейсика, соответствующего ему ДОС и меню (с изображением набора дискет) - Александр Кривцов. Он же предложил формат расширенного VTOC и согласовал соответствующие изменения с авторами других, входивших в ИКП, пакетов.

Название "Школьница" отсутствует в ИКП из юридических соображений: пакет под таким названием уже поставлялся по линии образования.????????????

В дальнейшем возникали также модификации ИКП - с поддержкой сети, kermit..

Надстройки: BioBasic, SubGraph. Расширенный Basic Master

Штатный Бейсик - плох или хорош, но продукт конкретный и конечный. Развивать можно всё до бесконечности, но разработчики штатного Бейсика вполне представляли себе границы его развития на текущий момент и выходить за них не собирались (чего, порой, не хватает нынешним программерам). Однако чего в нём всё таки реально не хватало - это ясных договорённостей о плагинах или резидентных программах. Можно сделать сколь угодно простую прогу, но если она обладает возможностью расширения - то большего от неё и не требуется.

Штатный Бейсик этго не имел. То есть не так, чтобы совсем не имел - операторы CALL, USR и недокументированный "&" позволяли вызывать ассемблерные процедуры, но во первых - эти процедуры нужно было написать и где-то разместить в памяти, зная её карту, во вторых - вопрос об одновременной работе нескольких таких расширений был исключительно пользовательской проблемой. А расширять Бейсик пользователям хотелось. И в этом деле наметилось две тенденции.

Первая - разработки вроде BioBasic, SubGraph, Sirius Basic. Это надстройки над штатным Бейсиком, т.е. некие проги, которые загружаются после загрузки интерпретатора, пристраивают свои части в малоиспользуемые уголки памяти, в надежде, что их оттуда никто не выгонит, распускают свои щупальца по разным "официальным" частям системы и, перехватывая разные ситуации, немножко помогают пользователю. Такой подход редко ухудшал совместимость с обычными программами, но название подобных комплектов сбивало с толку - вроде как это уже не Бейсик или не совсем Бейсик. На самом деле все эти программы - лишь дополнения к штатному транслятору.

Какие были надстройки ? Например, они позволяли использовать различные знакогенераторы в программах. С маленькими и большими буквами, специальными значками и т.д.. Или, например, упрощали ввод программ, предлагая автонумерацию. Позволяли делать print screen - печать копии экрана на принтер. Коротко вводить наиболее часто используемые слова через макросы.

Вторая тенденция - доработка штатного Бейсика до поддержки комбинаций плагинов, исправление ошибок - это, конечно, Basic Master. Это уже был коммерческий продукт (т.е. за отдельные деньги), имел богатую библиотеку готовых плагинов на разные случаи жизни, а также описание программного интерфейса - т.е. инструкции по созданию собственных плагинов. Но Basic Master уже имел очень подробное описание, так что тут вопросов совместимости возникать не должно.

Подкаталоги BTK

Тема, вроде не совсем относящаяся к Бейсику, но всё же увидеть и не понять её можно и работая с Бейсиком.

Штатная файловая система, ведущая своё начало ещё от Apple ][ (а может и раньше ?), не подразумевала наличия подкаталогов. Собственно, в них и смысла никакого не было на дискетах объёмом 140 кб. Туда реально помещается 10-30 файлов - и так не запутаешься. Можно, конечно, записать и сотню и две, но только если файлы будут совсем мелкие - например, бейсиковские программы на несколько строк.

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

Кому пришло решение - неизвестно, но, предполагаю, что это был автор Best Tool Kit - А. Голов. Во всяком случае именно в этой системе появилась поддержка подкаталогов. Для их создания и удаления имелась специальная утилита, а переходы могло выполнять ядро ОС.

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

Единственная важная особенность: указатель на текущий каталог (или подкаталог) хранился во VTOC, а не в оперативной памяти, поэтому текущий путь как бы запоминался на каждой дискете и она должна была быть доступна для записи. Это приводит также к тому, что старые ОС всегда видели на дискете тот подкаталог, который пользователь выбрал последним, работая в BTK ! Поэтому если вы увидите в Бейсике странные файлы типа Д - возможно, это подкаталог, который скрывает что-то ещё.

Другие операционки Агата

Заметьте: пока мы шли только по пути развития связки ДОС и Бейсика, но ведь двоичные B-файлы ДОС-а могут читать и другие ОС. Например Best Tool Kit. Вообще-то, эта система была предназначена для отладки двоичных программ, но по сути, является самостоятельной операционной системой, что, в результате вызвало появление программ для неё. Хранящихся, однако, виде обычных B-файлов старого ДОС3.3. И единственное, что спасает - эти программы, как и сама BTK - отечественной разработки, с описаниями на русском языке, где указывается - под какой версией ОС программа должна исполнятся. BTK тоже вполне разговорчива, и имеет как подробное описание так и несколько строк заголовка, в котором указаны год или версия выпуска.

Ну а вообще-то всяких разных операционок для Агата было с избытком. Причина их появления проста: Интернета ещё не было, разработчики о существовании друг друга знали плохо, а стандартный софт, особенно до появления ИКП, был не слишком логичен и надёжен. Пожалуй, из ранних ОС самой надежной была Школьница - в смысле отсутствия глюков. Она была собственной разработкой, сделанной под Агат и её структура была вполне логична. Но в то же время РАПИРА - интерпретатор входящий в Школьницу - кушал много памяти, медленно грузился и был медлительным в исполнении программ. Поэтому обходится лишь одной Школьницей не получалось.

К счастью (или к сожалению) новые ОС, такие как Спрайт-ОС или ONIX используют собственную файловую систему, структуру файлов и старые проги в них если и можно интегрировать, то уж точно не простой командой запуска. Так что здесь неясностей возникнуть не должно.

* * *

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

Антология Бейсика и Дос (обзор софта и файловых систем: исторические хроники)