Kilka lat temu opracowałem pierwszą wersję własnej architektury procesora zgodnego z MOS6502. Założenie było proste: utrzymać jak największą zgodność z oryginałem, przy możliwie najmniejszym stopniu zużycia dostępnych zasobów najmniejszego, dostępnego układu FPGA. Projekt dość szybko zyskał wybitnie "szufladowy" charakter.
Wszystko zaczęło się zmieniać w okolicach końca ubiegłego roku. Trafiłem na prezentację człowieka, skojarzonego z grupą ludzi odpowiedzialnych za reverse engineering oryginalnego produktu. W swoim wystąpieniu rzucił światło na bardzo istotny fakt, mianowicie moje założenia dot. obszaru dekodera instrukcji mocno pokrywały się z założeniami autorów oryginalnego proca.
Tyle mi wystarczyło. Postanowiłem wrócić do pracy w tym zakresie i - jak to często bywa - w konsekwencji zaprojektowałem coś zupełnie nowego, trzymając się starych przemyśleń i ... narzędzi, które stworzyłem na potrzeby rozwoju poprzedniej wersji
Implementacja wypada bardzo dobrze na tle podobnych - zarówno pod względem ilości wykorzystywanych zasobów logicznych, jak i pod względem czasu propagacji przez "krytyczną" ścieżkę kombinatoryczną (rzutującego na maksymalną częstotliwość pracy układu).
Najważniejsze jest jednak to, że całość została przetestowana w realnym środowisku. Myślę, że w tym miejscu tekstu postać samego środowiska staje się dość oczywista :).
Świetny projekt. Czy kompatybilność jest 100%? Rozkazy niepublikowane zachowują się jak należy? Dla jakich częstotliwości Twoje CPU może pracować poprawnie?
Ale, że wszystkie???? ;) Na moim Atari łatwo dało się stwierdzić, że kod wpadł w CIM, bo słyszalnie zmieniał się dźwięk :) Obraz generował się poprawnie, ale słychać było że CPU nie pracuje.
Edit: Tzn. układy pracowały poprawnie (dźwięk też), ale zakłócenia były wyraźnie inne - uboższe :)
Procesor realizuje prawidłowo wszystkie instrukcje ze zbioru, który osobiście uznaję za "oficjalny".Charakteryzuje się jednak bardzo dużą elastycznością. Nic nie stoi na przeszkodzie, aby bez większych zmian konfiguracji logicznej, dołożyć operacje uwzględnione przez producentów takich jak WDC. Wynika to z dwóch aspektów: Po pierwsze pojedynczy BRAM układu FPGA pełni funkcję dekodera instrukcji (sprawa wygląda analogicznie w oryginalnym układzie, jednak nie analizowałem materiałów badawczych, związanych z rev-eng. W konsekwencji sygnały dekodera muszą być odmienne). Po drugie - istnieje mechanizm mikrokodowania, zwiększający swobodę definiowania trybu adresowania dla każdej instrukcji. Wszelkie PHY/PHX/PLY/PLX/JMP(a,x) itp. wymagają w istocie jedynie ustalenia właściwej postaci właściwych wektorów, przenoszących obecnie konfigurację dla instrukcji NOP. Napisałem też kawałek softu, który to ułatwia (choć przy ok. 150 instrukcjach, bez interpretacji składników konkatenacji jest nieco "upierdliwy"). Dla zachowania wysokiej zgodności z oryginałem, nie wprowadziłem przetwarzania potokowego w obszarze asynchronicznym, który trochę się o to prosił (ALU - ADC/SBC bin/BCD). Mimo to, procesor powinien pracować prawidłowo przy ok. 70MHz (to dane dla obecnie zastosowanego, obecnie nieco leciwego układu FPGA). Układ eksploatuje ok. 105 przerzutników i 35% zasobów LUT najmniejszego spartana, którym dysponuję (XC3s50AN). To dobry wynik, choć dalsza optymalizacja jest cały czas możliwa. Przy okazji należą się podziękowania dla Pasia : bazowałem na opisach produktów niezwiązanych z Atari. Przy projektowaniu PCBka nie uwzględniłem prawidłowej obsługi sygnału HALT (dlatego na zdjęciu widać małą płytkę, podwieszoną do głównego modułu na kynarze).
Uczciwie przyznam, że nie zgłębiałem problemu nieopublikowanych instrukcji w sensie NMOSa z ataryny. Jeśli chodzi o "dziwaczne" rozkazy typu "LAX" - tak. Ten układ to zrealizuje bez problemu. Domyślam się oczywiście, że chodzi o grubszy temat. Mogę szukać materiałów w sieci, tylko po co? - przecież jestem u źródła:)
Bardziej kusiło mnie rozszerzenie funkcjonalności ALU. Instrukcje MUL/DIV nigdy nie istniały, a przecież szkoda. Przy ułańskiej fantazji można pójść w mnożenie z akumulacją (lol), tyle że to już przerost formy nad treścią. Głównym celem wrzucenia przedstawianego prototypu do ataryny było potwierdzenie prawidłowości działania zaprojektowanego procesora. Wszystko ładnie wygląda w symulatorze, na oscyloskopie/w analizatorze stanów logicznych, ale przecież jedynie "twardy" test ma szansę pokazać, czy dana konstrukcja jest coś warta, czy nie. No i proc wcale nie poszedł tak "od pierwszego kopa". To potwierdza jedynie słuszność przyjętej koncepcji.
Bez halt, do Commodore się nadaje już, po pełnej obsłudze halta i do Atari;)
70 MHz? Nieźle ;) Dla osób niezorientowanych: wyciśnięcie tych 70 MHz w real Atari na razie jest niemożliwe, bo będzie go spowalniał cały sprzęt. W tym celu potrzebne są kolejne modyfikacje. Nie mniej interesująco to wygląda;)
tdc: Super! Dzięki za uwidocznienie fotek. Bardzo słusznie podkreśliłeś, że szacowane możliwości samego rdzenia nie dotyczą maksymalnej częstotliwości pracy w przedstawianym środowisku.
Jak już ruszy pełne 70 MHz to można się pokusić o uruchomienie emulatora Atari na Atari ;):):)
Kwestia HDMI przy komercyjnym zastosowaniu staje się zbyt bardzo komercyjna, tzn. nieopłacalna. Aby użyć HDMI trzeba uiścić dwie opłaty, druga bardziej ukryta powoduje że całość przestaje się opłacać (szczególnie w zastosowaniu dla takiej społeczności jak nasza, która raczej liczy się z ceną...).
Nie ma sprawy, aby dodać fotki z netu wystarczy wkleić adres do postu, jeśli jest to załącznik z Twojego postu to trzeba opublikować post kliknąć w załącznik i skopiować jego adres do postu, a następnie na końcu dodać odpowiednio ".jpg", ".png", ".gif" itp.
@ kosa0, ja mówię o praktyce, że zamontowanie HDMI w swoim urządzeniu (czym by ono nie było) słono kosztuje i tyle. To się faktycznie przełoży że przy wyprodukowaniu np. 100-200 urządzeń (bardzo dużo jak na nasze możliwości), cena każdego wzrośnie o kilkaset złotych + faktyczny koszt części, robocizny itp. To trochę "niepraktyczne", skoro dzisiejsze urządzenia są dość drogie, jeśli samo HDMI ma zwiększyć ich cenę o 50% a nawet więcej obecnej ceny to dziwnie to wygląda...
@mav szczeze to dawno nie widzialem w tv YpbPr ale moze sie myle- zbyt dokladnie sie nie przygldalem - w najblizszy weekend nadrobie to i w skleie nie dla idiotow przypatrze sie co teraz tv oferuja :-)
W przedmiocie HDMI: Jest dokładnie tak, jak pisze tdc. Wszelkie konsorcja, odpowiedzialne za standardy transmisyjne(HDMI/HD-SDI/MIPI itd.) są w ogólności nastawione na czerpanie zysków w opisywanym trybie. Oczywiście należy dokładnie zbadać, o jaki charakter chodzi (Tutaj m.in. nie jestem pewien, czy urządzenie wyposażone jedynie w stosowne gniazdo, jest rozpatrywane odmiennie od takiego, które ma zadeklarowaną zgodność ze standardem HDMI, zaliczone compliance testy itp.). Samo pozyskanie dokumentacji nie jest proste, choć w przypadku TMDS (HDMI) pewne rzeczy zostały uwolnione (HDMI 1.1)
Nie tyle w zamian, co proponuję aby nasi elektronicy pokusili się o założenie stowarzyszenia, które wykupi możliwość montowania HDMI, tak aby każdy z osobna mógł je montować (nie wiem jak to prawnie wygląda, trzeba to sprawdzić). Jednak takie rozwiązanie spowoduje że co prawda i tak opłaty uiścić trzeba, ale wzrost ceny pojedynczego urządzenia nie będzie już tak wysoki, więc stanie się w zasięgu ręki (choć realnie i tak wydaje mi się że większość osób będzie sięgać po rozwiązanie bez HDMI aby nie przepłacać jak i tak wydają kilka setek na grafikę czy coś innego).
@tdc Czyli ze jak to mialo by wygladac - montujesz gniazdo za free - a kupujacy placi licencje i kupuje jakis klucz , passwd , certyfikat ktory wlcza to gniazdo ?
Pytam sie bo sie nie znam :-) i nie wiem czy cie dobre zrozumialem
Nie wiem jeszcze jednego: czy dodanie HDMI do Atari nie będzie powodowało zastosowania jakiegoś mocnego jednoukładowca. Przykładowo wykonanie przeskalowania sygnału Atari do rodzielczości HD, czy też zmiana częstotliwości sygnału itp. to są bardzo mocożerne operacje (czyli wymagają małego komputera, który też kosztuje). To są operacje niezbędne (zmieniamy sygnał SD na HD + inne parametry), ale może da się to jakoś obejść?
@kosa0, nie opłaty ponosi wykonawca urządzenia, ale skoro są to opłaty wysokie jak na polskie możliwości to musi to przenieść na kupującego, czyli ostateczną cenę urządzenia, która wraz z czasem może spaść, ale przy naszych ilościach sprzedawanych urządzeń to długo będzie trwało... stowarzyszenie wszystko przyspieszy i potani.
(na "dobranoc"): Przedstawiany procesor może bez żadnego problemu zająć miejsce automatu w opisywanej przeze mnie stacji dysków (HD 3.5"). Ze względu na stricte algorytmiczny charakter realizowanych funkcji, to miejsce po prostu powinno należeć do CPU. Elastyczność i łatwość dalszej rozbudowy - bezcenne.
to nie takie proste :) dvi jest w kilku wersjach: analogowe (dvi-a), cyfrowe (dvi-d) lub obydwa (dvi-i)
i glowy nie dam: dvi jako taki nie jest zgodne z hdmi- karta graficzna musi przelaczyc sie w tryb hdmi. a przejsciowka to tylo zamiana ksztaltu wtyczek. wiec urzadzenie i tak musi obslugiwac hdmi.
Wszystkie urządznia nadawcze HDMI powinny być zgodne z odbiornikami DVI 1.0 (to działa zresztą w obie strony), a fakt ten wynika ze specyfikacji. Kodowanie nadmiarowe jest identyczne w obu przypadkach, dlatego pomysł z DVI nie jest pozbawiony sensu - o ile faktycznie nie ma odpowiednich zastrzeżeń.
