07.03.2020 09:50
[#35]
Re: Akiko 32
@Hexmage960, post #27
Jak pisałem na swoim blogu owbreaction.wordpress.com.
Mnie tam wszystko działa na nowych amigach co używałem na a1200.
Wszystko lepiej szybciej.
Można nie akceptować a1200 ze względu na cenę i możliwości ale trzeba zauważyć że na Amidze X5000 przynajmniej rozwiązano problem z grafiką.
Mnie tam wszystko działa na nowych amigach co używałem na a1200.
Wszystko lepiej szybciej.
Można nie akceptować a1200 ze względu na cenę i możliwości ale trzeba zauważyć że na Amidze X5000 przynajmniej rozwiązano problem z grafiką.
07.03.2020 10:06
[#37]
Re: Akiko 32
@sanjyuubi, post #32
Czy ja mówiłem o wyrzucaniu Amig OCS na śmietnik? Przecież na Waszym sprzęcie działa 90% super gier. Mówiłem o rozszerzaniu OCS o takie wynalazki. 
Commodore opracowało AGA, ale część ludzi się "obraziła". Jak ktoś ma tylko Amigę 500 i nie dokupuje nowszego sprzętu, to nie ma problemu, rozumiem.
Ostatnia aktualizacja: 07.03.2020 10:09:13 przez Hexmage960
Commodore opracowało AGA, ale część ludzi się "obraziła". Jak ktoś ma tylko Amigę 500 i nie dokupuje nowszego sprzętu, to nie ma problemu, rozumiem.
Ostatnia aktualizacja: 07.03.2020 10:09:13 przez Hexmage960
07.03.2020 11:45
[#38]
Re: Akiko 32
@swinkamor12, post #35
Kolega źle zrozumiał. Ja nie krytykuję Amigi One X5000. Jednak od czasu rozszerzeń PowerPC sprzęt dla Amiga OS stał się bardzo, ale to bardzo drogi. 12000 PLN to zarabiam w ponad 12 miesięcy! Dlatego też nie przeszkadza mi grafika w Amidze 1200. Mam ten komputer od dawna, działa bez zarzutu. Advanced Graphics Architecture może stawać w szranki z VGA/SVGA i z tego co słyszałem nawet zadziałają na nim takie gry jak Settlers II - pod emulatorem Maka.
A niewątpliwie Dune II, Goblins 3, The Lost Vikings 2, Worms Armageddon, "Z" i inne mogły powstać dla AGA w 256 kolorach. Dla przykładu grę "Z" miał swego czasu przygotować Clickboom.
Jak chcę nowoczesne rzeczy, to mam PC, na którego zbierałem kasę - i za 500 PLN mam sprzęt, który radzi sobie ze wszystkimi obecnymi standardami. Amiga OS 4 długo nie będzie obsługiwał tych standardów, mimo że Amiga OS bardzo lubię. I nie jestem "niezaradny", albo wręcz "nieudacznik", jak próbuje nazywać biednych ludzi kolega Mufa - zagorzały fan OS4.
A jeśli kolega zapyta "dlaczego AGA?" to napiszę, że to jest przecież chipset Amigi modelu 1200. A ja Amigę po prostu bardzo lubię - świetny komputer i zauważalny fenomen w informatyce. Lubię praktycznie wszystko co kręci się wokół Amigi.
Ostatnia aktualizacja: 07.03.2020 11:52:33 przez Hexmage960
A niewątpliwie Dune II, Goblins 3, The Lost Vikings 2, Worms Armageddon, "Z" i inne mogły powstać dla AGA w 256 kolorach. Dla przykładu grę "Z" miał swego czasu przygotować Clickboom.
Jak chcę nowoczesne rzeczy, to mam PC, na którego zbierałem kasę - i za 500 PLN mam sprzęt, który radzi sobie ze wszystkimi obecnymi standardami. Amiga OS 4 długo nie będzie obsługiwał tych standardów, mimo że Amiga OS bardzo lubię. I nie jestem "niezaradny", albo wręcz "nieudacznik", jak próbuje nazywać biednych ludzi kolega Mufa - zagorzały fan OS4.
A jeśli kolega zapyta "dlaczego AGA?" to napiszę, że to jest przecież chipset Amigi modelu 1200. A ja Amigę po prostu bardzo lubię - świetny komputer i zauważalny fenomen w informatyce. Lubię praktycznie wszystko co kręci się wokół Amigi.
Ostatnia aktualizacja: 07.03.2020 11:52:33 przez Hexmage960
08.03.2020 23:13
[#41]
Re: Akiko 32
@teh_KaiN, post #29
Proteza C2P (nie wiem nawet czy dobrze zrobiona) na szybko zajmuje wszystkie makrocele w XC95288XL (74% PTERM i 89% rejestrów) przy automatycznym przydziale pinów przez program. Trochę na krawędzi, trochę logiki więcej i trzeba by używać już FPGA. Trochę droga zabawka wychodzi dla takiego bajeru. C2P w CD32 konwertuje tylko 8-bitowe piksele?
09.03.2020 19:20
[#46]
Re: Akiko 32
@swinkamor12, post #44
Coś takiego nie istnieje, ale jeśli już tak to chcesz nazywać, to zatrzask 32-bitowy składa się z 32 przerzutników (po jednym na każdy bit pamięci), pomnożone przez 8 daje 256 przerzutników, każda makrocela ma jeden przerzutnik, a więc z automatu na wszystkie rejestry idzie 256 makroceli. Być może idzie wykorzystać bramki w makrocelach na kolejne zatrzaski, kod zrobi się wtedy jednak bardzo zagmatwany.
Ostatnia aktualizacja: 09.03.2020 19:26:43 przez sanjyuubi
Ostatnia aktualizacja: 09.03.2020 19:26:43 przez sanjyuubi
10.03.2020 18:10
[#51]
Re: Akiko 32
@sanjyuubi, post #45
Oryginalne akiko nie ma innych trybów pracy.
Ale to nie szkodzi.
Sprzęt OCS/ESC poza a3000 ma dostęp do chip RAM 16 bit i max 6 bitplanów.
Dwa bity w każdym bajcie można olać.
Może być np zapis 8x2 bajty i odczyt 6 16 bit.
Wyjdzie mniej makroceli bo 6x16=96.
Ważne żeby od strony cpu kolor był pamiętany na bajcie.
Ale to nie szkodzi.
Sprzęt OCS/ESC poza a3000 ma dostęp do chip RAM 16 bit i max 6 bitplanów.
Dwa bity w każdym bajcie można olać.
Może być np zapis 8x2 bajty i odczyt 6 16 bit.
Wyjdzie mniej makroceli bo 6x16=96.
Ważne żeby od strony cpu kolor był pamiętany na bajcie.
10.03.2020 20:07
[#52]
Re: Akiko 32
@swinkamor12, post #51
Cały rejestr C2P to 32 bajty/piksele, więc przy 32-bitowej szynie wpisujesz/czytasz 4-bajty za jednym razem, bo masz taką możliwość, przy węższych szynach trwa to odpowiednio więcej cykli, pomijając dwa bitplany, wychodzi 32x6=192. Mając jednak pełne 8-bitowe rejestry, jeśli się nie mylę, można wcisnąć w jeden piksel chunky po dwa 4 bitowe piksele i od razu mieć skonwertowane 16 pikseli, czy coś z tego korzysta, nie wiem.
Jeśli Gloom używa Akiko, to zastanawiam się, czy robi jakiś test i czy wystarczy, aby ten konwerter pojawił się w mapie pamięci, czy są jakieś warunki związane z funkcjonowaniem AOS, by można było tego używać.
Ostatnia aktualizacja: 10.03.2020 20:11:35 przez sanjyuubi
Jeśli Gloom używa Akiko, to zastanawiam się, czy robi jakiś test i czy wystarczy, aby ten konwerter pojawił się w mapie pamięci, czy są jakieś warunki związane z funkcjonowaniem AOS, by można było tego używać.
Ostatnia aktualizacja: 10.03.2020 20:11:35 przez sanjyuubi
11.03.2020 05:28
[#55]
Re: Akiko 32
@sanjyuubi, post #52
W oryginale 32 bajty/piksele bo wpisuje się/odczytuje 4 bajty za jednym razem.
W OCS/ECS poza a3000 dostęp do pamięci jest 16 bit to można zrobić rejestr 16 bajtów/pikseli i odczyt/zapis 2 bajtów za jednym razem.
Wyjdzie 16x6=96 makrocel.
4 bitowe piksele odpadają. Chodzi o to żeby zapis do chunky od strony cpu to była jedna operacja.
W OCS/ECS poza a3000 dostęp do pamięci jest 16 bit to można zrobić rejestr 16 bajtów/pikseli i odczyt/zapis 2 bajtów za jednym razem.
Wyjdzie 16x6=96 makrocel.
4 bitowe piksele odpadają. Chodzi o to żeby zapis do chunky od strony cpu to była jedna operacja.
11.03.2020 09:08
[#56]
Re: Akiko 32
@sanjyuubi, post #54
Jeśli ktoś się brzydzi informacji z wyciekłych źródeł OS3.1 to niech nie czyta mojego posta. ;)
Przy inicjalizacji graphics.library kick sprawdza:
- czy pod adresem 0xb80002 znajduje się magiczny identyfikator 0xCAFE. Jak nie to fail.
- wykonuje testowy write pod 0xb80038+ wpisując 8 sztuk 0x55550000 longwordami
- czyta longowrdami spod 0xb80038+ spodziewając się przy tym naprzemiennie 0xcccccccc 0x00000000.
Jest parę flag kompilacji które mogą w ogóle wyłączyć to testowanie, więc YMMV w zależności od maszyny.
Przy inicjalizacji graphics.library kick sprawdza:
- czy pod adresem 0xb80002 znajduje się magiczny identyfikator 0xCAFE. Jak nie to fail.
- wykonuje testowy write pod 0xb80038+ wpisując 8 sztuk 0x55550000 longwordami
- czyta longowrdami spod 0xb80038+ spodziewając się przy tym naprzemiennie 0xcccccccc 0x00000000.
Jest parę flag kompilacji które mogą w ogóle wyłączyć to testowanie, więc YMMV w zależności od maszyny.
11.03.2020 09:25
[#57]
Re: Akiko 32
@teh_KaiN, post #56
SetPatch patchuje WriteChunkyPixels() (oraz WritePixelArray8()), by korzystały z AKIKO.
Jeżeli chodzi o "własne AKIKO", to zamiast korzystać z rejestru sprzętowego lepiej jest zrobić własne WriteChunkyPixels().
Narzut zerowy, a Twój program zadziała na każdym komputerze, który ma tą funkcję.
Generalnie zalety takich rozwiązań wychodzą za sprawą takich pakietów jak RTG Master.
Jeżeli chodzi o "własne AKIKO", to zamiast korzystać z rejestru sprzętowego lepiej jest zrobić własne WriteChunkyPixels().
Narzut zerowy, a Twój program zadziała na każdym komputerze, który ma tą funkcję.
Generalnie zalety takich rozwiązań wychodzą za sprawą takich pakietów jak RTG Master.
11.03.2020 09:36
[#59]
Re: Akiko 32
@teh_KaiN, post #58
O jejku, robić to na sztywnych rejestrach to kupa zachodu.
Gloom Deluxe nie wykrywa AKIKO, tylko pobiera swoje C2P za pomocą prostego linkera - każdy może tę procedurę bardzo łatwo podmienić - wystarczy je zaimplementować by używało naszej WriteChunkyPixels() - i to wystarczy! Wszystko opisane w pliczku "Read.me" do Glooma Deluxe.
Zobacz sobie do katalogu C2P. Są tam zasemblowane pliczki. Jest też źródło blackmagic.s zawierające kod źródłowy domyślnego C2P dla Glooma Deluxe i służy jako szablon.
Procedurę C2P wybiera się w programie "Setup".
Ostatnia aktualizacja: 11.03.2020 09:40:00 przez Hexmage960
Gloom Deluxe nie wykrywa AKIKO, tylko pobiera swoje C2P za pomocą prostego linkera - każdy może tę procedurę bardzo łatwo podmienić - wystarczy je zaimplementować by używało naszej WriteChunkyPixels() - i to wystarczy! Wszystko opisane w pliczku "Read.me" do Glooma Deluxe.
Zobacz sobie do katalogu C2P. Są tam zasemblowane pliczki. Jest też źródło blackmagic.s zawierające kod źródłowy domyślnego C2P dla Glooma Deluxe i służy jako szablon.
Procedurę C2P wybiera się w programie "Setup".
Ostatnia aktualizacja: 11.03.2020 09:40:00 przez Hexmage960