Maximal darstellbarer Bereich des (PAL) VIC-II

Es gibt 107 Antworten in diesem Thema, welches 5.738 mal aufgerufen wurde. Der letzte Beitrag (11. April 2025 um 20:56) ist von Tobias.

  • Falls jemand Infos zu NTSC hat, immer her damit.
    Vielleicht sind es ja auch tatsächlich 247 sichtbare Linien.:nixwiss:

    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
    200

    25 lower border
    12 lower v-blank

    Der 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)
    PAL

    Bitte 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 312

    NTSC

    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.:search:
    Bei den unteren Bordern kommen wir ja schonmal auf die gleichen Zahlen. :)

    NTSC: 419 x 243

    NTSC: 419 x 247

    Hier mal, wie es momentan für mich plausibel aussieht:

  • ... 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.:prof:
    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.

  • 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.:oob:

  • 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 = 16

    11 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.

  • 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 DECODES

    NAMESETCLEARFUNCTION
    VRESET261n/aResets vertical count to zero
    VSYNC1720Enables vertical sync
    VEQ1423Enables vertical equalazation (sic)
    VBLANK1324Blanks video during vert retrace
    VSW2455247Enables 24 row screen window
    VSW24 (sic)51251Enables 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. :thumbsup:

    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.