Mikrokontroler i composite video

:D

Ale w tym grajku jest juz procesor, i to znacznie lepszy. Wystarczy mu program zmienic :-)

J.

Dorobic koder wzglednie latwo.

Ha - ciekawe czy by sie dalo wpisac wprost w [S]VGA luminancje i chrominancje, albo od razu composite .. w zasadzie kwestia tylko dobrania odpowiedniego rozmiaru i czestotliwosci pikslowej ..

J>

W zasadzie nie trzeba myslec - atari 800 to mialo :-)

Biblioteka procedur graficznych bylaby jednak cokolwiek ciekawa :-)

J.

a nie, Atari mialo to jednak ciut inaczej rozwiazane - patenty: 4296476,

E... pracowac mozna by w RGB - potem konwersja na YUV(a nie YPbPr) - od biedy daloby sie zrobic przy obecnych prockach nawet calkiem szybko. krytyczny bylby modulator QAM bo to on bylby sercem enkodera...

ale ja o tym co bylo nieopatentowane. Czestotliwosc pikslowa [nie]szczesliwie dobrana tyle ile podnosna koloru [zlosliwi twierdza ze to dlatego ze te kwarce byly najtansze], i w trybie czarno-bialym pojawialy kolory w zaleznosci od sekwencji pikseli. A jakie ladne - Amiga sie chowa :-)

Ale ja bym chcial bez postprocessingu. W tym momencie wstawienie pixela byloby nietrywialne, bo to trzeba by zmodyfikowac pare danych w okolicy :-)

J.

YUV bylby nawet optymalny gdybys chcial na tym dekodowac MPG-i, JPG-i

Hehe, Amiga to duze Atari 800 (ale kolorki miala lepiej rozwiazane niz Atari), a chodzi Ci o znany bug GTIA ;)

Nie, operujesz na RGB, potem konwersja przestrzeni kolorow (ten kawalek jest bardzo dobrze zoptymalizowany bo standardowa operacja przy enkodowaniu/dekodowaniu video), po konwersji uzyskujemy YUV, majac skladowe YUV jestesmy w stanie enkodowac sygnal koloru dalej - CVBS=Y+(U*sin2nFsc)+-(V*cos2nFsc)

w MPEG czy JPEG nie ma ani sladu po YUV... to klasyczny blad ludzi od softu - myla im sie sygnaly roznicowe i sygnaly charakterystyczne dla systemow kodowania koloru z danymi cyfrowymi - w MPEG i JPEG mamy do czynienie z przestrzenia YCbCr i po konwersji na sygnal analogowy z YPbPr - natomiast YUV istnieje tylko i wylacznie wewnatrz enkodera/dekodera PAL tak jak YQI istnieje tylko wewnatrz enkodera/dekodera NTSC

Wygląda na to, że to najciekawszy trop. Ale CPLD to pamiętam ze starych czasów i tylko z teorii. Mógłbyś podpowiedzieć, od czego zacząć? Jakich narzędzi szukać? Google daje tysiące stron, i sie już gubię...

Czy można to zrealizować tak: procesor (jakiś) zajmuje się generacją merytoryczną i pisze do zewnętrznego RAM-u, a z tego samego RAMu CPLD odczytuje i wysyła na grafikę?

Pozdrowienia, MKi

MKi napisał(a):

Zależnie od producenta czyli Lattice, Altera, Xilinx i pewnie jeszcze kilku.

CPLD zaprogramujesz w Verilogu/VHDLu/ABELu czy też ręcznie rysując schemat logiczny (albo korzystając z kombinacji tychże).

CPLD to jakby bardziej ubodzy krewni FPGA choć są spore różnice w fizycznej implementacji. Jednak funkcjonalnie jeśli projekt się zmieści w CPLD to będzie działać. Myślę, że zwykły "framebuffer" powinien wejść w te chipy bez problemu. W sumie potrzeba tylko dwóch liczników a obsługa pamięci sram jest mało wymagająca.

Sam pewnie zrobię coś takiego jak tylko wreszcie zaprojektuję i wykonam odpowiednią płytkę PCB. :)

Pozdrawiam,

Radek