26

Odp: Chińskie scandoublery

Nie zamierzam się sprzeczać, jednak na swoją obronę przedstawię schemat myszki STM-1:
https://obrazki.elektroda.pl/7736301000_1515182489_thumb.jpg

W moim rozumieniu to jest układ analogowy... cztery analogowe komparatory (LM339), kilka rezystorów, ani jednej bramki logicznej. Owszem sygnałem wyjściowym są impulsy prostokątne, ale nie ma żadnego przetwarzania danych, formowania ramek, zegara. Układ praktycznie nie wprowadza opóźnień, bo nie przetwarza sygnału. Impulsy mają różna szerokość. Natomiast w część cyfrową po stronie Atari nie wnikałem.

Atari 1040STE (TOS 1.62/2.06 UK, 4MB RAM, DDD HD64/Megafile 60, SF314, Gotek HxC)

27

Odp: Chińskie scandoublery

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.

Ostatnio edytowany przez Mq (2018-01-05 21:50:05)

28

Odp: Chińskie scandoublery

Na wyjściu transoptorów szczelinowych jest coś co bardziej przypomina sinus niż prostokąt, dopiero komparatory formują z tego prostokąt, wyznaczając próg odcięcia (bardzo analogowy próg - konkretne napięcie). Ten przebieg prostokątny ciężko nazwać transmisją cyfrową, to po prostu przebieg prostokątny o zmiennej częstotliwości. W transmisji cyfrowej częstotliwość zazwyczaj jest stała. Tu nie są przesyłane żadne bity. To nie jest PWM, ani PDM...

Ciekawe czy dla Atari szerokość tych impulsów ma znaczenie? O ile odczyt nie jest realizowany przez przetwornik u=f(f) i trafia na ADC, wystarczy generować sygnał PDM (łatwiejszy do generowania, ze względu na stałą szerokość impulsów, a tylko różny czas przerwy). Zapewne "logika" patrzy tylko na zbocze narastające i przesunięcie fazowe pomiędzy dwoma sygnałami z pary.

ATMega wcale taka szybka nie jest, robiłem kiedyś na niej (328P @ 16MHz) generator sekwencji cyfrowych, a dokładnie to symulator sygnału czujnika położenia wału korbowego w silniku spalinowym - czyli coś bardzo podobnego, ale tylko jeden czujnik i szału z szybkością nie było. Oczywiście można stosować jakieś triki w stylu użycia SPI do generowania impulsów - wtedy jest dużo szybciej.

Zmierzam do tego, że każde przetwarzanie sygnału trwa, każda transmisja cyfrowa również.

Myszka PS/2 standardowo wysyła 100 ramek na sekundę, każda ramka to 3 bajty danych. Do każdego bajtu dochodzi nagłówek i stopka w ilości 3 bitów (czyli ramka ma 33 bity). Transmisja szeregowa, synchroniczna z zegarem 10kHz (czyli 5000bps). Zatem samo opóźnienie transmisji musi wynieść co najmniej 6,6ms.

P.S.
Zarówno PIC jak i ATMega to 8-bitowe procesory RISC, przy tym samym zegarze mają podobną wydajność... tyle, że PICe zwykle programowało się w assemblerze, a AVRy w C albo nawet C++ (ich assembler raczej nie zachęca do pisania w nim).

Ostatnio edytowany przez _tzok_ (2018-01-06 00:27:36)

Atari 1040STE (TOS 1.62/2.06 UK, 4MB RAM, DDD HD64/Megafile 60, SF314, Gotek HxC)

29

Odp: Chińskie scandoublery

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:-)

Ostatnio edytowany przez Mq (2018-01-05 23:44:32)

30

Odp: Chińskie scandoublery

zieffff, a tak szczerze, to jest jakiś nawet taki za 1k usd, na którym scrole nie będą szarpały, Lodziu pokazywał coś kiedyś takiego....

Główną przyczyną rozwodów jest małżeństwo.

31

Odp: Chińskie scandoublery

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

Atari 1040STE (TOS 1.62/2.06 UK, 4MB RAM, DDD HD64/Megafile 60, SF314, Gotek HxC)

32

Odp: Chińskie scandoublery

Skoro juz o tej myszcze to dziala to na tej zasadzie (nie jest to zadna modulacja) https://en.wikipedia.org/wiki/Rotary_en … ry_encoder

"tatusiu zobacz, narysowałam tobie takie same coś jak na twojej koszulce" 
jmp $e477

33

Odp: Chińskie scandoublery

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.

34

Odp: Chińskie scandoublery

Mq napisał/a:

zastanawiałem nad tym jak przetwarza sobie te dane Atari

Zajmuje się tym mikrokontroler HD6301V1 w klawiaturze. Nie wiadomo co siedzi w jego firmware.

Atari 1040STE (TOS 1.62/2.06 UK, 4MB RAM, DDD HD64/Megafile 60, SF314, Gotek HxC)

35

Odp: Chińskie scandoublery

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

Ostatnio edytowany przez voy (2018-01-07 00:57:46)

Post's attachments

HD6301V1ST.img 4 kb, liczba pobrań: 9 (od 2018-01-07) 

Tylko zalogowani mogą pobierać załączniki.
Powszechnie wiadomo, że kamień potrafi myśleć. Na tym fakcie opiera się cała elektronika.

36

Odp: Chińskie scandoublery

...no to jeszcze ktoś to zdeasembluje i już prawie będzie wiadomo co tam siedzi wink

Atari 1040STE (TOS 1.62/2.06 UK, 4MB RAM, DDD HD64/Megafile 60, SF314, Gotek HxC)

37

Odp: Chińskie scandoublery

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

Post's attachments

Atari ST 6301 RAM map.txt 3.88 kb, liczba pobrań: 14 (od 2018-01-07) 

Atari ST 6301 Rom disassemby commented.txt 56.19 kb, liczba pobrań: 12 (od 2018-01-07) 

Tylko zalogowani mogą pobierać załączniki.

38

Odp: Chińskie scandoublery

Coś się ruszyło w sprawie Lotharkowego scan-doublera - widziałem filmiki, wygląda to obiecująco. Ciekawe tylko jak będzie z ceną. Bliżej chińszczyzny czy framemeistera...

Atari 1040STE (TOS 1.62/2.06 UK, 4MB RAM, DDD HD64/Megafile 60, SF314, Gotek HxC)