Przedstawiam opis konstrukcji konsoli Pegasus z 4 procesorami – PAL/NTSC do wyboru, gniazdami na kardridże 60 pin (Pegasus) oraz 72 pin (NES), gniazdami na dżojstiki wąskie (9 pin), szerokie (15 pin), rozszerzeń (15 pin) oraz NESowe. A to wszystko z krystalicznym dźwiękiem i obrazem.
Wstęp i motywacja
Budowa własnej konsoli PEGASus chodziła za mną od dłuższego czasu. W oryginalnych konsolach mamy procesor CPU (UA6527P) oraz PPU (UA6538) napędzane kwarcem 26.601712 MHz i generujących obraz w systemie wideo PAL. Są jednak gry, których szybkość dostosowana jest do innego systemu – NTSC, a są też gry, które w ogóle nie działają w NTSC lub odwrotnie (np. Asterix). W większości dobrych emulatorów NESa mamy nawet do wyboru jeden z dwóch trybów wideo. Kiedyś kupując układy scalone, dostałem UA6527 zamiast UA6527P. Długo zastanawiałem się, czym on się różni od UA6527P, aż w końcu wyszukałem, że to procesor CPU do wersji NTSC. Napędzany standardowym kwarcem od Pegasusa (26.601712 MHz) nadawał dźwięk o oktawę wyższy. W międzyczasie trafiłem na taki schemat:
I wyjaśniło się, że do pary jest także UA6538, który jest procesorem graficznym dla NTSC. Całość napędzana powinna być kwarcem 21.57727 MHz.
W międzyczasie jeszcze zauważyłem, że chińczyki sprzedają coś takiego jak UA6528P – jest to podobno wersja PAL na 60 Hz – jak w Brazylii/Argentynie (PAL/M). Jak kiedyś kupię, to będziemy testować.
Potem wpadłem na pomysł, aby do konsoli dodać dwa gniazda kardridży – Pegasusowe (60 pin) oraz NESowe (72 pin), aby można było grać we wszystkie gry bez adapterów.
Podobny pomysł przyszedł mi do głowy w sprawie joysticków – połowa padów ma gniazda 9-pinowe, druga połowa 15-pinowe, są też joysticki NESowe – wszystko to sprawiło, że w konsoli powinny się znaleźć wszystkie możliwe kombinacje. I tak też się stało!
Początki budowy
Generalnie, cala konsola składa się z:
* CPU PAL (UA6527P) i PPU PAL (UA6538) napędzanych kwarcem 26.601712 MHz (4.43361875 MHz – częstotliwość nośna PAL , 26.601712 Mhz / 4.43361875 MHz = 6)
* CPU NTSC (UA6527) i PPU NTSC(UA6528), napędzanych kwarcem 21.67727 MHz. (3.579545 MHz – częstotliwość nośna NTSC, 21.57727 MHz / 3.579545 MHz = 6)
Mój schemat budowy (rysunki wyżej) jest identyczny, jak na krążącym po sieci schemacie Famicona, więc całości nie będe opisywał, powiem jedynie, że:
* jako pamięć wewnętrzną RAM dla CPU/PPU zastosowałem SRAM 62256 – bo taką akurat miałem),
* zmieniłem trochę połączenia do zatrzasku 74HC373, aby uprościć prowadzenie ścieżek,
* jest możliwość podpięcia mikrofonu (jak w padach od Famicona!),
* gniazda od NESa posiadają połączone wszystkie piny, w tym 4016_RD_D4/D3 oraz 4017_RD_D4/D3, umożliwia to więc połączenie bez problemu adaptera od NESa dla czterech graczy (NES 4-score).
Więcej uwagi wymaga natomiast opis przełącznika CPU PAL/NTSC oraz PPU PAL/NTSC. Jest to pierwsza tego typu konstrukcja na świecie, więc musiałem przetrzeć szlaki.
Początkowo oba procesory CPU były połączone równolegle (tj. wszystkie ich wejścia/wyjścia, z wyjątkiem: CLK, SOUND1, SOUND2, !RESET) połączone ze sobą, natomiast przełącznik CPU PAL/NTSC podawał na pin !RESET wybranego procesora stan wysoki, natomiast procesor nieaktywny miał linię !RESET aktywną. Przełącznik też przekazywał dźwięk z wybranego procesora na wyjście.
Podobnie zresztą połączone były procesory PPU – tutaj przełącznik oprócz podawania !RESETU, przekazywał sygnał wideo na wyjście z wybranego procesora.
To rozwiązanie oczywiście miałoby szansę działać poprawnie (bez zwarć) tylko, gdyby oba procesory zachowywało się „ładnie”, tj. w czasie resetu miały wszystkie wyjścia w stanie wysokiej impedancji (odcięte). Jak było naprawdę?
Pierwsze uruchomienie
Płytka drukowana (dwuwarstwowa), którą wykonałem była największą do tej pory stworzoną i wytrawioną przeze mnie, zarówno jeśli chodzi o rozmiar, skomplikowanie (ilość układów), jak i ilość przelotek.
Pierwsze uruchomienie oczywiście nie obyło się bez problemów. Dopiero po usunięciu kilkunastu minizwarć wynikłych albo z niedotrawień, albo powstałych już podczas lutowania oraz kilku niedolutowanych połączeń, coś tam działało. Początkowo testowałem na jednym CPU i jednym PPU i funkcjonowało. Na dwóch CPU i jednym PPU także działało, ale przy dwóch PPU konsola przestała generować obraz. Dopiero potem po zbadaniu przebiegów okazało się, że PPU wcale nie zachowuje się tak ładnie jak myślałem – podczas resetu jego magistrala adresowa, danych, sygnały sterujące wcale nie są w stanie wysokiej impedancji.
Już chciałem wszystko rzucić w kąt, bo wymagałoby to pewnie zaprojektowania i stworzenia płytki od nowa, ale w końcu.. Wpadłem na pomysł, że mogę stworzyć adapter, który będzie można wetknąć w miejsce oryginalnych dwóch PPU, sam zaś będzie posiadał bufory (po dwa na każdy PPU), które będą przekazywać dalej sygnały z magistrali tylko tego wybranego PPU! Przekazywane by były sygnały !RD, !WE, AD0-AD7, A8-A13, ALE. Sygnałów jest 17 (sic) a standardowy bufor (74XX245) przekazuje do 8 sygnałów, więc trzebaby dać po 3 bufory na PPU. Do tego jeszcze potrzeba negatora. Ale wpadłem na pomysł, że oprócz dwóch buforów (74XX245), ostatni z sygnałów będzie przekazywany mniejszym buforem (74XX125), który też może pełnić rolę negatora! To wszystko doprowadziło do powstania takiego fajnego-adapterka:
Wykonanie tego było sporą mordęgą, bo należało dostosować rozstaw, aby wszedł w oryginalne podstawki (goldpiny), dodatkowo należało zmieścić gniazdo na dwa PPU oraz dwa bufory pod nimi. W efekcie straciłem na tym cały dzień, bo do zwykłych podstawek DIL musiałem dolutowywać druciki, aby przedłużyć ich nóżki. W ramach taniości zastosowałem wylutowane z jakiejś starej płyty głównej układy 74F245. Układy musiały być gęsto obok siebie ułożone, więc musiałem delikatnie zeszlifować obudowę z boku. Efekt był taki, że wszystko i tak nie działało, ale nie wiedziałem dlaczego.
Dopiero potem mnie olśniło, a późniejszy eksperyment to potwierdził. Zastosowane układy 74F245 są z rodziny F, czyli bipolarne (szybkie LS). Układy pobierają znaczny prąd swoimi wejściami (a nie jak w CMOSach – prawie zerowy). Jedno z wejść układu było na masie, ale nie stałej, tylko przez rezystor ściągający 10k do masy (tak to zaprojektowałem). Wejście takiego układu pobiera prąd ok. 0.38mA, zgodnie z notą katalogową. Przepływ takiego prądu przez rezystor 10k spowoduje odłożenie na nim 3.8V, co sprawia, że ze stanu niskiego robi się stan wysoki!
Potem zamieniłem układy F na HCT, ale nadal nie działało. Dopiero potem zorientowałem się, że podstawka do zamontowania w konsoli została zamieniona z podstawką do zamontowania układu. Ze złości wywaliłem całość i zaprojektowałem adapter od nowa, zwiększając odstępy między scalakami oraz przesuwając je do góry – teraz wszystko mieści się idealnie pod podstawką DIL40 (środkową poprzeczkę zostawiam, aby trzymała sztywność, a dwie skrajne wyłamuje):
Takie cudo wymaga specjalnej kolejności lutowania, bo jak najpierw przylutuje goldpiny, to już potem nie dostane się z lutownicą do środka, aby przylutować podstawki!
Tym razem po wmontowaniu działało, ale.. jakoś dziwnie. Po włożeniu obu PPU, na jednym CPU działało, na drugim nie. Zacząłem oglądać pod analizatorem logicznym, długo siedziałem i patrzyłem, aż zobaczyłem, że.. PPU na magistrali, która łączy go z CPU także zachowuje się brzydko: gdy jest w stanie resetu, ale jest wybrany - PPU_CS=0 (pin13), to wtedy wystawia on na magistralę danych same zera. Znowu byłem zły i nie wiedziałem, jak to rozwiązać: lutować kolejny trzeci bufor dla każdego PPU? To wymagałoby projektowania kolejnego adaptera.. W końcu następnego dnia wpadłem na ciekawy pomysł. Jeśli PPU jest w stanie resetu, ale PPU_CS=1, to PPU nam na magistrali nie bruździ. Wystarczy więc, aby gdy PPU jest w stanie resetu, zawsze mu ustawiać PPU_CS = 1.
Nie chciałem lutować kolejnych scalaków, które by tą funkcję logiczną realizowały. Przypomniałem sobie, że na PCB mam wlutowany cztery bramki NAND, z których tylko jedna jest użyta (jako inwerter), pozostałe są wolne. Zacząłem sobie przypominać z pierwszego roku studiów jak realizowało się funkcje logiczne na bramkach i po kilku minutach miałem już gotowy przepis:
I akurat do jego realizacji potrzeba trzech bramek NAND! Wystarczy przeciąć dwie ścieżki na PCB, kilka połączeń kynarem i.. może zadziała.
Po kilkunastu minutach – włączam konsolę i sprawdzam. Efekt? Wreszcie po kilkunastu dniach wszystko działa!
Efekt końcowy:
Ciekawostki:
Do gniazd kardridży Pegasusa (60 pin) można wykorzystać gniazdo ISA z płyty głównej (8 bit) – nadmierną parę pinów należy wyciąć.
Do gniazd kardridży NESa (72 piny) też można wykorzystać gniazdo ISA z płyty głównej (16 bit) – należy odciąć niepotrzebną część z podziałką w środku, a gniazdo pod kardridż złożyć z dwóch kawałków:
Jako bolce do gniazd na pady od NESa można wykorzystać bolce z wtyków D-SUB montowanych na kabel:
Gry w PAL mają na moim telewizorze czarny pasek na górze i dole:
Podczas gdy gry w NTSC zajmują pięknie cały ekran:
Ponadto gry w NTSC mają troszkę bardziej stonowane kolory:
niż w PAL:
Dużo bardziej widać to np. w Fantastic Adventures of Dizzy (BLUE) gdy na NTSC kolory są ciepłe, a gra działa bez żadnych artefaktów graficznych:
a w PAL - trupio-sinio-zimne, przy scrollbarze widać artefakty:
Z kolei procesor graficzny w NTSC ma chyba jakiś problem ze stabilnością (albo mój telewizor, albo kwarc jest niestabilny) w kilku górnych liniach obrazu pionowe linie "gną" - widać to na liniach drzewa. W kolejnych liniach ekranu telewizor się "dosynchronizowuje":
Zapraszam do oglądania filmu:
Fajne? Ranking DIY