17.10.2021 11:42
[#1]
Protokoły myszek z obsługą rolki czyli "hakowanie Ryśka" ;)
Do napisania poniższego postu skłonił mnie wynik analizy myszek, a właściwie driverów do nich, bo żadnej z nich nie posiadam ;). W szczególności przeanalizowałem najpopularniejszy Cocolino, który jest pochodną projektu Alastair M. Robinson znanego jako robinsonb5 na EAB, a sam Cocolino obsługuje (chyba) wszystkie InputEvent:
oraz chyba najsłynniejszy klawisz w Amigach:
Protokół komunikacyjny opiera się na odczycie stanu linii LMB, RMB i dwu linii kwadraturowych, które szczęśliwie są do odczytania z rejestrów joy0dat ... wprost. Sam odczyt odbywa się po wywołaniu opadającego zbocza na linii MMB, która jest potem trzymana w stanie niskim przez kolejne 64us (przebiegi widać na zrzucie https://github.com/sq7bti/AVAGO/raw/main/cocolino_timing.png). Odpowiednie dobranie opóźnień jest krytyczne i niektóre problemy jakie doświadczyłem i tutaj opisuję mogą mieć pośrednio z nim związek. Komunikacja jest jednokierunkowa, więc nie ma mowy o jakimkolwiek potwierdzeniu dotarcia informacji. Doprowadza to do sytuacji, że po podłączeniu myszki która nie obsługuje protokołu Cocolino sygnały są interpretowane błędnie jako naciśnięcia dodatkowych klawiszy lub przekręcenie rolki. To może zrobić każdy kto posiada klasyczną mysz i ściągnie ze strony Elbox sterownik - do analizy przyda się tester który jest dołączony do pakietu, ale dużo lepszy jest RawKeys, który pokazuje stany i kody nawet gdy wciśniemy RMB albo LMB.
Klawisz środkowy (MMB) jest emulowany przez wystawienie stanu niskiego podczas impulsu na linii LMB. Przekręcenie rolki w którąś ze stron powoduje wystawienie odpowiedniej kombinacji na dwu liniach kwadraturowych które są używane do komunikacji
wraz z wystawieniem stanu niskiego na linii RMB. Ustawienie stanu wysokiego na linii RMB, z taką samą kombinacją na liniach kwadraturowych jest interpretowane jako wciśnięcie lub podniesienie jednego z dwu dodatkowych klawiszy (4th, 5th).
Przechodząc do sedna sprawy, linie na złączu myszy są obsługiwane przez trzy różne układy i mają odmienną charakterystykę z powodu ich pierwotnego zastosowania:
Podsumowując: ograniczenie użycia linii LMB/MMB/RMB do komunikacji DO myszy, a wyłącznie czterech linii kwadraturowych OD myszy, jest z moich obserwacji stabilniejsze i pewniejsze, i zapewnia wystarczającą pewną komunikację sygnałów z kółka i kilku dodatkowych klawiszy. Sprawa braku reakcji przy podłączonej klasycznej myszy można rozwiązać po prostu kodując informację w odpowiedni sposób - przez logiczny EXOR z aktualnym stanem na liniach kwadraturowych. Wystarczy w kontrolerze myszy zamiast na sztywno ustawiać linie X/XQ/Y/YQ, wykonać na nich operator "^=", a w sterowniku uruchomionym na komputerze wykonać operacje EOR na rejestrze JOY0DAT przed i po wywołaniu opadającego zbocza MMB.
s.
p.s. Wszystkie obserwacje powyżej opisane oparte są wyłącznie na badaniu działania oprogramowania Cocolino.driver i jego reakcji na impulsy z mojego eksperymentalnego kontrolera myszy. Jeśli posiadasz taki kontroler i widzisz jakieś niezgodności w moim opisie, byłbym wdzięczny za uwagi.
p.s. ^2 a gdzie jest Rysiek?
Ostatnia aktualizacja: 17.10.2021 23:00:17 przez sq7bti
Ostatnia aktualizacja: 17.11.2022 21:15:45 przez sq7bti
- MMB
- Wheel_up
- Wheel_down
- Wheel_right
- Wheel_left
- Fourth_button
oraz chyba najsłynniejszy klawisz w Amigach:
Protokół komunikacyjny opiera się na odczycie stanu linii LMB, RMB i dwu linii kwadraturowych, które szczęśliwie są do odczytania z rejestrów joy0dat ... wprost. Sam odczyt odbywa się po wywołaniu opadającego zbocza na linii MMB, która jest potem trzymana w stanie niskim przez kolejne 64us (przebiegi widać na zrzucie https://github.com/sq7bti/AVAGO/raw/main/cocolino_timing.png). Odpowiednie dobranie opóźnień jest krytyczne i niektóre problemy jakie doświadczyłem i tutaj opisuję mogą mieć pośrednio z nim związek. Komunikacja jest jednokierunkowa, więc nie ma mowy o jakimkolwiek potwierdzeniu dotarcia informacji. Doprowadza to do sytuacji, że po podłączeniu myszki która nie obsługuje protokołu Cocolino sygnały są interpretowane błędnie jako naciśnięcia dodatkowych klawiszy lub przekręcenie rolki. To może zrobić każdy kto posiada klasyczną mysz i ściągnie ze strony Elbox sterownik - do analizy przyda się tester który jest dołączony do pakietu, ale dużo lepszy jest RawKeys, który pokazuje stany i kody nawet gdy wciśniemy RMB albo LMB.
Klawisz środkowy (MMB) jest emulowany przez wystawienie stanu niskiego podczas impulsu na linii LMB. Przekręcenie rolki w którąś ze stron powoduje wystawienie odpowiedniej kombinacji na dwu liniach kwadraturowych które są używane do komunikacji
wraz z wystawieniem stanu niskiego na linii RMB. Ustawienie stanu wysokiego na linii RMB, z taką samą kombinacją na liniach kwadraturowych jest interpretowane jako wciśnięcie lub podniesienie jednego z dwu dodatkowych klawiszy (4th, 5th).
Przechodząc do sedna sprawy, linie na złączu myszy są obsługiwane przez trzy różne układy i mają odmienną charakterystykę z powodu ich pierwotnego zastosowania:
- linia LMB obsługiwana jest przez CIA. Jest "w pełni" cyfrowa, bo pierwotnie miała służyć odczytu przycisku joysticka i do pióra świetlnego (_LPEN podłączony do _FIRE0 albo do _FIRE1)
ograniczenie pasma przez pasywne obwody EMC: 68Ω/470pF
Detekcja stanu niskiego przy 1.3..1.4V
Odczyt (PRA) i tryb pracy (DDRA) przez rejestry CIA-A
CIAA Address Map --------------------------------------------------------------------------- Byte Register Data bits Address Name 7 6 5 4 3 2 1 0 --------------------------------------------------------------------------- BFE001 pra /FIR1 /FIR0 /RDY /TK0 /WPRO /CHNG /LED OVL BFE201 ddra Direction for port A (BFE001);1=output (set to 0x03)
- linie dwukierunkowe RMB i MMB obsługiwane przez Paula. Wejścia pierwotnie zaprojektowano do pomiaru oporności "wiosełek".
zapis i odczyt:
#POTGO #POTGOR
ograniczenie pasma przez pasywne obwody EMC: 68Ω/470pF, oraz przez 47nF na wejściach Pauli.
Detekcja stanu niskiego (przynajmniej w moim egzemplarzu) jest problematyczna. Nie dość że Paula reaguje na stan niski dopiero po obniżeniu napięcia poniżej 0.5V, to ustawia na stan wysoki, kiedy napięcie wzrośnie powyżej 1.4V - efekt histerezy.
Moje wstępne testy z mikrokontrolerem podłączonym bezpośrednio do tych linii się powiodły, ale kondensator na wejściu sprawiał problemy przy próbach impulsowych. Szczególnie linia MMB sterowana przez diode Schottky ("symulowanie" układu OC/OD na wyjściu GPIO), nie reagowała na krótkie niskie impulsy. Sprawę poprawia (częściowo) przez zastosowanie tranzystora (niższe napięcie i bardziej strome zbocze opadające), ale komplikacja układu nie przeważa zysku z jego zastosowania.
- cztery wejściowe linie kwadraturowe. W OCS/ECS multipleksowane (zegar CCK) przez 74LS157, do Denise, a w AGA, zatrzaskiwane w rejestrze szeregowym 74LS166 i przesyłane liniami MDAT do układu Lisa (co 4.5us). Od strony programowej widoczne do odczytu sa w tym samym rejestrze JOY0DAT (JOY1DAT), na bitach 0, 1, 8 i 9, z tym że piny 3 i 4 na złączu DB9 (/LEFT i /RIGHT), so do odczytania wprost z bitów 1 (X1) i 9 (Y1), a piny 1 i 2 (/FORWARD i /BACK) trzeba obliczyć ze wzorów:
To detect Read these counter bits -------- ---------------- Forward Y1 xor Y0 (BIT#09 xor BIT#08) Left Y1 Back X1 xor X0 (BIT#01 xor BIT#00) Right X1
ograniczenie pasma przez pasywne obwody EMC: 68Ω/470pF.
JOY0DAT JOY1DAT
Podsumowując: ograniczenie użycia linii LMB/MMB/RMB do komunikacji DO myszy, a wyłącznie czterech linii kwadraturowych OD myszy, jest z moich obserwacji stabilniejsze i pewniejsze, i zapewnia wystarczającą pewną komunikację sygnałów z kółka i kilku dodatkowych klawiszy. Sprawa braku reakcji przy podłączonej klasycznej myszy można rozwiązać po prostu kodując informację w odpowiedni sposób - przez logiczny EXOR z aktualnym stanem na liniach kwadraturowych. Wystarczy w kontrolerze myszy zamiast na sztywno ustawiać linie X/XQ/Y/YQ, wykonać na nich operator "^=", a w sterowniku uruchomionym na komputerze wykonać operacje EOR na rejestrze JOY0DAT przed i po wywołaniu opadającego zbocza MMB.
s.
p.s. Wszystkie obserwacje powyżej opisane oparte są wyłącznie na badaniu działania oprogramowania Cocolino.driver i jego reakcji na impulsy z mojego eksperymentalnego kontrolera myszy. Jeśli posiadasz taki kontroler i widzisz jakieś niezgodności w moim opisie, byłbym wdzięczny za uwagi.
p.s. ^2 a gdzie jest Rysiek?
Ostatnia aktualizacja: 17.10.2021 23:00:17 przez sq7bti
Ostatnia aktualizacja: 17.11.2022 21:15:45 przez sq7bti
27.04.2023 18:44
[#10]
Re: Protokoły myszek z obsługą rolki czyli "hakowanie Ryśka" ;)
@Pawelek, post #9
Bez sterownika niestety się nie da. Obsługa rolki pod systemem polega na reakcji okien na rolkę i przewijanie ich zawartości, a nie na odczycie samej myszki. Sterownik odpowiedzialny jest za wygenerowanie event'ów:
Od strony aplikacji również musi być zapewniona obsługa, choć istnieją programy, które powyższe event'y tłumaczą na wciśnięcia klawiszy strzałek, by zmusić np. edytor tekstu do przewijania ekranu.
#define NM_WHEEL_UP (0x7A) #define NM_WHEEL_DOWN (0x7B) #define NM_WHEEL_LEFT (0x7C) #define NM_WHEEL_RIGHT (0x7D) #define NM_BUTTON_FOURTH (0x7E)
Od strony aplikacji również musi być zapewniona obsługa, choć istnieją programy, które powyższe event'y tłumaczą na wciśnięcia klawiszy strzałek, by zmusić np. edytor tekstu do przewijania ekranu.