atarionline.pl
atarionline.pl Atari
Login:
Hasło:
Zapamiętaj mnie
Translate to RSS RSS
KWAS #19 w Łodzi z 2020-01-22 17:57 (15)
Zmiany, zmiany na AOL! z 2020-01-19 19:22 (43)
Perełki z szuflady: "Noddy" z 2020-01-18 23:38 (20)
Po KWAS-ie #18 z 2020-01-17 00:01 (21)
Zaprzyjaźniona strona o C64 z 2020-01-15 21:59 (25)
KazKompo 2019 wystartowało! z 2020-01-12 21:16 (93)
"Another Pong" uwolniony! z 2020-01-09 17:10 (16)
KWAS nr 18 w Warszawie z 2020-01-05 00:19 (24)
Życzenia i konkursowe przypomnienie z 2019-12-31 01:46 (56)
Historia pewnego talizmanu z 2019-12-28 19:51 (47)
"Weronika" po latach z 2019-12-27 16:42 (12)
Z wizytą w muzeum w Katowicach z 2019-12-26 12:04 (9)
Wesołych Świąt! z 2019-12-24 16:06 (17)
Najnowsze gry w Mad-Pascalu z 2019-12-22 23:01 (36)
"Oni migają..." z Darkiem Żołną z 2019-12-20 00:24 (34)
PostKWAS z 2019-12-16 18:19 (16)
Cartridge Weekend 3+ z 2019-12-15 23:22 (20)
O grze "Monty on the Run" z 2019-12-15 01:30 (39)
Wywiad z Klaudiuszem Dybowskim z 2019-12-11 22:38 (17)
Wznowienie produkcji RAM-CART z 2019-12-11 04:15 (57)
«« nowszestarsze »»

Pomocnik/Helper
Gry/Games

Katalog gier

Opisy gier
Submarine Commander opisał Kaz (7)
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 (18)
Basil The Great Mouse Detective opisał Charlie Cherry (122)
Inny Świat opisał Charlie Cherry (17)
Inspektor opisał Charlie Cherry (19)
Grand Prix Simulator opisał Charlie Cherry (16)
Rescue On Fractalus opisał Kaz (18)
«« nowszestarsze »»

Wewnętrzne/Internals



   Nowinki tworzone dzięki CuteNews
"Weronika" po latach
Zenon Rakoczy z grupy Dial napisał dla nas o projekcie "Weronika":

Założenia projektu

Założenia były takie. Moduł kartridża zawiera w sobie dowolny procesor pracujący z dowolną szybkością. Słowo "dowolny" proszę traktować w granicach rozsądku. Może to być procesor 6502 lub jego młodszy brat, 16-bitowy taktowany np. 10MHz, albo AT89C2051 taktowany np. 6MHz. W zasadzie dowolne procesory taktowane dowolną częstotliwością. Po co to? Otóż drugi procesor ma wspomagać procesor Atari przygotowując dla niego coś, co będzie potrzebne, gdy ten zajęty jest np. odczytem pliku ze stacji dysków.



Jak to jest synchronizowane? I na jakiej zasadzie przesyłane są dane do obróbki między jednym a drugim? Opiszę pierwotny projekt, który w czasie testów ulegał modyfikacjom i na końcu przyjął nieco inną ostateczną formę. Trzon pozostał ten sam. Otóż mówimy o kartridżu wyposażonym w drugi procesor. Do tego pamięć RAM o pojemności 8KB, pamięć EPROM też o pojemności 8KB (trochę na wyrost) oraz druga pamięć RAM na użytek tylko procesora kartridża, no i nieco elektroniki.

Od strony Atari nic ponad to, w co wyposażyli go konstruktorzy. A że lubię BASIC i łatwo posługując się nim przeprowadzać testy, więc używana będzie przestrzeń adresowa $8000-$9FFF. Nie bez znaczenia jest fakt, że BASIC nadal jest dostępny, a przestrzeń tą można używać w zasadzie bezkarnie, bez nieprzyjemnych konsekwencji. Natomiast w kartridżu umieszczony jest rejestr stanowiący ogniwo łączące dwa procesory, by jeden nie następował na odcisk drugiemu. Dostęp do tego rejestru ma zarówno procesor Atari, jak i ten drugi, umieszczony w kartridżu. Procesor Atari może do niego wpisać 1 lub 0 i odczytywać jego stan. Procesor kartridża może go tylko wyzerować, co równoważne jest wpisowi zera, i może odczytywać jego stan.

Pamięć RAM 8KB umieszczona jest w kartridżu, dostęp do niej ma zarówno jeden jak i drugi procesor, ale o tym do którego jest przypisana decyduje wyłącznie procesor Atari. Pamięć ta przełączana jest na zasadzie multipleksowania i albo podłączana jest w obszar $8000-9FFF Atari, albo w obszar adresowania drugiego procesora. Powtórzę: przełączenia dokonuje tylko i wyłącznie procesor Atari. Ale obydwa mogą ją zapisywać i odczytywać.



Jak to działa?

Zaczynamy! Włączenie zasilania uruchamia procesor kartridża który pracuje według programu umieszczonego w pamięci EPROM. A program ten przymusza go do testowania rejestru w pętli, bo na razie nie ma nic innego do roboty. Czeka na informację: masz dane, możesz je obrobić i przygotowane podstawić procesorowi Atari. Jednocześnie zaczął pracować procesor Atari. Co robi? Ano właśnie odczytał jakiś plik z dyskietki i przystępuje do wykonywania poleceń w nim zawartych. A te między innymi zawierają polecenie: ustaw linię RD4, przełącz się na pamięć RAM kartridża, wpisz tam dane i ewentualnie program, który ma wykonać drugi procesor. Potem: przełącz pamięć i jeszcze ustaw rejestr, przekazując drugiemu procesorowi informację, że ma przygotowane co trzeba. Procesor Atari robi swoje, jak potrzeba testuje rejestr a ten jest ustawiony i niesie sobą informację. Drugi procesor jeszcze pracuje: nie przełączaj pamięci, bo będzie konflikt (w rzeczywistości Atari odczyta stan rejestru jako zero, o czym dalej).

Pracujący drugi procesor testując rejestr wykrył że jest on ustawiony, więc „wskakuje” w obszar pamięci RAM, która tyle co dostępna była dla procesora Atari, a teraz zawiera co trzeba przygotowane dla niego i co ważne, jest dla niego dostępna. Fizycznego przełączenia dokonał procesor Atari, procesor kartridża posługuje się nią, a jeżeli trzeba, „biega” po jej adresach, wykonując to i tamto. Pracuje, przetwarza, liczy czy co tam jeszcze. Korzysta na przykład z procedury, którą przesłał procesor Atari, lub korzysta z procedur swojej pamięci EPROM, w razie potrzeby posiłkując się swoją pamięcią operacyjną RAM. W końcu praca została zakończona. Nie używa już pamięci RAM, by mogła stać się dostępna dla procesora Atari, zeruje rejestr i wchodzi w pętlę testującą rejestr, po drodze robi co programista mu nakazał. Rejestr jest przez niego wyzerowany więc niesie sobą informację: nie używaj tej pamięci RAM, bo będzie konflikt, czekaj w pętli lub rób swoje, bo procesor Atari nie podstawił ci nowych danych. Będzie ustawiony, to zadziałaj.

Procesor Atari oczywiście pracuje wykonując jakieś tam zadania, jednocześnie raz i drugi testuje rejestr. Rejestr ustawiony. Ignoruje go (odczyt daje zero), ale oto odczyt daje informację, że rejestr jest wyzerowany (Atari odczytuje że jest jedynka). Acha, drugi procesor zrobił swoje. Więc można przełączyć się na podstawioną pamięć i zrealizować to, co kolega przygotował. Więc myk i mam co trzeba. Praca, praca..., przetwarzanie, rysowanie, animowanie, etc. Nie trzeba liczyć jak szybko to idzie, bo policzone, wymierzone, uporządkowane. Kolejne dane podstawione są do pamięci i zasygnalizowane to jest ustawieniem rejestru (Atari wpisuje jedynkę), cykl się powtarza. Jak widać, procesor Atari jest nadrzędny nad drugim procesorem. To Atari inicjuje synchronizację sterowaną rejestrem. Sama pamięć RAM stanowi rzeczywistą kość (układ scalony), która multiplekserem jest albo podłączona w przestrzeń Atari $8000-$9FFF, albo w przestrzeń $8000-$9FFF drugiego procesora. A o tym co i kiedy się wykonuje decyduje program, a raczej programista, który oprogramować musi dwa procesory.

Opisałem prosty sposób wymiany danych i ich obróbkę. W rzeczywistości są dwie fizyczne kości pamięci po 8KB, w tym samym czasie jedna przypisana procesorowi Atari, druga procesorowi kartridża. Jak trzeba, a zdecyduje o tym procesor Atari, pamięci są zamienione elektronicznie miejscami (multiplekserem) i fakt ten zasygnalizowany jest odpowiednim ustawieniem rejestru, który znajduje się na stronie $D5. Zatem, każdy procesor ma swoje 8KB i w tym samym czasie robić może co trzeba, a potem pyk i gotowe, pamięci zamienione miejscami. Stąd szybkość i raz jeszcze szybkość wynikająca z pracy dwu procesorów, jak trzeba, drugiego taktowanego np. 10MHz.

Nietrudno zorientować się że nie ma tu żadnej synchronizacji, nie licząc rejestru, który sygnalizuje jednemu i drugiemu procesorowi co może zrobić, nie narzucając kiedy ma to zrobić, stąd idea, że drugi procesor może pracować z dowolną częstotliwością, a i tak będzie się to zazębiać i jeden drugiego nie zablokuje. Chyba że ignorować będzie informacje jakie niesie sobą rejestr. A że drugi procesor może być dowolnym procesorem, stąd procedury do niego przesyłane przez procesor Atari powinny być dla niego zrozumiałe. O tym decyduje już programista. By ułatwić sobie zadanie, dobrym pomysłem jest by drugi procesor też rozumiał polecenia procesora 6502, programista przez to dłużej pożyje i mniej ponarzeka na mnie za wymyślonego dziwoląga.

Opis

To teraz pora na schemat i opis, ale tylko fragmentu dotyczącego rejestru, który jest sercem i motorem napędowym całości. A jak ktoś chce niech nazwie go sobie rejestrem synchronizującym pracę dwu procesorów. Przedtem krótka wstawka. Dlaczego to coś nazwałem "Weronika". Otóż gdy realizowałem inne pomysły, nie omieszkałem pochwalić się jednym z nich w szkole, w której pracowałem. Jedna z uczennic (gimnazjalistka) zapytała wprost... co to? Odpowiedziałem, to "Beatka", bo właśnie ten model kartridża był prezentowany. „Zrobi pan też taki, co nazywać się będzie Weronika? Jak ja?”. Rozumiecie, jak mogłem odmówić? Nie wypadało. I tak Weronika przeszła do historii, przynajmniej tej związanej z Atari.

Zanim pojawi się schemat wcześniej pewne uporządkowanie. To włączone, to wyłączone, ten ustawia, drugi zeruje... mętlik. Rejestr ma działać według tej samej zasady dla jednego i drugiego procesora. Tabelka prawdę powie o działaniu rejestru:

Włączone zasilanie, nastąpił reset.
Atari: odczyt =1, pamięci można przełączyć
Drugi procesor: odczyt = 0, czekaj na przełączenie pamięci.

Praca procesorów.
Atari: wpis = 1 (odczyt = 0), przełączone pamięci, czekaj na odpowiedź drugiego procesora, nie przełączaj ponownie.
Drugi procesor: odczyt = 1, ma przełączoną pamięć, pracuj, nie odczytuj ponownie rejestru.
Po wykonaniu poleceń wpisz 0, odczyt = 0

Teraz Atari
Odczyt = 0, czekaj, drugi procesor jeszcze nie skończył.
Odczyt = 1, można przełączyć pamięć, wpisać nowe dane, przełączyć ją i do rejestru wpisać 1, co odczyta jako 0, drugi procesor jako 1.

I jest porządek, obowiązuje ta sama zasada reagowania na odczyt rejestru. Ze schematu wynika, że Atari może do rejestru wpisać 1 lub 0, co wydaje się nieporozumieniem. Służyć to ma przyszłym innym (lepszym) sterowaniem całością. Póki co od strony Atari NIE WOLNO DO REJESTRU WPISYWAĆ ZERA, bo całość się zawiesi. Sekwencja STA $D500,#bxxxxxxx0 jest zabroniona.

Schemat

Wreszcie schemat. Całościowy, według którego budowałem pierwszy model. Schemat drugi to sam rejestr i opis jego działania. Zamieszczam to w formie zdjęć oryginału, byście poczuli epokę i związany z tym klimat i wkład pracy:



Co do czego i po co. Dekoder 74138 generuje dwa sygnały, wpis i odczyt rejestru, na podstawie sygnałów R/W i CCTL. Z pinu15 sterowane jest wejście zegarowe przerzutnika 7474. Jego wejście D sterowane jest bitem D0 szyny danych Atari. Rejestr ma adres $D500 więc POKE 54528,1 ustawi rejestr, natomiast PRINT PEEK(54528) - dokona jego odczytu. Odczyt dokonuje się poprzez bufor trójstanowy 74367, również na pozycji bitu D0 szyny danych. Proszę zauważyć, że wpis 1, da odczyt = 0, bo sygnał do odczytu pobierany jest z wyjścia zanegowanego, pin6 przerzutnika 7474.

Drugi procesor dokonuje odczytu rejestru z pinu5 przerzutnika 7474 poprzez bufor 74367. Jego pin13 połączony jest z bitem D0 szyny danych.
Drugi procesor wpisuje zero do rejestru, po prostu go resetując. Sygnał przychodzi z układów dekodujących wybrany adres szyny adresowej i poprzez diodę D2, zeruje przerzutnik. Atari odczyta to jako 1, drugi procesor jako 0. Od strony drugiego procesora cała 64kB przestrzeń adresowa sygnałami adresowymi A14, A15 no i elektroniką, podzielona jest na bloki po 16kB. Każdy blok przypisany jest do czegoś innego. Jeden z nich do rejestru, to ten o adresach $4000-$7FFF. Wystarczy zatem zaadresować ten obszar, a rejestr zostanie wyzerowany, zresetowany. Dlaczego tak. Bo zyskujemy nieco na szybkości, upraszcza się elektronika, dekoder adresowy i takie tam. Zamiast:

LDA #00
STA $4000

wystarczy samo STA $4000, z dowolną zawartością akumulatora. Niby niewiele, ale zawsze szybciej.

Inny obszar $8000-$BFFF przypisany jest przełączanej pamięci, by było jak w Atari, jeszcze inny pamięci EPROM i pamięci operacyjnej RAM. Dekoder jest dekoderem niepełnym, stąd „zawijanie” adresów, bo rejestr potrzebuje jednego adresu, przełączana pamięć to 8KB, pamięć operacyjna powiedzmy też 8KB, EPROM wystarczy 4kB.

I jeszcze, po włączeniu zasilania przerzutnik 7474 jest resetowany impulsem generowanym przez opornik 3kohm i kondensator 10uF. No i wiadomo, że Atari ma podstawioną pamięć, drugi procesor nie. Dioda D1 pełni rolę separatora. Właściwie zamiast diod D1 i D2 powinna być bramka AND (uwaga, tu było omyłkowo NAND, tekst zmieniony), ale nie miałem już na płytce wolnej bramki do wykorzystania, stąd namiastka jej zbudowana na diodach i oporniku 2kohm podciągniętego do Vcc.

Na schemacie zauważyć można drugi przerzutnik 7474 który stanowi integralną część rejestru sprzętowego. Sterowany jest bitem D1 szyny danych Atari. Służy do przełączania multipleksera, tym samym zamianie przyporządkowania przełączanych pamięci. Opisu nie zamieszczam, bo tu skupiam uwagę na mechanizmie komunikacji między procesorami. No to tyle.

I jeszcze Nir Dary prezentuje dalekiego krewnego "Weroniki":


Prototypy

Początkowy projekt zakładał użycie pamięci EEPROM, SRAM, po stronie drugiego procesora, rejestr sterujący dwubitowy. D0 steruje rejestrem, D1 przełączaniem pamięci. Na pewnym etapie część elektroniki wprogramowana była w GAL, zamiast EEPROM pojawiła się kolejna SRAM, w której Atari mogło umieścić nazwijmy to OS drugiego procesora. Nastąpiła rozbudowa rejestru o kolejne bity sterujące, inne przypisanie adresów, możliwość współpracy ze SpartaDOS X i różne inne różności. Dla mnie to zadziałało, projekt był zakończony i zamysł okazał się słuszny. Idea rejestru sterującego wykorzystana została w innych projektach o podobnym zabarwieniu, bo już wtedy ludziki pytali mnie o jego działanie, a ja odpowiadałem, rysowałem schematy i opisywałem co i jak ma działać. Na zakończenie, fotki pierwszego modelu do testów z procesorem 6502, druga fotka to już model z GAL-em i dołączanym modułem z procesorem, tu 16-to bitowy brat 6502, taktowany jak pamiętam 8 czy 10MHz. Brak scalaków? Upływ czasu zrobił swoje, potrzebne były do czegoś innego.

Dziękuję za uwagę. Zenon/DIAL, 25 grudnia 2019 roku.

PS. od Kaza - wszystkie zdjęcia Zenona są też dostępne w oryginalnych rozmiarach tutaj.



2019-12-27 16:42 by Kaz
komentarzy: 12
Kaz @2019-12-27 16:43:07
Dzięki Zenon za poetycki opis :D
xxl @2019-12-27 18:09:13
a co sie stanie jak sie procesor na karcie zawiesi? czy to z powodu bledu w kodzie usera czy to z powodu przerwania pracy zmiana pamieci?
maly_swd @2019-12-27 18:44:55
Wyjąć i włożyć ;)
Cyprian @2019-12-27 19:09:57
fajny projekt,
tutaj inny opis: www serious-dial atari pl / zzone/ weronika html
Konop @2019-12-27 19:44:21
Miło słyszeć, że Zenek odzyskał zdrowie i emanuje energią.

@xxl. W skomercjalizowanej wersji Weroniki wyasygnownay jest bit do kontrolowania resetu CPU. 65816 wymaga pewnych zabiegów zsynchronizowanych czasowo, aby dokonać jego resetu.

Nie pamiętam, czy prototypowa wersja posiadała mechanizm resetu. Zenek będzie wiedział lepiej.
Zenon @2019-12-27 20:06:17
Jak się zawiesi, robi się to samo co przy innych zawieszeniach. Najlepiej ponownie całość odpalić, wyłączając i włączając zasilanie. Model nie jest bezwzględnie odporny i doskonały. Awaryjność jak wszystko inne. Zawiesi się stacja, odpalamy ponownie.
Jak się user pomyli.... nauka polega na eliminowaniu pomyłek.
W czasie przełączenia nie powinno się zawiesić. Procesor musi zapomnieć że można korzystać z przełączanej pamięci, wykonać np skok do swojej pamięci EPROM (operacyjnej) gdy operował na adresach przełączanej i realizując jakąś tam procedurę wydać dopiero polecenie do rejestru.
Opisałem model pierwotny, prototyp. W kolejnych stosowany był przycisk RESET, pomagał wybrnąć z kłopotów.
Na youtube, etap testów. Jak widać animacja się realizuje a migające LEDy sygnalizują przełączanie.
Wchodząc do youtube wpisać poniższe.
Veronica 0.3 cartridge running some example programs.
IRATA4 @2019-12-27 20:15:11
@Zenon Proszę o kontakt mailowy irata.atari(małpa)vp(DOT)pl
WAŻNE.
Kaz @2019-12-27 21:31:51
Wrzuciłem filmik do nowinki.
Creonix @2019-12-27 22:00:14
Piękne te rysunki itd. ale muszę się rozeznać o co chodzi.
anon @2019-12-27 22:20:08
We love Zenon/Dial
Kaz @2019-12-27 22:32:35
Na prośbę pana Zenona drobna poprawka tekście - AND zamiast NAND.
Kaz @2019-12-27 22:38:41
I jeszcze Zenon poprosił o wstawienie filmiku Nira Diarego z prezentacją kuzynostwa Weroniki :)
nickname
e-mail / website (opcjonalnie)
Aktualne tematy
Pisanie dla rozszerzonej pamięci (4)
ostatni: 28-01-2020 12:28, tebe
Ciekawostki (4462)
ostatni: 28-01-2020 12:05, Kaz
Atari Hotels (1)
ostatni: 28-01-2020 12:02, Kaz
KazKompo 2019 (50)
ostatni: 28-01-2020 11:51, pin
Polskie programy na Atari ST/e (5)
ostatni: 28-01-2020 11:11, Kaz
Atari 130XE server www ;) (145)
ostatni: 28-01-2020 11:08, pin
Piotr Marecki i Atari ;) (2)
ostatni: 28-01-2020 10:35, Kaz
Książka o polskim gamedevie i Ata... (77)
ostatni: 28-01-2020 02:10, tdc
Gravity Worms (288)
ostatni: 27-01-2020 19:07, pin
Do administratora (32)
ostatni: 27-01-2020 18:58, gorgh
Zmiany / usprawnienia na AOL (203)
ostatni: 27-01-2020 18:37, mgr_inz_rafal
Symulator 6502 (15)
ostatni: 27-01-2020 16:21, Koval
[S] Trochę gratów (19)
ostatni: 27-01-2020 15:04, tbxx
Jak zbudować i zaprogramować CART... (41)
ostatni: 26-01-2020 18:28, lopezpb
ATARI XE vs C64 (1237)
ostatni: 26-01-2020 13:04, Vidol

Kategorie Forum Atarum

Użytkowników: 2087
Ostatnio zarejestrowany: zak6
Postów ostatniej doby: 60

Społeczność/Community


Rozmawiali
F#READY i Dracon (21)
Daniel „Arctus” Kowalski i Dracon (25)
KATOD i TDC (13)
Mariusz Wojcieszek i "Adam" (16)
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)
Wolfgang Burger i Grey (0)
Mariusz "Ramos" Rozwadowski i Xeen (0)
Wywiad z Wojciechem Zientarą i Xeen (0)
Mateusz Stryjecki i Kaz (5)
Marcin Długosz i Kaz (16)
«« nowszestarsze »»

Najbliższe imprezy
Jeżeli znasz termin i miejsce jakiegoś zlotu albo spotkania milośników Atari to poinformuj nas. Tutaj możemy wstawić baner i link.

Stragan
Atari USBJoy Adapter oferuje Jakub Husak (0)
Programy: Kolony 2106 oferuje Kaz (6)
Sprzęt: rozszerzenia oferuje Lotharek (19)
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 (51)
Sprzęt: interfejs SIO2IDE oferuje Piguła (0)
Sprzęt: interfejs SIO2SD oferuje Piguła (22)

Użytki/Utils
Sprzęt/Hardware

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