Hallo zusammen! Ich habe mir die wichtigsten Seiten und Diagramme aus dem Netz zum Thema VGA-Signal ausgedruckt. Speziell der 640x400 @70Hz Modus interessiert mich. Ich musste aber feststellen dass gewisse Unterschiede in den Dauern der vorderen und hinteren horizontalen Schwarzschultern (je nach Webseite) bestehen. Gibt es da Toleranzen oder neue Standards ? Auch würde ich gerne wissen ob man unbedingt einen Schwarzwert (0V) auf die Pixel ausgeben muss während des horizontalen und vertikalen Synchronisations-Signals. Das würde wohl die Schaltung und das Steuerprogramm komplizierter machen. Edit: muss das Horizontale Synchronisationssignal weiterlaufen während der vertikalen Synchronisation ?
:
Bearbeitet durch User
Moin, > > Ich musste aber feststellen dass gewisse Unterschiede in den Dauern der > vorderen und hinteren horizontalen Schwarzschultern (je nach Webseite) > bestehen. Gibt es da Toleranzen oder neue Standards ? Zu den Zeiten, als diese Aufloesungen noch modern waren, gab's an den Monitoren Regler fuer Bildbreite,-hoehe,-lage. Damit konnte man Schwarzschultertimings ein bisschen an den jeweiligen Monitor anpassen. Ich wuerd' mal vermuten, dass VESA da die letzten "Standardtimings" spezifiziert hat. > Auch würde ich gerne wissen ob man unbedingt einen Schwarzwert (0V) auf > die Pixel ausgeben muss während des horizontalen und vertikalen > Synchronisations-Signals. Das würde wohl die Schaltung und das > Steuerprogramm komplizierter machen. Sagt der, der sich im Nachbarthread mit OpAmps und R2R-DACs verkuenstelt... Ich wuerde das Video waehrend der gesamten Austastluecke schwarztasten. Kann sein, dass es mit bestimmten Monitoren auch so geht, aber das Risiko besteht, dass irgendwelcher Scheiss, den du im Strahlruecklauf ausgibst, sichtbar wird. > > Edit: muss das Horizontale Synchronisationssignal weiterlaufen während > der vertikalen Synchronisation ? Sollte. Kann sein, das es Monitore gibt, die's nicht unbedingt brauchen, aber sicher ist's nicht. Auch beim Composite-Sync laueft H- waehrend des V-Sync weiter. Gruss WK
H-G S. schrieb: > Ich musste aber feststellen dass gewisse Unterschiede in den Dauern der > vorderen und hinteren horizontalen Schwarzschultern (je nach Webseite) > bestehen. Gibt es da Toleranzen oder neue Standards ? Es gibt Toleranzen und Standards, beides wie Sand am Meer. Ist aber letztlich ziemlich unkritisch, wirklich wichtig sind nur zwei Sachen: 1) Mindestbreite der Syncs nicht unterschreiten (gilt für alle Monitore) 2) Zeilenfrequenz des gewünschten Modus möglichst genau treffen und vor allem auch in der Folge möglichst konstant halten (gilt vor allem für Monitore mit Framebuffer, also das, was man heute üblicherweise so benutzt). > Auch würde ich gerne wissen ob man unbedingt einen Schwarzwert (0V) auf > die Pixel ausgeben muss während des horizontalen und vertikalen > Synchronisations-Signals. Sollte man, wenn man die Bildlage-Autokonfiguration moderner Monitore benutzen will. Die arbeitet üblicherweise am besten und schnellsten, wenn in der Blank-Zeit "Schwarz" ankommt. Sie funktioniert allerdings üblicherweise auch, wenn das nicht der Fall ist. Bloß halt dann längst nicht so gut. Durchaus möglich, dass du dann von Hand nachkorrigieren musst. Bei ollen Monitoren ohne Framebuffer musst du den Kram hingegen ohnehin von Hand justieren. Da spielt es keine Rolle, eventuelle Farbfehler ausserhalb des eigentlichen Bildbereiches wären die einzige Folge und die manuelle Konfiguration führt ja im Endeffekt dazu, dass nur noch der eigentliche Bildbereich sichtbar ist, sprich: es wird dann scheissegal, was ausserhalb abgeht. > Edit: muss das Horizontale Synchronisationssignal weiterlaufen während > der vertikalen Synchronisation ? Ja, sollte zumindest. Bei ollen Monitorgurken kann (und wird es auch meist) auch mal ohne das gut gehen, aber moderne Monitore mit Framebuffer brauchen ziemlich zwingend ein durchgehenden HSYNC, weil der die Basis für deren eigenes Timing ist und die Zeitkonstante der PLL, über die die daraus den Pixeltakt gewinnen, ziemlich klein ist, was wiederum dem Wunsch geschuldet ist, dass die Autokonfiguration in erträglicher Zeit zu einem Ergebnis kommt... Also ich würde dir vorschlagen, in beiden Belangen keine Kompromisse einzugehen. Der Mehraufwand an Steuerlogik ist minimal, wenn man es richtig durchdenkt. Bezüglich des durchgehenden HSYNC kostet es ein XOR-Gatter und bezüglich des definierten Schwarz in den Austastlücken (mindestens) ein "Extra-Pixel" pro Zeile, also nur minimal mehr RAM und eine andere Konstante für den Increment des Pixelzählers am Zeilenende, also eine "stride"-Logik. Die sollte man aber sowieso einbauen, um eine Vielzahl "billiger" Effekte zu ermöglichen, z.B. ein schnelles und trotzdem butterweiches horizontales Scrolling des Bildinhaltes...
Sehr hilfreich, danke dir! Ich hätte noch eine Frage: Wenn der V-Sync mitsamt seiner hinteren Schwarzschulter vorbei ist, was kommt danach ? Direkt ein H-Sync oder erst die vordere Schwarzschulter des H-Sync ? Edit: Mikrocontroller mit 200ns Befehlszeit werden den Sync wohl nicht präzise genug erzeugen oder ?
:
Bearbeitet durch User
H-G S. schrieb: > Sehr hilfreich, danke dir! > > Ich hätte noch eine Frage: > Wenn der V-Sync mitsamt seiner hinteren Schwarzschulter vorbei ist, was > kommt danach ? Direkt ein H-Sync oder erst die vordere Schwarzschulter > des H-Sync ? Google mal nach "DMTv1r11.pdf" (ohne "" eingeben). In diesem PDF findest DU ab Seite 11 die genauen SIgnaldiagramme von der VESA Standardisierungsorganisation sowie die exakten Zeitangaben. > Edit: Mikrocontroller mit 200ns Befehlszeit werden den Sync wohl nicht > präzise genug erzeugen oder ? Kommt auf den Monitor an. Spätenstens beim Pixeltakt hört es dann aber endgültig auf. Ein FPGA wäre die geeignetere Plattform. Oder ein LCD plus Controllerchip wie SSD1963 oder Epson S1D13781. Oder ein kleiner ARM oder PIC mit Hardware-LCD-Interface. fchk
Eigentlich ist das gar keine so große Sache eine VGA Ausgabe zu erzeugen, sind ein paar Zähler und Vergleiche und PortPins schalten, hier mal der pseudeo code für nen VGA (tester) controller den ich in nem FPGA gebastelt habe, der macht zwar 800x600 aber...
1 | constant FrameWidth = 800; |
2 | constant FrameHeight = 600; |
3 | constant hFrontPorch = 40; |
4 | constant hSyncPulse = 128; |
5 | constant hBackPorch = 88; |
6 | constant vFrontPorch = 1; |
7 | constant vSyncPulse = 4; |
8 | constant vBackPorch = 23; |
9 | constant WholeLine = (FrameWidth + hFrontPorch + hSyncPulse + hBackPorch); |
10 | constant WholeFrame = (FrameHeight + vFrontPorch + vSyncPulse + vBackPorch); |
11 | |
12 | while(1) |
13 | wait until rising_edge(clock_pixel); |
14 | if (currentpixel < hsyncPulse) then vga_hsync = HIGH |
15 | else vga_hsync = LOW |
16 | if (currentline < vsyncPulse) then vga_vsync = HIGH |
17 | else vga_vsync = LOW |
18 | if ((currentpixel >= (hsyncPulse + hbackPorch)) and (currentpixel < (WholeLine - hFrontPorch))) then |
19 | if ((currentline >= (vSyncPulse + vBackPorch)) and (currentline < (WholeFrame - vFrontPorch))) then vga_out = PixelColor |
20 | else vga_out = BLACK |
21 | else vga_out = BLACK |
22 | if (currentpixel < (WholeLine - 1)) then currentpixel = currentpixel + 1; |
23 | else
|
24 | currentpixel = 0; |
25 | if (currentline < (WholeFrame - 1)) then currentline = currentline + 1; |
26 | else currentline = 0; |
... evtl hilft es dir ja weiter.
Angehängte Dateien:
-
VGA_mit_Blank.jpg
86 KB
Denkt ihr das diese Schwarzwert-erzwing-Schaltung vorteilhaft ist ? Ein Latch wird am Ausgang hochohmig gesteuert und Pulldown-Widerstände erzeugen die Schwarz-Kodierung am Buffer. Könnte das Probleme mit der Pixelbreite des ersten und letzten Pixels einer Zeile bringen (bei unpräziser Ansteuerung durch den Controller) ?
:
Bearbeitet durch User
Moin, H-G S. schrieb: > Denkt ihr das diese Schwarzwert-erzwing-Schaltung vorteilhaft ist ? Selbstverstaendlich ist diese Schaltung vorteilhaft. Fuer die Chiphersteller und Platinenhersteller. Weil die dir dann mehr verkaufen koennen. Sonst ist's eher arg kompliziert. Gruss WK
Ich habe vergessen zu erwähnen dass ich die Schwarz-Erzwingung später für eine externe SRAM-Fütterung des DAC-Buffers benötige. Die Schaltung hier ist nur für einen Prototypen bei dem ein Mikrocontroller ein paar Pixelwerte erzeugt um das Sync-Timing zu testen. Ich habe die Befürchtung dass es Problem mit dem ersten Pixel geben könnte (zu schmal) bzw. mit dem letzten Pixel (zu breit).
Moin, Ich weiss nicht, was du da im Einzelnen vorhast. Aber ich weiss, dass z.B. der Sinclair ZX80 und ZX81 mit ueberschaubarer Zusatzlogik es schon vor >30 Jahren geschafft haben, Videosignale mit vernuenftigem Timing auszugeben. Und das mit einer 3.25 MHz getakteten CPU. Und dabei waerend ihres V-Blankings sogar auch noch BASIC interpretieren konnten... In der Zwischenzeit haben gefuehlt ca. 1.0e+6 Leute aehnliches auch in Farbe und Bunt mit allen moeglichen anderen µControllern, FPGAs, etc. hingebracht. Und das auch noch im Netz dokumentiert. Klar, wenn dein Pixeltakt wackelig ist, koennen Pixel auch mal laenger oder kuerzer sein. Dann taugt deine Schaltung halt nix. Gruss WK
Dergute W. schrieb: > In der Zwischenzeit haben gefuehlt ca. 1.0e+6 Leute aehnliches auch in > Farbe und Bunt Das VGA-Timing ist ein bisschen anspruchsvoller als das für Glotzenbetrieb verwendete NTSC/PAL-Timing. Letzteres arbeitet mit einer Zeilenfrequenz von 15625 Hz, ersteres nutzt knapp 32 kHz. Die zu produzierende Datenrate resp. der Pixeltakt ist halt auch um einiges höher als im Glotzenbetrieb.
Es könnte ein Problem mit der Abweichung des Pixeltaktes (79,44ns) geben! Ich finde keinen Quartz/Oszillator der genau 12.5875 MHz macht (bzw. 25.175MHz zum Halbieren). Diese Frequenz brauche ich aber für den Pixeltakt meiner 320 Pixel einer Bildzeile (79,44ns). Der nächste verfügbare Quartzoszillator wäre 12.288 MHz, das ergibt eine Abweichung von 1,94ns pro Pixel. Bei 320 Pixel kommt es früher als gedacht zu einer Summierung der Abweichung sodass sich Pixel komplett verschieben. Es müssten etwa 621ns Verschiebung sein nach 320 Pixeln. Denkt ihr dass das bedenklich ist ? :-)
:
Bearbeitet durch User
Du solltest den doppelten Pixeltakt verwenden und jedes Pixel doppelt ausgeben, so habens früher die VGA-Karten auch gemacht, wenn mit so geringer Horizontalauflösung gearbeitet wurde. In der Original-VGA-Karte von IBM wurden zwei Taktfrequenzen verwendet, 25.175 MHz und 28.322 MHz, der höhere Takt wird im Textmodus verwendet, wo die Horizontalauflösung bei 720 statt 640 Pixeln liegt. > Bei 320 Pixel kommt es früher als gedacht zu einer Summierung der > Abweichung sodass sich Pixel komplett verschieben. Es müssten etwa 621ns > Verschiebung sein nach 320 Pixeln. Was für ein Gerät soll das Signal darstellen?
> Ich finde keinen Quartz/Oszillator der genau 12.5875 MHz macht (bzw. > 25.175MHz zum Halbieren). Diese Frequenz brauche ich aber für den > Pixeltakt meiner 320 Pixel einer Bildzeile (79,44ns). Schlecht gesucht: https://www.digikey.de/product-detail/de/ecs-inc/ECS-100A-251.7/X130-ND/79229 fchk
Leider brauche ich den halben Takt, also 12,5875MHz. Ich benötige nämlich die halbe horizontale Auflösung einer 640er Zeile. Der 25,175MHz-Takt wäre für die volle 640er Auflösung und müsste erst halbiert werden. Aber das wäre bestimmt irgendwie mit Logikbausteinen möglich ...
H-G S. schrieb: > Leider brauche ich den halben Takt, also 12,5875MHz. Nein. > Ich benötige nämlich die halbe horizontale Auflösung einer 640er Zeile. Ja, aber das kannst Du mit dem richtigen Takt auch erreichen - gibt jedes von Deinen 320 Pixeln doppelt aus.
Rufus Τ. F. schrieb: >> Ich benötige nämlich die halbe horizontale Auflösung einer 640er Zeile. > > Ja, aber das kannst Du mit dem richtigen Takt auch erreichen - gibt > jedes von Deinen 320 Pixeln doppelt aus. Aber mein AVR mit dem ich die Testschaltung aufbauen will geht nur bis 20MHz! Ich sah gerade dass man mit Flipflops einen Frequenzteiler bauen kann.
H-G S. schrieb: > Aber mein AVR mit dem ich die Testschaltung aufbauen will geht nur bis > 20MHz! Du willst keine 1000er Serie bauen und am Nordpol oder in der Sahara betreiben. Dein AVR kann 25MHz bestimmt. Der AVR in meinem VGA Terminal läuft sauber bei 5V mit einem 25MHz Quarz.
Georg G. schrieb: > Du willst keine 1000er Serie bauen und am Nordpol oder in der Sahara > betreiben. Dein AVR kann 25MHz bestimmt. Der AVR in meinem VGA Terminal > läuft sauber bei 5V mit einem 25MHz Quarz. Soll ich meinen ATtiny auf 25MHz übertakten ? Ansonsten stach mir eben ein 74HC74-Flipflop ins Auge mit 15ns Umschaltzeit. Edit: weisste was ? Ich kaufe einfach beide und probier es aus! Edit2: Digikey könnte teuer werden oder ? Ab 50 Euro scheinbar versandkostenfrei, aber was ist mit Zoll ?
:
Bearbeitet durch User
H-G S. schrieb: > Soll ich meinen ATtiny auf 25MHz übertakten ? Ja. Und noch ein Hinweis: Andere VGA Projekte können mit einem handelsüblichen 25MHz Quarz leben. Den gibt es für kleines Geld an jeder Ecke.
Georg G. schrieb: > Und noch ein Hinweis: Andere VGA Projekte können mit einem > handelsüblichen 25MHz Quarz leben. Den gibt es für kleines Geld an jeder > Ecke. Stellt sich so ein VGA-zu-HDMI-Konverter automatisch auf die Pixelfrequenz ein oder wird das Farbsignal einfach durchgereicht ? Bei Letzterem wäre es ja egal ob die Pixelzeile insgesamt ein paar Pixel zu kurz ist.
H-G S. schrieb: > Ansonsten stach mir eben ein 74HC74-Flipflop ins Auge mit 15ns > Umschaltzeit. Nadelimpulse sind nicht ungefährlich. Immer Schutzbrille tragen, dann kann man solchen Effekten die Schwarzschulter zeigen. Dein Lieblingslied ist bestimmt: "Neverending Story"... https://www.youtube.com/watch?v=x1afn71-0sI :) -Feldkurat-
H-G S. schrieb: > Aber mein AVR mit dem ich die Testschaltung aufbauen will geht nur bis > 20MHz! Und? Muss denn Dein AVR jedes Bit von Hand schieben? Du könntest jeweils ein komplettes Byte parallel an ein Schieberegister (z.B. 74xx165) ausgeben, das dann den Kram mit dem richtigen Pixeltakt gespeist 'rausschiebt. Und die Pixelverdoppelung lässt sich einfach mit zwei kaskadierten Schieberegistern (dann z.B. 74xx589) oder einem 16-Bit-Schieberegister (74xx674) bewerkstelligen, bei denen je zwei Eingänge mit einem Bit Deines 8-Bit-Ports belegt sind.
ach ja, VGA auf einem AVR uC. Schon 1000 Mal bewiesen das es mit Kompromissen bei Auflösung und Farbtiefe geht. Und auch schon genau so oft eindrucksvollen Aminationen und Anwendungen gesehen. Also warum nicht einfach ein bestehendes Projekt 1:1 nachbauen ? Oder eine technisch bessere Umsetzung wählen, z.B. das billigste TFT mit SSD1963 auf Ebay (ca. 30 €) schiessen und an den AVR flanschen. Dann das TFT ablöten, einen DAC wie in Beitrag "Re: Zeigt her eure Kunstwerke (2017)" anlöten und fertig. Der SSD1963 bietet 1 MB Framebuffer und genug Saft, 640x480 und 800x480 darzustellen. Die Schaltung unter Beitrag "Re: VGA Signal Fragen" wird keine guten Ergebnisse liefern, da ein R2R Netzwerk weder die Signalpegel noch die Impedanz für VGA bietet. Aber diese Behauptung ist widerlegt, so bald die R2R Schaltung funktionsfähig auf dem Tisch liegt. Wenns nur um die Erzeugung eines Testbilds geht empfehle ich http://www.pyroelectro.com/projects/masochists_video_card/ Gruß, dasrotemopped.
Das mit den verfügbaren Quartz/Oszillatoren hat sich erübrigt! Ich habe gelesen dass diese VGA-zu-HDMI-Konverter nur 640x480 und 800x600 etc. als Eingangssignal unterstützen. Dann bleiben nur folgende Takt-Optionen: 10MHz für 200x150 Pixel (800x600 durch 4) 18MHz für 320x240 Pixel (640x480 durch 2) 20MHz für 400x300 Pixel (800x600 durch 2) Ich denke ich probiere die 10MHz, da dürfte es den geringsten EMI geben.
H-G S. schrieb: > Ich habe gelesen dass diese VGA-zu-HDMI-Konverter nur 640x480 und > 800x600 etc. als Eingangssignal unterstützen. Aha. Dann würden sie z.B. im Textmodus nicht funktionieren. Im PC-Umfeld ist so etwas dann nicht sinnvoll verwertbar. Könnte es sein, daß die Beschreibung etwas ... unvollständig ist?
Rufus Τ. F. schrieb: > Könnte es sein, daß die Beschreibung etwas ... unvollständig ist? Es waren die Spezifikationen von den billigsten VGA-HDMI-Konvertern, also um 15-30 Euro rum. Aber es gibt scheinbar noch welche ab 50 Euro, vielleicht unterstützen die mehrere VGA-Auflösungen.
H-G S. schrieb: > Ich habe gelesen dass diese VGA-zu-HDMI-Konverter nur 640x480 und > 800x600 etc. als Eingangssignal unterstützen. Das ist definitiv Unsinn. Schon für ca. 20€ kannst du (in Deutschland!) welche kaufen, die jeden VGA- oder VESA-Modus korrekt umsetzen, so lange der angeschlossene HDMI-Empfänger auf Anfrage anzeigt, dass er in der Lage und willens ist, mit diesem Format umgehen zu können... De facto handelt es sich bei diesen Wandlern um genau die gleichen Bausteine, die auch in jedem heutigen TV oder Monitor sitzen, sofern dieser überhaupt noch einen analogen VGA-Eingang (oder analogen Videoeingang) besitzt...
Beitrag #5108606 wurde von einem Moderator gelöscht.
Thread beobachten
Seitenaufteilung abschaltenBitte 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.