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

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

[Advertiser]

[b2m]

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

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

[KTSerg]

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

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

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

[ivagor]

Итак, остаётся открытым вопрос о "интеллектуальном" контроллере, который сводит работу с мышью к простому чтению двух или трёх портов?

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

[svofski]

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

[Improver]

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

[ivagor]

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

[UncleDim]

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

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

[Improver]

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

В случае Вектора wolf3d, скорее, частный случай, чем управление курсором. А так, получая сразу координату на экране можно избавить Вектор от дополнительных вычислений. И, если уж так хочется, можно сделать переключение режимов суперконтроллера, чтобы он выдавал координаты или смещение, или даже ещё и третий вариант -- "режим джойстика".

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

Пара IMHO
1. Голосую за минимальную дополнительную обработку в контроллере.

А моё имхо -- чем больше будет делать контроллер, тем меньше потребуется ресурсов Вектора, и тем быстрее будут работать программы и игры, и тем проще будет их делать, т.е. я голосую за максимальную обработку.

Мне вот представляются интересными не только координаты и основные кнопки, но и колесо.

Кстати, да -- колесо тоже можно как-то применить.

[ivagor]

Пара IMHO
1. Голосую за минимальную дополнительную обработку в контроллере. У текущего варианта, который сделал KTSerg один недостаток - слишком медленный опрос и если контроллер возьмет на себя только преобразование из последовательного вида в параллельный, то этого как мне кажется будет достаточно. Плюсы: упрощение ПО контроллера и его отладки, максимальная совместимость.
2. Все же я бы сделал порт номера и порт данных вместо нескольких фиксированных портов данных. Тут не только бережное использование адресного пространства ввода-вывода (которое у 8080 не такое уж большое) но и потенциальная совместимость с разными форматами. Мне вот представляются интересными не только координаты и основные кнопки, но и колесо.