SNESCIC-PIC will nicht mit SA-1-Modulen :-(

[Ramsis]

Bevor ich ins Detail gehe: Ich habe Umbauten wie diesen schon x-mal gemacht. Immer ließen sich eventuelle Probleme auf mehr oder weniger simple Fehler zurückführen.

An diesem Projekt allerdings beiße ich mir schon seit Monaten (immer mal wieder) die Zähne aus. Ich poste das mal hier, da vielleicht jemand von euch eine Idee hat, was die Ursache des Problems sein könnte – auch wenn ich mir wenig Hoffnung mache, ehrlich gesagt ...

Aaalso: Ich habe ein SNSP-CPU-02-Board zu Development-Zwecken mit einem mechanischen 50/60-Hz-Schalter versehen, der einwandfrei funktioniert. Dann habe ich den CIC entfernt und gegen einen SNESCIC-PIC getauscht (im Prinzip der Vorläufer des SuperCIC ohne den ganzen 50/60-Hz-Schnickschnack).

Resultat:

• Konsole bootet mit normalen Modulen jeder Herkunft.
• Konsole bootet mit S-DD1-Modulen (Star Ocean, Street Fighter Alpha 2) jeder Herkunft.
• Konsole bootet NICHT mit SA-1-Modulen (schwarzer Bildschirm). Genauer gesagt, mit dem "strengeren" SA-1, der z. B. in Kirby's Dreamland 3 oder manchen Super Mario RPGs verbaut ist, hat noch kein einziger der bislang ~8749204 Versuche ( ) geklappt. PGA European Tour (PAL) mit "weniger strengem" SA-1 hat dagegen tatsächlich ein- oder zweimal gebootet, was man aber wohl vernachlässigen kann.

Bilder vom Umbau (Achtung, Hi-Res):

versteckter Inhalt:

Bisherige Debugging-Maßnahmen:

• 3 verschiedene 12F629-Chips getestet
• 12F629-Chips in 1CHIP-Konsole mit demselben Umbau erfolgreich getestet
• Sämtliche Kabelverbindungen durchgemessen und auf Kurzschlüsse überprüft
• Verbindungen zum Cartridge-Slot überprüft
• Cartridge-Slot sorgfältig gereinigt (war gar nicht nötig )
• Pulldown-Widerstand (10 kΩ) durchgemessen
• Im Betrieb Spannung am PIC gemessen (~5 V)
• Im Betrieb Frequenzen an Quarz und Clock-Divider-Ausgängen gemessen
• Chip-Sockel und Kabel getauscht (insges. drei Mal, für abgerissene Pads teilweise alternative Lötpunkte verwendet)
• 17,7-MHz-Quarz (X1) gegen einen anderen (vom selben Board-Typ) getauscht
• Clock-Divider-Chip (S-CLK) gegen einen anderen (vom selben Board-Typ) getauscht

Ätsch-bätsch, SA-1-Spiele wollen trotz all dem Aufwand ums Verrecken nicht laufen.

Langer Rede kurzer Sinn: Jemand 'ne Idee?

[Redscorpion]

Hmm schwierig...

Hast du mal das hier Testweise gemacht?

http://www.mmmonkey.co.uk/super-mario-r ... -pal-snes/

Welches PicCode genau hast du den auf dem 17f629 drauf? Poste den mal bitte.

Gruß

red

[Ramsis]

Hast du mal das hier Testweise gemacht?

http://www.mmmonkey.co.uk/super-mario-r ... -pal-snes/

Nein, meine Spiele bleiben schön original. Dieser Umbau verändert übrigens nur die Region des SA-1, und das PAL-Golfspiel läuft ja auch nicht.

Welches PicCode genau hast du den auf dem 17f629 drauf? Poste den mal bitte.

Im Anhang. Die Datei ist die snescic-lock.hex. Der Quellcode scheint mit dem hier identisch zu sein.

[borti4938]

Kommt mir bekannt vor Hast du den Code selber compiliert?

Ich habe gerade mal das Hex angeschaut und gesehen, dass aus dem 'banksel' eine Instruktion gemacht wurde. Das Timing geht aber von zwei aus.

Magst du mal Validieren, ob das sd2snes startet, oder mit einem LED-Blink-Error den Dienst verweigert? Wenn letzteres der Fall ist, dann muss man an einigen wenigen Stellen n 'nop' einfügen Würde ich dir dann heute Abend reinsetzen...

Edit: Was mir gerade einfällt.
Nimm einfach den hier
https://github.com/mrehkopf/sd2snes/blo ... resync.hex

[Ramsis]

Hey borti, vielen Dank, deine Worte lassen mich hoffen.

Kommt mir bekannt vor Hast du den Code selber compiliert?

Ich wüsste gar nicht, wie das überhaupt geht ... Die obige ZIP-Datei stammt von ikaris Seite, heruntergeladen habe ich sie damals am selben Tag wie der Datestamp der .HEX-Dateien darin. Oh, ich sehe gerade, dass das heute auf den Tag genau fünf Jahre her ist. Wie die Zeit vergeht!

Ich habe gerade mal das Hex angeschaut und gesehen, dass aus dem 'banksel' eine Instruktion gemacht wurde. Das Timing geht aber von zwei aus.

Hmm ... dann hab ich möglicherweise schlicht und einfach ein Update verpasst (?).

Edit: Was mir gerade einfällt.
Nimm einfach den hier
https://github.com/mrehkopf/sd2snes/blo ... resync.hex

Aha, das mutmaßliche Update! Ich bin gerade nicht zu Hause, werde das heute Abend aber gleich mal ausprobieren. Wäre ja toll, wenn es damit klappt!

[Ramsis]

Leider kein Erfolg. Scheint wohl doch am Board zu liegen ...

[borti4938]

Hab mal n Paar nops in den Code, den du hattest eingefügt. Probiere mal

[ikari_01]

NOPs sind immer gut!

[Ramsis]

Hab mal n Paar nops in den Code, den du hattest eingefügt. Probiere mal

Lieben Dank für deine Mühe! Leider bringt auch die X.production-Version keine Besserung. Im Gegenteil: Star Ocean läuft damit nur mit schweren Grafikfehlern.

NOPs sind immer gut!

In diesem speziellen Fall wohl nicht ... und immerhin läuft der alte Code vom April 2010 ja einwandfrei auf allen meinen damit umgebauten Konsolen (z. B. meinem Ultra16), nur eben nicht bei diesem einen Board ... Aber sag mal, was ist eigentlich der funktionale Unterschied zwischen snescic-lock.asm und snescic-lock-resync.asm? Oder anders gefragt, was hat es mit diesem Resync-Feature auf sich?

[borti4938]

Schade Bei meinem Problem waren NOPs gold richtig
Ansonsten löte doch einfach n SuperCIC-lock ein. Schon probiert? LED-Ausgänge und Modi-Ausgang kann man ja freilassen. Außerdem kannst du schauen, ob auch 'normale' Module oder SDD1 oder SA1 in der richtigen Region erkannt werden (Pin 3 des SuperCIC). Oder brauchst du n langen Resetdruck für deine Tests???

[ikari_01]

Die resync ist eine Spezialversion. Der normale CIC-Clone geht für immer in einen Fehlerzustand, wenn der CIC-Handshake irgendwo auseinanderläuft. Die resync-Variante versucht in dem Fall den Modul-CIC immer wieder neu zu initialisieren und zu entriegeln. Gedacht war das für ein Dump-SNES für byuu, bei dem er zuerst ein Dump-ROM ins WRAM lädt und dann im Betrieb das Modul tauscht. Damit z.B. ein SA-1 dann "dumpbar" wird, muss er ja noch freigeschaltet werden.

[Ramsis]

Langsam zweifle ich echt an meinem Verstand.

Aber der Reihe nach: Habe den Umbau nun bei einem anderen SNSP-CPU-02-Board gemacht, auf dem PAL-SA1-Module vor Auslöten des Original-CICs einwandfrei liefen. Mit SNESCIC-PIC habe ich nun wieder exakt dasselbe Problem: Normale Module aller Regionen laufen, SA1-Module egal welcher Herkunft laufen nicht (schwarzer Bildschirm, kurzes grünes Flackern bei Druck auf Reset).

Habe insgesamt fünf (!) verschiedene 12F629-PICs probiert. Alle funktionieren einwandfrei in meinem 1CHIP-Test-Board mit demselben Umbau. Im SNSP-CPU-02-Board dagegen tritt der obige Fehler auf.

Was ist da bloß los? Mein Ultra16 (ebenfalls mit SNESCIC-PIC, der Umbau erfolgte schon vor Jahren) hat zwar ein SNSP-CPU-01-Board, aber fundamentale Unterschiede zwischen den beiden Revisionen (zumal bzgl. des CICs) gibt es m. W. nicht.

Bottom Line:

• Der verwendete Code ist der richtige
• Die Chips sind in Ordnung
• Der PIC-Sockel ist korrekt verkabelt, alle Verbindungen zu den PIC-Pins sind intakt

Wahrscheinlich liegt es an mir, und ich habe irgendwo einen ultra-simplen Fehler übersehen, der selbst einem Tiefsee-Schwamm im Wachkoma sofort ins nicht vorhandene Auge springen würde. Andererseits ... das wäre jetzt schon das zweite Mal und kann daher eigentlich nicht sein.

Hier nochmal das Verkabelungsschema:

Code: Alles auswählen

; ---------------------------------------------------------------------
    #include <p12f629.inc>
processor p12f629

 -------- snip --------

;   pin configuration: (cartridge slot pin) [original 18-pin SMD lock CIC pin]
;
;                       ,---_---.
;      +5V (27,58) [18] |1     8| GND (5,36) [9]
;      CIC clk (56) [7] |2     7| CIC data i/o 0 (55) [1]
;   host reset out [10] |3     6| CIC data i/o 1 (24) [2]
; CIC lock reset in [8] |4     5| CIC slave reset out (25) [11]
;                       `-------'

Für irgendwelche Ideen, was ich noch ändern/ausprobieren könnte, wäre ich wirklich sehr dankbar.

[borti4938]

Hast du mal n simple Methode mit dem originalen CIC versucht (falls noch vorhanden)?
Was man damit machen kann:
- Pins 1, 2 und 4 heben
- die Pads zu Pin 1 und 2 verbinden
- Pin 4 auf Masse (optional)

Wenn der originale CIC nicht mehr vorhanden ist (weil weggeschmissen), kannst du auch vom CIClone Pin 7 und 6 von den Pads zu 1 und 2 trennen.

[Ramsis]

Danke für den Tipp mit den I/O-Verbindungen -- werde ich ausprobieren, auch wenn ich mir nicht viel davon verspreche, ehrlich gesagt ( gerade SA1-Module erwarten doch korrekte Daten auf den I/O-Leitungen, oder?).

Wenn der originale CIC nicht mehr vorhanden ist (weil weggeschmissen), kannst du auch vom CIClone Pin 7 und 6 von den Pads zu 1 und 2 trennen.

Elektronische Komponenten, zumal wenn sie (wie der Original-CIC) noch funktionieren, werfe ich generell nicht weg.

[borti4938]

Die beschriebene Methode habe ich in meinem U16 #15 umgesetzt als ich es bekommen habe. (Pin 7 am S-CLK natürlich zurückgebogen und angelötet)

Es starten alle SA-1 Spiele, die ich habe, und auch Star Ocean und SSFZ2. Allerdings habe ich weder Super Mario RPG noch Kirby's Dreamland 3...
Warum?
Durch das Verbinden der Pads 1 & 2 'spricht' der CIC-key quasi mit sich selbst und bekommt ein gültigen CIC-Match.

Elektronische Komponenten, zumal wenn sie (wie der Original-CIC) noch funktionieren, werfe ich generell nicht weg.

Du glaubst nicht, wie viele CICs ich dann schon hier hätte