Czy po przerobieniu ksiazki "Asembler 6502" warto jest przerabiac ksiazki z serii "Mapa pamieci x,y,z" ? Z tego co czytalem to tam opisana jest budowa i jak wewnetrznie dzialaja te procedury a chyba najwazniejsze jest by wiedziec co robia i jak je uzyc i kiedy a nie wglebianie sie w ich wnetrze i jak dzialaja. Moze Wy dacie mi jakies szersze sporzenie na te pozycje i ich praktyczna przydatnosc.
"Mapa pamięci" faktycznie jest dość hermetyczna, ale myślę, że warto poczytać "Poradnik programisty Atari" Zientary. Jest tam trochę Basica, ale też i asemblera ale co najważniejsze to trochę sprzętu, jak działają tryby graficzne, sprajty, dźwięk itd
Warto. I poradnik programisty i mapa pamięci zawiera wiele informacji, których nie znajdziesz w Ruszczycu. Budowa i działanie OS, procedury startu komputera, informacje o tym jak działa ANTIC, GTIA i POKEY. Nie wiem jaki masz ogólnie cel w nauce asemblera, ale informacji o peryferiach i układach specjalizowanych nie znajdziesz w Assembler 6502, a bez tego nie ruszysz z żadnymi poważniejszymi projektami na Atari. Oczywiście można te informacje znaleźć też w sieci, polecam szczególnie ->link<- ale książkę też warto mieć pod ręką ;)
No chcialbym sie nauczyc Asemblera by sobie jakas gre kiedys w przyszlosci na Atari skrobnac. No ale wlasnie czy te wszystkie informacje jak zbudowany jest OS i jego dzialanie potrzebne jest w praktyce przy pisaniu np. gry?
jeśli robisz grę w starym stylu, bez doczytywania leveli, zapisywania stanów, itp, po prostu jeden pliczek jak river raid to potrzebujesz wyłącznie informacji o działaniu sprzętu (antic, gtia, pokey). jak wyłączysz OS to też nie musisz się przejmować rejestrami obsługiwanymi przez OS w rodzaju komórki 710.
A jesli bym chcial cos co doczytuje levele itd? To rozumiem, ze wtedy znajomosc OS jest juz wymagana - ale czy az w takim stopniu jak opisuja wyzej wymienione ksiazki ? W sensie budowy od srodka procedur OSu itd. ? Przeciez te procedury sa wbudowane w ROM i tak nic w nich grzebac nie mozna a znajomosc jak sa zbudowane i co sie dzieje w ich wnetrzu pomoze w ich uzywaniu ?
Pytam sie bo zastanawiam sie czy warto jest kupic reedycje tych ksiazek i czy one przydadza sie mi przy pisaniu jakiejs gry w dalekiej przyszlosci czy tylko to jest wiedza dla wiedzy dla ciekawych jak rzeczy dzialaja wewnatrz ROMu ;).
Bo nie widze w tym praktycznego sensu uczenia sie jakie sa kroki pomiedzy wywolaniem wbudowanej procedury a jej wynikiem. W czym ta wiedza moze sie przydac? To tak jakby uczyc sie wnetrza jakiejs funkcji w Unity - dla uzywajacego tej biblioteki wazne jest tylko co jej podac na wejsciu i co dostanie na wyjsciu w praktyce nie jest mu potrzebna znajomosc co sie tam mieli w srodku.
No jeszcze ludzie na atariage polecali mi po nauczeniu sie Asemblera 6502 na start "De Re Atari" a potem "Mapping the Atari" i wlasnie "Altirra hardware reference manual". Jeszcze po przeczytaniu "Asemblera 6502" Pana Ruszyca siegne sobie do innych angielskich ksiazek o Asemblerze 6502 dedykowanych dla Atari by sobie poszerzyc wiedze i wtedy bede juz chyba gotowy by siegac po reference guide'y by cos swojego skrobac powoli ;). Dluga droga przede mna, ale wierze, ze sobie poradze z odpowiednia determinacja i zapalem. Pewnie raz co jakis czas bede Was "meczyl" na forum jak bede mial jakis problem tak wiec szykujcie nerwy ;). Ogolnie to programowac potrafie w jezykach wysokiego poziomu jak Python czy C# w C/C++ czy Pascalu malo co pisalem wiec zejscie na tak niski poziom jak Asembler to bedzie nie lada wyzwanie ale no - challenge accepted.
mgr_inz_rafal mnie ubiegł, ale mniej więcej, czy nawet dokładnie to samo chciałem napisać:-)
Są oczywiście różne szkoły, ale dla mnie osobiście Twoje podejście w stylu "nauczę się tego, a potem czegoś tam dalej" jest kompletnie bez sensu. Moim zdaniem żeby zrobić grę na Atari, co jak rozumiem jest Twoim głównym celem, powinieneś zacząć od pisania tej gry. W trakcie jak napotkasz jakieś problemy, to będziesz szukał rozwiązań i się przesuwał do przodu.
Osobiście korzystam z tych wszystkich książek, które tu są wymieniane, ale nigdy w życiu żadnej z nich nie przeczytałem, choć wiem co w której znajdę i gdzie szukać jak czegoś potrzebuję. Polecam też to, jako jedną z głównych rzeczy, z których korzystam: ->link<-
Na Atari programowałem jako dzieciak w Basicu, później trochę próbowałem w assemblerze, ale był wtedy za trudny dla dzieciaka. Później programowałem w assemblerze na pecetach w czasach dosowych i jak wchodził Win95. Kilka lat później i całe dorosłe życie spędzam na programowaniu zawodowo z wykorzystaniem współczesnych technologii w różnych językach i środowiskach w zależności od potrzeb. Jakiś rok-dwa temu wróciłem do programowania na Atari i stwierdziłem, że mega zajebiście sprawdzają się w programowaniu na Atari współczesne techniki i wzorce programistyczne. Jakieś 15 lat temu przeczytałem książkę o programowaniu ekstremalnym. To taki wzorzec, tak się nazywa. Zachwyciłem się nim i od tamtego czasu stosuję w praktyce i całą pracę zawodową opieram o takie myślenie jak tam przedstawiono, a także tak programuję obecnie na Atari, a nawet przekładam sporą część założeń z tego na normalne życie prywatne:-) Jednym z podstawowych założeń programowania ekstremalnego jest rozpoczęcie pracy natychmiast, nawet kompletnie bez znajomości języka w którym się programuje. Polecam. Oczywiście nie wszystko z wzorca się stosuje, bo tam są np. ważne iteracje między ludźmi w zespołach, ale jak piszesz sam, to te rzeczy sobie po prostu pomijasz, ale to już szczegóły, chodzi o koncepcję ogólną.
Tutaj się bardzo mylisz:
Bo nie widze w tym praktycznego sensu uczenia sie jakie sa kroki pomiedzy wywolaniem wbudowanej procedury a jej wynikiem. W czym ta wiedza moze sie przydac? To tak jakby uczyc sie wnetrza jakiejs funkcji w Unity - dla uzywajacego tej biblioteki wazne jest tylko co jej podac na wejsciu i co dostanie na wyjsciu w praktyce nie jest mu potrzebna znajomosc co sie tam mieli w srodku.
Tak jest rzeczywiście np. we współczesnych technologiach, gdzie nie interesuje Cię też wydajność sprzętu, ani ilość pamięci, bo masz to wszystko zwykle w nadmiarze. Jak zaczniesz pisać na Atari, zwłaszcza jeśli będziesz wykorzystywał procedury gotowe np. systemowe, to szybko dojdziesz do wniosków, że potrzebujesz cykli, albo ramu i że możesz te procedury dostosować do swoich potrzeb upraszczając rzeczy niepotrzebne, łącząc w całość z własnymi bieżącymi potrzebami itp. w celu wyciśnięcia czegoś z Atari, co na początku w ogóle nie będzie Ci chciało zadziałać. Na Atari optymalizacja, to jest chyba 90% czasu pisania programu.
I na koniec tak podsumowując: radził bym zacząć od wybrania języka, środowiska, skonfigurowania sobie całości i zrobienia "hello world", następnie rozwijania tego o rzeczy, które przydadzą się w Twojej grze, a książki, to warto mieć po prostu na podorędziu.
Podejście "rzuć się w wir" jest najlepsze. Nie zniechęca, szybki postęp, szybki zwrot w postaci "nagrody". Czytanie książek jest dobre wtedy, gdy trzeba jakąś ogólniejszą wiedzę, albo podstawy ogarnąć. Dlatego Altirra HW Reference lub De Re Atari to podstawa. Trzeba ogarnąć, zanim się zacznie: - mapę pamięci, gdzie dos, gdzie program, etc. - display listę, grafikę, chociaż jeden tryb, a lepiej filozofię trybów tekstowych - przerwania (ale niekoniecznie, chociaż bez tego gra wygląda chropowato) - dźwięk obrzucić okiem I po kolei te punkty ogarniać w ww kolejności.
Hehehe:-) Może myślałeś, że to dobry żart, ale lepszym jest fakt, że to, że programujesz ekstremalnie słabo, mieści się świetnie i realizuje doskonale założenia programowania ekstremalnego:-) Tam jednym z postulatów jest fakt, że zaczynasz nie od nauki programowania, tylko od postawienia sobie zadania do wykonania. Dopiero w drugiej kolejności wybierasz język i środowisko, które się do tego nadadzą, a następnie zaczynasz realizować zadanie. Programowania uczysz się dopiero w trakcie. Ja to sobie tak kojarzę trochę ze sportami ekstremalnymi: wszyscy myślą, że czegoś nie da się zrobić, a delikwent najczęściej też tego nie potrafi, dlatego się na to decyduje i daje radę:-)
No to ma sens, bo osoby ktore sie znaja na tym stwierdzaja, ze racjonalnie nie da sie tego zrobic, a taka osoba nie ma o tym pojecia zaczyna to robic i okazuje sie, ze mu sie udaje ;). Nie raz tak bywalo. Calkiem fajna koncepcja
Materion, patrzę na inne tematy, które zakładasz, i nadal uważam, że idziesz nie do końca dobrą drogą. W jednym pytaniu pisałeś o mnożeniu w innym o dodawaniu. Próbujesz się tego uczyć, tymczasem zarówno mnożenie jak i dodawanie są rzeczami, których raczej należy unikać a nie się ich uczyć. Programowanie na Atari, to głównie przewalanie różnych wartości między komórkami pamięci za pomocą lda-sta i kombinowanie jak uniknąć wielu rzeczy (jak dodawanie i mnożenie), żeby zoptymalizować działanie. Jak zaczniesz uczyć się mnożenia, to zamiast gry w najlepszym razie uda Ci się pomnożyć przez siebie dwie liczby, przy czym komputer zrobi to w czasie tak długim, że ręcznie na kartce papieru szybciej to pomnożysz:-) To trochę sarkazm, ale chodzi mi o zasadę.
Piszę ogólnikami, więc podam konkretniejsze przykłady, postaw sobie konkretne zadanie, np.: 1. Chcę wydobyć dźwięk z Pokey'a - i wtedy poczytaj o Pokey'u co mu trzeba podać, żeby wydał z siebie dźwięk. 2. Chcę wyświetlić tekst - poczytaj o trybach tekstowych, graficznych, pamięci ekranu i wyświetl wtedy tekst. 3. Chcę wyświetlić grafikę w kolorze - wyświetl kawałek grafiki, wcześniej poczytawszy o Anticu i GTIA jak działają. 4. Chcę wyświetlić PMG - poczytaj o PMG i wyświetl coś.
To wszystko w kontekście, że pisałeś na początku, że chcesz robić grę. Do robienia gry mnożenie być może nie będzie Ci wcale do niczego potrzebne, zwłaszcza, że 6502 nie potrafi go wykonywać:-) Zmierzam do tego, że zaczynasz od spraw, które wydają się być najprostsze z punktu widzenia człowieka, który skończył szkołę, ale z punktu widzenia Atari są to rzeczy skomplikowane i często niepożądane. Na Atari łatwiej wyświetlisz obrazek, zrobisz scrolla, tęczę, albo obsłużysz poruszanie jakiegoś obiektu joystickiem niż wykonasz mnożenie. Przepraszam, że się tak tego mnożenia uczepiłem, ale to akurat dobry przykład jest na to co chcę tu przekazać.
To jaka droge polecasz? Powiem szczerze, ze jestem osoba ktora potrzebuje wiedziec jak cos dziala od wewnatrz - wiem, ze to zabiera duzo wiecej czasu dla wykonania efektu jak osoba ktora znajdzie w necie przyklad przeklei cos pozmienia i ma. Efekt szybciej osiagnela ta druga osoba, ale ja jak juz do tego efektu dojde to bede potrafil duzo wiecej z tym zrobic bo bede rozumial od podszewki i on w koncu trafi na sciane przez brak wiedzy o tym co zrobil. Z drugiej strony w MADs sie czy Fast Basicu mam juz gotowe funkcje ktore cos robia ze sprzetem - to mam ich nie stosowac tylko pisac samemu POKE i PEEKy? - wtedy rzeczywiscie cos bym sie nauczyl korzystajac z jezykow wyzszego poziomu. Jednak chcialbym sie tego asemblera nauczyc i zrozumiec by moc w nim cos zrobic nawet z wykorzystaniem MAD Pascala + wstawki asm.
Np z przykladow ktore podales - wyswietlenie tekstu no to w Basicu czy Mad Pascalu mam funkcje w stylu Print(x) to zrealizowanie tego to sekunda i niczego sie nie naucze bo wszystko jest "pod maska". O trybach tekstowych i graficznych juz czytalem bo zaczalem pisac gierke w Fast Basicu w trybie tekstowym i juz jakies wyswietlanie planszy i poruszanie bohaterem + kolizje z obramowaniem ekranu ogarnalem.
Np z przykladow ktore podales - wyswietlenie tekstu no to w Basicu czy Mad Pascalu mam funkcje w stylu Print(x) to zrealizowanie tego to sekunda i niczego sie nie naucze bo wszystko jest "pod maska".
Musisz sobie odpowiedzieć na pytanie, czy Twoim celem jest uczenie się samo w sobie, czy napisanie jakiegoś programu/gry. Ja gdybym chciał napisać grę, to ucieszył bym się z tego, że zrealizowałem coś w sekundę, ale mi nie zależy na nauce, tylko na rozwiązywaniu problemów i realizacji postawionych celów. Do realizacji gry/programu na Atari polecam obecnie pisanie w CC65 albo w Mad Pascalu i analizowanie wynikowych kodów w assemblerze, a także zapoznanie się z debugerem i wymyślenie sobie metod analizy wydajności kodu. Następnie poprawianie wydajności w assemblerze. Do nauki assemblera w ogóle nic nie polecam, bo nie umiem polecić, gdyż nigdy w życiu tak nie postępowałem żeby się uczyć jakiegoś języka samego w sobie bez konkretnego celu:-)
