Примитивная DOS размером 2 Кб

Тема о примитивной DOS размером в 2 кб, которую можно прошить в ПЗУ 573РФ2 расширяющее базовое ПЗУ РК86 и установленное в адресах F000...F7FF. Понятно, что в 2 кб можно уместить только примитивную DOS. Хотя РК86 это достаточно примитивный компьютер, но примитивность DOS вовсе не следует из примитивности самого компьютера, а лишь характеризует уровень сложности DOS.

Спойлер:

В оригинальном виде РК86 малопригоден для DOS. Нужны аппаратные доработки. Полноценные DOS требуют больших доработок. Когда стоИт задача только запускать программы, то достаточно даже примитивной DOS. Кроме подключения контроллера дискового привода, доработка, которая позволяет иметь минимальную DOS на РК86, заключается лишь в добавлении на плату РК дополнительного ПЗУ в 2 кб. Это минимальное вторжение в плату РК86. При наличии небольшого опыта эта доработка делается за полчаса.

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

Примером отечественной примитивной DOS является Hameleon-DOS для компьютера Львов ПК-01. ORDOS ОРИОНА, кстати, тоже примитивная, но не в смысле программного интерфейса, а в смысле идеологии. ORDOS даже ОС может называться с натяжкой, т.к не соотвествует общепринятым концепциям DOS (скорее является системой управления ROM-картриджем, адаптированной для доп.банки памяти, именуемой квазидиском) и вообще не поддерживает дисковод или другой массовый носитель.

Очевидно, что и для РК86 тоже были бы созданы самодельные любительские DOS (и естественно, поначалу они были бы именно примитивными), если бы в 1986...1991 годах и для РК86 имелось бы техническое решение по подключению дисковода или эл.диска из ОЗУ. Увы, такие технические решения появились лишь много лет спустя, когда это уже мало кому было надо.

Подключить дисковод в машину, в которой прогон программы непрерывно рвёт ПДП, реально сложно, а вот использовать RAM-диск (внешний или из добавленного ОЗУ в самом компьютере) было совсем несложно. Этому помешало скорее то, что большинство программистов и аппаратчиков любителей вскоре бросили РК86, т.к стали доступны платы для самосборки ZX-Spectrum и Специалиста.

Загружаться (например из ROM-диска) и работать в ОЗУ DOS для РК не удастся, т.к она должна обеспечить запуск программ размером в 28.5 кб, ибо такие программы для РК86 есть. Таким образом DOS должна размещаться где-то выше 8000.

И возникает вопрос - добавлять выше 8000 область ОЗУ или ПЗУ (или и то и другое). ПЗУ для пользователя удобнее, т.к в него грузить с МГ-ленты DOS не надо. Аппаратно вполне возможно совместимо установить доп.ПЗУ в каких-то дырках адресного пространства выше 8000, ибо у РК86 в адресах выше 8000 используется всего около 30 адресов, т.е найти место для дополнительного окна ПЗУ не трудно. Для установки доп.ПЗУ типа РФ2 достаточно один из четырёх восьмикилобайтовых участков для БИС разделить дешифратором. Например так, как предлагали И.Крылова или Е.Седов на страницах журнала "Радио". Всё-равно для подключения контроллера массового носителя (винта, флопа или флэша) нужен дополнительный чип-селект.

Хотя на оригинальной плате РК нет участка слепыша для доработок, всё-же одну панельку для РФ2 можно запаять в ряды отверстий рядом с разъёмом ГРПМ-61. При этом удобно (т.к недалеко) соединять проводками контакты этой доп.панельки с контактами имеющейся панельки ПЗУ F800. Разумнее всего доп.ПЗУ РФ2 адресовать в области F000...F7FF, что даёт 4 кб сплошного ПЗУ F000...FFFF. Кстати, и сами разработчики РК86 планировали включать доп.ПЗУ именно в области F000.

Всего 4 кб ПЗУ, если тут надо уместить и DOS и стандартные подпрограммы ввода/вывода (экран/клавиатура/магнитофон) - это очень мало. Полноценные DOS для КР580 обычно имеют размер порядка 8 кб. Самой компактной из DOS для КР580 вероятно можно считать RK-DOS, она имеет размер около 6 кб. Причём BDOS и ядро CCP размещается в ПЗУ 4 кб, а исполнительная часть CCP (т.е сами команды) размещаются в виде файлов на дискете (что не очень удобно). RK-DOS использует дефрагментацию, позволяет файлы любого размера и имеет развитые функции программного интерфейса и не может относиться к примитивным DOS.

Кстати, RK-DOS это довольно грамотный, но увы, опоздавший продукт. Эта DOS появилась, когда это уже перестало быть актуальным, - в 1993 году популярность РК86 уже упала почти до нуля и дисковый ассемблер для RK-DOS никому не помог писать программы для РК86. Т.к последние программисты для РК86 покинули его ещё за несколько лет до этого.

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

Наличие дискового ассемблера существенно ускоряет и облегчает разработку программ. И речь не о большей скорости загрузки с дискеты, чем с МГ-ленты. Главное, что тогда объём исходника на ассемблере не ограничен всего в 23 кб (т.к на РК из 29 килобайт доступного ОЗУ, 4 отнимал транслятор и 2 кб - буфер трансляции). С дискетным ассемблером размер исходника ограничивает только объём дискеты.

Без дисковода в буфер текста редактора/ассемблера умещался исходник дающий всего ~1.5 кб объектного кода (хотя в начале 90-тых появились методы сжатия исходников позволяющие транслировать аж до 2 кб). Программы большего объёма приходилось компоновать, вручную переписывая и вставляя в текст модулей адреса перекрёстных ссылок (причём при каждой перетрансляции). Учитывая, что каждый ассемблерный модуль приходилось грузить 3-4 минуты с ленты, и ещё 3-4 минуты тратить на сохранение после модификаций, было почти невозможно написать программу из более, чем двух модулей (т.е макс.объём собственно кода редко превышал 3.5 кб). Потому более крупные программы для РК86 писали кросс-ассемблерами на ДВК.

Кстати, даже примитивная DOS позволяет транслировать программы с исходником имеющим размер более объёма TPA, только исходник тут не может быть одним большим файлом, а должен состоять из одного основного файла и нескольких инклюдэ-файлов, каждый из которых умещается в буфер ассемблера в ОЗУ.

В 1989 году появились сведения о (как минимум) двух вариантах успешного подключения к РК86 дисковода с CP/M. Однако они не получили широкого распространения и даже известности, т.к дисководы тогда были практически недоступны. Дисководы на нелегальных рынках стали появляться лишь в 1990 году, а цена упала до более-менее приемлемой лишь в 1991.

Но и тогда, увы, для РК86 это ничего в плане дисковода не изменило. Т.к известные решения КНГМД на базе ВГ93 работали на основе программного обмена, а в РК86 этому препятствует работа ПДП. В итоге число пользователей РК86 стало быстро сокращаться. Лишь в 1993 году Е.Седов, пусть и весьма запоздало, но наконец решил проблему дисковода для РК86 и Микроши.

Однако, оказывается, уже намного ранее существовала реальная возможность получить DOS и, соответственно, дисковый ассемблер на РК86. Речь о DOS работающей с RAM-диском. Я купил банку ОЗУ 565РУ7 для электронного диска в 1988 году, а статика 62256 стала доступной чуть позднее в 1989-1990.

Внешний электронный диск на 565РУ7 довольно сложен (~25 корпусов) и не энергонезависим, его надо загружать/выгружать. А электронный диск выполненный на статике намного проще (лишь ряд панелек), и хоть по стоимости байта тогда получался примерно вдвое-втрое дороже, но может хранить данные и без питания за счёт крошечной пуговичной батарейки. На статике с батарейкой получается как бы крошечный аналог современного SSD-винчестера (кстати, уже в XXI веке стали доступны скоростные ОЗУ, которые не забывают данные по выключению питания).

Электронный диск (например 256 кб) на статическом ОЗУ может подключаться как полностью внешнее устройство через пользовательский ППА D14 (при необходимости может также иметь и свой собственный ППА для интерфейса). Такие электронные диски на статике всё-же появились на РК86, хотя уже слишком поздно и потому существовали лишь в единичных экземплярах.

Таким образом несложное расширение ПЗУ на одной дополнительной микросхеме типа 573 РФ2 (что требует монтаж на основной плате РК микросхемы 555ИД7 и панельки для ПЗУ РФ2) и подключение внешней несложной платки электронного диска на статике позволяло уже в 1989 году получить железо пригодное для работы более эффективного инструментария программиста, т.е дискового ассемблера. А впоследствии, после появления информации по использовованию на РК86 дисковода с помощью РК-КНГМД, DOS работающую на RAM-диск можно было очень легко (путём замены подпрограмм чтения/записи сектора) конвертировать для работы на дисковод.

К сожалению, среди пользователей РК86 к тому времени уже не было достаточно квалифицированных людей, способных придумать и спаять внешний RAM-диск на статике и написать даже самую простейшую DOS. Т.к все более-менее грамотные владельцы РК86, обнаружив предельную аппаратную ущербность РК86, предпочли перейти на другие компьютеры имеющие полноценную графику.

Рассмотрим набор подпрограмм нужных в примитивной DOS, которую любой любитель немного знакомый с ассемблером мог написать ещё в 80-тые годы XX века.

Естественно, первым делом нужны две подпрограммы чтения/записи сектора. Хотя эмуляторы не поддерживают внешний эл.диск на статике, но при разработке и отладке нет особой разницы, если в эмуляторе под эл.диск использовать резидентное дополнительное ОЗУ РК86, которое прокачивается в окне в 8 кб на A000...BFFF (и для чего у меня уже имеется соответствующий конфиг для эмулятора).

При смене носителя меняются только две подпрограммы чтения/записи сектора, а на остальной код DOS это не влияет (хотя для разных устройств размер этих подпрограмм разный). Подпрограммы чтения/записи сектора имеют минимальный размер для эл.диска, для контроллера на БИС ВГ93 и винчестера IDE их размер немного больше, а ещё больший размер имеют подпрограммы для программного РК-КНГМД.

Вот драйвер RAM-диска (т.е две подпрограммы чтения и записи сектора) для варианта расширения ОЗУ в РК86 в окне A000...BFFF:

Спойлер:

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

Механический дисковый носитель обычно работает с треками и секторами, но все винчестеры с размером от 1 гигабайта используют адресацию LBA, а не трек-секторную. Сама DOS не знает о треках и секторах, но они нужны для ретро-винчестера на 40 мб и дисковода, потому в данном драйвере подпрограмма TRKSEC пересчитывает номер кластера в трек и сектор.

Для эл.диска из ОЗУ прокачиваемым в окне в 8 кб естественно сделать размер трека в 8 кб. Тогда в таком треке умещается 16 физ.секторов по 512 байт. Сектор это минимальный элемент обмена в данной DOS (также сделано в RK-DOS), потому она работает намного быстрее, чем CP/M (которая тормозит из-за того, что в ней минимальный элемент обмена не равен размеру физ.сектора, что требует наличия промежуточных буферов и кучу копирований, что фатально замедляет обмен с диском).

Как видите, при грамотной схемотехнике подпрограммы для организации эл.диска совсем просты. Подпрограмма CMPADR рассчитывает адрес сектора в эл.диске, включает нужный его участок в окне 8 кб и возвращает в HL адрес начала сектора в ОЗУ. Попрограмма ADRCHS возвращает адрес для хранения контрольной суммы текущего сектора. Эти контрольные суммы хранятся в основном ОЗУ (или в странице 0 доп.ОЗУ, если оно есть) начиная с адреса PLCCHS (Place Check Sum) и на каждый сектор тратится один байт. КС представляет просто арифметическую сумму байтов сектора (плюс нач.оффсет).

Контрольные суммы секторов необходимы, даже если в системе не бывает сбоев, т.к в ходе отладки программ бывают улёты и процессор может "плюнуть" что-нибудь в эл.диск, что может привести к размножению дохлоты (так было в ранних CP/M для ОРИОНА, что в последующих версиях заставило ввести КС). И, естественно, подпрограмма MOVSEC копирует сектор размером в 512 байт.

Для внешнего VDISK-а, т.е при использовании внешней платки RAM-диска подключенной через ППА D14 и представляющей собой просто набор панелек со статическими ОЗУ, подпрограммы чтения/записи сектора отличаются только подпрограммой MOVSEC. Для реального дисковода (особенно, если он программный, как РК-КНГМД) подпрограммы чтения и записи сектора намного более сложные (и соответственно бОльшие по объёму кода).

Для работы с каталогом, как и в любой другой DOS необходим отдельный буфер, называемый CATBUF. В него DOS считывает сектора каталога и выполняет поиск каталоговых записей о файлах по имени. Естественно размер этого буфера д.быть равен размеру физического сектора. При отсутствии другого ОЗУ выше 8000 этот буфер приходится помещать в основное ОЗУ (т.е ниже 8000). Даже в системе, где эл.диск организован в окне A000 дисковый буфер д.быть в основном ОЗУ, т.к иначе потребуется копирование между страницами доп.ОЗУ, что не только резко тормознёт, но и потребует модификации ПЗУ F800 для введения подпрограмм F836/39 для чтения/записи байта из страниц ОЗУ.

Важное значение в любой DOS имеет формат каталоговой записи. Вот минимально желаемая каталоговая запись для простой (т.е нефрагментирующей файлы) DOS:

юзер               1
имя                8
расширение         3
адрес загрузки     2
число блоков       1
размер посл.блока  1
дата файла         2
N_кластера         2

Здесь шаг каталоговых записей - 20 байтов. N_кластера это номер первого кластера файла, т.е по сути адрес начала файла на диске. Под юзером понимается область диска пользователя аналогично CP/M. При шаге в каталоге в 20 байт в одном секторе каталога умещается 25 каталоговых записей.

Кстати, в терминологии CP/M каталоговые записи называются экстентами, т.к там каталоговая запись одного файла может состоять из нескольких экстентов. В примитивных DOS такого нет и для каждого файла выделяется только одна каталоговая запись или экстент.

Свободное место каталога естественно, как и общепринято, обозначает первый байт каталоговой записи равный E5 (т.к именно так заполняют сектора форматёры дисков в КНГМД на БИС). Если первый байт каталоговой записи меньше 80H, то это место в каталоге занято записью о файле. А если этот байт >80H, но не E5, то это или удалённый или невидимый для поиска и не выводимый по DIR файл-дохляк.

Понятие блок в 256 байт введено ради сокращения размера каталоговой записи при возможности иметь размер файла кратный одному байту, а не целому сектору (что обычно имеет место для простых DOS). В некоторых DOS, чтобы поиметь любой размер файла в каталоговой записи хранят число секторов и отдельно два байта отводятся под размер последнего сектора байта. При размере сектора в 512 байт и расходе в один байт для хранения числа секторов файла макс.размер файла - 512*256 байт (т.е 128 килобайт). При этом в целом для задания размера файла с точностью до байта тратится целых три байта (или даже четыре  байта, если нужны файлы крупнее 128 Кб и приходится тратить 2 байта под размер в секторах).

Разумнее сделать чуть экономнее. Размер файла храним в блоках по 256 байт, выделяя под это также всего один байт, что позволяет иметь лишь файлы с максимальным размером в 64 кб (чего для DOS с цельно-файловой загрузкой и CPU адресующим лишь 64 кб вполне достаточно). И ещё один байт я трачу на хранение размера последнего блока, что и позволяет знать размер файла с точностью до байта. Из размера файла в блоках по 256 байт не проблема получить размер файла в секторах по 512 байт (это делается с помощью арифметики с помощью операции деления на два, что в двоичной арифметике всего одна команда сдвига).

Т.к в крошечном ПЗУ в 2 Кб нет места для обслуживания юзеров, даты файла и размера файла с кратностью до байта, то для примитивной DOS разумно сократить каталоговую запись до 16 байт, что позволяет уместить в один сектор каталога аж 32 каталоговых записи. Тогда формат каталоговой записи в примитивной DOS такой:

имя                11
адрес загрузки     2
число секторов     1
N_кластера         2

В самой первой каталоговой записи в самом первом секторе каталога, как и в Хамелеон-ДОС храним основные параметры всего диска. А именно, - имя диска, атрибут разрешения записи (флаг R/O) и номер кластера, начиная с которого будет записываться очередной файл.

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

Для считывания файла требуется сначала найти в каталоге каталоговую запись по имени файла. Для этого нужна подпрограмма сканирования каталога для поиска нужной каталоговой записи. Неплохо работает вот такая подпрограмма:

Спойлер:

Как видите эта подпрограмма поиска в каталоге очень проста и легко пишется человеком, кто лишь вчера узнал о работе основных команд микропроцессора. И по сути это все самые сложные части примитивной DOS. Для получения DOS (для RAM-привода) нужна ещё подпрограмма форматирования эл.диска при первом старте (это просто заполнение кодом), процессор команд CCP (который писать не надо, т.к в качестве него используется CCP монитора) и реализация очень простых процедур LOAD, SAVE и KILL. Кстати, заметьте, что (в отличие от Хамелеон-ДОС) я предусмотрел в примитивной DOS и обработку дисковых ошибок.

Благодаря простоте алгоритма примитивная DOS умещается в 2 кб, а, благодаря обмену физическими секторами (а не логическими в 128 байт), работает на порядок быстрее, чем CP/M, что особенно заметно при использовании больших (по меркам 8-ми разрядки) партиций винчестера в 8...16 мб. Значительно большее напряжение мозга требуется, чтобы ввести в примитивную DOS возможность повторно использовать место занимаемое удалёнными файлами.

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

Как и для всех DOS без фрагментирования, чтобы получилась пригодная для эксплуатации система нужна ещё сервисная программа SQEEZE. Такая же встроенная команда для "сборки мусора" имеется в CCP ОС ДВК. Эта команда опасна, т.к может привести с гибели данных, потому её рекомендовалось применять лишь на качественных дискетах. При её запуске задаётся вопрос "Are You sure?" и работает она иногда очень долго, т.к сдвигает большой массив информации схлопывая пустоты между файлами. Кстати ОС ДВК, хоть и профессиональная система, но судя по необходимости "сборки мусора", в ней не используется фрагментация файлов, хотя повторное использование места от удалённых файлов есть.

Выполнять сдвижку файлов можно без опасения на RAM-дисках. И также на винчестерах, т.к на них обычно не бывает дохлых секторов. Хотя для винчестеров, как раз освобождение места на диске после удаления файлов не столь актуально, т.к на винчестерах которые можно поиметь сейчас места очень много.

DOS расположенная в ПЗУ и работающая на РК с базовой архитектурой, т.е только с ОЗУ в 32 кб не в состоянии полностью заменить магнитофон. Т.к, в любой DOS в этом ОЗУ требуется размещать, как минимум, один дисковый буфер размером с физический сектор (в данной DOS это CATBUF), который в случае дисковода и древнего винта имеет размер в 512 байт (а у современных винтов и флэшей аж 4 кб). Таким образом программу размером в 28.5 кб дисковая DOS без наличия дополнительного ОЗУ выше 8000 никак загрузить не сможет. По этим же причинам отладчик Г.Штефана загружающийся сразу ниже RAMTOP 7500 не запустить из DOS.

Если же требуется запуск программ размером в 28.5 кб, то это потребует расширения не только ПЗУ на 2 кб, но и ОЗУ. В минимуме достаточно расширения ОЗУ на 8 кб в окне A000...BFFF, что можно сделать (в случае 565РУ5) несложной коррекцией схемы приводящей к "открытию ОЗУ" в области A000...BFFF, или (в случае двух банок РУ3) путём монтажа статического ОЗУ 6264 (у которого объём как раз 8 кб). Речь о DOS не для RAM-диска из ОЗУ A000, а для дисковода.

Такая более сложная (чем удвоение объёма ПЗУ до 4 кб) доработка позволяет не только убрать дисковые буфера и раб.ячейки DOS из основного ОЗУ РК ниже 8000, но и позволяет в этом же доп.ОЗУ работать самой DOS. Если часть кода переместить в ПЗУ, то даже CP/M для дисковода сможет работать в этом окне ОЗУ A000...BFFF.

Однако для тормозного РК с его крошечным ОЗУ применение тормозной CP/M - это всё-же не лучшее решение. По сравнению с RK-DOS или любой другой DOS с цельносекторным обменом, ОС CP/M работает, как минимум, раз в 5 медленнее, и если стоИт задача только запустить игру, нет смысла тратить в ПЗУ целых 8 кб вместо 2 кб.

Всё-равно из-за нехватки объёма ОЗУ на РК не удастся прогонять фирменные CP/M пакеты и компиляторы ЯВУ. Даже самый примитивный CP/M бейсик-интерпретатор размером в 24 кб оставляет в ОЗУ РК слишком мало ОЗУ для бейсик программ (а MSX бейсик в 33 кб вообще не запустить на РК86). Хотя для программиста 80-тых годов ОС CP/M даже на машине со столь крошечным ОЗУ была бы очень полезной, т.к CP/M ассемблер позволил бы транслировать исходники любого размера.