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

[SpaceEngineer]

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

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

- - - Updated - - -

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

[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 и каталога (даже для системного ром-диска).

[Advertiser]

[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]

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

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

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

[SpaceEngineer]

Удалось ужать буфер fat в памяти до всего 1 сектора (256 байт). Производительность системы вернулась на прежний высокий уровень. Боттлнек был в загрузке всего fat и каталога целиком (а они раздулись до 7 КБ), а 16-бииная арифметика не влияет. Теперь fat грузится секторами по 256 байт по мере надобности. То же самое сделаю с буфером каталога. Для удобства и скорости это будет lru кэш на 1-2 КБ (правда, я пока не знаю, как фиксировать время доступа без часов или таймера... хм, а ведь таймер у нас есть!)

Какой формат дискет используется на Специалисте? Открыл odi образ дискеты от Рамфоса, увидел там знакомые D3 D3 D3 ИМЯ. Странное дело, неужели даже дискеты непрерывные, как рам-диск? Fifan, можешь прокомментировать, какой формат дискет поддерживает твой драйвер? (Я его ещё не изучал толком)

Думаю, стоит использовать формат IBM, чтобы можно было перекидывать файлы на ПК (в сообществе Орионщиков например все ещё много таких олдфагов, да). А это значит, что размер сектора надо увеличить до 512 байт.

А как дела обстоят с SD картой? Там сектора вообще огромные могут быть, а даже 4 КБ это уже много для Специалиста. Если сделать на уровне ОС максимальный размер сектора 1 КБ, это приведет к ограничению на способ форматирования SD карты. Это ок?

В принципе, ограничение можно обойти, если держать кэш в доп. странице ОЗУ. Хоть 32 КБ сектор можно поддерживать. Но это оверкилл для Специалиста, производительность будет очень низкой. Пока целюсь на кэш 1-2 КБ в основном ОЗУ.