Hallo! Ich suche schon seit einer ganzen Weile nach Fehlern in meiner VGA-Testgenerator-Schaltung und bin endlich soweit dass ein Bild angezeigt wird. Doch leider hat es natürlich einen weiteren Fehler :-) ...siehe Bilder. Bevor ich mich jetzt weiter dumm und deppert suche möchte ich gerne in die Runde fragen ob jemand die Symptome kennt. Hängt es vielleicht damit zusammen dass ich die H-Sync-Signale synchron zu den V-Sync-Signalen erzeuge (siehe Diagramm) ? Oder sollte ich lieber mit der vorderen Schwarzschulter der H-Sync-Signale anfangen ? Übrigens ist es ein 640x480@60Hz VGA-Signal das ein Testbild im 320x240-Modus mit einem AVR ausgibt. Es sollte einen weissen Rahmen aus einer (Doppel-) Zeile/Pixel rundum haben. Der PC-Monitor schaltet sich übrigens ständig dunkel so als ob etwas richtig nicht stimmt. Der TV dagegen zeigt einfach die Wabbelungen im oberen Bildbereich durchgehend an.
Angehängte Dateien:
-
TV_1.jpg
120 KB -
TV_2.jpg
150 KB -
Monitor_1.jpg
140 KB -
Monitor_2.jpg
130 KB -
Schaltung_Aufbau.jpg
270 KB -
Vsync_Hsync_Timing.jpg
25 KB
Angehängte Dateien:
Nachtrag: Mir fiel eben ein dass ich noch nicht getestet habe wie es ist wenn ich den Signalgenerator direkt an die VGA-Buchse des PC-Monitors anschliesse! Und siehe da: es gibt ein stehendes, komplettes Bild. Aber es scheint ein paar Unkonsistenzen/Störungen zu haben, möglicher weise durch den nichtoptimalen Schaltungsaufbau. Könnte das zum Versagen des VGA-zu-HDMI-Konverters geführt haben ?
Wie wärs mit einem Schaltplan? Für mich sieht das nach falschen Pegeln und/oder Timing aus. Ersteres kann man mit dem Schaltplan feststellen, zweiteres durch ein Listing.
Der Schaltplan ist simpel und das Listing kenne ich mittlerweile fast auswendig, weil ich da ewig Fehler suchen musste :-) Da ich Störungen durch ungünstigen Steckbrett-Aufbau vermute werde ich als nächsten Schritt eine kompakte Platine entwerfen. Danach versuche ich es nochmal mit dem VGA-zu-HDMI-Konverter. Danke euch trotzdem für eure Aufmerksamkeit und gute Nacht!
Bauchtanz nennt man das Fehlerbild. Kommt davon wenn dem Signal z.Bsp 50HZ überlagert wurden.
>Bauchtanz nennt man das Fehlerbild. Kommt davon wenn dem Signal z.Bsp >50HZ überlagert wurden. Du mußt mal Dein Wissen wieder etwas modernisieren ...
Wann stirbt eigentlich endlich mal das Steckbrett aus? Viele Sachen bekommt man auf selbst auf einer gut designten 2Lagen-Platine nicht mehr korrekt zum Laufen - und dann soll sowas funktionieren?
Darf ich fragen, ohne das es böse rüber kommt, was Du mit diesem Testbildgenerator vorhast? Du wandelst das Signal danach mit einem billigst-Konverter auf HDMI, es geht DIr also vermutlich nicht darum alte VGA-Monitore perfekt einzustellen? Finde es toll was Du da bastelst, aber um ein paar Farbbalken per HDMI darzustellen, warum nimmst Du nicht einfach einen Raspberry o.ä.? Hatte vor paar Wochen einen Original-verpackten Kramer Blackburst/ Color Bar Generator bei EBAY eingestellt, ging fürs Mindestgebot von 25€ gerade mal so weg Grüße Heinz
Jens G. schrieb: >>Bauchtanz nennt man das Fehlerbild. Kommt davon wenn dem Signal z.Bsp >>50HZ überlagert wurden. > > Du mußt mal Dein Wissen wieder etwas modernisieren ... Warum ? Dem H-Sync ist etwas überlagert deswegen verschiebt sich der Start der Zeile je nach dem wie das Störsignal dies überlagert. Früher beim Fernsehen nannte man das Bauchtanz ;) Fehler in der Ablenkung schießen wir mal aus ...
:
Bearbeitet durch User
Ist doch schön zu sehen. der verikal impuls überlagert mit seinem Überschwingen den Horizontalimpuls so stark, das dieser nicht ausgewertet wird und die H-Kipstufe frei lauft. im ergebnis siehst du den spannungsverlauf vom Sync-Eingang vertikal abgebildet. Erst in der Bildmitte ist das soweit abgeklungen, dass die Horizontalsynchronisation einrasten kann. Das Problem liegt in der RC gekoppelten Signalmischung der Synchronimpulse also in der HW Anpassung. Namaste
Rudolf R. schrieb: > Der Schaltplan ist simpel und das Listing kenne ich mittlerweile fast > auswendig, weil ich da ewig Fehler suchen musste :-) Ja, sehr schön, aber wir kennen weder Schaltplan noch Listing! Wenn du den Plan nicht posten willst, werden wir z.B. nicht rauskriegen, ob du DC- oder AC Kopplung verwendest, wie oben vermutet.
Rudolf R. schrieb: > Hallo! > > Ich suche schon seit einer ganzen Weile nach Fehlern in meiner > VGA-Testgenerator-Schaltung und bin endlich soweit dass ein Bild > angezeigt wird. schau dir mit nem scope das Hsync an, entweder ist die Flanke reichlich schlapp oder es kommt nicht mit konstanter Frequenz. Auch wäre zu prüfen ob du die korrekten Spannungspegel sendest, es gibt mehr Signalstandards als 5V TTL. Bei die schaut es fast aus als ob Du mit eine PULL/PUSH Stufe arbeitest.
Die GND-verbindungen auf dem Steckbrett scheinen mir aus suboptimal.Nimm mal für GND am VGA-stecker einen anderen Punkt vom steckbrett.
H.Joachim S. schrieb: > Wann stirbt eigentlich endlich mal das Steckbrett aus? Da frage ich dich, wie sieht den bei dir ein Testaufbau aus? Bist du so gut, das gleich eine Profiplatine machst, die auch noch Fehlerfrei ist! Mach dir keine Hoffnungen Steckbrett stirbt so schnell nicht aus. :D
xXx schrieb: > H.Joachim S. schrieb: >> Wann stirbt eigentlich endlich mal das Steckbrett aus? > > Da frage ich dich, wie sieht den bei dir ein Testaufbau aus? Ich antworte mal für Joachim, die Alternative zum steckbrett heisst nicht profiplatine sondern Lochraster. Es gibt sogar Lochraster im Steckbrett layout, Klar geht das auch für den geübten Löter etwas langsamer als zusammenstecken, dafür hat man aber 0-Probleme mitwackeligen Steckverbindern http://www.computers-home.de/electronics/maschine/PICT0211.JPG > Bist du so gut, das gleich eine Profiplatine machst, > die auch noch Fehlerfrei ist! Ein Lochraster richtig gemacht ist auch korriegierbar. Wers auslöten scheut, zwackt halt ein Stück Draht ab und setzt das Bauteil neu. > > Mach dir keine Hoffnungen Steckbrett stirbt so schnell nicht aus. :D Klär solange dien Angst vor dem Lötkolben nicht überwunden ist muss man mit den Wackellösungen leben.
Aber Lochraster wird ja auf die Dauer ein bisschen Teuer wenn ich statt es auszulöten immer die Drähte Abknipse. Dann kann ich ja jedes Bauteil nur ~3 mal benutzen...
Angehängte Dateien:
Danke für die hilfreichen Antworten! Die Therorie dass der V-Sync eine Weile überschwingt und solange den H-Sync stört ist bisher die schönste :-) Aber ist es normal dass bei soetwas die Frequenz der Störung abnimmt ? Müsste sie nicht gleichbleiben und einfach schwächer werden ? Laut der Störung am rechten oberen Bildschirmrand des Monitors scheint da eine Frequenzänderung stattzufinden (über mehrere Zeilen). Ich habe die Schaltung angehängt. Den kaum ausgelasteten Puffer-Baustein für die Sync-Signale würde ich am liebsten mit 2 Transistoren ersetzen. Überhaupt laufen die beiden Sync-Signale parallel auf dem Steckbrett und sind auch im Monitor hochohmig terminiert. Mich wundert es nicht dass da etwas überspricht. Vielleicht kann ich die Bauteile auf dem Steckbrett umsetzen und die Leitungen kürzen. Der RGB-Teil scheint in Ordnung zu sein.
Hast du etwa die Abblock-Kondensatoren vergessen? Der Plan deutet das an.
Stefan U. schrieb: > Hast du etwa die Abblock-Kondensatoren vergessen? Der Plan deutet das > an. Ich war nur zu faul sie einzuzeichnen... oder es war kein Platz oder so.
War auf uc.net nicht mal eine Seite wo gezeigt wird wie man Portausgänge mit Transistoren puffert (invertierend und nichtinvertierend) ?
Rudolf R. schrieb: Ground fehlt auf der Skizze, genau betrachtet hat VGA mehrerer Grounds, das das für die syncs und die Returnleitungen für die Farbkanäle: https://de.wikipedia.org/wiki/VGA-Anschluss Die werden allerdings gern zusammengeschaltet. Beachte da im Monitor noch 75 Ohm Terminierung an den Frabkanälen sind; mit den 100 Ohm Serienwiderständen an den syncs hast du u.U. einen Spannungsteiler gebaut. Da eine korrekte VGA Beschaltung: https://www.xilinx.com/support/documentation/boards_and_kits/ug130.pdf S.21. Beachte, da sind nur 5 pins am VGA-anschluss unbeschaltet, bei dir sind es 8!.
Die drei RGB-Massen habe ich über Brücken zusammengeschaltet (an den Klemmen der VGA-Adapterplatine) und die beiden Sync-Signale haben nur eine gemeinsame Masse (Klemme 10). Die Leitungsführung der Sync-Signale auf der Steckplatine ist recht ungünstig. Ich dachte es macht nichts da es nur ein paar Kilohertz sind. Doch scheinen da die Anstiegszeiten und die Drahtschleifen unschöne Effekte zu bewirken. Ich werde die Sync-Leitungen kürzer machen und nochmal testen. Zur Frage nach dem Sinn: Da ich ein wenig Retro-Bastelei vorhabe benötige ich ein Prüfgerät um zu testen welcher TV die VGA-Auflösung von 640x480@60Hz unterstützt und wieviel dieser vom Bild abschneidet usw. Diese VGA-Auflösung scheint mir am günstigsten zu sein, da sie auf 320x240 halbiert etwa 64k Pixel-Speicher benötigt und so ein 55ns-SRAM ausreicht. Nur der Quarz ist etwas schwer zu bekommen - meiner kam aus Texas oder so mit FedEx :-)
Nachtrag: Die von Xilinx haben den VGA-Pin "ID0" auf Masse gelegt. Ist das wichtig für die Funktion des VGA-Anschlusses oder legt das nur die Geräte-Adresse fest ?
Nimm die zwei 100 Öhmer raus und verwende 2 Treiber, welche nicht unmittelbar neben einander verlaufen oder mindestens einen Ground Pfad dazwischen haben. Wenn du die Pegel anpassen mußt, mach das nicht parallel auf dem Steckbrett sondern mit Masse symmetrisch dazwischen. Wenn du ein comp. Sync Signalbenötigst, achte auf die Pegelveschiebung und entkopple erst nach dem Mischen. Namaste
Die 100 Ohm nach dem Sync-Treiber waren laut einer Webseite dazu gedacht umd die Anstiegszeit etwas zu reduzieren. Ich glaube dass die Sync-Leitungen im VGA-Kabel keine Koaxleitungen sind sondern einfache Drähte und noch dazu sind die im Empfänger-Monitor irgendwie hochohmig abgeschlossen. Ich werde etwas später das Steckbrett umbauen damit alles kompakter wird, dann teste ich nochmal.
Schade: der Umbau zu kurzen Leitungen und auch das Überbrücken der 100 Ohm-Widerstände haben gar nichts gebracht. Das Problem muss fundamentaler Natur sein :-) Ich werde in der nächsten Runde mein Oszilloskop zweikanalig dranhängen und die Signale genau inspizieren.
Rudolf R. schrieb: > Die drei RGB-Massen habe ich über Brücken zusammengeschaltet (an den > Klemmen der VGA-Adapterplatine) und die beiden Sync-Signale haben nur > eine gemeinsame Masse (Klemme 10). Hm,also die RGB- GNDs würde ich an die Masse führen die an dem RGB-sendern liegt, also and 244 Bustreiber, reines zusammenschalten reicht da nicht unbedingt, der Strom muss bei Potentialwechsel auch irgendwohin abfliessen können. Klemme 10 mal direkt an die Masse vom regler klemmen, oder direkt an die "blaue Leiste" vom brett, nicht über eine weitere Steckverbindung. Eventuell hat der VGA-HDMI-adapter ein Masseproblem durch seine eigene Stromversorgung. > Die Leitungsführung der Sync-Signale auf der Steckplatine ist recht > ungünstig. Ich dachte es macht nichts da es nur ein paar Kilohertz sind. > Doch scheinen da die Anstiegszeiten und die Drahtschleifen unschöne > Effekte zu bewirken. Ich werde die Sync-Leitungen kürzer machen und > nochmal testen. Die Polarität ist manchmal entscheident, manche Monis brauchen neg Pol. an den Syncs, andere Positive, wieder andere können mit beiden. Monis bieten auch oft einen Infoscreen an denen man die Pol. /Frequenz ablesen kann. Da noch ein Link, der zeigt, das du mit der Vermutung Sync kein Koax richtig liegst: https://electronics.stackexchange.com/questions/93078/soldering-a-vga-cable-number-of-wires-doesnt-match Was mich wundert ist, das der Moni direkt am VGA wohl funktioniert aber über den Adapter wohl nicht? Vielleich kann dieser adapter ja die 640 nicht richtig umsetzen. Lt. HDMI-Spec wird aber 640x480 für 60Hz unterstützt: https://www.ketos.eu/fs/11a71061-4b14-11e5-ad75-85850ba828cf-meridian-general-info-eng-hdmi-specs.pdf
Ich habe mir vorhin die Oszi-Messung angetan - und zwar am Ausgang des VGA-Kabels (über Adapter und Pulldown-Widerstände terminiert). Die Signalformen sind gut, aber es waren auf dem V-Sync lauter Spitzen und zwar jedesmal wenn ein H-Sync sich änderte (die 100 Ohm Widerstände waren noch überbrückt). Kurioserweise wurden die Spitzen größer (1V) als ich den zweiten Oszi-Kanal anschloss - soviel zur Aussagekraft :-) Aber ich habe wieder dieses Phänomen gesehen: die automatische Oszi-Frequenzmessung am (stabilen) H-Sync und V-Sync Signal hat eine geringfügige Abweichung vom Wert aus der VGA-Timing-Tabelle. Natürlich könnte man den Wert (etwa 80ns für H-Sync) als Messtoleranz abtun, aber ich habe schon mehrstellige präzise Frequenzanzeigen von solchen Oszilloskopen gesehen. Da die Abweichung des H-Sync zwei AVR-Takte beträgt muss ich dem nachgehen und das Programm nochmal akribisch durchleuchten - aber erst morgen :-)
Rudolf R. schrieb: > Zur Frage nach dem Sinn: Da ich ein wenig Retro-Bastelei vorhabe > benötige ich ein Prüfgerät um zu testen welcher TV die VGA-Auflösung von > 640x480@60Hz unterstützt und wieviel dieser vom Bild abschneidet usw. Jeder VGA-Eingang kann diese Auflösung verarbeiten, und bisher hatte jeder Fernseher, den ich damit gefüttert habe, damit kein Problem (auch kein nennenswertes Overscan).
Rudolf R. schrieb: > Ich habe mir vorhin die Oszi-Messung angetan - und zwar am Ausgang des > VGA-Kabels (über Adapter und Pulldown-Widerstände terminiert). Die > Signalformen sind gut, aber es waren auf dem V-Sync lauter Spitzen und > zwar jedesmal wenn ein H-Sync sich änderte (die 100 Ohm Widerstände > waren noch überbrückt). Kurioserweise wurden die Spitzen größer (1V) als > ich den zweiten Oszi-Kanal anschloss - soviel zur Aussagekraft :-) Solches Störspitzen sind oft Zeichen für suboptimales Massekonzept. GND/Masse soll möglichst grossflächig gestaltet werden, siehe die großen Masseflächen auf PCB's. Die dünnen Groundleitungen an dem Steckbrett sind das gegenteil davon. Die Spitzen müssen auch nicht durch Crosstalk verursacht sein, Ground bounce ist auch eine mögliche Erklärung. Bei Ground bounce verschiebt sich das Bezugspotential GND was aber auf dem Scope fälschlicherweise als Verschiebung des Signalpotentials dargestellt wird. https://www.fairchildsemi.com/application-notes/AN/AN-640.pdf https://en.wikipedia.org/wiki/Ground_bounce
... ein Problem welches in der Audiotechnik zu Brummschleifen führt, in der E-Technik Masseverschiebung und in der HV-Technik zu Spannungstrichtern und Schrittspannung führt. Es hängt alles am Rx des Rückleiters. Da hilft amm Steckbrett nur ein sternförmiges Massekonzept, da vollflächig kaum möglich ist. Namaste
Ich tippe eher auf den VGA->HDMI-Konverter und falsches Timing. Die Konverter gehen von standardgemässen Timings aus. Wenn das nicht der Fall ist, versuchen irgendwelche PLL/Lockingmechanismen das zu fangen, aber das Ergebnis sieht man ja. Wenn das HDMI-Signal aussetzt (wie beschrieben) ist das ein deutliches Zeichen, dass was nicht passt. Röhrenmonitore haben so ziemlich alles geschluckt, fast unabhängig von Pixeltakt, Länge und Position der Syncs und Austastlücken... Da muss man jetzt genauer sein...
Georg A. schrieb: > Wenn das nicht der > Fall ist, versuchen irgendwelche PLL/Lockingmechanismen das zu fangen, > aber das Ergebnis sieht man ja. Wenn das HDMI-Signal aussetzt (wie > beschrieben) ist das ein deutliches Zeichen, dass was nicht passt. > Röhrenmonitore haben so ziemlich alles geschluckt, fast unabhängig von > Pixeltakt, Länge und Position der Syncs und Austastlücken... Da muss man > jetzt genauer sein... Wenn ich die Bilder des TO aber richtig verstehe, hat er seinen Generator aber auch an einem Nicht-RöhrenMonitor direkt getestet und da steht das Bild: https://www.mikrocontroller.net/attachment/351471/Monitor_VGA_Anschluss.jpg Die PLL des TFT-Monis hat also kein Problem mit dem unsauberen Timing. Und sofern bin ich nicht der meinung das das timing die PLL des converters aus dem Tritt haut. Eher das die Terminierungim Konverter einer andere ist als im Monitor. Mal den Widerstand zwischen den sync pins und zugehörigen GND am Kabel messen in beiden Fällen (kabel an Converter( Kabel an VGA-Moni). Vielleicht ist auch in einem Fall Masse auf dem Schirm (die Metallkrempe um das Pin-array) gelegt und im anderen fall nicht-> auch den Widerstand gegen schirm mal in beiden Fällen messen. Und es sollte nicht Schaden an der Klemmleiste das Pin rechts neben der 15 (mit GND beschriftet) mit GND am steckbrett resp steckbrettstromversorgung zu verbinden. BTW: Wenn man sich das Bild vergrössert anschaut sieht man tatsächlich, das da 1-2 Pixel jitter auf dem Hsync ist. Das sollt aber nicht wie in zugehörigen post vermutet der freiluftverdrahtung geschuldet sein sondern tatsächlich Programmierprobleme.
Es gibt Neues: Ich habe die Zeilenanzahl auf 50 reduziert (die verdächtigen sichtbaren Zeilen auf 5 Stück) und das Oszilloskop zeigt eine Abweichung von 8ns an (zu den VGA-Spezifikationen). Da ein CPU-Takt 39ns beträgt ist es unwahrscheinlich dass da eine Zeile zu lang oder zu kurz ist. Die 80ns Abweichung über die 500 Horizontalzeilen sind wohl nur summierte kleine Abweichungen des messenden Oszilloskops. Aber eine Hoffnung gibt es noch: Ich habe die VGA-Adapterplatine mit dem Multimeter durchgepiepst und festgestellt, dass sowohl das äussere Buchsenblech als auch die "GND"-Klemme nirgends hingehen. Da stellt sich einem die Frage wie das gedacht ist, denn die Unterseite der Adapterplatine ist mit einem dicken Schaumstoff beklebt. Wie soll ich denn da den Kabelschirm an Masse anschliessen und dwas ist mit dieser 16. "GND"-Klemme die nirgends hinführt ?
Rudolf R. schrieb: > Aber eine Hoffnung gibt es noch: > Ich habe die VGA-Adapterplatine mit dem Multimeter durchgepiepst und > festgestellt, dass sowohl das äussere Buchsenblech als auch die > "GND"-Klemme nirgends hingehen. Da stellt sich einem die Frage wie das > gedacht ist, denn die Unterseite der Adapterplatine ist mit einem dicken > Schaumstoff beklebt. Wie soll ich denn da den Kabelschirm an Masse > anschliessen und dwas ist mit dieser 16. "GND"-Klemme die nirgends > hinführt ? Da ist vielleicht die adapterplatine defekt, bei der die hier bei mir auf dem Tisch liegt ist Buchsenblech mit Pin 16 verbunden (grad durchgepiepst ca. 0,6 Ohm), zu allen anderen Klemmen ist das Blech unverbunden. Sieht fast aus wie Deine ausser das unter der Beschriftung 2 3 4 5 ein zweites Logo, "Delock" prangt. Ist wohl diese hier: https://www.reichelt.de/HDMI-DVI-VGA-Verbinder/DELOCK-65170/3/index.html?ACTION=3&GROUPID=7534&ARTICLE=113236 wobei im Unterschied zur Abbbildungdie Unterseite auch mit schwarzen Schaumstoff verklebt ist. Du könntest ja einen Draht unter die Sechskant Muttern klemme und denn mit ner Masse vom Brett in die Klemme 16 verlegen.
C. A. Rotwang schrieb: > Die PLL des TFT-Monis hat also kein Problem mit dem unsauberen Timing. > Und sofern bin ich nicht der meinung das das timing die PLL des > converters aus dem Tritt haut. Das ist jetzt nicht unbedingt ein logischer Schluss ;) Dann ist entweder der VGA-Eingang (bewusst) tolerant oder der Jitter verwirrt den Converter. Der will da ja irgendwie einen Datenstrom mit einem definiertem (=standardisiertem) Timing daraus produzieren.
Es ist eine Delock VGA-Adapterplatine. Ich werde wohl ein wenig basteln müssen um den Aussenschirm an Masse anzuschliessen. Es gibt aber noch ein Problem: die Ermittlung der Abweichung. Das Oszilloskop zeigt für 51 Horizontalzeilen eine Gesamtfrequenz von 31,4604kHz an. Laut VGA-Spezifikationen sollen es 31,46875kHz sein. Ich habe einfach die Periodendauer errechnet und kam da auf die 8ns Abweichung: 31,78599us gegen 31,77755us). Ich bin mir ziemlich sicher dass man die Abweichung so bestimmt nicht errechnet :-) Vielleicht versteckt sich doch irgendwo ein falscher CPU-Takt.
Och ne: Als ich vorhin den Programmteil für die sichtbaren Zeilen in einer verkürzten Endlosschleife ablaufen liess zeigte das Oszilloskop regelmässige Pausen in der Länge von 5 Zeilen an. Selbst nach komplettem Entfernen der inneren Schleife für die 478 Zeilen waren die Pausen noch da. Das muss ich morgen untersuchen, wenn mein Hirn wieder Saft hat :-)
Moin, Bei den Genauigkeitsvorstellungen bezueglich des Oszilloskops rollen sich mir altersbedingt die Fussnaegel schon ein wenig nach oben. Stell's doch mal auf "unendliche Nachleuchtdauer" und guck' dir deine Syncsignale an, ob die nicht einen Jitter um >=1 CPU Zyklus haben. Gruss WK
Georg A. schrieb: > C. A. Rotwang schrieb: >> Die PLL des TFT-Monis hat also kein Problem mit dem unsauberen Timing. >> Und sofern bin ich nicht der meinung das das timing die PLL des >> converters aus dem Tritt haut. > > Das ist jetzt nicht unbedingt ein logischer Schluss ;) Dann ist entweder > der VGA-Eingang (bewusst) tolerant oder der Jitter verwirrt den > Converter. Der will da ja irgendwie einen Datenstrom mit einem > definiertem (=standardisiertem) Timing daraus produzieren. Ja, das stimmt so knallhart zwingend logisch ist der Schluß nicht. Ich wollt jedenfalls rüberbringen das es nicht nur die (analogen) Röhrenmonis sind die so ziemlich alles schlucken, sondern auch die (digitalen) TFT's recht genügsam im pixel-jitter sind. Natürlich hast du Recht, das der ebenfalls digitale HDMI Umsetzer umsetzungsbedingt engere Anforderungen an die syncs stellen könnte. Ich bin davon ausgegangen, das der Umsetzer das VGA-bild wie vom TFT dargestellt, zwischenspeichert und für die HDMI-Seite komplett neu aus diesem (DualPort/FIFO) Speicher ausliest und daher keine feste Beziehung zwischen eingehenden VGA-Syncs und ausgehenden HDMI-syncs bestehen muss. Aber das ist natürlich eine willkürliche Annahme. Für den TO wäre es aber IMHO wichtig, weil er ja eigentlich alte (Retro) VGA-Monis testen will und nicht den (pingelischen) HDMI-Umsetzer. Vielleicht sind es ja mehrere Fehler, unzureichendes Grounding und Timing-Probs.
C. A. Rotwang schrieb: > Ich bin davon ausgegangen, das der Umsetzer das VGA-bild wie vom TFT > dargestellt, zwischenspeichert und für die HDMI-Seite komplett neu aus > diesem (DualPort/FIFO) Speicher ausliest und daher keine feste Beziehung > zwischen eingehenden VGA-Syncs und ausgehenden HDMI-syncs bestehen muss. Das macht so ein simpler VGA-zu-HDMI-Adapter nicht, dazu müsste der ja über ausreichend Zwischenspeicher verfügen, um auch die üblichen VESA-Auflösungen umsetzen zu können (denn das kann so ein Ding auch, das ist nicht auf Standard-VGA festgelegt). Bei "Full-HD" oder WUXGA aber wäre damit der Speicher für ein einzelnes Frame schon um die 7 MByte groß, und ein Frame würde nicht genügen. So viel Speicher aber ist viel zu teuer, als daß man ihn in so einem Krümelbaustein unterbringt, wie er in den üblichen VGA-zu-HDMI-Konvertern zu finden ist. Hier mal ein Beispiel für so einen Baustein: http://en.macrosilicon.com/info.asp?base_id=2&third_id=3 Nein, so ein Ding ist kein Framerate-Converter, sondern nimmt nur sehr simple Anpassungen vor und erwartet vor allem, daß der angeschlossene HDMI-Monitor auch mit dem von der VGA-Seite mehr oder weniger vorgegebenem Timing klarkommt. Sicher, es gibt auch echte Framerate-Converter mit Zwischenspeicher, die aber sind ganz erheblich teurer als dieses schwarze Klötzchen, das man im Eröffnungsposting im Bild "Aufbau" sehen kann. So ein Klötzchen hab' ich auch, und darin o.g. Baustein vorgefunden.
Ich bin auf etwas gestossen: Nachdem wieder fehlende Horizontalzeilen auftraten habe ich mit der isolierten oberen weissen Zeile herumgespielt. Als letzte Möglichkeit habe ich den "IJMP @Z"-Befehl am Ende durch einen "RJMP xxxx"-Befehl ersetzt. Und auf einmal funktionierte es einwandfrei - sogar die VGA-Horizontal-Frequenz stimmte perfekt. Dieser "IJMP @Z"-Befehl scheint etwas ominös zu sein. Entweder stimmt etwas nicht mit dem Befehls-Datenblatt nicht oder die Zähler werden nicht richtig geladen oder soetwas. Ich hab das Highbyte wie angegeben in R31 geladen und das Lowbyte in R30. Und es wurde eine Wortadresse angegeben, wobei angenommen wird dass die Adresse 0000/0001 als Wortadresse 0000 ergibt. Sehr seltsam das Ganze, denn das Datenblatt des ATTiny4313 listet den IJMP-Befehl auf.
Rudolf R. schrieb: > Ich bin auf etwas gestossen: > Nachdem wieder fehlende Horizontalzeilen auftraten habe ich mit der > isolierten oberen weissen Zeile herumgespielt. Als letzte Möglichkeit > habe ich den "IJMP @Z"-Befehl am Ende durch einen "RJMP xxxx"-Befehl > ersetzt. Und auf einmal funktionierte es einwandfrei - sogar die > VGA-Horizontal-Frequenz stimmte perfekt. > > Dieser "IJMP @Z"-Befehl scheint etwas ominös zu sein. Ist er ganz sicher nicht. Der tut, was er soll, genau wie er es lt. Doku tun soll. > Ich hab das Highbyte wie angegeben > in R31 geladen und das Lowbyte in R30. Und es wurde eine Wortadresse > angegeben, wobei angenommen wird dass die Adresse 0000/0001 als > Wortadresse 0000 ergibt. Das wäre korrekt. Allerdings: das entspräche einem Sprung zum Reset-Vektor. Ist das wirklich, was du an dieser Stellen tun wolltest? > Sehr seltsam das Ganze, denn das Datenblatt des ATTiny4313 listet den > IJMP-Befehl auf. Ja und der kann das auch wirklich und er verhält sich auch, wie er soll. Da kannst du dem DB (und mir) vollkommen vertrauen.
c-hater schrieb: > Das wäre korrekt. Allerdings: das entspräche einem Sprung zum > Reset-Vektor. Ist das wirklich, was du an dieser Stellen tun wolltest? Nein das war nur ein Nummerierungs-Beispiel. Ein IJMP war zB. nach Wort-Adresse 0010h bzw. original Byte-Adresse 0020h. An der RESET-Adresse steht eine Initialisierung von DDRD und DDRB sowie dann der beiden Portinhalte. Wenn beim IJMP in meinem Programm falsch gesprungen wird würde das ja irgendwie die regelmäßigen leeren VGA-Zeilen erklären. Ich werde morgen weiter forschen :-)
Angehängte Dateien:
-
Aufbau_neu.jpg
360 KB -
TV_HDMI.jpg
220 KB -
Monitor_HDMI.jpg
140 KB -
Monitor_VGA_Buchse.jpg
140 KB
Also sich nach dem Fehler zu Tode zu suchen hat eine neue Dimension angenommen :-) Ich bin tatsächlich weiter gekommen: ich habe für einen "SBIW"-Befehl fälschlicherweise einen Taktzyklus eingerechnet anstelle von zweien. Und womöglich war noch ein indirekter Sprung falsch, aber ich bin mir nicht mehr sicher denn ich habe tausendmal das Programm geändert um den Fehler einzukreisen. Dabei ist mir sogar der Sockel für den AVR lädiert worden, kein Wunder wenn man den AVR gefühlt über 20 mal mit dem Schraubenzieher rausholt. Aber ein Problem hat es noch (siehe Bilder): Im HDMI-Modus verschwinden am TV alle weissen Randlinien und am Monitor verschwindet die obere weisse Zeile. Über die VGA-Buchse des Monitors wird aber alles richtig angezeigt. Ich habe im TV keinen Menupunkt gefunden der die Ränder sichtbar gemacht hätte - selbst den "Game Mode" habe ich nicht finden können. Vielleicht war der VGA-zu-HDMI-Konverter zu billig. Aber ich kann noch ein wenig herumtesten und eine Zeile weniger ausgeben, was aber nicht logisch klingt da man sich an die VGA-Spezifikationen halten muss.
Rudolf R. schrieb: > Ich habe im TV keinen Menupunkt gefunden der die Ränder > sichtbar gemacht hätte bei Samsung nennt sich das PC Mode, es muss der overscan abgeschaltet werden
Im Steckbrett setze ich alle DIL-BE auf Sockel mit gedrehten Pins. Das schont die BE-Pins und sorgt für guten Kontakt. Programmiert wird bei mir über ISP, auch im Steckbrett. Das verdrahte ich von vornherein so, dass sich Programmier- und Betriebsmodus nicht beharken, was das umprogrammieren wesentlich erleichtert un beschleunigt. Namaste
:
Bearbeitet durch User
Angehängte Dateien:
-
AVR_Sockel_1.jpg
280 KB -
AVR_Sockel_2.jpg
340 KB
Hier ist der geschundene Sockel :-) Ich vermute dass ich einmal mit dem Schraubenzieher zu weit rein bin und beim vierten Beinchen die Gegenfeder abgebrochen habe.
diese Sockel mag ich nicht, nehme lieber gedrehte mit Präzisionsfassungen https://www.elmotex.de/images/dil-28p-s_640.jpg IC Auszieher könnte auch nützlich sein https://i.ebayimg.com/thumbs/images/g/ErcAAOSw3ZtaLlEV/s-l225.jpg
:
Bearbeitet durch User
Rudolf R. schrieb: > Im HDMI-Modus verschwinden > am TV alle weissen Randlinien und am Monitor verschwindet die obere > weisse Zeile. Der Nicht-Overscan-Modus heisst bei Samsung auch gern "Just Scan" und liegt üblicherweise auf der Taste für das Aspect-Ratio (4:3, ...). Wenn das nicht hilft, ist dein Timing immer noch nicht standardkonform :)
Den 4:3-Modus habe ich schon probiert - aus dem Bildschirm-Menu heraus. Ich werde nochmal nach dem PC-/Game-Modus suchen. Ich habe mittlerweile das Programm so umgeschrieben, dass H-Sync asynchron zum V-Sync ist (um eine vordere Schwarzschulter verzögert). Hat funktioniert - die obere weisse Zeile aber auch nicht sichtbar gemacht. Ich habe nun einen billigen VGA-Testgenerator und einen anderen billigen VGA-zu-HDMI-Konverter bestellt (Hongkong). Mit dem Testgenerator kann ich prüfen ob die Sync-Signale synchron oder asynchron laufen (per Oszilloskop). Wenn der neue Konverter auch die obere weisse Zeile frisst dann muss etwas faul sein.
Rudolf R. schrieb: > Wenn der neue Konverter auch die obere weisse Zeile frisst dann muss > etwas faul sein. Solange Du als HDMI-Gerät einen Fernseher verwendest, und nicht absolut sichergestellt ist, daß der seine unsäglichen Bildoptimierungen wie "Overscan" etc. nicht durchführt, taugt der Fernseher nicht zur Beurteilung eines HDMI-Signales. Schließ mal einen Computer am HDMI-Eingang an und lass' den (auf native Auflösung des Fernsehers gestellt) ein brauchbares Testbild anzeigen, wie z.B. das hier: https://www.eizo.de/monitortest Erst wenn das korrekt angezeigt wird, kannst Du Deinem Fernseher halbwegs vertrauen.
Ich habe irgendwie gar nicht so recht erwartet dass der Fernseher das VGA-Bild präzise wiedergibt - oder überhaupt wiedergibt :-) Was mich beunruhigt ist die fehlende obere Zeile auf dem PC-Monitor (über HDMI). Bestimmt liegt es am Billig-Konverter. Ich werde mehr wissen wenn in ein paar Wochen die Teile aus Hongkong da sind. Ich habe beim TV in den Optionen für 4:3 -Format nur 2 ausgegraute Menupunkte gefunden (irgendwas mit SSW oder so und Zoom), einen PC-Modus gibt es nirgends und in den 2 Smart-Modi fehlten auch alle Ränder. Der Fernseher geht wohl auf Nummer Sicher und schneidet ein wenig vom Rand rundherum ab. Der Schaltungsaufbau hat aber etwas wichtiges gezeigt: mit dem R2R-Netzwerk und den 244er Treiberbausteinen kann man ein VGA-Signal erzeugen - und das trotz fehlender eingangsseitiger Terminierung des VGA-Anschlusses. Jetzt werde ich noch versuchen die Sync-Treiber auf Transistoren umzustellen, muss aber warten bis sie per Post kommen. Ich bin mir nicht sicher ob ich die Schaltung auf Platine entwickeln (lassen ) soll denn ich hatte lauter Spitzen auf dem Oszilloskopschirm. Aber bei dem Versuchsaufbau und der Masseleitung des Oszilloskops hat man vielleicht immer Masse-Probleme. Es könnte natürlich wurscht sein wenn da Spitzen beim Pixelwechsel sind, denn der Farbwert wird bestimmt in der Mitte des Pixels digitalisiert.
ne beim TV liegt in den ersten 3 Zeilen normal dunkel getasteten Zeilen der Videotext. Dazumal war Vsync am auch für den Strahlrücklauf zuständig. Sicherheitshalber wurden auch die ersten 3 Zeilen dunkel getastet. Später wurde dort der Videotext übertragen, was die Informationsmenge begrenzte. Wenn dies Zeilen nicht dunkelgetastet sind sieht man die Bits des VT durch die ersten Zeilen tickern. Wenn die Dunkeltastung auf dem CRT defekt war hatte das Bild einen hellen diagonalen Streifen von unten rechts nach oben links. Namaste
:
Bearbeitet durch User
Rudolf R. schrieb: > Ich habe irgendwie gar nicht so recht erwartet dass der Fernseher das > VGA-Bild präzise wiedergibt - oder überhaupt wiedergibt :-) Also meiner (schon etwas betagt und nicht gerade ein Markengerät) kann VGA sowohl über den dedizierten VGA-Anschluß als auch über HDMI problemlos bildschirmfüllend, also vollständig ohne abgeschnittene Ränder darstellen, zumindest für alle üblicherweise genutzten VGA-Modi. Für diese beiden Anschlüsse ist das sogar "default behaviour". Man kann allerdings optional bei beiden Anschlüssen auch einen "Overscan" genannten Modus aktivieren, der dann ca. 5% des Bildes umlaufend wegschnibbelt, den verbleibenden Rest allerdings nur für einem Teil der VGA-Modi auf die volle Panel-Größe zu skalieren vermag. Er kann das allerdings nicht für Video-Modi über den SCART- oder Componenten-Anschluss, (bei SCART weder für RGB, noch S-Video oder Composite). Hier ist Overscan per default aktiv und schneidet dann fast 10% des Bildes weg. Die Option, um das abzuschalten, nennt sich dann "Konsole" und ist leider ebenfalls nicht in der Lage, die Sache ohne Abschneiden darzustellen, sie reduziert nur die 10% auf ca. 2%. Das allerdings ist ganz genau passend für einen 8Bit-Atari mit PAL-Timing. Scheinbar teilte der Firmware-Programmierer eine meiner Vorlieben ;o) Interessanterweise kann man aber Signale mit VGA-Timing auch über Component (mit xor-csync on green) und SCART (mit xor-csync auf Pin21) einspeisen, wobei der Sync-Pegel in einem sehr weiten Bereich akzeptiert wird. Dann ändert sich nicht nur das Verhalten, sondern sogar die verfügbaren Menü-Optionen auf exakt das, was auch bei Einspeisung über VGA bzw. HDMI verfügbar ist. > Was mich beunruhigt ist die fehlende obere Zeile auf dem PC-Monitor > (über HDMI). Bestimmt liegt es am Billig-Konverter. Nö, mit an Sicherheit grenzender Wahrscheinlichkeit ist das Problem allein die Firmware deines TV.
c-hater schrieb: > 8Bit-Atari mit PAL-Timing. Atari machte das nicht von ungefähr der GTIA Chip und seine Modi waren genau auf NTSC ausgelegt die PAL Anpassung war nicht so kompliziert. Guter Alter VBI was hat der nicht alles möglich gemacht und der HBI erst schnell ein registergewechselt und eine weitere Palette stand zur verfügung. Das war schon ein cooles Konzept. Namaste
:
Bearbeitet durch User
Gut zu wissen das mit dem Auto-Abschneiden der Fernseher! Man sollte wohl einen abgeschnittenen Rand einkalkulieren wenn man ein Anzeigegerät für VGA am TV entwickelt. Dann bleibt nur noch die Frage wieso der PC-Monitor die oberste Zeile nicht anzeigt. Das wird hoffentlich durch den Test mit dem anderen Konverter geklärt. Zu Atari: Was passiert wenn in etlichen Jahrzehnten die original Prozessoren und Videobausteine usw. ausfallen ? Denkt ihr jemand wirft wieder die Produktion an ?
Hm ich habe damals einen Pokey be segor nachgekauft den PIA hatte auch auch Conrad, Kürzlich habe ich noch einige OriginalChips der 65C02 und auch Pokeys irgendwo gesehen ANTIC und GTIA habe ich nur selten gesehen. Aber es gibt wohl 6502er Consolen-CLONE auf ASIC-Basis. bei heutigen Frequenzen sollten auch FPGA basierte Emulationen möglich sein einen C64 im Joystickgehäuse gibts auch. Schau mal da: http://www.lotharek.pl/products.php?kid=10 http://lotharek.pl/product.php?pid=82 http://spiflash.org/node/19 http://lotharek.pl/products.php?kid=30 man findet ziemlich viel in der 8bitSzene z.B. http://www.zock.com/8-Bit/forum.cgi viel Spass
:
Bearbeitet durch User
Angehängte Dateien:
-
HDMI_TV.jpg
120 KB -
Streifen_nah.jpg
240 KB
Ich habe ein paar (Doppel-) Pixel-Spalten reinprogrammiert, und nachdem ich die üblichen Programmfehler fand und beseitigte ergab sich folgendes Bild: Der blaue Streifen erscheint irgendwie dünn und zwischen grün und rot gibt es einen schwarzen dünnen Strich - und zwar im HDMI-Modus am TV sowohl als beim VGA-Eingang des PC-Monitors. Bei den dicken Balken des Testbildes sieht man übrigens auch dünne schwarze Streifen, und auch der ganze Farbbalken scheint senkrecht gestreift zu sein. Die Signalqualität sah recht ordentlich aus auf dem Oszilloskop, nur die üblichen kleinen Überschwinger die vermutlich durch die Messleitung herrühren waren zu sehen. Vielleicht liegt es ja an der Bildaufbereitung der TFT-Matrix der Anzeigegeräte (TV, Monitor).
Angehängte Dateien:
-
Aufbau_aktuell.jpg
280 KB -
Monitor_HDMI_Eingang.jpg
69 KB
Der neue VGA-zu-HDMI-Konverter ist gekommen und ich habe ihn ausprobiert! Der Monitor zeigt nun auch die obere weisse Zeile an wenn ich ihm das konvertierte VGA-Testbild über den HDMI-Eingang schicke. Das bedeutet dass der erste Konverter die erste Zeile unterschlagen hat und der Fehler nicht am Testbildgenerator lag. Kurioserweise habe ich auf dem Foto des aktuellen Aufbaus gesehen dass die Masseleitung komplett nicht angeschlossen ist am VGA-Stecker - doch es funktioniert dennoch :-) Auch habe ich anstatt dem 74HC244 zwei Transistoren BC 547C verwendet. Der Basisvorwiderstand beträgt 1,5k, der Kollektorwiderstand 330 Ohm, und ausgekoppelt wird über 100 Ohm. Die Signalflanken sind ein klein wenig abgerundet am Ende aber sieht nicht so wild aus.
Angehängte Dateien:
Abschliessender Nachtrag: Der 10-Euro-VGA-Testbildgenerator aus Hongkong ist gekommen und ich habe ihn sowohl an die VGA-Buchse des PC-Monitors als auch über den VGA-zu-HDMI-Konverter an jenen angeschlossen. Die "8 Testbilder" bestehen nur aus 2 Bildern mit Farbbalken ähnlich meines Aufbaus, und man kann noch 6 einzelne Vollbildfarben durchschalten bevor das Spiel sich in den nächsten 4 Auflösungen wiederholt. Der schwarze Bereich zwischen grüner und roter Farbe war auch vorhanden, sowohl beim Anschluss über VGA-Buchse als auch über den Konverter. Was noch interessant war: der V-Sync-Impuls-Versatz zum H-Sync-Impuls war anders als gedacht! Der V-Sync-Puls begann erst ein wenig nach dem der H-Sync auf Null ging, war also dem H-Sync etwas nachlaufend. Scheinbar hat man da eine gewisse Freiheit wie man die Sync-Pulse zueinander stellt, wichtiger ist wohl die richtige Gesamtlänge des V-Sync.
Rudolf R. schrieb: > Was noch interessant war: der V-Sync-Impuls-Versatz zum H-Sync-Impuls > war anders als gedacht! Der V-Sync-Puls begann erst ein wenig nach dem > der H-Sync auf Null ging, war also dem H-Sync etwas nachlaufend. > Scheinbar hat man da eine gewisse Freiheit wie man die Sync-Pulse > zueinander stellt, wichtiger ist wohl die richtige Gesamtlänge des > V-Sync. Das absolut wichtigste ist, dass der Hsync auch während des Vsync weiter läuft, nur halt invertiert. Weil das so ist: Hsync XOR Vsync = CSync! Bei ollen analogen Monitoren hat auch eine Verknüpfung per (wired) OR noch einigermaßen gut funktioniert. Moderne Technik ist da sehr viel mäkliger...
Winfried J. schrieb: > ne beim TV liegt in den ersten 3 Zeilen normal dunkel getasteten Zeilen > der Videotext. und letztens wieder Konserve vom NAS geschaut und dort ist die oberste Zeile (Videotext) vom AVI auch im VLC sichtbar gewesen, ich hatte gegrübelt wie man die alten VT Infos aus 1985 wieder rausbekommt. Mein VT Dekoder für die ISA Slots bekomme ich ja nicht mehr in einen PC
Joachim B. schrieb: > und letztens wieder Konserve vom NAS geschaut und dort ist die oberste > Zeile (Videotext) vom AVI auch im VLC sichtbar gewesen Wohl kaum. Die eine Zeile, die du da siehst, ist nicht der Videotext, denn das steckt erstens in mehr als einer Zeile, zweitens weit jenseits des sichbaren Bereichs und ist drittens ziemlich "bewegt". Das, was du da in der ersten Hälfte der ersten Zeile siehst, ist WSS ("wide screen signaling", selten passte übrigens ein Akronym weniger zur Funktion der Sache...) Die Decodierung ist für die meisten Bits so primitiv, dass man nichtmal Software dafür benötigt, sondern das locker im Kopf erledigen kann, wenn man das Bitmuster nur sieht...
WSS war als ausgegrauter Menupunkt der 4:3-Optionen in dem Samsung TV soweit ich mich erinnere. Übrigens läuft der ATTiny 2313 des VGA-Signalgenerators aus Hongkong mit einem 20MHz-Oszillator ... wie schafft der bloss die präzisen Sync-Signale damit - sogar bis rauf zu 1280x1024. Aber ich sah auch einen sehr schmalen vertikalen grauen Streifen im schwarzen Testbild, der war auch nicht immer an der gleichen Stelle ...
c-hater schrieb: > Wohl kaum. Die eine Zeile, die du da siehst, ist nicht der Videotext, doch weil sich der Inhalt ständig ändert, also so als Morsezeichen Aber evtl. war mehr als eine Zeile vom Videotext benutzt, dann reicht die eine sichtbare nicht.
c-hater schrieb: > Das absolut wichtigste ist, dass der Hsync auch während des Vsync weiter > läuft, nur halt invertiert. Weil das so ist: Hsync XOR Vsync = CSync! > > Bei ollen analogen Monitoren hat auch eine Verknüpfung per (wired) OR > noch einigermaßen gut funktioniert. Moderne Technik ist da sehr viel > mäkliger... Was meinst du mit invertiert ? Ich habe einfach den Low-aktiven H-Sync weiterlaufen lassen während des (ebenfalls Low-aktiven) V-Sync - also der H-Sync läuft durchgehend Low-aktiv durch. Wie steht es denn in der VGA-Spezifikation ?
Ich habe es ergoogelt :-) Auf dem geblankten Grünkanal soll ein XOR-Ergebnis der beiden Sync-Signale ausgegeben werden, und zwar während des V-Sync. Das ist dann wohl so ein Composite-Sync-Signal auf Grün. Also nehme ich an dass mein normales H-Sync während V-Sync schon in Ordnung ist - es hat ja nichts mit dem Grünkanal zu tun.
> Nur der Quarz ist etwas schwer zu bekommen
Zu 8-Bit Zeiten reichte bei meinen "Videoerzeugern" auch
ein simpler LC-Oszillator. Nur mal so als Tip.
Keine Ahnung ob dem dickethalen Gehampel die 1 % Abweichung
nicht bekoemmlich sind. Den Analogfernseher stoerte es
jedenfalls nicht.
Ich kenne die genauen VGA-Spezifikationen nicht, da die einzige Quelle eine kaum laden wollende russische Seite war - vermutlich voll mit Schadprogrammen usw. Daher weiss ich nicht welche Abweichungen die Sync-Signale verkraften. Doch die Pixel-Abtast-Frequenz ist vermutlich sehr pingelig in diesen VGA-zu-HDMI-Konvertern, da sie bestimmt fix eingestellt ist. Bei 640 Bildpunkten würde eine Abweichung im Takt irgendwann eine benachbarte Pixelgrenze erreichen, was natürlich fatal wäre.
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.