atarionline.pl
atarionline.pl Atari
Login:
Hasło:
Zapamiętaj mnie
Translate to RSS RSS
Imprezy retro 4-5 marca z 2017-02-25 23:53 (13)
Wywiad z Danielem „Arctusem” Kowalskim z 2017-02-19 23:36 (25)
Odkurzone gry Gandalfa z 2017-02-16 23:33 (3)
Jak zostałem atarowcem z 2017-02-12 00:16 (93)
10 linijek kodu – konkurs BASIC Tenliners 2017 z 2017-02-08 23:45 (3)
Nowe gierki: Kaverns of Kfest, Robbo SWS-14 z 2017-02-05 23:46 (1)
GRAWITACJA – to przyciąga! :) z 2017-02-01 22:33 (20)
Nowy PIXEL (nr 23) z 2017-01-30 23:57 (25)
Nowy MADS z 2017-01-28 13:17 (2)
Retro w Szczecinku z 2017-01-24 21:06 (13)
Rick i inne aktualności z 2017-01-21 19:37 (48)
KATOD - powiew świeżości w muzyce elektronicznej z 2017-01-17 23:05 (5)
Gry ze starych kaset MatoSimiego z 2017-01-12 23:48 (11)
Jak się robi design z 2017-01-04 19:55 (28)
Nowy Rok, nowe otwarcie! z 2017-01-01 13:55 (8)
Wyniki Kaz Kompo 2015 z 2016-12-29 16:35 (46)
Seria "Secretum Labyrinth" i zapowiedzi kolejnych gier Video 61 z 2016-12-28 13:54 (1)
Prezenty świąteczne: Jim Slide XL i Fairlight! z 2016-12-26 16:17 (7)
Świątecznie... z 2016-12-24 15:40 (7)
Zapowiedzi książkowe Retronics z 2016-12-22 19:18 (20)
«« nowszestarsze »»

Pomocnik/Helper
Gry/Games

Katalog gier

Opisy gier
Frogs opisał Xeen (0)
Choplifter! opisał Urborg (0)
Joust opisał Urborg (16)
Commando opisał Urborg (35)
Mario Bros opisał Urborg (13)
Xenophobe opisał Urborg (34)
Robbo Forever opisał tbxx (16)
Kolony 2106 opisał tbxx (0)
Archon II: Adept opisał Urborg/TDC (9)
Spitfire Ace/Hellcat Ace opisał Farscape (7)
Wyspa opisał Kaz (9)
Archon opisał Urborg/TDC (16)
The Last Starfighter opisał TDC (30)
Dwie Wieże opisał Muffy (17)
Basil The Great Mouse Detective opisał Charlie Cherry (37)
Inny Świat opisał Charlie Cherry (17)
Inspektor opisał Charlie Cherry (19)
Grand Prix Simulator opisał Charlie Cherry (16)
Rescue On Fractalus opisał Kaz (17)
Stranded opisał Kaz (9)
«« nowszestarsze »»

Użytki/Utils
Wewnętrzne/Internals



   Nowinki tworzone dzięki CuteNews
Jak się robi design
Opiszę tutaj pokrótce, w jaki sposób w słynnych un-demach MECów, został zakodowany design. Nie będę wchodził w subiektywne niuanse w stylu - czemu muzyka jest taka dziwna, albo brakuje sensownej grafiki. Opiszę, jak został zaprojektowany i zaimplementowany cały silnik dema, by móc takie wygibasy obsługiwać. Dla niektórych może nie będzie to nic odkrywczego (wszak nie jest to niewiadomo jaki wynalazek). Dla tych osób może to będzie jako ciekawostka przyrodnicza lub potwierdzenie słuszności koncepcji, jeśli sami coś podobnego stosują. Inni, może faktycznie się zainspirują.

Próby zsynchronizowania ze sobą obrazu i dźwięku są tak samo stare, jak dema. W przypadku naszych dem, na dobre temat się pojawił w pierwszym demie z serii UN - unplugged. Wówczas to, podczas kombinowania, w jaki wygodny sposób przełączać efekty wpadłem na pomysł, by rozdzielić logikę efektu od logiki przełączania. W unplugged mechanizm co prawda ułomny jest bardzo, ale jednak kierunek już został wytyczony. Z każdą kolejną produkcją mechanizm był rozwijany, aż do finalnej postaci w Undesigned.

By móc coś napisać, najpierw trzeba wiedzieć co - czyli koncepcja.

Sam pomysł, jak już na niego wpadłem wydawał się prosty. Każdy efekt ma swój kod, swoją logikę, która sprawia, że w skrócie pisząc - efekt działa. Czy to będzie zwykły scroll, czy ciężkiego kalibru 3D - zasada działania jest zawsze taka sama. Efekt ma główną pętlę, podczas której (w dużym skrócie) najpierw efekt jest renderowany, potem następuje zmiana parametrów. I tak w kółko.





Jednocześnie gra muzyka, patterny przemijają. Wypadało by wiedzieć, kiedy bieżący efekt ma się zakończyć. Gdy efekt w całym demie pojawia się raz, sprawa jest dosyć prosta. Wystarczy na VBlanku liczyć czas (w ten czy inny sposób), i w efekcie w odpowiednim czasie z efektu wyjść. Jednak, gdy kod uruchamiany jest kilka razy, zaczynają się pojawiać nieprzyjemne if-y. W tym momencie do głowy przyszedł mi pomysł banalny - w kodzie efektu trzeba po prostu sprawdzać flagę - wychodzimy już, czy nie? Flaga jest ustawiana przez kod realizujący logikę dema. Na podstawie bieżącego stanu muzyki ustawią ją odpowiednio. W tym momencie efekt uwolnił się od ciągłego sprawdzania muzyki, a sprawdza tylko flagę. Jednocześnie kod designu sprawdza muzykę. Oba kawałki są proste do napisania. Zmiana niby niewielka, ale jak napisałem - umożliwia dwie rzeczy:

  • oddzielenie logiki efektu od logiki designu
  • efekt można łatwo pokazywać i kończyć wiele razy.

    Czyli jest prawie dobrze. Prawie, bo wciąż prawie dwa razy sprawdzać trzeba co robić w temacie designu. Raz - podczas śledzenia muzyki ustawić trzeba odpowiednie flagi, a drugi raz - w samym efekcie flagi trzeba sprawdzać. A co jeśli w samym efekcie by nie sprawdzać flag w ogóle, a cała robota by była robiona przez kod logiki? W tym miejscu właśnie pojawia się koncepcja rodem z Undesigned - 'sloty' (jak je nazwałem). Z technicznego punktu widzenia są to adresy (wektory) umieszczone na stronie zerowej, w których umieszczone są bieżące adresy do kodu renderującego. Co ważne - mogą być puste, i wtedy są nieaktywne. Z logicznego punktu widzenia są to kolejne,
    równolegle uruchamiane efekty. I to jest właśnie ta koncepcja. Jakie są konsekwencje takiego podejścia?

    1. Efekt nigdy nie wie, jak długo będzie wykonywany. Czy to, co właśnie jest renderowane, to będzie ostatnia ramka, czy jeszcze nie.
    2. Efekt nie może być uciążliwy w (re)inicjalizacji. Seria kilku(nastu) LDA/STA jest dopuszczalna, ale przeliczanie tablic zajmie dużo czasu i flow dema może zakłócić. Zatem jest tylko jedna duża inicjalizacja - na samym początku dema.
    3. Wszystkie efekty muszą się w pamięci zmieścić z całym swoim kodem i danymi jednocześnie. W skrócie - wszystkie w pamięci leżą i czekają na uruchomienie.
    4. Każdy efekt ma swój kawałek strony zerowej tylko dla siebie.
    5. Efekt zastaje ekran w pewnym stanie, i nie może go zniszczyć. Musi dodać tylko swoje rzeczy nie nadpisując tego, co zastał.
    6. Efekt od silnika dema dostaje informację, na którym buforze renderować trzeba (poprzez numer i/lub adres bufora).




    Sport tylko dla twardych - czyli implementacja.

    W demach MECów używany jest player do TMC. Dostępny player udostępnia bieżącą pozycję w patternie*. Pośrednio jest też dostępna pozycja w songu. Jest więc dostępna pełna informacja o bieżącym stanie muzyki. Mając możliwość indeksowania bieżącego stanu dema (a znając bieżącą pozycję w muzyce można mieć możliwość indeksowania), całe flow dema można zdefiniować poprzez odpowiednie tablice - na jakiej pozycji w muzyce co trzeba do slotów wpisać, by engine dema zaczął uruchamiać co trzeba, i całość gotowa :).

    Slotów w Undesigned są 4 (i czasem wszystkie zajęte) W system.scenario_index trzymana jest bieżąca pozycja designu. Wektory slotów są umieszczone bezpośrednio jeden za drugim, a sam numer slotu w tablicy flow.slot jest pomnożony przez 2. Reszta tablic jest chyba wystarczająco czytelna. Sama zmiana efektu następuje poprzez
    zmianę adresu w slocie:



    flow_handler equ *
    ldy system.scenario_index
    lda flow.pattern,y
    cmp system.pattern_position
    bne flow_handler_1
    lda flow.song,y
    cmp system.song_position
    bne flow_handler_1
    ldx flow.slot,y
    lda flow.routine_lo,y
    sta slot0,x
    lda flow.routine_hi,y
    sta slot0+1,x
    iny
    sty system.scenario_index
    flow_handler_1 equ *
    rts



    Samo uruchomienie slota jest już banalne:



    call_slot0 equ *
    lda slot0+1
    beq call_slot0_1
    lda #$00
    sta current_slot
    jmp (slot0)
    call_slot0_1 equ *
    rts



    W current_slot jest bieżący numer slota. Czasem się przy pewnych machinacjach, by efekt wiedział, na którym slocie siedzi.

    *Na ST jest jeszcze fajniej, bo player Maxymisera ma komendę Z, której parametr (8 bitów bez znaku) jest przez player udostępniana programowi. Nie trzeba zatem ręcznie czekać na pozycję w songu, tylko bezpośrednio z muzyki wydawać komendy, co ma właśnie się wydarzyć. Jeżeli player jest do d..., to trzeba posiłkować się licznikami na vblanku lub jakimiś innymi protezami.

    Parę słów mądrych na koniec.

    Nasz świat tak jest ułożony, że proste rzeczy mają swoje naukowe, bardzo mądre czasem nazwy. Nie inaczej jest i tutaj. W temacie koncepcji i terminologii, mamy tutaj następujące rzeczy:

    1. Programowanie obiektowe. Dokładniej - polimorfizm oraz hermetyzacja. Każdy efekt ma dokładnie taki sam interface (w ten sam sposób dostaje informację, gdzie ma renderować) oraz przed silnikiem dema chowa swoje szczegóły implementacji. Silnik potrzebuje tylko dwóch informacji - adres kodu inicjalizującego (na samym początku, jeszcze przed uruchomieniem muzyki) oraz adres kodu renderującego. Budowa dema jest więc fajnym przykładem, że programowania obiektowego nie używamy pisząc w Javie/C++/... tylko pisząc w odpowiedni sposób niezależnie od języka.

    2. Wielozadaniowość. Silnik dema uruchamia kilka efektów na ramkę, więc jest tutaj używana wielozadaniowość. Ze względu na pewne założenia kodu (i jego pełną kontrolę) i architektury jest to wersja bez wywłaszczenia.

    I to w zasadzie tyle, co chciałem o designie napisać. Na XE już wiecie jak się to robi :). Na ST - pomysł jest analogiczny, jednak całość jest sterowana Z kodami, a adres jest przekazywany poprzez rejestr procesora.

    2017-01-04 19:55 by Rafał "bob_er" Ciepiela
    komentarzy: 28
  • pin @2017-01-04 22:55:05
    ogólnie dzięki Panowie za demka spod znaku "UN". Ciekawe "inne" pomysły, dobry design, coś się dzieje. Oby tak dalej!
    xeen @2017-01-05 09:25:14
    Ogólnie mam bardzo podobny schemat postępowania tyle, że mam dwa sloty i zawsze w nich zakładam efekt główny i efekt wspomagający. Czasem efekt wspomagający służy do wyjścia/wejścia (np. najprostszy fade out) lub do przeczekania np. na rozpakowanie jako efekt który jest relatywnie lekki. Mam wrażenie, że podobnie robi scena c64 z efektami wspomagającymi / rysunkami bo tam dochodzi zawsze aspekt dogrywania ze stacji (nie ma bajki w postaci 128 czy tam 320 KB).

    To co muszę dopracować bo zawsze robię to na piechotę to synchro z muzą - teraz jechałem własnym licznikiem i było to słabo utrzymywalne jak muzyk zmienił co nieco. Zresztą nawet zapinając się na konkret jak player taki udostępnia i tak trzeba to utrzymywać przy zmianach muzy (często jakieś błyski są uzależnione od perkusji i chyba wtedy lepiej zapinać się na jakieś qasi shadow'y dla pokeya).


    Punkt 5 mnie mocno zastanawia bo to jednak spore ograniczenie - zwłaszcza jak się jedzie na więcej niż jeden koder. Z drugiej strony takie założenie mocno trzyma ryzy dema i samo z siebie utrzymuje pewną jego spójność.

    Dzięki za artka.
    tebe @2017-01-05 12:10:54
    dobry art :)

    W kwestii playerów Numen poszedł o krok dalej, niezależnie od efektów dźwiękowych player z Numena zabiera co najwyżej linię skaningową obrazu, ma to znaczenie gdy zakodujemy efekty które są na granicy wytrzymałości ramki obrazu.

    Ktoś zakoduje jakiś efekt, działa płynnie, ślicznie, doda muzykę i zaczyna rwać, decyduje się na jakiś szybszy player, rezygnuje z pewnych efektów dźwiękowych bo zajmują za dużo czasu CPU, musi iść na kompromis. Nie raz już tak miałem że kilkaset cykli CPU więcej i potrzebna jest dodatkowa ramka na synchronizację, albo zmieniam sposób synchronizacji zamiast VBL korzystam z VCOUNT ($D40B) i synchro ustawiam gdzieś od środka ramki, będzie mniej widać że "szarpie", coś za coś.

    A gdyby tak móc korzystać z każdego playera msx, móc korzystać z każdych efektów dźwiękowych i cały player zawsze mógł zajmować tyle samo, minimalnie czasu CPU :)

    Numen tak ma bo korzysta z bufora na muzykę, są tam zapisane wartości dla POKEY-a (np. 9 bajtów), player jest wywoływany w konkretnych miejscach dema aby uzupełnić bufor, czyli w takich miejscach gdzie efekt nie obciąża w pełni CPU, gdzie wyświetlane są różne przerywniki.

    Kilkanaście ramek obrazu pozwala wypełnić bufor, tak aby odegrać muzykę przez kilkanaście kolejnych sekund.

    Player nie jest autonomiczny, jest sterowany przez "skrypt" który zaprogramował koder składający demo.
    xxl @2017-01-05 12:52:42
    oby wiecej technicznych artkow :-)
    xeen @2017-01-05 15:05:00
    no to rozumiem, że muzyka zajmuje ok 28KB na minutę w takim Numenie prze jej prekalkulowaniu? To jest dosyć kuszące
    wieczór @2017-01-05 15:38:39
    @xeen: nie oznacza, że cała jest przekalkulowana już na starcie. Kalkulowanie następuje w miarę potrzeb, z tego co zrozumiałem - do określonego bufora. Natomiast samo przekalkulowanie wówczas nie jest krtyczne czasowo i może być wykonywane w wolnych chwilach - przy klasycznym graniu, całe kalkulowanie następnych wartości rejestrów musi zmieścić się w ramce (wraz z innymi rzeczami) i trochę zajmuje. O dwóch replayach na ramkę już nawet nie mówiąc
    xxl @2017-01-05 15:47:12
    prekalkulacja wcale nie musi miescic sie w ramce.
    tebe @2017-01-05 15:54:06
    "player" zapisuje wartości do bufora POKEY-a z pełną mocą CPU w danej chwili, więc wywołań takiego playera w 1 ramce jest do oporu, w zasadzie tyle na ile pozwala aktualnie wyświetlany efekt

    kolejny player, już ten właściwy pobiera z bufora i zapisuje do POKEY-a, on jest już z kolei wywoływany raz na ramkę

    muzykę w formacie MPT można tutaj traktować jak archiwum, spakowane dane, przerobiony player MPT który zamiast do POKEY-a wysyła dane do bufora należy nazwać dekompresorem ;)
    tebe @2017-01-05 15:57:05
    jeśli bufor liczy np. 10KB, 10240 / 9 = 1137 ramek = ~22 sekundy (wartość 9 -> AUDCTL, AUDC1..4, AUDF1..4)
    Polak mały @2017-01-05 16:15:06
    Brawo!!! Wiecej mądrych i edukacyjnych artykułów to krok w kierunku roszerzania wielu manii. Jednocześnie pozbywacie się ELitOmanii. Tak trzymać , jego mać!!!
    xeen @2017-01-05 17:12:14
    wieczór - dałem skrót myślowy. Ja rozmarzyłem się aby sobie zrobić taki prekalk na pełen czas trwania utworu w prodce niezależnej od Numena (licząc of coz raz na ramkę). Zrozumiałem jak to jest robione w Numenie (i przyznam nie wiedziałem o tym - bardzo fajny pomysł).
    Hospes @2017-01-05 19:33:05
    wieczór: ooo taki precalc w wersje ST i YM, gdzie można sobie poszaleć na timerach. Zero ograniczeń, że mi Timer włazi czasowo na ramke;)
    króger @2017-01-05 20:32:23
    bardzo pouczająca dyskusja w komentarzach
    pin @2017-01-05 21:07:48
    ... dość wyjątkowa to sytuacja, faktycznie ;)

    hi Króger!!!
    wieczór @2017-01-05 22:03:59
    @Hospes: nie rozumiesz :) I tak wejdzie i tak wejdzie - timer jest na samym końcu tego procesu :)
    wieczór @2017-01-05 22:11:21
    Przy takim precalcu to dwa czy nawet 3 razy na ramkę to nie problem, bo zajmuje tylko wpisy do rejestrów. Zajmuje chwilkę. Największym problemem jest zawsze odpalenie całej procedury analizującej song, pattern, obwiednię i obliczająca wartości do tych rejestrów. Ile to zajmuje to widać po paskach w xexowym playerze RMT (a on naprawdę jest optymalizowany przy kompilacji). Sam wpis do rejestrów na końcu to jest pikuś. Jak wartości są przygotowane to można szaleć i 4 razy na ramkę. I wszystko się w czasie zmieści (oby tylko zmieściło się w pamięci ;) )
    dhor @2017-01-05 23:18:03
    Ooo, to o to chodzi w demkach UN... A to się człowiek na starość dowiedział :D

    Buforowanie wartości dla pokeya - klawa sprawa. Niemniej, w przypadku chęci grania co ileś przerwań iRQ.. Czy to się da stablicować? (teoretycznie - czemu nie)...

    Ale kto gra na irq :)
    the fender @2017-01-06 13:31:15
    Coder's talk :) To tylko pokazuje jak ogromna jest przepaść ludzi pasjonujących się Atari od ludzi pasjonujących się Atari i rozumiejących jak to działa i jak coś zrobić :)

    Sama dysputa wielce interesująca, oby takich więcej tutaj.
    bob_er @2017-01-07 11:30:32
    Dzięki za miłe słowa. Widać jest popyt na takie rzeczy, to pewnie jeszcze coś napiszę.
    Co do pomysłów w komentarzach:
    1. Tablicowanie pokeya - pomysł fajny, ale IMHO wymaga już przynajmniej 128k RAMu. Efekt (jeśli to nie jest przejście) trwa przynajmniej kilkadziesiąt sekund. Z drugiej strony - nie każde wywołanie playera zmienia wszystkie rejestry pokeya, więc pewnie można coś pokombinować. Pomysł do rozważenia na przyszłość :). Tym bardziej, że chodzi mi po głowie demo, gdzie użyję separacji Antic/CPU dla rozszerzonej pamięci.
    2. Można też łatwiej grać x razy na ramkę. Nie trzeba tutaj IRQ stosować, można DLI użyć. Czasami demo ma stałą DL, więc było by to wtedy łatwe do utrzymania.
    3. Odporność na zmianę muzyki - tego to żadna metoda nie gwarantuje. Choć najbliższe jest rozwiązanie z Maxymisera na ST - Z komenda do sychronizacji. Ból jest wtedy taki, że moduł musi latać w te i wewte pomiędzy muzykiem a koderem - żeby nie stracić już wpisanych Z komend. Normalnie moduł leci od muzyka do kodera. Używanie na XE pozycji w songu i patternie jest dla mnie o tyle wygodne, że design w głowie układam słuchając utworu, czasem nawet kilkadziesiąt razy. Potem w trackerze ustalam, na jakiej pozycji muzyka jest i po prostu te wartości zapisuję w tablicach.
    4. Na ST pomysł z tablicowaniem muzyki nie jest banalny. Muzyka zwykle gra na Timerze C, czasem na VBLANKu. Do tego dochodzą kolejne timery, by obsługiwać buzzery i inne sidy. Naprawdę byś musiał długo grafikę wyświetlać, by wyliczyć wartości dla czasu trwania kolejnego efektu.
    MKM/Lamers @2017-01-07 11:42:02
    bob_er bardzo fajny artek;)

    Ad 4. Na ST/STE podobna technike stosuja niektore grupy ale wymaga to rezygnacji z efektow dzwiekowych na timerach. dlaczego wiec taki zwykly dump rejestrow ym sie czasem oplaca? szczegolnie w efektach fullscreen gdzie caly kod jest docyklowany (hardsync) i tak nie wolno uzywac timerow (bo kod sie sypnie) a kazdy cykl cpu zanim electron beam wejdzie w widoczny na ekranie obszar jest na wage zlota. z tego co wiem taka technike stosowali np dhs czasem.

    PS. az strach mi pisac jak my musielismy walczyc z synchronizacja efekty/muzyka w Polygon Discount gdzie takie Falcon gra MP2 w innym tempie niz orginal na PC... a na emulatorze za to wlaczenie emualcji DSP powoduje ze dzwiek pierdzi i wszystko zwalnia;) ufff to byl koszmar hehe;)
    mrroman @2017-01-07 13:37:09
    bob_er: jeszcze nie czytałe czałego artykułu ale wygląda super :)

    Co do buforowania danych do Pokeya i zapisywania za każdym razym wszystkich rejestrów, to mam taki pomysł. Może po prostu do bufora pisać od razu kod, który pisze do rejestrów (jakieś STA AUDF0, STA AUDC0, RTS) i wykonywać go w danym momencie. Wtedy ten kod piszący do bufora wpisywałby tylko te rozkazy które potrzebuje.
    xxl @2017-01-07 13:45:39
    no ale probujemy zaoszczedzic na buforze a tu nagle oprocz samych danych chcesz tam wsadzic adresy i jeszcze rozkazy... z 9 bajtow zrobi sie 35
    bob_er @2017-01-07 14:21:21
    I taki kod nie będzie wiele szybszy. Wersja max stablicowana zajmie 72-81 cykli (w zależności od układu tablic na stronach) vs 54 cykli (z kodem w buforach). Wychodzi niecałe 20 cykli różnicy.
    0xF @2017-01-07 17:58:56
    Eleganckie rozwiązanie sterowania czterema jednoczesnymi efektami na podstawie pozycji w songu i paternie. Dzięki!
    Konop @2017-01-07 18:55:33
    Można rozważyć kodek RLE w celu ograniczenia ilości pamięci. Całość będzie wolniejsza, ale da znaczny zysk na pamięci.
    bob_er @2017-01-07 21:42:05
    RLE by najwięcej korzyści przyniosło, gdyby kodować osobno każdy kanał oraz AUDCTL. Ewentualnie, system flag bitowych (czy była zmiana czy nie) i strumień bitowy (tzn - z wejścia odczytujemy bitami (np. 4 bity albo 8 bitów), a nie bajtami). To też spowolni odczyt, ale zapis będzie szybszy niż w RLE.
    Vasco/Tristesse @2017-01-08 19:14:22
    O, ja też korzystałem z buforowania muzy - najszybsze trackmo na Atari ;)
    10 GOSUB 10 @2017-01-26 14:56:37
    Dema MECów są brzydkie, brudne i szorstkie i dlatego je lubię.
    nickname
    e-mail / website (opcjonalnie)
    Aktualne tematy
    Reedycja gier (305)
    ostatni: 28-02-2017 13:45, Enjo
    Potrzebujemy Twojego głosu na Ste... (6)
    ostatni: 28-02-2017 10:44, IRATA4
    Moje własne pikselarty (18)
    ostatni: 28-02-2017 06:56, Vidol
    Klawiatura do Atari XEGS (3)
    ostatni: 28-02-2017 01:00, Stoopi
    Altirra - czy można jakoś pozyska... (37)
    ostatni: 27-02-2017 16:47, pirx
    Wątek do testów (122)
    ostatni: 27-02-2017 13:02, insert
    doradźcie jakiegoś joya... (11)
    ostatni: 27-02-2017 12:34, Jacques
    ast multi cardridge (37)
    ostatni: 26-02-2017 23:00, atariki50
    Atari 130 XE - czarny ekran (7)
    ostatni: 26-02-2017 22:14, xangel
    Fajny Chip wczoraj słyszałem (214)
    ostatni: 26-02-2017 19:15, makary
    Książki SOETO (66)
    ostatni: 26-02-2017 18:04, Duddie
    syntezator (23)
    ostatni: 25-02-2017 22:42, TheFender
    Jaka to gra!?? (26)
    ostatni: 25-02-2017 10:41, IRATA4
    Wirusy na 65 XE (31)
    ostatni: 25-02-2017 01:38, IRATA4
    Muzyka z Atari w tle (16)
    ostatni: 25-02-2017 00:02, IRATA4

    Kategorie Forum Atarum

    Użytkowników: 1647
    Ostatnio zarejestrowany: Stoopi
    Postów ostatniej doby: 23

    Społeczność/Community

    Najbliższe imprezy

    Sprzęt/Hardware

    Wynalazki
    Atari i Bluetooth napisał Kaz (17)
    SIO2PC-USB napisał Larek (44)
    Nowe SIO2SD napisał Larek (0)
    SIO2SD w CA12 napisał Urborg (9)
    Ratowanie ATMEL-ów napisał Yoohaas (12)
    Projektowanie cartów napisał Zenon (12)
    Joystick do Atari napisał Larek (54)
    Tygrys Turbo napisał Kaz (7)
    Testowałem "Simple Stereo" napisał Zaxon (3)
    Rozszerzenie 1MB napisał Asal (20)
    Joystick trzyprzyciskowy napisał Sikor (18)
    Moje MyIDE oraz SIO2PC na USB napisał Zaxon (16)
    Jak wykonać płytkę drukowaną? napisał Zaxon (25)
    Rozszerzenie 576kB napisał Asal (13)
    Soczyste kolory napisał scalak (28)
    XEGS Box napisał Zaxon (13)
    Atari w różnych rolach napisał (8)
    SIO2IDE w pudełku napisał Kaz (5)
    Atari steruje tokarką napisał Kaz (14)
    DarkMouse napisał Kaz (7)
    «« nowszestarsze »»