letzter Beitrag von Highlander64 am
Jetzt stelle ich mir die Frage, ob ein ADV7180 (oder eine seiner Alternativen) als Eingangs-IC ausreicht, oder ob ich dann immer mit Farbsäumen leben muss und praktisch nie eine perfekte Darstellung erreichen könnte...
Da hilft nur ausprobieren. So teuer ist der Chip ja nicht.
Da hilft nur ausprobieren. So teuer ist der Chip ja nicht.
Am Preis der Chips liegt es bestimmt nicht.
Allerdings funktioniert "ausprobieren" ohne nachfolgende Arbeiten nicht:
* Schaltplan für Eingangsstufe erstellen
* Schaltplan für nachfolgende Verarbeitung durch FPGA erstellen
* Layouten (4 Layern, ca. 10cm x 10cm)
* Platine fertigen lassen und bestücken
Während man auf die Platine wartet:
* FPGA-Schaltung für Analyse der Videodaten in VHDL/Verilog erstellen
* I2C-Ansteuerung des Eingangsbausteins bedenken (über separaten AVR-Controller oder erstmal über Raspberry Pi)
Und wenn ALLE diese Dinge erledigt sind, erst dann kann ich mir eine Bewertung der Qualität erlauben. Und dann evtl. mit einem anderen IC alles wiederholen?
Du siehst, dass der Preis das geringste Übel hier ist. Der zu betreibende Zeitaufwand ist die entscheidende Größe. Und an einer mittelmäßigen Lösung habe ich kein Interesse... 
Gruß,
Thomas
Du siehst, dass der Preis das geringste Übel hier ist. Der zu betreibende Zeitaufwand ist die entscheidende Größe. Und an einer mittelmäßigen Lösung habe ich kein Interesse...
Ok, ich hätte jetzt vermutet das die erste Schaltung noch auf Lochrasterplatine gemacht wird.
Am Preis der Chips liegt es bestimmt nicht.
Allerdings funktioniert "ausprobieren" ohne nachfolgende Arbeiten nicht:
Vielleicht hilft es, dass Terasic den ADV7180 auf einigen ihrer FPGA-Entwicklungsboards verbaut hat?
Vielleicht hilft es, dass Terasic den ADV7180 auf einigen ihrer FPGA-Entwicklungsboards verbaut hat?
Leider nicht wirklich:
Terasic: Altera
Freak: Xilinx-Fanboy 
Ich habe mal aus diesem Youtube-Video "Tutorial:Connecting camera to FPGA using ADV7180 on DE1-SoC board" ein Bild rauskopiert, welches gut verdeutlich, wie sich die Farbe eines Pixels eigentlich zusammensetzt:
Gruß,
Thomas
ein Bild rauskopiert, welches gut verdeutlich, wie sich die Farbe eines Pixels eigentlich zusammensetzt:
Wenn man das macht, bekommt man Farbsäume in Farben, die im Bild sonst gar nicht vorkommen würden. Korrektes 4:2:2-Farbsubssampling funktioniert anders, ich kann aber gerade vom Tablet aus keine geeignete Grafik rauskramen und einfügen.
Aber das ist doch genau das, was die Chips alle ausgeben: "Nach ITU-R BT.656". Soweit ich das jetzt nach ein paar Tagen Datenblattstudium beurteilen kann, deckt sich das mit obiger Grafik, sowie dem oben verlinkten Wikipediaartikel.
Gruß,
Thomas
Wenn man das macht, bekommt man Farbsäume in Farben, die im Bild sonst gar nicht vorkommen würden.
Genau das sehe ich ja genauso. Ich will aber eigentlich später ein Bild über HDMI darstellen, welches "wie von einem Emulator" aussieht... Also ohne Fransen oder Farbsäumen oder Unschärfen...
Korrektes 4:2:2-Farbsubssampling funktioniert anders, ich kann aber gerade vom Tablet aus keine geeignete Grafik rauskramen und einfügen.
Kein Problem, ich kann warten... Allerdings habe ich ja die Ausgabe des Wandlers laut Datenblatt mit obiger Grafik verglichen. Und beide stimmen überein.
Gruß,
Thomas
Aber das ist doch genau das, was die Chips alle ausgeben: "Nach ITU-R BT.656". Soweit ich das jetzt nach ein paar Tagen Datenblattstudium beurteilen kann, deckt sich das mit obiger Grafik, sowie den oben verlinkten Wikipediaartikel.
Die Darstellung, dass abwechselnd Y und eine der Farbkomponenten gesendet wird ist korrekt, aber die Farbzuordnung nicht. Bei 4:2:2 wird efffektiv nur die Farbe jedes zweiten Pixels gesendet, wobei natürlich das Farbsignal vor dem Sampling passend bandbreitenbegrenzt wird um kein Aliasing zu bekommen. Zur Rekonstruktion darf man nicht wild die Farbkomponenten zweier Pixel mischen, sondern berechnet im einfachsten Fall den Mittelwert der Farben des vorherigen und nachfolgenden Pixels.
Die Grafiken in der Wikipedia sind evtl. hilfreich: https://en.wikipedia.org/wiki/…mpling_systems_and_ratios
ZitatGenau das sehe ich ja genauso. Ich will aber eigentlich später ein Bild über HDMI darstellen, welches "wie von einem Emulator" aussieht... Also ohne Fransen oder Farbsäumen oder Unschärfen...
Dann wirst du vermutlich mit einem normalen PAL-Decoder nicht weit genug kommen. Ich bin mir nicht mal sicher, ob die modulierte Farbinformation überhaupt genug Bandbreite hat, um daraus (ohne C64-spezifische Tricks) die Farbe für jeden C64-Pixel zu rekonstruieren.
jedoch haben alle diese Wandler einen Nachteil: Die Unterabtastung des Chroma-Signals.
Diese sogenannte 4:2:2-Wandlung erzeugt nur für jedes zweite Luma-Pixel eine Farbinformation. Das mag bei bewegten Videosequenzen nicht bemerkbar sein, wenn man jedoch ein Computerbild nach dem Standard digitalisiert, erhält man zwangsläufig Farbsäume und kein "Pixel-Perfect"-Bild.
Eiglich ist es keine Chroma-Unterabtastung, sondern eher eine Unter-"Datenausgabe" der
Farbinfo. Intern wird ja mit 80+x MHz abgetastet und in das gewünschte Format
umgewandelt. Und das Tolle am ADV7180 ist, dass er auch RGB565 ausgeben kann, d.h.
je Pixel die kompletten Farbinfos (warum im YT-Video 565 erwähnt wird und dann in
VHDL eine Umwandlung von YCrCB ins RGB-Format besprochen wird wohl ein Geheimnis
bleiben).
Farbsäume kannst aber trotzdem geben. Die wird man wohl manuell rausfiltern müssen
(beim C64 wird ja nur jedes 2. Pixel verwendet). Bei mir (Altera NEEK-Board) sah's jedenfalls
im Vergleich zu all den VGA-Konverterbildern sehr gut aus.
I2C: hab zwar auch kein eigenes Modul, aber in einem der Digilent-Beispiele war mal eins
dabei. Das lässt sich sehr einfach mit einem Registervektor (Addr+Data) initialisieren.
Und das Tolle am ADV7180 ist, dass er auch RGB565 ausgeben kann, d.h.
je Pixel die kompletten Farbinfos (warum im YT-Video 565 erwähnt wird und dann in
VHDL eine Umwandlung von YCrCB ins RGB-Format besprochen wird wohl ein Geheimnis
bleiben).
Bist Du Dir in diesem Punkt sicher? Das Datenblatt (Rev. J) geht nicht mit einem Wort auf eine RGB-Ausgabe ein...
Farbsäume kannst aber trotzdem geben. Die wird man wohl manuell rausfiltern müssen
(beim C64 wird ja nur jedes 2. Pixel verwendet). Bei mir (Altera NEEK-Board) sah's jedenfalls
im Vergleich zu all den VGA-Konverterbildern sehr gut aus.
Und es sind ja nur 16 mögliche Farben (oder 121 beim C16), so dass man die Pixeldaten analysieren und entsprechend zuordnen könnte...
Gruß,
Thomas
Bist Du Dir in diesem Punkt sicher? Das Datenblatt (Rev. J) geht nicht mit einem Wort auf eine RGB-Ausgabe ein...
Stimmt, hast recht, mein Irrtum. Ich habe/hatte 5 verschiedene Video-AD-Erweiterungskarten.
Und eine bzw. ein Chip hatte RGB (war glaube ich 565) geliefert. Der ADV7180 kann's nicht.
Was mir aber gerade noch eingefallen ist: letzten Sommer habe ich im Netz eine Karte mit
einem TVP5154 von TI geschossen. Der kann 4 Videoquellen gleichzeitig einsampeln. Ich kenn
jetzt das SVideo- bzw. C64 Chroma/Luma-Signal nicht gut genug. Falls aber beide die kompletten
Schulterinfos etc. enthallten, dann kannst du mit diesem Chip jedes der beiden Signale als
Lumasignal sampeln und im FPGA wieder zusammenfügen. Einziger Nachteit: der Chip liefert
je Quelle ein eigenen Takt (glaube auch bei sync. Quellen). Und der Taktunterschied ist
glaube ich nach jedem Einschalten anders. (bzw. 2. Nachteil: TQFP mit 128 Pins!!)
Ich habe seit 2 Jahren leider keinen C64 bzw. C128 mehr, sonst hätte ich's selbst getestet.
Ich hätte eine Frage zu dem Ruckeln wegen der Bildwiederholfrequenz. Wenn man immer 2 Frames vom C64 speichern würde, könnte man dann nicht
diese beiden Frames so interpolieren, dass kein Ruckeln mehr erkennbar ist ?
Ich glaube jemand hatte geschrieben dass das ein schlechtes Bild ergibt ? Wieso genau ist das so ?
Und wegen der Farben: Wie schwierig wäre eine PAL Emulation in Hardware ? Ist das realistisch oder zu aufwändig ?
Ich hätte eine Frage zu dem Ruckeln wegen der Bildwiederholfrequenz. Wenn man immer 2 Frames vom C64 speichern würde, könnte man dann nicht
diese beiden Frames so interpolieren, dass kein Ruckeln mehr erkennbar ist ?
Ich glaube jemand hatte geschrieben dass das ein schlechtes Bild ergibt ? Wieso genau ist das so ?
Und wegen der Farben: Wie schwierig wäre eine PAL Emulation in Hardware ? Ist das realistisch oder zu aufwändig ?
Zum ersten Absatz: Nein, das Ruckeln kommt ja allein durch die unterschiedlichen Frequenzen zwischen der Quelle (dem C64 mit 50,125 Hz Bildausgabefrequenz) und dem Monitor (mit 50 Hz). Da der Monitor bei FBAS oder SVideo sich meistens nicht auf die Quelle synchonisiert ruckelt es halt ab und zu. Eine Interpolation mit Zwischenbildern löst dieses Problem nicht. Damit es nicht ruckelt ist eine Synchonisierung obligatorisch.
Zum zweiten und dritten Absatz: Keine Ahnung. ist auch nicht unbedingt Thema dieses Threads.
Nebenbei bemerkt: Warum überhaupt eine PAL-Emulation realisieren? Ich will das PAL-Signal doch gerade dekodieren und über HDMI ausgeben (und erwarte das sich der Monitor auf die 50,125 Hz synchronisiert). Wäre also genau die falsche Richtung.
Nebenbei nebenbei bemerkt: Vor Interpunktionszeichen gehört kein Leerzeichen. Beim Punkt, Doppelpunkt und Komma machst Du es richtig. Beim Fragezeichen weichst Du davon ab. Warum?
Gruß,
Thomas
Meine Suche nach geeigneten Wandlern für FBAS und SVideo nach 4:4:4 (also für jedes der 720 Pixel pro Zeile 720 Y-, 720 Cr- und 720 Cb-Werte) war leider erfolglos. Vielleicht gibt es auch keine, da für bewegte Bilder eine 4:2:2-Wandlung ja völlig ausreichend ist...
Doch, es gibt Wandler, die nach 4:4:4 wandeln (mit 13,5 MHz und 8 Bit Auflösung) und das Ergebnis auch in der Frequenz parallel ausgeben: ADV7401
Der Chip ist zwar schon älter und es wird auch auf eine neuere Alternative verwiesen, allerdings ist der neue Typ nur als BGA-Typ erhältlich und erschwert somit das Basteln zuhause erheblich. Der ADV7401 (oder auch ADV7403 mit unnötigen 10 Bit Auflösung) ist als LQPF mit 100 Pins erhältlich. Das lässt sich noch gut zuhause löten. Ich denke, dass wird meine Eingangsstufe. Mit ca. 40 EUR ist das IC aber nicht gerade ein Schnapper...
Die Daten gehen dann parallel in einen Spartan6, wo die Farbraumumwandlung gemacht wird.
Soweit meine Idee...
Wenn ich mir allerdings das Datenblatt vom ADV7401 anschaue: Mit 350 Seiten schon sehr umfangreich. Für ein "1-Mann-Projekt" schon eine Menge Holz...
Gruß,
Thomas
Ich hab Heute Morgen nochmal meine Projekte der letzten Jahre überflogen,
in meiner Erinnerung habe ich wohl einen VGA/RGB-Scanner mit einem
Videoscanner-IC verwechselt. Meine Video-ICs geben nur YCrCb aus, die
Wandlung erfolgt im FPGA. Ich kann Dir aber ein Modul für die Farbwandlung
zuschicken (sehr einfach, kein Pipelining und läuft auf CycloneIII mit >50MHz,
also ausreichend für Video).
In der Liste der ICs bin ich noch auf einen weiteren gestossen: ADV7183B.
Der hat 2 ADCs intern und nicht all zu viele Pins.
In der Liste der ICs bin ich noch auf einen weiteren gestossen: ADV7183B.
Der hat 2 ADCs intern und nicht all zu viele Pins.
Mit 80 Pins aber auch ganz gut bestückt, kann aber auch nur 4:2:2. Der ADV7401 ist nach langem Suchen einer der wenigen, die 4:4:4 können, also für jedes Pixel die volle Farbinfo. Damit hätte ich eine gute Grundlage für die Weiterverarbeitung im FPGA.
Ich kann Dir aber ein Modul für die Farbwandlung
zuschicken (sehr einfach, kein Pipelining und läuft auf CycloneIII mit >50MHz,
also ausreichend für Video).
Bin ich sehr empfänglich und sehr dankbar für! 
Allerdings ist das alles erstmal nur ein Gedankenexperiment, ob man mit Hausmitteln ein Wandeln in "Studioqualität" realisieren kann. Und das zu relativ moderaten Kosten. Das das keine 20 Euro-Lösung sein wird ist mir klar. Wenn ich mir dann am Ende allerdings sage: "Ja, dass kann man schaffen", dann bin ich auch gerne bereit etwas Geld in die Hand zu nehmen und den Lötkolben aufs Feuer zu legen...
Gruß,
Thomas
Nebenbei bemerkt: Warum überhaupt eine PAL-Emulation realisieren?
Also wenn man alles so ausgibt auf dem neumodischen TV wie es gesendet wird, dann hat man alles perfekt dargestellt. Aber wenn ich es richtig verstanden habe, dann würde
man die Farbeffekte die durch Farbmischung entstehen evtl. auf dem neumodischen TV ganz anders sehen als es auf unseren alten PAL TVs ausgesehen hat ? Die Frage wäre
also ob es überhaupt gut is, alles "perfekt" auszugeben ...
Die Frage wäre
also ob es überhaupt gut is, alles "perfekt" auszugeben ...
Wechselnde Farben, die sich auf Röhren-TV schön zu einer Mischfarbe vereinen, werden eventuell anders aussehen. Das kann gut sein.
Es ist daher eine Ansichtssache, ob man weiterhin an einem 1084-Monitor festhält (und ihn mit auf Partys schleppt) oder ob man einen kleinen leichten LCD-TV einpackt und dazu eine kleine Kiste, die das Signal auf HDMI ausgibt...
Gruß,
Thomas
Wenn ich mir die Pixelfarbe vom letzten Bild allerdings im internen RAM des FPGA speichern würde, dann könnte man darauf zurückgreifen und der FPGA könnte die Farbmischung errechnen und das errechnete Pixel ausgeben und für den nächsten Durchlauf speichern. Jetzt kommen wir aber langsam an meine (zeitlichen und fachlichen) Grenzen...
So viele Ideen und so wenig Zeit...
Ich hab mir für den Zweck einen Scaler gebraucht von Kramer geholt.
Der wandelt FBAS auf XGA oder was auch immer um. Das ist Bühnen, PA-EQUIPMENT was heute wegen des 15pol D-Sub Ausgangs kein Profi mehr brauchen kann. Mit etwas Geduld kann man da für wenig Geld spitzen Technik ergattern.
Hatte ihn mal in "heute so angekommen" vorgestellt, kann aber auch hier Infos einstellen wenn gewünscht.
Hatte ihn mal in "heute so angekommen" vorgestellt, kann aber auch hier Infos einstellen wenn gewünscht.
Besser ist das. Bei "heute so angekommen" findet das kein Mensch mehr wieder.
