Софт для ДВК/PDP11

[AFZ]

Вот то, что командный язык у RT-11 прекрасный, согласен на 1000%. Всякие оболочки жрут память, медленно работают, особенно с дисководом. В командной строке можно сделать всё и очень удобно, особенно если загружен SL. Для автоматизации можно воспользоваться IND, ну или как я, написал свой UCL.

Я когда-то тоже пытался сделать аналог Командира Нортона для ДВК. Главным тормозом оказался КЦГД - он отрисовывал полный экран около ТРЕХ секунд. (Тут не так давно по моей просьбе уточняли, получилось 2.7с). После чего коммерческая ценность проекта была признана равной нулю и проект свернут.

[Advertiser]

[perestoronin]

КЦГД наверное не при делах. Нужно научиться на экране отрисовывать изменения средствами КЦГД, а не пересылать через последовательный порт в него картинку экрана с вычислителя вместо этого.

А файловый коммандер изобретать не надо - образец для вдохновений linux-вый mc, и у него должно быть два режима - с одной панелью и с двумя. А еще и окно выполнения, которое можно было бы в любой момент посмотреть.

[AFZ]

КЦГД наверное не при делах. Нужно научиться на экране отрисовывать изменения средствами КЦГД, а не пересылать через последовательный порт в него картинку экрана с вычислителя вместо этого.

Не при делах, как раз, последовательный порт. Тормозит именно рисование. За те самые 2.7с последовательный порт на скорости 56К перешлет 15 Кбайт с копейками, этого хватит на 8 экранов, но КЦГД не в состоянии принять данные на такой скорости и приостанавливает обмен сигналами по линиям сопровождения.

И что значит "отрисовывать изменения"? Естественно, переместить указатель, то есть убрать инверсию текущей строки и проинвертировать новую - дело почти мгновенное, по крайней мере на глаз. А если изменения значительные? Элементарно, на текущем диске файлов (намного) больше, чем влезает в окно. Вот, указатель стоит в последней позиции окна. Двигаем его дальше, и что делать? Как ни крути, а надо перерисовывать бОльшую часть содержимого окна...

А файловый коммандер изобретать не надо - образец для вдохновений linux-вый mc, и у него должно быть два режима - с одной панелью и с двумя.

Вообще-то, в свое время, когда клепали Полуночного Командира, тоже смотрели на Командира Нортона в оба глаза. Так, что особой разницы нет.

А еще и окно выполнения, которое можно было бы в любой момент посмотреть.

А вот с этим на КЦГД совсем плохо. Под "большими" системами, глубоко в них закопавшись, может быть, и удастся что-то сделать (хотя, ИМХО, вряд ли), а под RT-11 это вообще невозможно. Где взять экран выполнения? Это на писюке все эти Командиры перед рисованием на экране своего материала, копируют к себе во внутренний буфер содержимое памяти текстового экрана, а потом в любой момент могут его восстановить. У нас же текстового экрана нет, получить с КЦГД алфавитно-цифровое содержание экрана невозможно. Его там нет, оно сразу конвертится в графику, и все. А вести внутри ОС дубликат - может быть у "больших" систем и есть что-то такое (У TSX, вроде-бы, есть, не знаю, насколько оно адекватно), но на простой RT-11 - индейская народная национальная изба фигвам!

[hobot]

2 form: c Праздником!
В известной папке вот эта версия уже лежит?


или это "устаревший" не актуальный скрип-шот?

[form]

или это "устаревший" не актуальный скрип-шот?

Это старый вариант - когда изучал поведение на грани исчерпания памяти
В новом упор делался на изучение XM версии - там не все так просто: по сути нужно сделать одно-оверлейную программу с минимальным корневым сегментом, а на адресацию буфера при этом остается окно в которое не влезут одновременно два полных буфера панели - их приходится мапить перед началом действий с панелью. Зато такую программу можно загрузить командой SRUN/FRUN на отдельном терминале и она там будет жить параллельно обычной работе. С VBGEXE программами такой номер не пройдет - слишком уж много нижней памяти они жрут, а по сему годятся только для прямого запуска как BG Job.

Теперь вроде все вопросы прояснились и можно начинать добавлять функционал

[perestoronin]

Тормозит именно рисование.

Нельзя с этим ничего сделать? Тормозит программа рисования из ПЗУ 181/182-* или своя самописанная и исполняемая из РЕмулятора установленного на плате КЦГД? Программа рисования оптимизирована дальше некуда, или есть заделы для оптимизации прошивок ПЗУ КЦГД?
Про РЕмулятор написано здесь: http://forum.pk-fpga.ru/viewtopic.php?f=43&t=5450

что особой разницы между нортоном и командиром нет.

Существенная разница - на нортон исходников нет, а на командира есть в свободном доступе.
https://ru.wikipedia.org/wiki/Midnight_Commander

Где взять экран выполнения?

Перерисовывать не весь экран, а лишь обновляемую часть. Перерисовывать на основе "буфера" хранящегося в текстовом виде, а не в графическом. Тем самым удастся укладываться в размеры ОЗУ КЦГД и мощность ВМ2.

Вопрос: никто не пробовал подключать в схему КЦГД вместо кучи, уже дефицитных, РУ5 какой либо китайский легкодоступный чип DRAM-памяти с минимальными изменениями в схеме КЦГД ?
Можно использовать положительный опыт по замене 16 микросхем РУ5 на платках БК на один китайский чип:

• 16 микросхем ОЗУ КР565РУ5 заменены одной DRAM TC511664BJ-80 (к ней дополнительно идут две КР1533АП6 и одна КР555ЛА3)
• на освободившееся место ...
• учтены доработки ..
• добавлена поддержка РЕмулятора, в том смысле, что сигналы CS теперь не надо подводить навесным монтажом
• Большая часть микросхем серии 555 заменена на серию КР1533/КР1531

Не помешало бы и в новодел КЦГД внести эти несущественные доработки, перед его производством, они и ретростиль не сильно нарушат, и живучесть платки улучшат, да и объем ОЗУ немного увеличат, если будет понятно как его использовать в КЦГД.
http://forum.pk-fpga.ru/viewtopic.php?f=15&t=5427

[Error404]

А вот с этим на КЦГД совсем плохо. Под "большими" системами, глубоко в них закопавшись, может быть, и удастся что-то сделать (хотя, ИМХО, вряд ли), а под RT-11 это вообще невозможно. Где взять экран выполнения? Это на писюке все эти Командиры перед рисованием на экране своего материала, копируют к себе во внутренний буфер содержимое памяти текстового экрана, а потом в любой момент могут его восстановить. У нас же текстового экрана нет, получить с КЦГД алфавитно-цифровое содержание экрана невозможно. Его там нет, оно сразу конвертится в графику, и все. А вести внутри ОС дубликат - может быть у "больших" систем и есть что-то такое (У TSX, вроде-бы, есть, не знаю, насколько оно адекватно), но на простой RT-11 - индейская народная национальная изба фигвам!

Почему бы и нет? Только делать дубликат экрана в текстовом буфере не внутри ОС, а внутри своего командера - "переваривая" коды терминала VT-xxx перед выводом их в STDOUT и соответственно корректируя буфер. Я именно так делал для VT-52 на Орионе (где тоже "в железе" графический экран, а в textonly-CP/M текстового буфера не предусмотрено), это не так громоздко получается как может показаться. Опять же в эту же подсистему можно встроить подпрограммы оконного интерфейса, у меня это было сделано по аналогии с VCL и с системой на сообщениях "окнам"/"объектам" (типа как принято на Винде), но можно и еще как-то.

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

Т.е. как раз вот это самое:

Перерисовывать не весь экран, а лишь обновляемую часть. Перерисовывать на основе "буфера" хранящегося в текстовом виде, а не в графическом. Тем самым удастся укладываться в размеры ОЗУ КЦГД и мощность ВМ2.

[form]

К сожаление только 8-битные символы, КОИ-8. Можно конечно загрузить резидент, обрабатывающий <Esc> F и <Esc> G. Я такой писал, называется ESCFG.SAV, но псевдографика там взята вроде бы с КЦГД ДВК.

В дальнейшем можно будет подумать над этим. В последнем тестовом варианте FC предусмотрено принудительное указание типа терминала вместо автоопределения, эти типы можно расширить, добавив разные варианты советских VT52 с псевдографикой - дополнительной памяти это не требует (ну по крайней мере в пределах добавки еще десятка вариантов ).

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

Перерисовывать не весь экран, а лишь обновляемую часть. Перерисовывать на основе "буфера" хранящегося в текстовом виде, а не в графическом.

Это иногда полезно и с чистым текстом делать, порой даже буфера для этого не требуется
Об эффективности подхода можно судить, сравнив между собой RMD в RSX и RTMON в RT. В первом информации на экране много, но обновление для глаза фактически незаметно и часы на экране аккуратно идут с интервалом в секунду. Во втором информации совсем немного, но обновляется весь экран со всеми вытекающими...
В плане же всяких командеров-редакторов можно еще воспользоваться асинхронной перерисовкой (как в K52/KED например) - там при быстром выполнении друг за другом действий, требующих активной перерисовки, в результате получим окончательный вариант на экране.

[Alex_K]

Нельзя с этим ничего сделать? Тормозит программа рисования из ПЗУ 181/182-* или своя самописанная и исполняемая из РЕмулятора установленного на плате КЦГД? Программа рисования оптимизирована дальше некуда, или есть заделы для оптимизации прошивок ПЗУ КЦГД?

Да, тормозит программа эмуляции текстового терминала в ПЗУ 1801РЕ2-181/182. Дело в том, что графический экран у КЦГД в строке содержит 800 точек, а символов в строке 80, т.е. на каждый символ приходится 10 пикселей в строке. В рисунках знакогенератора в строке символа 8 пикселей. Соответственно строка символа может начинаться в одном байте, а заканчиваться в другом, поэтому подпрограмма отрисовки символа осуществляет сдвиг строки символа на нужное количество бит, да еще надо в видеопамяти не стереть неиспользуемые биты, а записать только используемые, т.е. сначала левую часть, а потом правую. Еще запись в видеопамять идет не прямым обращением туда, а через регистры адреса/данных.
Аналогично в УКНЦ, но там всё выровнено по байтам, есть регистры цвета точки и цвета фона, потому запись идет за один приём.

[form]

Гляди - это вариант запуска когда RK0 это система

Выложил обновленный вариант. Была ошибка при работе с устройствами фиксированного размера (RK, VM итд).

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

И еще раз обновил файлы. Добавлен функционал выбора файлов (CTRL/T). Вот теперь точно можно начинать основным функционалом заниматься
Отсюда сразу возникает вопрос: выполнять ли файловые операции внутри командера, рисовать окошки с прогрессом или передавать в KMON команды для PIP?..
Последнее впрочем весьма проблематично для SYS/FG Job, вернее требует некоего драйвера который будет обслуживать такие запросы от всех задач...