Немного сложный, немного простой текстовый редактор (Страница 1 из 3)

Он был встроен в собственный ДОС..., но вроде есть исходник, надо смотреть... Да и функций там в редакторе минимум. Домой приду-выложу образ. Там прикольно все выглядит, жаль не доделал в свое время.

Что касается ассемблера Школьницы, то вчера впервые увидел сообщение наподобие: "Таблица меток переполнена" ))

Кончился буфер для меток)) Первый раз такое. Это примерно 11,5к строк с некоторыми комментариями. Ну или около 24Кб кода.

UPD. Вот нашел. Диск загрузочный. Свой ДОС. При старте запускается редактор текста. Но он ничего не умеет кроме как символы набирать и строки вставлять. Ну и печатает еще картинку экрана, если принтер в 4-м слоте, по клавише"@". Зато редактор в графике сделан 512х256. И скорость движения текста приличная. Подозреваю, там алгоритм вывода текста оптимизирован. Исходники где-то были вроде, надо искать. Но там явно завязки на функции ДОСа своего...
"Ред"-выход в ДОС, уже в текстовый режим. Команда "list"  выводит список команд ДОС.
Все это не доделано, но вот такое вот было. Это где-то 92-94гг, не позже.
Извиняюсь что офтопик.

Похоже что он))

Что значит абсолютных адресов? Вот эти вот ячейки что-ли? $99, $9A, $A2?

Ну там данные какие-то хранятся... размер окна и т.п.

А! ну это мой дурной стиль. Видимо было лень пару лишних символов набирать))

Прошерстил уже больше половины, очень напоминает редактор ДОК, в смысле такое же деление буфера на две части. Но у ДОК деление буфера происходило кратно строке, а тут, похоже, по текущему символу.

Скорость в графике приличная потому что кое что оптимизировано: например, при скролинге экрана перевыводятся/перемещаются только изменившиеся символы. Фактически, все операции идут в скрытом текстовом режиме, в графику только зеркалируются изменения. Кроме того: там же только окно - оно меньше половины экрана. Развернуть его на полный экран - будет медленнее.

Исходник не очень тяжелый для понимания, после разбора линкера почти халява.

Я не буду пока его улучшать, только хочу разобрать, прокомментировать, заменить численные константы на символьные. Потом проверю на совпадение результатов компиляции (исходной и моей версии).

Затем уберу поддержку графики, чтобы чуть упростить и попробую перетащить под cc65 с возможностью сборки под ИКП-Бейсик и ДОК. Будет нормальная такая демка для cc65.

(
Когда-то мне очень хотелось написать свой (или адаптировать из ДОК) редактор текста, сразу под бейсик-60. Даже начал над этим работать, старался приблизить редактор ДОК к чему-то вроде редакторов борландовских IDE. Чтобы была и вставка символов по умолчанию и прочие плюшки. Однако закончить эту работу не успел.

Но после разбора кучи коллекций интерес пропал - мы нашли много новых редакторов текста для Агата, хотя я и не копался до сих пор в них.
)

> Да? А я вот особо сам себя понять не могу))

У современных текстовых редакторов есть чудесная функция: поиск с заменой. Особенно если есть поддержка регулярных выражений. Это позволяет такой кусок:

 LDA#>TFЙ
 STA$360
 LDA#<TFЙ
 STA$361
 LDA#>TF4
 STA$328
 LDA#<TF4
 STA$329
 LDA#>TFД
 STA$300
 LDA#<TFД
 STA$301

довольно быстро превращать в такой:

; Задаём собственные callback-функции к досовским операциям

 LDA #>MY_PUTCHAR
 STA DOS_H_PUTCHAR+0
 LDA #<MY_PUTCHAR
 STA DOS_H_PUTCHAR+1

 LDA #>MY_SCROLL_WIN
 STA DOS_H_SCROLL_WIN+0
 LDA #<MY_SCROLL_WIN
 STA DOS_H_SCROLL_WIN+1

 LDA #>MY_SET_VIDEO_MODE
 STA DOS_H_SET_VIDEO_MODE+0
 LDA #<MY_SET_VIDEO_MODE
 STA DOS_H_SET_VIDEO_MODE+1

становится всё гораздо яснее.

Сейчас часть текста у меня выглядит примерно так:

REЭ4
 JSR REM41
 LDY #$00
 LDA ($A1),Y
 JSR REM4
 CMP #CHAR_CR
 BEQ REЭ55
 CLC
REЭ55
 JSR REZ
REЭ54
 LDA DOS_DRAW_X1
 STA ED_PH_COL
REЭ5
 LDX ED_PH_COL
 LDY ED_PH_LINE
 JSR DOS_VT_CALC
REЭ12

- тут кое что уже распознано, но ещё пока не всё.

Парочка вопросов:

1) В коде есть процедуры вывода текста в графике, но нет чтения шрифта. Хотя в памяти он уже есть. Т.е. как бы получается, что ДОС читает шрифт сама, но не имеет операций с графическим режимом. Почему ? В autoexec команд чтения отдельных файлов шрифта тоже нет, да и самих файлов я не вижу. Или сам редактор собран со шрифтом встроенным?

2) Часть ДОС-векторов лежит в регионе $3xx и ещё часть в $4xx. Как я понял, регион 3 - это просто вектора на функции ДОС. А вот 4 - это вроде как хуки для встраивания своих callback-функий (Т.е. мы вызываем, например, функцию вывода символа. ДОС выводит символ в текстовое окно, а потом вызывает зарегистрированную нами (callback) функцию, в которой мы выводим тот же символ уже в графике) ? Или такого деления нет ? В то же время есть операция копирования региона 4 на 3 перед выходом из редактора. Она совсем сбила меня с толку.

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

Почему не было сделано по другому: ведь, например, стрелка - это смена координаты курсора. X++, X--, Y++, Y--. Ну максимум, можно проверить границы - первая или последняя строка сейчас (для Y). Для X достаточно сравнить с границами окна. ВВОД - вставка строки плюс X=0, Y++.

А дальше одна общая процедура, которая, в соответствии с X/Y перестраивает (согласует) остальные внутренние структуры. Например, пересчитывает верхнюю экранную строку, перевыводит экран, если надо.

Сейчас, чтобы, например, добавить листание PgUp/PgDown (не, тут у тебя предусмотрен скрол на несколько строк) или переход на заданную строку (поиск, например) нужно написать ещё кучу процедур.

Был ли такой выбор обусловлен оценкой скорости, например ?

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

Да ладно!

Loop:
 lda (zp1),y
 sta (zp2),y
 iny
 bne Loop

Это 16 тактов на байт, а значит 64КБ в секунду.

Сегодня вспомнил одну штуку: в 90-е пользовался попеременно то Агат-Автором, то редактором ДОК. У ДОК было одно занятное преимущество: когда нажимаешь стрелку и ПВТ, курсор бежит и его отчётливо видно. В Агат-авторе же курсор пропадал. Т.е. если кнопки отпустить он появлялся в новом месте, но было непросто угадать, где именно он появится.

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

Это к слову об оптимизации кода.

> Да при любой скорости копирования, если есть возможность не двигать 10Кб на каждый чих, то лучше не двигать :)

Алгоритмы усложняются. Тут балланс желателен.

В этом редакторе около 2000 строк. За счёт чего удалось так оптимизировать? Его код связан с тем, что мы рассматриваем в этой ветке? Как-то можно их назвать по именам или номерам, чтобы не путаться при обсуждении?

Кажется, нашлась одна серьёзная ошибка или недоделка:

редактор располагается в памяти где-то в адресах $4000.49ff, а его буфер (заданный, похоже, операционной системой) - в адресах $2800.BEEE.

О программной архитектуре редактора.
Весь код крутится вокруг следующих глобальных переменных:

ED_P_HI_CUR EQU $5C ..$5D  Указатель на текущий символ в верхней части буфера
ED_P_LO_CUR EQU $5E ..$5F  Указатель на текущий символ в нижней части буфера

ED_PH_COL   EQU $75        Физическая (экранная) колонка курсора
ED_PH_LINE  EQU $76        Физическая (экранная) строка курсора

ED_P_LO_BUF EQU $97 ..$98  Указатель на начало текстового буфера
ED_P_HI_BUF EQU $99 ..$9A  Указатель на конец текстового буфера

ED_P_TOP_LN EQU $91 ..$92  Указатель на строку, выводимую в первой физической строке экрана                         

ED_NT_LN_DC EQU $9B ..$9C  Номер строки, выводимой в первой физической строке экрана (в десятичном представлении)
ED_NLINE_DC EQU $9D ..$9E  Номер текущей строки в десятичном представлении

Переменные ED_P_*_CUR задаются до запуска программы операционной системой - это указатели на доступную память. В самом начале редактора их значения копируются в ED_P_*_BUF, а в начале и конце буфера записываются символы перевода строк - они нужны для корректной работы алгоритмов поиска разделителей строк.

Также важны ещё четыре значения:

; Эти ячейки описывают графическое окно для функий ОС, в дальнейшем редактор использует их в этом же значении
DOS_WIND_X1 EQU $7A
DOS_WIND_Y1 EQU $7B
DOS_WIND_X2 EQU $7C
DOS_WIND_Y2 EQU $7D
; В нынешней версии их значения - константы, но код относится к ним как к переменным. Т.е. размер и положение окна редактора можно менять (однако это не отлаживалось и не будет работать идеально).
; Важно: номера строк выводятся левее X1. Т.е. эти границы определяют именно вывод редактируемого текста !

Перечисленные выше ячейки хранятся постоянно, редактор во всех операциях исходит из их значений. Почти все остальные переменные будут вычислятся из них.

Буфер текста делится на две части: P_LO_BUF .. P_LO_CUR и P_HI_CUR .. P_HI_BUF.
Любое движение курсора приводит к сдвигу границ P_LO_CUR и P_HI_CUR. Если они смыкаются (это проверяется при любых операциях вставки) редактор выводит сообщение "Ошибка".

Код построен так, что каждая операция (нажатие стрелок, клавиши ВВОД, ввод символов) выполняет только минимально необходимые операции. Фактически, каждая клавиша имеет свой обработчик, который выполняет только те проверки и перемещения байт, которые необходимы здесь и сейчас. Здесь мало общих процедур, почти весь код обработчиков линеен. Отдельные крупные процедуры (используемые всеми обработчиками):

SCROLL_UP_AND_OUT_SCREEN - прокрутка экрана вверх на заданное в X число физических строк.
SCROLL_DN_AND_OUT_SCREEN - прокрутка экрана вверх на заданное в X число физических строк.
OUT_FULL_SCREEN - обновление всего экрана.
OUT_REST_OF_SCREEN - обновление экрана от курсора и ниже.

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

По агатовской традиции, если логическая строка не помещается в физическую, её делят на несколько физических строк (Есть и другая традиция: выводить только часть логической строки в физическую, таким образом избегая переноса. На агате почему-то не использовалась, хотя для текстов программ это было бы правильнее).

Существенную часть кода редактора занимает именно расчёт соответствий физических строк логическим и наоборот.

Отдельную сложность добавляет особый режим перемещения курсора - полностью свободный ("ДОК-стиль"). Т.е. вы можете двигать курсор в любое место экрана, даже если символов там нет (за знаком "перевод строки"). В этом случае редактор создаёт "виртуальные" пробелы - они не существуют в тексте до тех пор, пока вы не введёте любой символ. При этом виртуальные пробелы становятся реальными, за ними будет следовать и введённый символ.
Если же просто увести (стрелками) курсор с данной строки, виртуальные пробелы из неё исчезают.

ED_VIRT_SPC EQU $90        Количество позиций, на которые курсор правее последнего символа (где как бы нет символов)

О переменных *DC. Эти переменные, хотя и вычисляются редактором при различных операциях, не используется нигде иначе чем для вывода на экран. Они хранятся как шестнадцатерично-десятичные, таким образом максимальный номер строки - 9999. Однако, так как само значение редактору не важно, он может работать и с большим числом строк и за номером 9999 вы увидите на экране строку 0.

Поддержка графики и печать экрана на принтер выполнены как бы немного сбоку от основного кода - они используют свои переменные (довольно далеко от регионов основных переменных). Кроме того, поддержка графики реализована в виде callback функций ДОС: т.е. редактор обращается для ввода / вывода к операционной системе, а она, выполнив операции в текстовом окне, вызывает процедуры редактора, которые дублируют вывод в графическом окне (на это время переключаются модули памяти).