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

[hobot]

Дальше на эту тему спорить не буду

я и не спорю и на вас не наезжаю, просто я пишу основываясь на реальном опыте - это раз!

И два: СМИТ и БАТОН не глупее нас с вами были(а может и есть)дядьки.
Они не спроста однопанельку накатали - поверьте могли и 8 экранный накатать )))
Так что опять же - моноэкран был выбран не с воздуха! )

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

Достаточно команды DIR

любой системщик из системной строки не вылазя сделает всё что надо без всяких шелов.
Так что в RT-11 достаточно командной строки в любом случае ))) Если на то пошло )))

PAFCOM - делался в 609 по запросу от бухгалтерш ИМХО )))
И с подглядыванием на стоявшие по соседству 386 )))
Но насколько он неповоротливый по сравнению с шустрой MFP?

[Advertiser]

[perestoronin]

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

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

[AFZ]

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

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

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

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

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

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

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

[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

[Alex_K]

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

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

[AFZ]

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

Подозреваю, что никто в эти прошивки детально не вникал. Опять же, подозреваю, что грубых ляпов там нет, то есть никакая оптимизация не даст существенного ускорения. (Ускорение даже в два раза существенным считать нельзя - надо хотя бы в 10 раз).

Существенная разница - на нортон исходников нет, а на командира есть в свободном доступе.

И толку с них? Там же ничего особо военного нет, все действия прозрачны. Это с одной стороны. С другой - нельзя забывать, что Полуночный командир сделан для существенно более мощных процессоров, ресурсы которых превосходят наши не на один порядок, так, что его творцам не нужно было задумываться о какой-либо оптимизации там, где нам придется экономить весьма жестко. То же самое адресное пространство - у них 4Г, у нас - 64К...

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

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

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

Тут вся беда в том, что 5-в микросхемы обычной DRAM - тоже глубокое ретро. Тогда уж статику туда забабахать...

[form]

Как только программа попытается порулить отображением средствами VT52/VT100, этот буфер полностью теряет актуальность. Отслеживать это дело самому?

Тут не нужно отслеживать весь экран, тут нужно отслеживать элементы на нем которые требуют перерисовки. В рамках же командера по идее и вовсе отслеживать ничего не надо: там и так известно что перерисовать (и вариантов немного)

[Alex_K]

Подозреваю, что никто в эти прошивки детально не вникал. Опять же, подозреваю, что грубых ляпов там нет, то есть никакая оптимизация не даст существенного ускорения. (Ускорение даже в два раза существенным считать нельзя - надо хотя бы в 10 раз).

Я начинал вникать, но не окончил. На предыдущей странице топика я описал алгоритм вывода символа на графический экран, ну а собственно дизассемблированная прошивка - тут.

[AFZ]

В рамках же командера по идее и вовсе отслеживать ничего не надо: там и так известно что перерисовать (и вариантов немного)

Естественно. Мы же обсуждаем т.наз. экран задачи. То, что было перед запуском командера, то, что образуется после запуска какой-либо программы или выдачи команды.

Вот мы подали какую-нибудь команду на исполнение. Наш командир выгружается и запускает исполнение этой команды. Во время выполнения идет выдача на экран и стоит задача как-то сохранить эту выдачу - ведь запустившийся командир все это благополучно сотрет. У писюка все просто, в его видеоадаптере есть текстовый буфер экрана, по два байта на знакоместо, байт - код символа, байт - атрибуты (цвет/яркость, мигание, подчеркивание и т.д.) Сохрани этот буфер, запомни положение курсора, и все, можешь восстановить этот экран в любой момент. А как это сделать с нашими VT52/VT100? Ну, разве что завести буфер в 2*1920 символов и сэмулировать в нем работу терминала перед тем, как отдать это на реальный терминал. Но это такой огород, что ой! Да и где все это держать - оно ведь должно работать во время работы системы и исполняемой ею программы, а там свободной памяти нет вообще!

То есть, конечно, если исполняемая программа ведет "простую" выдачу, без использования ESC-последовательностей управления VT52/VT100, то особых сложностей нет, кроме вопроса, где держать буфер. Только это ведь существенное ограничение на исполняемые программы...

Я начинал вникать, но не окончил.

Я тоже начинал. Но эта программуля - порядка 2000 строк ассемблерного текста, это же 30-35 страниц. В то время, когда я этим занимался, не нашлось желающих оплатить эту работу, а энтузиазм иссяк после разбора 15-20% от всего...

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

Потом и до точки доберемся - ввода команды пока все-равно нету

Так надо не точку, а название и номер диска, куда назначен DK:.

[Error404]

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

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

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

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

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