nice, ich hatte mal vor der Aktion gehört, schon jemand eine Idee was die Testports machen ?

Bei der PPU2 sieht es für mich so aus, als ob Pin 93 ("TST15") ein Eingang wäre, dessen Signal irgendwo in dem Logikblock Mitte-Rechts verschwindet und TST0 bis 14 bidirektionale Pad-Treiber haben. Es sieht aber auf den ersten Blick nicht so aus, als ob TST0 bis 14 alle in die gleichen Logikblöcke führen würden.

Ich hab mal die Pads durchnummeriert


Ich glaub alle Testpins laufen in den Bereich unter T14 T15, aber ka was das ist

Laienfrage: Bringen diese Decaps einem Kevtris noch zusätzliche Infos, wo er doch mit dem FPGA SNES schon durch ist? Wäre der SuperFX nicht ein interessanteres Angriffziel gewesen? Oder hat das eine mit dem anderen nix zu tun und ein Decap brächte beim SuperFX nichts?

Hab nochmal bisschen was an den Testports markiert

Die 4 oberen T15-T12, (liegen extern auf GND) haben eine Verbindung in den blau markieren Bereich, je ein Kontakt geht außen rechts lang und dann irgendwo in die Logik. Wie Unseen schon geschrieben hat, hat der Port T15 nur eine Verbindung.

Alle anderen Ports T11 bis T0 sind nur mit dem blauen Bereich verbunden. Die Ports floaten.

Ich kann auch das Bild Fullsize hochladen wenn jemand will ist halt 450MB groß (das Gekritzel ist nicht drauf)

Einige Zeit später: Ja, ein wenig.

ikari_01 hat versucht, die fest auf Masse liegenden TST-Pins in seinem SNES mal von der Platine zu heben und Signale einzuspeisen. Dabei stellte sich heraus, dass TST12 bis TST15 einstellen, welche Signale auf den Testpins ausgegeben werden. IIRC konnte man zB mit einer bestimmten Konfiguration Signale sehen, die ziemlich deutliche Korrelationen mit VRAM-Zugriffen haben.

Für mich war aber ein Modus besonders interessant: Wenn TST15 auf High liegt, wird auf TST0 bis TST14 die Farbe des aktuellen Pixels als RGB555-Wert ausgegeben. Das schreit natürlich danach, die Signale mal in einen FPGA einzuspeisen und damit herumzuspielen - zB durch Mitschreiben eines kompletten Frames im FPGA-BlockRAM, welches danach per UART an den Rechner übertragen wird für pixelperfekte Screenshots. Ich habe mal als Proof-of-Concept ein paar davon angefertigt und hier angehangen.

Hinweis zu den Screenshots: Für schönere Darstellung im Forum wurden die Screenshots vertikal per Nearest Neighbour-Sampling vergrössert, horizontal passiert das schon implizit weil meine Logik einfach 512 Pixel pro Zeile aufzeichnet. Es wurde keine Aspect-Ratio-Korrektur vorgenommen, SNES-Pixel sind eigentlich rechteckig und nicht quadratisch wie in den Screenshots. Das Bild ist ein wenig nach rechts verschoben, da ich als Referenz das HBlank-Signal verwendet habe ohne zu bedenken, dass sich das auf das Lesen der Videodaten bezieht und nicht auf die Ausgabe des Pixelshifters. Liesse sich leicht korrigieren, aber die Screenshots nochmal anfertigen war mir zu viel Arbeit.

Super Mario World:


Street Fighter 2 Turbo:


Super Metroid:


Zelda Link to the Past:


Super Gameboy:


Mario Kart:


Und bevor jetzt jemand hibbelig wird und Rufe nach einem "HDMI-SNES-Mod" oder so laut werden muss ich noch einen wichtigen Hinweis geben: Bei der Entwicklung von GCVideo brauchte ich damals nur einen Tag brauchte um per FPGA ein Farbbild aus der Konsole zu erhalten, aber danach verging noch ein gutes halbes Jahr Entwicklungszeit, bis das ganze weit genug gereift war um wenigstens GCVideo-Lite (nur mit Analogausgang) zu veröffentlichen. GCVideo-DVI brauchte dann nochmal einige weitere Monate - und der Gamecube hat ein Videotiming, welches sich tatsächlich an den aktuell immer noch üblichen Videostandards orientiert. Das SNES ist da tatsächlich komplizierter, deswegen sollte man vor 2019 (möglicherweise Anfang April?) keinesfalls mit einer veröffentlichungsreichen hardware rechnen und vielleicht dauert es noch viel länger.

Und nein, ich suche keine Vorab-Betatester - falls daraus mal was fertiges wird, landet es auf Github und jeder darf sich als Betatester fühlen.

Freu mich schon auf das nächste Jahr

so Infos am ersten April sind ja immer eine Sache für sich

Schön das endlich bekannt ist wie die Testpins funktionieren
Ich hab die Ports vor einigen Jahren immer floaten lassen aber konnte nur quatsch messen.

Schade, kaum Reaktionen... Zu offensichtlich? Hätte es plausubler gewirkt wenn ich geschrieben hätte, dass die Testpins in bestimmten Situationen als digitaler Videoeingang statt Ausgang funktionieren?

Versuch war gut und haben sicherlich auch einige geglaubt.

Aber der aufmerksame Leser hat einen Widerspruch entdeckt:

vs.
Da noch n bisschen Fachchinesisch mit rein, dass TST12 bis 15 mit so ner Art Huffman-Code angesteuert wird mit ner kleinen Tabelle dazu und es wäre ein wenig perfekter gewesen Irgendwelche Oszibilder (von irgendwoher genommen) mit Freiinterpretation inkl. irgendwelchen Markierungen wären dazu auch cool gewesen.

Och, das passt aber ziemlich gut dazu, dass TST15 der einzige Nur-Eingang-Pin ist, aber Nintendo trotzdem TST12 bis TST15 auf Masse gelegt hat.


Hmm, sowas? "Gelb ist Pin 4 der PPU2 (im Schaltplan "TOUMEI", nirgendwo angeschlossen), Cyan ist Composite Video. Das Signal scheint bei schwarzen Pixeln auf Low zu gehen. In transparenten Bereichen im Mode7 wird es zu einem Eingang, mit dem umgeschaltet wird ob die Testpins als Videoeingang arbeiten oder die Pixel aus einer in bisherigen Beobachtungen dauer-schwarzen Quelle kommen."

genau so

Liegt wohl eher daran, dass die meisten hier Posts mit zu viel technischem Blablabla einfach überlesen.

...oder einfach nicht verstehen. So wie ich zum Beispiel!

Ich hab hier reingeschaut... Aha gesagt... und weitergeklickt!

Die TLDR-Fassung ist, dass es im 3-Chip-SNES einen (ungenutzten) Port mit digitalen Videodaten gibt. Dort kann man den Bildinhalt der Konsole gestochen scharf abgreifen statt die etwas matschigen Analogausgänge der PPU2 zu verwenden. Allerdings gibt es einige noch nicht gelöste Probleme im Mode 7.

flash war zu schnell...

Liebe Kinder, das war kein Aprilscherz. Ihr dürft jetzt alle ausflippen.

Ein inverse April-Scherz sozu sagen. Mich hatte er gehabt

In der Tat sehr nett

Da hänge ich also so einen DAC+RGB Encoder aus einer PSX dran, und raus kommt bestes RGB und sogar Composite.
Könnte man so bauen, oder?

Ja, sowas war die ursprüngliche Hoffnung. In der Praxis gibts jedoch ein paar Haken:

• Die 4 Helligkeits-Bits in Register $2100 werden über die Referenzspannung des internen DACs realisiert, auf dem Digital-Port hat das Register daher keine Auswirkung. Dadurch fehlen in vielen Spielen z.B. Fade-Effekte. Das sollte sich aber via FPGA leicht nachbilden lassen, wenn man nur genug Signale vom SNES ranführt.
  
• Irgendwas funktioniert in der PPU2 nicht ganz zuverlässig, wenn der Testport als Videoausgang konfiguriert ist. Das führt z.B. bei Pilotwings im Titelbild oft (aber nicht immer) zu einer falschen Palette und bei Chrono Trigger fehlt das schwingende Pendel im Intro. Das Problem lässt sich wohl dadurch umgehen, dass man TST15 im Blanking-Bereich wieder auf Low setzt, aber ich habe noch nicht getestet ob es timingmässig hinkommt um alle sichtbaren Pixel zu erwischen.
  
  
• In einer bestimmten Konfiguration im Mode 7 (Register $211a Bits 7+6 auf 01b) stellt das SNES ausserhalb der aktiven Mode7-Bitplane normalerweise nur Sprites und die Hintergrundfarbe dar, wenn auch inklusive Colormath, Mosaikeffekten und evtl. mehr. Der Modus wird z.B. in den Titelbildern von Pilotwings und Super Bases Loaded 2 verwendet. Wenn der externe Videoport aktiv ist, zeigt die PPU2 an der Stelle stattdessen entweder schwarz oder das an den Testpins von aussen eingespeiste(!) Signal an. Bisher habe ich noch keine Möglichkeit gefunden, in diesen Bereichen - die sich anhand des Signals auf den OVER1/OVER2-Pins leicht identifizieren lassen - die PPU2 trotzdem zur Ausgabe der "normalen" Pixelfarbe zu überreden.
  

Die bisher am erfolgversprechendsten aussehende Lösung für das letzte Problem ist, die PPU2 teilweise nachzubilden - für das Helligkeitsregister muss man eh den B-Bus anzapfen und dabei kann man auch gleich die Palettenregister mitschneiden, um die Farben für Sprites und Hintergrund zu erhalten. Die Sprites werden wohl hauptsächlich von der PPU1 behandelt, die PPU2 bekommt einfach Palettennummer, Farbindex und Priorität des aktuellen Spritepixels auf Pins 41 bis 49 geliefert. Colormath und Mosaik nachbilden sollte auch machbar, wenn auch evtl. etwas lästig sein.

Was ich aber jetzt schon sagen kann ist, dass der Einbau eines Digi-Video-Ausgangs in ein SNES eine ziemliche Nervarbeit werden wird, die PPUs haben 0.65mm Pinabstand und es werden grob geschätzt 40-50 Signale benötigt wenn die PPU2 tatsächlich teilweise nachgebildet werden muss.

Aber um auch mal was positives zu erwähnen: Einer der ersten Tests mit dem Port war ein einfacher 3x1-Bit-DAC aus drei Widerständen an den höchstwertigsten Farbbits, angeschlossen an den RGB-Eingang meines PVM-9L3. Super Mario World sieht auf 8 Farben reduziert zwar ziemlich seltsam aus, aber die erzielte Bildschärfe war extrem beeindruckend.

Hochgradig technische Tips, falls jemand an den PPUs forschen will:

• Man kann auch ohne Oszilloskop schnell herausfinden, wie ein Signal der Konsole sich zum Bildaufbau verhält, indem man das Luma- oder Composite-Signal der Konsole an den Y-Anschluss (grün) eines Component-Video-Eingangs anschliesst und das zu untersuchende Signal über einen 330-Ohm-Widerstand an den Pb- oder Pr-Anschluss (blau/rot) des gleichen Component-Eingangs. Je nach dem ob das fragliche Signal im Blankingbereich high oder low ist (weil da der Referenzpegel gemessen wird) ändert sich die Farbe im Bild je nach Pegel zu grün/rot bzw. gelb/blau. Beispiel mit PPU 1 Pin 94 (/OVER) im Chrono Trigger-Intro:
  
  
• Für Experimente mit dem Testport empfiehlt es sich, TST12 bis TST15 von der Platine abzuheben und mit Pulldown-Widerständen (10 kOhm gegen Masse, einer pro Pin) zu versehen. Dadurch kann man leicht mit dem "Originalzustand" vergleichen, indem man einfach keine alternativen Signale in diese Pins einspeist. Im Digital-Ausgangs-Modus wird es aber trotzdem noch zu flackernden Streifen an den Rändern von Mode7-Bereichen mit Transparenz kommen, weil die anderen Testpins dann immer noch floaten - aber das kann man natürlich auch positiv sehen weil dann deutlicher ist, was die PPU2 gerade mit den Pins anstellt.
  
• CSync scheint eine erste brauchbare Näherung für das Signal zu sein, das man in TST15 einspeisen will um zB die Fehlfarben in Pilotwings und das verschwundene Pendel in Chrono Trigger zu fixen.
  

Ich hab das technische Blabla zwar auch nur (bestenfalls) bruchstückhaft verstanden - aber zumindest konnte ich dem Beitrag entnehmen, dass scheinbar über ein paar Testpins vom SNES ein digitales Bildsignal entnehmbar ist. Dann sah ich das Posting-Datum und verlor schlagartig das Interesse ...

Ist auf jeden Fall schon mal sehr cool, das die Testpins tatsächlich den erwarteten Digitalausgang bereitstellen.

Die Probleme mit den Spezialmodi und dem Abdunkeln klingen leider doch stark nach externem FPGA.
Damit würde es dann ein dickes Projekt mit extra Platinen und langen Teilelisten.

Vielleicht findet sich ja doch noch ein Testmodus, der das Verhalten in Spezialmodi erhält.
Für das Abdunkeln kann man vielleicht analog was machen

Sorry, habe es für einen Aprilscherz gehalten
Kommt nicht wieder vor.

Wenn Test 15 high ist und 12 bis 14 floaten, hat man dann noch weiterhin ein analoges Signal bei dem auch Mode7 funktioniert oder macht die analoge Ausgabe dann auch Probleme ?

hmm vielleicht irgendwas Timingmäßiges, zb digital out nicht während des Blanking

Ich weiß nicht ob es interessant ist, aber TOUMEI ist auch ein I/O

Ich kann inzwischen die Verwendung alter 80-Pin-IDE-Kabel empfehlen. Deren Adernabstand ist zwar eigentlich etwas zu klein (0,635mm statt 0,65mm), aber wenn man sich auf Gruppen von maximal 8 Pins beschränkt ist das kein grosses Problem:



Das sowieso nicht, sonst scheint die PPU2 irgendwelche Registerzugriffe zu verschlucken - möglicherweise die Palette?

Ich weiß nicht ob es interessant ist, aber TOUMEI ist auch ein I/O

Ja, und der wird genau in den problematischen Bereichen interessant: Dann schaltet TOUMEI um, ob digitales Video von den Testpins eingelesen(!) wird oder das Bild von einer anderen Quelle kommt. Leider scheint diese andere Quelle auch nur schwarze Pixel zu produzieren.

Für mich sieht das alles so aus, als ob beim Dranbasteln von Mode 7 (*) vorgesehen worden wäre, ein Videooverlay aus externen Quellen über das Bild zu legen. Möglicherweise hat das ganze dann nicht so funktioniert wie eigentlich geplant und so wurde es stillgelegt oder auf die Testpins umgebogen? Es gibt ja auch noch das EXTBG(?)-Bit, bei dem Daten eigentlich über einen anderen Port in die PPU fliessen würden, der dann aber auf der Platine parallel zu einem der Videodatenbusse geschaltet wurde.

(*) Mode 7 ist ja eh schon ungewöhnlich, weil der Bildschirmspeicher dort deutlich anders organisiert ist als in den anderen Modi