01.01.2019 16:39
[#35]
Re: Sprzętowego Nowego Roku
@Krashan, post #34
Może myśle zbyt korpoobiektowo, ale fajnie by bylo mieć system pluginów do outputu:
- podstawowy przez port zegara
- RDP przez UDP
- cokolwiek innego przez cokolwiek innego
Szkoda natomiast, że nie przekroczy się magicznej granicy prędkości Zorro2 na praktycznie czymkolwiek procz Z2 i 32bitowych portów CPU :( Może się okazać, że prędkość przez lana po UDP będzie podobna do tej z portu zegara.
- podstawowy przez port zegara
- RDP przez UDP
- cokolwiek innego przez cokolwiek innego
Szkoda natomiast, że nie przekroczy się magicznej granicy prędkości Zorro2 na praktycznie czymkolwiek procz Z2 i 32bitowych portów CPU :( Może się okazać, że prędkość przez lana po UDP będzie podobna do tej z portu zegara.
01.01.2019 17:21
[#36]
Re: Sprzętowego Nowego Roku
@michal_zukowski, post #35
Myślisz dobrze, ale chyba nie na tym poziomie. Jeżeli chcesz mieć jakiś ekran wyrzucony zdalnie przez RDP, to po prostu należy napisać sterownik "RDP.monitor" i wrzucić go do DEVS:Monitors. Tak samo w kwestii czegokolwiek innego przez cokolwiek innego. Używajmy tej modułowości, w jaką wyposażony jest system.
W tym celu możesz oczywiście sforkować seapiggy.monitor na GitHubie (tak, nawet teraz, repo jest u mnie i jest publiczne, chociaż niewiele tam jeszcze kodu) i podmienić odpowiednie rzeczy.
Oczywiście, przez to, że RTG dopiero zaczęło być tworzone przez Commodore w epoce kicka 3.0 i 3.1, plik *.monitor wyświetlający na "obcym" urządzeniu musi ostro poużywać SetFunction() paczując jakąś połowę graphics.library. Niemniej sam kod łatek do – dajmy na to – SeaPiggy, a RDP, praktycznie nie będzie miał punktów wspólnych. Więc nie ma sensu robić jakiegoś systemu pluginów.
W tym celu możesz oczywiście sforkować seapiggy.monitor na GitHubie (tak, nawet teraz, repo jest u mnie i jest publiczne, chociaż niewiele tam jeszcze kodu) i podmienić odpowiednie rzeczy.
Oczywiście, przez to, że RTG dopiero zaczęło być tworzone przez Commodore w epoce kicka 3.0 i 3.1, plik *.monitor wyświetlający na "obcym" urządzeniu musi ostro poużywać SetFunction() paczując jakąś połowę graphics.library. Niemniej sam kod łatek do – dajmy na to – SeaPiggy, a RDP, praktycznie nie będzie miał punktów wspólnych. Więc nie ma sensu robić jakiegoś systemu pluginów.
01.01.2019 17:34
[#37]
Re: Sprzętowego Nowego Roku
@Krashan, post #36
Kraszan ja wiem ze teraz ja popłynie z fantazją za daleko. Ale jeżeli tobie udało się zmusić tak uniwersalny sprzęt jak malina żeby robiła z kartę gfx, to czy Nie można by było zrobić takiej mikro dystrybucji Linux z przeglądarka kierowaną z amigi. Może to nie koszerne ale odpada sporo problemów do których na pewno niema już tylu developerów i tyle czasu.
01.01.2019 17:40
[#38]
Re: Sprzętowego Nowego Roku
@Krashan, post #34
Witaj.
Projekt pomysłowy tylko ten 1MB cholernie wąskie gardło . Wiem oczywiście ze ARM będzie robił za cooper czy bliter i może mięc dużo dodatkowych bajerow ( rysowanie lini czy wypełnianie itp ) ale procesor będzie tez tym wąskim gardłem obciążony . Szczerze życzę powodzenia w projekcie. Pozdrawiam Szymon
Projekt pomysłowy tylko ten 1MB cholernie wąskie gardło . Wiem oczywiście ze ARM będzie robił za cooper czy bliter i może mięc dużo dodatkowych bajerow ( rysowanie lini czy wypełnianie itp ) ale procesor będzie tez tym wąskim gardłem obciążony . Szczerze życzę powodzenia w projekcie. Pozdrawiam Szymon
01.01.2019 17:50
[#40]
Re: Sprzętowego Nowego Roku
@jimiche, post #37
Nie można by było zrobić takiej mikro dystrybucji Linux z przeglądarka kierowaną z amigi.Pewnie by można, tylko nie wiem po co. Możesz sobie postawić Malinę obok, zainstalować Raspbiana, odpalić Firefoxa... Efekt ten sam. Dla mnie Amiga to retrocomputing i z przeglądarkami tego nie mieszajmy.
01.01.2019 18:19
[#41]
Re: Sprzętowego Nowego Roku
@Cizar, post #38
Projekt pomysłowy tylko ten 1MB cholernie wąskie gardło.Tak, to jasne. Będzie to zasadnicza i podstawowa wada SeaPiggy. Karty, w których pamięć VRAM jest bezpośrednio zmapowana w przestrzeni adresowej procesora Amigi – na przykład Wasz projekt, czy karta w Vampire – będą miały tutaj dużą przewagę, zwłaszcza wobec sposobu, w jaki pisało się gry czy dema pod RTG. Najczęściej taka gra wywołuje co ramkę LockBitMap(), renderuje procesorem i woła UnLockBitmap(), jednocześnie zmieniając bufor dla podwójnego buforowania. Przy mapowanej VRAM LockBitMap() jest bardzo szybka. Ja będę musiał skopiować całą bitmapę z Maliny do pamięci Amigi i skopiować z powrotem przy UnlockBitMap(). Co prawda API CGX-a pozwala na kopiowanie tylko zmienionych fragmentów, ale można założyć, że w grach i demach i tak zmianie ulega cała zawartość ekranu. Podobnie sytuacja będzie wyglądała z filmami – w zasadzie jedyna na to szansa to streamowanie z Amigi skompresowanego strumienia i dekodowanie po stronie Maliny.
Trzeba więc przyjąć, że w istniejące gry RTG grać się na SeaPiggy nie da. To będzie tania karta do używania Workbencha w dużych rozdzielczościach i 24 bitach, prosta do podłączenia do współczesnych monitorów przez złącze HDMI. Oczywiście można napisać grę, która będzie na tej karcie działać szybko, ale wymaga to zmiany podejścia – trzeba całą grafikę najpierw załadować do Maliny i operować nią już tylko tam. Być może niektóre istniejące gry robią podobnie, ale to się dopiero okaże przy testach. Z tego co wiem, wszelakie strzelanki FPP, typu porty Dooma, Quake itp. renderują klatki bezpośrednio procesorem i nawet przy karcie graficznej na Zorro II jest już problem – wersja AGA działa szybciej.
Mam zamiar stworzyć proste w użyciu niskopoziomowe API właśnie do zabawy w pisanie gier, na początek 2D. Ma być jak w Amosie, ale łatwiej i oczywiście o wiele szybciej. Nie mam jednak złudzeń, że nagle nastąpi wysyp takich gier.
Pieśnią przyszłości będzie udostępnienie Amidze standardu OpenGL ES 2.0 obsługiwanego przez RPi. Jest to technicznie możliwe, ale wymaga sporo pracy. Wtedy Quake by śmigał
. 01.01.2019 19:10
[#45]
Re: Sprzętowego Nowego Roku
@snajper, post #10
przecież pisze na screenie. Świnka Piggy, nie znasz?
Peggy Plus
Ostatnia aktualizacja: 01.01.2019 19:11:44 przez Dorian3d
Ostatnia aktualizacja: 01.01.2019 19:12:22 przez Dorian3d
01.01.2019 19:17
[#46]
Re: Sprzętowego Nowego Roku
@Krashan, post #25
Czy 8-bitowa szyna clockportu i jego timing wolniejszy niż cykl procesora 68000 na 7MHz (wg datasheetu Gayle z A600, czy w A1200 clkport jest szybszy?) nie jest tutaj jakimś hamulcem?
Clockport oryginalnie posiada 16-bitową szynę, więc teoretycznie można robić na rozszerzeniach jego 16-bitowe wersje specjalnie do Twojego urządzenia, gdyby było takie wsparcie.
Clockport oryginalnie posiada 16-bitową szynę, więc teoretycznie można robić na rozszerzeniach jego 16-bitowe wersje specjalnie do Twojego urządzenia, gdyby było takie wsparcie.
01.01.2019 19:23
[#47]
Re: Sprzętowego Nowego Roku
@sanjyuubi, post #46
Jak chcesz pisać po staremu to hamulcem jest to owszem. W praktyce jeśli będziesz pisać po nowemu, czyli pchasz wszystko na GFX zawczasu i potem tylko rysujesz ramkę rozkazami rysowania to idzie to zdecydowanie szybciej niż na czipsecie amigowym.
To gdzie ta karta naprawdę dostanie pazura to przy obsłudze GLES2 gdzie się to w ten sposób generalnie robi to raz, dwa że nie dogoni wtedy tego żadna inna karta bez GPU z prawdziwego zdarzenia. To długa droga, ale jako twórca gier właśnie na to czekam najbardziej.
Co do 16-bitowego CP - nie mam A1200 i nie orientuję się jak to jest tam zrealizowane - wyprowadzone jest po ludzku czy trzeba to brać z dziwnych miejsc na płycie?
To gdzie ta karta naprawdę dostanie pazura to przy obsłudze GLES2 gdzie się to w ten sposób generalnie robi to raz, dwa że nie dogoni wtedy tego żadna inna karta bez GPU z prawdziwego zdarzenia. To długa droga, ale jako twórca gier właśnie na to czekam najbardziej.
Co do 16-bitowego CP - nie mam A1200 i nie orientuję się jak to jest tam zrealizowane - wyprowadzone jest po ludzku czy trzeba to brać z dziwnych miejsc na płycie?
01.01.2019 19:43
[#48]
Re: Sprzętowego Nowego Roku
@sanjyuubi, post #46
Czy nie jest hamulcem? I tak i nie. GPIO w RPi ma za mało pinów, żeby puścić dwukierunkową komunikację w 16 bitach, a i dużo szybciej niż clockport pogonić się tej komunikacji nie da. Nie wiem nawet czy się wyrobi na „clockportach” dodawanych przez Jensa do niektórych jego kart, używających sygnału NET_CS zamiast SPARE_CS. NET_CS ma mniej waitstates i jest tam prawie 2 razy szybciej. Wstępne pomiary analizatorem stanów sugerują, że GPIO nie zdąży, zwłaszcza w kierunku Malina -> Amiga.
Natomiast nie zgadzam się z tym, że clockport ma 16-bitową szynę. Owszem na drugiej połowie złącza P9B jest 16 bitów danych, ale to jest szyna pamięci chip (po drugiej stronie Budgie) oznaczona na schemacie jako DRD. Na P9A (po drugiej stronie układów pamięci chip) jest nawet pozostałe 16 bitów tej 32-bitowej szyny. Jednakże pożytek z niej żaden. Całe złącze P9 było przewidziane do modułu rozszerzającego pamięć chip z 1 do 2 MB, planowano bowiem Amigi z 1 MB chip RAM. Ostatecznie jednak wszystkie A1200 miały fabrycznie 2 MB, dlatego nie obsadzano pinami w całości obu złącz P9, a tylko fragment będący clockportem. Każda próba „wepchnięcia się” na tę szynę skończy się albo uszkodzeniem zawartości pamięci chip, albo konfliktem z jakimś DMA.
Ostatnia aktualizacja: 01.01.2019 19:58:20 przez Krashan
Natomiast nie zgadzam się z tym, że clockport ma 16-bitową szynę. Owszem na drugiej połowie złącza P9B jest 16 bitów danych, ale to jest szyna pamięci chip (po drugiej stronie Budgie) oznaczona na schemacie jako DRD. Na P9A (po drugiej stronie układów pamięci chip) jest nawet pozostałe 16 bitów tej 32-bitowej szyny. Jednakże pożytek z niej żaden. Całe złącze P9 było przewidziane do modułu rozszerzającego pamięć chip z 1 do 2 MB, planowano bowiem Amigi z 1 MB chip RAM. Ostatecznie jednak wszystkie A1200 miały fabrycznie 2 MB, dlatego nie obsadzano pinami w całości obu złącz P9, a tylko fragment będący clockportem. Każda próba „wepchnięcia się” na tę szynę skończy się albo uszkodzeniem zawartości pamięci chip, albo konfliktem z jakimś DMA.
Ostatnia aktualizacja: 01.01.2019 19:58:20 przez Krashan
01.01.2019 20:15
[#52]
Re: Sprzętowego Nowego Roku
@Krashan, post #48
W sumie to masz rację, powierzchownie spojrzałem kiedyś na ten "pełny" clockport i tak mi zostało w pamięci, że było tam 16 bitów danych na jednym złączu.
Mniejsza z tym, bo co masz zamiar z robić z clockportami, które działają jeszcze szybciej, np. Artur powiedział mi, że na wichrze clockport działa z pełną prędkością przez co zakładam, że jest to cykl około 30ns przy 50MHz.
Czy bufor w postaci SRAMu pomiędzy clocportem i maliną, do którego wrzucałoby się jakąś strukturę i dane, nie rozwiązałoby problemu różnic prędkości?
Ostatnia aktualizacja: 01.01.2019 20:17:16 przez sanjyuubi
Mniejsza z tym, bo co masz zamiar z robić z clockportami, które działają jeszcze szybciej, np. Artur powiedział mi, że na wichrze clockport działa z pełną prędkością przez co zakładam, że jest to cykl około 30ns przy 50MHz.
Czy bufor w postaci SRAMu pomiędzy clocportem i maliną, do którego wrzucałoby się jakąś strukturę i dane, nie rozwiązałoby problemu różnic prędkości?
Ostatnia aktualizacja: 01.01.2019 20:17:16 przez sanjyuubi
01.01.2019 20:18
[#54]
Re: Sprzętowego Nowego Roku
@forge, post #51
Z przekompilowaniem Dooma to już trochę odjazd moim zdaniem. Oczywiście można skompilować Dooma na procesor ARM, załadować go z Amigi do RPi i odpalić, a mysz i klawiaturę odbierać z Amigi. Tylko po co wtedy tak naprawdę nam ta Amiga?
Co do bobów, jak najbardziej. 24 bity, kanał alfa, proszę bardzo.
Co do bobów, jak najbardziej. 24 bity, kanał alfa, proszę bardzo.
01.01.2019 21:24
[#57]
Re: Sprzętowego Nowego Roku
@forge, post #56
Tylko, że grafiki 3D nie "narysujesz" tak jak 2D za pomocą przesuwania graficznych obiektów i poleceń kreślenia linii i figur geometrycznych, karta musiałaby mieć jakąś zdolność transformacji obiektów, inaczej obraz musiałby powstać w Amidze, a potem być kopiowany do Maliny bajt po bajcie co przy porywającej przepustowości około 1.5MB/s (strzelam z głowy biorąc pod uwagę te 540ns) nie da zbyt spektakularnego efektu. Za to dla gier 2D te 400MB na dane to istny raj, gry pokroju NEOGEO i innych automatów nie byłyby wyzwaniem.
01.01.2019 21:27
[#58]
Re: Sprzętowego Nowego Roku
@sanjyuubi, post #57
Nic dodać, nic ująć. No może oprócz tego, że układ Video Core w Malinie obsuguje OpenGL ES 2.0 i da się do niego dobrać. Więc przy odrobinie chęci i dużej ilości wolnego czasu...
Natomiast gry, które obecnie renderują cały ekran amigowym procesorem co klatkę, to na SeaPiggy będzie tragedia, nie ma co się oszukiwać. Pisałem już o tym w tym wątku.
Natomiast gry, które obecnie renderują cały ekran amigowym procesorem co klatkę, to na SeaPiggy będzie tragedia, nie ma co się oszukiwać. Pisałem już o tym w tym wątku.
