Вид для печати
Я когда-то тоже пытался сделать аналог Командира Нортона для ДВК. Главным тормозом оказался КЦГД - он отрисовывал полный экран около ТРЕХ секунд. (Тут не так давно по моей просьбе уточняли, получилось 2.7с). После чего коммерческая ценность проекта была признана равной нулю и проект свернут.Цитата:
Сообщение от Alex_K
КЦГД наверное не при делах. Нужно научиться на экране отрисовывать изменения средствами КЦГД, а не пересылать через последовательный порт в него картинку экрана с вычислителя вместо этого.
А файловый коммандер изобретать не надо - образец для вдохновений linux-вый mc, и у него должно быть два режима - с одной панелью и с двумя. А еще и окно выполнения, которое можно было бы в любой момент посмотреть.
Не при делах, как раз, последовательный порт. Тормозит именно рисование. За те самые 2.7с последовательный порт на скорости 56К перешлет 15 Кбайт с копейками, этого хватит на 8 экранов, но КЦГД не в состоянии принять данные на такой скорости и приостанавливает обмен сигналами по линиям сопровождения.Цитата:
Сообщение от perestoronin
И что значит "отрисовывать изменения"? Естественно, переместить указатель, то есть убрать инверсию текущей строки и проинвертировать новую - дело почти мгновенное, по крайней мере на глаз. А если изменения значительные? Элементарно, на текущем диске файлов (намного) больше, чем влезает в окно. Вот, указатель стоит в последней позиции окна. Двигаем его дальше, и что делать? Как ни крути, а надо перерисовывать бОльшую часть содержимого окна...
Вообще-то, в свое время, когда клепали Полуночного Командира, тоже смотрели на Командира Нортона в оба глаза. :) Так, что особой разницы нет.Цитата:
Сообщение от perestoronin
А вот с этим на КЦГД совсем плохо. Под "большими" системами, глубоко в них закопавшись, может быть, и удастся что-то сделать (хотя, ИМХО, вряд ли), а под RT-11 это вообще невозможно. Где взять экран выполнения? Это на писюке все эти Командиры перед рисованием на экране своего материала, копируют к себе во внутренний буфер содержимое памяти текстового экрана, а потом в любой момент могут его восстановить. У нас же текстового экрана нет, получить с КЦГД алфавитно-цифровое содержание экрана невозможно. Его там нет, оно сразу конвертится в графику, и все. А вести внутри ОС дубликат - может быть у "больших" систем и есть что-то такое (У TSX, вроде-бы, есть, не знаю, насколько оно адекватно), но на простой RT-11 - индейская народная национальная изба фигвам!Цитата:
Сообщение от perestoronin
2 form: c Праздником!
В известной папке вот эта версия уже лежит?
http://pdp-11.org.ru/~form/files/pdp-11/rt-11/fcnow.png
или это "устаревший" не актуальный скрип-шот?
:redface:
Это старый вариант - когда изучал поведение на грани исчерпания памяти :)Цитата:
Сообщение от hobot
В новом упор делался на изучение XM версии - там не все так просто: по сути нужно сделать одно-оверлейную программу с минимальным корневым сегментом, а на адресацию буфера при этом остается окно в которое не влезут одновременно два полных буфера панели - их приходится мапить перед началом действий с панелью. Зато такую программу можно загрузить командой SRUN/FRUN на отдельном терминале и она там будет жить параллельно обычной работе. С VBGEXE программами такой номер не пройдет - слишком уж много нижней памяти они жрут, а по сему годятся только для прямого запуска как BG Job.
Теперь вроде все вопросы прояснились и можно начинать добавлять функционал :)
Нельзя с этим ничего сделать? Тормозит программа рисования из ПЗУ 181/182-* или своя самописанная и исполняемая из РЕмулятора установленного на плате КЦГД? Программа рисования оптимизирована дальше некуда, или есть заделы для оптимизации прошивок ПЗУ КЦГД?Цитата:
Сообщение от AFZ
Про РЕмулятор написано здесь: http://forum.pk-fpga.ru/viewtopic.php?f=43&t=5450
Существенная разница - на нортон исходников нет, а на командира есть в свободном доступе.Цитата:
Сообщение от AFZ
https://ru.wikipedia.org/wiki/Midnight_Commander
Перерисовывать не весь экран, а лишь обновляемую часть. Перерисовывать на основе "буфера" хранящегося в текстовом виде, а не в графическом. Тем самым удастся укладываться в размеры ОЗУ КЦГД и мощность ВМ2.Цитата:
Сообщение от AFZ
Вопрос: никто не пробовал подключать в схему КЦГД вместо кучи, уже дефицитных, РУ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
Почему бы и нет? Только делать дубликат экрана в текстовом буфере не внутри ОС, а внутри своего командера - "переваривая" коды терминала VT-xxx перед выводом их в STDOUT и соответственно корректируя буфер. Я именно так делал для VT-52 на Орионе (где тоже "в железе" графический экран, а в textonly-CP/M текстового буфера не предусмотрено), это не так громоздко получается как может показаться. Опять же в эту же подсистему можно встроить подпрограммы оконного интерфейса, у меня это было сделано по аналогии с VCL и с системой на сообщениях "окнам"/"объектам" (типа как принято на Винде), но можно и еще как-то.Цитата:
Сообщение от AFZ
- - - Добавлено - - -
Т.е. как раз вот это самое:
Цитата:
Сообщение от perestoronin
В дальнейшем можно будет подумать над этим. В последнем тестовом варианте FC предусмотрено принудительное указание типа терминала вместо автоопределения, эти типы можно расширить, добавив разные варианты советских VT52 с псевдографикой - дополнительной памяти это не требует (ну по крайней мере в пределах добавки еще десятка вариантов :)).Цитата:
Сообщение от Alex_K
- - - Добавлено - - -
Это иногда полезно и с чистым текстом делать, порой даже буфера для этого не требуется :)Цитата:
Сообщение от perestoronin
Об эффективности подхода можно судить, сравнив между собой RMD в RSX и RTMON в RT. В первом информации на экране много, но обновление для глаза фактически незаметно и часы на экране аккуратно идут с интервалом в секунду. Во втором информации совсем немного, но обновляется весь экран со всеми вытекающими...
В плане же всяких командеров-редакторов можно еще воспользоваться асинхронной перерисовкой (как в K52/KED например) - там при быстром выполнении друг за другом действий, требующих активной перерисовки, в результате получим окончательный вариант на экране.
Да, тормозит программа эмуляции текстового терминала в ПЗУ 1801РЕ2-181/182. Дело в том, что графический экран у КЦГД в строке содержит 800 точек, а символов в строке 80, т.е. на каждый символ приходится 10 пикселей в строке. В рисунках знакогенератора в строке символа 8 пикселей. Соответственно строка символа может начинаться в одном байте, а заканчиваться в другом, поэтому подпрограмма отрисовки символа осуществляет сдвиг строки символа на нужное количество бит, да еще надо в видеопамяти не стереть неиспользуемые биты, а записать только используемые, т.е. сначала левую часть, а потом правую. Еще запись в видеопамять идет не прямым обращением туда, а через регистры адреса/данных.Цитата:
Сообщение от perestoronin
Аналогично в УКНЦ, но там всё выровнено по байтам, есть регистры цвета точки и цвета фона, потому запись идет за один приём.
Выложил обновленный вариант. Была ошибка при работе с устройствами фиксированного размера (RK, VM итд).Цитата:
Сообщение от hobot
- - - Добавлено - - -
И еще раз обновил файлы. Добавлен функционал выбора файлов (CTRL/T). Вот теперь точно можно начинать основным функционалом заниматься :)
Отсюда сразу возникает вопрос: выполнять ли файловые операции внутри командера, рисовать окошки с прогрессом или передавать в KMON команды для PIP?..
Последнее впрочем весьма проблематично для SYS/FG Job, вернее требует некоего драйвера который будет обслуживать такие запросы от всех задач...