Maximal darstellbarer Bereich des (PAL) VIC-II
-
Tobias -
15. März 2025 um 17:51 -
Erledigt
Es gibt 107 Antworten in diesem Thema, welches 5.733 mal aufgerufen wurde. Der letzte Beitrag (
-
-
Falls jemand Infos zu NTSC hat, immer her damit.
Vielleicht sind es ja auch tatsächlich 247 sichtbare Linien.
Das könnte hinkommen, wenn z.B. das obere v-Blanking nur halb so groß ist wie bei PAL (4 vs. 8 Zeilen).
In diesem Falle wäre der VICE Screenshot nur geringfügig falsch.Neue Annahme:
4 upper v-blank
22 upper border
20025 lower border
12 lower v-blankDer VICE Screenshot ist:
23 upper border
200
24 lower border -
... ohne selbst etwas substantielles beitragen zu können: interessantes Thema!
Begrifflichkeiten wie "Overscan" verband ich bisher nie mit dem C64, sondern eher mit dem Amiga (dank der gleichnamigen Pref).
Dachte bislang, beim C64 ist alles "festverdrahtet" - man lernt auch nach fast 40 Jahren Benutzung desselben noch was hinzu! -
Noch was zu der vertikalen Auslösung.
Ich habe mal ein quick-and-dirty Programm gemacht das $d012 (Raster Zeile) in $d020 (Border Color) kopiert.
Sceenshots
vice (debug border - mit screen capture darüber)
PALBitte melde dich an, um diesen Anhang zu sehen.
NTSC
Bitte melde dich an, um diesen Anhang zu sehen.Auf dem Oszilloskop sieht das dann so aus (in der Nähe vom VSYNC-Signal)
PAL
Bitte melde dich an, um diesen Anhang zu sehen.
NTSC
Bitte melde dich an, um diesen Anhang zu sehen.Bitte melde dich an, um diesen Anhang zu sehen.
Das gibt dann
PAL
VBLANK (Inkl. VSYNC) 11 Zeilen
oberen Rahmen 52 Zeilen
main Display 200 Zeilen
unteren Rahmen 49 Zeilen
Insgesamt 312NTSC
VBLANK (Inkl. VSYNC) 11 Zeilen
oberen Rahmen 27 Zeilen
main Display 200 Zeilen
unteren Rahmen 25 Zeilen
Insgesamt 263
-
Sceenshots
vice (debug border - mit screen capture darüber)
Hmm, vielleicht ist VICE ja auch in dieser Hinsicht 'falsch' programmiert?
Bei den PAL-Werten bin ich mir eigentlich sicher, falls Borderpolizei keinen Mist anzeigt. Jedenfalls konnte ich durch Verstellen des CRT oben keine weiteren Linien mehr sehen.

Bei den unteren Bordern kommen wir ja schonmal auf die gleichen Zahlen.
Alles anzeigenPAL
VBLANK (Inkl. VSYNC) 11 Zeilenoberen Rahmen 52 Zeilen
main Display 200 Zeilen
unteren Rahmen 49 Zeilen
Insgesamt 312
NTSC
VBLANK (Inkl. VSYNC) 11 Zeilenoberen Rahmen 27 Zeilen
main Display 200 Zeilen
unteren Rahmen 25 Zeilen
Insgesamt 263
NTSC: 419 x
243NTSC: 419 x 247
Hier mal, wie es momentan für mich plausibel aussieht:
-
VBLANK (Inkl. VSYNC) 11 Zeilen
Das wäre sportlich.

Anbei mal eine Überlegung, warum die 16 bzw. 20 Zeilen plausibel sein könnten. -
... ohne selbst etwas substantielles beitragen zu können: interessantes Thema!
Danke. Es ist auch für mich interessant, darum mache ich es. Wie man im Thread sieht, lerne auch ich durch Hilfe anderer während eines solchen Treads immer dazu.

Begrifflichkeiten wie "Overscan" verband ich bisher nie mit dem C64, sondern eher mit dem Amiga (dank der gleichnamigen Pref).
Dachte bislang, beim C64 ist alles "festverdrahtet" - man lernt auch nach fast 40 Jahren Benutzung desselben noch was hinzu!
Overscan macht der Bildschirm, nicht der Zuspieler.
Das war üblich, weil man bei den Röhren das nicht so genau im Griff hatte und auch um Verzerrungen an den Rändern zu kaschieren.
In der Praxis üblich dürfte ein Overscan von etwa 5% (90 % des Bildes bleiben sichtbar) gewesen sein.Übrigens haben auch heute noch fast alle Flachbild-TV per default einen Overscan eingestellt, auch wenn das eigentlich bei den digitalen Bildsignalen Unsinn ist.
Ich habe das bei mir ausgeschaltet. Ganz ganz selten sehe ich bei älteren 4:3 Serien dann oben minmales aufgereihtes Pixelrauschen, was z.B. ein Timecode sein kann. Vielleicht lässt man deshalb auch heute oft noch einen Overscan aktiviert.
Was ein (Heim-)Computer an TV-Standard-Signal rausgibt, ist relativ fix, bei allen dieser Quellen. Sonst könnten es die Monitore/TVs nicht anzeigen.
Bei der Vertikalauflösung kann man Computer-seitig eigentlich nur damit spielen, wie groß der Rahmen ist und ob man 1 (progressiv) oder 2 (interlaced) Fields ausgibt.
Die Horizontalauflösung ist nicht so diskret wie die Linineanzahl und ergibt sich dann aus Pixelseitenverhältnis und Bildseitenverhätnis.
Was man dann sieht, hängt vom Overscan des Monitors ab bzw. was der User an den Einstellrädchen dreht.Bis clevere Coder den Rahmen des C64 nutzen konnten, war es auch völlig egal, wie groß (maximal und bei x % Overscan) der Rahmen denn ist.
Eigentlich kann man den Rahmen ja nicht nutzen, aber in den darstellbaren Bereich kann man mit Hilfe von Sprites (oder Rasterlines) 'Pixel' in den eigentlich einfarbigen Rahmen reinmogeln.Beim Amiga konnte man den Rahmen aber auch tatsächlich ohne solche Tricks als Pixelfläche nutzen, oder? Also die Amiga-"Overscan"-Modi.
Das wäre dann auch der gravierende Unterschied des Rahmens C64 vs. Amiga.
Hier
Bitte melde dich an, um diesen Link zu sehen.kannst Du ein wenig von Amiga zu dem Thema lesen.
-
Beim Amiga konnte man den Rahmen aber auch tatsächlich ohne solche Tricks als Pixelfläche nutzen, oder?
Das ging schon beim VIC-20, soweit ich weiß. Der VIC-2 ist in der Hinsicht leider unflexibeler.
-
NTSC
Bitte melde dich an, um diesen Anhang zu sehen.
Zitat von Scott Brockway / Vanessa Dannenberg /via Facebook)OK we checked again, last visible line in the bottom is $0c, first in the top is $21. That's the 128 in 40 cols mode.
Dort kommt man auf eine v-Blanking Lücke nach 12 und vor 33. Was aber auch wieder 20 Zeilen wären und somit >16 und >11
263-20 = 243.
Das sind aber die gleichen Leute, die die 247 (VICE: 23+200+24) sichtbaren Linien für NTSC festgelegt haben. Ich bin verwirrt.

-
C64 Display ist kein PAL oder NTSC, also es ist alles ein bisschen undefiniert.
Der C64 zeigt Bild in Zeilen wo das offiziel per PAL oder NTSC verboten ist, weil die zur VBI (Vertical Blanking Interval) gehören.
-
C64 Display ist kein PAL oder NTSC, also es ist alles ein bisschen undefiniert.
Der C64 zeigt Bild in Zeilen wo das offiziel per PAL oder NTSC verboten ist, weil die zur VBI (Vertical Blanking Interval) gehören.Bei der echten Hardware oder nur in Vice?
Bis nicht jemand auf echter Hardware in PAL mehr als 292 Zeilen und in NTSC mehr als 247 Zeilen angezeigt bekommt, würde ich es dabei belassen.
Das ist ja eh schon alles weit außerhalb des normal angezeigten Bereichs.
Was denkst Du? -
Der Vollständigkeit wegen hab ich mal meine Linealmessungen grafisch und ungeschönt zusammengefasst. Dabei kam mir die Idee, die (bei NTSC teils) angenommenen und auf dem Sony (auch bei "103 % Scan) nicht dargestellten Bereiche maßstäblich einzutragen (transparent und leicht versetzt). Lila ist dabei V-Blanking.
Der Sony LMD-1420 hat eine Anzeigefläche von 283 x 212 mm. Im Bild entsprechen vier Pixel einem Millimeter.
-
Was man wirklich sehen kann hängt vom Anzeigerät ab. Die zahlen 52 + 200 +49 (PAL) , 27 + 200 + 25 (NTSC) sind absolute Maximas.
Ich kann mir vorstellen dass z.B. der LMD-1420 Probleme hat die ganz obene Zeilen da zu stellen. Also dann wird für diese Bildschirm 292 PAL 243 NTSC wohl richtig sein. Aber jedes Gerät hat seine eigene Beschränkungen.
Manche Geräte wie z.B. capture cards können überhaupt nur 240 (NTSC) oder 288 (PAL) Zeilen darstellen. Man kann höchstens, wenn man Glück hat, die Capture Area nach oben verschieben, aber dann verliert mann die unteren Zeilen.
-
Ich kann mir vorstellen dass z.B. der LMD-1420 Probleme hat die ganz obene Zeilen da zu stellen. Also dann wird für diese Bildschirm 292 PAL 243 NTSC wohl richtig sein. Aber jedes Gerät hat seine eigene Beschränkungen.
Der Sony LMD-1420 zeigt im Underscan oben 36 PAL-Linien an, in NTSC ca. 17 (ausgemessen). Also ja, oben schneidet er defiitiv was ab. Siehe Illustration mein Post darüber. Transparent hellblau ist das was beim Sony fehlt von den oberen 43 (PAL) bzw. 22 (NTSC) Linien. 103 % Scan würden aber so oder so nicht ausreichen (der schwarze Bereich), um alle oberen Linien einzufangen. Für Deine 52 PAL-Linien wären es sogar 312/288 = 108 %

Commodore 1084S-P1 mit runtergedrehtem v-scale zeigt oben maximal 38 PAL-Linien.
Mit dem Highscreen DP622/00W konnte ich mit etwas Einstellen oben 43 PAL-Linien sehen. So komme ich auf die 292 Linien, was man im Netz so auch als maximale PAL-Angabe finden kann. Meist ist eher von 284 Linien die Rede.
(Von NTSC hab ich nur die maximale Angabe aus dem VICE-Screenshot. Mangels passendem NTSC-Monitor kann ich das obere Limit nicht testen.
Aber ganz passt der NTSC-Screenshot wohl nicht, weil er unten nur 24 Linien hat: 23+200+24 statt 22+200+25 )Die zahlen 52 + 200 +49 (PAL) , 27 + 200 + 25 (NTSC) sind absolute Maximas.
52-43 = 9 +11 = 20
27-22 = 5 +11 = 1611 Zeilen als 'echtes' V-Blanking war ja das, was Du aus dem Oszilloiskop oben rausgelesen hast. Ganz blicke ich das Signal nicht, aber aus Erfahrung vertraue ich Dir da.

Sind das echte Hardware-Signale oder was von VICE simuliertes?20 bzw- 16 Zeilen ist vielleicht das absolute Minimum, was ein reales (analoges) Anzeigegerät mindestens für V-Blanking braucht?
Das sind umgerechnet immer nur noch weniger als 82 % von dem, was der PAL-/NTSC-Standard vorschreibt. -
capture cards können überhaupt nur 240 (NTSC)
Das ist dann aber dem Digitalformat geschuldet. Normerweise könnten es 243 'aktive' Zeilen sein (486 von 525).
-
Oszi captures sind echte C64er

Vielleicht hilft folgendes auch noch etwas zu erklären wo die 11 Zeilen VBLANK herkommen
Für NTSC gibt es das MOS 6567 VIC-II preliminary datasheet
Bitte melde dich an, um diesen Link zu sehen.
Da seht man auf seite 13
VERTICAL DECODESNAME SET CLEAR FUNCTION VRESET 261 n/a Resets vertical count to zero VSYNC 17 20 Enables vertical sync VEQ 14 23 Enables vertical equalazation (sic) VBLANK 13 24 Blanks video during vert retrace VSW24 55 247 Enables 24 row screen window VSW24 (sic) 51 251 Enables 25 row screen window (Edit: 261 ist für den 'alten' 6567, später ist das geändert worden in 262 (das gibt dann 263 Zeilen))
-
Zusammenfassend:
Echtes V-Blanking haben PAL und NTSC C64 nur für 11 Zeilen (davon 3 mittig als V-Sync).
In der Praxis wurde bisher minimale tatsächliche V-Blanking Werte von 20 (PAL) und 16 (NTSC) Zeilen beobachtet.
So?Woher weißt Du in Deinem Oszilosskop, wo welcher vertical count ist? Und warum fängt das generell nicht "oben am Bildschirm" bei 0 an und ist bei NTSC und PAL verschieden?

-
Der Trick mit dem Oszilloskop ist das ich ein Programm ausführe dass den wert des Raster-registers kopiert im Rahmen-farben. Also kann man die unteren 4 bits von Raster ablesen. (z.b. wenn man eine Zeile hat wo alles am niedrigsten Pegel ist, und danach eine Zeile mit alles auf Max, dan weiss man das das farben 0 und 1 betrifft.)
-
Für NTSC gibt es das MOS 6567 VIC-II preliminary datasheet
Auch der Horizontal-Blank, was ich anhand der Werte aus einem Bitte melde dich an, um diesen Link zu sehen. ausgerechnet hatte, passt pixelgenau zu den Angaben im Datasheet.
Und Deine Bitte melde dich an, um diesen Link zu sehen. zeigen ebenfalls das gleiche.
Zeigt Dein Oszilloskop bei den 9 bzw. 5 "verschollenen V-Sync"-Zeilen ("Too-Early-Lines"?, also nach den 11 echten V-Sync-Zeilen) denn auch z.B. den Color Burst oder weißen VIC-II-Bug in jeder Zeile?
-
Color burst und weisse Pixel fängen direkt nach ende von VBLANK an (also wenn RC=311 für PAL, RC=24 NTSC)
Ich glaube man kann das auch im Video überprüfen.
composite
Bitte melde dich an, um diesen Anhang zu sehen.Bitte melde dich an, um diesen Anhang zu sehen.Bitte melde dich an, um diesen Anhang zu sehen.
luma
Bitte melde dich an, um diesen Anhang zu sehen.Bitte melde dich an, um diesen Anhang zu sehen.Bitte melde dich an, um diesen Anhang zu sehen.
-