Das Design des Super-Nintendo-Videosystems verstehen

• Das SNES-Video war innerhalb der Grenzen von CRT-Fernsehern und NTSC-Signalen der frühen 1990er Jahre entworfen: 256x224-Bild, 60,098 Hz Framerate und abgestimmte Blankings
• Eine CRT zeichnet keine Pixelraster, sondern Scanlines mit Elektronenkanonen, RGB-Signalen und HSYNC/VSYNC; Progressive und Interlace unterscheiden sich ebenfalls durch die Position der Sync-Signale
• Da das SNES keinen separaten Video-Oszillator haben konnte, teilte es den 21,47727-MHz-Master-Clock herunter, erzeugte daraus einen 5,3693175-MHz-Dot-Clock und kam mit der Kombination aus 262 Zeilen und 341 Dots auf 60,098 Hz statt der NTSC-Standardfrequenz von 59,94 Hz
• Der Grundmodus besteht aus 224 sichtbaren Zeilen von 262 Zeilen und 38 Zeilen VBLANK sowie 256 sichtbaren Dots von 341 Dots und 85 Dots HBLANK, wodurch Zeit für die Sprite-Line-Buffer-Arbeit der PPU geschaffen wird
• Das PAL-SNES bot für eine 50-Hz-Umgebung mit 312,5 Zeilen einen anderen Oszillator und einen Overscan-Modus mit 240 Zeilen, doch die meisten Spiele waren auf 224 Zeilen ausgelegt, sodass schwarze Balken und eine 17 % langsamere Ausführung üblich waren

---

Wo CRT-Fernseher das Design begrenzten

• Das primäre Zielgerät für die Videoausgabe des SNES war ein Standard-CRT-Fernseher; damalige Fernseher empfingen analoge NTSC-Sendungen über Antenne oder externe Videosignale über einen AUX-Eingang
• Der Hilfseingang gewöhnlicher Fernseher bestand aus einer gelben Composite-Video-Buchse sowie weißen und roten Stereo-Audio-Buchsen
• Eine CRT kann man sich als 15-kHz-Gerät zum Zeichnen von Zeilen vorstellen, das etwa 15.000 Zeilen pro Sekunde zeichnen kann

Eine CRT arbeitet nicht mit Pixeln, sondern mit Scanlines und Signalen

• Im Inneren einer CRT befinden sich drei Elektronenkanonen; die Elektronen werden durch vertikale und horizontale Magnete nach oben und unten sowie nach links und rechts abgelenkt
• Elektronen selbst haben keine Farbe; eine Maske sorgt dafür, dass die Elektronen jeder Elektronenkanone auf den Streifen des Leuchtstoffs mit der richtigen Farbe treffen
• Eine CRT hat keine Pixel, und auch die Slots sind keine Pixel
  • Hochauflösende Fernseher haben kleinere Slots und können dasselbe Farbsignal horizontal genauer darstellen
• Eine CRT empfängt fünf Signale über vier Leitungen
  • Die Signale Red, Green und Blue sind jeweils direkt mit einer Elektronenkanone verbunden
  • Liegt auf den drei RGB-Leitungen kein Signal an, werden keine Elektronen abgefeuert, und es wird Schwarz angezeigt
  • Die weiße Leitung ist Composite Sync (CSYNC) und überträgt HSYNC und VSYNC zusammen
• Eine CRT erzeugt kein VSYNC selbst, sondern richtet die Position der Elektronenkanonen an den Sync-Signalen aus, die ein externes System sendet

Der Unterschied zwischen Progressive und Interlace

• Eine CRT zeichnet eine Zeile von links nach rechts und kehrt beim Empfang von HSYNC zur linken Bildschirmseite, X=0, zurück
• Beim Empfang von VSYNC kehrt sie zur oberen Bildschirmkante, Y=0, zurück
• Während sich die Elektronenkanone nach rechts bewegt, folgt sie einer nach unten geneigten Bahn; die nächste Zeile nach HSYNC wird unterhalb der vorherigen Zeile gezeichnet
• Wenn VSYNC zum selben Zeitpunkt wie das letzte HSYNC auftritt, entsteht ein Progressive Scan, bei dem das Feld an derselben Position gezeichnet wird
• Wenn VSYNC zwischen zwei HSYNCs auftritt, liegen die Zeilen des nächsten Felds zwischen denen des vorherigen Felds; das ist Interlace
  • Interlace verdoppelt die vertikale Auflösung, halbiert aber die Aktualisierungsrate jeder Zeile
• NTSC gibt zwei Felder mit etwa 30 Hz aus, daher hatten CRTs den Zeilenabstand für Interlacing; beim Zeichnen in Progressive sind schwarze Scanline-Abstände sichtbar

NTSC-Spezifikation und Grenzen eines einfachen Designs

• Das SNES-Design musste nahe an Werten liegen, die ein NTSC-Fernseher verarbeiten konnte
  • Seitenverhältnis: 4:3
  • Zeilen pro Feld: 262,5
  • Dots pro Zeile: 341,25
  • Feldfrequenz: 59,94 Hz
• Schwarzweiß-NTSC hatte ursprünglich 60 Hz, doch Farb-NTSC senkte die Frequenz um 0,1 %, um beim Hinzufügen von Farbe unter Wahrung der Abwärtskompatibilität Artefakte zu vermeiden
• Eine einfache Lösung könnte 262 progressive Zeilen, 350 Dots und 59,94 Hz wählen und damit einen Dot-Clock von 5.496.498 Hz erfordern
• Dieses Design passte jedoch nicht zum tatsächlichen SNES
  • Wegen Kostenvorgaben konnte es keinen dedizierten Oszillator nur für das Videosystem geben; die Subsysteme mussten den Master-Oszillator herunterteilen und nutzen
  • Da die Elektronenkanone auch während der Bildschirmrückkehr weiter feuern kann, sind Overscan und Blanking-Behandlung nötig

Blanking und Wahl der vertikalen Auflösung

• Wenn beim horizontalen oder vertikalen Zurücksetzen der Position der Elektronenkanone weiter Elektronen abgefeuert werden, entstehen sichtbare Artefakte
• Fernseher verwenden Overscan und zeigen ein Bild an, das etwas größer als der Bildschirm ist; das Ausmaß unterscheidet sich je nach Fernseher
• Nach VSYNC und HSYNC schwankt die Position der Elektronenkanone kurz, daher ist eine Zeit nötig, in der das Feuern der Elektronen gestoppt wird, bis wieder eine stabile gerade Linie erreicht ist
  • Der Zeitraum ohne Elektronenfeuer nach VSYNC ist VBLANK
  • Der Zeitraum ohne Elektronenfeuer nach HSYNC ist HBLANK
• Auch konkurrierende Systeme der Zeit nutzten Blanking
  • Capcom CPS-1: 262 Zeilen, 38 Zeilen VBLANK, 224 sichtbare Zeilen, 59,6294 fps
  • Sega Genesis: 262 Zeilen, 38 Zeilen VBLANK, 224 sichtbare Zeilen, 59,9227 fps
  • Neo-Geo AES: 264 Zeilen, 40 Zeilen VBLANK, 224 sichtbare Zeilen, 59,18 fps
• Das SNES teilt 262 Zeilen in 224 sichtbare Zeilen + 38 Blank-Zeilen auf
  • 224 ist durch 16 teilbar und passt gut zu einer Grafik-Pipeline auf Basis von 16x16-Tiles

Horizontale Auflösung und 60,098 Hz

• Das SNES teilt den 21,47727-MHz-Master-Clock durch 4 und verwendet einen 5,3693175-MHz-Dot-Clock
• Framerate, Zeilenzahl, Dots pro Zeile und Dot-Clock hängen zusammen
• Setzt man eine Ziel-Framerate von 59,94 Hz und 262 Zeilen ein, ergeben sich etwa 342 Dots pro Zeile; wegen Carrier-Artefakten der Composite-Ausgabe mussten die Nintendo-Ingenieure jedoch 341 Dots verwenden
• Mit dieser Kombination beträgt die Framerate des SNES 5,3693175 MHz / (341 * 262) = 60,098 Hz
• 60,098 Hz unterscheidet sich von den 59,94 Hz von NTSC, funktioniert aber innerhalb der Toleranzen von CRTs

Warum 256x224 zum Standardbild wurde

• Nicht alle 341 Dots einer Zeile können als sichtbarer Bereich verwendet werden; es braucht HBLANK, um Schwankungen, Artefakte und TV-Overscan zu verbergen
• Bei 224 Zeilen liegt eine sichtbare Breite nahe 4:3 bei 224 * 4/3 = 298 Dots
• Die Tilemap-Pipeline verwendet 16x16-Tiles, daher kommen Werte wie 304, 288, 272, 256 oder 240 infrage
  • 304 Dots liegen nahe an einem Wert mit fast keiner Bildverzerrung
• Außerdem gab es die Einschränkung, dass die PPU während HBLANK den Sprite-Line-Buffer füllen musste
  • Bei 304 sichtbaren Dots blieben 37 Dots HBLANK, also nur etwa 7 µs
  • Für das Holen der Daten von bis zu 128 Sprites war vermutlich mehr Zeit nötig
• Die endgültige Wahl waren 256 sichtbare Dots + 85 HBLANK-Dots
  • Die PPU erhält während HBLANK etwa 16 µs
  • Das Seitenverhältnis des sichtbaren Bereichs ist nicht 4:3, sondern 8:7, wodurch bei der Anzeige auf einer CRT eine leichte Verzerrung entsteht

Kompromisse bei den High-Resolution-Modi

• Die grundlegende SNES-Video-Konfiguration ist eine Overscan-Auflösung von 341x262, eine sichtbare Auflösung von 256x224 und eine Framerate von 60,098 Hz
• 99 % der Spiele nutzten diese Konfiguration, doch das SNES hat auch High-Resolution-Modi, die die vertikale oder horizontale Auflösung verdoppeln
• 448 vertikale Zeilen lassen sich erzeugen, indem VSYNC eine halbe Zeile nach dem letzten HSYNC ausgegeben wird und so ein Interlace-Frame entsteht
  • In diesem Fall wird eine Zeile mit 60,098/2 = 30,049 Hz aktualisiert
  • Es entsteht Flimmern und es sieht nicht gut aus, aber die vertikale Auflösung steigt
• Die Verdopplung der horizontalen Auflösung ist schwieriger, weil der nötige Dot-Clock fehlt
  • Das SNES verschiebt das zweite Feld horizontal leicht, sodass die Punkte zwischen den Punkten des vorherigen Felds liegen
  • Das führt zu halber Framerate und starkem Farbbluten
• fullsnes.txt sammelt Beispiele für die High-Resolution-Nutzung in verschiedenen Titeln
  • Nintendo-Logo in Donkey Kong Country 1: 512x224, BgMode5
  • Einstellungsbildschirm von Seiken Densetsu 2: 512x224, BgMode5
  • RPM Racing: Intro und In-Game 512x448, BgMode5+Interlace
  • Beim Ranma-1/2-Fall ist es tatsächlich 256x224, aber Interlace wurde versehentlich aktiviert und verursacht unnötiges Flimmern

PAL, SECAM und das Problem des europäischen SNES

• Europäische Fernseher verwenden nicht NTSC, sondern PAL, und Frankreich nutzte auch SECAM
• Die PAL-Umgebung erwartet exakt 50 Hz und 312,5 Zeilen pro Feld
• Das PAL-SNES enthält statt des 21,4772700-MHz-Oszillators von NTSC einen 17,7344750-MHz-Oszillator
  • Der S-CLK-Chip führt eine 6/5-Verarbeitung durch und teilt erneut durch 4, wodurch ein 5,32034250-MHz-Dot-Clock entsteht
• Wenn nur 224-Zeilen-Grafik verwendet wird, entstehen ober- und unterhalb des sichtbaren Bereichs große schwarze Balken
• Um das zu reduzieren, gab es einen Overscan-Modus, der die sichtbaren Zeilen auf 240 erhöht
  • Die zusätzlichen 16 Zeilen entsprechen der Höhe eines Tiles
  • In der Praxis wurden die meisten Titel für 224 Zeilen entwickelt und nutzten diesen Modus kaum
  • Insgesamt verwendeten ihn nur 12 Titel
• Super Mario World reagierte darauf, indem es den vertikalen Sichtbereich in PAL vergrößerte
• Da NTSC und PAL beide das Seitenverhältnis 4:3 verwenden, ist das PAL-Bild vertikal etwas stärker komprimiert als NTSC
• Viele Spielcodes berücksichtigten nicht, dass VSYNC nicht mit 60,098 Hz, sondern mit 50,00697891 Hz auftritt; dadurch liefen Spiele 17 % langsamer als beabsichtigt

Ausgangssignal und AV-Anschluss

• Die oben betrachteten RGB- und Sync-Signale sind reine Signale, die eine CRT direkt ansteuern, doch in die meisten tatsächlichen Fernseher konnte man Signale nicht direkt in die CRT einspeisen
• Viele Fernseher hatten auf der Rückseite nur den gelben Composite-Eingang, während einige höherwertige Modelle einen S-Video-Eingang boten
• Das SNES wandelt die CRT-Signale sowohl in Composite als auch in S-Video um
• Der AV-Anschluss verwirft die Signale nicht, sondern stellt mehrere Ausgabearten bereit
  • Red, Green, Blue
  • C-Sync
  • S-Video auf Basis von Luminance und Chrominance
  • Composite Video
  • +5 V DC
  • Ground
  • Left Audio, Right Audio
• Europäische Fernseher, insbesondere französische, hatten oft einen SCART-Anschluss, und diese Methode ermöglichte die Herstellung von Kabeln, die Signale direkter in die CRT einspeisten
• Dadurch konnten europäische Nutzer Spiele mit 17 % geringerer Geschwindigkeit und schwarzen Balken in hoher Bildtreue genießen

[GN⁺]

Hacker-News-Kommentare

• 224 ist sehr wahrscheinlich keine zufällig gewählte Zahl. Sie ist durch 16 teilbar (224/16=14) und passt damit gut zu den Tilemaps in der Grafik-Rendering-Pipeline.
  Als ich als Kind beim Versuch, Spieleprogrammierung zu lernen, mit allem Möglichen herumexperimentierte, verstand ich das erst viel später – und dann ergab es für mich sehr viel Sinn. Bei CGA/EGA/VGA waren 320x200-Modi üblich, NES und SNES hatten 256x224, was im Grunde eher an den Einschränkungen von Fernsehern lag.
  Arcade-Pac-Man dagegen hatte 288x224, deshalb sahen Pac-Man-Klone auf dem PC nie „richtig“ aus, und selbst die von Namco erstellte NES-Version von Pac-Man passte nicht. Die Map-Tiles wurden kleiner, wodurch die Figuren riesig wirkten; oder es wurde wie bei der Game-Boy-/Tengen-Version eine scrollende Welt; oder es gab Kompromisse wie Verzerrungen oder nicht originale Maps. Wenn man zu Hause ein „Arcade“-Spiel spielen wollte, fühlte sich das daher seltsam und frustrierend an.
  Nachdem ich die Maschinenarchitektur und die Funktionsweise von Sprites gelernt hatte, kam die große Erkenntnis: Es gab letztlich keine andere Wahl. Wenn man dann noch berücksichtigt, dass die Pixel bei dieser PC-Auflösung nicht quadratisch waren, wird es noch komplizierter.
  Seitdem prüfe ich bei jeder Pac-Man-Portierung oder jedem Klon sofort die Weltgröße, Tile-Größe und Sprite-Größe.

  • Das NES hat tatsächlich 256x240 und nutzte alle 240 Zeilen eines NTSC-Felds, aber viele Fernseher schnitten oben und unten etwas ab, sodass der auf den meisten Fernsehern sichere „nutzbare“ Bereich 256x224 betrug.
    Dieses Overscan-Verhalten unterschied sich allerdings von Fernseher zu Fernseher, und moderne Fernseher oder Emulatoren zeigen normalerweise alle 240 Zeilen.
    Die vertikale Auflösung des SNES konnte, wie im Artikel beschrieben, auf 224 oder 240 Zeilen eingestellt werden. Die meisten Spiele verwendeten 224 Zeilen, weil dadurch die vertikale Austastzeit länger wurde und somit mehr Zeit blieb, Grafiken an die PPU zu übertragen.
  • Ich hatte schon früher das Gefühl, dass viele Portierungen im Vergleich zur Arcade-Version gestreckt aussehen, wusste aber überhaupt nicht, warum. Das galt auch für mehrere Versionen wie die alten Fassungen für Atari-8-Bit-Computer oder Ms. Pac-Man und Super Pac-Man.

• Auch Rodrigo Copettis Artikel zur SNES-Architektur ist einen Blick wert: https://www.copetti.org/writings/consoles/super-nintendo/

• Dass 59,94 Hz eine seltsame Zahl ist, stimmt, aber meines Wissens gibt es kein 30-Hz-Stromnetz. Nordamerika und einige andere Regionen, für die NTSC entwickelt wurde, nutzen ein 60-Hz-Stromnetz.
  https://en.wikipedia.org/wiki/Mains_electricity_by_country

  • Beim ursprünglichen Schwarzweißfernsehen waren es 60 Halbbilder pro Sekunde, also 30 interlaced Vollbilder pro Sekunde.
    Die höchste Frequenz, die in einem Schwarzweißfernseher erzeugt wurde, war die horizontale Abtastfrequenz, und sie war ein Vielfaches der Bildrate. Mit der Einführung des NTSC-Farbsignals mit einem 3,579545-MHz-Träger wurde die höchste Frequenz im Fernseher deutlich höher. Um die Hardware einfach zu halten, wurden die niedrigeren Frequenzen weiterhin auf Teiler dieser höchsten Frequenz, also des Farbträgers, abgestimmt. Dadurch ergab sich eine Bildrate von 59,94 Halbbildern pro Sekunde.

• Der Punkt, dass Spiele in PAL-Regionen nicht auf 50.00697891 Hz VSYNC angepasst wurden und deshalb 17 % langsamer liefen als bei 60.098 Hz, trifft bei mir sehr einen Nerv.
  Das ist nicht nur eine Super-Nintendo-Geschichte, aber es erinnert mich daran, als ich Sonic the Hedgehog auf dem Mega Drive (Genesis) zum ersten Mal gesehen bzw. gespielt habe. Es fühlte sich träger und langsamer an als die Master-System-Version und war daher nicht besonders beeindruckend; erst als YouTube aufkam, wurde mir klar, wie enorm der Geschwindigkeitsunterschied zwischen NTSC und PAL war. Nicht nur die Spielgeschwindigkeit, auch die Musik klang unter PAL grauenhaft.
  Schon in der 16-Bit-Ära wusste ich von PAL und der Notwendigkeit von „Black Boxes“, aber mir war nicht klar, dass der Unterschied so groß war. Die Konsolenmagazine damals behaupteten, glaube ich, meist, die Unterschiede seien in den meisten Spielen gering; eine Ausnahme war die SNES-Version von DooM, bei der der NTSC-Bildschirm größer war.
  Als Kind war ich gut in der NES-Version von Punch-Out und konnte Mr. Dream oder Mike Tyson in der ersten Runde besiegen, aber rückblickend habe ich wohl die PAL-Version gespielt. Wäre ich bei einem US-Turnier angetreten, hätte man mich in der ersten Runde zerlegt, und ich wäre überzeugt gewesen, dass mich jemand in eine Falle gelockt hat.

  • Super Metroid ist ein Spiel, das die Entwickler angepasst haben, damit es auch auf PAL-Konsolen mit der richtigen Geschwindigkeit spielbar ist. Aber selbst solche Anpassungen führen, besonders bei Speedruns, wegen feiner Unterschiede bei physikalischen Konstanten und Animation-Timing zu echten Unterschieden im Gameplay.
    Bei niedrigerer Framerate bewegen sich Samus und Projektile zum Beispiel pro Frame mehr Pixel weit, wodurch es leichter wird, durch Objekte hindurchzukommen; deshalb ist dieser Gate-Glitch nur auf PAL möglich: https://www.youtube.com/watch?v=RvyIwtO_qgM
    Samus’ physikalische Konstanten und Animation-Timings wurden an die neue Framerate angepasst, Gegner, Cutscenes und andere Umgebungselemente dagegen nicht. Daher bewegt sich Samus in PAL mit derselben Geschwindigkeit wie in NTSC, während sich der Rest der Welt langsamer bewegt. Dadurch kann man die Bombs aufheben und den Raum verlassen, kurz bevor sich die Tür verriegelt, und so den Miniboss überspringen: https://www.youtube.com/watch?v=R3t8TIIj7IM
    Derselbe Skip in der NTSC-Version erfordert komplexe Vorbereitung und dutzende framegenaue Eingaben in Folge; bislang hat ihn nur eine einzige Person geschafft: https://www.youtube.com/watch?v=jcKUMk5g8Wk
    Es gibt auch einen Vergleich der kürzesten Tool-assisted Speedruns von NTSC (links) und PAL (rechts): https://www.youtube.com/watch?v=KD_-thqcB5s Beide Runs nutzen fast bis zum Ende dieselbe Route, und die NTSC-Version ist in fast jedem Raum schneller, aber die Vorbereitung für Arbitrary Code Execution ist komplett anders, sodass PAL am Ende zuerst fertig ist. Der NTSC-Run muss eine sehr langsame Pause/Unpause-Sequenz ausführen, um durch eine Tür zu gehen, ohne sie auszulösen, außerhalb der Grenzen zu landen und Speicherkorruption zu verursachen. Die PAL-Version dagegen kann über eine Race Condition im Animationssystem des Spiels vollständig innerhalb des Bildschirms Arbitrary Code Execution erreichen. Es ist ein Rennen zwischen dem Knockback-Timer der Stacheln und Samus’ Landeanimation; nur Samus’ Timing wurde für PAL angepasst, die Stacheln aber nicht, wodurch in PAL genau in diesem Kontext ein ausnutzbares Timing entsteht.
  • In Australien wusste man dank Magazinen wie „Hyper“ von den Timing-Unterschieden, aber man konnte nichts dagegen tun. Vielleicht wäre es besser gewesen, unwissend und glücklich zu bleiben.
    Mit dem Dreamcast gab es zum ersten Mal Spiele, bei denen man zwischen 50 Hz und 60 Hz umschalten konnte, sofern der Fernseher es unterstützte. Außerdem konnte man bei Spielen, die diesen Unterschied nicht korrekt berücksichtigten, auf 50 Hz zurückschalten und sie damit einfacher machen; ich erinnere mich, dass Crazy Taxi bei 50 Hz deutlich leichter war.
  • Vielleicht erklärt das, warum sich das Timing immer falsch anfühlt, wenn ich SNES-Spiele im Emulator spiele. Ich bin als Kind mit der PAL-Version aufgewachsen und dachte bisher, es liege nur an der Verzögerung moderner Fernseher.
  • Ich bin in den USA aufgewachsen, und als ich später zum ersten Mal vom Geschwindigkeitsunterschied zwischen PAL und den US-Versionen hörte, war ich schockiert.
    Es fühlt sich seltsam an, dass so unterschiedliche Spiele unverändert verkauft wurden, aber ich verstehe völlig, warum man diese Entscheidung getroffen hat. Als Kind ging ich selbstverständlich davon aus, dass Mario überall Mario ist und Sonic überall Sonic.
    Ich frage mich, ob diese Unterschiede mit der 3D-Konsolenära aufgehört haben. Ab dann waren Rendering und Spiellogik schließlich meist nicht mehr vollständig miteinander gekoppelt.

• Im Original scheint ein Tippfehler zu sein. Dort wird das Seitenverhältnis mit 8:6 angegeben, aber das ist dasselbe wie 4:3; rechnerisch müsste es 8:7 sein.

  • Stimmt. Das interne Seitenverhältnis ist 8:7, und Emulatoren wie Snes9x verwenden das auch als Standard. Nach meinem Verständnis werden auf CRTs eigentlich quadratische Pixel durch die Funktionsweise des Geräts zu Rechtecken gestaucht, sodass das Ergebnis ungefähr als 4:3 angezeigt wird.

• Es scheint zu fehlen, dass die Ausgabeauflösung von 256x224, also 8:7, auf ungefähr 4:3 gestreckt wird, genauer gesagt auf ein Bild mit 64:49.
  Die Dot-Rate des SNES liegt bei etwa 5,37 MHz und ist damit langsamer als die vom ATSC-Standard definierte Rate für quadratische Pixel von etwa 6,13 MHz. Sie ist genau um den Faktor 8/7 langsamer, daher werden die Pixel horizontal um 8/7 gestreckt, und die 8:7-Auflösung wird zu (8/7)(8/7)=64/49 gestreckt, was nahe an 64:48=4:3 liegt.
  Die Rechnung „für ein Seitenverhältnis nahe 4:3 braucht man 224(4/3)=298 sichtbare Dots“ bekommt, wenn man den obigen Faktor berücksichtigt, den Koeffizienten (4/3)/(8/7)=7/6. Dann braucht man 224*(7/6)=261,33... sichtbare Dots, was den tatsächlich gewählten 256 viel näher kommt.

• Ich habe eine Switchbox an den RF-Ausgang angeschlossen und damit abwechselnd SNES und TV-Antenne ausgewählt.

  • Die einzige Möglichkeit, die Bildqualität noch weiter zu verschlechtern und zusätzlich Rauschen einzubringen, war, zwischen RF-Switchbox und Fernseher einen zweiadrigen UHF-Schraubklemmen-Adapter zu stecken. Genau so habe ich es natürlich bei meiner Pong-Klon-Konsole aus den 1970ern gemacht, die ich als Kind hatte. Ein echter Atari war finanziell nicht drin.
    Später, nachdem ich Videoingenieur geworden war, konnte ich darüber lachen; aber damals war ich als Kind zum Glück ahnungslos, wie grauenhaft diese Bildqualität wirklich war.

• Das 8:7-Seitenverhältnis der Artwork-Grafiken ist auch bei Portierungen von SFC/SNES-Titeln auf andere Plattformen zu sehen, etwa ROCKMANX3 / Mega Man X3.
  Die PSX-/Saturn-/PC-Versionen haben die Originalgrafiken nicht gestreckt, sondern beibehalten und stattdessen je nach Stage vertikale Ränder hinzugefügt, um 8:7 auf 4:3 zu bringen. Wenn man an die Originalversion gewöhnt ist, stört das beim Spielen ziemlich; auf Screenshots der Saturn-Version sieht man, dass alles ein klein wenig zu schmal wirkt: https://segaretro.org/Mega_Man_X3

• Ich frage mich, wie lange Fabien braucht, um solche Artikel zu schreiben. Es gibt wirklich viele Details, und sie sind sauber aufbereitet.

  • Ungefähr einen ganzen Sonntag, von 9 Uhr morgens bis 21 Uhr abends.

• Ich frage mich, wie viel von den SNES-Auflösungen in der Konsolenhardware fest vorgegeben ist und wie viel vom Modul angesteuert werden kann.
  Wenn ein Modul zum Beispiel einen eigenen Co-Prozessor hätte, sodass es keine Sprites laden müsste, und außerdem einen Onboard-Takt, könnte es dann theoretisch mehr als 256 horizontale Pixel pro Zeile ausgeben?

  • Meiner Ansicht nach ist das alles in der PPU fest vorgegeben.
    Mit einem Co-Prozessor könnte man zwar selbst ein Frame rendern und es an die Speicherstelle legen, von der die Tiles für die nächste Zeile gelesen werden. SuperFX hat das meines Wissens ungefähr so gemacht.
    Aber am Ende ist es die PPU, die tatsächlich die Pixel zeichnet und Dinge wie die Anzahl der Farben verarbeitet; damit ist man letztlich an die Beschränkungen der PPU gebunden.