ОС для Специалиста_МХ: Commander/MXOS

[SpaceEngineer]

А тут не понятно. Я когда первые опыты делал тоже делал ПЗУ до FFBF. А оказалось, RAMFOSу надо доступ в ОЗУ, куда он копирует систему. Т.е., диск ограничивается до BFFF. Я же ограничил до 7FFF по двум причинам:
1. При поддержке SD карты большой встроенный диск не требуется.
2. Постоянный доступ к экрану позволяет часть процедур, работающих с ним, расположить в ПЗУ. В том числе и код выбора режима на старте (вывод логотипа и т.д.).

Да, ещё можно шрифт держать в ПЗУ и рисовать прямо из него.
Я у себя сделал как в MX2, до 7FFF, но добавил возможность джамперами подключить старшие адреса ПЗУ к регистру страниц рам-диска. Т.е. запись в порт FFFE с числом на ШД включит одну из 32 кб страниц. Пока ещё не проверял это. Но уже ясно, что 32 кб или даже 64 кб для системы мало. Особенно когда у меня на "системном разделе" будут одновременно сидеть MXOS, Ramfos со своими редактором и ассемблером, и куча мониторов.
Но вообще я хочу все эти фишки сделать отключаемыми, для совместимости с железом, имеющимся у людей. Причем через файл (config.sys?), а не через перекомпиляцию исходников.

- - - Updated - - -

Вот и закончилось место в DOS.SYS... Придётся выкинуть из него п/п обмена с магнитофоном.

[Advertiser]

[HardWareMan]

Ну, технически, можно действительно всё жирное системное держать в ПЗУ (в том числе полноценный знакогенератор на всю cp866, например), а освободившееся место в ОЗУ использовать для расширенного сервиса. Более того, если регистр банка сделать обнуляемым по аппаратному сбросу + вычитываемым обратно, тогда в принципе весь BIOS и сервис DOS можно посадить в ПЗУ, сохраняя выбранную страницу перед вызовом нужной подпрограммы в ПЗУ. А сами файлы знакогенератора и BIOS/DOS можно расположить в рамках файловой системы ROM диска, всё равно фрагментация файлов тут не бывает. И тогда в принципе не будет каких-либо ограничений.

[SpaceEngineer]

Ну, технически, можно действительно всё жирное системное держать в ПЗУ (в том числе полноценный знакогенератор на всю cp866, например), а освободившееся место в ОЗУ использовать для расширенного сервиса.

Знакогенератор в MXOS и так на все 256 символов и занимает 2 кб, при том, что по умолчанию п/п вывода текста работает в KOI-7. В оригинале знакогенератор работал из ПЗУ, перед выводом символа его изображение копировалось в небольшой буфер. Vinxru сделал опцию компиляции проекта, где можно знакогенератор пересадить в ОЗУ на E900-F0FF (это место ничем не занято), и рисовать прямо из него, без временного буфера. И программку, чтобы переключить обратно на шрифт в ПЗУ.

Более того, если регистр банка сделать обнуляемым по аппаратному сбросу + вычитываемым обратно

В моей схеме он обнуляемый, там ТМ9 стоит. А вот читать его обратно - зачем? В памяти просто есть переменная, где хранится номер страницы. В обновлённой ОС у меня даже ее не будет, с номером страницы будет работать драйвер FAT12/16 внутри себя.

А сами файлы знакогенератора и BIOS/DOS можно расположить в рамках файловой системы ROM диска, всё равно фрагментация файлов тут не бывает. И тогда в принципе не будет каких-либо ограничений.

Фрагментация бывает, там же fat-подобная файловая система (а я переделываю на FAT12/16). Но, в принципе, системный раздел можно специально форматировать так, чтобы определенные программы располагались определенным образом (как сейчас с файл шрифта font.bin). Но, имхо, это лишнее. У Специалиста и так дофига памяти под ОС - целых 16 кб (в отличие, например, от Ориона). Просто надо это место грамотно использовать. Не держать все сервисы резидентно в памяти, а подгружать по необходимости. Тот же Нортон, текстовый и hex редакторы, format.com - грузятся на место друг друга. В Ramfos то же самое сделано для редактора, ассемблера, дизассемблера, отладчика. Я хочу сейчас сделать п/п работы с магнитофоном в виде отдельной программы, сервиса или драйвера, автоматически загружаемого в какую-то область при необходимости. А пока пытаюсь хоть оригинальному MXOS скормить реальный файл через звковуху ПК. Не нравится ей формат. Через Монитор-2 получилось. Наверное, у MXOS формат заголовка другой. Какие вообще есть форматы файлов на ленте для Специалиста? И стоит ли вообще с этим заморачиваться? В принципе, через мониторы можно грузить, а в MXOS их много разных. Только как сохранять загруженное из памяти? В MXOS нет такой опции.

[SpaceEngineer]

Выложил апдейт на гитхабе.
Стоит открывать новую тему? Может быть я просто развиваю Коммандер, в может быть в итоге получится новая ОС, гибрид Коммандера и Рамфоса.

[fifan]

Наверное стоит здесь продолжать. Всё по теме.

[SpaceEngineer]

Продолжаю переход на FAT16. RAM и флеш диск уже единый, правда, до 512 кб пока. Таблица FAT и каталог (до 32 файлов) в памяти разрослись до 6 кб, пришлось временно перенести их в подэкранное пространство. Работа системы заметно замедлилась! Система при любом поводе дёргает загрузку FAT и каталога в буфер, а это теперь долго, т.к. надо качать 6 кб. И сама работа с FAT стала дольше, т.к. она теперь большая, да ещё и с 16-битной арифметикой. Поддержка FAT12 ту не особо поможет, она даст небольшую экономию памяти, но усложнит арифметику. Похоже, придётся, для увеличения скорости, объединять 256-байтные секторы в кластеры, хотя бы по 4 штуки (1 кб). Тогда FAT16 для 512 кб диска займет 1 кб - уже приемлемо. Но для 2 Мб флеш диска она будет опять 4 кб; на нём придется делать кластеры ещё крупнее.

Для рам-диска можно вообще избавиться от буферов в памяти, и работать с FAT и каталогом в нём напрямую (я перенёс из нортона в биос побайтовый драйвер обмена с рам-диском, так что теперь есть п/п чтения и записи байта). Но это не прокатит для некоторых устройств, которые могут ЗАПИСЫВАТЬ данные только целыми секторами (к таким относится флеш-диск). Так что какой-то буфер всё же нужен. Тут есть два варианта. Первый - сделать механизм кеширования, т.е. выделить 1-2 кб под кэш, и грузить туда секторы FAT и каталога с устройства по мере надобности, и из него же записывать (с загрузкой и записью секторов, относящимся к данным файла, вопросов нет - буфер нужен только для FAT и каталога). Второй - выделить под кэш место на рам-диске, в виде файла, или вообще целую 64к страницу откусить. Загрузка-выгрузка через быстрый блочный драйвер, анализ/обновление через медленный побайтовый драйвер. Это решит проблему памяти, но не решит проблему скорости. С ней бороться можно только объединением секторов в большие кластеры.

Уже потеряна совместимость с некоторыми программами под саму MXOS - теми, которые используют низкоуровневый доступ к диску. Например, MON2.COM работает со старым форматом дескриптора файла (имя в формате 6.3, длина дескриптора 16 байт). Я дизассемблировал и добавил в проект MON2.COM и редактор E.COM, нужна помощь в их изучении и комментировании. После этого можно будет обновить в них те части кода, где была потеряна совместимость. А заодно составить таблицу директив монитора, раскрасить редактор и добавить в него строку подсказки (а то вообще не понятно, как в них работать).

Заметил одну неприятную особенность, связанную с загрузкой файлов и присущую и оригинальному коммандеру. Обмен с накопителями идет блоками по 256 байт, и драйвер не может считать меньше (в 32-байтном окошке просто нет места для еще одной инструкции - декремента счётчика байт). Поэтому если вы, например, напишете драйвер размером 400 байт, и попытаетесь для экономии памяти загрузить его впритык ПЕРЕД чем-то важным, то драйвер диска всё равно считает 512 байт и затрёт хвостом это что-то важное. Я пока с этим ничего делать не буду, но, теоретически, можно это исправить, сделав п/п загрузки файла поумнее. Надо, чтобы она последний кластер файла грузила не прямо в память, а во временный буфер, а потом из него копировала бы в память только нужное количество байт.

Апдейт на гитхабе. Рам-диск и флеш-диск объемом больше 512 кб пока не работают, т.к. в системе один и тот же размер FAT и каталога (даже для системного ром-диска).

[SpaceEngineer]

Запуск на реальном Специалисте. Стартовый экран - системный ром-диск и инфоапнель. Объём свободной памяти выдается стандартной п/п 0C830h. Не знаю, почему MXOS сообщает ее как FAFFh (типа 64256 байт свободно), а не 8FDFh (36832 байт) - начало блока переменных под экраном.


Флеш-диск, 32 игрушки заняли почти весь объем 512 кб.


Рам-диск, накопировал на него файлов с флеш-диска. Всё работает, запускается.


В принципе, система уже юзабельна. При желании, 6 кб буфер fat/каталога можно впихнуть в область выше нортона, если использовать шрифт из ПЗУ. А ограничение в 512 кб обойти тем, что буквы B и C отдать под рам-диск, а E F G H - под флеш-диск. Для переброски файлов в рамфос сделать рам-диск D в формате рамфоса, одну или две страницы.

- - - Updated - - -

Ах да, забыл сказать - драйвер магнитофона теперь живет в отдельном файле tape.com, загружаясь в (пока еще) свободное место в верхнем ОЗУ. Если его не запустить предварительно, попытка работы с магнитофонными функциями просто перезагружает систему. В dos.sys освободилось 300 байт, которые уже, впрочем, почти все заняты.
Из-за особенностей загрузки файлов, о которой я упомянул выше, под драйвер магнитофона пришлось выделить 512 байт в памяти. Думаю, можно в него пересадить ещё что-нибудь ненужное, например магнитофонные функции из нортона (там зачем-то реализованы свои п/п записи и чтения файла с заголовком с ленты, хотя в dos.sys похожие уже есть).

Скорее всего, придётся двигать нортон с D000h повыше - для dos.sys уже мало места осталось. Или разбить dos на две части, вторую расположить на F800-FFBF, как в рамфосе.

[fifan]

Две подсказки, если они будут услышаны:
1. Имена файлов лучше писать прописными буквами, а не заглавными. Это конечно в случае, если будут поддержаны каталоги. Их имена заглавными буквами.
2. Версию коммандера нужно обновить до 2.1, например. И надпись "(С) Санкт-Перербург 2022" тоже будет смотреться красиво.

- - - Добавлено - - -

Кстати test_fif.com (судя по названию мой) давно обновился. Вот исходник и бинарник, замени. В новой версии сделано правильное вычисления количества страниц RAM-диска и ещё что-то, не помню. Запускается он и с РАМФОСа и в качестве тестовой ПЗУ, записанной в 2 кБайтную 2716.

[SpaceEngineer]

Кстати test_fif.com (судя по названию мой) давно обновился. Вот исходник и бинарник, замени. В новой версии сделано правильное вычисления количества страниц RAM-диска и ещё что-то, не помню. Запускается он и с РАМФОСа и в качестве тестовой ПЗУ, записанной в 2 кБайтную 2716.

Тест странно работает. Объем рам-диска из одной линейки РУ5 определил как 320 кб, а из одной линейки РУ7 - как 512 кб. Проверил "3 линейки" и завис. В эмуляторе же все четко, только некоторые линейки микросхем не закрашиваются (напр. когда 256 кб). Другие тесты правильно работают, и п/п определения объема доп. ОЗУ из рамфоса vinxru тоже.

Экранная область ОЗУ в твоем тесте не тестируется. Она просто заливается по очереди разными цветами, а тестировать байты и биты кто будет? Вообще, при битой памяти тест не будет работать даже из пзу, т.к. используется стек.

Тест-MX сделан по-другому. Первая половина теста работает только из ПЗУ по адресу 0000h, без стека и call, поэтому все подпрограммы заинлайнены, даже бип динамиком. Он сначала тестирует верхнюю половину памяти 8000h-FFDFh. Поэтому в Специалисте-МХ с более чем 32 кб ПЗУ надо ставить перемычку, которая отключает верхнюю часть ПЗУ и открывает ОЗУ выше 8000h. Вначале тест заполняет экранную память (8000h-BFFFh) паттерном 33 33 CC CC, потом 55 AA 55 AA, и читает его обратно. При этом в регистр цвета выставляется цвет символов = цвет фона, поэтому это выглядит как просто заливка экрана сплошным цветом. Потом так же тестируется память C000h-FFDFh. Если тест верхней половины ОЗУ прошел успешно, программа рисует интерфейс, копирует вторую свою половину в верхнее ОЗУ, так, чтобы задеть область непереключаемого ОЗУ, где сидит драйвер рам-диска, и прыгает на нее. Там она отключает ПЗУ и тестирует нижнюю половину ОЗУ 0000h-7FFFh, а потом и рам-диски.

Вот тут я дизассемблировал его и начал комментировать, но бросил, когда дошел до драйвера рам-диска. Оказалось, что это старая версия теста, не поддерживающая множественные страницы доп. ОЗУ.
test_mx.zip

[SpaceEngineer]

Спасибо. Да, это твой тест. Я для себя все тесты переименовал, чтобы не путаться. Стоит в релизе обратно переименовать?

1. Это пока геморно сделать. MXOS почему-то работает в КОИ-7, где только заглавные буквы, хотя имеет полноценный шрифт. Наверное, так сделано для совместимости со стандартными программами. К слову, большинство старых игр запускается под коммандером без проблем, т.к. его биос (в отличие от рамфоса) почти совместим не только с Монитором-2, но даже с Загрузчиком (есть точки входа C037h, C377h и т.п.). Только цветные игры становятся ч/б, т.к. регистр цвета другой.
В MXOS есть возможность переключить п/п печати строки на КОИ-8, но для этого в начале строки должен стоять Esc + '('. В начале каждой строки, т.к. после ее вывода режим сбрасывается обратно на КОИ-7. Не очень-то удобно, вот думаю, как бы сделать получше. Можно, например, чтобы по умолчанию был включен КОИ-8, а КОИ-7 включать перед запуском программы пользователя. И чтобы режим КОИ не сбрасывался сам. А то вставлять Esc + '(' перед каждым именем файла в таблице....

2. Думаю, в копирайт надо записать имена всех контрибьютеров, в первую очередь самого Константина Юденцова. И vinxru тоже, он сделал большую работу по комментированию дизассемблированного кода. Указывать город - странная традиция.
Кстати, когда запускается редактор, появляется заставка EDITOR VERSION 4.1, (C) OMSK KSOFT '92. Интересно, что это за KSOFT такой, и имеет ли он отношение к автору системы.