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.

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...

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.

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

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!