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

[KTSerg]

Эмуляторы мыша уж как-нибудь изобразить смогут, было бы что изображать.
Осмысленный контроллер должен иметь два порта на которых будет постоянно обновляющаяся дельта перемещения +-127. Наверное прекрасно хватило бы и одного порта, допустим старший бит признак X/Y, а младшие 7 +- 63 дельта.

Потому и говорил, что скорее всего понадобится ТРИ порта, так как если перемещения засунуть в один байт, то разрядность перемещения получится слишком маленькая, а ведь нужно ещё состояние кнопок получать.

В идеале - да. Но все зависит от задач, например для редактора шрифтов текущий вариант вполне нормальный, там ограничивающим фактором является скорость человека. А вот для требовательных игрушек типа warcraft или wolf 1/10 времени на опрос мыши - непозволительная роскошь. Другое дело, что таких игрушек для вектора не будет, а редактор шрифтов - вот он, осталось добавить туда мышь.

Ну, с реал-тайм активными игрушками, как ни жаль, на Векторе будет тяжеловато, из-за известных причин...
А вот что-то типа пошаговых стратегий, где персу нужно указать, куда пойти, что взять, и т.п. ... даже без контроллера, подключенной к "ПУ" мыши вполне достаточно, и игровой процесс будет "приятнее", я так думаю...

[Advertiser]

[ivagor]

скорее всего понадобится ТРИ порта

Если минимизировать число портов для чтения, то достаточно двух - в одном выбор номера (в него запись) в другом - данные выбранного номера (отсюда читаем).

[KTSerg]

Если минимизировать число портов для чтения, то достаточно двух - в одном выбор номера (в него запись) в другом - данные выбранного номера (отсюда читаем).

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

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

+- 64 точки, то есть четверть экрана, за 1/50 секунды это совсем не маленькая разрядность по-моему. Буду рад увидеть софт, который демонстрирует недостаточность такой разрядности. Но кнопки конечно да, без кнопок никак.

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

[PPC]

Потому и говорил, что скорее всего понадобится ТРИ порта, так как если перемещения засунуть в один байт, то разрядность перемещения получится слишком маленькая, а ведь нужно ещё состояние кнопок получать.

Наверное можно из регистра "состояния кнопок" сделать статус регистр 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 окон)
Но это детали