Программирование на УКНЦ как?

[Alex]

Программа "Smirnow commander" и прочие, потому так долго экран перерисовывали, так как использовали КЦГД как терминал, единственно что грузилось - фонт. Возможно, фонт грузился и для того, чтобы КЦГД шустрее работал, не 8 пикселов ли в высоту фонт был??
Если красиво рамки рисовать, то используется VT100 мода, а там длинные ESC-последовательности . Тот же "Smirnow commander" в моде VT52 вполне шустро работал. Я его вспомнил, но у меня была версия под VT52.

Когда программа сидит внутри КЦГД - не надо её постоянно грузить и не надо пересылать кучу ESC-последовательностей. По этому всё сильно быстрее происходит

Ещё со мной автор поделился, что у него проблема была с определением завершилась ли программа на ЦП или нет. Его коммандер вылавливал точку с ВК и ПС. Но были программы, кои слали подобное и патченные мониторы со своим промптом....

[Advertiser]

[AFZ]

Если красиво рамки рисовать, то используется VT100 мода, а там длинные ESC-последовательности.

Длина самой ESC-последовательности - ерунда. Тормозит сам КЦГД, особенно в режиме VT240. Полетаев рассказывал, что первоначально пытались сочинить отдельную ВП1 которая будет передавать байты параллельным кодом, потом посмотрели, что и на 56К загрузка этих двух -065-х не превышает 50%, да и плюнули на это дело...

Когда программа сидит внутри КЦГД - не надо её постоянно грузить и не надо пересылать кучу ESC-последовательностей. По этому всё сильно быстрее происходит

Вообще-то, как раз, это - мелочи. Загрузить этого самого командира и один раз отрисовать экран - можно и подождать. А вот когда на диске несколько тысяч файлов, а командир способен показать, максимум, 60 файлов, попробуй добраться до конца списка. Это когда на диске 100=200 файлов, еще как-то терпимо...

[form]

Это когда на диске 100=200 файлов, еще как-то терпимо...

А есть диски с таким количеством файлов, что команда COP *.* DDN: оборвется по ошибке
К примеру V5.7 source kit.

[Alex]

Ведь товарищ этот ушёл от PIP, свою утилиту написал... Справилась бы его утилита - не ведаю. V5.7 source kit тогда ещё не было
Тормоза КЦГД в режиме VT240 - это особенность реализации. У меня не было КЦГД в режиме VT240, только VT100. В режиме VT52 КЦГД работал быстрее.
У него своя загрузка была в моде VT240 на тот момент не работавшая.

Из проблем - автор ещё жаловался, что памяти мало в КЦГД и задумывался над алгоритмами сжатия. Я ему тогда присоветовал свою простенькую утилиту вместо DIR накатать, коя бы чисто каталог как есть, физическими блоками в КЦГД отправляла для последующего разбора и отображения. Там и так сжатие хорошее, если пустых мест от удалённых файлов нет. RADIX-50 в именах и всё компактно Но скорее всего он это не сделал . Ушёл на PC.

[form]

Справилась бы его утилита - не ведаю. V5.7 source kit тогда ещё не было

Зависит от того как она работает.
Если просто копирует файлы - не справилась бы.
Там проблема в алгоритме заполнения сегментов - просто происходит переполнение.
Вариант копирования без ошибок - SQ/OUT:DDN

[Alex]

То есть глюк в PIP?

[form]

То есть глюк в PIP?

Нет.
Просто при штатном создании файлов алгоритм такой в RT-11: как заполняется половина сегмента каталога - открывается следующий и начинает заполняться он.
Если файлов очень много - наступает момент когда новый файл воткнуть некуда, хотя промежуточные сегменты заполнены только наполовину.
Приходится делать SQ и повторно копировать без перезаписи.
Это вобщем-то документировано.

[Alex]

Я помню, что под файл при открытии может получить либо столько места, сколько просит, либо если не ведом конечный объём - половину от наибольшей свободной области, либо вторую по размеру. Но при копировании вроде всегда конечный размер файла известен. И насколько помню, всё ложилось без зазоров. Я правда на RT-11 V5.02 в основном работал. RT-11 V5.04 у меня в конце моей работы на ДВК появилась, я с ней только опыты проводил
И вроде как сегменты дополнительные в каталоге приходилось создавать, так как файлов было много. Хотя скорее всего не достиг того количества файлов.
Винчестеры на моих ДВК были в 10 мегабайт.... Знаю, что были в 5 и 20 мегабайт...

[form]

Я помню, что под файл при открытии может получить либо столько места, сколько просит, либо если не ведом конечный объём - половину от наибольшей свободной области, либо вторую по размеру.

#0 - половина, #-1 - максимальная дырка

Еще в RMON есть смещение, отвечающее за реальный максимум.
Посмотрел в VKMON - настройку такую не сделал.
Хотя вроде собирался

[AFZ]

Это расход дискового пространства. Но, кроме того, штатный алгоритм программы USR для выделения памяти в сегментах оглавления тоже хромает. И когда файлов сильно много, спотыкается, в результате чего всю память оглавления за один проход (одну перезапись большого количества файлов) не займешь - USR не умеет сжимать оглавление. Чтобы записать стандартным образом (.ENTER - .WRITx - .CLOSE, как делает и PIP) нужно записать, сколько получится, затем сжать диск и затем продолжить запись (COP/NOREP). И, может быть, не один раз. То есть, файловая система RT-11 хорошо работает, когда диск заполнен не более, чем на 50% - и оглавление, и пространство для данных. Можно натолкать и больше, но появятся неудобства, вроде перечисленных. Диск, который не требует частых перезаписей (например, системный) можно натолкать "до упора", а вот рабочие диски лучше всего ведут себя, будучи занятыми процентов на 20-30. Хотя, опять же, многое зависит от того, какие программы работают...