Jeżeli raz Ci się udało coś uruchomić, a innym razem tego samego nie udało się i masz błędy takie jak opisujesz, to może być wina firmware FujiNetu. Wersja 1.2 łaczy się za pośrednictwem protokoło UDP i ma tendencję do błędów transmisji w zależności od jakości połączenia, a protokół ten nie kontroluje niepoprawnie przesłanych ramek i nie ponawia ich wysyłania.

Zaktualizuj sobie wersję firmware FujiNet, od wersji 1.3 zrobiono bardzo poważną poprawkę, która umożliwia łączenie się po protokole TCP zamiast UDP i wszystkie problemy transmisji znikają jak ręką odjął. Zwłaszcza zauważalne jest to przy połączeniach internetowych przez sieci komórkowe, ale nie tylko.

Wiesz, ja testowałem sobie te częstotliwości autofire i uznałem że nie ma sensu ich zmieniać, bo to więcej przeszkadza niż pomaga. Ale zrób sobie własne testy najlepiej jak to poskładasz w jakiś prototyp, to sam zobaczysz i uznasz co tam będziesz chciał.

To co mówi @mono, to ja jestem zwolennikiem takiego właśnie autofire, że pod przyciskiem jest autofire, a nie włączany na stałe przełącznikiem. Tak dokładnie jak działają te przyciski turbo, to w (S)NESctrl jest zrealizowany pod osobnym przyciskiem autofire, i pod osobnym przyciskiem tryb decathlonowy. Czyli działa tylko jak się trzyma przycisk. Podobne rozwiązanie z tego co wiem chyba jest zastosowane w larkowym JoyCart'cie.

O opcji decathlonowej wspomniałem tylko przy okazji, bo ja akurat coś takiego kiedyś sobie zrobiłem. Chodziło o to, że (S)NESctrl służył do podłączenia padów od NES-a/SNES-a do Atari, a na takim padzie z krzyżakiem za bardzo nie da się grać w Decathlona. Sama gra nie robi się bezsensowna, bo pomimo że siłę mamy z automatu pod jednym przyciskiem, to jeszcze w grach tego typu trzeba w odpowiednim momencie wciskać i puszczać fire, więc powstają różnice w wynikach, spalone skoki/rzuty, przewrócone płotki itd.

Odwrotnie: jak jest wciśnięty fire2(fire3), to wtedy pokazuje 228. Po to właśnie jest ten rezystor podciągający do plusa zasilania, żeby fire2(fire3) działał na zwarcie do masy, tak samo jak pozostałe styki w joysticku i podstawowy fire1. Defaultowo wejście potencjometryczne jest ściągane do masy, dlatego żeby bez przeróbek mieć tam fire, to trzeba by było przyciskiem zwierać to wejście do plusa zasilania a nie do masy. Nie było by takie rozwiązanie jednak zgodne z tym stosowanym od lat w Amidze, a po drugie tak się nie robi, bo nie powinno występować napięcie zasilania na przyciskach żadnych, lepiej jeśli zwiera się przyciskami wszystko zawsze do masy. Tak że rezystor o którym mowa jest rezystorem podciągającym i ma za zadanie odwracać nam sytuację defaultowo nadając potencjał plusa zasilania wejściu potencjometrycznemu.

Jak się podciągnie do plusa rezystorem, to paddle pokazuje wartość 2/3 zazwyczaj, a czasami 4 może pokazać nawet. Przy czym nie zależy to od wartości tego rezystora, tylko od egzemplarza Atari (z moich obserwacji). Ten rezystor nadaje potencjał wejściu potencjometrycznemu, a na nim samym nie występuje spadek napięcia. Napięcie przed i za rezystorem jest takie samo.

Wartości wskazywane przez paddle przy różnych rozwiązaniach zgodnych z Joy2B+ z tego co zaobserwowałem doświadczalnie, wahają się nieznacznie przy różnych egzemplarzach Atari. W rozwiązaniach "mechanicznych" występuje dodatkowo często problem śniedziejących styków i jak rośnie przez to opór na przycisku fire, to z kolei po wciśnięciu tego fire paddle nie pokazuje 228/229, tylko mniejsze wartości. Połączenie od plusa zasilania poprzez rezystor podciągający dalej przez przycisk fire do masy, stanowi dzielnik napięcia. I teraz jeśli rezystancja jakaś się pojawia na samym przycisku, to im mniejszy mamy ten rezystor podciągający, tym bardziej rezystancja przycisku ma wpływ na zmianę liczby na mniejszą z 228/229. Więc chociażby z tego powodu również warto dawać większy ten rezystor.

Biorąc też pod uwagę powyższe rozważania, warto odpowiednio oprogramowywać drugi i trzeci fire w grach tak, żeby zniwelować wpływ rodzaju rozwiązania w różnych joystickach na sposób działania samej gry. Ja zalecam oprogramowywać to tak, żeby interpretację fire przyjmować na jakiejś bezpiecznej granicy. Czyli nie sprawdzać np. czy jest 228, albo czy jest 2/3, tylko podzielić ten zakres np. na pół. Generalnie bierzemy wartość paddle i tesujemy sobie jako fire jeden ze starszych bitów, np. 128, albo 64, albo 32. I od tego bitu uzależniamy nasz wynik odczytu i interpretację czy przycisk jest wciśnięty czy odpuszczony.

Te rezystory podciągające daj 4k7 na przykład. Nie rozumiem dlaczego ktoś wymyślił tam 330R i płynie tamtędy cały czas prąd bez sensu.

Ciekawe czy UAV robi coś ekstra dodatkowo, czy to po prostu zaleta puszczenia osobno lumy i chromy?

A te francuskie RGB, to może by się dało odtworzyć schemacik jakoś? Ciekawi mnie jak to jest zrobione, czy wymaga jakichś specjalistycznych chipów?

Paczka dotarła. Wszystko świetnie zapakowane, polecam serdecznie zakupy u Javalonde! :-) Testowanie musi zaczekać, bo robota...

O, dzięki x_angel !
Przyda się to co wrzuciłeś.

Ja najbardziej lubię zawsze s-video w tych starych sprzętach, więc chyba właśnie takie sobie spróbuję sprawić, ale zobaczymy co z tego będzie, jeszcze nie zaglądałem w schematy co tam w ogóle siedzi, jaka jest konstrukcja, ani jakie są gotowe rozwiązania, bo może nie ma co koła od nowa wynajdować. To podobnie jak z kartridżami, mógłbym projektować własne, ale widzę że już tego jest trochę w internetach, więc może zamówię płytki pod jakieś gotowce. Jak by co to będę dawał znać.

Gratulacje naprawionego sprzętu!

A SALT sprawdza rozszerzoną?

lopez, ja już się wkręciłem i przeczytałem dzisiaj cały internet o modach video i o konstrukcjach kartridży, więc będzie dłubane:-) Mam już też plan na naprawę dziur w obudowie, tak że będzie zabawa:-) Taki mam pomysł, żeby sobie odrestaurować to cudo tak, żeby wyglądało jak nówka, a śmigało lepiej niż nówka. Pobawię się też na pewno w konstrukcje jakichś własnych kartridży. Jak będę miał jakieś efekty, to na pewno podzielę się na forum i udostępnię co wymyślę. Tak że sprzęcik idzie chyba w dobre ręce.

Wysłałem PW.