Просмотр полной версии : Вектор06Ц, клава и мышь PS/2 через "ПУ"
Не знаю можно ли перенести в эту тему начало обсуждения ps/2 через ПУ из соседней ветки...
Набросал программку с протокольчиком ps/2 (на основе исходников из Ардуино).
Собрал переходник. Подключил его к "ПУ", воткнул в него USB-клаву.
Вот что получил на экране.
6840468405
Там в верху 7F, это ответ USB-клавы на инициализацию. А дальше по две строки нажатие и отпускание клавиш USB-клавы.
Нужно разбираться, некоторые клавиши при нажатии дают один код, некоторые два...
- - - Добавлено - - -
Схема переходника "ПУ" - PS/2 (USB)
С замашкой на одновременное подключение и клавы и мыши.
68406
Приклею первый вариант тестовой программки.
С ДОСом не дружит, работает сама по себе. Инитит PS/2 клаву и выдает на экран полученные от неё коды нажатия и отпускания клавиш (в set3).
В архиве исходник, и готовый rom. А также hex.fnt который нужно приклеить к коду, если пересобирать программу.
Добавлю архив с исходником для ps/2-мыши подключенной к ПУ на шину клавы.
Архив mous_ps - исходник и rom, просто гонять точку по экрану.
Архив mousе_ps - rom с отображением в hex того, что приняли от мыши (бонус к mous_ps).
Архив arkanoim - модифицированный Арканоид для тестирования PS/2 мыши, подключенной к разъёму "ПУ" (в разъём клавиатуры).
В нижнем левом углу выводится полученные с мыши данные (первые два байта), это для проверки функционирования "драйвера".
По поводу управления.
ЛКМ - дублирует "пробел".
ну и вправо/влево соответственно.
Перемещение мыши вверх/вниз - не обрабатывается.
ПКМ - делит скорость перемещения мыши на 2, каретка начинает двигаться со скоростью примерно как от клавиатуры.
СКМ - возвращает оригинальную скорость перемещения мыши, каретка начинает шустро бегать.
blackmirror
12.03.2019, 18:50
Нужно разбираться, некоторые клавиши при нажатии дают один код, некоторые два...
У клавиатур есть три набора кодов, в set1 и set2 клавиши дублирующие другие в целях совместимости присылали коды с префиксами, чтобы старый софт который ничего про них не знает работал с обеими клавишами. В set3 это безобразие пофиксили, в общем при желании можно переключить клавиатуру в set3 и не морочить себе голову.
https://www.win.tue.nl/~aeb/linux/kbd/scancodes-10.html
https://wiki.osdev.org/PS/2_Keyboard
Странно. Что-то я пока не соображу...
После инициализации, даю команду перейти на set3 (F0 03). Клава отвечает подтверждением FA. Но дальше при нажатии любой кнопки, кидает код АА и перезагружается, после чего снова выдает коды в set2.
blackmirror
12.03.2019, 20:10
0xAA Self test passed (sent after "0xFF (reset)" command or keyboard power up)
Очень походе что диода не хватило чтобы притянуть данные к 0, и F0 был воспринят как FF - Reset and start self-test
0xAA Self test passed (sent after "0xFF (reset)" command or keyboard power up)
Очень походе что диода не хватило чтобы притянуть данные к 0, и F0 был воспринят как FF - Reset and start self-test
Не, после команды F0 03 однозначно приходит FA. Код АА клава выплёвывает после перезапуска. А перезапуск происходит только после нажатия любой кнопки. Если ничего не нажимать, то после FA 03 стоит сколько угодно. И только при нажатии кнопки перезагружается. После перезапуска стабильно работает выплёвывая коды в set2.
Завтра попробую другую клаву.
Странно. Что-то я пока не соображу...
После инициализации, даю команду перейти на set3 (F0 03). Клава отвечает подтверждением FA. Но дальше при нажатии любой кнопки, кидает код АА и перезагружается, после чего снова выдает коды в set2.
Переход в режим Scan Code 3
ldi data,0xf0 ;Select Alt_Scan
rcall trans_ack ;передать
ldi data,0x03 ;Alt_Scan = 3
rcall trans_ack ;передать
;
ldi data,0xf8 ;Select All Make/Break
rcall trans_ack ;передать
Переход в режим Scan Code 3
...
Не помогло.
После нажатия любой кнопки, клава перезагружается с одновременным зажиганием всех светодиодов (как и раньше).
Кстати, команды точно проходят, т.к. задавал в цикле мигать светодиодами, мигают, перезагрузки не происходит, но как только нажимаю клавишу - перезагружается.
Буду искать другую клаву.
Попробовал две USB-мыши... :( они не переходят в режим ps/2.
По вышеупомянутой ссылке (https://www.win.tue.nl/~aeb/linux/kbd/scancodes-10.html) в разделе
10.5 Use
много написано про то, что set 1 и 3 могут быть не реализованы в некоторых клавиатурах, или реализованы с ошибками. А set 2 всегда есть и более-менее нормально работает. На форуме тоже можно найти сообщения, что у человека set 3 не поддерживается конкретной клавиатурой.
Смысл в использовании set 3 - упрощение и сокращение драйвера, но нужно ли это менять на совместимость? Если бы это было принципиально - например драйвер где-то не помещается, это одно дело, а без веских причин - зачем? Хотя, с другой стороны, проект не коммерческий и автору решать, как и что использовать.
По вышеупомянутой ссылке (https://www.win.tue.nl/~aeb/linux/kbd/scancodes-10.html) в разделе
10.5 Use
много написано про то, что set 1 и 3 могут быть не реализованы в некоторых клавиатурах, или реализованы с ошибками. А set 2 всегда есть и более-менее нормально работает. ...
Ага, в пункте vi судя по всему написано, что USB-клавы держат только set2.
Ну я уже успел на переходнике к USB запараллелить ps/2 разъём будет для экспериментов.
KTSerg, клавиатуру с поддержкой set 3 не предлагаю искать, а вот с поддержкой set 1 было бы интересно. Выцепил из архива В. Фиронова три файлика про XT-клаву Платонова. Там есть дос, который Платонов адаптировал под XT-клавиатуру. Идея такая - можно попробовать перед запуском mdos2xt переключиить клавиатуру в set 1, вдруг дос сможет после этого с ней работать. И тогда Improver окажется практически прав, что Платонов в свое время подключил PS2 клаву к вектору.
... Выцепил из архива В. Фиронова три файлика про XT-клаву Платонова. Там есть дос, который Платонов адаптировал под XT-клавиатуру. ... И тогда Improver окажется практически прав, что Платонов в свое время подключил PS2 клаву к вектору.
Протоколы ХТ и PS/2 не совместимы. У ps/2, после данных идёт бит чётности и стоп-бит, этого нет в ХТ.
Если ДОС и работает с ХТ клавой, то с клавой ps/2 работать не будет. Драйвер менять нужно.
Сейчас рылся в кладовке... откопал клаву от ЕС1840... её провод лежал сверху и проплавил кнопки... :(
Разберусь с протоколом ps/2, попробую клаву от ЕС подключить к Вектору и попробовать тот ДОС2ХТ.
Протоколы ХТ и PS/2 не совместимы. У ps/2, после данных идёт бит чётности и стоп-бит, этого нет в ХТ.
Если ДОС и работает с ХТ клавой, то с клавой ps/2 работать не будет. Драйвер менять нужно.
Да, тут я облажался. Меня сбило с толку, что начало у них одинаковое:
xt - старт-бит и 8 бит кода
ps2 - старт-бит, 8 бит кода, потом бит четности и стоп-бит.
Т.е. думал, что IBMKey прочитает содержательную часть, а остальное можно проигнорировать. А сейчас прочитал, что если комп установит признак неготовности раньше, чем клавиатура передаст полный пакет, то после готовности компа к приему снова будет передан тот же скан-код. Скорее всего если подключить PS2 и запустить dos2xt, то после нажатия одной клавиши будет ее бесконечный автоповтор.
- - - Добавлено - - -
А, это еще не все, у xt и состояния по другому индицируются и инициируются, похоже обмена ps2 клавиатуры с xt-драйвером совсем не получится.
Приволок с работы древнюю АТ-клаву (с DIN5). Через переходник подцепил к Вектору. Чудненько работает в режиме ps/2 и в set3 переключается без проблем. Только для неё понадобилась команда F8, про которую мне тут писал caro. Без этой команды клава не шлёт код отпускания кнопки, сообщает только о нажатиях.
Нашел старую USB-мышь, которая работает в режиме ps/2. По крайней мере она инициализируется и передаёт состояние кнопок. Но оптика на ней не работает, перемещения не протестировать. Но главное и такие USB-мыши есть/были.
Обычная ps/2 мышь работает.
Столько "веселья" на пустом месте...
PS/2 мышкой на Векторе по экрану гонять точку :) Чувствительность нормальная, от края до края экрана мышку перемещать по столу 3-4 см.
Рыба есть, можно даже быстренько простенький граф.редактор сварганить (ну там точку поставить/стереть, линию, квадрат)... :)
Improver
14.03.2019, 08:16
Нашел старую USB-мышь, которая работает в режиме ps/2. По крайней мере она инициализируется и передаёт состояние кнопок. Но оптика на ней не работает, перемещения не протестировать. Но главное и такие USB-мыши есть/были.Да, такие мыши были, у меня даже одна такая сохранилась... Важная примета того, что мышка умеет работать в двух режимах, это то, что к ней в комплекте был переходник USB->PS/2. А если переходник при продаже не прикладывался, то можно даже не пробовать, такие мышки работают только по USB.
PS/2 мышкой на Векторе по экрану гонять точку Чувствительность нормальная, от края до края экрана мышку перемещать по столу 3-4 см.
Непрерывный опрос (опросил, нарисовал и так по кругу) или по прерываниям?
Непрерывный опрос (опросил, нарисовал и так по кругу) или по прерываниям?
Опрос мыши в прерываниях. Мышь специально переключается в такой режим работы.
По умолчанию мышь без запроса гонит поток при любом перемещении или нажатии кнопок.
... Сейчас рылся в кладовке... откопал клаву от ЕС1840... попробую клаву от ЕС подключить к Вектору и попробовать тот ДОС2ХТ.
Похоже, что эта клава оказалась у меня по единственной причине... она не исправна... :(
"Признаки жизни" она подаёт, индикаторы "ЦИФ", "РУС" и "LAT" реагируют адекватно на нажатие соответствующих клавиш. Но в шину она гонит явно "мусор", причём только по одному сигналу, второй глухо молчит.
Соответственно попытка запустить Дос2ХТ ни чем не увенчалась.
Хотя причина, что Дос не запустился может быть и не в клаве. Т.к. Дос при запуске даже загрузочную сетку не стирает, зависает.
Хотя причина, что Дос не запустился может быть и не в клаве. Т.к. Дос при запуске даже загрузочную сетку не стирает, зависает.
Он ждет признаков жизни от XT-клавиатуры и будет ждать их до упора. Если его маленько обмануть (что XT клава присутствует и у них с досом взаимность), то он покажет такую картинку
68438
crackintosh
14.03.2019, 21:22
Существует куча адаптеров XT->AT
Да и клав XT/AT не проблема найти еще.
Еще вариант - все же найти PS2 клавиатуру с поддержкой set 1 и заменить в mdos2xt драйвер на PS2шный. Но PS2шный будет подлиннее, просто так не заменить, надо искать дополнительное место.
Он ждет признаков жизни от XT-клавиатуры и будет ждать их до упора. Если его маленько обмануть (что XT клава присутствует и у них с досом взаимность), то он покажет такую картинку
...
Этот ДОС к Дисководу привязан? Без контроллера Дисковода тоже зависнет?
- - - Добавлено - - -
Существует куча адаптеров XT->AT
Чёт в этом я не очень уверен... это ведь на уровне протокола. Там проводками не обойтись. Поток данных перехватывать нужно и конвертировать в обе стороны на ходу.
Да и клав XT/AT не проблема найти еще.
Вот это более реалистично.
Этот ДОС к Дисководу привязан? Без контроллера Дисковода тоже зависнет?
Он при старте ждет дискету в дисководе, вроде большинство векторовских дисководных досов так себя ведут.
Он при старте ждет дискету в дисководе, вроде большинство векторовских дисководных досов так себя ведут.
Ясно.
В первом сообщении добавил архив с исходником и готовым rom-ом тестовой программки ps/2-клавы.
Он ждет признаков жизни от XT-клавиатуры и будет ждать их до упора. Если его маленько обмануть ...
Ты разобрался, как обмануть ДОС?
Чего ДОС ждёт от клавы?
Примерно то, что описано в вектор-usere, основная процедура опроса точно как там.
... Но PS2шный будет подлиннее, просто так не заменить, надо искать дополнительное место.
Мало того, что приём Байта длиннее, так ещё и отправку в клаву нужно обязательно делать (а она ещё длиннее), т.к. с клавой на ps/2 иначе не договориться, её настраивать надо. По крайней мере индикаторами на клаве можно управлять только командами.
А ХТ-клава, судя по всему, в этом смысле "самодостаточна", ни каких настроек не требовала.
отправку в клаву нужно обязательно делать
Это как раз не проблема, настройку можно сделать один раз в самом начале, а потом пусть с этим куском кода будет что угодно, его можно и затереть. Т.е. инициализацию можно в дос не встраивать, а просто добавить в качестве стартующего перед досом фрагмента.
crackintosh
15.03.2019, 08:31
Вот пжалуста. Микра+3 резистора + диод и конденсатор.
http://www.vcfed.org/forum/showthread.php?26426-AT2XT-keyboard-converter&p=188311#post188311
Тут дело вкуса, но на мой взгляд, если использовать микроконтроллер, то уж лучше делать преобразование PS2->клавиатура вектора. И тогда приходим к проекту caro. Если не путаю, то его использовали с новодельным вектором-2014.
Вот нормальной мышки для вектора не было, эту тема для меня более интересна. И там все упирается в программную поддержку.
...
Вот нормальной мышки для вектора не было, эту тема для меня более интересна. И там все упирается в программную поддержку.
Тут снова приходим к вопросу о том, что хотим получить.
Наверное можно и проект PS2->клава Вектора доработать подключением к нему ps2-мыши и переводить её перемещения в нажатия клавиш курсора, а кнопки мыши в нажатие каких-то заданных или выбираемых кнопок Вектора.
Только скажу честно, я не разбирался в том как работает подобный эмулятор. Не понимаю как можно эмулировать все возможные варианты запросов состояния клавиатуры Вектора. Ведь программа может опрашивать не только по одному ряду, а сразу несколько рядов, и видя что что-то нажато, начать опрашивать каждый ряд отдельно, либо сразу поняв, что ничего не нажато - экономить время.
И вот как с этим может справиться эмулятор....
Наверное можно и проект PS2->клава Вектора доработать подключением к нему ps2-мыши и переводить её перемещения в нажатия клавиш курсора, а кнопки мыши в нажатие каких-то заданных или выбираемых кнопок Вектора.
Вот эмуляция мышки в клавиатуру мне не особо интересна. Фишка мыши в свободном и быстром перемещении в двумерном пространстве. Проблема в том, что векторовских программ, которые это уже могут практически нет, т.к. мышки не было. Minesweeper с мышкой, коммандер с мышкой, графический редактор - это было бы прикольно, хотя вряд ли кто-то будет делать или переделывать эти программы под мышь.
Вот эмуляция мышки в клавиатуру мне не особо интересна. Фишка мыши в свободном и быстром перемещении в двумерном пространстве. ...
А в чём принципиальная разница при перемещении курсора мышью или кнопками, если результат совпадает?
Разница может быть только если "текстовый курсор" и "указатель мыши" не зависимы друг от друга, но это действительно должен софт поддерживать.
А если "курсор" один, то как он попадёт из "точки А" в "точку Б" (на экране), думаю не принципиально... или ошибаюсь?
При управлении курсором мы задаем только направление перемещения, а у мышки есть еще скорость перемещения по каждой координате, это принципиальное отличие.
При управлении курсором мы задаем только направление перемещения, а у мышки есть еще скорость перемещения по каждой координате, это принципиальное отличие.
Тут я не особо согласен. Скорость в данном случае понятие субъективное. И означает лишь количество простых перемещений за единицу времени (между прерываниями). Если правильно эмулировать, то можно при перемещении мыши выдавать серию нажатий. Вот и получится, чем быстрее мышь перемещаем, тем "чаще нажимаем" клавиши курсора.
Наверно я что-то не понимаю.
Случай 1. Типа обычного настольного ПК - нет мышки и мы ее эмулируем курсором. Можно ли? - да! Нужно ли - только в крайнем случае, когда мышка по каким-то причинам не доступна.
Случай 2. Вектор. Для простоты возьмем игрушку сапер. Можно ли там многократными нажатиями курсора переместить его в нужную клетку - да, можно. Удобнее было бы перемещать в данной игрушке курсор мышкой - на мой взгляд намного удобнее. Т.е. управление курсором в векторовских саперах - это очевидно вынужденная мера в связи с отсутствием мышки, это "эмуляция мыши с использованим курсора". Также удобнее было бы произвольно перемещать курсор в графическом редакторе, в файловом коммандере и в других подобных случаях.
Т.е. речь не о принципиальной невозможности заменить мышь курсором или в особо хитром случае наоборот, а о большем удобстве мышки там, где нужно произвольное перемещение курсора по сравнительно большой площади.
- - - Добавлено - - -
Если правильно эмулировать, то можно при перемещении мыши выдавать серию нажатий.
Понял, вот это ключевой элемент. Надо пробовать, если будет хорошо работать - замечательно. У клавиатуры принципиальное ограничение - не более одного нажатия в данном направлении за один опрос, если этого хватит, то все нормльно.
...
Т.е. речь не о принципиальной невозможности заменить мышь курсором или в особо хитром случае наоборот, а о большем удобстве мышки там, где нужно произвольное перемещение курсора по сравнительно большой площади.
Вот я и говорил, что если речь о наличии одного "курсора", то перемещение мыши эмулируется клавишами курсора.
НО если речь идёт о разделении "текстового" и "графического" курсоров, тогда я полностью согласен, тут управление может быть только раздельным. Т.к. они влияют на принципиально разные "объекты" (курсоры), но в этом случае и софт должен быть принципиально переделан/адаптирован.
Добавил в первое сообщение архивы для ps/2-мыши подключенной к ПУ на шину клавиатуры. Там исходник и готовый rom.
- - - Добавлено - - -
Фсё фигня...
В ВекторЮзер, в статье про подключение ХТ-клавы, схема соответствует описанию...
Моя клава от ЕС1840 ведёт себя странно (относительно этого описания).
По логике описания сигнал на шине Данных должен быть инверсным от имеющегося.
KTSerg, пробовать XT клавиатуру проще не с досом, который требует fdd, а с тестом ibmkbd.mac, который есть в ранее выложенном архиве, его можно запустить и в досе кваз-only. Компильнул его, надеюсь при адаптации под tasm ничего не поломал.
- - - Добавлено - - -
Можно даже без кваза запустить в мониторе-отладчике, но там кодировка не та.
ivagor, тест пока не запускал. Т.к. уверен, что работать не будет :(
Чем больше разбираюсь, тем больше запутываюсь...
Прихожу к выводу, что описанная в статье "ХТ-клава", моя "ЕС1840" и "IBM PC/XT" - это три совсем разные клавиатуры...
все они между собой имеют отличия. Некоторые не критичны и не помешают работе, некоторое отличия принципиальны.
Например:
1. Алгоритм из статьи читает/ждет 11 синхро-Бит. Первые 2 пропускает (как Старт-биты) 8 - данные, 1 - Стоп-Бит.
НО у ЕС и РС/ХТ в пакете только 10 синхро-Бит. 1 - Старт, 8 данные и 1 Стоп.
2. Алгоритм из статьи и ЕС считают, что чтение данных происходит по переднему фронту строба, а в описании РС/ХТ ясно видно, что по заднему фронту (спаду)...
3. у ЕС стоп-бит = "1", а из описания РС/ХТ следует, что стоп-бит должен быть "0".
4. В ЕС-клаве передача данных о нажатии/отпускании клавиш начинается с выставления "1" на шине данных, причём за 66мкс до первого синхроимпульса. А в описании РС/ХТ явно всё начинается с перевода синхры в "0".
5. эксперимент показал, что если у ЕС-клавы "зажать" в "0" шину данных, то она совсем не будет пытаться что-то передать или сообщать о том, что ей есть, что сказать, она не будет "дёргать" шиной синхры. А ведь именно этого ждёт от клавиатуры алгоритм из статьи.
Приложу скриншот логгера нажатия клавиши ЕС-клавы и найденное в нете (на этом форуме в архиве) описание протокола РС/ХТ-клавы.
68466
68467
1. Алгоритм из статьи читает/ждет 11 синхро-Бит. Первые 2 пропускает (как Старт-биты) 8 - данные, 1 - Стоп-Бит.
НО у ЕС и РС/ХТ в пакете только 10 синхро-Бит. 1 - Старт, 8 данные и 1 Стоп.
Я читал (если очень нужно, попробую еще раз найти), что оригинальные XT-клавы давали 2 старт-бита, клоны - 1 старт бит.
Насчет полярности сигналов - если их оба инвертировать, то тогда получается нормально?
На мой взгляд принципиальных проблем тут нет, попробуй переделать IBMKBD, чтобы он правильно заработал с имеющейся клавиатурой. Там ведь переделка в основном касается только полярности (которую можно попробовать и аппаратно изменить), еще возможно придется уменьшить на 1 число принимаемых бит. По аналогии я потом постараюсь переделать mdos2xt.
Я читал (если очень нужно, попробую еще раз найти), что оригинальные XT-клавы давали 2 старт-бита, клоны - 1 старт бит.
Насчет полярности сигналов - если их оба инвертировать, то тогда получается нормально?
На мой взгляд принципиальных проблем тут нет, попробуй переделать IBMKBD, чтобы он правильно заработал с имеющейся клавиатурой. Там ведь переделка в основном касается только полярности (которую можно попробовать и аппаратно изменить), еще возможно придется уменьшить на 1 число принимаемых бит. По аналогии я потом постараюсь переделать mdos2xt.
На счет 2-ух старт-бит написано в википедии, но там написано, что после 8ми бит данных идет ещё и отдельный бит указывающий нажата клавиша или отпущена.
На полярность стоп-бита можно вообще не обращать внимания, т.к. он просто игнорируется.
Сейчас разбирался в исходнике теста хт-клавы. Попробую уменьшить кол-во принимаемых старт-бит и изменить принцип проверки готовности клавы передать данные. А дальше будет видно.
Хотя было-бы интересно найти настоящую ХТ-клаву и посмотреть логером её протокол.
Т.к. в 90-ых ходили разговоры, что при создании семейства ЕС (или это речь была про "Поиск") были внесены какие-то не значительные изменения, которые вроде как в основном не влияли на работу компа и фирменного софта, но позволили для производства не покупать лицензию. Но тем ни менее в очень редких случаях эти внесённые изменения вылазили боком и некоторый софт отказывался работать...
Попробую уменьшить кол-во стоп-бит и изменить принцип проверки готовности клавы передать данные.
Лучше сначала попробовать изменить принцип, а потом уменьшить количество (наверно все же стартовых, не стоповых) бит.
Забрасываю свою ЕС-клаву обратно туда, где она была...
Столько времени (правда много чего узнал)... и нет что-бы сразу на характеристики протокола посмотреть... частота следования синхроимпульсов 26КГц и длительность импульса всего 5мкс... у Вектора цикл:
in 05 ; читать порт
ana c ; выделить бит синхры
jnz ... ; повтор
уже составляет 9,3мкс, т.е. теоретически даже синхроимпульс может не заметить... и с этим ничего не поделать. Сейчас проц работает на частоте 5МГц, осталось попробовать поставить 2МГц, чтобы тормознуть...
Возвращаюсь к ps/2-клаве...
Из принципа, перекинул в схеме один проводок, это позволило оптимизировать алгоритм чтения. Получил возможность принять байт (в основном цикле) с частотой следования бит около 41.7КГц. Но это не помогает поймать строб (синхронизироваться).
Если немного развернуть алгоритм и учесть возможность потери строба, то иногда даже начинает правильно читать коды клавы, но очень не устойчиво. При таком коротком стробе надежного чтения наверное не добиться.
Одновибратор (ждущий мультивибратор) не поможет?
Одновибратор (ждущий мультивибратор) не поможет?
Тоже об этом думал. Удлинить синхроимпульс до 10мкс уже станет легче.
Выяснилось, что при нажатии разных клавиш, меняется и период следования синхроимпульсов, в диапазоне от 38мкс до 48мкс (между соседними).
Лень было паять одновибратор, и получить потом протокол который Вектор теоретически сможет прочитать, но при этом НЕ сможет понять, т.к. количество передаваемых бит всё равно не совпадает, а значит мДОС2хт тоже нужно будет перепиливать.
На макетке сварганил конвертор протоколов, благо за это время изучил и векторовский ХТ, и ЕС-ХТ.
И эта "шняга" заработала!
68475
Дополнительно получил несколько приятных плюшек.
Первое, оказалось, что некоторые клавиши не совпадают по назначению. Решение - перед отправкой кода в Вектор, меняем его на нужный. Кстати это багофича ЕС-клавы, т.к. это её коды не соответствуют таблице set1.
Потом, имею логи нажатий в отладочный СОМ-порт и соответственно по СОМ-порту можно "якобы нажимать" клавиши, отправляя нужные коды с РС.
И есть возможность сюда-же воткнуть ps/2 клаву и конвертировать её set2 в нужный Вектору set1, да ещё и без переделки ДОСа.
Мозги "размял", удовольствие получил...
KTSerg, поздравляю!
Пасиба.
Ещё понять бы, какой диск "С" нужен этому мДос2хт?
На мой обычный КвазиДиск он ругается, при переходе на диск С, пишет, что на диске ошибки. Наверное ему доработка "Баркаря" требуется, или ещё какой вариант.
Думаю, что кваз скорее всего нужен обычный, но стартовать первый раз нужно с его форматированием. И тут вопрос, что в этом досе нужно жать при старте (вряд ли УС на векторовской клавиатуре, хотя можно попробовать), чтобы форматнулся квазидиск.
Думаю, что кваз скорее всего нужен обычный, но стартовать первый раз нужно с его форматированием. И тут вопрос, что в этом досе нужно жать при старте (вряд ли УС на векторовской клавиатуре, хотя можно попробовать), чтобы форматнулся квазидиск.
Точно. Векторовская клава ведь не опрашивается, а я УС жму по привычке. Скорее всего нужно жать что-то соответствующее ему на ХТ-клаве. Ввод я нажимал, точно не форматирует.
Это странно, но в mdos2xt форматирование кваза все же по нажатию УС на клавиатуре вектора при старте.
Это странно, но в mdos2xt форматирование кваза все же по нажатию УС на клавиатуре вектора при старте.
Ты это в коде Доса посмотрел?
Я вчера вечером в отладчике глянул, ДОС после старта (начал смотреть не с самого начала) висит в цикле чтения ХТ-клавы. Смоделировал нажатие и отпускание клавиши "L.Ctrl" (с кодом 1Dh), программа сразу перешла к активной работе с Квазидиском. Правда я не стал выяснять, что он (ДОС) делает.
Ты это в коде Доса посмотрел?
Да. Сначала он опрашивает xt-клавиатуру, если ее нет так и будет висеть, а если она есть и ответила, то идет дальше, проверяет УС и, если он нажат, форматирует кваз. Думаю при старте этого доса нужно подольше держать УС.
Точно. Для форматирования КвазиДиска нужно удерживать нажатой "УС" на клавиатуре Вектора. Но держать её достаточно в момент нажатия (точнее отпускания) любой клавиши на ХТ-клавиатуре, когда ДОС уже стартонул и завис в ожидании реакции от ХТ-клавы (при этом на экране остается загрузочная сетка, но уже в режиме 512х256 точек).
crackintosh
20.03.2019, 00:02
все уже изобрели в 90-ых.... просто поискать надо!
вот тут вся периферия вектора http://www.vector06c.fdd5-25.net/photo.html
из них часть утеряна. Но большинство найдено!
Там-же есть Контроллер ХТ/АТ клавиатуры
все уже изобрели в 90-ых.... просто поискать надо!
вот тут вся периферия вектора http://www.vector06c.fdd5-25.net/photo.html
из них часть утеряна. Но большинство найдено!
Там-же есть Контроллер ХТ/АТ клавиатуры
Я не нашел возможности увеличить фото. К представленной там периферии есть схемы и драйвера или софт?
Я был-бы очень рад, если где-то была-бы собрана инфа про ВСЯ периферия для Вектора.
Но там не увидел фото модема (первой версии) фото которого я выкладывал. Нет фото контроллера ЛВС. Нет фото "заводского" варианта КвазиДиска+Контроллер НГМД на одной плате, он устанавливался в общий корпус с дисководом (огромный такой лапоть).
Думаю много чего ещё не хватает в архиве по ссылке... :(
crackintosh
20.03.2019, 12:59
Поиск медленно, но продвигается. Не все архивы Фиронова разобраны.
Увы, на том сайте картинки только мелкие.
Заводской квазидиск есть в нашем музее. Могу попросить сфотать его.
Я вобще собирался его реплику сделать т.к. есть вся инфа на него.
Контроллер АТ-клавиатуры делался в Кирове. Меринов Сергей ( FMSSOFT ) 610031, Киров, а/я 2729
Там надо копать.
источник: http://sensi.org/scalar/media/w/vector-byte-1-33-151108.pdf
P.S. для размышлений https://zx-pk.ru/threads/9294-orion-128-kontroller-ps-2-klaviatury.html
Контроллер АТ-клавиатуры делался в Кирове. Меринов Сергей ( FMSSOFT ) 610031, Киров, а/я 2729
Не стоит торопиться с "атрибуцией". Меринов Сергей - автор единственной статьи того номера, он точно не автор всех тех железок, которые перечислены под надписью "Имеется в продаже:". Т.е. в номере были: реквизиты выпускающего (Шустов А.М.), статья Меринова С. про пзу и список имеющихся в продаже у автора выпуска (Шустова) железок. Если говорить про автора кировского контроллера писишной клавиатуры, то это Саттаров, в Ветор-user есть упоминание, хотя или с ошибкой или речь про предварительрную версию контроллера (написано XT вместо AT). У меня была кировская реклама, там писали про контроллер AT-клавиатуры Саттарова.
Надо же, впервые вижу РУ5В в векторовском квазидиске.
А что там кроме РУ5 могло стоять?
До сих пор видел только РУ5Г
crackintosh
20.03.2019, 18:05
Кстати, это сообщение читали?
http://www.phantom.sannata.ru/forum/index.php?t=2385&p=29004#pp29004
Кстати, это сообщение читали?
http://www.phantom.sannata.ru/forum/index.php?t=2385&p=29004#pp29004
Мне кажется это "стандартная" статья аналогичная Векто-Юзер про подключение ХТ-клавы.
Подозреваю, что контроллер который делали для подключения АТ-клавы, был на i8048. И выполнял роль конвертора протоколов. Фото длинной платы контроллера рассмотреть нет возможности, но сомневаюсь, что контроллер клавы можно было сделать просто на логике. Не, сделать можно, но Вектор читая инфу только в стандартном прерывании, постоянно будет что-то терять. На логике можно делать если есть дополнительное аппаратное прерывание, которое заставит прочитать подготовленные данные, которые в любой момент могут быть затёрты новыми.
crackintosh
20.03.2019, 18:25
перекинул КД в Вектор железо
Если я правильно понимаю, это вариант примерно как в вектор-user и он меня не устраивает. Нужен "интеллектуальный" контроллер.
Что подразумевается под понятем ""интеллектуальный" контроллер" ?
Имеется в виду, что в предложенном варианте необходимо общаться с мышью по последовательному интерфейсу, а хочется свалить это на контроллер, и считывать с него уже готовые, принятые и обработанные данные, не расходуя на это процессорное время?
Но данный вариант предложен с прицелом на повторяемость. Спаять несколько резисторов и диодов значительно проще чем контроллер собирать.
Естественно можно собрать контроллер на чем-то вроде Ардуино или добавить его в ПЛИС, если такой уже висит на "ВУ", но мне кажется "повторяемость" (желание собирать такое) от этого снизится.
Скажу честно, я уже не помню, что там предлагалось в вектор-user.
Но смутные воспоминания говорят о том, что получаемые с мыши данные были аналогичны данным от Джойстика, т.е. просо биты направления перемещения.
Но при использовании мыши ps/2 от неё получаем данные о расстоянии пройденном мышью с момента последнего опроса.
Признаю, некорректно сравнивать опрос доисторической "простой" мыши в вектор-user и опрос мыши PS/2.
PS/2 в принципе нормальный вариант, но при таком "ручном" последовательном обмене слишком большие накладные расходы. Прикидка по mous_ps.rom показывает, что опрос занимает в районе 9% времени прерывания.
- - - Добавлено - - -
Там можно оптимизировать, но вряд ли даже в 2 раза.
Итак, остаётся открытым вопрос о "интеллектуальном" контроллере, который сводит работу с мышью к простому чтению двух или трёх портов?
Слепить такой сейчас думаю проблем нет.
Но как я уже говорил, не представляю, модно-ли "подключить" подобный контроллер к эмуляторам?
ЛВС-контроллер хоть и подключался, но эмулировался не совсем корректно, из-за отсутствия контроля над потоком данных. Хотя более вероятно, что проблема в криво написанном моём внешнем софте, так как я не смог полностью разобраться, как с эмулятором общаться.
Но как я уже говорил, не представляю, модно-ли "подключить" подобный контроллер к эмуляторам?
Эмуляторы мыша уж как-нибудь изобразить смогут, было бы что изображать.
Осмысленный контроллер должен иметь два порта на которых будет постоянно обновляющаяся дельта перемещения +-127. Наверное прекрасно хватило бы и одного порта, допустим старший бит признак X/Y, а младшие 7 +- 63 дельта.
Но +-63 это конечно недальновидно, потому что ivagor спортирует Quake и людигеймеры будут жаловаться, что время реакции не то.
Итак, остаётся открытым вопрос о "интеллектуальном" контроллере, который сводит работу с мышью к простому чтению двух или трёх портов?
В идеале - да. Но все зависит от задач, например для редактора шрифтов текущий вариант вполне нормальный, там ограничивающим фактором является скорость человека. А вот для требовательных игрушек типа warcraft или wolf 1/10 времени на опрос мыши - непозволительная роскошь. Другое дело, что таких игрушек для вектора не будет, а редактор шрифтов - вот он, осталось добавить туда мышь.
Эмуляторы мыша уж как-нибудь изобразить смогут, было бы что изображать.
Осмысленный контроллер должен иметь два порта на которых будет постоянно обновляющаяся дельта перемещения +-127. Наверное прекрасно хватило бы и одного порта, допустим старший бит признак X/Y, а младшие 7 +- 63 дельта.
Потому и говорил, что скорее всего понадобится ТРИ порта, так как если перемещения засунуть в один байт, то разрядность перемещения получится слишком маленькая, а ведь нужно ещё состояние кнопок получать.
В идеале - да. Но все зависит от задач, например для редактора шрифтов текущий вариант вполне нормальный, там ограничивающим фактором является скорость человека. А вот для требовательных игрушек типа warcraft или wolf 1/10 времени на опрос мыши - непозволительная роскошь. Другое дело, что таких игрушек для вектора не будет, а редактор шрифтов - вот он, осталось добавить туда мышь.
Ну, с реал-тайм активными игрушками, как ни жаль, на Векторе будет тяжеловато, из-за известных причин...
А вот что-то типа пошаговых стратегий, где персу нужно указать, куда пойти, что взять, и т.п. ... даже без контроллера, подключенной к "ПУ" мыши вполне достаточно, и игровой процесс будет "приятнее", я так думаю...
скорее всего понадобится ТРИ порта
Если минимизировать число портов для чтения, то достаточно двух - в одном выбор номера (в него запись) в другом - данные выбранного номера (отсюда читаем).
+- 64 точки, то есть четверть экрана, за 1/50 секунды это совсем не маленькая разрядность по-моему. Буду рад увидеть софт, который демонстрирует недостаточность такой разрядности. Но кнопки конечно да, без кнопок никак.
Если минимизировать число портов для чтения, то достаточно двух - в одном выбор номера (в него запись) в другом - данные выбранного номера (отсюда читаем).
Ну, в таком случае и одного порта достаточно.
На запись - выбор данных.
Чтение - данные с мыши.
Но если нужна оптимизация и скорость, зачем тратить ресурсы на запись в порт, если можно просто читать из заранее определённых портов.
- - - Добавлено - - -
+- 64 точки, то есть четверть экрана, за 1/50 секунды это совсем не маленькая разрядность по-моему. Буду рад увидеть софт, который демонстрирует недостаточность такой разрядности. Но кнопки конечно да, без кнопок никак.
Често говоря, за 4 года, я уже забыл, сколько разрядов данных мыши я использовал в тестовой программе, которая гоняет графический курсор по экрану.
допустим старший бит признак X/Y, а младшие 7 +- 63 дельта.
Достаточно одного порта на чтение: старший бит признак начала пакета, в пакете три байта dX, dY, кнопки. Вроде COM-портовая мышь так и делала. Сейчас такую уже фиг найдёшь наверное.
Достаточно одного порта на чтение: старший бит признак начала пакета, в пакете три байта dX, dY, кнопки. Вроде COM-портовая мышь так и делала. Сейчас такую уже фиг найдёшь наверное.
На сколько я понял, речь шла не о реальном протоколе ps/2 мыши, а о том, как данные для Вектора должен предоставить воображаемый контроллер.
Глянул исходник, там в протоколе ps/2-мыши, при запросе данных, в ответ приходит три байта:
в первом - кнопки и флаги направления смещения
второй - смещение по Х, видимо все 8 бит используются, т.е. максимум +-255 позиций.
Третий - смещение по Y, так-же +-255 позиций.
В тестовой программе, я не увидел, что резал разрядность, к предыдущей позиции просто прибавлял полученные данные.
Хотя, может и глаз замылился.
Improver
09.08.2023, 20:33
Если делать аппаратный суперконтроллер для мыши на трёх портах, то логичнее передавать не смещение, а сразу координаты курсора -- по вертикали как раз хватит 0-256 в восьми битах, а по горизонтали можно один бит (младший) передавать вместе с кнопками в третьем порту, чтобы можно было получить 0-512. Я так думаю...
Разности - это более общий вариант, а координаты все же частный случай когда управляем курсором на экране. Проблема в том, что обработка абсолютных координат с насыщением по краям экрана. А если вдруг мы поворачиваемся в wolf3d, то никаких насыщений нет, поворачиваемся пока не укачает.
UncleDim
09.08.2023, 22:09
Разности - это более общий вариант
(имхо) идеально будет, если они будут накапливаться в случае невозможности считывания (чем-то же надо занять суперконтроллер).
Потому и говорил, что скорее всего понадобится ТРИ порта, так как если перемещения засунуть в один байт, то разрядность перемещения получится слишком маленькая, а ведь нужно ещё состояние кнопок получать.
Наверное можно из регистра "состояния кнопок" сделать статус регистр c 2 зарезервированными битами: изменение по x > x_threshold, изменение по y > y_threshold. Ну и добавить control register сквозной, в котором 1 bit под координату и 7 под threshold. 2 записи в control reg для установки thresholds по x и по y
Тогда если мышь не движется или threshold не достигнут, достаточно поллить один регистр "умного контроллера". Mouse clicks будут свежие каждые 20ms, а набежавшие cмещения надо читать только по появлению бита в статус регистре. Чтение должно ессно гасить соответствующий бит.
Можно вообще грубую схему сделать, где под координату 2 бита в статус регистре: один из них бит знака, другой - признак превышения порога смещения. Но это уже дискретный джойстик с фильтром получается.
Вообще, плясять наверное стоит от софта. Хотелось бы хоть на эмуле поглядеть как это будет с софтиной сопрягаться. Там свои некоторые хитрости (если мы про окна и редактор фонтов). Ничего принципиально нерешаемого нет, но придется делать несколько обработчиков маус кликов:
- в menuitem data для получения соответствующего кода акселератора
- в клик над видимой областью окна (для кнопок и overlapped окон)
Но это детали
Пара IMHO
1. Голосую за минимальную дополнительную обработку в контроллере. У текущего варианта, который сделал KTSerg один недостаток - слишком медленный опрос и если контроллер возьмет на себя только преобразование из последовательного вида в параллельный, то этого как мне кажется будет достаточно. Плюсы: упрощение ПО контроллера и его отладки, максимальная совместимость.
2. Все же я бы сделал порт номера и порт данных вместо нескольких фиксированных портов данных. Тут не только бережное использование адресного пространства ввода-вывода (которое у 8080 не такое уж большое) но и потенциальная совместимость с разными форматами. Мне вот представляются интересными не только координаты и основные кнопки, но и колесо.
Improver
10.08.2023, 06:36
Разности - это более общий вариант, а координаты все же частный случай когда управляем курсором на экране.В случае Вектора wolf3d, скорее, частный случай, чем управление курсором. :) А так, получая сразу координату на экране можно избавить Вектор от дополнительных вычислений. И, если уж так хочется, можно сделать переключение режимов суперконтроллера, чтобы он выдавал координаты или смещение, или даже ещё и третий вариант -- "режим джойстика".
- - - Добавлено - - -
Пара IMHO
1. Голосую за минимальную дополнительную обработку в контроллере.А моё имхо -- чем больше будет делать контроллер, тем меньше потребуется ресурсов Вектора, и тем быстрее будут работать программы и игры, и тем проще будет их делать, т.е. я голосую за максимальную обработку.
Мне вот представляются интересными не только координаты и основные кнопки, но и колесо.Кстати, да -- колесо тоже можно как-то применить.
Понятно, что в зависимости от конкретного случая, хочется получить от мыши что-то своё.
Если говорить о реализации на контроллере, от в реализации любых "хотелок" думаю проблем вообще ни каких нет.
Можно немного подитожить.
Если предположить, что для некоторых задач достаточно мыши подключенной к "ПУ" с реализацией протокола обмена программным способом,
а для других "гипотетических" желательно иметь контроллер, который возьмёт на себя преобразование последовательных данных в параллельные и предоставление их в удобном виде, то собственно, имеем ситуацию как с большинством железа на Векторе...
Есть реализация и на "ПУ" и на "ВУ" (или ещё где-то).
Мне кажется, что для предварительного тестирования, имеющейся схемы подключения к "ПУ" и исходника, вполне достаточно.
Что касается реализации на контроллере...
Если для начала остановиться на варианте использования одного адреса порта, то даже с этим вариантом можно реализовать огромное количество "хотелок".
Это конечно медленнее, чем три отдельных порта, но намного гибче. Ведь количество читаемых регистров может быть 256...
Три первых "сырые данные": кнопки+флаги, X, Y.
А в "регистрах" остальных можно реализовать любые хотелки... хоть совместимость с джойстиком, хоть меньше разрядность смещения, хоть больше разрядность... и т.д. и т.п.
- - - Добавлено - - -
Глянул еще раз протокол ps/2-мыши...
При наличии колеса прокрутки, есть режим получать 4 байта данных, последний байт - смещение колеса.
При наличии у мыши 5-ти кнопок, есть режим получать от неё 5 байт данных, соответственно состояние этих дополнительных кнопок в 5-ом байте данных.
http://www.programmersclub.ru/%D0%98%D1%81%D1%81%D0%BB%D0%B5%D0%B4%D0%BE%D0%B2%D 0%B0%D0%BD%D0%B8%D0%B5-%D0%BF%D1%80%D0%BE%D1%82%D0%BE%D0%BA%D0%BE%D0%BB%D 0%B0-ps2-%D0%B4%D0%BB%D1%8F-%D0%BC%D1%8B%D1%88%D0%BA%D0%B8/
- - - Добавлено - - -
Вот только подозреваю, что просто так, мышь подключенную к "ПУ" не реализовать в эмуляторах...
Или ошибаюсь?
Кроме мыши к гипотетическому микроконтроллеру можно подключить и клавиатуру (хотя бы для досов) и получить с него еще какие-нибудь плюшки. Например любой современный микроконтроллер умеет умножать (да и делить) намного быстрее 8080. Но это все баловство, я бы отложил микроконтроллерный вариант до появления реальной потребности в нем и подождал реализации в эмуляторе(ах) хотя бы текущего варианта.
Кроме мыши к гипотетическому микроконтроллеру можно подключить и клавиатуру (хотя бы для досов) и получить с него еще какие-нибудь плюшки. Например любой современный микроконтроллер умеет умножать (да и делить) намного быстрее 8080. Но это все баловство, я бы отложил микроконтроллерный вариант до появления реальной потребности в нем и подождал реализации в эмуляторе(ах) хотя бы текущего варианта.
По-моему это хорошая идея, она не не идет в разрез (в том числе в буквальном смысле) с основной схемой Вектора и позволит добавить интересные функции. По сути это "мультикарта": последовательный порт с фифо (лучше два), миди, внешняя клавиатура, мышка, джойстики. Математику круто было бы тоже, причем я бы не ограничивался отдельностоящими делениями и умножениями.
Для реализации в эмуляторах надо описание поточнее.
Что до откладывания на потом, ничего точно не появится, пока не будет устройства. Для Вектора и так пишут 1.5 человека. Откуда тут взяться четко обозначенной потребности? Лучше сделать устройство и ждать, пока у кого-то руки не начнут чесаться под него чего-нибудь написать.
Чисто теоретически в мультикарте можно реализовать очень крутые вещи, например (если на плис) математический сопроцессор с отображением на память для быстрого обмена. Но реализация крутых вещей сначала в железе, потом (желательно адекватно) в эмуляторе требует больших затрат сил и времени.
Возвращаясь в реальность - добавишь в v06x мышь KTSerga? Он и в железе реализовал и программу (с исходником) выложил.
BlaireCas
10.08.2023, 14:20
Для Вектора и так пишут 1.5 человека. Откуда тут взяться четко обозначенной потребности?
Для УКНЦ тоже самое, "полтора землекопа" :) Но мышку подключили. Зачетно ездит. Хватило 7-бит смещений со знаком (+-64) и двух кнопок. Тут главное начать, а вдруг кто напишет duck hunt для мыши :)
Чисто теоретически в мультикарте можно реализовать очень крутые вещи, например (если на плис) математический сопроцессор с отображением на память для быстрого обмена. Но реализация крутых вещей сначала в железе, потом (желательно адекватно) в эмуляторе требует больших затрат сил и времени.
Возвращаясь в реальность - добавишь в v06x мышь KTSerga? Он и в железе реализовал и программу (с исходником) выложил.
Не обещаю скоро, но поставил в очередь.
ПЛИС тут по-моему не нужно. Это сложно и заморочно, ухудшает повторябельность проекта. Где можно без нее обойтись, лучше сделать помедленней, но попроще. Pi Pico, например, все это сможет. Она сможет даже быть USB-хостом для клавиатуры и мышки.
...
лучше сделать помедленней, но попроще. Pi Pico, например, все это сможет. Она сможет даже быть USB-хостом для клавиатуры и мышки.
И куда её подключать?
На "ПУ", и воспринимать её как ПЗУ (например). Типа порт "С" на выход для указания номера читаемого регистра, а порт "А" на вход данных полученных от мыши?
Для навеса такой штуки на "ВУ" мне кажется разрядов портов на ней маловато для ШД, ШАВВ и сигналов управления.
Хотя, вроде разглядел ещё порты, похоже на ней и для подключения к "ВУ" разрядов хватит.
А вот если давать пользователю возможность самостоятельно программировать параметры мыши, одним адресом ввода/вывода не обойтись, наверное. Понадобится ещё один адрес для настроек.
И куда её подключать?
На "ПУ", и воспринимать её как ПЗУ (например). Типа порт "С" на выход для указания номера читаемого регистра, а порт "А" на вход данных полученных от мыши?
Для навеса такой штуки на "ВУ" мне кажется разрядов портов на ней маловато для ШД, ШАВВ и сигналов управления.
Только на ПУ, конечно. ВУ ни разрядов не хватит, ни быстродействия для опроса. А для ПУ должно хватить: всего на пипико выведено 26 gpio. Если сделать как ты сказал, один порт адрес регистра, второй данные, + строб и r/w. Получается 18 пинов, если задействовать все адреса (пусть будет много адресов для разных воображаемых хитрых устройств типа векторного процессора). Осталось еще 8 пинов. 2 на USB хост (через хаб мыш и клавиатура), 4 на два последовательных порта, остается 2 в запасе: через i2c экспандер сделать джойстики и cts/rts/dsr/dtr для компортов. В общем помещается, но в деталях я не уверен.
Пятивольтовость придется адаптировать к сожалению.
Только на ПУ, конечно. ВУ ни разрядов не хватит, ни быстродействия для опроса. А для ПУ должно хватить: всего на пипико выведено 26 gpio. Если сделать как ты сказал, один порт адрес регистра, второй данные, + строб и r/w. Получается 18 пинов, ...
Если пользователю не давать доступа к настройкам мыши, то одного порта "ПУ" для чтения с мыши вполне достаточно. А вот если захочется её программировать вручную, то нужен ещё порт на выход, что-бы не приходилось ещё и направление портов "ПУ" менять постоянно.
У простого варианта кстати есть потенциальный плюс - проще добавить в v06cc на девбордах с мышью.
Если пользователю не давать доступа к настройкам мыши, то одного порта "ПУ" для чтения с мыши вполне достаточно. А вот если захочется её программировать вручную, то нужен ещё порт на выход, что-бы не приходилось ещё и направление портов "ПУ" менять постоянно.
Для мыши может быть это не критично, а для всяких других устройств двунаправленность данных обязательна. Но начинать можно с малого, шадки не сразу строились.
Для мыши может быть это не критично, а для всяких других устройств двунаправленность данных обязательна. Но начинать можно с малого, шадки не сразу строились.
Двунаправленность шины это чаще всего удобно, но у ВВ55 для смены направления РУС нужно переписывать, данные в портах сбрасываются... хлопотно за этим всем следить. Проще выделить отдельные порты на вход и на выход, пользоваться ими и нещёлкать направлениями постоянно. Да, больше расход пинов/портов/разрядов, но код программы проще, отслеживать направление данных не нужно.
Но это моё личное мнение хронического лентяя...
Один раз достаточно написать процедуры для ввода и вывода и следить больше не нужно.
Но по-моему 8255 уже дает все, что нужно как раз примерно для такого обмена: порт А в режиме 2 (двунаправленные данные), порт B в режиме 0 (адрес), порт C[3:7]- гандшейк для порта А.
Мне кажется проще выделить один порт на запись, а другой на чтение, чтобы не заниматься двунаправленным обменом через A. Или для экономии портов (и возможно совместимости с другими устройствами подключенными к ПУ) все же переключать направление обмена, для мыши и клавиатуры это сравнительно малозатратно.
Должно быть просто и быстро. Направление настраивается один раз и больше не трогается. Думаю, при разумно сделанном контроллере, фулл даплекс режим нибблов порта C вообще будет не востребован. Кидаем номер регистра в порт (A или B) настроенный в режиме запись потом либо туда же пишем Дату Туташхию либо читаем данные из порта (B или A) настроенного на чтение. На запись получается регистр-секвенсер. На чтение, 2 разных порта. Не стоит направления переключать. Это лишние такты проца. Итого 256 регистров. Их разрядность можно оговаривать, но в первом приближении, пусть будут все по 8 бит.
ЗЫ. Биты третьего двунаправленного порта можно завести под status/control самого контроллера. Типа:
ожидание чтения (данных)
ожидание записи (данных)
keep in reset
discard command (типа игнорировать последний выбранный регистр).
Но это плюшки уже
Если подумать о предполагаемых плюшках типа представления данных от мыши (или подключенных к девайсу джойстиков), в виде, совместимом с данными от джойстика, то наверное стоит посмотреть, будет-ли он полностью совместим с уже существующим стандартом джойстика по подключению и управлению... или это будет ещё одна разновидность, под которую будут свои дрова, и существующие софт его не будет видеть как джойстик...
Improver
11.08.2023, 07:57
будет-ли он полностью совместим с уже существующим стандартом джойстика по подключению и управлениюПравильное замечание. Можно и нужно сделать возможность переключения контроллера в режим такой совместимости, кнопкой и/или программно.
И вообще, обсуждение сокращения числа используемых портов на ПУ не имеет смысла без привязки к существующему железу для ПУ: если этот контроллер не будет нормально сосуществовать с джойстиками, или ром-картриджем на ПУ, то теряет смысл экономии портов и с аппаратной точки зрения, и с программной -- проще использовать все три порта, не выдумывая хитрые протоколы считывания данных по одному каналу.
Работа с мышью через контроллер, имеет скрытые подводные камни.
Возможно проявляться проблема будет в неравномерности движения курсора, возможно это будет не очень заметно, а возможно и очень заметно. Только реальный эксперимент, реализованный в железе, сможет показать, юзабельно это, или будет раздражать...
Всё будет зависеть от того, как будет реализовано общение контроллера с мышью и с Вектором.
Если опрос мыши будет осуществляться только после запроса данных от Вектора, то большого выигрыша может и не быть, так как на время получения от мыши данных, Вектор будет вынужденно висеть в цикле опроса статуса запроса. Но можно предположить, что перемещение курсора будет вполне адекватным.
Хотя при такой реализации, конечно, можно и хитрить... типа в начале прерывания отправить запрос контроллеру, а получать от него запрошенные данные только в конце обработки прерывания.
Если контроллер просто будет постоянно опрашивать мышь, с частотой (приблизительно равной) прерываний Вектора, то возникнет проблема синхронизации, так как нет синхронизации Вектора и контроллера.
Если для синхронизации будут использоваться сами запросы, возникнет проблема предоставления не актуальных данных, если запросы от Вектора будут не регулярными, из-за приостановки или пропуска прерываний.
Вот какие-то такие мысли в голову лезут...
Контроллер должен сам регулярно опрашивать мышь и копить приращения по X и Y (и желательно колесо). Если при обращении вектора текущее накопленное приращение больше байта, то нужно выдать максимум и вычесть его из накопленного приращения.
- - - Добавлено - - -
Кстати, использование контроллера с накоплением в нем приращений позволяет вектору опрашивать мышь не по прерываниям.
Improver
11.08.2023, 22:44
Если контроллер будет возвращать сразу координаты курсора на экране, то опрашивать его можно будет быстро, просто и в любое удобное время, независимо от прерываний. А приращениями всякими, отслеживанием выхода за границу экрана и прочим пусть занимается контроллер. Понадобятся вдруг приращения в программе -- вычти новую считанную координату из предыдущей, это не сложно.
Если контроллер будет возвращать сразу координаты курсора на экране, то опрашивать его можно будет быстро, просто и в любое удобное время, независимо от прерываний. А приращениями всякими, отслеживанием выхода за границу экрана и прочим пусть занимается контроллер. Понадобятся вдруг приращения в программе -- вычти новую считанную координату из предыдущей, это не сложно.
Ну, это просто может быть одной и плюшек, т.е. для "координат курсора" просто отдельные "регистры" контроллера выделить.
Если к девборде есть исходники хаба для usb-мыши/клавы, то думаю именно usb имеет смысл юзать, а не ps/2.
Хотя, судя по реализации на длугих железках, usb реализован на прерываниях, можно наверное и от Вектора запрос потерять.
Для принятия таких решений, нужно конкретное железо знать/ковырять.
CodeMaster
12.08.2023, 07:52
Дико извиняюсь, что врываюсь в вашу дискуссию, как слон в посудную лавку, но сейчас это одна из немногих живых тем на форуме, приходится почитывать ;-)
Не очень понимаю куда вас вывезет кривая, но технически пока получается, что это будет нечто сложнее чем на одной ATMega8. Тогда, почему бы сразу не сделать SuperComboDevice (или МегаШадки), добавив в него мышь, клавиатуру и VGA?
Improver
12.08.2023, 08:30
это будет нечто сложнее чем на одной ATMega8.Atmega32u4 с USB-входом потянет легко, думаю, и ps/2 тоже.
Тогда, почему бы сразу не сделать SuperComboDevice (или МегаШадки), добавив в него мышь, клавиатуру и VGA?Добавить vga в котроллер -- это сразу на порядок его усложнит и потребует переход на шину ВУ вместо ПУ, но зато там можно будет ещё организовать и аппаратный курсор на экране. :)
- - - Добавлено - - -
Ну, это просто может быть одной и плюшек, т.е. для "координат курсора" просто отдельные "регистры" контроллера выделить.Ещё раз повторю идею: порт А, например, -- координата Х, порт В -- координата Y, порт С -- всё остальное, в т.ч. управление контроллером. В результате со стороны Вектора имеем очень простое и быстрое ПО. Вычислить приращение, если нужно -- разность двух байт, тоже проще, чем переключать контроллер... Хотя, кому нужно это приращение, если будем получать готовую координату?
Хотя, кому нужно это приращение, если будем получать готовую координату?
Если я возьму и видео-режим переключу с высокого на низкое разрешение ненадолго. Как теперь координату интерпретировать?
Мыши прирастают, и этим ценны. Absolute mode хорош когда есть touch panel с фиксированным разрешением и пиксел спэйсингом.
Жаль конечно, что идея карты с мульти-фифо отвергается. Мне уже виделось как я настраиваю SPI mode и clock prescaler и пишу в какой-нить SPI flash через ПУ. Ну пусть будет мышь. Только если можно, в relative mode (со смещениями) пожалуйста.
Уже писал о проблеме с абсолютным режимом, попробую еще раз. Проблема возникает при долгом (или очень долгом) смещении мыши в одну сторону. С абсолютными возможны два варианта, которые неприемлемы в общем случае (годятся только при управлении курсором в рамках одного экрана): или насыщение или заворот. Думаю понятно, что в общем случае это может привести или к залипанию или к "метаниям".
- - - Добавлено - - -
Еще один как мне кажется важный момент - простота и повторяемость реализации. Если контроллер ограничится буферизацией значений от мыши и переводом последовательный<->параллельный, то это можно сравнительно легко повторить и в эмуляторах и в v06cc.
[QUOTE=ivagor;1183816]Думаю понятно, что в общем случае это может привести или к залипанию или к "метаниям".
- - - Добавлено - - -
Именно поэтому absolute mode используют только в touch panels. Но даже там встречаются контроллеры которым необходима калибровка от центра.
Это "не наш метод" (с)
Improver
12.08.2023, 09:59
Если я возьму и видео-режим переключу с высокого на низкое разрешение ненадолго. Как теперь координату интерпретировать?В случае разрешений Вектора -- нет никаких проблем. С учётом того, что режим 512х256 -- это просто экранные плоскости со смещением, то можно использовать те же 256 значений, курсор даже не сдвинется при изменении разрешения. А при желании можно добавить "двойную точность", добавить девятый бит по горизонтали в порт С...
Absolute mode хорош когда есть touch panel с фиксированным разрешением и пиксел спэйсингом.А на Векторе и есть, фактически, фиксированное разрешение.
- - - Добавлено - - -
Проблема возникает при долгом (или очень долгом) смещении мыши в одну сторону. С абсолютными возможны два варианта, которые неприемлемы в общем случае (годятся только при управлении курсором в рамках одного экрана): или насыщение или заворот. Думаю понятно, что в общем случае это может привести или к залипанию или к "метаниям".Все эти проблемы легко решаемы в контроллере -- можно и отслеживать границы экрана, и завороты с метаниями, и регулировать чуствительность мыши. А если это не делать в контроллере, то все эти проблемы лягут на плечи Вектора.
то это можно сравнительно легко повторить и в эмуляторах и в v06cc.Насчёт эмуляторов соглашусь, сделать там такой контроллер будет сложнее...
- - - Добавлено - - -
встречаются контроллеры которым необходима калибровка от центра.Калибровка мыши "от центра" -- это просто её поднять и перенести в другое, более удобное место на коврике. :)
курсор даже не сдвинется при изменении разрешения
Тогда это будет не очень приятно при высоком разрешении. Вроде, мышь двинули, а курсор стоит. И всяко 512 отсчётов в байт невпихуемо. Значит, старший бит придётся читать каждый раз для режима высокой точности (пусть хоть и из другого порта). А с относительные смещения можно ограничить диапазоном +-127
У вектора пикселы в высоком и низком разрешении имеют разный спейсинг. Если смещения относительные, чувствительность можно рихтовать программно, и добиться более-менее естественной гармонии между хуманом и девайсом в соответствии с конкретным софтом. Так мне верится, может зря. Но абсолютный режим - это железный дровосек-автоматон. Он приходит c безоговорочной координатой. Намаемся, боюсь (даже не учитывая залипы).
CodeMaster
12.08.2023, 10:16
Добавить vga в котроллер -- это сразу на порядок его усложнит и потребует переход на шину ВУ вместо ПУ
Ну, так и Комбо и Шадки и так на ВУ, зато сразу получится всё необходимое в одном устройстве. Насчёт ресурсов для VGA не знаю, а для клавы и мыша возможно они там уже есть.
Improver
12.08.2023, 10:17
Тогда это будет не очень приятно при высоком разрешении.Это будет незаметно на Векторе, как незаметно переключение из 256х256 на 512х256 в "Тесте устройств". Но если нужна двойная точность, то я бы предложил добавлять бит не в старший разряд, а в младший -- так будет проще, не потребуется пересчёт координат в экранной плоскости при изменении разрешения. Т.е. девятый бит =0, то пишем в нечётные плоскости, а если =1 -- то в чётные, по тем же координатам.
А насчёт "намаемся" и "гармонии" могу сказать, что любом случае, всё, что не будет сделано в контроллере, потребуется делать в Векторе, а там уж намаяться можно в разы больше.
Все эти проблемы легко решаемы в контроллере
Совершенно не согласен.
Improver
12.08.2023, 11:20
Совершенно не согласен.Почему? По сути, есть физические перемещения мышки, которые надо переделать в перемещения курсора по экрану. Кто будет заниматься какой частью этих преобразований не важно -- драйвер на Векторе, или контроллер, но их нужно выполнить, с отработкой всех коллизий (типа заворотов и метаний), это неизбежно. Можно, конечно, всё сделать в Векторе, но любая ардуина с этой задачей справится влёт, так почему бы и нет? Да и написать и отладить скетч легче, чем сделать то же самое на Векторе, при отсутствии эмуляции этой новой железки. Конечно, без драйвера для Вектора не обойтись, но чем он будет проще, тем проще получится разработка всего устройства. Разве нет?
Почему? По сути, есть физические перемещения мышки, которые надо переделать в перемещения курсора по экрану. Кто будет заниматься какой частью этих преобразований не важно -- драйвер на Векторе, или контроллер,получится разработка всего устройства. Разве нет?
Ещё как важно! Этим absolute addressing мы сразу убиваем возможность выставить mouse курсор в произвольное место по желанию (софта), или, скажем ограничить зону действия мыши некоей областью. Я так понимаю, курсор нам отрисовывать тоже давать не планируется...
В общем, с точки зрения софта, работа в absolute mode будет мукой. Это если мы примем, что контроллер разрулит все указанные выше проблемы (большинства из которых просто нет в relative mode по определению)
ЗЫ. И это ещё при том, что для нормальной точности в режиме высокого разрешения придётся дважды лазить в порт зачем-то. 512x256 и так тяжел а тут ещё и лишние чтения.
Почему?
Потому что это не общее решение, пример когда оно не применимо я приводил и могу еще привести (и PPC еще привел), но даже одного неподходящего примера достаточно.
чем он будет проще, тем проще получится разработка всего устройства
Согласен, поэтому и предлагаю обойтись минимальной обработкой в контроллере.
Жаль конечно, что идея карты с мульти-фифо отвергается. Мне уже виделось как я настраиваю SPI mode и clock prescaler и пишу в какой-нить SPI flash через ПУ
Не всеми! Просто у нас тут пока битва абсолютоконечников с приростоконечниками. Она на самом деле проходит совершенно по касательной и к сути устройства отношения не имеет.
- - - Добавлено - - -
Если координаты абсолютные, но 16-битные, становится все равно. Разница с предыдущим положением -- приращение. Разница с начальным условным нулем -- абсолютное положение на экране.
С ужасом подумалось, что будет когда мы дойдём до сути.
Будет битва в стиле "почему в вашем USB нет PD контроллера и альт мод не пронегошиировать"
Если координаты абсолютные, но 16-битные, становится все равно
Плата за все равно - придется передавать в два раза больше данных между контроллером и вектором.
Improver
12.08.2023, 13:30
Ещё как важно! Этим absolute addressing мы сразу убиваем возможность выставить mouse курсор в произвольное место по желанию (софта), или, скажем ограничить зону действия мыши некоей областью.Вовсе нет. Ничто не мешает управлять настройками контроллера с Вектора, отправляя на него соответсвующие команды, тут даже половинки порта С хватит. Можно даже прикинуть, что будет проще -- отправить при необходимости команду "перемести курсор в Х,У" или заниматься вычислениями координат по приращениям каждое прерывание, да ещё и с проверкой коллизий... И мне кажется, что выигрыш будет не на стороне упрощённого контроллера.
В общем, с точки зрения софта, работа в absolute mode будет мукой. Это если мы примем, что контроллер разрулит все указанные выше проблемы (большинства из которых просто нет в relative mode по определению)Разрулит, даже не сомневайтесь. Самая простая ардуинка сейчас мощнее Вектора, так почему бы это не использовать? А будет ли это мукой или спасением -- только практика покажет.
ЗЫ. И это ещё при том, что для нормальной точности в режиме высокого разрешения придётся дважды лазить в порт зачем-то.Не сложнее, чем в других случаях, если учесть, что дополнительный бит будет в порту С, вместе с кнопками, и туда в любом случае надо будет лезть.
- - - Добавлено - - -
Согласен, поэтому и предлагаю обойтись минимальной обработкой в контроллере.Да, но следует учесть, что упрощение разработки эмулятора в итоге выливается в усложнение написания программ для Вектора, которое может дать непеодолимый барьер его внедрению.
Плата за все равно - придется передавать в два раза больше данных между контроллером и вектором.
Поддерживаю. Как бы мы не делали, с мультикартой или без, затыка - 8-битные регистры PPA. Поэтому max 7 бит смещения + 1 бит знака в relative mode имеет смысл для обоих видеорежимов. Не знаю, сколько накопится за 20ms между IRQ, но думаю надо будет сильно мышью дрыгать в одном направлении чтобы переполнило. Это предел контроллер должен на себя взять (ты уже писал)
Поддерживаю. Как бы мы не делали, с мультикартой или без, затыка - 8-битные регистры PPA. Поэтому max 7 бит смещения + 1 бит знака в relative mode имеет смысл для обоих видеорежимов. ...
Я уже писал ранее, в стандартном протоколе ps/2-мыши передаётся 8 бит смещения.
Бит направления находится в одном байте с кнопками.
Я уже писал ранее, в стандартном протоколе ps/2-мыши передаётся 8 бит смещения.
Бит направления находится в одном байте с кнопками.
Ну нам никто не мешает попробовать урезать до 6 бит как тут кто-то про БК упоминал, и хранить кнопку и направление в одном байте. Это то контроллер может на себя взять. Тогда всё уложится в 2 чтения портов (если колесо не надо читать).
следует учесть, что упрощение разработки эмулятора в итоге выливается в усложнение написания программ для Вектора, которое может дать непеодолимый барьер его внедрению.
Тут уже надо переходить к конкретным цифрам, которых у меня в полном виде нет. Грубые прикидки такие:
1. Текущий вариант KTSerga - в районе 5000+ тактов на опрос. Очень много (можно ускорить), поэтому контроллер хотелось бы, но я согласен даже на такой вариант, т.к. он уже реализован в железе и работает.
2. Вариант с параллельной передачей от контроллера. Тут смотря как считать и что считать, но пусть будет 200-300 тактов. Разница между абсолютным и относительным (вектор сам будет считать абсолютные) - ну тактов 100, ну пусть даже 200, зато можно использовать для любых задач.
Плата за все равно - придется передавать в два раза больше данных между контроллером и вектором.
Я сам больше за приращения. Но разница между приращениями и абсолютными в общем отсутствует. Даже если они 8 битные с переполнением, это все равно то же самое. Проблема только если в контроллере будет насыщение, тогда это вообще никуда не годится.
разница между приращениями и абсолютными в общем отсутствует. Даже если они 8 битные с переполнением, это все равно то же самое. Проблема только если в контроллере будет насыщение, тогда это вообще никуда не годится.
Отметаем насыщение - не будет залипаний, это хорошо. Но если 8 битные абсолютные с переполнением, то при определенном сочетании условий возможны "метания". При 16 битах вызвать метания вряд ли возможно.
Отметаем насыщение - не будет залипаний, это хорошо. Но если 8 битные абсолютные с переполнением, то при определенном сочетании условий возможны "метания". При 16 битах вызвать метания вряд ли возможно.
По моим оценкам добиться метаний будет непросто -- или программа будет слишком редко опрашивать, или мышка полетит с третьей космической. Как пруф -- мышка у коммодора 64 фактически передает постоянно проворачивающееся положение условного колеса. Забыл разрядность АЦП-а, но он там точно в пределах 8 бит. Коммодор 64 не знаменит своими мышовыми способностями, но нам и до него пока как пешком до луны.
Так почему все-таки просто приращения нельзя? Вроде миллиарды человеко-часов пользования мышей с приращениями (за вычетом тех, что на коммодоре 64) говорят о том, что приращения работают.
Так почему все-таки просто приращения нельзя
Improver считает, что абсолютные значения от контроллера резко упросят и ускорят работу с мышью. Я считаю, что упростят и ускорят, но не намного, зато это разом ограничивает возможные варианты использования мыши, что на мой взгляд совсем неприемлемо.
Если прикинуть 16-битный режим c приращениями в 1м приближении (по 2 чтения порта на координату), мы ломаем копья вокруг примерно 92х тактов в ISR (плюс необходимость прочесть PPA порт C для кнопок)
84 * 2 = 168 тактов в ISR
(дважды)
DB (lxi h)
axis: DW 0
in
mov c,a
in
mov b,a
dad b
shld axis
против 76 тактов при 8-битных приращениях
lxi h,yx
in
add m
mov m,a
inx h
in
add m
mov m,a
Really?
Резкость сейчас сглаживается легкостью обмена информацией. Но при полутора потенциальных пользователях важно учитывать пожелания всех и каждого.
Improver
12.08.2023, 15:53
зато это разом ограничивает возможные варианты использования мыши, что на мой взгляд совсем неприемлемо.А давайте обсудим все возможные варианты использования мыши? Я могу предположить следующие:
Указание на экране -- кнопки меню, точки при рисовании и т.д.
Эмуляция функций джойстика -- движение вправо/влево/вверх/вниз...
... Что ещё?
В первом случае однозначно передача координат будет лучше, во втором надо сделать переключение режима в "джойстик", программно или кнопкой, причём контроллер должен полностью эмулировать сигналы джойстика ПУ, чтобы не патчить существующие программы. А в каких случаях лучше получать дельту координат? В упомянутом Wolf3d?
Ну вот, я не успел сочинить ответ, а PPC уже написал драйвер.
Я к тому, что контроллер умный и обрабатывает знаки. На векторе понадобятся простые нормировки краёв, примитивные как репа (проверка битов старше 8-го или -9го в зависимости от видеорежимов).
в каких случаях лучше получать дельту координат?
1.
ограничить зону действия мыши некоей областью
2.
В упомянутом Wolf3d
3. Перетаскивание/прокрутка карты (или чего-то подобного) в окне.
Тут достаточно было одного примера, если он существует, значит абсолютные не годятся.
UncleDim
12.08.2023, 16:30
Абсолютные координаты превращают мышь в аналоговый джойстик, в граф. планшет, во что угодно - но это уже не мышь
Имхо
Вот не пруха... хотел посмотреть, какие можно получить значения смещения при максимальной скорости перемещения мыши... и добавить в тестовую программу значения колеса прокрутки...
Но не смог найти распаянный переходник. Там были распаяны разъёмы и ps/2 и usb.
Improver
12.08.2023, 19:38
1.Не проблема и в координатах.
2.Которого ещё нет и не факт, что он будет.
3. Перетаскивание/прокрутка карты (или чего-то подобного) в окне.Да, было несколько игрушек, где экран прокручивался в окошке с четверть размера экрана (или даже меньше), на большее ресурсов Вектора не хватало. Но для такого частного случая можно и посчитать разность.
Тут достаточно было одного примера, если он существует, значит абсолютные не годятся.То же самое можно сказать и про относительные...
- - - Добавлено - - -
Абсолютные координаты превращают мышь в аналоговый джойстик, в граф. планшет, во что угодно - но это уже не мышь
ИмхоТ.е. в той же винде мышка превращается во что-то другое? Хм...
А что тогда будет точно мышь?
Не проблема и в координатах.
Тут не получится просто брать абсолютные координаты и пользоваться ими. Придется добавить обработку, которая так или иначе использует разности ("выливаем чайник на плиту").
Которого ещё нет и не факт, что он будет.
Есть рейкастер для 8080 и есть wolf48 для вектора с z80 (кстати спековский оригинал поддерживает мышь).
Но для такого частного случая можно и посчитать разность.
Как и для первого случая.
То же самое можно сказать и про относительные
У абсолютных есть принципиальное ограничение - при очень быстром перемещении произойдет переполнение и мы не сможем однозначно сказать в какую сторону переместились (и тут возможны "метания"). На практике с этим можно бороться частым опросом мыши, чтобы она не успела уехать слишком далеко. Предполагаю, что комодорский вариант так и делает, тем более там не 256 точек ни по X ни по Y (и скорее всего они переходят к разностям).
Что будет при очень быстром перемещении мыши и относительных приращениях. У контроллера внутри разрядность счетчиков приращений можно сделать больше, что позволяет при очень быстром перемещении запомнить его внутри и потом выдавать за несколько опросов. У внутренних счетчиков разностей надо делать насыщение, тогда даже при супербыстром и длительном перемещении метаний не будет, в худшем случае перемещение курсора будет отставать от перемещения мыши.
Improver
12.08.2023, 20:47
У абсолютных есть принципиальное ограничение - при очень быстром перемещении произойдет переполнение и мы не сможем однозначно сказать в какую сторону переместились (и тут возможны "метания").Вот поэтому лучше это делать контроллером -- там можно мышь опрашивать так часто, как Вектор просто не сможет, а координаты выдавать по запросу Вектора.
У контроллера внутри разрядность счетчиков приращений можно сделать больше, что позволяет при очень быстром перемещении запомнить его внутри и потом выдавать за несколько опросов.Но лучше сделать пересчёт там же, в контроллере, и выдавать готовую координату за один запрос, без метаний. Зачем, опять же, нагружать Вектор тем, что может сделать контроллер?
Похоже, что доводы, для аппонентов не убедительны...
Осталось только каждому собрать контроллер, с реализованном в нём конкретном способе предоставления информации, интегрировать в софт поддержку полученного контроллера мыши, и показать всем, что именно его идея наиболее удобна для применения. ;)
- - - Добавлено - - -
...
Но лучше сделать пересчёт там же, в контроллере, и выдавать готовую координату за один запрос, без метаний. Зачем, опять же, нагружать Вектор тем, что может сделать контроллер?
Если контроллер будет выдавать готовые координаты курсора, то и запрос от Вектора не нужен. Контроллер должен постоянно выставлять на "ПУ" актуальные координаты, вообще не интересуясь, забирает их Вектор или нет.
Если все-же кто-то соберёт переходник (без контроллера), и протестирует мышь, то нужно проверить, достаточно-ли скорости перемещения курсора, если отбросить младший разряд данных.
Но лучше сделать пересчёт там же, в контроллере, и выдавать готовую координату за один запрос, без метаний. Зачем, опять же, нагружать Вектор тем, что может сделать контроллер?
Так контроллер ее и выдаст.
Мне очень не хотелось, по похоже придется вернуться к началу и рассмотреть, когда от абсолютных есть толк.
Сразу отметим, что от насыщения по краям придется отказаться. Для такого варианта пришлось бы ограничить возможную область перемещений мыши, откалибровать и не выходить за эти рамки (иначе залипания). Крайне неудобно и никто так делать не будет, для таких случаев лучше тачпад или что-то в этом духе.
Значит используем переполнение/перенос. Когда есть польза от такого варианта - если мы управляем курсором, область перемещений которого весь экран и при достижении края происходит заворот. Честно говоря, это не самый распространенный вариант интерфейса, но только в этом случае мы можем брать координаты от контроллера и непосредственно их использовать. Во всех других случаях придется пересчитывать (скорее всего на разности) и все преимущество абсолютных испаряется.
Improver
12.08.2023, 23:08
Если контроллер будет выдавать готовые координаты курсора, то и запрос от Вектора не нужен. Контроллер должен постоянно выставлять на "ПУ" актуальные координаты, вообще не интересуясь, забирает их Вектор или нет.Да, всё так и должно быть. Я имел в виду не прямо запрос данных, а просто чтение из нужного порта.
Сразу отметим, что от насыщения по краям придется отказаться.Не понял, почему? Откуда будут залипания? Допустим, координата стала равна нулю у края, двинул мышку влево -- остаётся ноль, а вправо -- она сразу увеличивается.
Не понял, почему? Откуда будут залипания? Допустим, координата стала равна нулю у края, двинул мышку влево -- остаётся ноль, а вправо -- она сразу увеличивается.
Признаю ошибку, при полноэкранном интерфейсе и насыщении проблем не будет. Проблемы и большие при использовании насыщения начинаются в этих случаях (https://zx-pk.ru/threads/30224-vektor06ts-klava-i-mysh-ps-2-cherez-quot-pu-quot.html?p=1183859&viewfull=1#post1183859).
UncleDim
13.08.2023, 13:37
в той же винде мышка превращается во что-то другое?
Вот вообще не понял этого. В той же винде мышка (при упертом в край курсоре) не перестает передавать приращения, т.е. НЕ превращается во что-то другое.
Так...
Переходник я нашел, ps/2-мышь подключил.
Для тех, кто захочет повторить, в выложенных исходниках написано, что мышь подключена к разъёму клавиатуры.
Видимо в готовом модуле работы с клавиатурой, я не изменил биты управления на мышиные.
Колесо прокрутки подключил, протестировал (исходники пока не выкладывал).
При стандартных значениях параметра "разрешение" = 4 пикс/мм, с разрешением экрана 256/256 - мышь бегает вполне привычно.
Соответственно, при переходе к разрешению экрана 512/256 - по горизонтали скорость ниже в два раза.
Выход, при инициализации мыши, увеличиваем значение параметра "разрешение" в два раза 8 пикс/мм, и уменьшаем полученное значение смещения мыши в два раза для осей с разрешением 256. И получаем равномерное передвижение указателя мыши по экрану с комфортной скоростью в любом направлении.
А ещё, как-бы быстро не дёргал/перемещал мышь, значения смещения по осям X/Y не превысили 100 в десятичном значении, т.е. укладываются в 7 бит. Это при регулярных опросах мыши в прерываниях.
У колеса прокрутки, по паспорту диапазон от -8 до +7.
Improver
13.08.2023, 14:17
В той же винде мышка (при упертом в край курсоре) не перестает передавать приращения, т.е. НЕ превращается во что-то другое.Ну и тут будет то же самое. В чём тогда проблема?
UncleDim
13.08.2023, 14:43
Improver, да где ж то же самое, если эти приращения вы предлагаете убивать ещё в контроллере?
Improver
13.08.2023, 15:01
UncleDim, а что, разве есть разница, где выполняются вычисления, если результат, в конечном итоге, один? Или контроллер выдаёт какие-то некошерные байты? :)
UncleDim
13.08.2023, 15:11
Improver, вы правда не догоняете? Что в
иных сценариях эти вычисления не выполняются и их результат не нужен?
Improver
13.08.2023, 16:29
UncleDim, а сколько этих "иных сценариев" может быть, применительно к Вектору? Т.е. всех программ, где мышь может использоваться не как указатель координаты на экране и не как замена джойстика? Выйдет пять, ну пусть даже 10, и проблема всех этих "иных" решается банальным вычитанием. Ради это стоит усложнять все остальные?
проблема всех этих "иных" решается банальным вычитанием.
Т.е. ты все же за абсолютные с переполнением/переносом? Если нет, то как при абсолютных с насыщением сделать банальным вычитанием продолжительное перемещение карты или картинки в окне в одну сторону или продолжительное вращение персонажа рейкастера в одну сторону?
UncleDim
13.08.2023, 17:06
Improver, сценариев может быть достаточно, при наличии аппаратного вертикального скроллинга
Каким вычитанием вы собрались отличать неподвижную на краю экрана мышь от движущейся за край?
Improver
13.08.2023, 22:56
Если нет, то как при абсолютных с насыщением сделать банальным вычитанием продолжительное перемещение карты или картинки в окне в одну сторону или продолжительное вращение персонажа рейкастера в одну сторону?Ну если надо техническое решение для этой задачи, то я бы предложил два варианта, на выбор в зависимости от конкретных условий:
При попадании курсора в область у края экрана, или рамки (шторки) вокруг карты, делать сдвиг изображения. Собственно, тут ничего нового -- это и на ПК встречается.
Переключить контроллер в режим "джойстик" и двигать карту. Этот вариант подходит в случае, если в программе мышь для других целей не используется.
Вообще, не стоит забывать, что Вектор -- это не современный быстрый компьютер, он не сможет двигать большую карту в экране со скоростью курсора мыши, даже при наличии аппаратного скроллинга.
UncleDim
13.08.2023, 23:04
не стоит забывать, что Вектор -- это не современный быстрый компьютер
т.е. двигать курсор по экрану - для него норм, а НЕ двигать на краях - уже перебор?))
за сколько тактов при обработке приращения vs абсолютов борьба идет? притом ценой функционала?
Improver
13.08.2023, 23:14
т.е. двигать курсор по экрану - для него норм, а НЕ двигать на краях - уже перебор?))Вообще не понял, что Вы имеете в виду, поясните.
за сколько тактов при обработке приращения vs абсолютов борьба идет? притом ценой функционала?Не считал в числах, но он явно будет, тут даже сомнений нет. И да, потеря функционала при обработке приращения тоже будет -- теряем аппаратный ускоритель вычисления позиции курсора.)) Причём ускоритель этот полностью независим от прерываний и не требует постоянного слежения за тем, двигалась мышь или нет.
UncleDim
13.08.2023, 23:28
поясните
всякое движение вызовет какую-то реакцию - перерисовать что-то на экране в типовом виде, и это явно не один-два байта. что (по сравнению с этим) экономится при передаче абсолютных координат вместо приращений? крохи..
Improver, ради копеечного выигрыша в варианте использования, который ты считаешь важным и нужным ты готов сделать невозможным использование мыши в других вариантах, которые тебе неинтересны. Что сказать, позиция понятна.
Improver
14.08.2023, 08:07
ivagor, не совсем так. Моя позиция, и об этом я написал в самом начале -- не упрощать контроллер, а усложнять, перенести в него большинство вычислений, насколько это будет возможно, и в то же время упростить обращение к нему. И я согласен на разные режимы его работы, в т.ч. на аппаратную эмуляцию джойстиков, и на гибкое управление его настройками, вплоть до программной настройки чуствительности мыши.
Ну а Ваша позиция тоже понятна -- сделать всё сейчас быстро и просто, экономя не понятно для чего в железе, и не важно, что будет потом. Пусть те, кто будет писать программы с поддержкой мыши сами "жрут кактус"... Тем более, что все и так привыкли к тому, что мышь может только давать информацию об относительных перемещениях, не более.
Периодически всплывает мнение, что мышь должна иметь возможность (восприниматься Вектором) работать как джойстик.
Честно говоря, я мало играл джойстиком, но мне кажется его преимущество, держать контакты замкнутыми, достаточно долго.
Тогда как у мыши, так не получится ни при каком раскладе. Так как эмуляция "нажатия контактов" зависит от физического перемещения мыши. Значит у "джойстика" из мыши будет постоянный "дребезг контактов". Приемлемо ли это?
Скорее всего это ограничит применяемость такой имитации.
Или я не прав?
- - - Добавлено - - -
... Моя позиция, и об этом я написал в самом начале -- не упрощать контроллер, а усложнять, перенести в него большинство вычислений, насколько это будет возможно ...
Я с самого начала говорил, что если это контроллер, то ничего не мешает реализовать в нём все "хотелки".
Вопрос, как управлять контроллером, если все три порта "ПУ" будут настроены на вход?
Как я понял, к примеру:
порт "А" - X;
порт "В" - Y;
порт "С" - 3 кнопки, 1 бит для Х в режиме 512, колесо прокрутки 4 бита (значение от -8 до +7).
Как сообщить мыши, что нужно перейти в другой режим, перезагрузиться, или изменить чувствительность?
Как вариант, соединить контроллер мыши с разъёмом магнитофона, и по нему слать команды управления? ;)
UncleDim
14.08.2023, 08:57
все три порта "ПУ"
а не слишком ли жирно для одной мыши-то?
Ну а Ваша позиция тоже понятна -- сделать всё сейчас быстро и просто, экономя не понятно для чего в железе, и не важно, что будет потом.
Мне представляются приемлемыми два варианта:
1. Максимально простой, который KTSerg уже реализовал.
2. Его сравнительно простая адаптация с микроконтроллером, который возьмет на себя преобразования последовательный<->параллельный.
При этом в вектор передаются нативные данные с мыши, что является проверенным универсальным решением. Передавать абсолютные координаты с насыщением = ограничивать область применения мыши для копеечной экономии в тактах векторовского софта в части задач (и непреодолимых проблем в других задачах), это я уже повторяюсь. Компромиссным вариантом является добавление абсолютного режима в качестве дополнительного, программно переключаемого.
а не слишком ли жирно для одной мыши-то?
Ну так-то оно конечно ряха у мыши может и треснуть...
Но если есть желание ускорить опрос мыши (контроллера) то как минимум два порта точно будут заняты, а если есть желание командовать мышью, и при этом нет желания переключать режим порта ввод/вывод, то снова будут заняты все три:
"А" вход - чтение данных из мыши
"В" выход - команды управления контроллером
"С" вход/выход - сигналы управления/состояния
Конечно, при подключении мыши без контроллера достаточно 4 бит порта "С". Но довольно большой расход ресурсов процессора на опрос мыши по последовательному интерфейсу.
UncleDim
14.08.2023, 10:36
нет желания переключать режим порта ввод/вывод
не для этого ли придуман mode 2 в 8255, раз уж цепляем контроллер?
Improver
14.08.2023, 10:47
Периодически всплывает мнение, что мышь должна иметь возможность (восприниматься Вектором) работать как джойстик.
Честно говоря, я мало играл джойстиком, но мне кажется его преимущество, держать контакты замкнутыми, достаточно долго.
Тогда как у мыши, так не получится ни при каком раскладе. Так как эмуляция "нажатия контактов" зависит от физического перемещения мыши. Значит у "джойстика" из мыши будет постоянный "дребезг контактов". Приемлемо ли это?
Скорее всего это ограничит применяемость такой имитации.
Или я не прав?Прав. Первые реализации мыши на Векторе так и работали, и были не очень удобны в этом плане, если не ошибаюсь -- где-то я видел об этом статью...
Как сообщить мыши, что нужно перейти в другой режим, перезагрузиться, или изменить чувствительность?Пока что у меня такая идея:
- порты А и В -- координаты курсора, или эмуляция сигналов джойстика (УСПИД -- порт А, ПУ -- порт В и С). Ну или относительное перемещение, для страждущих.
- порт С, т.к. он позволяет разделить себя на два по 4 бита, использовать, например, так: на кнопки можно отдать 2 бита (10-"левая", 01-"правая" и 11-"средняя"), и два бита колесо и для режима 512 (0х -- бит для 512, 11 -- колесо крутится вверх, 10 -- колесо вниз). А вторые 4 бита использовать для управления, возможно управлять придётся передачей нескольких байт...
Ну это для примера, можно и по-другому всё распределить -- как будет удобнее.
а не слишком ли жирно для одной мыши-то?Если контроллер не будет предполагать одновременного подключения с ROM-диском, джойстиками или чем-то ещё -- то не жирно. В любом случае весь разъём ПУ будет занят, нет смысла ужиматься в портах.
- - - Добавлено - - -
ограничивать область применения мыши для копеечной экономииОграничений там не будет, можно реализовать всё, что угодно. И... "копейка рупь бережёт". :)
не для этого ли придуман mode 2 в 8255, раз уж цепляем контроллер?
Когда-то давно, я искал инфу на этот режим работы. Но или не нашел, или не разобрался, или он не подошел для моих нужд... уже не помню.
Точно знаю, что никогда этим режимом не пользовался.
Там для управления портом "А" чето много от порта "С" отгрызают... не знаю точно.
А если порт "С" будет занят управлением портом "А", то снова порт "В" понадобится.
Возвращаемся обратно к разбитому корыту, от чего уходили, к тому и вернулись.
Ограничений там не будет, можно реализовать всё, что угодно.
Раз можно реализовать все, что угодно, то я продолжаю ждать ответа, как можно реализовать то, что я написал здесь (https://zx-pk.ru/threads/30224-vektor06ts-klava-i-mysh-ps-2-cherez-quot-pu-quot.html?p=1183926&viewfull=1#post1183926). Это (https://zx-pk.ru/threads/30224-vektor06ts-klava-i-mysh-ps-2-cherez-quot-pu-quot.html?p=1183941&viewfull=1#post1183941) не ответы на мои вопросы, с таким же успехом можно было написать, что можно и без мыши обойтись и управлять с клавиатуры.
Раз можно реализовать все, что угодно, то я продолжаю ждать ответа, как можно реализовать то, что я написал здесь (https://zx-pk.ru/threads/30224-vektor06ts-klava-i-mysh-ps-2-cherez-quot-pu-quot.html?p=1183926&viewfull=1#post1183926). Это (https://zx-pk.ru/threads/30224-vektor06ts-klava-i-mysh-ps-2-cherez-quot-pu-quot.html?p=1183941&viewfull=1#post1183941) не ответы на мои вопросы, с таким же успехом можно было написать, что можно и без мыши обойтись и управлять с клавиатуры.
Влажу в чужой диалог, но мне кажется ответ на этот вопрос уже был.
Перемещение карты или поворот перса осуществляется при выходе координат мыши за пределы карты или окна, при наличии бордюра или шторки (вокруг карты или окна). Либо смещение и разворот продолжаются до тех пор, пока координаты мыши имеют минимальное/максимальное значение. Соответственно для остановки смещения/разворота достаточно отодвинуть курсор мыши от края экрана. При таком варианте, для длительного смещения или разворота, даже мышкой не нужно двигать, достаточно подогнать курсор к самому краю экрана. Ну, это конечно софт должен понимать, чё нужно делать.
Ну это я так понял, возможно ошибаюсь.
мне кажется ответ на этот вопрос уже был.
Я задал два вопроса (по сути они одинаковые, вернее в их реализации при абсолютных координатах с насыщением одна и та же пробдема) и ответа на них я не видел.
Перемещение карты или поворот перса осуществляется при выходе координат мыши за пределы карты или окна, при наличии бордюра или шторки (вокруг карты или окна). Либо смещение и разворот продолжаются до тех пор, пока координаты мыши имеют минимальное/максимальное значение. Соответственно для остановки смещения/разворота достаточно отодвинуть курсор мыши от края экрана. При таком варианте, для длительного смещения или разворота, даже мышкой не нужно двигать, достаточно подогнать курсор к самому краю экрана. Ну, это конечно софт должен понимать, чё нужно делать.
Да можно вобще курсором на клавиатуре двигать, я же не спрашивал как еще можно организовать интерфейс.
- - - Добавлено - - -
Ладно ребята, если и автору железа и потенциальному программисту не понятно, что я пишу, наверно проблема во мне. Завершаю свое участие в данной теме, чтобы не засорять тему и не мешать.
UncleDim
14.08.2023, 12:11
если порт "С" будет занят управлением портом "А", то снова порт "В" понадобится.
Так А двунаправленным будет, с учетом трех свободных линий порта С - через А можно будет читать из контроллера хошь координаты, хошь приращения, хошь скан-коды,... и управлять контроллером через него же
Improver
14.08.2023, 12:22
Это (https://zx-pk.ru/threads/30224-vektor06ts-klava-i-mysh-ps-2-cherez-quot-pu-quot.html?p=1183941&viewfull=1#post1183941) не ответы на мои вопросыЭто и был ответ, извиняюсь за своё путанное описание, но KTSerg его выше (https://zx-pk.ru/threads/30224-vektor06ts-klava-i-mysh-ps-2-cherez-quot-pu-quot.html?p=1183972&viewfull=1#post1183972) совершенно правильно разъяснил, более подробно и не скажешь...
- - - Добавлено - - -
Так А двунаправленным будет, с учетом трех свободных линий порта С - через А можно будет читать из контроллера хошь координаты, хошь приращения, хошь скан-коды,... и управлять контроллером через него жеЯ тут (https://zx-pk.ru/threads/30224-vektor06ts-klava-i-mysh-ps-2-cherez-quot-pu-quot.html?p=1183966&viewfull=1#post1183966) предложил несколько другой вариант -- там все порты однонаправленные могут быть.
Я задал два вопроса (по сути они одинаковые, вернее в их реализации при абсолютных координатах с насыщением одна и та же пробдема) и ответа на них я не видел.
...
Честно говоря, я действительно не совсем понимаю о чём идёт речь, возможно я не представляю, что такое "при абсолютных координатах с насыщением", конкретно, что такое "насыщение" в данном контексте.
Думаю, для нового софта, нет проблемы получать от мыши готовые координаты курсора, и используя их, реализовать смещения и развороты.
Мне кажется, могут возникнуть проблемы, если захочется интегрировать мышь в уже готовый софт, в котором курсор может спокойно стоять на крайних координатах экрана, а смещение экрана инициируется через попытку сместить курсор за пределы экрана. Т.е. например стоит курсор в координате Х=0, а для сдвига экрана нужно нажать клавишу влево, т.е. попытаться сместить курсор за пределы экрана. Ведь контроллер мыши, выдающий готовые координаты не позволит такого сделать.
Вот интересно, есть-ли какой-то софт для Вектора, например графического редактора, в который можно было-бы попытаться интегрировать мышь, желательно без проблем глобального масштаба ?
В гаф. редакторах наиболее затратная по времени процедура, это заливка, интересно, во время заливки прерывания отключаются ?
- - - Добавлено - - -
Кстати о расположении мыши на "ПУ".
Вспомнился "сюрприз", обнаруженный мной в штатном загрузчике .02-го Вектора.
А конкретно, что в нём есть работа с ВВ55, расположенной по адресам F0-F3 (если кто-то не видел эту тему).
И раз в штатном ПЗУ эта ВВ55 используется, значит её можно считать "штатным железом". ;)
Перевесить мышь туда, и "ПУ" снова освободится...
Improver
14.08.2023, 18:02
Перевесить мышь туда, и "ПУ" снова освободится...Можно перевесить, но только на реалах там нет ВВ55А, надо будет ещё и её подключать.
UncleDim
15.08.2023, 00:26
на реалах там нет ВВ55А
т.е. была уже достаточно широко распространенная периферия, так? а какая? любой новодел не должен по идее ей мешать..
т.е. была уже достаточно широко распространенная периферия, так? а какая? любой новодел не должен по идее ей мешать..
Если вопрос про использование ВВ55 на портах F0-F3, то кроме меня, вроде ни кто не сообщал, что где-то встречал упоминания об этом железе.
Вот тема про его обнаружение:
https://zx-pk.ru/threads/28939-syurpriz-v-zavodskom-zagruzchike.html?p=954099&viewfull=1#post954099
Если кратко, обнаруженный ВВ55 - это скорее всего аналог порта "ПУ", для загрузки ПО (32КБ) при старте Вектора, из альтернативного "внешнего ПЗУ".
Поскольку этот порт ВВ55 использовался в штатной прошивке, но в самом Векторе он отсутствовал, то можно предположить, что это был отдельный модуль, скорее всего, подключаемый к разъёму "ВУ".
Возвращаясь к нашей теме мыши... поскольку её подключение к разъёму "ПУ" ни как не влияет на работу Вектора при старте (опросе периферии на ПУ), то и перенос мыши на адреса гипотетически существовавшего (ВВ55) "внешнего ПЗУ", ни как не должно никому помешать.
При этом освободится разъём "ПУ" для подключения другого железа.
Improver
15.08.2023, 08:17
перенос мыши на адреса гипотетически существовавшего (ВВ55) "внешнего ПЗУ", ни как не должно никому помешать.Да, переносу адресов мыши в этот диапазон никак не помешает (и поможет) наличие кода в загрузчике 02-го, но, чисто теоретически, в некий счастливый момент в результате археологических изысканий или новодела может появится тот самый картридж для ВУ, и вот тогда это может стать проблемой... Может просто выбрать и принять в качестве стандарта для мыши любой свободный диапазон портов, если уж решим освободить ПУ?
...
- порт С, т.к. он позволяет разделить себя на два по 4 бита, использовать, например, так: на кнопки можно отдать 2 бита (10-"левая", 01-"правая" и 11-"средняя"), и два бита колесо и для режима 512 (0х -- бит для 512, 11 -- колесо крутится вверх, 10 -- колесо вниз).
...
Мне кажется, что если оставить от колеса прокрутки только признак/направление вращения, то это резко ухудшит его использование, поскольку "чувствительность" будет напрямую зависеть от частоты опроса мыши.
Предположим, что мышь опрашивается в прерываниях, значит от колеса прокрутки получим максимум 50 позиций смещения за 1 секунду, тогда как при получении значения вращения, могли-бы за ту-же секунду теоретически получить до 350-ти позиций вращения.
Получается, что будет не важно, быстро крутил колесо, или медленно, больше 50-ти смещений не получишь. Приходим к варианту "мышь в режиме джойстика" - использовать можно, но не удобно :( нет пропорциональности, чувствительности к активности использования элементом управления :(
Improver
16.08.2023, 08:08
Получается, что будет не важно, быстро крутил колесо, или медленно, больше 50-ти смещений не получишь.Не стоит забывать, что Вектор -- это не большой ПК, он просто физически не сможет обработать столько смещений. Если, допустим, на каждое смешение делать сдвиг текста на одну строку, то 10 смещений в секунду -- это максимум его возможностей (исходя из скорости вывода ~800 символов в секунду в лучшем случае).
UncleDim
16.08.2023, 08:27
он просто физически не сможет
(полуOFF) есть мнение, что через ВУ можно "отобрать" у вм80 всё, все "потроха" Вектора (и, соответственно, "отдать" их кому-то более шустрому).
Не стоит забывать, что Вектор -- это не большой ПК, он просто физически не сможет обработать столько смещений. Если, допустим, на каждое смешение делать сдвиг текста на одну строку, то 10 смещений в секунду -- это максимум его возможностей (исходя из скорости вывода ~800 символов в секунду в лучшем случае).
Сдвиг текста - частный случай. В МикроДосе вообще применение мыши затруднено, так как курсор привязан к командной строке.
Только в текстовых редакторах есть некая свобода.
Но я говорил про возможность использования в играх и в прикладных задачах, где нужно будет сдвинуть/изменить значение какого-то параметра. Вот тут и будет морока с чувствительностью.
- - - Добавлено - - -
(полуOFF) есть мнение, что через ВУ можно "отобрать" у вм80 всё, все "потроха" Вектора (и, соответственно, "отдать" их кому-то более шустрому).
Ну, скорее не "отобрать" а "перехватить" для возможной параллельной обработки.
И не всё и не сразу.
Где-то было обсуждение, что в простом Векторе сталкивались с проблемой, с адресами внешних устройств, с адресами до 0Fh, а в 02-ом такой проблемы нет. Или я что-то путаю...
В общем не всё так однозначно.
Improver
16.08.2023, 11:21
Сдвиг текста - частный случай.Для колеса скорее частый. :)
Но я говорил про возможность использования в играх и в прикладных задачах, где нужно будет сдвинуть/изменить значение какого-то параметра. Вот тут и будет морока с чувствительностью.Для таких случаев, когда нужно точно знать, насколько и куда прокрутили колесо, можно сделать ещё один режим контроллера, например, так: когда зафиксировано вращение колеса в порт А пишется не координата мыши, а насколько был поворот -- в любом случае Вектор не сможет отслеживать и курсор, и колесо. Ну или выдавать данные по колесу на запрос отдельной командой в порт С, т.е. увидели бит, что колесо прокрутили -- запросили в С и считали из А куда и на сколько.
...
два бита колесо и для режима 512 (0х -- бит для 512, 11 -- колесо крутится вверх, 10 -- колесо вниз).
...
Пока колесо крутится, не возможно будет узнать бит для 512 ?
Improver
16.08.2023, 18:59
Пока колесо крутится, не возможно будет узнать бит для 512 ?Да, получается так... Вообще, это ещё не стандарт, можно всё переиграть, например, сделать сообщения колеса как написал выше (https://zx-pk.ru/threads/30224-vektor06ts-klava-i-mysh-ps-2-cherez-quot-pu-quot.html?p=1184149&viewfull=1#post1184149), а четвёртый бит использовать только для 512.
Оказалось, что Арканоид, очень легко адаптируется для подключения мыши.
Конечно, в заставку не влезал, ни каких доп. меню, просто мышь дублирует клавиатуру.
Правда перемещение мыши пропорциональное, скорость движения каретки зависит от скорости перемещения мыши.
Если есть желающие... модифицированный Арканоид прикрепил к первому сообщению этой темы.
https://zx-pk.ru/threads/30224-vektor06ts-klava-i-mysh-ps-2-cherez-quot-pu-quot.html?p=1003249&viewfull=1#post1003249
Мышь PS/2 подключена к "ПУ" по схеме из первого поста, мышь по прежнему подключена в "разъём клавиатуры", т.е. в "ПУ" задействованы: РС1,РС2,РС5,РС7.
По поводу управления.
ЛКМ - дублирует "пробел".
ну и вправо/влево соответственно.
Перемещение мыши вверх/вниз - не обрабатывается.
ПКМ - делит скорость перемещения мыши на 2, каретка начинает двигаться со скоростью примерно как от клавиатуры.
СКМ - возвращает оригинальную скорость перемещения мыши, каретка начинает шустро бегать.
Вроде в теме про Пенсил только про Пенсилы разговор, а я тут про вообще. Что если все-таки приделать на ПУ последовательный порт с FIFO, а лучше два? Железно можно равняться на стандартный 16550, на практике можно его эмулировать микроконтроллером. Реалистично Вектор наверное сможет обрабатывать максимум 4800 бит/c (исхожу из глубины фифо и частоты прерываний Вектора).
Вроде в теме про Пенсил только про Пенсилы разговор, а я тут про вообще. Что если все-таки приделать на ПУ последовательный порт с FIFO, а лучше два? ...
"ПУ" довольно удобен для исследований железа, но на практике он уже слишком перегружен девайсами.
Столкнулся с этим когда мышь к Пенсилу подключал. Там есть функционал вывода на принтер, а он как известно к "ПУ" подключен. Уже конфликт оборудования гарантирован.
С другой стороны, у "ПУ" конечно значительное преимущество перед другими вариантами подключения - это простота для повторяемости желающими, так как собрать схему подключения к "ВУ" значительно сложнее.
Но если с железным СОМ-ом заморачиваться, то лучше сразу его на "ВУ" вешать.
Я пока мышь ковырял, уже подумывал выделить отдельный порт и повесить его на "ВУ". На нём может висеть 4 линии эмулирующие выход с ОК. Хоть c ps/2 экспериментируй, хоть с i2c.
Но если с железным СОМ-ом заморачиваться, то лучше сразу его на "ВУ" вешать.
Я глубоко идейно поддерживаю этот тезис, но я уже один раз навешивал на "ВУ" и мне показалось, что это невыносимо затратная морока даже для одержимого фаната Вектора. Вероятность того, что устройство на "ВУ" будет реплицировано, если только это не ComboDevice, исчезающе мала. Поэтому я даже больше за примитивный PS/2 на ПУ как сейчас, чем за настоящий компорт на ВУ.
... Реалистично Вектор наверное сможет обрабатывать максимум 4800 бит/c (исхожу из глубины фифо и частоты прерываний Вектора).
Оптимистичный прогноз, а почему не 2400 бит/с ?
Improver
09.09.2023, 08:50
Если что, уже делал попытки собрать com-порт для Вектора (https://zx-pk.ru/threads/30481-com-port-dlya-vektora.html), но до практической сборки так и не дошло...
Оптимистичный прогноз, а почему не 2400 бит/с ?
4800 бит/c ~ 480 байт в сек, делим на 50 получается 9.6 байт за прерывание. Получается, что FIFO глубиной 16 символов не будет переполняться, если не пропускать прерывания.
Мышки по-моему работают на 1200.
- - - Добавлено - - -
Если что, уже делал попытки собрать com-порт для Вектора, но до практической сборки так и не дошло...
Без буфера по-моему нет смысла пробовать.
Improver
09.09.2023, 12:34
Без буфера по-моему нет смысла пробовать.Можно сделать буфер на стороне контроллера -- в любом случае сейчас комовских мышей не найдёшь, надо как-то делать преобразование ps2 <-> com, там и добавить буфер.
4800 бит/c ~ 480 байт в сек, делим на 50 получается 9.6 байт за прерывание. Получается, что FIFO глубиной 16 символов не будет переполняться, если не пропускать прерывания.
Мышки по-моему работают на 1200.
...
Да я понимаю.
Тоже считал: 50 (прерываний в сек.) * 16 (байт, буфер fifo) * 8 (бит) = 6400 бит/с. Соответственно ближайший меньший стандарт 4800.
Было бы интересно прикинуть, максимально возможную скорость, которую может потянуть Вектор, если подключить 16550 к "ПУ", с учетом всех потерь на управление портом 55-ым.
Я ещё не изучал 16550, не знаю, нужно ли постоянно читать регистр статуса (необходимость постоянно переключать направление порта), чтобы узнать состояние буфера, или достаточно подключить выход "INTRPT" на вход порта "С", тогда часто переключать направление портов не нужно будет.
Можно сделать буфер на стороне контроллера -- в любом случае сейчас комовских мышей не найдёшь, надо как-то делать преобразование ps2 <-> com, там и добавить буфер.
16550 это и есть UART с буфером. Я на всякий случай уточню -- что идея подключения компортовской мышки не столько ради упрощения, сколько ради обобщения. Если есть компорт, который Вектор может полноценно использовать, то к нему можно подключить мышь, а можно модем или терминал, или другой Вектор.
Адаптер ps/2 на serial -- задача решенная уже много раз. Ну просто например: https://hackaday.io/project/27575-ps2-to-rs232-mouse-converter. Но ps/2 в наше время тоже как-то уже грустно. Если б я сам загорелся идеей, я бы взял rp2040-zero и сделал адаптер USB-мышки и клавиатуры с помощью pico-pio-usb. Но я точно не буду.
16550 это и есть UART с буфером. Я на всякий случай уточню -- что идея подключения компортовской мышки не столько ради упрощения, сколько ради обобщения. Если есть компорт, который Вектор может полноценно использовать, то к нему можно подключить мышь, а можно модем или терминал, или другой Вектор.
...
Погуглил про СОМ-мыши.
Подключать СОМ-мышь к Вектору не имеет ни какого смысла.
Если ps/2-мышь можно настроить, чтобы сообщала смещение только по запросу, то СОМ-мышь тупо шлёт данные при перемещении, не интересуясь, принимают эти данные или нет. Не нашел инфы, про интервалы между пакетами. Не понятно, как часто СОМ-мышь отправляет данные. Но подозреваю, что Вектор задолбается разгребать спам от СОМ-мыши.
- - - Добавлено - - -
Получается, что в случаях, когда программа не критична, что мышь ест 30% времени, подойдёт и простая в подключении ps/2.
На Арканоид я очень удачно наткнулся :) там ресурсы тратятся фактически только на перемещение каретки и шарика.
Для программ, более критичных к времени и размеру драйвера - ни куда не деться от контроллера, который будет работать с мышью, и готовить для Вектора данные, в виде, наиболее удобном для чтения/применения.
Не понятно, как часто СОМ-мышь отправляет данные. Но подозреваю, что Вектор задолбается разгребать спам от СОМ-мыши.
Что ж тут непонятного. 1200 7N1: 1200/9/50, значит за прерывание может прийти максимум 3 байта и это верхняя оценка с запасом.
Микрософтовский протокол шлет обновления примерно 40 раз в секунду по три байта за посылку. Кнопки + два байта со знаком + битик синхронизации. Вот тут нарисована картиночка: https://roborooter.com/post/serial-mice/
Это как раз то, что самодельный контроллер все равно пришлось бы заставить делать, только уже сделано за нас.
Что ж тут непонятного. 1200 7N1: 1200/9/50, значит за прерывание может прийти максимум 3 байта и это верхняя оценка с запасом.
У меня складывается впечатление, что за одно прерывание, 3 байта не успеют полностью приняться.
Поскольку нет синхронизации в виде запрос/ответ, то должен быть дополнительный буфер принятых данных, из которого будут вылавливаться пакеты.
Микрософтовский протокол шлет обновления примерно 40 раз в секунду по три байта за посылку. Кнопки + два байта со знаком + битик синхронизации. Вот тут нарисована картиночка: https://roborooter.com/post/serial-mice/
Это как раз то, что самодельный контроллер все равно пришлось бы заставить делать, только уже сделано за нас.
Почему-то не вдохновляет.
Делать СОМ-мышь из usb или ps/2-мыши, что-бы потом маяться со спамом данных, которые валятся без запроса.
Для интеграции мыши в игры, это слишком заморочисто.
Делать/использовать два контроллера для мыши, что-бы получить данные, на интерпретацию которых нужно дополнительно тратить ресурсы... мне кажется это перебор.
У меня складывается впечатление, что за одно прерывание, 3 байта не успеют полностью приняться.
Поскольку нет синхронизации в виде запрос/ответ, то должен быть дополнительный буфер принятых данных, из которого будут вылавливаться пакеты.
Разумеется нужен буфер. Я говорю с первого сообщения про буфер и в каждом сообщении повторно привожу его характеристики в расчетах.
Я пожалуй сдаюсь. Разочаровался в своей способности излагать мысли.
Разумеется нужен буфер. Я говорю с первого сообщения про буфер и в каждом сообщении повторно привожу его характеристики в расчетах. ...
А я то думал, что речь шла о fifo внутри 16550.
Но его не достаточно, чтобы корректно принять данные от мыши. И я сказал, что дополнительно к fifo в 16550, нужен ещё один кольцевой fifo для корректного вылавливания пакетов.
А я то думал, что речь шла о fifo внутри 16550.
Но его не достаточно, чтобы корректно принять данные от мыши. И я сказал, что дополнительно к fifo в 16550, нужен ещё один кольцевой fifo для корректного вылавливания пакетов.
Я именно о нем и говорю. Ты можешь объяснить почему его недостаточно для того, чтобы принять три байта? Тебя смущает то, что три байта будут приходить необязательно все вместе и их нужно складывать в программный буфер? Это тривиальная задача.
Я именно о нем и говорю. Ты можешь объяснить почему его недостаточно для того, чтобы принять три байта? Тебя смущает то, что три байта будут приходить необязательно все вместе и их нужно складывать в программный буфер? Это тривиальная задача.
Да, я предвзято отношусь у потоку данных СОМ-портов.
Меня нервирует, что отправленный блок данных, может приходить кусками разной длины, а два отдельно отправленных блока данных, могут объединяться в приёмном буфере в непрерывную цепочку данных.
Это конечно не касается конкретно мыши, где блок всего 3 байта. Хотя и с ней будет точно так-же.
Но принимать даже эти несчастные 3 байта кусками в разных прерываниях, это тоже не фонтан.
Я понимаю, что вылавливать их не такая уж сложная задача. В конце концов, приняв 5 байт, мы гарантированно имеем один целый пакет, и его уже можно анализировать.
Просто не вижу в этом особого смысла. Зачем собирать два контроллера и потом возиться с дикой мышью, когда можно сделать сразу то, что нужно Вектору, что-бы освободить его от лишних хлопот, и получать от контроллера мышиные данные в нужном виде.
Поэтому я остаюсь приверженцем синхронизации, и получения только запрошенных данных.
aGGreSSor
03.12.2025, 23:07
Чем больше смотрю (по диагонали) векторного текстового наследия, тем больше возникает ощущение что "всё" было, было - много, но всё это жестоко проано. В частности мышка на Векторе. Потому что она постоянно и регулярно упоминается. Пользователи пишут, что она у них есть и они ей пользуются. На спектруме так с Kempston, AY и AMX мышками не носились, как на Векторе с ПУ-мышкой. При этом софта нет, отдельных каких-то схем нет (эмуляторщикам - пофиг), как она в реале подключалась и обрабатывалась неизвестно и эмуляторы её не поддерживают. Отсюда можно сделать вывод, что либо все эти вектористы были сумасшедшими, либо всё про[beep]ано. :rolleyes:
Поверхностная хронология:
[B]1994 - Задумались о начале "грандиозной работы по адаптации графредакторов. Уже есть пара программ (каких - неизвестно) где мышь мелькает среди джойстиков. См. Журнал "Гепард №1", сентябрь-94;
1996 - Мышь подключили к ПУ, адаптировали для неё как минимум DRAW. Это подаётся как стандартная мышь для Вектора. См. Журнал "Микро №4", 1996;
1998 - Мышь широко (по меркам Вектора) распространена (зачем-то). С. Кучеренко, Украина, Киевская обл. г. Вышгород, перечисляя устройства которыми с радостью пользуется упоминает "мышь" к разъёму "ПУ" (параллельно принтеру и независимо от его работы). См. Радиолюбитель №1 за 1998;
2000 - В. Быков, село Ратчино Оренбургской обл. сетует на большое число схем подключения джойстиков не считая 1 схемы подключения мышки. См. Ваш компьютер №6 за 2000. Ну т.е. это действительно стандарт
Это можно расширять, первое что отметилось. Как бы, вот...
Учитывая что известных личностей касаемо вектора в те годы можно пересчитать на пальцах двух рук, кто то из них пользовался мышью (наверно) и схемы были на бумаге, которые уже давно утеряны. Всем остальным эта мышь была нужна, как собаке пятая нога, поэтому и не взлетела так сказать. да и сообщество вектористов было в 1000 раз меньше чем спектрумистов, к сожалению. Помню в своем городе один раз за все время пользования вектором нашел на него кассету с софтом в магазине, при этом спектрумных кассет продавалось тысячами на каждом углу.
Powered by vBulletin® Version 4.2.5 Copyright © 2025 vBulletin Solutions, Inc. All rights reserved. Перевод: zCarot