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

[KTSerg]

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

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

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

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

[ivagor]

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

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

[svofski]

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

[KTSerg]

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

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

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

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

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

[b2m]

допустим старший бит признак X/Y, а младшие 7 +- 63 дельта.

Достаточно одного порта на чтение: старший бит признак начала пакета, в пакете три байта dX, dY, кнопки. Вроде COM-портовая мышь так и делала. Сейчас такую уже фиг найдёшь наверное.

[KTSerg]

Достаточно одного порта на чтение: старший бит признак начала пакета, в пакете три байта dX, dY, кнопки. Вроде COM-портовая мышь так и делала. Сейчас такую уже фиг найдёшь наверное.

На сколько я понял, речь шла не о реальном протоколе ps/2 мыши, а о том, как данные для Вектора должен предоставить воображаемый контроллер.
Глянул исходник, там в протоколе ps/2-мыши, при запросе данных, в ответ приходит три байта:
в первом - кнопки и флаги направления смещения
второй - смещение по Х, видимо все 8 бит используются, т.е. максимум +-255 позиций.
Третий - смещение по Y, так-же +-255 позиций.

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

[Advertiser]

[Improver]

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

[ivagor]

Разности - это более общий вариант, а координаты все же частный случай когда управляем курсором на экране. Проблема в том, что обработка абсолютных координат с насыщением по краям экрана. А если вдруг мы поворачиваемся в wolf3d, то никаких насыщений нет, поворачиваемся пока не укачает.

[UncleDim]

Разности - это более общий вариант

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

[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 окон)
Но это детали