[Atari] AtariOnLine: "Weronika" po latach

[2] # AtariOnLine | Piątek, 27 Grudnia 2019 16:42CET

[Atari] AtariOnLine: "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
→ NOWSZY [Atari] AtariOnLine: Zapowiedź nowej gry "Adam Is Me"
→ NOWSZY [Atari] AtariOnLine: W czasach kwarantanny
→ NOWSZY [Atari] AtariOnLine: Jaskinia Prawiczka
→ NOWSZY [Atari] AtariOnLine: Loading o Atari
→ NOWSZY [Atari] AtariOnLine: RAM-Cart jako inspiracja
→ NOWSZY [Atari] AtariOnLine: Nowa gra "Angry Betty"
→ NOWSZY [Atari] AtariOnLine: Atari na poważnie i na wesoło
→ NOWSZY [Atari] AtariOnLine: Grawitacja 2020
→ NOWSZY [Atari] AtariOnLine: Nadchodzi KWAS #20
→ NOWSZY [Atari] AtariOnLine: Relacja z KWAS #19

Tagi: Atari, Atarionline.pl, Atari Xe, Atari Xl, Retroserwisy, Ataionline, Fusik

wstecz27/12/2019 16:42
Inne treści związane z tematem
[Atari] AtariOnLine: Zmiany, zmiany na AOL! [Atari] AtariOnLine: Zmiany, zmiany na AOL!
Nowy rok zaczął się od licznych zmian na AtariOnline.pl, które mamy nadzieję, zwiększą przyjemność z korzystania z serwisu:1. Koniec z 404Po pierwsze, zrezygnowaliśmy z wyświetlania komunikatu "błąd 404". Okazało się, że nie cieszy się on popularnością wśród czytelników. Niektórzy do tego stopnia nie ...
[Atari.Area] RAD Player 0.3 [Atari.Area] RAD Player 0.3
Ukazał się program autorstwa Mono/Tristesse odtwarzający moduły muzyczne w formacie RAD za pomocą układów OPL2/OPL3 podłączonych do Atari za pomocą kartridży YAMari i Melody. Player wymaga również SpartaDOS X w wersji najmniej SDX 4.48. Program, a także zmodyfikowaną wersję emulatora Atari800 można znaleźć na stronie autora - więcej informacji na naszym forum.
[Atari.Area] RAD Player 0.3 [Atari.Area] RAD Player 0.3
Ukazał się program autorstwa Mono/Tristesse odtwarzający moduły muzyczne w formacie RAD za pomocą układów OPL2/OPL3 podłączonych do Atari za pomocą kartridży YAMari i Melody. Player wymaga również SpartaDOS X w wersji najmniej SDX 4.48. Program, a także zmodyfikowaną wersję emulatora Atari800 można znaleźć na stronie autora - więcej informacji na naszym forum.
[Atari.Area] Zin80 #2 [Atari.Area] Zin80 #2
Wydany został już drugi numer Zin80 - czasopisma poświęconego maszynom zbudowanym wokół mikroprocesora Z80. Tym razem przed nami 60 stron wypełnionych informacjami przydatnymi nie tylko dla fanów ZX Spectrum. A dlaczego o tym piszemy na tej stronie? Otóż jeden z artykułów poświęcony jest stacji dysków do Atari, a tak naprawdę to komputerowi, bowiem dodając nieco pamięci do LDW ...
[Atari.Area] Zin80 #2 [Atari.Area] Zin80 #2
Wydany został już drugi numer Zin80 - czasopisma poświęconego maszynom zbudowanym wokół mikroprocesora Z80. Tym razem przed nami 60 stron wypełnionych informacjami przydatnymi nie tylko dla fanów ZX Spectrum. A dlaczego o tym piszemy na tej stronie? Otóż jeden z artykułów poświęcony jest stacji dysków do Atari, a tak naprawdę to komputerowi, bowiem dodając nieco pamięci do LDW ...
Komentarze

T-shirt "W brzuchu burczy..."

Retro T-Shirt W brzuchu burczy... - męski podkoszulek
Newsy Linkownia Emulatory na PC Wideoteka Screenshoty Bajtek Reduks Ready.Run

© Try2emu 1999 - 2020 | Krzysztof 'Faust' Karkosza Google+Kontakt