Kolega z pracy namówił mnie na udział w konkursie 100 Commitów. Od kilku miesięcy chodzi za mną pomysł zaprogramowania czegoś na Atari 2600. Pomyślałem, że konkurs to dobra okazja do zabawy i spróbowania czegoś zupełnie nowego. Postanowiłem napisać grę na Atari w ramach konkursu. Mam już pomysł, ale jeszcze go nie zdradzę.
Przygotowania rozpocząłem kilka tygodni temu. Poznaję narzędzia, instaluję środowisko pracy. Zacząłem także czytać książki:
- Nick Montfort, Ian Bogost - Racing the Beam - zawiera analizę platformy Atari 2600 oraz kodu kilku słynnych gier z punktu widzenia programistycznego.
- Jan Ruszczyc - Asembler 6502 - opis assemblera procesora 6502. Atari 2600 zawiera co prawda procesor 6507, ale jest to okrojona wersja 6502, więc zdobyta wiedza nie zmarnuje się.
Prawie zlamiłem pierwszego dnia! Zasady konkursu wymagają co najmniej jednego commita dziennie od autora repozytorium. W konfiguracji gita miałem podany błędny adres e-mail i moje wcześniejsze commity zaliczyły się na konto innego użytkownika Githuba! Na szczęście zauważyłem to w porę.
Spędziłem noc czytając dokumentację języka Batari Basic, opisy "kerneli" stąd: https://www.randomterrain.com/atari-2600-memories-batari-basic-commands.html
Wygląda na to, że ograniczenia są dosłownie na każdym kroku. Zastanawiam się, jak je obejść, aby np. zrobić "dużego ludzika" w grze.
Kilka przykładów ograniczeń:
- Atari 2600 ma 128 bajtów RAMu, ale tylko 26 jest dostępnych. Pozostałe są domyślnie użyte dla różnych celów.
- Możesz narysować pięć poruszających się obiektów: 2 sprite'y graczy, 2 pociski (muszą być kwadratowe) i jedną piłkę.
- Jeśli sprite ma używać więcej niż jednego koloru, nie użyjesz pocisku.
- Nie ma prostej metody wyświetlenia tekstu (nie zacznę standardowym programem "hello world!").
- Wersja binarna programu powinna mieć maksymalnie 4KB. Jeśli potrzeba więcej, można wykorzystać technikę przełączania banków pamięci, ale Atari w danym momencie ma dostęp tylko do jednego, 4-kilobajtowego banku.
Zacząłem pracować nad płytką kartridża. Dlaczego, skoro jeszcze nie mam ani jednej linijki gry? Chcę zamówić płytki jak najszybciej. Mogą dotrzeć nawet po 30 dniach. Jeśli popełniłem błąd, chciałbym mieć czas na jego poprawę.
Jednak wcześniej robiłem bardziej skomplikowane kartridże - na przykład 128-in-1 cartridge clone. Jestem przekonany, że mój projekt prostego kartridża 4KB także zadziała. Możecie znaleźć podobne projekty tu i ówdzie, na przykład: https://grandideastudio.com/portfolio/gaming/pixels-past/.
Projekt jest prosty, elegancki i sprawdzony w boju, ale chcę go jeszcze uprościć. Obecnie używam inwertera 74S04 i to tylko jednej z jego sześciu bramek. Nie potrzebuję układu scalonego, aby odwrócić jeden bit. Zamierzam użyć inwertera z tranzystora i dwóch rezystorów.
Dziś pobawiłem się trochę edytorami sprite'ów i stworzyłem - na razie wstępną - wersję sprite'a postaci. Przywitajcie Bertę!
Nie jestem pewien, czy będę mógł go użyć w takiej formie ze względu na użyte kolory.
Sprawdziłem też, czy inwerter z tranzystora i dwóch rezystorów zadziała zgodnie z planem. Zadziałał!
Dobra, wymieniłem układ scalony inwertera na inwerter bazujący na tranzystorze i zamówiłem płytki drukowane.
Dziś eksperymentowałem ze sprite'ami. I wyjawiłem pomysł na grę :) Wyświetliłem kilka sprite'ów. Gra jest dość statyczna, więc nie muszę ich animować. Chciałbym, aby gra była bardzo kolorowa (takie gry przemawiają do mnie bardziej, niż te z czarnym tłem), więc spróbowałem połączyć sprite'a z "polem gry", aby wyświetlić dużą Bertę:
Efekt jest jeszcze daleki od ideału, ale jestem właściwie przekonany, że zdołam wyświetlić to, co chcę.
Postanowiłem, że wykorzystam bardziej tradycyjne metody projektowania. Rysuję sprite'y i "pole gry" ręcznie, ołówkiem. No dobra, używam tabletu reMarkable, a nie prawdziwego papieru. Powiedzmy, że wykorzystuję pół-tradycyjne metody ;)
Wiem już, że muszę połączyć "pole gry" ze spritem, aby wyświetlić wielokolorową, dużą postać. Główna trudność polega na tym, że "piksele" pola gry są prostokątne, a "piksele" sprite'a są kwadratowe i czasami jest trudno osiągnąć pożądany efekt. Tutaj szyja Berty jest zbyt długa, ale nie mogę jej skrócić, bo nie mogę podzielić "piksela" pola gry:
Gdy widzę inną grę na Atari 2600, automatycznie myślę o tym, jak była zrobiona. Przykładowo, Combat to prezentacja bezpośredniego wykorzystania możliwości konsoli: wyświetlenia dwóch sprite'ów i dwóch pocisków na polu gry. Breakout najwyraźniej wykorzystuje sprite'a na paletkę, do tego piłkę i klocki z "pikseli" pola gry.
Kontynuowałem ręczne projektowanie. Zakodowałem też sprite i "pole gry", aby po raz pierwszy wyświetlić Bertę we właściwej postaci!
Dziś przerwa :) Mogę wrzucić widok płytki PCB, która się aktualnie produkuje:
No dobra, poeksperymentowałem troszkę z obsługą joysticka.
Dodałem drugi sprite - na siatkę na motyle. To ostatni sprite jaki mogę użyć :)
Zacząłem myśleć o sterowaniu joystickiem. Na oryginalnej grze G&W potrzeba tylko jednego wciśnięcia przycisku, aby poruszyć postać w zadanym kierunku (góra-lewo, góra-prawo, dół-lewo, dół-prawo). Na Atari czasami będą potrzebne dwa ruchy joysticka. Na przykład, aby poruszyć Bertę z kierunku dół-lewo do góra-prawo, potrzeba poruszyć joystick w prawo i w górę. Inny kontroler, na przykład z Playstation czy Xboxa, byłby lepszy. Mógłbym wykorzystać strzałkę w górę, strzałkę w dół, trójkąt oraz krzyżyk. Być może zrobię specjalny adapter dla tej gry (albo nawet specjalny kontroler).
Zmieniłem sprite z siatką na motyle na bardziej "realistyczny" :) Po pierwszych eksperymentach z obsługą joysticka teraz sprawiłem, że to Berta nieco się porusza. Wykorzystałem też rejestry REFP0 i REFP1, aby uzyskać lustrzane odbicie sprite'ów w zależności od tego, czy Berta jest obrócona w lewo, czy w prawo. Dzięki temu nie muszę zużywać pamięci ROMu na przechowywanie dwóch wariantów sprite'ów.
| Berta w pozycji góra-lewo | Berta w pozycji dół-prawo |
|---|---|
 |
 |
Poszerzyłem sprite siatki - jest dwa razy szerszy niż był. Zacząłem eksperymenty z dźwiękiem, ale jeszcze nie mam nic do commitnięcia...
Dodałem także eksperymentalną wersję "animacji" motylka. Motyle są zrobione z "pikseli pola gry", a ich modyfikacja jest kosztowna jeśli chodzi o cykle procesora. Prawdopodobnie nie wystarczy mi cykli, gdy będę chciał wyświetlić 4 czy 5 motyli jednocześnie.
Nadszedł czas, aby zacząć myśleć o algorytmie rozgrywki. Chcę, aby doświadczenie gry było podobne jak w oryginale, ale nie identyczne. Przykładowo - nie zrobię zegarka ani budzika. Pamiętam też, że w oryginalnej grze czasami pojawiał się kogut i traciło się tylko połowę życia, gdy był widoczny. Nie mam miejsca na ekranie na "koguta", dlatego jego też odpuszczę.
Oryginalna konsola G&W używała mikroprocesora Sharp SM-5A, a rosyjskie konsole wykorzystywały jego klon - КБ1013ВК1-2. Milan Galcik stworzył disassembler tego procesora i wykonał inżynierię wsteczną gry w jajeczka: Sharp SM-5A Disassembler. Jestem pełen podziwu dla jego pracy. Co prawda nie chcę stworzyć odpowiednika 1:1 gry, ale jego materiały na pewno będą pomocne.
Dziś dodałem dźwięk do "animacji" motyla i brzmi on całkiem dobrze jak na moje uszy. Nie wspomniałem o tym wcześniej, ale możliwości dźwiękowe Atari 2600 są także bardzo ograniczone. (Jednak prawdziwy artysta może z nim zdziałać cuda - zobaczcie ten występ cTrixa: https://youtu.be/S8e7g8kJIlo).
Chcę zanurzyć się w oryginalnej grze, aby poznać ją najlepiej, jak to możliwe. Niestety, żadna z moich zabytkowych konsolek nie działa, ale od czego są emulatory?
Dodałem brakujące motyle. Są one zrobione z "pikseli pola gry". Ich wyświetlanie jest kosztowne jeśli chodzi o cykle procesora. Na razie animują się poprawnie, ale będzie ich jeszcze więcej - nawet 12 w jednym momencie! Obstawiam, że to będzie za dużo. Prawdopodobnie kiedyś zmienię metodę "zapalania" "pikseli pola gry" na bardziej bezpośrednią, assemblero-podobną.
Dodałem też krzaki i chmurki :)
Zmieniłem sposób, w jaki przechowywana jest pozycja Berty. Tak będzie ją łatwiej obsłużyć i porównywać pozycję ze "źródłami" motylków.
Zaimplementowałem roboczą wersję algorytmu wypuszczania motylków. Działa całkiem dobrze, jednak kilka zmiennych jest w tej chwili zabitych na sztywno:
- Maksymalna liczba motylków latających w jednym momencie - 3. W oryginalnej grze liczba ta zależy od aktualnego wyniku.
- Numer "źródła", które pauzuje i nie wypuszcza motylków. W oryginalnej grze zależy to od liczby żyć gracza.
Dziś nic spektakularnego - odpoczywam :) Dostosowałem kolory wersji NTSC i ustawiłem ją jako domyślną, gdyż emulator domyślnie traktuje ROMy jako wersje NTSC. Oczywiście wersja PAL pozostaje dla mnie ważniejsza, bo chcę ją uruchomić na prawdziwej konsoli, a tę mam w wersji PAL.
Próbowałem narysować Bertę na potrzeby przyszłej okładki kartridża i pudełka. Problem w tym, że nie umiem rysować. Na razie to mój najlepszy rezultat:
Inne rysunki są jeszcze gorsze. Jeden z nich pasowałby jako plakat do horroru Williama Wylera - Kolekcjoner.
Prawdopodobnie poprosze żonę o rysunek :)
Bardzo chciałem zobaczyć, jak program zadziała na prawdziwym sprzęcie. Co prawda zamówione płytki jeszcze nie dotarły i jeszcze nie da się grać, ale mimo to poświęciłem kość EPROM i użyłem jednej z wcześniejszych płytek prototypowych, aby uruchomić Bertę!
Poruszałem trochę Bertą używając joysticka. Nie było aż tak źle, ale i tak zacząłem przymierzać się do skonstruowania adaptera pada, aby sterowanie było wygodniejsze. Zdecydowałem się na pady od Super Nintendo - ich zamienniki są tanie, mają odpowiednią liczbę przycisków do obsługi gry. Z padem od Playstation 4 byłoby więcej roboty, wymagałoby też użycia potężniejszego (droższego) mikrokontrolera. Zamówiłem gniazda pada od SNESa i zacząłem projektować płytkę adaptera.
Wrzuciłem projekt płytki drukowanej adaptera kontrolera. Będzie wykorzystywał mikroprocesor Atmega8/48/88, który nie jest tak tani, jak kiedyś był, ale jest bardziej przyjazny hobbistom niż procesory w wersji SMD. Muszę go jeszcze zaprogramować, ale to nie powinno być problemem. Robiłem wcześniej podobne adaptery dla padów od NESa, które są podobne i różnią się tylko liczbą przycisków i wtyczką.
Dziś urodziny żony i miałem zrobić sobie przerwę, ale dokonałem kilku drobnych poprawek w projekcie płytki adaptera pada:
Berta od teraz może złapać motylka! Co prawda nie można jeszcze stracić życia, ale po raz pierwszy można zdobyć punkt :)
Wrzuciłem pierwszą "grywalną" wersję na największe forum o Atari - Atari Age
Liczę na jak najwcześniejsze opinie!
Zaimplementowałem też zależność maksymalnej liczby jednocześnie wypuszczonych motylków od aktualnego wyniku.
Dziś wprowadziłem drobną poprawkę w algorytmie uwalniania motylków. Gdy nie ma żadnych motyli w powietrzu, wypuszczanie nie jest zależne od wyniku losowania. Wcześniej zdarzały się przerwy, kiedy nie wylatywały żadne motyle.
Dotarły płytki kartridży! Niestety, nie znalazłem chwili, aby polutować pierwszy egzemplarz na próbę.
Polutowałem pierwszy kartridż. Niestety, nie działa. Jedyna nowość w jego projekcie to inwerter oparty o tranzystor. Spytałem x_angela, który jest moim elektronicznym guru, jaki może być powód. Wygląda na to, że stan "niski" w Atari jest za wysoki (0.6V) i nie jest odwracany na 5V, a na 0V. Muszę go obniżyć przy użyciu dzielnika napięcia.
Poeksperymentowałem z wartościami rezystorów, ale bez efektu. Kartridż wciąż nie działa. Na ten moment sam nie wiem, co o tym myśleć, ale się nie poddam :)
Wciąż bez sukcesu z inwerterem. W najgorszym razie użyję małego inwertera 74V1T14 z jedną bramką i umieszczę go jakoś na płytce. Ale najpierw poeksperymentuję dalej z rezystorami. Muszę sprawdzić, jakie są dokładne poziomy napięć w Atari przy użyciu oscyloskopu.
Muszę zrobić przerwę od inwertera. Zamiast tego zacząłem pracę nad oprogramowaniem dla adaptera pada SNES. Przygotowałem prototypowy kabelek do eksperymentów:
Postanowiłem sprawdzić, czy może na płytce kartridża są jakieś inne błędy. W tym celu podłączyłem "standardowy" inverter - 74S04. Z nim kartridż działa prawidłowo:
Zbliża się Wielkanoc. Dziś nic wielkiego - dodałem wstępną obsługę straty życia.
Wysłałem paczkę z płytką drukowaną i EPROMem do x_angela, który pomoże mi w sprawieniu, aby inwerter zadziałał.
Dziś pracowałem nad oprogramowaniem dla adaptera padów od SNESa. Tym razem robię prototyp przed zamówieniem płytek :)
Dzięki x_angelowi kartridż z prostym inwerterem zadziałał! Dwie pierwsze fotki są z jego pola bitwy:
Rozwiązanie okazało się bardzo proste. Należy dodać kondensator 1nF równolegle do rezystora R1. X_angel mówi, że inwerter działa zbyt wolno, a kondensator go "przyspiesza".
Uwzględnię dodatkowy kondensator w projekcie, a na już zamówionych płytkach dolutuję go w następujący sposób:
Zaprogramowałem adapter pada od SNESa. Te pady są łatwe do obsłużenia. W środku znajduje się rejestr przesuwny, który szeregowo przesyła dane o tym, które przyciski są wciśnięte.
Atmega8 wydaje się dobrym procesorem do adaptera, gdyż gniazdo joysticka w Atari 2600 nie ma zbyt dobrej wydajności prądowej i inne procesory (SAMD21, Pico, ESP32) mogłyby wcale nie zadziałać...
Zaktualizowałem projekt płytki drukowanej kartridża, dodając kondensator, dzięki któremu działa inwerter.
Zmiana jest kosmetyczna. Kondensator lutuje się od drugiej strony płytki:
Dziś chciałem kontynuować pracę nad głównym programem gry. Jednak zamiast tego 3 razy sprawdziłem, czy z projektem adaptera wszystko w porządku i zamówiłem płytki :)
Wróciłem do głównego programu, czyli gry. Dodałem wstępną wersję "animiacji" straconego motylka.
Nie wspominałem o tym wcześniej, ale zamierzam użyć obudów od Sikor Soft do kartridży. Są bardzo dobrej jakości, zrobione na wtryskarce, a nie za pomocą druku 3D. Sprawdziłem, czy płytki pasują:
Pasują idealnie!
Obudowy istnieją w dwóch kolorach - czarnym i białym. Białe bardziej pasują mi do Berty.
Dodałem animację utraconego motylka. Nie jestem z niej w pełni zadowolony i prawdopodobnie później ją trochę dostroję.
Dodałem też funkcję "końca gry". Kiedy stracisz życia, nowe motylki się nie pojawią.
To dobre wiadomości. Zła wiadomość jest taka, że zostało mi tylko 855 bajtów! Chciałbym dodać co najmniej ekran tytułowy z muzyką i dwa poziomy trudności... Mam nadzieję, że te 855 bajtów mi wystarczy.
Od teraz motylki są uwalniane z rosnącą prędkością, gra stała się trudniejsza.
"Pauzujące" źródło motyli zmienia się po każdej utracie życia.
Udostępniłem obecną wersję współpracownikom z mojego zespołu. Grali w online'owym emulatorze Javatari. Oto aktualny, najwyższy wynik:
Dodałem drugi poziom trudności, dostroiłem trochę prędkość, dodałem opcję wyłączenia dźwięku.
Mimo, że zastosowałem kilka optymalizacji, zostało mi już jedynie 778 bajtów.
Dziś dodałem ekran tytułowy. Na razie w wersji polskiej. Jak się podoba?
Dodałem muzykę tytułową. Aczkolwiek, na moje ucho jest trochę za szybka.
Zdołałem spowolnić muzyczkę tytułową i sprawić, że brzmi tak, jak chciałem.
Kiedy gra się zakończy, można teraz wrócić do ekranu tytułowego i zacząć ponownie.
Dziś dodałem ekran tytułowy w wersji "międzynarodowej":
Dodałem sposób na rozróżnienie, który poziom trudności jest ustawiony. W poziomie "łatwym" siatka jest żółta. W "trudnym" jest czerwona.
Dodatkowo, jeśli na ekranie tytułowym chmurka jest nad literą "B", oznacza to, że jest ustawiony poziom "łatwy" (z ang. "beginner"). Kiedy jest nad literą "A", mamy poziom "trudny" ("advanced").
Dziś 50-ty dzień konkursu 100 Commitów. Pomyślałem, że to dobra okazja, aby wydać pierwszą wersję beta gry - obecnie jest już całkiem grywalna. Udostępniłem ROM tu i ówdzie i czekam na feedback.
Wykonałem też kolejny kartridż, aby pograć na prawdziwej konsoli:
Wrażenia pierwszych grających są pozytywne. Z uwag - brakuje napisu "game over" na koniec. Nie wiem, czy go dorobię, czy wystarczy mi miejsca w ROMie i czy w ogóle chcę to robić - w oryginale na koniec był tylko sygnał dźwiękowy.
Zebrałem kilka raportów z wyników i rekordziści zebrali powyżej 400 motyli!
Sam znalazłem jednego buga związanego z kolorowaniem siatki. Nie był to na szczęście błąd krytyczny, no i już go poprawiłem.
Dziś nic spektakularnego - testy, testy i jeszcze raz testy. Mój osobisty rekord to 640.
Właśnie dostałem przesyłkę z płytkami do adaptera kontrolera od SNESa! Czuję się, jakby była gwiazdka!
Zbudowałem pierwszy adapter (zgadnijcie, czemu jest czerwony?):
Pomysł polega na wykorzystaniu strzałki w górę, w dół oraz przycisków "X" i "B", aby łatwo poruszyć Bertę w pożądanym kierunku.
Adapter działa! Nie zadziałał za pierwszym razem, ale musiałem poprawić jedynie numery pinów w kodzie źródłowym i zrekompilować go.
Próbuję zrobic jakąś grafikę na okładkę. Na razie mam taką wersję roboczą:
Rozwinąłem oprogramowanie dla adaptera pada. Jeśli założy się zworkę, kontroler zadziała jako "normalny" joystick - kierunki i "Y" jako "fire".
Zacząłem zamieniać wywołania pfpixel na bezpośrednie manipulacje zmiennymi pola gry. Dzięki temu oszczędzę trochę miejsca w ROMie.
Berta pojawiła się w programie ZeroPage Homebrew! Możecie zobaczyć ostatni odcinek tutaj: https://youtu.be/SA3xd5n5TF4?t=3413
Próbowałem odsyzkać trochę miejsca w ROMie, ale bez sukcesu. Mam jednak pomysł jak to zrobić.
Zaimplementowałem zapamiętywanie najwyższych wyników dla trybu "łatwego" i "trudnego". Musiałem w tym celu zwolnić dwie zmienne, bo użyłem już wszystkich możliwych.
Zapamiętywanie wyników nie jest permanentne. Mogłoby być, gdybym zaimplementował obsługę zewnętrznego urządzenia SaveKey, ale na to nie starczy mi miejsca w ROMie. Mimo optymalizacji, zostało mi tylko 26 bajtów...
Wgrałem aktualną wersję gry na kartridż i testowałem na prawdziwej konsoli. Po niedawnej poprawce dotyczącej limitu motyli, gra stała się za trudna. Dostrajam poziom trudności.
Dalej dostrajam poziom trudności...
Pobawiłem się trochę Leonardo AI. Wypróbowałem funkcję generowania obrazu na podstawie innego obrazu, aby przerobić mój rysunek Berty. Oto kilka wyników. Dobra, jeden z nich nie był na podstawie innego obrazu :) A pierwszy to ten oryginalny.
 |
 |
 |
 |
 |
 |
Próbowałem zmienić "animację" straconego motylka, ale na koniec wycofałem wszystkie zmiany :) Jestem zbyt przyzwyczajony do oryginalnej.
Dziś w Polsce mamy święto, także robię sobie dzień wolny.
Zaimplementowałem sygnał dźwiękowy na koniec gry. Miejsca w ROMie starczyło mi na cztery dźwięki - na pięć już nie.
Zrobiłem Bercie sesję fotograficzną. Zdjęcia mają być bazą do rysunku na okładkę kartridża.
 |
 |
Postanowiłem zrobić właściwą wersję PAL gry. Do tej pory pracowałem z wersją NTSC, co jest wygodniejsze. Dla przykładu, NTSC jest domyślna w emulatorach.
Problem polega na tym, że w NTSC mamy 30 klatek na sekundę, a w PAL 25. Należy dostosować czasy różnych wydarzeń, aby wersja PAL działała z taką samą prędkością, jak NTSC. Należy też zmienić kolory, bo palety kolorów są zupełnie inne w PAL i NTSC.
Wciąż dostosowuję timingi wersji PAL...
Wersja PAL ukończona! Poza samym tempem muzyczki tytułowej, wylatywania motyli itp. musiałem dostosować także poziom trudności.
Berta trafiła na AtariOnline! Dalton robi grę na A2600
Zrobiłem też nowy release v0.80.rc1. Gra jest właściwie skończona i nawet, gdybym chciał, nic już więcej nie zmieszczę - zostało 14 bajtów ROMu :)
Wczorajszy artykuł na AtariOnline zainspirował użytkownika Santyago do stworzenia za pomocą AI takich ładnych obrazków:
 |
 |
 |
Wciąż próbuję wykonać rysunek Berty. Oto jeden, bazujący na zdjęciu:
Wyeliminowałem użycie zworki w adapterze kontrolera od SNESa. Tryb działania zmienia się teraz wciskając jednocześnie Start i Select. Wybrany tryb jest przechowywany w EPROMie Atmegi.
Wciąż próbuję zrobić rysunek Berty, który byłby na tyle dobry, abym go użył na okładkę kartridża. Eksperymentuję z Leonardo AI, aby wykonać obrazek na bazie mojego obrazka. Oto kilka rezultatów.
 |
 |
 |
 |
 |
 |
Poprosiłem kolegę Xeda, który ma konto premium w Leonardo AI, aby poeksperymentował z obrazkiem Berty używając innych narzędzi (na przykład "Content Reference"). Oto kilka jego wyników:
 |
 |
 |
 |
Sporo ludzi grało w Bertę! Wśród nich był Milan Galcik i X_angel, który przysłał mi to zdjęcie:
Na razie nikt nie miał problemów, nie dostałem żadnego zgłoszenia buga. Myślę, że wkrótce wydam wersję finalną!
Istnieje urządzenie o nazwie SaveKey dla Atari 2600. Podłącza się je do portu joysticka gracza drugiego i niektóre gry (około 40) są w stanie zapisać na tym najlepsze wyniki.
Co prawda nie mam już wolnego miejsca w ROMie, chciałem się pobawić SaveKeyem. Jest to bardzo proste urządzenie i można znaleźć jego schemat w Internecie. Zaprojektowałem własną płytkę drukowaną jakiś miesiąc temu i dziś dotarła!
Zbudowałem SaveKeya:
i przetestowałem go na grze "Fall Down". Zadziałał poprawnie!
Dziś z żoną wybraliśmy się na jubileuszowe spotkanie toruńskiego Java User Group. Spotkałem kilku znajomych ze studiów i niektórzy pytali o Bertę! Było to bardzo miłe :)
Poeksperymentowałem z SaveKeyem. Nie ma problemu z implementacją wsparcia dla niego, ale wyszedłbym poza 4KB... Nie widzę możliwości optymalizacji mojego kodu, a zapisywanie najwyższych wyników nie jest dla mnie niezbędne, więc ostatecznie zdecydowałem, że nie będę wspierał SaveKeya.
Jednakże, mam kolejny pomysł. EPROM w SaveKeyu używa protokołu I2C. Tego samego protokołu używają układy RTC. Mógłbym wyświetlać aktualną godzinę na planszy tytułowej - nazwa "Game & Watch" zobowiązuje ;) Do implementacji tego pomysłu potrzebowałbym zaprojektować kolejną płytkę drukowaną, no i oczywiście to także wymagałoby więcej niż 4KB ROMu. Poeksperymentuję z tym pomysłem, jednak to też nie jest niezbędna funkcjonalność. Może kiedyś wydam 8-kilobajtową wersję deluxe ;)
Zacząłem pracę nad właściwą etykietą na kartridż. Dokładniej mówiąc, stworzyłem SVG z warstwami - jedną widzialną, a drugą z wykrojem dla maszyny tnącej.
Kontynuuję pracę nad etykietą. Oto wynik:
Jestem zadowolony z okładki. Problem z okładką jest taki, że drukarnie oczekują warstwowych plików PDF, a nie SVG. Z kolei Inkscape, w którym tworzyłem okładkę, nie potrafi wyeksportować warstwowego pliku PDF... Walczyłem trochę próbując, ale bez rezultatu...
Poprosiłem znajomego, Bartasa, aby przekonwertował mi pliki SVG na PDF. Robił to dla mnie już wcześniej, gdy wydawałem grę "Invaders from Andromeda" autorstwa Cisano. Wówczas użył wersji trial programu Adobe Illustrator. Trial jednak wygasł i szuka innych opcji :)
Bartas na razie nie znalazł innej możliwości przekonwertowania SVG na PDF, niż Illustrator. Ale jeszcze powalczy. Ja też jeszcze powalczę.
Zacząłem projektować zegar dla Atari 2600. Eagle mnie trochę zawiódł, bo w jego bibliotece komponentów brakowało układu DS1307, który chciałem wykorzystać...
Zamiast układu DS1307 użyłem generycznej podstawki DIL8. Brakuje mi jednak gniazda na baterię, ale powinienem je znaleźć w jakiejś bibliotece komponentów. Chociaż zegara DS1307 nie znalazłem...
Wciąż usiłuję zrobić pliki PDF z okładką, gdyż chciałbym lada chwila zamówić ich wydruk. Słyszałem, że Scribus potrafi zrobić warstwowe pliki PDF. Okazało się, że nie jest w stanie prawidłowo otworzyć moich SVG...
Bartas odkopał oryginalną, pudełkową wersję pakietu Adobe Creative Suite 3 z wieczystą licencją i mi pożyczył. Mimo, że to wersja z 2007 roku, bez problemu utworzyłem w niej właściwe pliki PDF. Jutro zamówię wydruki.
Wydruki zamówione!
Wykonałem też prototyp zegara dla Atari 2600, z kwarcem przylutowanym bezpośrednio do nóżek układu scalonego:
Dziś mamy święto, więc też zrobiłem sobie wolne. Nie mogę się doczekać wykruków!
Analizowałem protokół I2C i myślałem, w jaki sposób zmodyfikować metody do komunikacji z SaveKeyem, aby komunikowały się z układem zegara. Problem w tym, że jeśli coś zaimplementuję, muszę to wgrać na EPROM i uruchomić na prawdziwej konsoli. Jeśli nie zadziała właściwie, muszę ponowić cały proces, a jest to bardzo czasochłonne. Dlatego przygotowuję się solidnie, aby takich iteracji nie było zbyt wiele.
Próbowałem pobrać sekundy z DS1307 i wyświetlić je jako wynik, ale bez rezultatu. Na razie użyłem 3 EPROMy :)
Czytałem o układzie DS1307. Myślałem, że bateria jest mu potrzebna tylko jako backup, aby godzina odliczała się, gdy nie ma włączonego głównego zasilania. Okazało się, że jest niezbędna! Być może komunikacja z zegarem jest zaprogramowana właściwie. Niedługo podlutuję baterię i sprawdzę to.
Zdołałem naprawić dwie z moich sowieckich konsolek! Wymieniłem gumki przewodzące, przeniosłem ekrany pomiędzy konsolkami, a oto rezultat:
To prawda - bateria jest niezbędna, aby DS1307 działał. Przylutowałem ją:
i napisałem prosty program komunikujący się z DS1307 przy użyciu protokołu I2C i wyświetlający godzinę, minuty i sekundy jako liczbę punktów: https://youtube.com/shorts/fulqg-NeGTo?feature=share
Zacząłem od wykonania kolejnego kartridża dla szybkiego prototypowania. Programowanie EPROMów ciągle od nowa i kasowanie ich przez pół godziny jest zbyt czasochłonne. Wykorzystałem jedną ze starszych płytek drukowanych, która przeznaczona jest na 128 4-kilobajtowych gier na EPROMie 27C4001. Ten EPROM jest prawie pin w pin zgodny z pamięcią flash 39SF040, która nie wymaga kasowania, dzięki czemu mogę pracować efektywniej. Musiałem tylko dokonać kilku małych modyfikacji:
Wczoraj odebrałem naklejki na kartridże!
A teraz zrobiłem pierwszy kartridż w docelowej formie:
Obecnie uzupełniam dokumentację. Zaprojektowałem też przód i tył pudełka. Planuję użyć takiego pudełka: https://www.dpcraft.pl/pl/produkt/pudelko-tekturowe-18x14x4-cm.html. Oto projekty - na ten moment wyłącznie po polsku:
| Przód | Tył |
|---|---|
 |
 |
Wykonałem pierwszy prototyp pudełka:
Jednak nie jestem zadowolny z wyniku. Tylna układka jest trochę za duża, a kolory części przedniej na wydruku wyglądają inaczej niż te same kolory na części tylniej.
Dziś ostatni dzień konkursu! Uzupełniam dokumentację, promuję projekt w portalach społecznościowych itp. Na szczęście moja gra jest ukończona. Jak powiedział Steve Jobs, "it's not done until it ships" (Ciężko to przetłumaczyć, ale spróbuję: "Nie jest ukończone, dopóki nie będzie dostarczane"). Oznacza to, że dowiozłem projekt w 100 dni, gdyż zamierzam rozsyłać kartridże od poniedziałku ;)
Dodałem angielską wersję projektów pudełka.
Etap głosowania w konkursie zakończył się wczoraj, a oto wyniki!
Jednak nie znaczy to, że wygrałem. Teraz Jury wybierze zwycięzcę spośród tych 10 projektów. Ale miło było zobaczyć Bertę na pierwszym miejscu. Oznacza to, że inni zawodnicy docenili mój projekt. Dziękuję!
Dziś imieniny mojej żony. Zrobiłem dla niej pierwszy właściwy egzemplarz pudełkowej wersji gry "Berta i motyle":
Zdołałem ustawić zegar z poziomu programu na Atari! Na ten moment napisałem osobny program do eksperymentów z zegarem, ale będę mógł powstałe metody użyć także w rozszerzonej wersji gry.
Projekt "Berta i motyle" zajął pierwsze miejsce w konkursie "100 commitów"!
Bardzo się cieszę! Do Torunia wróciłem z Macbookiem Pro, ale nie o nagrodę w tym wszystkim chodziło. Dużo cenniejsza jest wiedza, jaką nabyłem przez te 100 dni konkursu, a także nowe znajomości.
Wciąż trochę nie dowierzam, że w konkursie programistycznym XXI wieku wygrała gra na konsolę z 1977 roku!
Przyznam, że początkowo w ogóle nie chciałem brać w tym wszystkim udziału. Pomyślałem, że dowolność wyboru tematu projektu oznaczać będzie, że wybór zwycięzców stanie się zbyt subiektywny. Ale szybko się opamiętałem i właśnie dowolność tematu zacząłem odbierać jako największą zaletę konkursu. Od roku chodził za mną pomysł napisania czegoś na Atari 2600, a skoro temat może być dowolny, to dlaczego nie spróbować w ramach konkursu? Konieczność commitowania każdego dnia wykorzystałem jako czynnik dyscyplinujący.
Gratuluję wszystkim, którzy przetrwali 100 dni. O poziomie konkursu niech świadczy fakt, że w finałowym głosowaniu jurorów głosy zebrało aż 7 różnych projektów z finałowej dziesiątki! Mimo, że "jechałem z pole position", do ostatniej chwili wcale nie byłem pewien, że wygram też w ostatnim etapie.
Dziś zamówiłem płytki do układu zegara.
Wyprodukowałem kolejne kartridże z Bertą. Wyślę je niebawem, także zagranicę!
Dotarły płytki do budowy układu zegara!
Od razu polutowałem pierwszą. Działa tak samo, jak działał prototyp, czyli jest dobrze :)
