laoo/ng napisał/a:willy napisał/a:Czy do VBXE jest dostepne cokolwiek od czego mozna zaczac? Czy wszystko od zera trzeba? Czy moze na zasadzie Zrobmy burze mozgow, ktos to zlozy w calosc i nikt tego nie zobaczy w formie zrodlowej?
Nie potrafię odpowiedzieć na to pytanie, ale nie wiem, czy jest to witalne zagadnienie. Skoro przez 18 lat nikt się tym nie interesował, to dlaczego nagle teraz miałby być wysyp zainteresowanych? Na razie są wczesne prace nad pomysłem, o którym myślę sobie od paru lat, mam prototyp funkcjonalności w Altirrze (więc od razu będzie emulacja) oraz pracujemy z Mateuszem nad prototypową implementacją w MiSTerze, jak będzie z wciśnięciem tego co wyjdzie do VBXE to zobaczymy. Jak się nie uda, to nie będzie tematu :)
Martwi mnie to ostatnie zdanie .. Ja bym sie raczej skupil na implementacji celowej dla VBXE.
W moim pytaniu chodzi bardziej o to czy rdzen zostanie opubikowany w rodzaju jakiegos OpenSource.
Wracajac do samych algorytmow kompresji to sa one raczej FPGA unfriendly. I zostaly zaprojektowane go streamowego przetwazania danych i ciezko bedzie w tym wypadku wykorzystac zalety FPGA. Dodatkowo niezdefiniowany rozmiar sprita jest dodatkowym utrudnieniem. Jak ma byc latwe do uzycia to musi byc proste. Zdefiniowany rozmiar, albo ... kompilator do rdzenia ktory przygotuje bitstream do FPGA pod konkretne wymagania rozmiaru.
Sama dekompresja danych dosc powaznie zwieksza zapotrzebowanie na przepustowosc pamieci - jesli ma to byc dekompresja *inplace*.
Jeden strumien na dane wejsciowe(tokeny), prawdopodobnie drugi na dane nazwijmy je losowe(literale) i trzeci na zdekompresowane dane.
Dlatego bylo moje pytanie o cel kompresji.
Zeby zoptymalizowac proces, mozna by wydzielic staly bufor na sprity(staly bufor => staly rozmiar) i w chwili gdy mamy wolne pasmo w strumieniu z Ram (potrzebny tu bedzie arbiter) dekompresowac dane do sprajtow nastepnej ramki. A potem juz prosty blitter zrobi swoje.
Ot takie przemyslenia.
Mam ich nieco wiecej, ale nie bede wszystkich na raz pisal ;)
