Вектор06Ц, клава и мышь PS/2 через "ПУ"

[ivagor]

Но лучше сделать пересчёт там же, в контроллере, и выдавать готовую координату за один запрос, без метаний. Зачем, опять же, нагружать Вектор тем, что может сделать контроллер?

Так контроллер ее и выдаст.

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

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

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

[Advertiser]

[Improver]

Если контроллер будет выдавать готовые координаты курсора, то и запрос от Вектора не нужен. Контроллер должен постоянно выставлять на "ПУ" актуальные координаты, вообще не интересуясь, забирает их Вектор или нет.

Да, всё так и должно быть. Я имел в виду не прямо запрос данных, а просто чтение из нужного порта.

Сразу отметим, что от насыщения по краям придется отказаться.

Не понял, почему? Откуда будут залипания? Допустим, координата стала равна нулю у края, двинул мышку влево -- остаётся ноль, а вправо -- она сразу увеличивается.

[ivagor]

Не понял, почему? Откуда будут залипания? Допустим, координата стала равна нулю у края, двинул мышку влево -- остаётся ноль, а вправо -- она сразу увеличивается.

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

[KTSerg]

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

- - - Добавлено - - -

...
Но лучше сделать пересчёт там же, в контроллере, и выдавать готовую координату за один запрос, без метаний. Зачем, опять же, нагружать Вектор тем, что может сделать контроллер?

Если контроллер будет выдавать готовые координаты курсора, то и запрос от Вектора не нужен. Контроллер должен постоянно выставлять на "ПУ" актуальные координаты, вообще не интересуясь, забирает их Вектор или нет.

Если все-же кто-то соберёт переходник (без контроллера), и протестирует мышь, то нужно проверить, достаточно-ли скорости перемещения курсора, если отбросить младший разряд данных.

[KTSerg]

Так...
Переходник я нашел, ps/2-мышь подключил.
Для тех, кто захочет повторить, в выложенных исходниках написано, что мышь подключена к разъёму клавиатуры.
Видимо в готовом модуле работы с клавиатурой, я не изменил биты управления на мышиные.

Колесо прокрутки подключил, протестировал (исходники пока не выкладывал).

При стандартных значениях параметра "разрешение" = 4 пикс/мм, с разрешением экрана 256/256 - мышь бегает вполне привычно.
Соответственно, при переходе к разрешению экрана 512/256 - по горизонтали скорость ниже в два раза.
Выход, при инициализации мыши, увеличиваем значение параметра "разрешение" в два раза 8 пикс/мм, и уменьшаем полученное значение смещения мыши в два раза для осей с разрешением 256. И получаем равномерное передвижение указателя мыши по экрану с комфортной скоростью в любом направлении.

А ещё, как-бы быстро не дёргал/перемещал мышь, значения смещения по осям X/Y не превысили 100 в десятичном значении, т.е. укладываются в 7 бит. Это при регулярных опросах мыши в прерываниях.
У колеса прокрутки, по паспорту диапазон от -8 до +7.

[KTSerg]

Периодически всплывает мнение, что мышь должна иметь возможность (восприниматься Вектором) работать как джойстик.
Честно говоря, я мало играл джойстиком, но мне кажется его преимущество, держать контакты замкнутыми, достаточно долго.
Тогда как у мыши, так не получится ни при каком раскладе. Так как эмуляция "нажатия контактов" зависит от физического перемещения мыши. Значит у "джойстика" из мыши будет постоянный "дребезг контактов". Приемлемо ли это?
Скорее всего это ограничит применяемость такой имитации.
Или я не прав?

- - - Добавлено - - -

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

Я с самого начала говорил, что если это контроллер, то ничего не мешает реализовать в нём все "хотелки".
Вопрос, как управлять контроллером, если все три порта "ПУ" будут настроены на вход?
Как я понял, к примеру:
порт "А" - X;
порт "В" - Y;
порт "С" - 3 кнопки, 1 бит для Х в режиме 512, колесо прокрутки 4 бита (значение от -8 до +7).

Как сообщить мыши, что нужно перейти в другой режим, перезагрузиться, или изменить чувствительность?
Как вариант, соединить контроллер мыши с разъёмом магнитофона, и по нему слать команды управления?

[UncleDim]

все три порта "ПУ"

а не слишком ли жирно для одной мыши-то?

[KTSerg]

а не слишком ли жирно для одной мыши-то?

Ну так-то оно конечно ряха у мыши может и треснуть...
Но если есть желание ускорить опрос мыши (контроллера) то как минимум два порта точно будут заняты, а если есть желание командовать мышью, и при этом нет желания переключать режим порта ввод/вывод, то снова будут заняты все три:
"А" вход - чтение данных из мыши
"В" выход - команды управления контроллером
"С" вход/выход - сигналы управления/состояния

Конечно, при подключении мыши без контроллера достаточно 4 бит порта "С". Но довольно большой расход ресурсов процессора на опрос мыши по последовательному интерфейсу.

[UncleDim]

нет желания переключать режим порта ввод/вывод

не для этого ли придуман mode 2 в 8255, раз уж цепляем контроллер?

[KTSerg]

не для этого ли придуман mode 2 в 8255, раз уж цепляем контроллер?

Когда-то давно, я искал инфу на этот режим работы. Но или не нашел, или не разобрался, или он не подошел для моих нужд... уже не помню.
Точно знаю, что никогда этим режимом не пользовался.
Там для управления портом "А" чето много от порта "С" отгрызают... не знаю точно.
А если порт "С" будет занят управлением портом "А", то снова порт "В" понадобится.
Возвращаемся обратно к разбитому корыту, от чего уходили, к тому и вернулись.