Jak już będziesz programował tą Atmegę, to koniecznie poszukaj jak tam ustawić fusebity. Pamiętam, że kiedyś było to opisane na stronie SIO2SD, ale dziś już chyba tej strony nie ma, bo nie mogę znaleźć... Pamiętam natomiast na pewno, że w starszych wersjach SIO2SD fusebity były źle ustawiane, co powodowało właśnie wysypywanie się od czasu do czasu Atmegi. Po aktualizacji oprogramowania do najświeższej wersji ważne było ustawienie tych fusebitów odpowiednio i dopiero wtedy można się cieszyć bezawaryjną pracą. Objaw który pokazałeś może wskazywać rzeczywiście na wysypany soft w Atmedze.
Aha, z tego co piszesz, to nie masz doświadczenia z mikrokontrolerami Atmela, więc bardzo uważaj co robisz programując fusebity, bo jak zrobisz to źle, to możesz sobie skutecznie zablokować mikrokontroler, którego już samodzielnie za pomocą tego samego programatora nie odblokujesz...

@Jacques: mam taką stację. Ja z kolei mam sytuację odwrotną, bo potrzebowałem ją zamontować w STFM, więc delikatnie wymontowałem ten pryzmacik ukośny z wierzchu, bo w STFM przeszkadzał. Ale mam go, a zdemontowałem delikatnie, więc można go bez problemu z powrotem założyć i przywrócić całość do oryginału.
Jeżeli Twoja stacja jest w pełni sprawna (bo moja jest), i pokryjesz koszty wysyłek, to mogę się z Tobą zamienić 1:1. Jak chcesz, to zapraszam na PW.

Edit: zastanowiłem się i mogę również sprzedać tą stację jak byś wolał. Wysłałem ofertę na PW.

Ja się przyłączę do pytania: mnie z kolei interesuje walor użytkowy w stosunku do SIO2SD - czy SDRIVE jest wygodniejszy/mniej wygodny w wypadku chęci pogrania sobie po prostu w gierki? Pytam, bo u nas w kraju SIO2SD zdominował inne rozwiązania, ale mamy kombajn z milionem opcji, których nikt chcący sobie tylko pograć nie używa i one przeszkadzają trochę szczerze mówiąc. W wypadku SDRIVE (którego nie mam, ale chciałem kiedyś sobie zrobić) wydaje się, że jest dużo prościej, szybciej, wygodniej i poręczniej. Czy rzeczywiście tak jest?

Tak, trzeba wiercić od zewnątrz i nie cisnąć mocno, tylko z czuciem. Poza tym polecam wiercić najpierw cieniutkim wiertłem np. 1mm, wtedy można precyzyjnie bardzo równo kilka otworków w rzędzie zrobić. Później przy poszerzaniu grubsze wiertło idzie ładnie w tym samym miejscu, a też robiąc jeszcze kroki pośrednie coraz grubszym wiertłem można jeszcze delikatnie poprawić geometrię otworów względem siebie oraz samego otworu. Ostatnie wiertło powinno być dokładnie o takiej grubości jak potrzeba, żeby nic nie piłować. Na koniec na wierzchu zostaje delikatny jakby wiór dookoła, który ścinamy czubkiem noża do tapet, ale nie kroimy tego mocno, tylko też delikatnie wkoło zrównujemy z powierzchnią. Taki otwór jak się postaramy, to wygląda jak z fabryki. Piszę, bo sam tak robię, no i wypracowałem sobie taką technikę z czasem. Nie zawsze się uda, ale jak się cierpliwie podejdzie do tematu, to efekt końcowy jest warty tego całego zachodu.

Z kolei otwory prostokątne jak np. pod kartę SD robię tak, że wiercę kilka otworów obok siebie, środek wycinam nożykiem, a później dopiłowuję precyzyjnie otwór malutkimi iglakami. Jak już jest mniej-więcej dobry i równy kształt, to później jednak lepiej nożykiem do tapet niż pilnikiem. Po pilniku zostają rysy i powierzchnia nie jest idealnie gładka. Najładniejsza powierzchnia wychodzi jak się ją cieniutkimi wiórami skrawa takim właśnie nożykiem. Trzeba trochę wprawy, cierpliwości i precyzji, ale polecam wypróbować również taką technikę.

Jak do peceta, to pewnie to joystick analogowy, więc się do Atari nie nada.

Wg mnie to jest normalne zachowanie z tą kontrolką. W moim rozwiązaniu podpięcia Goteka razem z FDD na wewnętrznej taśmie mam dokładnie taki sam efekt po przełączeniu AB/BA. Przejrzałem schematy i sygnał BD0SEL to jest właśnie sygnał który służy tylko i wyłącznie do sterowania diodą FDD w klawiaturze. I tak jak zauważyłeś jest to zbuforowany sygnał SEL0, więc jak najbardziej poprawnie świeci ta dioda po zamianie AB/BA.

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

@_tzok_: nie zrozum mnie źle, bo mam trochę wyrzuty, że akurat ostatnio się spotykamy w prawie każdym wątku - to zbieg okoliczności, bo akurat w tym samym czasie mamy nasilenie zainteresowania ST:-) Stąd cenię sobie pozytywnie to, że się spotykamy, i też czerpię trochę z Twoich postów ciekawej wiedzy, ale w tym konkretnym przypadku nie zgodzę się z Tobą:-)

Atmega w tym projekcie jest taktowana zegarem 4MHz, więc dobrze napisany program jest bez problemu w stanie przetworzyć dane PS2 i wysłać je do Atari szybciej i częściej niż Atari jest w stanie je przetwarzać. Oryginalna mysz od Atari nie jest analogowa, jak z resztą żadna mysz kulkowa. Wszystkie myszy działają w ten sam sposób: ruch kulki przekładają na rolki, a rolki obracają tarczami na których otwory zasłaniając i odsłaniając transoptor szczelinowy generują ciąg impulsów. Pomyśl: jaką częstotliwość jesteś w stanie wygenerować w ten sposób ręcznie przesuwając mysz? Bardzo małą w stosunku do częstotliwości o których mówimy. Na oko może maksymalnie kilkadziesiąt Hz?

W tym aspekcie akurat problem jest dokładnie odwrotny: trzeba specjalnie mocno spowalniać częstotliwość impulsów podawanych do Atari, bo nie nadąża on ich sczytywać i następują błędy spowodowane gubieniem tych impulsów przez Atari. Dlatego pisałem o tym, że szukałem takiego wsadu do PIC-a, który będzie działał przyzwoicie na Atari i Amidze, bo Amiga wielokrotnie szybciej potrafi sczytywać impulsy niż Atari i duża część interfejsów działających poprawnie na Amidze nie działa poprawnie na Atari po odpowiedniej zamianie pinów portu myszy. Problem ten opisał dokładnie w jakimś wątku na AOL Kuba Husak (można poszukać). Pierwotnie żeby użyć na Atari interfejsu, który działał mi na Amidze spowalniałem nieco zegar PIC-a do wartości, przy której Atari potrafiło sobie poradzić z impulsami, a zarazem transmisja w protokole PS2 pozostawała w zakresie częstotliwości podawanych przez specyfikację.

Programuję atmele i znam się na tym, ale nie chciało mi się robić kolejnego interfejsu do myszy, skoro jest ileś tam gotowców. Niemniej zgłębiłem temat i wiem, że błędy jakie popełniają programiści dotyczą niewłaściwego taktowania obu transmisji. Trzeba po drodze z odpowiednią częstotliwością komunikować się z PS2, zapisywać dane w jakiś tymczasowy bufor, przetworzyć je i wysłać z inną częstotliwością do Atari. Nie pamiętam częstotliwości, ale rzędy wielkości są takie, że komunikacja PS2 to jakieś kilkoherce, komunikacja z Atari to dziesiątki herców, a przetwarzać na atmedze możemy to wszystko w megahercach, więc wszystko powinno się bez problemu "zmieścić pomiędzy transmisjami" i być niezauważalne. Tak jak pisałem:  testowałem kilka wsadów adapterów i nie ma kompletnie żadnych lagów w dobrze napisanych programach.

A o źródło tego interfejsu na atmedze zapytałem, bo tak jak mówię wolę atmela, bo go dużo programuję, a PIC już dziś jest przestarzały i trudniej dostępny. Ogólnie fajny projekt, a z tego co piszesz o tych lagach, to pewnie wymagał by dopracowania sam program.
Ja mam interfejs wg tych opisów:
http://eab.abime.net/showthread.php?t=66443
Wersja firmware 1.3 jest odpowiednia i działa zarówno z Atari jak i z Amigą. Nie ma żadnych lagów ani innych przypadłości. Działa idealnie.

Przepraszam za odbiegnięcie od tematu wątku...

Jeśli w A1200 masz oprogramowanie cortex, to w ogóle się nie zastanawiaj, tylko przejdź od razu na FF. Skoro masz HxC, to znasz go już dobrze, a FF ma taki tryb, w którym pracuje niemal identycznie jak HxC i wykorzystuje te same pliki co HxC. Poczytasz o tym w dokumentacji w linku, który podał _tzok_ powyżej. FF możesz też używać na nieprzerobionym Goteku z tym standardowym wyświetlaczem, więc nie masz na co czekać. Na Amidze w cortex są błędy powodujące, że rzadko kiedy działa poprawnie zapis na dyskietki. Ponadto cortex ma też błędy w timingach komunikacji z pendrivem, co objawia się z kolei tym, że bardzo duża część pendrive-ów w ogóle nie jest widzianych i nie działa. Na FF działają mi wszystkie pendrivy jakie testowałem.

Sam nie drukuję na drukarkach 3D, ale widziałem jak się to robi, widziałem też trochę takich wydruków. Kwestie wytrzymałościowe, to przewidzenie różnych rzeczy na etapie projektu: stosuje się wsporniki, pogrubienia, kratownice itp. Są też różne materiały do druku 3D - jedne tworzywa są bardziej elastyczne i wytrzymałe na zgięcia, inne natomiast twardsze i mocniejsze, ale za to bardziej podatne na pęknięcia czy skruszenia. Ogólnie szeroki temat i trochę trzeba umieć projektować, dobierać materiały, przekroje itd. Niektórym się wydaje, że wystarczy se narysować byle co na kompie i już jedzie na drukarkę, bo widział na filmie w youtubie, że drukarka robi wszystko sama:-)
Wg mnie są dwa aspekty, które trochę deplasują produkcje z drukarek 3D. Po pierwsze wysoki koszt wydruku większych rzeczy, a po drugie jakość tego wydruku, który jednak nigdy nie wygląda i nie będzie jeszcze długo wyglądał jak plastik z formy. Po prostu widać te warstwy wydruku i nie jest to idealne.

@Yerzmyey: ja wiem, że są takie różne obudowy, jest też masa projektów gotowych na drukarki 3D w necie za free. Oczywiście taki wydruk też kosztuje, czy tam taka obudowa, ale właśnie o to mi chodziło o czym napisałeś. Nie wertowałem wszystkiego, żeby znaleźć cenę, ale takiego rzędu się spodziewałem jak napisałeś. 470zł. Czyli ktoś kasuje spore siano za to, że wrzuci emulator na gotowy minikomputerek i zapakuje to w kawałek plastiku. Nie powiem: ładne to i może jest, ale niewarte takiej ceny wg mnie.

To po co taka klawiatura? Przecież to suchar jest...