DSDOS для ПРК "Орион-128"

[Denn]

Давно хотел оценить количественно скорость работы накопителей в ОС DSDOS, и наконец-то, что называется, дошли руки.

Для удобства была создана утилита генерации тестовых файлов:

FILEGEN$

Утилита FILEGEN$ позволяет создавать на целевом диске произвольное количество тестовых файлов определённого размера. Также возможно групповое удаление тестовых файлов, созданных утилитой ранее.
Параметры генерации задаются с помощью командной строки. Краткая справка выводится при запуске утилиты без параметров:



Подробности в сопроводительном текстовом файле помощи - FLGEN.HP

[свернуть]

Измерения проводились под ОС версии 3.88, на двух платформах:

1) "ОРИОН-128 рев.512" (ЦП ВМ80А, ОЗУ 512Кб, квазидиск 360Кб, НЖМД через переходник на порт пользователя #F6, виртуальный диск на 16C550 @ 115200 Бод);
2) "ОРИОН-ПРО v3.10F" (ЦП Z80B*, ОЗУ 512Кб, квазидиск 360Кб, НЖМД по схемотехнике NEMO-IDE, виртуальный диск на 82C51A @ 115200 Бод).
__________________________________________________ ___________________________________
* В двух программно-аппаратных конфигурациях: CLK=2,5МГц и CLK=10МГц.

Цели исследования:
- оценка реальной (боевой) скорости работы с файлами;
- сравнение скоростей основных быстрых накопителей;
- оценка вклада быстродействия ЦП, интерфейса накопителя, алгоритмов работы ОС.

Полный протокол измерений собран в этой таблице.

Измерения на ОРИОН-ПРО в конфигурации "CLK=2,5МГц" производились фактически для сравнения двух типов КНЖМД: NEMO_IDE vs. ВВ55_IDE-затычка.

Все виды тестов проводились в двух вариантах:

1) Обработка 253-х тестовых файлов, каждый размером 512 байт;
2) Обработка 4-х тестовых файлов, каждый размером 32768 байт;

В обоих случаях общий объём полезной информации примерно одинаковый - около 128 Кб. В первом случае добавляется (ощутимый) вклад операций с файловой системой (далее - ФС), во втором случае им можно пренебречь - измеряется фактически чистая скорость переноса полезной информации (содержимого файлов).

Итак, результаты.


Безусловный лидер по скорости во всех видах состязаний, разумеется, квазидиск [B:]:

Запись на диск 4-х файлов по 32Кб: 2 сек / 3 сек / менее 1 сек *
Запись на диск 253-х файлов по 512 байт: 20 сек / 22 сек / 9 сек **

Чтение с диска 4-х файлов по 32Кб: 2 сек / 2 сек / менее 1 сек
Чтение с диска 253-х файлов по 512 байт: 20 сек / 20 сек / 8 сек

Удаление с диска 4-х файлов: 0 сек / 0 сек / 0 сек ***
Удаление с диска 253-х файлов: 12 сек / 13 сек / 6 сек
__________________________________________________ __________________________________________________ _____________
* замеры производились вручную с использованием секундомера, точность +/-0,5 сек.
** указаны значения для трёх конфигураций: ОРИОН-128@2,5МГц / ОРИОН-ПРО@2,5МГц / ОРИОН-128@10МГц, соответственно.
*** слишком быстро, доля секунды, вручную измерить не представляется возможным!

Характерные особенности:

- при обслуживании ФС отсутствуют операции записи/чтения каталога диска;
- скорость записи/чтения информации максимальная (определяется скоростью работы МПС);
- при записи/чтении данных используются ускоренные алгоритмы с использованием операций со стеком;
- размер кластера 256 байт.

Резюме: на ПРК с тактовой частотой 2,5 МГц чистый битрейт чтения/записи данных составляет около 64 Кб/сек,
при "нарезке" данных файлами малого объёма на первый план выходит обработка ФС (поиск файла в каталоге, поиск секторов в FAT), и скорость падает на порядок - около 6 Кб/с;
на ПРК с тактовой частотой 10 МГц (виртуально около 7 МГц, ибо вэйты при обращении к ОЗУ/ВУ) получается 128 Кб/с и 16 Кб/с, соответственно.
Из реальной практики: работаю в текстовом редакторе с большими исходниками (около 40 Кб), периодически сохраняюсь - жму Ctrl+S и тут же продолжаю печатать, т.е. пока палец перемещается к очередной клавише, комп успевает полностью перезаписать файл 40 Кб.


Второе место достаётся накопителю с IDE-интерфейсом (НЖМД, диск [C:]):

Запись на диск 4-х файлов по 32Кб: 10 сек / 3 сек / 2 сек
Запись на диск 253-х файлов по 512 байт: 3:25 сек / 1:13 сек / 31 сек

Чтение с диска 4-х файлов по 32Кб: 8 сек / 2 сек / 1 сек
Чтение с диска 253-х файлов по 512 байт: 21 сек / 19 сек / 8 сек

Удаление с диска 4-х файлов: 2 сек / 1 сек / 1 сек
Удаление с диска 253-х файлов: 2:23 сек / 57 сек / 24 сек

Характерные особенности:

- обслуживание ФС сопровождается операциями записи(каждый раз)/чтения(однократно) каталога диска + FAT (4+4=8 Кб);
- за один такт накопитель записывает/считывает два байта информации (определяется схемотехникой КНЖМД);
- при записи/чтении данных используются ускоренные алгоритмы с использованием операций со стеком;
- размер кластера 4096 байт.

Резюме: в случае применения КНЖМД по схемотехнике NEMO чистый битрейт чтения данных аналогичен квазидиску - около 64 Кб/с (@2,5МГц)!
Упрощённое подключение НЖМД через порт ВВ55 проигрывает по скорости чтения больших файлов аж в 4 раза, в случае большого кол-ва маленьких файлов битрейт аналогичен NEMO и квазидиску - около 6 Кб/с (@2,5МГц).
Чистый битрейт записи данных на NEMO примерно в 1,5 раза уступает чтению - 43 Кб/с (@2,5МГц), на ВВ55-переходнике в 5 раз - 13 Кб/с (@2,5МГц).
На ПРК с тактовой частотой 10 МГц и NEMO удаётся получить чистые 128 Кб/с (чтение) и 64 Кб/с (запись), соответственно. В случае "файлонарезки" показатели падают в 8 и в 15 раз, соответственно.
Невероятно печальные показатели на 2,5МГц-платформе с подключением НЖМД через ВВ55-переходник: многофайловая запись - 0,6 Кб/с (с NEMO в 3 раза быстрее - 1,8 Кб/с).


На третьем месте виртуальный диск [G:]:

Запись на диск 4-х файлов по 32Кб: 13 сек / 13 сек / 12 сек
Запись на диск 253-х файлов по 512 байт: 1:23 сек / 1:12 сек / 1:05 сек

Чтение с диска 4-х файлов по 32Кб: 13 сек / 12 сек / 12 сек
Чтение с диска 253-х файлов по 512 байт: 27 сек / 25 сек / 19 сек

Удаление с диска 4-х файлов: 0 сек / 0 сек / 0 сек *
Удаление с диска 253-х файлов: 58 сек / 50 сек / 50 сек
__________________________________________________ __________________________
* слишком быстро, доля секунды, вручную измерить не представляется возможным!

Характерные особенности:

- обслуживание ФС сопровождается операциями записи(каждый раз)/чтения(однократно) каталога диска (размер = кол-во файлов * 16 байт);
- линейная (бескластерная) организация хранения/передачи данных;
- скорость передачи данных определяется приемущественно скоростью работы COM-порта (тест проводился на максимальной - 115200 Бод);

Резюме: скорость многофайлового чтения на 2,5МГц-платформах приближается к таковой у НЖМД/квазидиска и составляет - 5 Кб/с.
Чистый битрейт чтения данных хуже NEMO/квазидиска в 6 раз - 11 Кб/с.
Чистый битрейт записи данных хуже НГМД (NEMO) в 4 раза - 9,8 Кб/с. Средний битрейт многофайловой записи - 1,7 Кб/с (меняется нелинейно с ростом кол-ва файлов в каталоге).
Тактовая частота ЦП практически не влияет на скорость чтения/записи файлов.


Кэширование каталога (чтение файлов).

НЖМД [C:]:

Чтение с диска 4-х файлов по 32Кб с кэшированием: 8 сек / 2 сек / 1 сек
Чтение с диска 4-х файлов по 32Кб без кэширования: 10 сек / 3 сек / 1 сек

Чтение с диска 253-х файлов по 512 байт с кэшированием: 21 сек / 19 сек / 8 сек
Чтение с диска 253-х файлов по 512 байт без кэширования: 2:16 сек / 45 сек / 19 сек

Резюме: очевидное приемущество кэширования каталога при многофайловых операциях - ускорение в 7 раз с ВВ55-переходником и в 3 раза с NEMO-IDE.

Виртуальный диск [G:]:

Чтение с диска 4-х файлов по 32Кб с кэшированием: 13 сек / 12 сек / 12 сек
Чтение с диска 4-х файлов по 32Кб без кэширования: 13 сек / 12 сек / 12 сек

Чтение с диска 253-х файлов по 512 байт с кэшированием: 27 сек / 25 сек / 19 сек
Чтение с диска 253-х файлов по 512 байт без кэширования: 2:04 сек / 1:57 сек / 1:51 сек

Резюме: также очевидное приемущество кэширования каталога при многофайловых операциях - ускорение в 5 раз.


Копирование файлов между дисками (в порядке убывания производительности).

1. НЖМД -> квазидиск:

4-х файлов по 32Кб: 10 сек / 5 сек / 2 сек
253-х файлов по 512 байт: 42 сек / 41 сек / 17 сек

Резюме: на 2,5МГц-системе с NEMO-IDE чистый битрейт около 26 Кб/с, многофайловый поток - 3 Кб/с,
увеличение такта ЦП до 10МГц увеличивает скорость примерно вдвое.

2. Квазидиск -> НЖМД:

4-х файлов по 32Кб: 13 сек / 5 сек / 2 сек
253-х файлов по 512 байт: 3:45 сек / 1:35 сек / 39 сек

Резюме: чистый битрейт аналогичен предыдущему варианту - около 26 Кб/с.
Падение скорости при многофайловой "нарезке" данных ощутимо больше: в 18 раз (против 8 раз в предыдущем),
что связано с отсутствием кэширования каталога при записи на НЖМД (на каждый записываемый файл размером 512 байт в нагрузку записывается каталог 8 Кб, и так 253 раза!).

3. Вирт. диск -> квазидиск:

4-х файлов по 32Кб: 15 сек / 14 сек / 13 сек
253-х файлов по 512 байт: 47 сек / 47 сек / 27 сек

Резюме: чистый битрейт около 9 Кб/с, многофайловый поток - 3 Кб/с

4. Квазидиск -> вирт. диск:

4-х файлов по 32Кб: 16 сек / 16 сек / 12 сек
253-х файлов по 512 байт: 1:32 сек / 1:30 сек / 1:12 сек

Резюме: чистый битрейт около 8 Кб/с, многофайловый поток - 1,4 Кб/с
"Просадка" многофайлового битрейта по сравнению с предыдущим вариантом вызвана добавлением пересылки каталога,
т.к. после записи файла в вирт.диск содержимое каталога меняется и Орион вынужден загружать каталог по-новой (в этом случае кэширование по сути не работает).

5. НЖМД -> вирт. диск:

4-х файлов по 32Кб: 23 сек / 15 сек / 13 сек
253-х файлов по 512 байт: 03:37 сек / 01:56 сек / 01:22 сек

Резюме: чистый битрейт около 9 Кб/с (NEMO-IDE) и 6 Кб/с (ВВ55-IDE).
С многофайловым потоком всё ощутимо хуже - 1,1 Кб/с и 0,6 Кб/с, соответственно.
Катастрофическое падение производительности связано с совмещением буфера каталогов дисков [C:] и [H:],
в следствие чего при обработке каждого файла производится два чтения и одна запись каталогов!

6. Вирт. диск -> НЖМД:

4-х файлов по 32Кб: 25 сек / 15 сек / 13 сек
253-х файлов по 512 байт: 7:25 сек / 3:38 сек / 02:37 сек

Резюме: чистый битрейт аналогичен предыдущему варианту - 9 Кб/с (NEMO-IDE) и 6 Кб/с (ВВ55-IDE).
С "файлонарезкой" всё ещё печальнее - 0,6 Кб/с и 0,3 Кб/с, соответственно.
В данном случае имеем самые невыгодные условия при обработке файла: чтение каталога вирт.диска (4 Кб) + чтение каталога НЖМД (8 Кб) + запись каталога НЖМД (8 Кб), итого к каждому файлу "прицеп" в 20 Кб.

[Denn]

Полагаю, вопрос о pFE можно закрыть. Если запись в этот порт ничего не будет портить в стандартном варианте Ориона, то в следующей версии ОС добавлю OUT 0FEH и всё.

Случайно вспомнил про эту тему и сегодня проверил на реале (ОРИОН-128 рев.512): запись в порт #FE переключает экранные области, далее выяснил что остальные порты также имеют клоны - F8=FC, F9=FD, FA=FE, т.е. в стандартном варианте ПРК на ВМ80А дешифрация портов упрощённая, и дублировать № банки ROM-диска в #FE нельзя ((

П.С. в эмуляторе эффект не проявляется, вероятно там "дешифрация" честная.

[HardWareMan]

Так и есть, 20 сигнал не используется.

[Sancho45]

Случайно вспомнил про эту тему и сегодня проверил на реале (ОРИОН-128 рев.512): запись в порт #FE переключает экранные области, далее выяснил что остальные порты также имеют клоны - F8=FC, F9=FD, FA=FE, т.е. в стандартном варианте ПРК на ВМ80А дешифрация портов упрощённая, и дублировать № банки ROM-диска в #FE нельзя ((

П.С. в эмуляторе эффект не проявляется, вероятно там "дешифрация" честная.

ответил в соотв. теме.

[Denn]

Sancho45, спасибо.

Придумал обнаружение порта #FE по следующему незатейливому принципу. Выставляю адрес 0000h читаю два байта, запоминаю. Далее, пишу 01h в порт #FE и также читаю два байта с 0000h, сравниваю с запомненными. Возвращаю 00h в порт #FE. Если полное совпадение обоих байтов, значит либо порт #FE отсутствует в системе, либо воткнуто ПЗУ 64 Кб - оба варианта означают бесполезность управления банками через порт #FE, т.о. работаем с банками ROM-диска стандартно - через порт клавиатуры.

[Sancho45]

Если вм80, то OUT FEh будет как mov FEFEh, a
Может проц сначала задетектить или если обратно записывается 0 в порт fe, то особо можно не беспокоиться ? И какова вероятность совпадения 2-х байт в разных страницах, может там заголовок или еще чего?

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

В общем готов потестить, если будет релиз(как время будет, с чем проблемы, как и у многих. И нюансы всякие на новодельной плате обсудить.

[Denn]

Может проц сначала задетектить или если обратно записывается 0 в порт fe, то особо можно не беспокоиться ?

В моменты чтения из верхних банок на номальном Орионе будет мерцать экран, это имхо некрасиво.
Детектить проц - лишний код, к тому же возможны разные варианты натягивания Z80 на Орион-128... КМК, алгоритма, описанного выше, будет достаточно. В причинном месте кода будет "00 00", а в случае прочтения различающейся инфы при единоразовом тесте во время загрузки ОС, туда будет вставлено "D3 FE". Я уже проверил на своём ВМ80-варианте, такой быстрый тест даже не вызывает заметного моргания экрана.

В общем готов потестить, если будет релиз(как время будет, с чем проблемы, как и у многих. И нюансы всякие на новодельной плате обсудить.

Спасибо! Да, релиз в процессе, будут разные новшества, включая поддержку обоих вариантов адресации ВИ1 и полную эмуляцию ORDOS (чтоб работал весь софт, включая нагло лазающий напрямую в ОЗУ квазидиска). Надеюсь к НГ успею

[Denn]

Очень хотел релизнуть к НГ Но всего доделать не успел, поэтому обещанная "предновогодняя" сборка ОС DSDOS, но "альфа" v3.90a для Орион-128.

Краткий список новшеств:

► поддержка RTC на базе БИС КР512ВИ1 на уровне BIOS;
► поддержка альтернативного управления переключением банков ПЗУ ROM-диска (через порт #FE);
► поддержка двух вариантов "посадки" RTC (F76x и F7Bx);
► поддержка двух вариантов КНЖМД (через порт юзера #F6 и NEMO-IDE @F79x);
► новый код эмуляции API ОС ORDOS, полная поддержка всех векторов;
► исправлены ошибки в поддержке подкаталогов на НЖМД и SDHC;
► изменены буквы дисков: НЖМД №0 = "C:", НЖМД №1 = "D:", НГМД №0 = "F:", НГМД №1 = "H:";
► поддержка подкаталогов в оболочке для дисков C, D, G и H;
► интеграция драйвера расширения ExtDRV v2.8;
► конфигурационные файлы текстового редактора Gemini-EDIT и оболочки ОС хранятся на рабочем диске ОС;
► изменения некоторых горячих клавиш в текстовом редакторе, добавление новых комбинаций;
► в сборку включён графический редактор PENX$, который теперь прекрасно и полноценно работает!


Подробнее напишу позже, а пока традиционно:

▼▼▼ Ссылки для скачивания различных вариантов сборок ▼▼▼

Для ПРК ОРИОН-128/512:

ПЗУ ROM-диска объёмом 64 Кб

ПЗУ ROM-диска объёмом 128 Кб

ПЗУ ROM-диска объёмом 256 Кб

ПЗУ ROM-диска объёмом 512 Кб


ПЗУ ROM-диска объёмом 1024 Кб

специализированная "программерская", ПЗУ ROM-диска объёмом 512 Кб

специализированная "программерская", ПЗУ ROM-диска объёмом 1024 Кб


Для ПК ОРИОН-ПРО:

"Стандарт-64", ПЗУ ROM-диска объёмом 64 Кб
"Стандарт-256", ПЗУ ROM-диска объёмом 256 Кб

"Игровая-64", ПЗУ ROM-диска объёмом 64 Кб
"Игровая-256", ПЗУ ROM-диска объёмом 256 Кб

"Программист-64", ПЗУ ROM-диска объёмом 64 Кб
"Программист-256", ПЗУ ROM-диска объёмом 256 Кб

Внутри архивов под объёмы 256 Кб находится два варианта: одним полным образом (файл romdisk.bin) для новой версии ROM-диска, и четырьмя файлами по 64 Кб (файлы romdiskN.bin) для старого варианта диска (в составе мультикарты).

Внимание! Архивы были обновлены до версии 3.92 , 13.01.2019 !


П.С. Всех с Наступившими!

[Denn]

Итак, более подробно о релизе. Традиционно, нетерпеливый предновогодний пост отредактирован – архивы сборок обновлены до версии 3.91

Новая версия сборщика ROM-диска – CRTDSK$

Заново переписана «с нуля» утилита подготовки образов ROM-дисков для прошивки в ПЗУ. Помимо более информативного интерфейса, также добавлен новый функционал. Утилита позволяет собирать диски «бесконечного» объёма, «полёт фантазии» ограничен лишь размерами дисков, на которых размещаются файлы, ну и текущим максимальным поддерживаемом объёмом ПЗУ ROM-диска Ориона = 1 Мб. Старая версия утилиты «запиналась» при неудачном расположении файлов и физически не позволяла «монтировать» подряд идущие очень длинные файлы. В новой версии эти недостатки устранены, корректно компонуются любые файлы, в любом порядке следования, в т.ч. при попадании заголовка файла на границу между банками. По-умолчанию производится разбивка на 32 Кб фрагменты, необходимые для прошивки больших ПЗУ непосредственно с помощью Ориона, опционально доступна разбивка на фрагменты по 2, 8 и 16 Кб – для прошивки ПЗУ соответствующих актуальных размеров (РФ2, РФ4, 27128).
Традиционно сохранена возможность сборки ROM-диска в формате ORDOS (округление длин файлов кратно 16) – указанием ключа «/O». А также опция сокрытия системных файлов в каталоге – ключ «/H».
Добавлена возможность указывать в списке файлов команды смены каталогов! Т.о. теперь не обязательно размещение всех исходных файлов собираемого ROM-диска в одном каталоге виртуального диска или винчестера.
В случае ошибки чтения или записи файла в процессе обработки, утилита предоставляет возможность повторить операцию (диск был не готов, «отвалился» и т.п.) или выбрать другой диск (на текущем место закончилось). Т.о. теперь есть возможность собирать диск, не имея в наличии «жирных» носителей для выходных файлов, фрагменты образа можно «размазать» по нескольким дискам малого объёма.
Благодаря новой версии утилиты удалось более логично скомпоновать файлы в сборках, а также сделать 1Мб-версию для Орион-128. К сожалению, для Ориона-ПРО нет аппаратного решения для ROM-диска более 256 Кб, или оно мне не известно, поэтому для «ПРОшки» традиционно два варианта дисков на 64 и 256 Кб.

Видео пример процесса сборки образа ROM-диска на 512 Кб - https://www.youtube.com/watch?v=Mq_6iFt_tAc


Теперь непосредственно про ОС. Данным релизом сменилась значимая часть номера версии, что означает критичные изменения (новшества) в API ОС, таким образом ПО созданное под версию 3.9x работать в предыдущих версиях (3.8x и ниже) не будет! Поддержка старого ПО в новой ОС остаётся в полном объёме. Нововведения не меняют концепции взаимодействия с ОС, а просто ещё немного упрощают код прикладного ПО и позволяют практически полностью отказаться от вызова п/п Монитора, а также унифицировать код для разных платформ (128/ПРО). В новой версии работа с RTC абстрагирована от конкретной реализации в «железе» и доступна через API DSDOS.
Все изменения внесены в соотв. библиотеки SDK - http://denn.ru/8bit/orion/soft/dasm/dsdos_sdk.rar


Поддержка обоих вариантов «посадки» часов ВИ1

Так случилось, что для Ориона-128 популярны два варианта включения отечественных часиков реального времени на базе БИС КР512ВИ1: по адресам F7B0/F7B1 и по адресам F760/F761 (с реверсной адресацией регистров). В новой версии ОС сделана прозрачная поддержка обоих вариантов. Если каким-то чудесным образом в системе присутствуют оба, то приоритет первому (авторскому), его поиск при автодетекте производится первым. Обнаружение м/сх часов производится посредством записи и считывания контрольной информации в последнюю ячейку CMOS. Прикладное ПО начиная с версии 3.9 работает через API, поэтому оно даже не «в курсе» какой вариант посадки RTC используется. Тем не менее, при желании программист может узнать эту информацию: п/п инициализации “#B0” выдаёт номер обнаруженных RTC (или 00h при их отсутствии).


Эмуляция API нативной авторской ОС ORDOS

Как неоднократно упоминал ранее, ПО под ORDOS (в т.ч. авторское) часто пытается работать с дисками напрямую, т.е. тело файла вычитывается не средствами ОС, а непосредственно из ОЗУ квазидиска. Поскольку диски в ОС DSDOS организованы совсем иначе (кластерное хранение данных, и в случае квазидиска - в разных банках доп. ОЗУ), непосредственно реализовать «уязвимость» ORDOS не представляется возможным. В итоге было принято решение организовать т.н. «песочницу», т.е. на лету имитировать ORDOS-структуру квазидиска в области атрибутов цвета теневого экрана (8000h-AFFFh). При вызове п/п поиска файла, код эмуляции API ORDOS загружает найденный файл в «песочницу» и программе предоставляет физические адреса тела файла честно во второй странице ОЗУ, т.е. на лету организуется кусок структуры ORDOS'овского квазидиска персонально под запрошенный файл. Также с помощью «песочницы» реализован функционал последовательной записи в ORDOS-файл, а по факту закрытия файла он уже сохраняется в виде файла DSDOS на текущем диске.

Эмулируются все п/п ОС ORDOS, сообщение об ошибке возможно только при выходе за границы «песочницы», размер её буфера - 12 Кб, а также при попытке нарушения границ тела файла в ОЗУ виртуального квазидиска.

На такие заморочки сподвигнуло давно не дающее покоя «шило» - PENX. Одна из выдающихся авторских программ на Орионе, по сути визитная карточка ПРК. Собственно вариантов было два: либо перепилить работу с файлами у PENX'а, либо гора идёт к Магомету

Графический редактор был успешно дизассемблирован, работа с файлами через API ORDOS понята, но в последний момент решил не «портить» этот шедевр, а всё же подстроиться со своей стороны. Однако чуть-чуть подпилить PENX всё же пришлось, т.к. выяснилось, что он не запускается, если квазидиск ORDOS заполнен выше 8000h, а «песочница» как раз расположена именно там! Пришлось заткнуть эту проверку, т.к. в данном случае она не актуальна, с 8000h у нас временный буфер, а реальные файлы хранятся совсем в другом месте. Плюс подкорректировал некорректное «упрощённое» обращение к знакогенератору, использующееся при «быстром» выводе цифр кратности положения пера восьми. Работает! Программа суперская, реально шедевр программирования, автору однозначно респект.


Поддержка НЖМД

Собственно о поддержке жёстких дисков я уже писал ранее и даже выкладывал версию 3.88, сам активно пользовался почти весь прошлый год. За этот период были найдены некоторые недочёты и даже серьёзные баги, которые успешно исправлены в релизе v3.9.

Критичным багом была некорректная работа с т.н. «каталогами в каталоге», в результате чего данные содержимого подкаталога располагались в произвольном месте жёсткого диска, которое зависело от имён файлов в родительском каталоге %)

Также много хлопот доставило обнаружение НЖМД при загрузке ОС. Дело в том, что согласно тех. документации по IDE, при отработке команды сброса (аппаратного или программного) винчестер может «тянуть с ответом» до 30 секунд! И как показала практика, при включении (подаче питания) некоторые модели HDD «выгребают» этот лимит по-полной! Понятное дело – раскручивание шпинделя, внутренние тесты… но лично я уже привык к почти моментальной загрузке ОС, и тут вдруг такие тормоза!
Совсем печально обстоит дело с вариантом подключения HDD по т.н. упрощёнке (через порт пользователя #F6xx), а точнее с неподключением туда диска. Если в случае NEMO-контроллера достаточно мгновенно убедиться в аппаратном отсутствии самого КНЖМД и не ждать ответа от накопителя, то в случае ВВ55 – порт же всегда есть в системе, и если на нём нет накопителя, то приходится честно ждать пол минуты его ответ (а вдруг он там всё таки есть?).
К счастью обнаружилась приятная аппаратная особенность интерфейса IDE – если накопитель присутствует, но не выбран, то он подтягивает все линии шины к лог. «1», а «голый» порт ВВ55 наоборот выдаёт все «0». Благодаря этой фишке удалось избавиться от тормозов в случае отсутствия НЖМД на ВВ55.

Лично я долго и упорно сопротивлялся пускать «винты» в свои Орионы (скорее по «религиозным» соображениям), но, как и в случае с виртуальным диском (vs. дискеты) , объёмы + скорость и, как следствие, комфорт одержали победу. Осталось только совсем что называется наступить на горло песне и поставить SSD через китайский переходник IDE-SATA )) - ну всё же хочется идеальной тишины от Ориона. Хотя честно говоря хороший ноутбучный «винт» вполне себе нешумный, даже в полной ночной тишине.

В связи со всей этой историей наметился вектор постепенного (или не очень?) ухода от поддержки дискет в ОС DSDOS. По крайней мере по-умолчанию. Всегда есть возможность установки драйвера экзотического устройства вместо какого-то родного диска или, на худой конец, отдельной утилиты для работы с НГМД. Кмк, в базовой комплектации ОС поддержка дискет «для галочки» имеет мало смысла в наше время, а драгоценное место код отжирает, что ограничивает дальнейшее развитие.

Тем не менее, в версии 3.9 поддержка НГМД сохранена, но изменились буквы дисков. Ранее ассоциированные с дискетами имена дисков [C:] и [D:] присвоены НЖМД №0 и НЖМД №1 («Master» и «Slave», соответственно).
При загрузке ОС и обнаружении КНГМД по-умолчанию виден только дисковод №0 – диск [F:] (ассоциация «Floppy»), дисковод №1 неявно присутствует как диск [H:] (его можно сделать видимым через SYSTEM$). Дело в том, что конфигурация Ориона с двумя дисководами исчезающе маловероятна в наше время, кмк, но возможность поддержки такого варианта сохранена.. пока


Драйвер расширения ExtDRV v2.8

Ранее было подробное описание, а теперь он стал неотъемлемой частью всех сборок, кроме 64Кб-варианта (физически мало места, с драйвером уже не помещается базовый набор утилит).
Подгружается драйвер в BOOT автоматически. Нативный текстовый редактор Gemini-EDIT использует функционал драйвера расширения для диалогов чтения/записи файлов. Также оконный интерфейс драйвера использует утилита просмотра графических файлов – PICVIEW$. Соответственно, в варианте 64Кб-сборок загрузка рабочих файлов в данных программах возможна только через командную строку.
При создании ПО в дальнейшем также планируется активное использование ExtDRV API.


Хранение конфигурационных файлов SHELL и Gemini-EDIT на рабочем диске ОС

Изначально «центром вселенной» был квазидиск, он же был и «рабочим» диском согласно концепту ОС DSDOS. Все файлы конфигурации складывались туда же – в квазидиск. Потом появились варианты: «ЭД™» и «RAM7™», информация в которых не пропадает при выключении питания. Мне показалось логичным немного изменить концепт: при обнаружении в системе SRAM-диска, рабочим назначать его, чтобы конфигурационные и рабочие файлы сохранялись на нём, и, как следствие, при включении пользователь получал аналог выхода из «спящего» режима (состояние ПРК такое же, как на момент выключения), а квазидиск используется для временных файлов и как виртуальная память.

Опыт реальной работы на Орионе показал некоторые минусы второго варианта концепта, поэтому он пока в стадии осмысления. Самый главный минус – скорость загрузки ПО. К хорошему, как известно, привыкаешь, а к хорошей скорости работы – очень сильно
Подгрузка конфигурационных файлов при запуске некоторых программ это по сути загрузка двух файлов с разных дисков, а значит подгрузка и обработка каталогов этих дисков, поиск файлов на них… короче говоря, хоть это и доли секунды, но разница с т.з. комфорта при активной работе ощутимая, особенно на Орионе-128 с ВМ80 (@2,5 МГц).
В любом случае всегда можно переназначить рабочий диск через SYSTEM$.


Горячие клавиши в Gemini-EDIT

Тут изменения коснулись комбинаций клавиш работы с буфером обмена. Работать на PC приходится часто, поэтому писишные привычки очень сильны, но и на Орионе много работаю с текстами программ, поэтому вынужден был сделать «стандартные» Ctrl+C, Ctrl+V, Ctrl+Ins, Shift+Ins, Shift+Del, Ctrl+D.

[Sancho45]

Привет. Страницы по порту FEh выше 512 кб какими битами переключаются? Там вроде первые три бита, 4-й бит работает со спикером, и 5 и 6 с переключением остальных страниц ЕМНИП. Я в отпуске, компа нет под рукой, проверить. Через пару дней посмотрю.