atarionline.pl
atarionline.pl Atari
Login:
Hasło:
Zapamiętaj mnie
Translate to RSS RSS
Bardzo krótka relacja z KWAS #33 z 2024-03-25 21:11 (8)
KWAS #33 w Katowicach za moment! z 2024-03-21 13:06 (7)
Zbigniew Kasprzycki - współtwórca Polskiego Logo z 2024-03-15 22:25 (8)
"Zoltar Cosmic Pirates" w sieci z 2024-03-15 12:21 (6)
KWAS #32 z 2024-02-16 00:08 (39)
Która kolorystyka okładki lepsza? z 2024-02-11 18:30 (37)
Demo gry "Tony: Montezuma's Gold z 2024-02-05 21:09 (53)
Wywiad z Mariuszem Jaroszem z 2024-01-31 11:43 (12)
Nachodzi "Cosmic Hero 2" z 2024-01-28 06:27 (22)
Miniaturowe Atari (FPGA) z 2024-01-26 11:46 (15)
Światowa premiera "Cyborg Warriors"! z 2024-01-17 18:38 (40)
Grel #2 już dostępny! z 2024-01-11 19:21 (29)
Śmierć śmieciom! z 2024-01-06 21:23 (30)
Nowy program kopiujący "Microcop 61KB" z 2024-01-02 17:29 (25)
Wywiad Dracona z Mr. Bacardim z 2023-12-30 19:11 (12)
I po świętach! Kręcimy kołem z 2023-12-28 00:59 (13)
Wesołych Świąt 2023! z 2023-12-23 12:36 (18)
Silly Venture 2023 WE za nami z 2023-12-13 09:16 (17)
Pisma "Atari Fan 8" oraz "Grel 2" z 2023-12-07 17:32 (12)
From PLATO to Fujinet z 2023-11-25 23:16 (12)
«« nowszestarsze »»

Pomocnik/Helper
Gry/Games

Katalog gier (konwencja TOSEC)

Opisy gier
"Old Towers" (Atari ST) opisał Misza (19)
Submarine Commander opisał Kaz (11)
Frogs opisał Xeen (0)
Choplifter! opisał Urborg (0)
Joust opisał Urborg (16)
Commando opisał Urborg (35)
Mario Bros opisał Urborg (13)
Xenophobe opisał Urborg (36)
Robbo Forever opisał tbxx (16)
Kolony 2106 opisał tbxx (2)
Archon II: Adept opisał Urborg/TDC (9)
Spitfire Ace/Hellcat Ace opisał Farscape (8)
Wyspa opisał Kaz (9)
Archon opisał Urborg/TDC (16)
The Last Starfighter opisał TDC (30)
Dwie Wieże opisał Muffy (19)
Basil The Great Mouse Detective opisał Charlie Cherry (125)
Inny Świat opisał Charlie Cherry (17)
Inspektor opisał Charlie Cherry (19)
Grand Prix Simulator opisał Charlie Cherry (16)
«« nowszestarsze »»

Katalog gier (konwencja Kaz)
Aktualizacja: 2024-03-16
Liczba katalogów: 8377, liczba plików: 36679
Zmian katalogów: 0, zmian plików: 0

0-9 A B C D
E F G H I
J K L M N
O P Q R S
T U V W X
Y Z inne
zipCałość 2817 MB


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
    Atari 400 mini (1)
    ostatni: 28-03-2024 12:53, bandolier
    Time Wizard - gra na ABBUC Softwa... (196)
    ostatni: 28-03-2024 12:23, xbx
    TSFX Turbo Blizzard (55)
    ostatni: 28-03-2024 11:08, baktra
    RMT hacking (171)
    ostatni: 26-03-2024 20:59, emkay
    Awaria SIO2SD? (22)
    ostatni: 26-03-2024 19:47, pustak
    Ciekawostki (5543)
    ostatni: 25-03-2024 22:13, bruno_j
    Niedokładność Fujinet (47)
    ostatni: 25-03-2024 17:59, Alex
    Rick Dangerous (322)
    ostatni: 25-03-2024 17:35, tebe
    Murmulator i A800 ;) (5)
    ostatni: 25-03-2024 17:12, zaxon
    Turbo ROM Plus - problem z wczyty... (2)
    ostatni: 25-03-2024 11:36, lexx
    SF 314 przerobiony na XF 351 ;) (2)
    ostatni: 25-03-2024 10:43, Peri Noid
    Moje materiały wideo z grami na A... (192)
    ostatni: 24-03-2024 15:53, nowy80
    Nowe okładki gier - LAURA (270)
    ostatni: 24-03-2024 00:38, Peri Noid
    Jaki napęd 5.25 do XF551 (40)
    ostatni: 23-03-2024 20:49, zaxon
    ZIARENKO KURKI (26)
    ostatni: 23-03-2024 18:40, gizmomagic

    Kategorie Forum Atarum

    Użytkowników: 2771
    Ostatnio zarejestrowany: crawlergo@gmail.com
    Postów ostatniej doby: 13

    Spotkania i zloty / Meetings & Parties

    Najbliższe imprezy
    link do naszych spotkań online, zapraszamy do odwiedzenia kanału zoom również przez kod QR:

    KWAS

    Kalendarz AOL


    Społeczność/Community


    Rozmawiali
    Wywiad z Mariuszem Jaroszem i Kaz (12)
    Wywiad Dracona z Mr. Bacardim i Kaz (12)
    Tomasz Dajczak i Kaz (21)
    Lech Bąk i "Świat Młodych" i Kaz (26)
    Michał "Mike" Jaskuła i Kaz (6)
    F#READY i Dracon (22)
    Daniel „Arctus” Kowalski i Dracon (25)
    KATOD i TDC (15)
    Mariusz Wojcieszek i "Adam" (17)
    Romuald Bacza i Ramos (16)
    Śledzenie Amentesa i Larek (9)
    Leszek Łuciów i Charlie Cherry (17)
    TO JUŻ ZA TOBĄ: rozmowa z Bobem Pape i cpt. Misumaru Tenchi (39)
    Rob Jaeger i Emu (53)
    Jacek "Tabu" Grad i Dracon (0)
    Alexander "Koma" Schön i Kaz (0)
    Maciej Ślifirczyk i Charlie Cherry (0)
    Jarek "Odyniec1" Wyszyński i Kaz (0)
    Marek Bojarski i Kaz (0)
    Olgierd Niemyjski i Ramos (0)
    «« nowszestarsze »»

    Stragan
    Nowe, pojemniejsze RAM-Carty oferuje Kaz (21)
    "mouSTer" czyli myszka ST oferuje Kaz (30)
    Atari USBJoy Adapter oferuje Jakub Husak (0)
    Programy: Kolony 2106 oferuje Kaz (7)
    Sprzęt: rozszerzenia oferuje Lotharek (25)
    Gadżety: naklejki, pocztówki oferuje Sikor (11)
    Sprzęt: cartridge RAM-CART oferuje Zenon (7)
    Miejsce na drobne ogłoszenia kupna/sprzedaży oferuje Kaz (58)
    Sprzęt: interfejs SIO2IDE oferuje Piguła (0)
    Sprzęt: interfejs SIO2SD oferuje Piguła (34)

    Użytki/Utils
    Sprzęt/Hardware

    Wynalazki
    Atari i Bluetooth napisał Kaz (34)
    SIO2PC-USB napisał Larek (45)
    Nowe SIO2SD napisał Larek (0)
    SIO2SD w CA12 napisał Urborg (12)
    Ratowanie ATMEL-ów napisał Yoohaas (12)
    Projektowanie cartów napisał Zenon (12)
    Joystick do Atari napisał Larek (54)
    Tygrys Turbo napisał Kaz (11)
    Testowałem "Simple Stereo" napisał Zaxon (5)
    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 (26)
    Rozszerzenie 576kB napisał Asal (36)
    Soczyste kolory napisał scalak (29)
    XEGS Box napisał Zaxon (13)
    Atari w różnych rolach napisał Różyk (9)
    SIO2IDE w pudełku napisał Kaz (5)
    Atari steruje tokarką napisał Kaz (15)
    DarkMouse napisał Kaz (7)
    «« nowszestarsze »»