04.03.2020 20:02
[#1]
Akiko 32
Witam!
Dopiero przeczytałem w AF, że niedawno zaprezentowano akiko 32 - nowy ITX bazujący na specs CD32.
Ktoś coś wie więcej?
Podobno (w newsie) piszą że "już działa".
Jaka architektura? Zero wzmianki o FPGA, więc to realna konkurencja dla V4 Standalone.
Będzie to jako Open Hardware, więc może Lotharek (czy inny Architect1200) się podejmie??
Ciekawe!
Forum tu.
Dopiero przeczytałem w AF, że niedawno zaprezentowano akiko 32 - nowy ITX bazujący na specs CD32.
Ktoś coś wie więcej?
Podobno (w newsie) piszą że "już działa".
Jaka architektura? Zero wzmianki o FPGA, więc to realna konkurencja dla V4 Standalone.
Będzie to jako Open Hardware, więc może Lotharek (czy inny Architect1200) się podejmie??
Ciekawe!
Forum tu.
06.03.2020 10:30
[#22]
Re: Akiko 32
@swinkamor12, post #21
Ale o ile pamietam to Akiko nie ma DMA więc i tak kopiowanie leci prockiem co zabija wydajność ponad jakąś biedę w stylu A1200 z Fastem. To ja juz bym sie zastanowil czy nie mozna byloby dać 2xPaula i miec 8 kanałów, albo zrobić dropin replacement dla Akiko żeby było DMA.
Ostatnia aktualizacja: 06.03.2020 10:32:34 przez michal_zukowski
Ostatnia aktualizacja: 06.03.2020 10:32:34 przez michal_zukowski
06.03.2020 17:07
[#23]
Re: Akiko 32
@michal_zukowski, post #22
Nie wiem jak działa ta część AKIKO, która jest odpowiedzialna za C2P (bo tylko z tego znają ludzie ten układ), ale jeśli polega to na zapisie piksela chunky do rejestrów X, i odczycie danych planarnych z rejestrów Y, to pewnie można to zrobić w CPLD i mieć dostęp do tego na poziomie prędkości pamięci FAST.
06.03.2020 21:21
[#24]
Re: Akiko 32
@sanjyuubi, post #23
Z tego co pamiętam czytasz z tego samego miejsca co wpisujesz. W sumie jaka by się dało to wepchnąć do rozszerzeń fastowych co już są na rynku (w szczególności a6095) to to by było coś! Bankowo bym to wykorzystywał w swoim kodzie. Tylko gdzie to umieścić w przestrzeni adresowej by widział to ocs?
Ostatnia aktualizacja: 06.03.2020 21:22:41 przez teh_KaiN
Ostatnia aktualizacja: 06.03.2020 21:22:41 przez teh_KaiN
06.03.2020 21:46
[#26]
Re: Akiko 32
@teh_KaiN, post #24
To wymagałoby przebudowania od nowa tego rozszerzenia, bo trzeba doprowadzić 16-32 linie danych w zależności od tego, czy jest to karta na 68000/10, czy 68EC020.
Ile Akiko ma rejestrów i jakiej szerokości do tej konwersji (nie wiadomo jaki CPLD by się do tego nadał i czy np. 288 makroceli by wystarczyło)? Gdybyś mi opisał jak to ma działać, to może do A500 jakąś taką prowizoryczną podstawkę pod rozszerzenia można by zrobić. A potem, może nawet dołożyć C2P do karty Lukzera i do Wichra :)
A to musi widzieć OCS, czy tylko procek ma do tego dostęp?
Ostatnia aktualizacja: 06.03.2020 21:51:54 przez sanjyuubi
Ile Akiko ma rejestrów i jakiej szerokości do tej konwersji (nie wiadomo jaki CPLD by się do tego nadał i czy np. 288 makroceli by wystarczyło)? Gdybyś mi opisał jak to ma działać, to może do A500 jakąś taką prowizoryczną podstawkę pod rozszerzenia można by zrobić. A potem, może nawet dołożyć C2P do karty Lukzera i do Wichra :)
A to musi widzieć OCS, czy tylko procek ma do tego dostęp?
Ostatnia aktualizacja: 06.03.2020 21:51:54 przez sanjyuubi
06.03.2020 22:54
[#27]
Re: Akiko 32
@teh_KaiN, post #24
W sumie planowano rozszerzenia do Amigi 1200 z czymś w rodzaju AKIKO. Takie raczej nie powstały, ale szybsze procki załatwiają sprawę.
Moim zdaniem jednak Amiga 500 opanowałaby coś takiego, tylko może nie w czasie rzeczywistym.
Tylko nie rozumiem, czemu przywiązywać się aż tak do OCS, przecież opracowano CD32 po to, żeby dać boost grafice w Amidze.
Ja tam widzę normalną ewolucję Amig: Amiga 1000, Amiga 500, 500+, 3000, 600, 1200 itp. Każdy model coś wnosił.
Można nie akceptować Amigi One X5000 ze względu na odstęp czasu, cenę oraz brak kompatybilności, ale pewne rzeczy są naturalne.
Moim zdaniem jednak Amiga 500 opanowałaby coś takiego, tylko może nie w czasie rzeczywistym.
Tylko nie rozumiem, czemu przywiązywać się aż tak do OCS, przecież opracowano CD32 po to, żeby dać boost grafice w Amidze.
Ja tam widzę normalną ewolucję Amig: Amiga 1000, Amiga 500, 500+, 3000, 600, 1200 itp. Każdy model coś wnosił.
Można nie akceptować Amigi One X5000 ze względu na odstęp czasu, cenę oraz brak kompatybilności, ale pewne rzeczy są naturalne.
07.03.2020 00:14
[#29]
Re: Akiko 32
@Hexmage960, post #27
Bo a1200 są w mojej opinii niedorzecznie drogie i a600 łatwiej zawieźć na party ;)
Według tego wątku wpisuje się pod adres b80038 32 8-bitowe piksele chunky a wyciąga się 8 32-bitowych wartości planar. Nie obraziłbym się gdyby powstało rozszerzenie ocs w którym można pracować w tym trybie albo podawać 16 4-bitowych pikseli. Albo jakby ktoś zrobił zamiennik denise z 4-bitowym chunky, mniam.
Według tego wątku wpisuje się pod adres b80038 32 8-bitowe piksele chunky a wyciąga się 8 32-bitowych wartości planar. Nie obraziłbym się gdyby powstało rozszerzenie ocs w którym można pracować w tym trybie albo podawać 16 4-bitowych pikseli. Albo jakby ktoś zrobił zamiennik denise z 4-bitowym chunky, mniam.
07.03.2020 00:56
[#30]
Re: Akiko 32
@teh_KaiN, post #29
Tak gwoli ścisłości to zapisuje się pod adres GfxBase->ChunkyToPlanarPtr.
Spoko, rozumiem teraz Twoje marzenie. Mnie chodziło o to, że po co rozwijać to w OCS, skoro zostało to już rozwinięte i to jeszcze w Commodore. Ciekawym na ile taki chunky by przyśpieszył operacje.
Bo normalnie masz lookup-table z 16 trójkami RGB. Wówczas szukasz odpowiedniego koloru - bierzesz indeks i wklejasz.
Ostatnia aktualizacja: 07.03.2020 01:03:55 przez Hexmage960
Nie obraziłbym się gdyby powstało rozszerzenie ocs w którym można pracować w tym trybie albo podawać 16 4-bitowych pikseli. Albo jakby ktoś zrobił zamiennik denise z 4-bitowym chunky, mniam.
Spoko, rozumiem teraz Twoje marzenie. Mnie chodziło o to, że po co rozwijać to w OCS, skoro zostało to już rozwinięte i to jeszcze w Commodore. Ciekawym na ile taki chunky by przyśpieszył operacje.
Bo normalnie masz lookup-table z 16 trójkami RGB. Wówczas szukasz odpowiedniego koloru - bierzesz indeks i wklejasz.
Ostatnia aktualizacja: 07.03.2020 01:03:55 przez Hexmage960