Hallo Leute.
Ich verzweifele gerade, bei dem Versuch mit meine Spartan3 ein PAL
Signal zu erzeugen, welches dann über Scart RGB zum Fernseher soll
Die monochrome Ausgabe über Composite funktioniert richtig gut und
erfolgt über das gleiche Kabel.
Als "Fernseher" nutze ich momentan den Commodore 1084, der normalerweise
von einem Amiga gefüttert wird und definitiv funktionstüchtig ist.
Er bietet außerdem einen Schalter, mit dem Ich einstellen kann, ob er
Composite oder RGB des Scart-Kabels darstellen soll.
Mein Problem ist nun, dass das Bild im RGB Modus am Anfang nach rechts
ausschwenkt und dabei auch stark flimmert. Erst nach ein paar Zeilen
fängt sich die Synchronisation, wobei das Flimmern immer noch präsent
ist. Dazu kommen starke Unschärfen.
Woran kann das liegen ?
Das Composite Signal, welches ja offensichtlich vernünftig dargestellt
wird, sollte doch eigentlich auch den Sync für den RGB Modus liefern.
Ich informiere mich unter anderem über
http://de.wikipedia.org/wiki/Fernsehsignal
>Wie sieht das Sync Signal während des VSync aus? Lässt du dabei VSync>weiterlaufen, oder ist das Sync Signal in dieser Zeit dauerhaft aktiv?
Ich verstehe die Fragestellung nicht ganz.
Das beste währe es wohl, wenn Ich meinen Code poste.
Das ist ein Untermodul, welches das eigentliche Grafikmodul mit
Timingdaten versorgt.
Wenn sync in diesem Modul 1 ist, wird Composite im Scart auf 0 V
gezogen.
Ist es 0, liegt der Pegel bei 0,3V und manchmal eben höher, da ein
Monochromes Signal mit übertragen wird.
Wenn Sync auf 1 ist, also 0 V, werden auch automatich die RGB Lines auf
0 V gezogen.
Ich weiß, dass der Stil extrem grausig ist. Wenn es funktioniert, werde
Ich eine State-Machine schreiben.
clk80 ist eine 80MHz Clock.
1
reg [13:0] pal_y;
2
reg [13:0] pal_x;
3
4
reg sync;
5
reg visiblewindow;
6
reg backporch;
7
8
assign syncout=sync;
9
assign visiblewindowout=visiblewindow;
10
11
assign backporchout=backporch;
12
13
14
15
assign newline=(pal_x>=0 && pal_x<200);
16
assign newframe=(pal_y==0);
17
18
reg pixelclock;
19
reg [5:0] pixelclockcounter;
20
21
assign pixelclockout=pixelclock;
22
23
initial
24
begin
25
pal_x=0;
26
pal_y=0;
27
pixelclockcounter=0;
28
backporch=0;
29
sync=0;
30
end
31
32
parameter linelength=5120;
33
parameter halflinelength=linelength/2;
34
35
parameter Normalsync=376;
36
parameter backporchsync=800;
37
parameter frontporchsync=132;
38
39
parameter shortsync=Normalsync/2;
40
parameter longsync=halflinelength-Normalsync;
41
42
always @ (posedge clk80)
43
begin
44
//Ausgangssituation für jeden Durchlauf
45
46
//Nach jedem Clock zählen wir die X Position hoch
47
pal_x=pal_x+1;
48
49
50
if (pal_x==linelength) //5120 clk80 posedges pro Zeile ala 64 Mikrosekunden
51
begin
52
pal_x=0;
53
pal_y=pal_y+1;
54
pixelclockcounter=0;
55
56
if (pal_y==312) //Nach jedem Frame
57
begin
58
pal_y=0;
59
60
end
61
end
62
63
64
//Nun kommen wichtige Signale für ein korrektes PAL Signal.
65
66
if (pal_y >= 5 && pal_y <=309) //In diesen Zeilen ist das sichtbare Bild
67
begin
68
69
if (pal_x >= 0 && pal_x < frontporchsync) //Frontporch
70
begin
71
sync=0;
72
backporch=1;
73
visiblewindow=0;
74
75
end
76
77
else if (pal_x >= frontporchsync && pal_x < frontporchsync+Normalsync) //1 Normal Sync
78
begin
79
sync=1;
80
backporch=0;
81
visiblewindow=0;
82
83
end
84
else if (pal_x>=frontporchsync+Normalsync && pal_x< frontporchsync+Normalsync+backporchsync) //Back Porch
85
begin
86
backporch=1;
87
visiblewindow=0;
88
sync=0;
89
end
90
else //Die sichtbaren Daten
91
begin
92
backporch=0;
93
sync=0;
94
visiblewindow=1;
95
96
if (pixelclockcounter==0)
97
pixelclock=1;
98
else
99
pixelclock=0;
100
101
pixelclockcounter=pixelclockcounter+1;
102
if (pixelclockcounter==11)
103
pixelclockcounter=0;
104
105
end
106
end
107
else
108
begin
109
visiblewindow=0;
110
backporch=0;
111
112
if (pal_y==0 || pal_y==1) //2 Long Syncs
113
begin
114
if ((pal_x>=0 && pal_x<longsync) || (pal_x>=2560 && pal_x<2560+longsync))
115
sync=1;
116
else
117
sync=0;
118
119
end
120
else if (pal_y==2) //Ein Long und ein Short Sync
121
begin
122
123
if ((pal_x>=0 && pal_x<longsync) || (pal_x>=2560 && pal_x<2560+shortsync))
124
sync=1;
125
else
126
sync=0;
127
end
128
else if (pal_y==3 || pal_y==4 || pal_y==309 || pal_y==310 || pal_y==311)//2 Short Syncs
129
begin
130
131
if ((pal_x>=0 && pal_x<shortsync) || (pal_x>=2560 && pal_x<2560+shortsync))
Andre Z. schrieb:
>>Wie sieht das Sync Signal während des VSync aus? Lässt du dabei VSync>>weiterlaufen, oder ist das Sync Signal in dieser Zeit dauerhaft aktiv?> Ich verstehe die Fragestellung nicht ganz.
Sorry, ich meinte HSync im 2. Satz.
Aber das scheint der Fall zu sein wenn ich den Code richtig
interpretiere.
Hast du das Timing rund um den VSync mal simuliert bzw. nachgemessen?
Ein verzerrtes Bild deutet immer darauf hin, dass das Timing falsch ist,
daher die Frequenz im Monitor wegdriftet und die PLL erst wieder
einrasten muss.
Andre Z. schrieb:
> Mein Problem ist nun, dass das Bild im RGB Modus am Anfang nach rechts> ausschwenkt und dabei auch stark flimmert. Erst nach ein paar Zeilen> fängt sich die Synchronisation, wobei das Flimmern immer noch präsent> ist. Dazu kommen starke Unschärfen.
Hmm, also die Commodore Monitore hatten manchmal etwas Probleme. Hast Du
schonmal die VCR-Taste gedrückt? Ist vielleicht der Pegel des
Synchronsignales falsch? Es müsste genau die selben Pegel wie beim
normalen Videosignal sein. Wie schon gesagt, die alten Commodore
Monitore sind da vom Pegel her etwas zickig.
>Hmm, also die Commodore Monitore hatten manchmal etwas Probleme.
Das glaube ich. Den Atari ST mag er leider auch nicht.
>Hast Du schonmal die VCR-Taste gedrückt?
Das macht es nur noch schlimmer.
>Ist vielleicht der Pegel des>Synchronsignales falsch? Es müsste genau die selben Pegel wie beim>normalen Videosignal sein.
Ich könnte dich küssen! Danke!
Es lag tatsächlich am Pegel.
Meine D/A Wandler für die Farbanteile sind nicht ganz akkurat.
100 % liegt bei 0,9 V. Erlaubt sind aber eigentlich nur 0,7.
Aber eigentlich sollte das doch nicht so den Unterschied machen, oder ?
Auf jeden Fall scheint der 1084 von Commodore sich nicht an die
Spezifikationen zu halten.
Ich hatte vorher 750 Ohm zwischen 3,3V Ausgang und dem Composite Eingang
am Scart Kabel. Der Eingangswiderstand bei Composite sollte bei 75 Ohm
liegen.
3,3*75/(750+75)=0,3 V
Laut Spezifikation müsste das reichen. Tat es aber nicht.
3,3*75/(300+75)=0,66 V
Selbst das reicht nicht...
3,3*75/(200+75)=0,9 V
Erst jetzt habe ich keine Synchroprobleme mehr.
Aber warum muss der Schwarzlevel vom Composite dem hellsten Level des
RGB Signals entsprechen ?
Das macht doch keinen Sinn!
Das Problem ist jetzt zwar gelöst und Ich bin relativ zufrieden.
Jedoch habe ich nun nicht mehr die Möglichkeit parallel noch ein
Composite Signal mitzuschicken.
EDIT:
Mit 100 Ohm wirkt es gefühlsmäßiger noch klarer.
3,3*75/(100+75)=1,4 V
Aber ist das noch erlaubt ?
Und vielleicht ist es auch nur Einbildung.
Andre Z. schrieb:
> Aber warum muss der Schwarzlevel vom Composite dem hellsten Level des> RGB Signals entsprechen ?> Das macht doch keinen Sinn!
Eigentlich sollte es das nicht. Wie schon gesagt die alten Monitore
haben da oft schwierigkeiten. Übrigens manchmal auch, wenn Du die an
eine normgerechte Quelle anschließt. Was ich noch mal machen würde, wäre
einfach einen Elko in Reihe schalten um den Gleichspannungsanteil zu
eliminieren. Vielleicht ändert das was bei den Monitoren.
> EDIT:> Mit 100 Ohm wirkt es gefühlsmäßiger noch klarer.> 3,3*75/(100+75)=1,4 V>> Aber ist das noch erlaubt ?> Und vielleicht ist es auch nur Einbildung.
Also kaputt geht bei 1,4 Volts noch nichts.