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

[fifan]

Хочу начать новую тему касаемую программного обеспечения для Специалиста_МХ Commander, далее доработанного Vinxru до MXOS.

Я давно хотел свести данные по этому ПО в отдельную тему. Последним толчком для этого послужило написание мною драйвера дисковода под Commander. Обо всём по порядку. Я буду пользоваться описанием данного ПО когда-то предоставленным HardWareMan'ом и выдержками с описания MXOS от Vinxru.

Commander написал в 1992 году Константин Юденцов (ныне покойный) и он является альтернативной RAMFOS'у операционной системой для Специалиста_МХ. Основными достоинствами/недостатками являются:
1. нет поддерживаемых системой верхней и нижней строки состояния;
2. система не содержит форму для открытия файла;
3. нет поддержки звука на основе К580ВИ53;
4. нет поддержки цвета;
5. поддерживается значительно меньше специальных кодов при выводе на экран;
6. поддерживается лишь одна модель принтера;
7. поддерживается лишь 64 кБайт дополнительного ОЗУ (что в сумме дает 128 кБайт), которое используется как RAM-диск.

http://www.spetsialist-mx.ru/images/commander.png

Поддерживаются две кодировки KOI-7 и KOI-8, переключаемые как с клавиатуры, так и ESC-последовательностями (ESC+'(' и ESC+')'). Знакогенератор содержит 256 символов. Используется раскладка клавиатуры Стандартного специалиста. При холодной перезагрузке запускается файл B:AUTOEX.BAT, затем A:FORMAT.COM B:, а затем A:NC.COM. Устройство A: - это ПЗУ, устройство B: - это оперативная память. Максимально поддерживается 8 устройств.
При перезагрузке инициируемой программами запускается лишь A:NC.COM. Папки самой операционной системой не поддерживаются, но это можно реализовать через драйверы. Максимальное количество файлов в папке - 48 штук, но оболочка поддерживает отображение лишь 36 файлов. Остальные файлы Вы не увидите, не сможете выполнять над ними действия из оболочки, но сможете запустить их командной строки. Максимальный размер файла - 64 кБайт, но оболочка может работать лишь с ~36 кБайт. При попытке скопировать (и т. п.) файл большего размера произойдет переполнение буфера, уничтожение системных переменных, затем экрана, затем самой ОС в зависимости от размера файла.

Клавиши выполняют следующие команды:
ESC - очистка командной строки;
TAB - переход между панелями;
F1, F2 - выбор накопителя для левой и правой панели;
F3 - отображение на неактивной панели информации о накопителе активной панели;
F4 - запуск внешнего редактора E.COM для выбранного файла;
F5 - копирование файла;
F6 - изменение имени файла / перемещение;
F7 - загрузка файлов с ленты (магнитофона) на накопитель;
F8 - удаление файла;
F9 - сохранение файла с накопителя на ленту.

Следующий раз я приведу структуру FAT, используемую в Commander'е. Остальное можно прочитать здесь (http://www.spetsialist-mx.ru/Soft/MXOS.rar).

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

Продолжу.

Commander поддерживает лишь 64 кБайт RAM-диска и отображается как накопители B-H. Причём при старте эти диски являются копиями друг друга. Но каждый из этих дисков можно настроить под свои нужды используя свои драйверы (что и сделал я). Система адресует диски 256 байтными блоками. А так как последние 64 байта адресного пространства всегда занимают основное ОЗУ и устройства, то целых блоков получается 255.

Файловая система подобна FAT. Накопитель максимальным объемом 64 кБайт разбит на 256 блоков (кластеров) по 256 байт. Первые 4 кластера содержат служебную информацию. Нулевой кластер - это таблица FAT, следующие 4 кластера - каталог.
Таблица FAT содержит 256 чисел. Число 5 по адресу 8, значит что за 8 блоком следует читать 5-ый блок. Последний блок замыкается сам на себя, то есть у последнего блока в ячейке 7 должно быть число 7. Свободным блокам в таблице FAT соответствует число 0. Из рисунка видно как выглядит распределение чисел в FAT в зависимости от номера кластера и количество кластеров.
Каталог находящийся в кластерах с 1-го по 3-й содержит список файлов. 48 файлов по 16 байт на каждый. Конец каталога - это байт FFh в начале имени файла.

57407

Формат дескриптора файла:
6 байт - имя файла;
3 байта - расширение файла;
1 байт - атрибуты файла: 00h - обычный файл, 01h - системный файл;
2 байта - начальный адрес загрузки в ОЗУ, он же и стартовый;
2 байта - размер файла в байтах - 1;
1 байт - ?;
1 байт - номер первого кластера в FAT.

Я не зря в предпоследнем байте поставил знак вопроса. У HardWareMan'а - это флаг автозапуска, 00h - данные, FFh - программа. А вот Vinxru так и не понял его назначения. Я в одном месте листинга MXOS нашёл, что при создании файла почему-то сюда записывается как бы "накопленный" байт, который получается при суммировании всех байтов программы, но не является контрольной суммой файла.

В следующий раз я опишу MXOS от Vinxru, которая является доработанной/переработанной версией Commander'а.

Здесь я цитирую со своей редакцией описание ПО Vinxru (https://github.com/alemorf/retro/tree/master/specialist-mxos).

MXOS - это название операционной системе я дал сам, поскольку оригинального названия я не нашел.
Исправленные недоработки:
В файле DOS.SYS
1. поддержка ДОЗУ (RAM-диска) большего объема, чем 64 кБайт;
2. размер ПЗУ у Специалиста_MX2 всего 32 кБайт;
3. загрузка шрифта в ОЗУ (ускорение работы и возможность загрузки ОС с любого накопителя);
4. включена инициализация контроллера цвета при запуске.

В файле NC.COM
1. включен цвет;
2. Bподдержка ДОЗУ (RAM-диска) большего объема, чем 64 кБайт;
3. исправлена ошибка определения свободного объема.

MXOS более шустрая и обладает более приятным интерфейсом напоминающим Norton Commander. Любое расширение файла можно привязать к любой программе. Список соответствий хранится в файле NC.EXT, максимальный размер которого 36 кБайт. Но при этом MXOS содержит меньше сервисных возможностей и не совместима с RAMFOS'ом. Оригинальная ОС (Commander) поддерживает лишь 64 кБайт дополнительного ОЗУ (что в сумме дает 128 кБайт), которое используется как RAM-диск. Запуск с большим объемом памяти приведет к зависанию, так как в порт выбора страницы записывается случайное число. Исправленная версия ОС поддерживает 448 кБайт дополнительной памяти, т. е. 7 страниц как накопители B...H. Многие возможности можно реализовать дополнительными модулями. Например, в комплекте идет драйвер ПЗУ подключаемого к порту расширения.
MXOS поддерживает BAT-файлы и передачу аргументов запускаемым программам. При холодной перезагрузке запускается файл B:AUTOEX.BAT, затем A:FORMAT.COM B:, а затем A:NC.COM. Устройство A: - это ПЗУ, устройство B: - это оперативная память. Максимально поддерживается 8 устройств. При создании собственного ПЗУ (загрузочного диска A:) вы можете разместить AUTOEX.BAT так же и на диске A:, а в нем разместить запуск драйверов. Если при запуске компьютера зажать клавишу ?, то MXOS сразу перейдет к загрузке программы с магнитофона. Если при запуске компьютера зажать клавишу ?, то MXOS пропустит запуск B:AUTOEX.BAT.
В отличии от "монитора" стандартного Специалиста, MXOS не содержит режима работы с консоли и соответственно директив вводимых с клавиатуры. Вся работа происходит в диалоговом режиме.
В оригинальной системе ПЗУ по адресам 800h...FFFh должно содержать знакогенератор. Перед выводом каждого символа на экран, этот символ будет копировать из ПЗУ в ОЗУ. Что не только медленно, но и не позволяет отвязать систему от ПЗУ.

http://www.spetsialist-mx.ru/images/MXOS.PNG

Теперь пришло время рассказать о прекрасном инструменте от автора называемым "подключаемыми драйверами накопителя". Авторы вышеупомянутого ПО и b2m всегда высказывались, что достаточно просмотреть файл DISK_H.COM и всё сразу станет понятным о механизме подключения сторонних накопителях.

Давайте рассмотрим этот драйвер (дизассемблированный листинг от Vinxru, но в мнемонике Z80). Т.к. он не большой я приведу его полностью.
Обработчик имеет три функции (номер передаётся в регистре Е):
1 - записать блок (256 байт, номер блока в регистре D, адрес в HL);
2 - считать блок (256 байт, номер блока в регистре D, адрес в HL);
3 - выдать размер диска (в блоках, в регистре А).
Обратиться к обработчику текущего диска можно по адресу С863h.


; Установить драйвер
org #fa00
ld a, #07
ld hl, #fa0f
jp sys_installDriver ; посадить обработчик на один из 8 дисков

; Сделать активным диск H
LFA08 ld e, #01
ld a, #07
jp sys_fileGetSetDrive ; выдать/установить текущий диск

LFA0F ld a, e ; Запись не поддерживается
cp #01
ret z
push hl ; сохранение регистров
push de
push bc
ld a, #90 ; настройка портов
ld (IO_EXT_MODE), a
ld a, #0d ; 6 вывод = 1
ld (IO_KEYB_MODE), a
ld a, e ; определение размера
cp #03
jp z, LFA39
cp #02 ; чтение 256-байтного блока
jp nz, LFA51 ; не верная функция - выход

; чтение блока
; вход: [D] - номер блока
; вход: [HL] - адрес буфера в памяти
xor a
ld e, a ; [DE] = 0 - начальный адрес в блоке
LFA2D call LFA61 ; чтение данных
ld (hl), a ; сохранение данных в памяти
inc hl ; инкремент адреса в буфере
inc e ; следующий адрес в блоке
jp z, LFA51 ; выход, если блок закончился
jp LFA2D ; иначе - цикл

; определение обьема ПЗУ
; выход: [A] - количество секторов на диске
LFA39 xor a
ld b, a
ld d, a
ld e, #04 ; [DE] = 4 - начальный адрес в блоке
LFA3E call LFA61 ; чтение данных
cp #ff
jp nz, LFA47 ; переход, если не конец диска
inc b ; инкремент счётчика байтов
LFA47 inc e ; инкремент адреса в блоке
ld a, e
cp #c0
jp nz, LFA3E
ld a, #c0 ; И общий обьем ПЗУ получается ROM_SIZE-0FFh
sub b ; A = A - B
LFA51 push af
ld a, #0c ; 6 вывод = 0
ld (IO_KEYB_MODE), a
ld a, #9b ; восстановление режима портов
ld (IO_EXT_MODE), a
pop af ; восстановление регистров
pop bc
pop de
pop hl
ret


; чтение данных
; вход: [DE] - адрес
; выход: [A] - данные
LFA61 ex de, hl ; [HL] - номер блока/байт
ld (IO_EXT_B), hl ; передача адреса
ld a, (IO_EXT_A) ; приём данных
ex de, hl
ret

А теперь я опишу назначение данного драйвера. Он предназначен для загрузки каталога и запуска файлов с внешнего ROM-диска, подключаемого к К580ВВ55 (порт программатора). Его объём до 64 кБайт. Нигде нет его схемы, но из конфига эмулятора от b2m я предполагаю что данные ПЗУ подключаются к порту А ППА, а адрес - к портам В и С. Автор выбрал для подключения внешнего ROM-диска накопитель H.

Юденцов может и хотел написать драйвер дисковода, но наверное не успел. Я где-то здесь на форуме написал в сердцах что не хочу писать его (драйвер), но всё же почти сделал это. На данный момент я сделал вывод корневого каталога с дискеты, подсчёт занимаемого места файлов корневого каталога. Работает операция копирования содержимого выбранного файла в RAM-диск, но где-то скрылась ошибка и данные переписываются неверно. Сейчас я перечислю все трудности, с которыми я столкнулся при написании драйвера:
1. в MX-DOS (ОС контроллера дисковода) дискриптор файла очень отличается от FAT дискриптора файла. А именно название файла не 8 символов, а 6, причём все буквы только заглавные и в кодировки КОИ-7;
2. не поддержено разбиение на каталоги. Так что я на первом этапе вывожу только корневой каталог дискеты. Переход в другие каталоги я хочу сделать путём переименования каталога в EXE файл и передачей ему номеров 1-го сектора и 1-й дорожки открываемого каталога;
3. Т.к. Commander поддерживает только 64 кБайта или 256 кластеров, то отображаемая информация по F3 то же будет не верной. Если принять максимальное количество файлов в одном каталоге в MX-DOS может быть 16 с максимальным размером каждого файла 64 кБайта то получаем 16*64 кБайт=1024 кБайта. Максимальная ёмкость дискеты всего 800 кБайт.

Исходники драйвера я выложу позже.

Сейчас я опишу алгоритм построения программы драйвера. Входными переменными, об этом писалось ранее, являются номер кластера и адреса буфера. Номер кластера может принимать значения от 04h...feh. Причём последние в этом списке значатся:
feh - чтение/запись каталога;
fdh - чтение/запись каталога;
fch - чтение/запись каталога;
fbh - чтение/запись таблицы FAT.
Т.е. при запросе кластера с этими номерами мы уверены, что идёт обращение к каталогу или таблице FAT. Остальные кластеры - это обращение к 256 байтному блоку памяти с конкретным номером. Т.к. каталог у нас будет состоять не более чем из 16 файлов (максимальное количество каталогов/файлов в одном каталоге MX-DOS), то обращение к кластерам с номерами fdh/feh можно просто заменить заполнение кластерами символом ffh.
А вот обращение к 04h...fah - это работа с конкретным кластером. Я сделал так. Опрашиваю весь каталог из области fc00h...fcffh и по данным каждого дескриптора файла я вычисляю начальный и конечный кластеры занимаемые каждым файлом. Если этому диапазону принадлежит запрашиваемый кластер, то я считываю в буфер запрашиваемую область. Т.к. в MX-DOS можно считывать только один сектор (1/10 часть дорожки = 1024 байт), то необходим выбор какую 1/4 часть нам использовать. Номер 1-го сектора/дорожки мы берём из дескриптора соответствующего файла дискеты.
Запись кластера должна действовать в обратном порядке, но пока мною не написана.
Заполнение таблицы FAT я сделал при обращении к кластеру fbh. Я подсмотрел листинг файла dos.sys от Vinxru. Там есть подпрограмма fileCreate, которая создаёт файл со входными данными дескриптора. Но применить её полностью мне не удалось. Она сначала ищет в каталоге имя создаваемого файла и если он есть, то сначала удаляет его. На этом этапе у меня всё зависало и я убрал эти обращения. Тупо подставляю переделанной подпрограмме дескриптор и она помещает дескриптор в каталог и соответственно размещает номера кластеров в таблице FAT. И всё.
Функцию "выдать размера устройства" я сделал так. Я просматриваю весь каталог и суммирую число кластеров занимаемое каждым файлом. Хотя система число кластеров больше 256 не воспринимает. Так что выводимая информация по F3 будет недостоверной.
В атаче исходники программы. Из архива файл ramfos.bin нужно переименовать в ramfos.rom и подставить в эмулятор emu.

[fifan]

После долгого перерыва решил закончить драйвер. Но просмотрев исходники я понял что не помню некоторые моменты в программе. Почему например, кластеры по которым я считываю каталог с дискеты имеют номера feh, fdh, fch, fbh - таблицы FAT? В памяти страницы эти кластеры считаются системными и имеют номера с 0-го по 3.
Буду и дальше копать в этом направлении и есть задумка, и она верная, что с построением каталога необходимо не только тупо переписывать дескриптор файла, но и само тело файла. Так же необходимо при построении каталога следить за объёмом страницы и не превышать размера в 255 кластера. На каждый каталог необходимо отводить 1 кластер (на дискете он имеет размер в 1 кБайт) и писать небольшой драйвер, который бы загружал в память параметры каталога (номера сектора/дорожки, количество файлов в каталоге). Название каталогов будет в виде NAME01.DIR, главного каталога MAIN.DIR. Vinxru в описании MXOS упоминал что есть средства для работы с файлом NC.EXT, в котором могут быть описаны действия выполняемые системой при разных расширениях файла. Однако ни готового файла, ни описания каков его синтаксис нет. Я б в этом файле описал расширение DIR.
И последнее. После успешного написания драйвера для дискет можно замахнутся и на SD каталог. Правда, подпрограммы работы с SD картой от Vinxru, взятые с loader'а занимают сравнительно много памяти - 3 кБ, что для драйвера многовато. Смысла запускать на МХ программы RKS я не вижу и присматриваюсь к расширениям CPU/I80. Наличие для каждой программы пары файлов (CPU/I80) обязательно, т.к. в первом есть начальный адрес программы с расширением I80.

[fifan]

Разобрался со своими заморочками из предыдущего поста.
1. feh, fdh, fch, fbh - это старший байт буфера куда считывается кластер. Назначается системой и соответственно по этому значению система пишет данные в буфер с таблицы FAT или с директория.
2. В корне не верно писать сразу данные тела файла. Да и куда. По номеру кластера вычисляем какому файлу он принадлежит и считываем весь сектор (4 кластера) с дискеты. Нужный кластер передаём системе.
Пока сделал считывание корневого каталога с дискеты, подсчёт чтобы сумма байт считанных файлов в каталоге не превышала 63 кБайт. Лишние файлы не выводятся.
Запуск выбранного файла не происходит, система выводит ошибку. Нужно разобраться с расширениями запускаемые системой.

[Pyk]

Можно вопрос по Специалисту и Коммандеру?

Фрагмент кода nc.com:

call getch

; Стираем курсор выбранного файла
push psw
COLOR(COLOR_FILE)
call drawCursor
pop psw

; Анализ нажатий клавиши
mov c, a
jc mainLoop_ctrl

То есть после вызова getch (C803) проверяется флаг С, и при его установке происходит переход на mainLoop_ctrl:

mainLoop_ctrl: cpi 0Dh
jz ctrlEnter
jmp mainLoop_e

Никак не пойму, что же за признак такой возвращает процедура С803 в этом флаге и как он влияет на нажатие Enter в коммандере?

P.S. Вопрос снят: это признак нажатия клавиши "ПВ", которая выступает в роли Сtrl

[fifan]

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

[Pyk]

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

[HardWareMan]

Клавиатура МХ не отличается от стандартной. Изменен только метод опроса. Не нужно придумывать.

[b2m]

Клавиатура МХ не отличается от стандартной. Изменен только метод опроса. Не нужно придумывать.
Ну как-же? А esc,tab и функциональные клавиши? ;)

[HardWareMan]

Ну как-же? А esc,tab и функциональные клавиши? ;)
МХ делается из стандарта. Мы делали из Экспресса. Клавиатура не меняется - та же пленка. Все по букварю. Так что не верю!

Но кое-что все же замечу. Если вы об этом:
http://savepic.ru/12918471.png
То тут только сравнивать таблицы кодов.

Таблица кодов RAMFOS:
Offset 0 1 2 3 4 5 6 7 8 9 A B C D E F
00000430 81 0C 19 1A 20 20 20 08 09 18 0A 0D 00 C0 00 C6 Ѓ... ......А.Ж
00000440 51 5E 53 4D 49 54 58 42 40 2C 2F 5F BB FF 00 00 Q^SMITXB@,/_»я..
00000450 46 59 57 41 50 52 4F 4C 44 56 5C 2E 00 00 00 00 FYWAPROLDV\.....
00000460 4A 43 55 4B 45 4E 47 5B 5D 5A 48 3A B1 00 00 00 JCUKENG[]ZH:±...
00000470 3B 31 32 33 34 35 36 37 38 39 30 2D 05 0A 00 00 ;1234567890-....
00000480 1B 8A 00 01 02 03 04 05 06 8B 8C 1F 00 00 06 30 .Љ.......‹Њ....0

Таблица кодов NC:
Offset 0 1 2 3 4 5 6 7 8 9 A B C D E F
000014A0 81 0C 19 1A 09 1B 20 08 80 18 0A 0D 00 00 00 00 Ѓ..... .Ђ.......
000014B0 71 7E 73 6D 69 74 78 62 60 2C 2F 7F 00 00 00 00 q~smitxb`,/....
000014C0 66 79 77 61 70 72 6F 6C 64 76 7C 2E 00 00 00 00 fywaproldv|.....
000014D0 6A 63 75 6B 65 6E 67 7B 7D 7A 68 3A 00 00 00 00 jcukeng{}zh:....
000014E0 3B 31 32 33 34 35 36 37 38 39 30 2D 00 00 00 00 ;1234567890-....
000014F0 00 01 02 03 04 05 06 07 8A 8B 8C 1F 00 00 00 00 ........Љ‹Њ.....

Таблица кодов ПСПЗУ:
Offset 0 1 2 3 4 5 6 7 8 9 A B C D E F
000004A0 81 0C 19 1A 09 1B 20 08 80 18 0A 0D 00 00 00 00 Ѓ..... .Ђ.......
000004B0 71 7E 73 6D 69 74 78 62 60 2C 2F 7F 00 00 00 00 q~smitxb`,/....
000004C0 66 79 77 61 70 72 6F 6C 64 76 7C 2E 00 00 00 00 fywaproldv|.....
000004D0 6A 63 75 6B 65 6E 67 7B 7D 7A 68 3A 00 00 00 00 jcukeng{}zh:....
000004E0 3B 31 32 33 34 35 36 37 38 39 30 2D 00 00 00 00 ;1234567890-....
000004F0 00 01 02 03 04 05 06 07 8A 8B 8C 1F 00 00 00 00 ........Љ‹Њ.....

Только RAMFOS отличился тем, что "03" и "09" (1B/09) он воспринимает как 2 дополнительных пробела, а нехватающие коды перенесены в функциональный ряд. Но это фиксится буквально за секунду руками в любом хексе. И я напоминаю, как именно выглядит пленочная клавиатура:
http://savepic.ru/12936920.jpg
Заметили особенность? Функциональный ряд начинается с F, потом F1 ... F8.

[b2m]

Если вы об этом:
Вот именно об этом. Почему в скобках указаны другие клавиши? И какой клавише соответствует клавиша "F" в ряду функциональных на плёночной?

[fifan]

Я отвечу. Это первоначальный вариант клавиатуры от самого автора Специалиста Волкова. Вот (http://www.spetsialist-mx.ru/images/Keyboard4.png) скан первоисточника. Видно что F - 1 клавиша слева в верхнем первом ряду - пересечение выводов 17 и 25 ВВ55.

[b2m]

Видно что F - 1 клавиша слева в верхнем первом ряду
Разве я спрашивал про клавишу F1? Я про ту, что слева от неё!

[HardWareMan]

Разве я спрашивал про клавишу F1? Я про ту, что слева от неё!
Он и ответил. Но не F1 а F - первая (написал прописью цифру) клавиша в функциональном ряду. Если смотреть на пленочную клавиатуру (что автора, что экспресса), то матрица 12х6 там видна не вооруженным взглядом, только 03 и 09 вынесены из-под пробела вбок.

[b2m]

Если смотреть на пленочную клавиатуру (что автора, что экспресса), то матрица 12х6 там видна не вооруженным взглядом
То есть в RAMFOS-е у нас отсебятина? Просто - говорим RAMFOS, подразумеваем MX. Вот и получается, что в MX несколько иная раскладка.

[HardWareMan]

То есть в RAMFOS-е у нас отсебятина? Просто - говорим RAMFOS, подразумеваем MX. Вот и получается, что в MX несколько иная раскладка.
Если не менять физическое расположение кнопок, тогда все будет соответствовать тому, что было в оригинале.

В RAMFOSе у нас то, что придумали авторы RAMFOSа. F как ESC и циклически сдвинутые влево коды кнопок F1 - F8. Но если fifan пилит свой СпецКомандер на основе NC из Омска, то его коды клавиш полностью совпадают со стандартом, хотя и работает программа на MXе. Я же не просто так привел сканкоды из оригинальных программ.

И да: MX - это доработка стандартного (STD) аппаратного обеспечения. RAMFOS это программная часть и ОС. NC не является RAMFOS, но работает именно на доработке MX.

[b2m]

Просто мне хотелось бы избавиться от разных раскладок у себя в эмуляторе для стандартного Специалиста и MX. Но я хоть убей не пойму, как разложить клавиши по матрице (в отношении esc,tab и функциональных).

[HardWareMan]

b2m, я тебя понимаю. Но думаю идеальным вариантом будет последовательность [ESC] - [F8], как оно есть на клавиатуре ([ESC] на клаве будет [F] в спеце). Если это реализуемо, конечно (вдруг там забандены какие-то функции эмульгатора).

[b2m]

Но думаю идеальным вариантом будет последовательность [ESC] - [F8], как оно есть на клавиатуре ([ESC] на клаве будет [F] в спеце).
Мне не нравится, что при таком раскладе в RAMFOS будет несоответствие функциональных клавиш. Дотошному пользователю же не объяснишь, что это не глюк эмулятора :)

[HardWareMan]

Если так беспокоит мнимое несоответствие, то делай отдельно RAMFOS и отдельно MX/MX2.

[uart]

А где сейчас можно найти исходники от vinxru? Причем интересует не сколько Commander, сколько RAMFOS. Хотя и все остальное с его github тоже интересно.

[b2m]

А где сейчас можно найти исходники от vinxru? Причем интересует не сколько Commander, сколько RAMFOS. Хотя и все остальное с его github тоже интересно.
vinxru теперь называется alemorf, и на гитхабе тоже: Ramfos (https://github.com/alemorf/retro/tree/master/specialist-ramfos/Ramfos)

[fifan]

Т.к. контроллеры дискет ушли с прошлым веком то я подумал о том не написать ли драйвер для работы с SD картой для Коммандера? Т.к. работа с SD картой под контроллером от Vinxru мною не много освоена, то начать нужно с него. В МХ режиме SD карта читается (https://youtu.be/AWXlcpEDTEw). Перечислю недостатки работы с SD картой под Коммандером:
1. пресловутые всего 6 символов в имени файла;
2. вывод только имён файлов без директориев (работа с директориями мною не освоена);
3. механизм запуска файлов вообще пока не ясен.

В окне Коммандера имя файла будет одно на реальную пару на SD карте, например так: DESTRO EXE - destroy.cpu/destroy.i80.

[SpaceEngineer]

Где теперь брать исходники? Я бы тоже поработал над коммандером. Давайте общий опенсорс проект запилим, а?

Что хочется сделать:
- больший размер кластера (4-8 секторов по 256 байт), или переход на fat12
- более длинные имена файлов. Совместимость ни с чем не теряем, ведь под коммандер нет софта, он только как оболочка используется?
- унификация RAM/ROM/FLASH дисков, любой размер и количество
- FLASH диск вместо ППЗУ, включенный в адресное пространство процессора наподобие страниц RAM диска (доработка архитектуры минимальная)
- поддержка записи во FLASH диск (как включенный вместо ППЗУ, так и через ВВ55)
- добить драйвер SD карты
- встроенный редактор, HEX редактор, ассемблер, дизассемблер, отладчик, Бейсик - можно портировать из RAMFOS, освежив интерфейс
- поддержка формы (окошка) выбора файла для этих программ
- две таблицы с раскладкой клавиатуры, одна для английского, вторая для русского. Так можно сделать нормальный ЙЦУКЕН/QWERTY. Мониторы и RAMFOS тоже можно доработать.
- поддержка шрифтов 6*8, 8*8, 6*10, 8*10 и переключение между ними в настройках. 8*8 и 8*10 будут очень шустрые, 6*8 и 6*10 для совместимости, или если надо больше текста вместить (напр. в HEX редакторе).
- поддержка микросхемы часов с CMOS памятью, куда можно сохранять настройки.
- ПЗУ можно вообще полностью исключить, оставить в нем тест и загрузчик ОС с флеш диска или SD карты. При перезагрузке показывать простое меню типа 1 - загрузка ОС, 2 - запуск теста (который может работать при неисправной памяти).

[CityAceE]

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

[b2m]

Где теперь брать исходники?
Добрые люди форкнули в своё время: https://github.com/VWarlock/retro/tree/master/specialist-sd_controller

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

Ой, наверное имелись ввиду вот эти исходники: https://github.com/VWarlock/retro/tree/master/specialist-mxos
Но репозиторий тот-же.

[SpaceEngineer]

О, спасибо. Сейчас пытаюсь в эмуляторе погонять те архивы, что были выложены тут. http://spetsialist-mx.zx-pk.ru/index19.html
Запускается, но не работает. Файл скопировать не может, запустить тоже (только некоторые). Что за текстовый редактор там? Никаких подсказок нет, как в нём работать, не понятно.

[SpaceEngineer]

Чем отличается exe от com? Вроде и тот, и тот - просто бинарный дамп, а адрес загрузки хранится в дескрипторе файла в каталоге.

[SpaceEngineer]

Кстати, хоть это немного оффтоп злесь. Я пробовал подредактировать таблицу кодов клавиш в рамфосе, чтобы вернуть стандартную раскладку. Рамфос работает, а вот софт... Некоторый работает, некоторый думает, что раскладка MX (свой драйвер у них что ли?), некоторые не распознают Esc (эта кнопка вроде отдельно обрабатывается даже в самом рамфосе).
Но я планирую добить эту переделку. У меня ведь железный Специалист с матричной клавиатурой, и иметь две разные раскладки клавиш функционального ряда, чтобы пользоваться и рамфосом, и коммандером, дико неудобно.

[SpaceEngineer]

Не понимаю логику автозапуска команд при перезагрузке. Порылся в исходниках, там такой порядок:

Сначала dos.sys вызывает:

В:AUTOEX.BAT
A:NC.COM

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

Потом NC.COM зачем-то вызывает:

A:FORMAT.COM B

Это вызывается однократно при холодной перезагрузке. Для этого читается байт из рам-диска - это работает лучше, чем решение, применённое в dos.sys. Поэтому после сброса команда форматирования не вызывается.

Видимо, идея была в том, чтобы в B:AUTOEX.BAT разместить запуск драйверов и команды форматирования остальных рам-дисков, но как это будет работать, если при включении компьютера на диске B: ничего нет? Вручную копировать батник не комильфо. К тому же, придётся каждый раз отвечать N на запрос форматирования дисков. А запуск драйверов при теплой перезагрузке всё же нужен: они слетают если, например, запустить Бейсик.

Нужно придумать другой механизм. Самое простое будет иметь два батника на A:, один для холодной перезагрузки, другой для тёплой. Запускаться они должны dos-ом, а не нортоном. Причём FORMAT.COM должен иметь опцию тихой работы, чтобы не надо было нажимать Y.

- - - Updated - - -

Запуск батника с диска A: не работает. Дос загружает батник не по тому адресу, который указан в атрибутах файла в каталоге, а по адресу FC00h (видимо, чтобы выполняющиеся из батника программы не затёрли его). Для этого используется функция fileGetSetAddr, которая подменяет адрес загрузки файла и прописывает его в атрибуты на диск. Но с ром-диском же это не работает! В итоге при запуске с ром-диска, батник загружается по тому адресу, который указан в атрибутах (а обычно это ноль), но анализируется буфер по адресу FC00h, где может быть мусор.

Т.е. чтобы батник мог выполняться с ром-диска, адрес его загрузки в атрибутах должен быть FC00h. Если создаёте образ ром-диска с помощью js скрипта vinxru, файл должен называться AUTOEX.64512.BAT (64512 это адрес посадки в десятичном виде). Надо про это написать в первом посте темы!

[SpaceEngineer]

Где можно найти описание точек входа коммандера и биоса, и директив мониторов? Есть конечно дизассемблер, но готовое описание от автора было бы лучше.

Edit: составил сам. Там же и Ramfos, для сравнения совместимости.
https://docs.google.com/spreadsheets/d/1m1eX0XzpzDAgWfc9xcPZXElVy3iwksZ1cR4qKGbpdqI/edit#gid=0

[fifan]

Автор данного коммандера умер уже давно. Единственный кто попытался разобраться в программе был Алексей Морозов (Vinxru/Alemorf). Исходники (https://github.com/VWarlock/retro/tree/master/specialist-mxos) от него (вернее от MXOS) не помогут?

[HardWareMan]

Не понимаю логику автозапуска команд при перезагрузке. Порылся в исходниках, там такой порядок:
У ORDOS такой же принцип:
https://i.ibb.co/6gMmBMW/image.png

[SpaceEngineer]

Автор данного коммандера умер уже давно. Единственный кто попытался разобраться в программе был Алексей Морозов (Vinxru/Alemorf). Исходники (https://github.com/VWarlock/retro/tree/master/specialist-mxos) от него (вернее от MXOS) не помогут?

Да, умер, к сожалению, и не оставил документации на софт. Я уже изучил исходники vinxru и начал делать модификации. Изменил логику autoex.bat, исправил несколько багов. Цель - сделать гибрид коммандера и рамфос, т.е. реализовать точки входа и подпрограммы рамфоса, чтобы его софт мог работать, а файловая система и красивый шустрый нортон чтобы были от коммандера. В перспективе перейти на fat12/fat16.

Много ли оригинального софта существует под коммандер? В архивах вашего сайта нашел только ром диск с бейсиком, ассемблером и еще чем-то не работающим. Ну и редактор, который выглядит беднее рамфосовского. Это я к тому, что если новая ОС потеряет совместимость с коммандером, много ли потеряем?

[fifan]

HardWareMan составлял один сборник из программ для командера, я тоже пару штук. Алексей Морозов жаловался что стандартные программы под RAMFOS частянько не запускались. Лучше сначала проверить работу из под эмулятора, а потом уже шить ROM-диск. В моих планах было сделать драйвер для запуска программ с SD карты, но так и руки и не дошли. А вот драйвер для запуска с дискет работает (на эмуляторе пробовал).

[SpaceEngineer]

HardWareMan составлял один сборник из программ для командера, я тоже пару штук. Алексей Морозов жаловался что стандартные программы под RAMFOS частянько не запускались. Лучше сначала проверить работу из под эмулятора, а потом уже шить ROM-диск. В моих планах было сделать драйвер для запуска программ с SD карты, но так и руки и не дошли. А вот драйвер для запуска с дискет работает (на эмуляторе пробовал).
Где можно их скачать?


Алексей Морозов жаловался что стандартные программы под RAMFOS частянько не запускались.
Потому что адреса некоторых функций C800 не совпадают или имеют другое назначение, а точек входа F800 вообще нет (а они используются софтом под рамфос).
Вот, составил таблицу подпрограмм (https://docs.google.com/spreadsheets/d/1m1eX0XzpzDAgWfc9xcPZXElVy3iwksZ1cR4qKGbpdqI/edit?usp=sharing) коммандера (из его исходников, т.е. уже апгрейженного).

В комплекте с коммандером есть мониторы MON_88, MON2, и SP_580. Второй и третий грузятся на адреса, перекрывающие F800, и содержат там таблицу переходов (https://disk.yandex.ru/i/vbgTqKpEA8spag), похожую на рамфос (или ордос от Ориона). Т.е. можно попробовать запустить MON2, сбросить, запустить прогу из рамфоса. Я не совсем понял, оригинальные ли они, или vinxru портировал их из рамфоса? Может быть, он хотел реализовать запуск классических программ (rks) в STD режиме, как в обновлённом рамфосе?

MON2 выглядит родным для коммандера, т.к. имеет такие директивы:
? - вывод каталога текущего диска
<буква диска>: - сменить диск

С другими ещё не разобрался, надо дизассемблировать и изучить, раз документации нет.

- - - Updated - - -


А вот драйвер для запуска с дискет работает (на эмуляторе пробовал).
Публиковали его?

[fifan]

Публиковали его?
А как же - в начале этой темы.

[SpaceEngineer]

Прикрутил запуск RKS файлов, как в Рамфосе vinxru, Monitor2.sys взял оттуда же. Запуск сделал через механизм NC.EXT - назначение расширению RKS обработчика (отдельной программы-загружалки). Но всё равно пришлось лезть в код Коммандера, иначе он не хотел запускать RKS с любого диска (файл NC.EXT должен быть на том же диске, что и запускаемый RKS - думаю, это или баг, или недоработка; в исправленной версии достаточно одного A:NC.EXT).

Вопрос, как хранить RKS файлы на дисках Коммандера (рам/ром/флеш). Vinxru приложил к исходникам скрипт для создания образа ром-диска из отдельных файлов. Так вот, он отрезает от RKS первые 4 байта (начальный и конечный адреса загрузки) и последние 2 байта (контрольная сумма), и записывает их в структуру каталога, а на сам "диск" записывает только тело программы. Это, конечно, удобно и экономит дисковое пространство (многие программы Специалиста как будто специально имеют "круглый" размер, например 2048 байт, поэтому с лишними 6 байтами RKS файл занял бы на 1 кластер больше). Но правильно ли это? Когда (если) сделаю поддержку дискет и SD карт, то перекидывать RKS с ПК будет неудобно. Можно встроить автоматическое преобразование при копировании между "нормальным" RKS и "внутренним" для рам/ром/флеш диска, но это некрасиво как-то.

Скачать можно с гитхаба. Флеш-диск ещё не поддерживается эмулятором, но протестировать можно, прошив пару RKS игр на системный ром-диск, и запуская их оттуда и с рам-дисков.
https://github.com/UnivEngineer/Specialist-OS/

[SpaceEngineer]

Наверное, продолжить про развитие MXOS нужно в этой теме. Сделал первый этап перехода на FAT12/16: увеличил размер дескриптора файла в каталоге с 16 до 32 байт, и привёл его в соответствие с форматом FAT. Имя файла теперь 8.3, и куча неиспользуемых полей (одно из них выделил для адреса загрузки). Следующий этап - саму таблицу FAT перевести на 16 бит.

76952

[SpaceEngineer]

Странная вещь в есть в коде MXOS. Как известно, драйвер обмена с доп страницами ОЗУ расположен в 32-байтном окошке непереключаемгого ОЗУ по адресу FFC0-FFDF. Потому что при переключении страницы, код ОС исчезает, и остаётся только в этом маленьком окошке.
Но зачем драйвер обмена с ПЗУ располагается там же? Ведь ПЗУ в MX подключается на адреса 0000-BFFF (48 кб), а в MX2 на 0000-7FFF (32 кб, две страницы). Поэтому драйвер обмена с ПЗУ можно сделать гораздо проще. У Юденцова что, была схема с единым ПЗУ на все 64 кб за вычетом окошка и портов?

[HardWareMan]

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

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

[SpaceEngineer]

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

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

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

В принципе, система уже юзабельна. При желании, 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 КБ в основном ОЗУ.

[fifan]

По городу автора. Vinxru или Alemorf или Алексей Морозов тоже из Питера. Так что вы оба - земляки.

[Sandro]

Размер сектора на SD -- 512 байт. Это кластеры в файловой системе могут быть большими.

[fifan]

Какой формат дискет используется на Специалисте?
Разбивка диска стандартная: 162 дорожки с двух сторон, 5 секторов, по 1024 байта каждый.
Опознать диск можно по стрингу "Dos_MX V3.6", который находится по смещению 5, в нулевом секторе нулевой дорожки.
Файловая структура дисков весьма необычная: файл позиционируются с точностью до байта. Дело в том,что файловая система основывается на структуре ROMDISK'а для этого компьютера.

Формат дескриптора файла в каталоге:
3 байта - признак заголовка (#d3 #d3 #d3)
8 байт - имя файла
1 байт - пробел (#20)
3 байта - раcширение файла
1 байт - признак сохранённости/несохранённости файла (#8c/#8b)
3 байта - дата создания файла
1 байт - номер 1-го сектора дорожки (#00...#0a)
1 байт - номер 1-й дорожки (#00...#4f)
2 байта - количество секторов (объём файла в кБайтах)
1 байт - признак файла/каталога (#00/#ff)
2 байта - начальный адрес
2 байта - конечный адрес
2 байта - контрольная сумма
2 байта - назначение не ясно
Назначение остальных байтов неизвестно, требуется дополнительная информация.

Не могу найти документы о структуре FAT. Хотя когда-то написал программу для просмотре занятости секторов на дискете. Вот исходник и запускаемый файл.

[SpaceEngineer]

Понятно. Такие дискеты нет смысла поддерживать в рамках MXOS2 (или как её назвать?) Раз в ней будут FAT из коробки, значит и дискеты и SD карты должны быть в FAT (которая стандартная, Microsoft). Старые образы дискет можно распаковать и пересохранить в fat.
Значит мне надо сделать поддержку секторов любого размера (сейчас 256 байт) и кластеров. Потом - перейти на полноценную структуру FAT, с загрузочным сектором и общепринятыми кодами пустой записи каталога и т.п. Накопителей у меня пока два виде - рам диск и флеш диск. Драйверы дисковода и SD карты еще предстоит написать.

[SpaceEngineer]

Пресобрал редактор E.COM для работы на другом адресе. Не так просто это оказалось, самомодификация кода и таблица с кодами клавиш и адресами п/п и обработки - такое дизассемблер сам не отлавливает.
В процессе стало ясно назначение клавиш. Получилась инструкция.

Инструкция к редактору E.COM

F1 - переключение режима Insert/Overwrite
F2 - курсор на страницу вверх (PageUp)
F3 - курсор на страницу вниз (PageDn)
F4 - открыть файл
F5 - сохранить файл
F6 - открыть файл и вставить его в конец документа
F7 - поиск текста в строке курсора и ниже (перематывает документ на строку с текстом)
F8 - отмена изменений в строке

Стрелки - управление курсором. Можно его разместить где угодно, в т.ч. за концом строки и за концом документа.
Del - удалить символ, на котором курсор
Enter - вставить строку ниже курсора (не разбивает текущую строку)
Tab - курсор вправо на следующий ближайший столбец шириной 4 (8) знакомест (не совсем понятно, шаг постоянно меняется, может баг?), не вставляет символ tab, а просто передвигает курсор
Home - курсор в начало строки
End (ПС) - курсор в конец строки
СТР - выход (без сохранения!)

Esc-Home - курсор в начало первой страницы
Esc-End - курсор в начало последней страницы
Esc-S - разбить строку в положении курсора на две
Esc-J - объединить текущую строку (на которой курсор) и следующую
Esc-L - выделить текущую строку; потом можно переместить курсор на другую строку и снова Esc-L - выделить все строки от первой выделенной до текущей
Esc-U - снять выделение строк
Esc-C - вставить выделенные строки в строку ниже текущей
Esc-M - переместить выделенные строки в строку ниже текущей
Esc-D - удалить выделенные строки
Esc-N - новый файл (очистить буфер), выводится запрос для подтверждения
Esc-O - сохранить файл на магнитофон
Esc-I - загрузить файл с магнитофона
Esc-V - загрузить файл с магнитофона (в другом формате?)
Esc-G - загрузить файл с магнитофона и вставить в конец документа

Редактор поддерживает запуск из командной строки с передачей имени открываемого файла в виде аргумента. Это используется в Коммандере - редактор назначен на клавишу F4. Также можно ассоциировать с ним любые типы файлов, например TXT, прописав их в NC.EXT.
Редактор хранит переменные в области памяти под экраном, ниже переменных BIOS. Это позволяет ему помнить некоторые настройки между сессиями, даже загруженный/введенный ранее текст, если ничто не попортило буфер в памяти.
У кнопки F3 есть второй обработчик, но до него управление никогда не доходит. Поменял их местами ради интереса - просто нажатие F3 выбрасывает из редактора. Если перед этим загрузить файл по F4, то стирается экран, вместе со строкой состояния.
Команды F4-F6 - работа с файлами на дисках Коммандера. В строке состояния выводится запрос имени файла. Если не вводить букву диска, имеется в виду текущий диск. При этом буфер для ввода имени файла - всего 9 символов, т.е. хватает только на имя, точку и расширение (6.3), а на букву и двоеточие уже не хватит, если имя длинное.
Кнопка СТР злая, выход из редактора сразу без сохранения и каких-либо запросов. Получается, нет простого способа просто взять и сохранить изменения: надо нажать F5, вспомнить имя редактируемого файла, сохранить. Это если редактор запускается с передачей файла через командную строку. Если запускать его отдельно и открывать файл через F4, то он запомнит имя файла и будет сразу его показывать в строке ввода команд F4-F6. Может быть, это просто недоработка.
Кнопка Tab не вставляет символ tab, а просто передвигает курсор. Вроде бы должна двигать на ближайший столбец шириной 4 (8) знакомест, но шаг постоянно меняется. Может, это баг, а может как-то хитро заточено под форматирование кода на ассемблере.
Не понятно, как переключиться на ввод русского текста (ps: понял как, HP+Рус переключает язык. В режиме КОИ-8 Рус работает как Caps Lock. А в режиме КОИ-7 Рус переключает язык. Это общий принцип в этой ОС). Редактор нормально отображает файлы в кодировке КОИ-8, но как печатать? Кстати, код символа Ъ = 0FFh используется как признак конца файла, так что нельзя, чтобы он был в тексте.

Кто в курсе, является ли этот редактор адаптацией какого-то известного? Есть ли более продвинутые редакторы, приближенные к современным по принципу работы с текстом? Или всё же стоит его доработать? Из доработок, кроме перехода на формат файла FAT (увеличить буфер имени и т.п.), хочу вывести подсказку по клавишам F1-F8 в строку состояния, и раскрасить его, для придания внешнего вида "родного" для Коммандера плагина. По Esc-последовательностям можно сделать экран хелпа, и повесить его на F1 (а Ins перевесить куда-то еще). А по F4 - запуск хекс редактора, как было в Волков Коммандере :)

[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, а потом и рам-диски.

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

[SpaceEngineer]

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

https://github.com/UnivEngineer/Specialist-OS

Что сделано:

- FAT16 почти стандартный, имена файлов 8.3, загрузочный сектор, одна таблица FAT и корневой каталог (до 256 файлов). Папки пока ещё не поддерживаются. Отличия от стандарта - сектор = кластер = 256 байт, и по мелочам (пустая запись в каталоге обозначается FFh, а не E5h, присутствует адрес загрузки файла, и т.д.)
- Дисковый буфер в памяти превратился в кэш, сохранив первоначальный размер (1 кб). Если раньше fat и каталог грузились с накопителя целиком, то теперь в кэш грузятся произвольные секторы по мере надобности, затирая наиболее давно использовавшиеся (LRU кэш). Это позволило работать с огромными по размеру fat и каталогом (на 2 Мб флеш-диске они занимают 16 + 8 кб), сохранив приличную производительность, и не расходуя память.
- Рам-диск и флеш-диск теперь сплошные, до 256 файлов и до 16 Мб размером.
- Добавлен драйвер стандартного 64 кб ROM-диска, подключаемого через ВВ55, работает в эмуляторе emu. Эмулятор не поддерживает 2 Мб флеш-диск HardwareMan'а, но с этим драйвером можно поиграться с "виртуальным" большим ром-диском (если передать ему файл с первыми 64 кб образа ром-диска, где находятся fat и каталог, то можно в нортоне погулять по нему. Файлы загружать, естественно, не получится, ну кроме тех, что целиком поместились в эти 64 кб).
- В нортоне реализован скроллинг, чтобы можно было добраться до любого файла. Если каталог большой (на флеш-диске у меня 133 файла), скролинг подтормаживает, потому что каталог каждый раз целиком читается с накопителя. Буфер со списком файлов, отображаемых на панели (36 шт), и так килобайт занимает, тут особо не разгуляешься. Эта проблема решится с реализацией поддержки папок - не будет в одном каталоге такой огромной россыпи файлов.
- На инфопанели выводится информация об объеме памяти и диска, свободном месте на нём, количестве файлов, и метка тома - всё, как в "настоящем" Нортон коммандере.
- В системе включен шрифт КОИ-8 по умолчанию. Имена файлов можно писать в любом регистре (по-русски тоже - но я не проверял). Сами файловые операции к регистру нечувствительны.
- Поменялось распределение памяти. Стандартные программы (нортон, редактор и др.) переехали на E800h, что, кстати, совместимо с Ramfos. Редактор E.COM адаптирован и слегка раскрашен. Для драйверов осталось 2-2.5 кб памяти. Кто бы написал драйвер дисковода и SD карты? Нужны, как и раньше, только три функции - запись сектора, чтение сектора, получение размера.

- - - Updated - - -

https://disk.yandex.ru/i/rnapNP6z21CtCw
77022

https://disk.yandex.ru/i/OcPtdCbA8UNNow
77023

https://disk.yandex.ru/i/HDox5vRNRQpR4Q
77025

Кстати, надписи КАПСОМ смотрелись как-то аккуратнее. Разрешение шрифта маловато что ли для строчных букв?

[CityAceE]

Строка помощи почему-то с нестандартной раскраской. Вызывает диссонанс.

https://upload.wikimedia.org/wikipedia/en/1/1b/Norton_Commander_5.51.png

http://i006.radikal.ru/1012/b9/2c118d55e7b8.png

[SpaceEngineer]

В палитре Специалиста нет такого болотного зеленого цвета. Можете сами поэкспериментировать с цветами, они прописаны в начале файла NC/NC.asm.

Кстати, что лучше писать в строке объема диска - физический или доступный? Загрузочный сектор, fat и каталог занимают место, поэтому про пустой рам диск система пишет "512 kb total, 503 kb free, 0 files use 9 kb".

[CityAceE]

В палитре Специалиста нет такого болотного зеленого цвета.
Это не болотный зелёный, а тёмный cyan, и он в палитре Специалиста всё-таки есть ;)

[SpaceEngineer]

Вот почти стандартная раскраска. Палитра все же не совсем соответствует. На реальном Специалисте через китайский VGA конвертер так вообще.
Но мне больше нравится раскраска vinxru. Хотя может быть я просто привык :)
https://disk.yandex.ru/i/z-VmyGdykHRxUA
77024

[CityAceE]

Вот почти стандартная раскраска.
По мне так гораздо лучше стало! Для меня так гораздо привычнее, потому что даже Midnight Commander под Linux придерживается стандартов, заданных когда-то Питером Нортоном.

[SpaceEngineer]

Разобрался с монитором MON2.COM. Весьма полезная программка! Вот список директив:

G - запуск программы по указанному адресу, второй параметр - инъекция точки останова
D - дамп блока памяти в HEX виде
L - дамп блока памяти в текстовом виде
M - побайтовое редактирование блока памяти
T - копирование блока памяти на новый адрес (простое, пересекающиеся блоки будут испорчены)
F - заполнение блока памяти байтом
C - сравнение двух блоков памяти
S - поиск последовательности байт в блоке памяти
N - печать всех байт в блоке памяти, не равных данному
X - печать содержимого регистров процессора
H - печать суммы и разности двух HEX слов
K - подсчет контрольной суммы блока памяти
W - запись блока памяти на ленту без имени
R - чтение файла с ленты
J - выход из Mонитора (теплая перезагрузка ОС)

? - листинг каталога текущего диска (выводится имя, адрес загрузки, размер в HEX виде)
V - загрузка файла в память по указанному адресу
U - загрузка файла в память по адресу, указанному в его дескрипторе
B - запись блока памяти в файл
A - установка нового адреса загрузки файла
Q - печать байта атрибутов файла
Y - установка нового байта атрибутов файла
A: ... H: - переключиться на другой диск

Адаптировал его для работы с обновлённой ОС (несовместимость возникла из-за нового формата дескриптора файла, по стандарту FAT12/16). Большинство директив стандартные, но интересное начинается с директивы ? - файловые операции с дисками. Директива вводится как обычно, например B1000,1FFFF <BK>, но затем появляется запрос имени файла. Можно вводить его с буквой диска, если текущий диск отличается, при этом произойдет переключение диска.

Загадочная штука - наличие в мониторе таблицы подпрограмм F800h, большинство из которых дублируют стандартные C800h. Вероятно, это сделано для экспериментов/адаптации программ от Ориона, или же от Рамфоса (но его подпрограммы F800h заметно отличаются по назначению).

[SpaceEngineer]

Ну, мужики, я исчезаю на неопределенный срок. Кабздец всему пришел.