Mikrokontroler i composite video

:D

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

J.

U¿ytkownik "PAndy" snipped-for-privacy@poczta.onet.pl> napisa³ w wiadomo¶ci news:e2ntts$rn0$ snipped-for-privacy@news.dialog.net.pl...

Rozwi±zanie proste sprzêtowo to rejestr przesuwny, do którego procesor zapisuje dane. G³ównym programem procesora jest w³a¶nie ten zapis i realizacja obrazu. Sprzêtowo robi to wyspecjalizowany uk³ad, a procesor wype³nia pamiêæ obrazu, ale oblicza który pixel zapaliæ, lub znak wy¶wietliæ. Jeszcze dalej - uk³ad dostaje polecenie grafiki wektorowej.

VGA nie ma wyj¶cia video, a by³y CGA, które mia³y normalne video.

"Bogdan Gutknecht" <usunto_b_gutknecht snipped-for-privacy@interia.pl wrote in message news:e2pko0$2lj$ snipped-for-privacy@atlantis.news.tpi.pl...

Pewnie tak tylko taki co potrafi zamienic adres we wspolrzednych x,y na konkretny adres w pamieci.

Zgadza sie, niektorzy radykalowie ida nawet dalej i rezygnuja z rejestru przesuwnego i cala robote robi procesor - w jakims projekcie na scenix'ach jest nawet enkodowanie PAL zaimplementowane w programie.

Alez ma tylko RGB, niektore uklady potrafia wygenerowac zespolony sygnal synchronizacji i wystawic go razem z kolorem zielonym - otrzymujesz wtedy po zaprogramowainiu rejestrow VGA (glownie sekwenser) pelnowartosciowe CVBS tyle ze w odcieniach szarosci... btw od dawna zastanawialem sie czy nie byloby mozliwe generowanie programowe CVBS w jakims systemie kolorow na karcie VGA (czesc obrazu musialby stanowic burst chromy ale to raczej nie bylby klopot...)

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>

hehe, mysle o tym od dluzszego czasu :D wlascwie to trzeba sprobkowac i uformowac w burst sinus o czestotliwosci chromy, do tego zmeinaic jego faze, a kolorek zakodowac juz w samym sygnale - wystarczylby jeden kanal i byloby ok... a mozna by dawac niezalezne 3...

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

tak

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

Je¿eli ma byæ wy¶wietlany tylko zwyk³y tekst to wystarczy kupiæ scalak - generator napisów od magnetowidu Scalak ma wej¶cie wideo przelotowe i wmiksowuje w sygna³ napisy. Dostaje te napisy z kontrolera dwoma przewodami (zegar i dane). Jeszcze dochodzi do kontrolera synchro H i V , ale tego nie jestem pewien - musia³bym rzuciæ okiem na jaki¶ schemat

Leszek

To ju¿ bylo proponowane - scalak z telegazet± lub OSD. Ale kolega chce kolorow± grafikê pe³nej rozdzielczo¶ci PAL.

To mo¿e gotowy scalak SoC, np. IBM STB03400

Pawe³