Eigentlich nur als Ergänzung zu meinem AVR-BASIC-Computer gedacht, habe ich einen FBAS-Encoder in VHDL entwickelt. Er läuft mit 16 oder 20 MHz (die Farbträgerfrequenz wird intern mittels DDS erzeugt), kann die 8 "Grundfarben" sowie 8 Graustufen darstellen und passt sogar in ein XC9536 CPLD. Allerdings nur, wenn man entweder PAL oder NTSC nutzt. Das Projekt ist auch unter http://www.opencores.org zu finden.
Wunderbar ! Darauf habe ich schon lange gewartet. Ich werde es gleich mal ausprobieren... Meine Versuche ein FBAS Signal am PC zu berechnen und das Bild dann aus einem 512k Flashspeicher auszugeben waren nämlich nicht ganz so erfolgreich. Wäre eine Version mit 256 (oder zumindest 64Farben, also 2bit pro Pixel) möglich ? Falls ja, würde das in einen XC9572 passen ?
Hallo Jörg und Benedikt, Sieht interessant aus, ich muß mir das auch näher anschauen. Die Farben hängen bei PAL/NTSC von der Anzahl möglicher Phasenlagen ab, 8 sind immerhin schon 45 Grad Stufen. Um den Farbträger feinstufiger zu verschieben müssten irgendwelche Laufzeiten benutzt werden, und das für PAL sogar zeilenweise um 180 Grad für die eine Komponente alternierend. 73 Christoph
Das mit dem Phasenlagen ist klar, aber es reichen lediglich sin+cos die in unterschiedlichem Verhältnis addiert werden um beliebige Phasenlagenn zu erzeugen. Mit 13MHz Samplerate habe ich schon ein richtiges FBAS Bild erzeugt, der Takt ist also nicht das Problem.
@Benedikt Das mit den 64 Farben werde ich mal probieren und dann Bescheid geben. Theoretisch sollte es machbar sein, ob es in den 9572 passt, wird sich noch zeigen. @Christoph Da Phasenlage und Amplitude für jede Farbe schon vor der Synthese berechnet sind, sollte das kein Problem darstellen. Allerdings kann es sein, dass die zeitliche Auflösung des modulierten Signals von 45 Grad nicht mehr ausreicht, um die Farben sauber darzustellen. Jörg
Mich wundert, dass sowas funktioniert. Der 16 MHz DDS hat ja nicht mal 4 Stützstellen pro Schwingung des Farbträgers. Wie kann ich dann noch die Amplitude von Sinus und Cosinus digital ändern? Was da rauskommt ist doch nur noch ein stark jitterndes Rechteck.
@Christoph Wieso nur 4? Wenn man es genau nimmt, hat man soviele Stützstellen, wie der DDS-Zähler mögliche Zustände hat. Das ist ja gerade der Vorteil von DDS, man tastet sozusagen eine virtuelle Schwingung ab. Und von den z.B. 4096 möglichen Abtastpunkten verwende ich in meinem Code nur 8 Gruppen, indem ich nur die obersten 3 Bits des Zählers nutze.
Das Rechteck ändert nur knapp viermal pro Farbträgerschwingung seinen Wert. Spektral gesehen hat das was rauskommt vor allem Anteile auf 16 MHz, der Farbträger selbst dürfte auf einem Analysator im Rauschen verschwinden. Das Gezappel hat nur langfristig einen Mittelwert von 4,433 MHz. Man sieht jedenfalls, so ein Farbdecoder ist schon mit wenig zufrieden.
Wenn Du einen Ton mit 12 KHz auf einem CD-Spieler mit 44,1 kHz Abtastrate abspielst, folgt das "Gezappel" auch nur im Mittelwert der 12kHz-Schwingung. Laut Nyquist reicht das Doppelte der maximal zu übertragenden Frequenz als Abtastfrequenz aus. Wenn man das Signal mit den Oszi sinnvoll betrachten will, braucht man ein Tiefpassfilter, wie es auch im TV vorhanden ist.
wenn ich den Ton von 12 kHz überhaupt noch höre. Der Farbdecoder soll aus dem Signal aber noch zwei Farbdifferenzsignale mit etwa 1 MHz Bandbreite entnehmen können - jedes Tiefpassfilter so dicht unter der Nyquistfrequnez macht Phasenverschiebungen. Wie gesagt, schön dass das trotzdem funktioniert. Ich hätte eher einen Farbquarz verwendet, also 17,... oder 35, .. MHz mit vier oder achtfacher Frequenz, und die Zeilenfrequenz daraus heruntergeteilt.
Angehängte Dateien:
-
Video_Scope.png
63 KB
Ich hatte sowas ähnliches vor etwa 10 Jahren mit dem Lattice CPLD ispLSI1016 angefangen. Ein Oszilloskop auf dem TV mit PAL-Videosignal als Ausgabe, das sollte im Endausbau auch noch farbig sein. Schwarz-weiß hat es schonmal funktioniert, dann ist mein Projekt eingeschlafen. Hier ein Beispielfoto: http://www.mikrocontroller.net/attachment/20204/TV_Oszilloskop_mit_CPLD.png Das angehängte Synario-Schematic enthält fast wie bei Jörg einen Teiler durch 2270, also 2* 1135 und wird vom 8-fachen Farbträger als Takt für alles versorgt. Die Pixelrate ist 1/6 davon also knapp 6 MHz, in den 6 Takten wird ein read-modify-write des angeschlossenen Bildspeichers ( 64k*4 ) ausgeführt. Jeder 32.Bildpunkt und jede 32.Zeile ist ein Gitterraster. 4 Bit ergeben 16 Graustufen. Und schließlich sollte das ganze auch noch fremdsynchronisierbar werden. Immerhin hat es so noch in das CPLD reingepasst, war aber ziemlich voll.
Angehängte Dateien:
-
PAL_Testbild_Elektor_96.png
320 KB
Zur Ergänzung ein Literaturhinweis. Elektor hat in Heft 9 und 10 1996 diese Schaltung veröffentlicht, mit einem Altera EPM7032 CPLD, einem 4MBit-Eprom, einem 74AC4040 und einem PAL-Encoder von Sony CXA1645P , hier die erste Seite mit Foto und technischen Daten.
Ich will mal sehen, den ursprünglichen Code etwas aufzubereiten und öffentlich zu machen. Dort kann man auch sehr gut sehen, wie das Signal aus phasenverschobenen Träger und Helligkeitsinformation zusammengesetzt wird. In der aktuellen Version erzeuge ich ja den Signalverlauf sozusagen vorher, das CPLD spielt die Daten nur noch ab. Das mit dem Oszi habe ich auch mal angefangen, ist bei mir aber auch wieder eingeschlafen. Es lief mit einem NEC TFT-Display (RGB-Ansteuerung) und konnte übereinander in zwei Feldern Kurvenzüge mit je 100 Stufen oder 6 Digitalsignale mit einer Breite von 256 Pixeln darstellen. Dazu noch Raster, Textfelder, Zoombalken und Cursor (auch als Bereich). Das Problem war halt, dass ich das Display auf ca. 10KkHz/37,5 Hz runterdrosseln musste und das Teil somit an keinem TV mehr lief. Bei geringerer Horizontalauflösung als 320 sah die Anzeige auf dem TFT aber sch... aus. Und da es das Display wahrscheinlich nur noch bei ebay gibt, ist die ganze Konstruktion eigentlich obsolet. Realisiert hatte ich es mit einem XC9536 und einem Mega16 und war eigentlich nur der Anzeigeteil. Der AVR hat nur die Daten rübergeschoben (7 Bit + Cursorbit), das Anzeigen und auch das Verbinden der Punkte zu Linien hat das CPLD gemacht. Wenn Interesse besteht, könnte man das Projekt aber je nach verfügbarar Zeit wieder aufrollen...
Sogar dot-joining im CPLD? Die "Glöckchen und Trillerpfeifen" wie die Amis sagen sorgen oft dafür dass ein Projekt nicht fertig wird. Bei mir war es ein Sharp-Videodisplay von Pollin. Der hatte damals so ca 5000 Stück aus einem DAB-Pilotversuch bekommen und für nur 49 DM angeboten, die waren innerhalb weniger Tage weg.
Auch wenn das Ganze vielleicht etwas off-topic wird, dot-joining im CPLD ist einfacher als man denkt, aber man kommmt nicht so einfach drauf... Der anzuzeigende Pegel bewegt sich sozusagen von links nach rechts, der Zeilenaufbau im Display geht auch von links nach rechts und von oben nach unten. Das CPLD erzeugt das ganze Timimg,enthält also auch den Zeilenzähler. Der Controller gibt einfach jede Zeile die Messdaten an einem Port aus. Im CPLD werden die Daten zwischengespeichert, damit hat man sowohl den Wert Y(t) auch den Wert Y(t-1). Lediglich beim ersten Messwert passt das nicht, weil Y(t-1) noch vom Ende der vorherigen Zeile stammt. Entweder, beim ersten Wert werden Y(t) und Y(t-1) gleichzeitig gesetzt oder man zeigt die erste Spalte nicht mit an. Bei jedem Pixel wird nun verglichen, ob die (korrigierte) Zeilennummer zwischen dem Wert von (einschliesslich) Y(t-1) und Y(t) liegt. In VHDL geht das mit einfachen Vergleichsfunktionen. Wenn ja, dann wird das Ausgangssignal auf '1' gesetzt, wenn nein dann eben nicht. Lediglich, wenn die Messwerte periodisch zwischen zwei benachbarten Werten wechseln, sieht man nur eine dicke Linie.
Angeregt durch die Kommentare von Christoph und Benedikt habe ich das Ganze in eine etwas andere Richtung weiterentwickelt. Anstelle den Sinus digital nachzubilden, erzeugt die neue Version nur noch ein phasenmoduliertes Rechtecksignal als Chrominanz-Signal, welches dann ausserhalb tiefpassgefiltert und mit dem Luminanz-Signal gemischt wird. Zusätzlich sind Impedanzwandlerstufen an den Ausgängen dazugekommen. Da der Plan vom Video-Scope von Christoph relativ oft heruntergeladen wurde, wäre für mich interessant, welches Interesse an einem solchen Projekt besteht. Jörg
Angehängte Dateien:
-
fbas-enc_01.jpg
33 KB
Hier mal ein Testbild von einem alten 37-er TV. Die Farben sind durch die Digikam leider etwas verfälscht, besonders das Blau sieht im Original besser aus.
Guten Tag! Finde diese Forum hier echt klasse! Habe hier schon viles gelernt. Ich habe auch vor einen PAL-Encoder für meinen Projekt zu machen. Finde die Sources hier für'ne perfekte Anfang! Aber als erstes ich möchte verstehen wie die PAL-farbenkodierung überhaupt funktioniert. Habe im Netz nichts gefunden. Nur ziemlich allgemeine Information. Aber keine richtige erklärung. Hat jemand vielleicht ein Paar links oder PDF's wo PAL-farbenkodierung vollständig dokumentiert ist??? Danke!
Bin gerade auf der Suche nach Farbausgabe auf engstem Raum. Die Erzeugung von Komposit Video ist extrem wichtig, denn nur damit ist später der zusätzliche Verdrahtungsaufwand gering. Preiswerte Framegrabber gibt es massig, ich verwende Expresscard im Notebook, wo auch AVRStudio drauf ist und von dem direkt geflasht wird. Bin gerade an Versuchschaltung mit Atxmega128A1 und habe noch eine Ecke auf der Platine frei, um color statt s/w Videoausgabe draufzusetzen. Mit 8K internem RAM macht das dann schon Sinn (Vergleich: Sinclair ZX Spectrum hatte 6,75K Bildwiederholspeicher). XC9572 gibt es recht klein und kann gut mit SAA7121 konkurrieren. Besonders gut finde ich die Verwendung des Atmega-Taktes. Sicherlich kennt ihr das Formum mit der analogen Encoder-Lösung: http://www.4freeboard.to/board/thread.php?threadid=26409 Bin gespannt, wie es hier weiter geht.
Thread beobachten
Seitenaufteilung abschalten
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.