Hej, luz, nie chodzi o sprzeczanie, ja też jestem od tego daleki:-)

Tutaj użyto analogowych komparatorów, ale w zastosowaniu cyfrowym:-) i układ jest cyfrowy, bo przetwarza sygnały cyfrowe składające się z zer i jedynek, a reszta nas nie interesuje. Idąc Twoim tokiem rozumowania, że komparator nazywa się "analogowym", to można by powiedzieć, że procesor jest też analogowy, bo składa się przecież z tranzystorów, które to potrafią wzmacniać sygnały analogowe:-) - no ale tak nie jest. O tym czy układ jest cyfrowy czy analogowy w uproszczeniu decydują przetwarzane w nim sygnały i sposób ich przetwarzania.

W tym konkretnym układzie z transoptorów otrzymujemy sygnał cyfrowy, który jednak jest "nieładny". Fototranzystory w zależności od tego jak są wygięte w tej myszce (nie ustawisz ich idealnie) oraz swojego rozstrzału parametrów dają nierówne napięcia, a w dodatku posiadając pewną "bezwładność" i pojemności w efekcie nie otrzymujemy idealnego prostokąta, tylko wydłużone zbocza narastające i opadające oraz "falujące" zera i jedynki. Atari oczekuje zer i jedynek a nie takiego bałaganu i dlatego, żeby ten sygnał wyrównać, to zastosowano komparatory analogowe, na wyjściu których mamy już ładny prostokąt o maksymalnie krótkich zboczach, który na porcie joya może Atari sobie odczytać i przetworzyć dalej cyfrowo na ruch myszy.
Aha, i chyba najważniejsze, od czego powinienem zacząć, to komparatory dopasowują też poziomy tych zer i jedynek do takich, które można dalej przetwarzać za pomocą układów TTL, bo z fototranzystorów dostajemy napięcia o innych poziomach niż potrzebujemy.

Słusznie zauważyłeś że impulsy mają różną szerokość (czyli tym samym częstotliwość), która jest zależna od ruchu myszy, ale tak jak napisałem wcześniej częstotliwość ta jest rzędu kilkudziesięciu herców, co można wygenerować i przetwarzać na wielokrotnie wolniejszym mikrokontrolerze niż atmega8 i na prawdę nie stanowi to żadnego problemu. A Atari próbkuje ten sygnał też z bardzo małą częstotliwością i nasz odczyt, przetworzenie i wystawienie sygnału za pomocą mikrokontrolera dla Atari jest zbyt szybki i trzeba go spowalniać, bo Atari nie nadąża tego czytać. Dlatego jeśli są jakieś opóźnienia i coś nie działa jak należy w takim interfejsie, to jest to wina źle napisanego firmware, a nie tego, że coś tam musi trwać, bo musi zostać przetworzone i musi być opóźnienie.

Racja, że na wyjściu transoptora jest ten sygnał daleki od prostokąta - napisałem to trochę innymi słowami, może trochę potocznie - dla ludzi niekoniecznie będących elektronikami:-)

Zwróć jeszcze uwagę, że sam początek naszej transmisji (bo jest to bardzo prosta transmisja w gruncie rzeczy) zaczyna się od razu cyfrowo. W sumie można by przyjąć, że ruch myszy po blacie biurka jest analogowy, a naszym przetwornikiem analogowo-cyfrowym są tarcze na rolkach. Mysz przesuwamy o odległość "analogowo". Analogowa jest wartość odległości i prędkości przesuwu myszy. Czyli  w transmisji przesyłamy dwie wartości analogowe: odległość i prędkość. Ten analogowy sygnał zamieniamy na cyfrowy tarczami na rolkach, które przesłaniają i odsłaniają fototranzystor oświetlony diodą led - dzięki temu generujemy już nasze zera i jedynki. Sygnał ten jest nieładny, więc go później obrabiamy jeszcze, ale już w tym miejscu wiemy jaki ciąg zer i jedynek otrzymamy na końcu. Jest to już więc dla nas informacja cyfrowa. Zawiera odległość w postaci ilości impulsów oraz prędkość w postaci częstotliwości naszego sygnału. Kierunek jak napisałeś jest ustalany za pomocą par sygnałów.

Nie wiem czy Atari liczy tylko zbocza. Możliwe, że Atari po prostu próbkuje z określoną częstotliwością te linie i robi sobie z tego ciągi zer i jedynek, które już łatwo przekształcić na ruch. Co więcej robi to raczej sterownikiem programowo, bo przecież to zwykłe wejścia cyfrowe jak do joysticka (z resztą te same) i nie ma tam specjalizowanego układu jak np. w myszy PS2. W transmisjach z ramkami jak w PS2 musi być przesłana odległość, prędkość ruchu i kierunek, ale w Atari można przecież bezpośrednio po wystąpieniu każdej pary ruchu w określonym kierunku przesunąć po prostu kursor od razu. Nie potrzeba obliczać o ile i z jaką prędkością. Wystarczy reakcja od razu. W sumie też ciekawi mnie to w jaki sposób Atari to robi, może ktoś napisze. Ja się skłaniam do wersji z próbkowaniem, ponieważ wiem z testów które przeprowadzałem, że jak za szybko się przesyła dane z myszy, to Atari nie nadąża i się gubi. Gdyby był jakiś kawałek elektroniki liczącej wszystkie zbocza, generującej przerwanie i zbierającej dane w jakimś buforze (jak przy PS2), to Atari by się nie gubiło tylko najwyżej robiło by opóźnienia.

No a z tą prędkością atmegi to na prawdę nie przesadzajmy, przecież ona nie ma nie wiadomo jakiej roboty przy przetworzeniu ruchu myszy. Atmega umie poważniejsze rzeczy robić. No i poza tym tak jak wcześniej pisałem na PIC-u było to samo, na niektórych programach działało mizernie, a na tym, który zalinkowałem działa wszystko bez problemu.

Ja z kolei podobny interfejs zrobiłem do pada NES/SNES. Opisałem w tym wątku:
http://www.atari.org.pl/forum/viewtopic.php?id=14670
I mam tam transmisję odczytującą pady NES/SNES - przy czym zachowałem częstotliwość transmisji taką jaka była w specyfikacji, później przetwarzam sobie zebrane dane dokładając różne własne funkcje i na koniec wystawiam odpowiednie stany joysticka. W zasadzie bardzo podobna robota jak przy interfejsie myszy. U mnie czas jaki upływa od momentu odczytu danych do wystawienia sygnałów joysticka liczy się w co najwyżej mikrosekundach, stosuję celowe opóźnienia około 10 milisekund co ramkę w transmisji, żeby zachować zgodność z protokołem NES/SNES, żeby mieć pewność że interfejs zadziała z każdym wynalazkiem (np. pady bezprzewodowe itp.). Reakcja na ruch pada w grach jest natychmiastowa, bez najmniejszego opóźnienia. Okres próbkowania i podawania sygnału joysticka wynosi u mnie właśnie tych 10 milisekund. Czyli jak dasz radę, to w ciągu sekundy możesz wykonać 100 różnych ruchów padem i wszystkie zostaną kolejno w ciągu tej jednej sekundy przesłane do portu joysticka. Przy czym każdy z tych 100 ruchów może się składać z kombinacji kilku różnych przycisków.

Edit: @_tzok_: Tak w ogóle zrobiliśmy straszny offtop, proponuję wrócić do tematu scandoublerów, który też czytam z zaciekawieniem:-)

Taaa... XRGB mini Framemeister. Niecałe 1500zł... do 1k USD jeszcze mu daleko.

Nikt nie pisał o żadnej modulacji. Jak działa sam enkoder, to wiemy, ja się tylko zastanawiałem nad tym jak przetwarza sobie te dane Atari: czy czeka na zbocza i wywołuje jakieś przerwanie, czy próbkuje stan wejść z określoną częstotliwością żeby odczytywać to co nadchodzi z enkoderów myszy. Ja z obserwacji tego co widzę wnioskowałem, że raczej jest realizowana ta druga opcja, ale mogę się mylić, bo tego nie wiem, tylko sobie gdybam.

Wiadomo. :) Zrzut jest w poniższym pliku. Pochodzi z archiwum Steem SSE.

W repozytorium Steem SSE jest już zdezasemblowany zrzut i mapa pamięci, w dodatku z komentarzami.