С любовью к вам, Yandex.Direct
Размещение рекламы на форуме способствует его дальнейшему развитию
по кодировкам. можно писать русские буквы в 866 и включать в db ""(любимый Emeditor, ага). ужясм хавает и не плачет. только ему слэши не нравятся.
А чем не нравится IS-DOS? Полный набор: оконный интерфейс, система перемещаемых драйверов памяти, дисков, клавиатуры, файловая система, куча прикладного софта. Есть и другие оси. DOORS - не щупал, не знаю, но наверняка тоже все атрибуты ОС имеются. Просто данная тема форума - про собственный, отдельный оконный интерфейс.
"Во времена всеобщей лжи говорить правду - это экстремизм" - афоризм.
Barmaley_m, Вопрос по твоей оконной системе.
В модуле работы с клавиатурой есть код:
Физический смысл его это ожидания нажатия на клавишу, код которой в ULBUF, пришедший в буфер из ф-ции прерывания?Код:CST: LD HL,(ULBUF) LD A,L CP H LD A,0 RET Z CPL RET CONIN: EI CONIN0: CALL CST JR Z,CONIN0 DI LD A,L INC A CP LENBUF-1 JR NZ,CONIN1 XOR A CONIN1: LD (ULBUF),A LD DE,BUFKLA LD H,0 ADD HL,DE LD A,(HL) EI RET
Последний раз редактировалось asve79; 25.12.2018 в 16:21.
Да, смысл данного кода - это ожидание нажатия на клавишу. В данном драйвере используется буфер клавиатуры, в который подпрограмма INTKEY, работающая по прерываниям, помещает коды клавиш по мере их нажатия. Если подпрограмма CONIN (ожидание нажатия на клавишу) долго не вызывалась - то в буфере может быть несколько кодов. Они будут по одному извлечены из буфера за несколько вызовов CONIN. Переменные ULBUF и USBUF - это не коды клавиш, а указатели в пределах буфера. Сам буфер расположен в области памяти BUFKLA.
Устройство буфера - типичный кольцевой буфер (Ring buffer, Circular Buffer). Имеется два указателя - один на запись, второй на считывание. Тот, который на запись, изменяется только по прерываниям. Тот указатель, который на считывание, изменяется только в подпрограмме CONIN.
Замечу, что эта функция составлена неэффективно. Вероятно, авторы драйвера (и я в 1996г) не понимали, что кольцевой буфер относится к структурам данных с возможностью неблокирующего доступа (Lock-free data structure). Если подпрограмма CONIN составлена грамотно - то неважно, в каком месте она может быть прервана прерыванием, её работа будет в любом случае корректной. Иными словами, можно таким образом изменить функцию CONIN, чтобы в ней не надо было запрещать прерывания. Это устранит вероятность пропуска прерывания и сделает работу системы более отзывчивой.
К тебе вопрос - ты можешь внести меня на Github в список разработчиков проекта, чтобы я мог вносить свои изменения? А то как раз появилось желание немного оптимизировать код.
Добавил в код ф-цию CONINW, которая не ждет нажатия на клавишу. а возвращает 0, если пусто.
В моем случае в это возможность опросить порт на предмет входящих данных.
Постепенно прихожу к мысли. что было бы здорово иметь возможность "переключаться" в область вывода другого окна, как будто текущее закрылось, а потом возвращаться в область координат текущего с текущим положением курсора. При этом перекрыванием окон можно пренебречь и оставить на совести пользователя. Но тут похоже не такая малая доделка нужна.
Такая функция имеет ограниченную область применения. А именно - во время длительной операции обработки данных или рисования смотреть, не нажата ли клавиша, которая должна прервать этот процесс. Во всех остальных случаях рекомендуется пользоваться блокирующей функцией CONIN. Это идеология многопоточных систем, в которых следует избегать циклов, где что-то опрашивается и процессор занят на 100%. Хотя в моей библиотеке многопоточности пока нет, но её можно прикрутить (см., например, мою тему в этом разделе "вытесняющая многозадачность").
Если перекрыванием пренебречь - то доделка будет умеренной. С перекрыванием - да, сложнее. Попробую покумекать на досуге. Мой план: сначала сделать Diff твоей репозитории на GitHub со своими исходниками, чтобы точно выяснить, что ты поменял; и тогда уже начну вносить свои изменения.
Почему ты, кстати, настаиваешь на отказе от кодировки CP866 в исходниках?
Да я не то, чтобы настаиваю. Я работаю под linux, система работает в UTF-8 и не надо ничего придумывать с IDE. Плюс если делать pull/merce реквесты в github-е, то изменения проще сравнивать когда кодировки UTF8, не уверен что там будет корректно отображаться другие кодировки. Но Это не проверял, поэтому высказываю лишь свои предположения.
Посмотрел что будет если кириллицу попробовать вывести - мда, выводит коряво, видимо ассемблер не переводит кодировку, что наверное и не удивительно. На этот счет не размышлял еще.
В целом, я только устранял несоответствие между синтаксисом zasm/sjasm. Т.е удалял CSEG/DSEG. Добавлял описание модулей в файлах модулей. Добавлял названия модулей в CALL-ах, ссылающихся на ф-ции в других модулях. Удалил упоминания EXTERN/PUBLIC, добавил Include.
В логический состав кода не лазал.
Эту тему просматривают: 1 (пользователей: 0 , гостей: 1)