nedoPC.org

Файлом конфигурации переназначить на свой вкус можно ли?
А на одновибраторах с задержкой сигнала от светового пера на 50-60 мкс можно ли дело поправить, раз в знакоряде по 10 линий?
(Хотя, вообще-то сейчас проблема в том, какое и как световое перо физически подключить бы!)

А так, программно это решается одним байтом.Типа такого?Попробуйте запустить редактор, но в PC директивой X пусть будет 0, в DE - 2100. Повлияло на производительность?

На самом деле, так ещё перед каждым выводом строки стоит вызов F812, иначе клавиатура очень вяло реагирует.
В самом начале разработки отображался голый текст.
Убрать нумерацию строк - не проблема, так как занимает кучу кода.
А вот для пользователя такой текст будет ли удобен?

P.S.: Спасибо за тестирование!

Нет, Alt+V - это, как через тв-тюнер, а на телевизоре ещё меньше.

Последнее - снимок с физического экрана?
Если на реальном железе, будьте добры высказаться о производительности.
(В режиме с отладчиком (PC=0800 в X) и без (PC=0000).)

Вижу, что верхняя и нижняя строки почти читабельны.
(Вообще-то верхнюю я сделал для личных нужд отладки.)

А вот левый край - удручает.
Первые символы строк не видно - это совсем плохо!

(Интересно, подстройка режима ВГ75 может как-то помочь? Типа, увеличить с 78 до 80 символов или изменить длительность ССИ.)

Изображения подписаны.

Emu80 достаточно точно эмулируется производительность.

Не стоит. В стандартном режиме использовать прямоугольник 64x25, но на пару символов правее.

Вот только, извините уж, но я этого не писАл...

Увы, пока нет. В планах есть, но пока руки не дошли сделать...

Думаю, должно получиться, хотя возможны нюансы. Непонятно, например, зачем на Кристе сдвинули экран относительно РК и Микроши. Есть подозрение, что из-за каких=то проблем со световым пером (иначе зачем было ломать совместимость), но вот каких именно - непонятно...

Нет, это еще тормознее традиционного способа получилось, чуть позже постараюсь привести пример.

Да, стало значительно лучше, но тормоза все равно ощущаются...

Неплохо бы вообще от F812 избавиться, как источника тормозов. А в идеале избавиться и от F803 и постараться сделать все на F81B Но это непросто, я думаю, особенно без прерываний от таймера...

Да, ТВ-тюнер - это идеал, телевизоры дополнительно обрезают картинку, даже многие ЖК, а не только ЭЛТ...

Типа такого (см. вложения).
Один вариант очень быстрый, но большой по объему, второй - чуть медленнее, но более компактный.
(перед запуском заполнить чем-нибудь экран)

Парсинг текста на предмет табуляции много времени требует.

А ещё сейчас подсчёт первой экранной строки буфера происходит нудным сканированием обратно: Можете проверить, указав через X в DE произвольный адрес в интервале до 2EFF.

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

Конечно, сейчас очевидно, что пока каретка не выходила за верхний/нижний край экрана, пересчёт строк делать не нужно. Это дело добавления ещё одного флажка.
Ну, почему же?
Например, директива D Монитора обращается к F812 по 58 раз за строку - это норма. Это тормозит до нажатия любой клавиши.
У меня это - вынужденная мера. Попробуйте занулить три ячейки по адресам 03D1-03D3 и сравните: Вывод быстрее, но перемещаться курсором становится тормознее.
А вот обращение к F81B - тоже не панацея. В ZX-Spectrum'е существовали игры, где в опциях по переназначению клавиш забыли добавить антидребезг и хоть какую-то паузу. Как итог, одна клавиша назначалась махом на все действия и в игру невозможно было играть. Видимо, владельцы Kempstone-джойстиков тестировали и не заметили такой баг.
Переписать код, чтобы стрелочные клавиши работали через F81B можно, но это трата драгоценных байтов редактора (под вариант для ПЗУ F000-F7FF).
Ну, если так, то можно:
На стеке только вертикальную прокрутку можно сделать, но не отображение строки: Горизонтальная прокрутка не ускорится.

А в целом...
Необходимо именно редактируемую строку в отдельном подбуфере изменять и отображать. При переходе к другой строке текущую следует в общий буфер вставить, предварительно его раздвинув/ужав.
Это же в Бейсиках происходит в манипуляциях листинга.
И об этом я думал, но хотелось просто хоть как-то код заставить работать.
Но, именно заточка под ПЗУ, когда портить ОЗУ промежуточными буферами нежелательно, отодвинуло это на второй план.

Все эти недели я только и боролся с тем, чтобы код - элементарно не падал.
Фрагменты с корректированием табуляции - самое больное место: Весь текст искажается в случае просчёта.
А ещё есть страшные подпрограммы возвращения указателя на текст по координате каретки с учётом табуляции - вот настоящий адский уголок!!!

Сейчас я побаиваюсь что-то оптимизировать.
Нужно продумать базовую логику и переписать всё с чистого листа.

Хотя...
Можете запустить промежуточный вариант где мышью работает прокрутка вниз/вверх скроллингом и отображением одной ключевой строки.
Выглядит шустро и весело, но имеются баги и все 2 Кб памяти занято уже.
(Сравните текст приветствия по G0).

P.S.: А если вдуматься, редакторы "Микрон" и "WEL" значительно уступают в скорости, но тысячи пользователей как-то справлялись.

В принципе, тоже рабочий вариант, хотя и менее универсальный и чуть медленнее по тактам.
Я имел в виду, что сделать горизонтальную прокрутку, а потом вывести вертикальный ряд символов. Но для этого нужно реализовать хранение каких-то метаданных о тексте - адресов начала строк, например, как-то учесть табуляцию и т.п. Я как-то упустил момент, что редактор предполагается к испоkьзованию в ПЗУ, объем ограничен и использование доп. буферов нежелательно, так что наверное действительно здесь это неприменимо...

Насчет F812... Не нравится мне, как это реализовано в РК. Тут надо учесть, что при нажатии клавиши задержка с озвучиванием клавиши будет именно в вызове F812, а вызов F803 уже отработает мгновенно, поэтому в целом связка F812+F803 работает не очень предсказуемо. Но опять-таки все упирается в размер, к тому же у Партнера, для которого я переписывал работу с клавиатурой, клавиши герконовые, с дребезгом проблем нет...

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

При открытии файла .rkr реально падает. Отличный пример. Надо разобраться.
При загрузке через команду I - нормально.

У меня и так используются все ячейки Монитора, которые на период сессии редактора никак не используются:

• 760D - подпрограмма ввода с ленты сохраняет там регистр SP
• 7614-761F - директивой X Монитора хранятся значения регистров PC/HL/BC/DE/SP/AF
• 7633-7652 - буфер ввода директив Монитора

Соответственно, в этих ячейках я сохраняю состояние редактора, а ячейки с 7633 служат буфером хранения массива указателей на каждую из 25 строк.
(Так, прокрутка вверх просто перезаписывает указатель на начало отображение из ячеек 7635-7636.)

К тому же и стек расположен как у Монитора - под 76D0: Много вложенных вызовов совершать нельзя.

P.S.: Сейчас написал и отладил отдельную подпрограмму отображения нумерации строк с заполнением массива адресации строк, так как при экспериментальной той экспресс-прокрутке они затираются на экране.
Вроде бы пустяк, а часа два ушло на отладку крошечной процедуры - видимо сказывается уже переутомление.

Именно так и было.

Всего-то лишний байт E6 в начале файла, а какая реакция Эмуль хочет грузить файл в адрес E600, что явно за пределами 32Кб.

Вопрос: всегда ли надо пропускать начальный байт E6? А вдруг загрузочный адрес действительно в области E600 (например для другого компьютера с 64Кб памяти).

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

Исправил эмулятор. Теперь грузит без ошибки.

Сделал какую-то проверку в итоге? Я пока просто всегда пропускаю, хотя для некоторых РК-подобных компов теоретически действительно может быть что-то в этой области...