Вот эмуляция мышки в клавиатуру мне не особо интересна. Фишка мыши в свободном и быстром перемещении в двумерном пространстве. Проблема в том, что векторовских программ, которые это уже могут практически нет, т.к. мышки не было. Minesweeper с мышкой, коммандер с мышкой, графический редактор - это было бы прикольно, хотя вряд ли кто-то будет делать или переделывать эти программы под мышь.Сообщение от KTSerg
С любовью к вам, Yandex.Direct
Размещение рекламы на форуме способствует его дальнейшему развитию
А в чём принципиальная разница при перемещении курсора мышью или кнопками, если результат совпадает?
Разница может быть только если "текстовый курсор" и "указатель мыши" не зависимы друг от друга, но это действительно должен софт поддерживать.
А если "курсор" один, то как он попадёт из "точки А" в "точку Б" (на экране), думаю не принципиально... или ошибаюсь?
При управлении курсором мы задаем только направление перемещения, а у мышки есть еще скорость перемещения по каждой координате, это принципиальное отличие.
Тут я не особо согласен. Скорость в данном случае понятие субъективное. И означает лишь количество простых перемещений за единицу времени (между прерываниями). Если правильно эмулировать, то можно при перемещении мыши выдавать серию нажатий. Вот и получится, чем быстрее мышь перемещаем, тем "чаще нажимаем" клавиши курсора.
Наверно я что-то не понимаю.
Случай 1. Типа обычного настольного ПК - нет мышки и мы ее эмулируем курсором. Можно ли? - да! Нужно ли - только в крайнем случае, когда мышка по каким-то причинам не доступна.
Случай 2. Вектор. Для простоты возьмем игрушку сапер. Можно ли там многократными нажатиями курсора переместить его в нужную клетку - да, можно. Удобнее было бы перемещать в данной игрушке курсор мышкой - на мой взгляд намного удобнее. Т.е. управление курсором в векторовских саперах - это очевидно вынужденная мера в связи с отсутствием мышки, это "эмуляция мыши с использованим курсора". Также удобнее было бы произвольно перемещать курсор в графическом редакторе, в файловом коммандере и в других подобных случаях.
Т.е. речь не о принципиальной невозможности заменить мышь курсором или в особо хитром случае наоборот, а о большем удобстве мышки там, где нужно произвольное перемещение курсора по сравнительно большой площади.
- - - Добавлено - - -
Понял, вот это ключевой элемент. Надо пробовать, если будет хорошо работать - замечательно. У клавиатуры принципиальное ограничение - не более одного нажатия в данном направлении за один опрос, если этого хватит, то все нормльно.
Вот я и говорил, что если речь о наличии одного "курсора", то перемещение мыши эмулируется клавишами курсора.
НО если речь идёт о разделении "текстового" и "графического" курсоров, тогда я полностью согласен, тут управление может быть только раздельным. Т.к. они влияют на принципиально разные "объекты" (курсоры), но в этом случае и софт должен быть принципиально переделан/адаптирован.
Добавил в первое сообщение архивы для ps/2-мыши подключенной к ПУ на шину клавиатуры. Там исходник и готовый rom.
- - - Добавлено - - -
Фсё фигня...
В ВекторЮзер, в статье про подключение ХТ-клавы, схема соответствует описанию...
Моя клава от ЕС1840 ведёт себя странно (относительно этого описания).
По логике описания сигнал на шине Данных должен быть инверсным от имеющегося.
Последний раз редактировалось KTSerg; 15.03.2019 в 22:08.
KTSerg, пробовать XT клавиатуру проще не с досом, который требует fdd, а с тестом ibmkbd.mac, который есть в ранее выложенном архиве, его можно запустить и в досе кваз-only. Компильнул его, надеюсь при адаптации под tasm ничего не поломал.
- - - Добавлено - - -
Можно даже без кваза запустить в мониторе-отладчике, но там кодировка не та.
Последний раз редактировалось ivagor; 16.03.2019 в 07:59. Причина: заменил на правильный вариант
ivagor, тест пока не запускал. Т.к. уверен, что работать не будет
Чем больше разбираюсь, тем больше запутываюсь...
Прихожу к выводу, что описанная в статье "ХТ-клава", моя "ЕС1840" и "IBM PC/XT" - это три совсем разные клавиатуры...
все они между собой имеют отличия. Некоторые не критичны и не помешают работе, некоторое отличия принципиальны.
Например:
1. Алгоритм из статьи читает/ждет 11 синхро-Бит. Первые 2 пропускает (как Старт-биты) 8 - данные, 1 - Стоп-Бит.
НО у ЕС и РС/ХТ в пакете только 10 синхро-Бит. 1 - Старт, 8 данные и 1 Стоп.
2. Алгоритм из статьи и ЕС считают, что чтение данных происходит по переднему фронту строба, а в описании РС/ХТ ясно видно, что по заднему фронту (спаду)...
3. у ЕС стоп-бит = "1", а из описания РС/ХТ следует, что стоп-бит должен быть "0".
4. В ЕС-клаве передача данных о нажатии/отпускании клавиш начинается с выставления "1" на шине данных, причём за 66мкс до первого синхроимпульса. А в описании РС/ХТ явно всё начинается с перевода синхры в "0".
5. эксперимент показал, что если у ЕС-клавы "зажать" в "0" шину данных, то она совсем не будет пытаться что-то передать или сообщать о том, что ей есть, что сказать, она не будет "дёргать" шиной синхры. А ведь именно этого ждёт от клавиатуры алгоритм из статьи.
Приложу скриншот логгера нажатия клавиши ЕС-клавы и найденное в нете (на этом форуме в архиве) описание протокола РС/ХТ-клавы.
Я читал (если очень нужно, попробую еще раз найти), что оригинальные XT-клавы давали 2 старт-бита, клоны - 1 старт бит.
Насчет полярности сигналов - если их оба инвертировать, то тогда получается нормально?
На мой взгляд принципиальных проблем тут нет, попробуй переделать IBMKBD, чтобы он правильно заработал с имеющейся клавиатурой. Там ведь переделка в основном касается только полярности (которую можно попробовать и аппаратно изменить), еще возможно придется уменьшить на 1 число принимаемых бит. По аналогии я потом постараюсь переделать mdos2xt.
Эту тему просматривают: 1 (пользователей: 0 , гостей: 1)
Ваши права
Ответить с цитированием
