16.03.2020 12:25
[#151]
Re: Akiko 32
@abcdef, post #134
Czy Ty i inni w ogóle czytasz temat jako całość, czy reagujesz na zdania wybiórczo?
No właśnie, a gdzie sobie wkładają użytkownicy turbo różne urządzenia? Nigdzie?
Ile razy można pisać to samo, że chodzi o eksperyment, którego wyniki mogą zadecydować, warto w ogóle PRZY OKAZJI dodawać AKIKO do projektów NOWYCH kart turbo 68000/020/030.
Jeśli nie masz zamiaru pomóc, po co się wypowiadasz? Jeszcze nikt złotych gór nie obiecał, a już pojawili się malkontenci jak szarańcza przed wzejściem plonów. Moderacja działa aż za dobrze, zamykając wątki będące pokarmem dla trolli, sprawiła, że nie mają gdzie się wyszaleć.
No właśnie, a gdzie sobie wkładają użytkownicy turbo różne urządzenia? Nigdzie?
Ile razy można pisać to samo, że chodzi o eksperyment, którego wyniki mogą zadecydować, warto w ogóle PRZY OKAZJI dodawać AKIKO do projektów NOWYCH kart turbo 68000/020/030.
Jeśli nie masz zamiaru pomóc, po co się wypowiadasz? Jeszcze nikt złotych gór nie obiecał, a już pojawili się malkontenci jak szarańcza przed wzejściem plonów. Moderacja działa aż za dobrze, zamykając wątki będące pokarmem dla trolli, sprawiła, że nie mają gdzie się wyszaleć.
16.03.2020 12:33
[#153]
Re: Akiko 32
@teh_KaiN, post #138
Nie ma sensu się rozpisywać temu panu, który w ogóle nie potrafi zrozumieć o co chodzi, nie czyta wątku i intencji ze zrozumieniem i myśli, że my myślimy, że zrewolucjonizujemy Amigę i na podstawie swoich założeń generuje malkontenckie posty, tak jakby nie wiedział, czemu po 30 latach ludzie wciąż grzebią przy martwej platformie, żałosne.
16.03.2020 12:38
[#154]
Re: Akiko 32
@Krashan, post #152
Mnie akurat nie interesuje model biznesowy, tylko wykonanie i sprawdzenie wyników dla własnej przyjemności, bo projekt jest prosty i tani do wykonania w ramach eksperymentu hobbystycznego, więc można sobie "pyknąć" przy okazji, a to czy w ogóle, to coś da, to inna sprawa.
16.03.2020 12:51
[#155]
Re: Akiko 32
@Hexmage960, post #133
Pamiętajcie, że oprócz grafiki - Doom ma bardzo zaawansowane algorytmy.
Gdzie Doom ma bardzo zaawansowane algorytmy, ktore powoduja ze jest wolny? Doom to engine 2.5d, w ktorym teksturowanie jet robione przez pionowe skalowanie bitmap. Jedyny zaawansowany algorytm to drzewa bsp, ale one sa preprocesowane i w grze tylko sie po nich trawersuje. Z Doomem problem lezy w niezbednej konwersji chunky to planar i przepustowosci chip ramu.
16.03.2020 12:52
[#156]
Re: Akiko 32
@sanjyuubi, post #153
Z tego co naczelny troll ppa pisał chodziło o rozwiązanie tanie i powszechne.
Poza tym temat nie zaczął się od Twojej wizji eksperymentu akiko@cpld tylko od swoistego CD32 w formacie itx. I tak - śledziłem z uwagą cały.
Ostatnia aktualizacja: 16.03.2020 13:05:47 przez abcdef
A chodzi o to żeby było tanio żeby wszyscy używaliW przypadku NOWYCH kart turbo ta kwestia ma zdecydowanie mniejsze znaczenie (o czym pisałem), a że koszt większego FPGA będzie miał niewielki wpływ na ostateczną cenę całości to jak najbardziej zasadne jest poruszanie tematu czy SAMO C2P jest tutaj tym co rzeczywiście będzie czymś konkretnym co to wyróżni i przyniesie wymierne zyski samo w sobie. Nie potrafisz się do tego ustosunkować tylko rzucasz inwektywami. Brawo! Esencja amigowej Elyty...
Poza tym temat nie zaczął się od Twojej wizji eksperymentu akiko@cpld tylko od swoistego CD32 w formacie itx. I tak - śledziłem z uwagą cały.
Ostatnia aktualizacja: 16.03.2020 13:05:47 przez abcdef
16.03.2020 12:58
[#157]
Re: Akiko 32
@marianoamigo, post #148
Będę się czepiał punktu 1: http://amiga.resource.cx/exp/blizzard1230mk1 (co prawda 40MHz ale dla A1200). A było już 68040/25MHz oryginalnie w A4000D w 1992 na nędznej A3640. Były też karty do A500 i A2000: http://amiga.resource.cx/exp/a2630
http://amiga.resource.cx/exp/apollo2030
http://amiga.resource.cx/exp/magnum2040
Co do reszty to się zgadzam. W CD-32 Akiko robiło robotę, ale za mało softu było i brakowało do kompletu fast ram.
Szkoda że A1200 nie wyszła z kawałkiem Akiko do c2p i z nawet 256kB fast ram w standardzie.
Jak ktoś dołoży takie c2p do karty turbo z fat/020/030 do A500/600/1200 to by była super sprawa. Byłoby czym się pobawić.
http://amiga.resource.cx/exp/apollo2030
http://amiga.resource.cx/exp/magnum2040
Co do reszty to się zgadzam. W CD-32 Akiko robiło robotę, ale za mało softu było i brakowało do kompletu fast ram.
Szkoda że A1200 nie wyszła z kawałkiem Akiko do c2p i z nawet 256kB fast ram w standardzie.
Jak ktoś dołoży takie c2p do karty turbo z fat/020/030 do A500/600/1200 to by była super sprawa. Byłoby czym się pobawić.
16.03.2020 13:14
[#158]
Re: Akiko 32
@abcdef, post #156
Z tego co naczelny troll ppa pisał
To zdanie jakiejś losowej osoby piszącej wątku ma decydujący wpływ na kierunek, w którym on dąży?
czy SAMO C2P jest tutaj tym co rzeczywiście będzie czymś konkretnym co to wyróżni i przyniesie wymierne zyski samo w sobie.
No nie gadaj...
Ostatnia aktualizacja: 16.03.2020 13:18:43 przez sanjyuubi
16.03.2020 14:42
[#160]
Re: Akiko 32
@docent, post #155
Wielu użytkowników Amigi klasycznej ma błędne wyobrażenie co do szybkości tego komputera i upatruje problemy z płynnością gier Doomo-podobnych w konieczności konwersji c2p. To nie jest do końca prawda. Po to wymyślono uciążliwe w obsłudze bitplany aby powolnej Amidze 500 przyspieszyć operacje na blokach o wielokrotności 16px ponieważ w niższej ilości kolorów jest to dużo szybsze. Inaczej mówiąc, bitplany są rozwiązaniem problemu wolnego dostępu do pamięci graficznej.
Doom to nie jest gra na Amigę 1200 14MHz ale nie tylko ze względu na konwersję. Ten komputer nie jest w stanie przekopiować tak dużej ilości danych tekstur wypełniających cały ekran w krótkim czasie.
Na pewno da się zrobić test szybkości renderowania ADoom bez konwersji cp2 a zamiast tego zwykłe kopiowanie fast -> chip. Nawet wtedy gra na całym ekranie 320x200 nie będzie grywalna.
Doom to nie jest gra na Amigę 1200 14MHz ale nie tylko ze względu na konwersję. Ten komputer nie jest w stanie przekopiować tak dużej ilości danych tekstur wypełniających cały ekran w krótkim czasie.
Na pewno da się zrobić test szybkości renderowania ADoom bez konwersji cp2 a zamiast tego zwykłe kopiowanie fast -> chip. Nawet wtedy gra na całym ekranie 320x200 nie będzie grywalna.
16.03.2020 15:55
[#162]
Re: Akiko 32
@sanjyuubi, post #161
To wytłumacz analogię co do tego jak ktoś pyta o kartę za 400zł a dostaje odpowiedź o karcie za 4000. Nowy leżak XC95288XL (bo raczej bez XL w typowych kanałach dystrybucji nie dostaniesz) to ~100PLN, za tyle są LCMXO2 i MACH10 z ~6000LE, które trzeba tylko doposażyć w dwukierunkowe translatory poziomów gdzie trzeba i jednokierunkowe gdzie można. Tak, wtedy wychodzi nieco drożej z naciskiem na NIECO. Zatem argument zupełnie z d... chyba, że kupujesz komponenty na banggood czy alibabie i udaje się dostać za kilkukrotnie niższą cenę, nawet po przesiewie wadliwych. A na ~5k LE leci już TG68k - co z tego wynika? Ano tyle, że na stosunkowo małym FPGA można zaimplementować dużo więcej rzeczy niż na CPLD nie zwiększając znacząco kosztów materiałowych względem CPLD. Jeśli dla Ciebie to jak różnica między kartą za 400, a za 4000PLN to chyba mamy inną arytmetykę.
16.03.2020 16:50
[#163]
Re: Akiko 32
@abcdef, post #162
To wytłumacz analogię co do tego jak ktoś pyta o kartę za 400zł a dostaje odpowiedź o karcie za 4000.
Wystarczy przeczytać swój własny post #128:
Zaraz się okaże, że przerzucenie Alice do FPGA i podbicie prędkości DMA zrobiłoby 20FPS ;) A włożenie karty grafiki na Cyclone V z Cortex A7 nawet i 40 :P
Pojechałeś w kosmos jak w wspomnianych wątkach.
Ostatnia aktualizacja: 16.03.2020 17:04:52 przez sanjyuubi
16.03.2020 17:18
[#164]
Re: Akiko 32
@sanjyuubi, post #163
A motywem przewodnim tego wątku od samego początku jest sprawdzenie, jak będzie wyglądała sytuacja z Akiko bez opóźnień
Nie ma Akiko bez opóźnień, zawsze na jakimś etapie będzie kopiowanie z/do chip ram, a to jest wolne. Nie rozumiem czemu chcesz kontrolować swoisty fork z dyskusji zapoczątkowanej na zupełnie inny temat tak by mieścił się w twoich osobistych kryteriach. Swoją drogą fajnie, że cytujesz, ale jeśli już bardzo chcesz to rób to pełnie, bo pierwszy akapit zaczyna się od
Tylko jaki to wszystko ma sens skoro i tak chipset będzie blokował. Trochę mniej, ale jednak. I tego nie przeskoczysz, ani nie ominiesz.czyli dokładnie to samo co wyżej napisałem i dokładnie to samo co kilkukrotnie w całej dyskusji sam przyznałeś.
To nie jest wątek "AKIKO w chipsecie VS algorytm szybkiego CPU", ktokolwiek myśli, że tak jest, to źle trafił.
Akurat dyskusja na te tory zeszła i nie przeze mnie, a Ty nie jesteś moderatorem dyskusji by określać o czym ona jest, a o czym nie. Dyskusja zmieniała się z ITXowej płytki CD32 na możliwości oryginalnego Akiko, mechanizm jego działania czy wreszcie implementację w CPLD, zahaczała również o wydajność względem zoptymalizowanych algorytmów przy kartach turbo. Nie Ty decydujesz w jakim kierunku idzie, to akurat zależy od dyskutantów. W swoją stronę ciągnie (po staremu) kawia domowa, w przerywniku w inną stronę zbaczają pozostali dyskutanci. BTW ZZ9000 w preorderze to ~1400zł, a nie 4000 :) A czemu uderzyłem w tą nutę? Bo autorzy tej karty dobrze wiedzieli, że samo RTG@FPGA to jest za mało. Potrzebne są killer-ficzery. I masz... full hd chunky. Jest. SD+FF - jest. JPEG&MP3 decode - jest. Ethernet - jest. USB Mass Storage - jest. Zatem zdroworozsądkowo - jeśli już byłaby nowa generacja 9T, wspierałaby się tym razem FPGA to samo C2P wydaje się słabą zachętą. Ale Twój czas, Twoje zabawki. Nie masz żadnego prawa by regulować to co komentuję i w jaki sposób o ile nie łamię regulaminu. A nie łamię.
Ostatnia aktualizacja: 16.03.2020 17:21:31 przez abcdef
16.03.2020 17:46
[#165]
Re: Akiko 32
@abcdef, post #164
Chodzi o zakres prac nad neo-akiko. Wielokrotnie łatwiej jest zrobić akiko-podobne c2p dla wszystkich Amig po raz pierwszy w historii, przy okazji je przyspieszyć bo dostep do jego rejestrów może być bezwaitstate'owy (waitstate'y przy przerzucaniu do CHIP pozostają) niż prowadzić projekt typu ZZ9000 czy karta na modłę Warpa, którego sugerowana cena to własnie magiczna liczba 4000zł.
Fakt, zrobił się offtop w tym wątku, ale wydawał mi się dość konstruktywny. Tylko nie wiedzieć czemu starsi ode mnie, więc pewnie mądrzejsi, zaczęli się wykłócać o nieistotne cyferki i rzucać przy tym bluzgami. A szkoda.
W sumie chyba w temacie neo-akiko zostało powiedziane wszystko co miało być, teraz tylko by się przydał koncepcyjny hw żeby zobaczyć czy używanie tego jest jakkolwiek opłacalne.
Fakt, zrobił się offtop w tym wątku, ale wydawał mi się dość konstruktywny. Tylko nie wiedzieć czemu starsi ode mnie, więc pewnie mądrzejsi, zaczęli się wykłócać o nieistotne cyferki i rzucać przy tym bluzgami. A szkoda.
W sumie chyba w temacie neo-akiko zostało powiedziane wszystko co miało być, teraz tylko by się przydał koncepcyjny hw żeby zobaczyć czy używanie tego jest jakkolwiek opłacalne.
16.03.2020 18:24
[#166]
Re: Akiko 32
@teh_KaiN, post #165
Ale to jak działa c2p akiko (bo samo Akiko to trochę więcej niż c2p) i na ilu makrocelach da się go zrobić było 3 strony wcześniej, włącznie z tym jakie są cpld do wyboru (albo i nie, bo prawie żadne nie są już produkowane, a zastąpiły je FPGA z wbudowanym flash konfiguracyjnym). Jeśli rejestry są w przestrzeni adresowej $B80000-$B87FFE to są poza chipem, poza fastem. W przestrzeni która wcześniej (razem z kawałkiem dla Alice) czyli na OCS jest "reserved". Co za tym idzie samo c2p byłoby zapewne robione przy dekoderze adresów kontrolera fast ramu karty turbo. A i tak ograniczenie wynikałoby z transferów do chip ram.
https://github.com/tonioni/WinUAE/blob/master/akiko.cpp
tu jak jest zaimplementowane w winuae włącznie z rozpoznawaniem przez kick.
https://github.com/tonioni/WinUAE/blob/master/akiko.cpp
tu jak jest zaimplementowane w winuae włącznie z rozpoznawaniem przez kick.
16.03.2020 18:37
[#167]
Re: Akiko 32
@abcdef, post #164
Nie ma Akiko bez opóźnień, zawsze na jakimś etapie będzie kopiowanie z/do chip ram, a to jest wolne.
No właśnie, czyli albo nie czytasz, albo nie wiesz o czym tak naprawdę rozmawiamy, bo na pewno nie o opóźnieniach związanych z kopiowaniem do CHIP, a dostępem do samego AKIKO, które jest powolne, bo każdy cykl z karty turbo do czegokolwiek z Amigi, powoduje jej spowolnienie do poziomu cyklu szyny danej Amigi, a to znaczy, że w przypadku CD32, bez względu na to jak szybka będzie karta turbo, dostęp do rejestrów Akiko będzie na poziomie cyklu 68020 14MHz (czyli mniej więcej tak jakbyś robił operacje na pamięci CHIP) i tylko z tego powodu konwersja C2P jest wydajniejsza na szybkich procesorach, niż na sprzęcie.
Ostatnia aktualizacja: 16.03.2020 18:48:54 przez sanjyuubi
16.03.2020 19:24
[#168]
Re: Akiko 32
@sanjyuubi, post #167
Fajnie, fajnie, tylko to pomoże w szybszym załadowaniu rejestrów c2p z fastu i szybszym przepisaniu skonwertowanych wartości do fastu. Ile to w ogólnym rozrachunku będzie szybciej to się dopiero okaże. Tak samo się dopiero okaże czy gra jest warta świeczki na tym 040/25MHz, czy tylko na 030/50MHz.
16.03.2020 20:31
[#170]
Re: Akiko 32
@mikecios, post #169
AKIKO nie koliduje datacache, problem wynika z tego jak działa datacache , które przechowuje ostatnio odczytane z pamięci dane, a nawet te które są zapisywane w zależności od trybu jego pracy, co sprawia, że procesor dostaje dane pochodzące z cache zamiast z Akiko. Jedynym rozwiązaniem tutaj jest wyłączanie datacache lub oznaczanie tego obszaru jako niecache'owalnego za pomocą MMU.
16.03.2020 20:39
[#171]
Re: Akiko 32
@sanjyuubi, post #170
Koniec końców datacache plus akiko powoduje kaszanę na ekranie.
Tak jak mówisz ratunkiem jest wyłączenie datacache co z drugiej strony mija się z celem bo wydajność procka leci w dół i w rezultacie akiko plus procek bez datacache nie wycisnie tyle co sam procek z datacache ale bez akiko.
Tak jak mówisz ratunkiem jest wyłączenie datacache co z drugiej strony mija się z celem bo wydajność procka leci w dół i w rezultacie akiko plus procek bez datacache nie wycisnie tyle co sam procek z datacache ale bez akiko.
16.03.2020 20:47
[#173]
Re: Akiko 32
@mikecios, post #169
Trafilem na taki wątek, że niestety procek 68030 to bublel, ma bląd w rdzeniu związany z cache Found nasty bug in 68030 CPU!
16.03.2020 20:54
[#175]
Re: Akiko 32
@mikecios, post #171
Tak, ale to nie jest wina ani cache, ani Akiko, tylko programistów, którzy nie założyli, że ktoś mógłby chcieć uruchomić ich program na innym procesorze, niż ten w CD32, za pomocą MMU można wyłączyć cache dla dowolnego obszaru pamięci.
Czy to zostało już sprawdzone na CD32 z 030?
w rezultacie akiko plus procek bez datacache nie wycisnie tyle co sam procek z datacache ale bez akiko.
Czy to zostało już sprawdzone na CD32 z 030?
16.03.2020 20:56
[#176]
Re: Akiko 32
@teh_KaiN, post #174
Chyba źle. Chodzi o to, że pinu CIIN nie da się zastosować do wyłączenia cache dla wybranego obszaru przestrzeni adresowej za pomocą zewnętrznego dekodera. Bo przecież zewnętrzna logika dowie się o adresie dopiero gdy procesor wystawi cykl odczytu na szynę. Ten zaś oczywiście go nie wystawi, jeżeli znajdzie daną w cache.
16.03.2020 20:57
[#177]
Re: Akiko 32
@sanjyuubi, post #175
Tak sprawdzałem.
Odkąd wpadł mi sx32pro w 1996r zawsze mnie męczył czemu w gloom deluxe to nie idzie w parze.
Co prawda wylaczylem wszystkie pamięci cache z rozpędu ale dla swietego spokoju w wolnej chwili zrobię próbę tylko z wyłączonym datacache.
Ostatnia aktualizacja: 16.03.2020 21:00:30 przez mikecios
Odkąd wpadł mi sx32pro w 1996r zawsze mnie męczył czemu w gloom deluxe to nie idzie w parze.
Co prawda wylaczylem wszystkie pamięci cache z rozpędu ale dla swietego spokoju w wolnej chwili zrobię próbę tylko z wyłączonym datacache.
Ostatnia aktualizacja: 16.03.2020 21:00:30 przez mikecios
16.03.2020 21:00
[#178]
Re: Akiko 32
@teh_KaiN, post #174
To też, jednak mam tutaj pewne wątpliwości, ponieważ coś mi się kojarzy, że np. 040 robi i tak 4 cykle odczytu jeśli mu się aktywuje ten sygnał (3 są puste), w przeciwieństwie do wyłączenia cache za pomocą MMU, kiedy to robi wtedy normalne cykle. Takie samo zachowanie jest już w 020, kiedy to przy wyłączonym cache, prefetch i tak pobiera całe długie słowo podczas odczytywania jakiejkolwiek instrukcji z pamięci, przez takie zachowanie 020 bez cache przegrywa (w sysinfo) wydajnością z 68000 na tej samej szynie i przy tym samym taktowaniu.
