snesfreaks.com

borti4938 hat geschrieben: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.

Funktioniert bei mir leider nicht: SFA2 (PAL) zeigt beim Start nur vertikale weiße Streifen, und Star Ocean (JAP) bzw. SA1-Module egal welcher Region starten überhaupt nicht (schwarzer Bildschirm).

Habe den Mod nunmehr bei einem weiteren SNSP-CPU-02-Board (dem mittlerweile dritten!) ausprobiert -- wieder mit demselben Ergebnis: SFA2 (PAL) und Star Ocean (JAP) starten problemlos, SA1-Module egal welcher Region führen zum Blackscreen.

@borti4938, du hast inzwischen sicherlich mehr SNES-Konsolen auf SNESCIC/SuperCIC umgerüstet als ich; gibt es deiner Erfahrung nach eine statistisch gesehen erhöhte Fehlerrate mit SNSP-CPU-02-Boards?

Bin mittlerweile, ehrlich gesagt, ziemlich verzweifelt. Wenn schon dieser im Grunde super-einfache Mod nicht mehr klappt (aus welchen Gründen auch immer), dann brauche ich mir erst gar keine Mühe zu geben, zukünftig SuperCIC-Mods durchzuführen. Und diese Aussicht ist nicht nur frustrierend, sie ist geradezu desaströs.

Ich habe noch NIE Probleme gehabt!!! Bei mir startete immer alles...

Da ich gerade kein SNSP-CPU-02 hier habe, könntest du mir ja mal eins langschicken
Wenn du magst -> PN an mich

borti4938 hat geschrieben:Da ich gerade kein SNSP-CPU-02 hier habe, könntest du mir ja mal eins langschicken
Wenn du magst -> PN an mich

Danke, sehr nett von dir! Evtl. komme ich in Kürze darauf zurück.

Jetzt habe ich mir allerdings erst mal ein paar 16F630er bestellt, um mit einem der zickenden SNSP-CPU-02-Boards den SuperCIC-Mod zu testen (den ich schon öfter erfolgreich durchgeführt habe, darunter auch einmal mit einem 02er-Board). Mittlerweile habe ich nämlich einen bösen Verdacht ...

@borti4938, du weißt nicht zufällig, ob man beim SuperCIC die Ausgänge für LED und 50/60-Hz-Umschaltung problemlos unbeschaltet lassen kann? (Das geplante Dev-Board kriegt eh einen mechanischen 50/60-Hz-Schalter. )

kannst du Du musst lediglich Pin 7 auf Masse legen, weil der als Eingang geschaltet ist.
Allgemein: die Pins 3, 5, 6 und 12 können unbelegt bleiben. Pin 4 und 7 musst du festlegen - ich würde Masse nehmen.
Denke daran, dass du halt nur n kurzen Reset hast und den Doppelreset. Langes Halten des Resettasters bewirkt nichts.

Fortschritt/Erkenntnis von heute: Der SuperCIC bringt's.

Die Einzelheiten: Habe den 8-Pin-Sockel des SNESCIC durch einen 14-Pin-Sockel für den SuperCIC ersetzt und dann (da ich ja noch auf meine Bestellung warte) den SuperCIC aus einer meiner zum Zocken verwendeten Konsolen -- in welcher der SuperCIC seit jeher einwandfrei seinen Dienst verrichtet -- eingesetzt.

Resultat: Alle Spiele starten/resetten auf Anhieb, sogar mein hyperkritisches japanisches Super Mario RPG, das ich als SA1-Referenz-Testmodul verwende.







Mein angedeuteter Verdacht, dass der alte SNESCIC-PIC-Code nicht zu 100% zuverlässig ist, hat sich demnach bestätigt, zumal ich dieselben Strippen verwende wie bisher (rote Kabel) und Software-Probleme mit dem Willem-Brennprogramm ausschließen kann (schließlich funktioniert ein- und derselbe SNESCIC-PIC im 1CHIP-SNES korrekt, nicht jedoch im erwähnten 02er-Board).

@ikari_01, besteht evtl. die Möglichkeit, den relevanten Teil aus dem letzten SuperCIC-Release vom Herbst 2010 in den (freilich noch älteren, aber im Vergleich offenbar fehlerhaften) SNESCIC-Code vom 28.04.2010 zu "backporten"? Würde mich riesig freuen.

Lieben Gruß,
Ramsis

Ein Blick in die ASM-Files - der interessante Teil ist identisch

Vielleicht mag dein Willem den PIC 12F629 nicht wirklich (Softwareupdate mal gemacht?). Hast du keine PICKit?
Kannst du mal n PIC (der nicht läuft) über deinen Willem auslesen und mir das Hex schicken?

Ich habe derweil auch nochmal geschaut und einen gefragt, der n U16-PCB mit dem PIC 12F629 in ein SNSP-CPU-02 eingebaut hat: Super Mario RPG (Jap.) läuft dort...!!!
(Meine PICs habe ich mit einem PICKit 3 (teilweise auch mit dem Tl866) geflasht)

Achja: du kannst C9 entfernen. Der Elko ist arbeitslos ohne originalen CIC.

Grüße,

ich hab hier mal den 12f629 Code für den Only CIC Umbau beim U16 hochgeladen:

https://dl.dropboxusercontent.com/u/197 ... ic-pic.zip

Eventuell bringts das?

Btw: Willem: Hast du bei der OSCAL-Abfrage Ja oder Nein gemacht?!

Gruß

red

Redscorpion hat geschrieben: Btw: Willem: Hast du bei der OSCAL-Abfrage Ja oder Nein gemacht?!

Irrelevant, da eh ein externer Takt verwendet wird

borti4938 hat geschrieben:Ein Blick in die ASM-Files - der interessante Teil ist identisch

Höchst seltsam, in der Tat.

borti4938 hat geschrieben:Vielleicht mag dein Willem den PIC 12F629 nicht wirklich (Softwareupdate mal gemacht?). Hast du keine PICKit?
Kannst du mal n PIC (der nicht läuft) über deinen Willem auslesen und mir das Hex schicken?

An ein Softwareproblem habe ich ja auch schon gedacht – aber warum funktioniert dann ein und derselbe PIC im 1CHIP-SNES (und nur dort)? Einen PICKit habe ich leider nicht.

Jedenfalls habe ich mal zwei der mit ikaris originalem Code beschriebenen Chips gedumpt (im Anhang). Tatsächlich unterscheiden sich Dump1.hex und Dump2.hex erheblich von der Originaldatei (snescic-lock.hex) -- keine Ahnung, ob das so sein darf/muss. Außerdem unterscheiden sich die beiden ersten Dumps auch untereinander, vermutlich wegen der unterschiedlichen OSCCAL-Werte (ich habe jeweils immer die OSCCAL-Werte der Chips beibehalten).

Dann habe ich die neueste Version der Willem-Software installiert (0.98D12, vorher hatte ich 0.98D5) und den zweiten Chip noch einmal frisch beschrieben und gleich wieder ausgelesen (Dump3.hex). Ergebnis: Dump2.hex und Dump3.hex sind identisch.

borti4938 hat geschrieben:Achja: du kannst C9 entfernen. Der Elko ist arbeitslos ohne originalen CIC.

Ah, danke, nach einem Blick auf die SNES-Schaltpläne neulich hatte ich das schon gehofft. Immerhin ein SMD-Elko weniger, der womöglich irgendwann ausläuft.

Redscorpion hat geschrieben:Grüße,

ich hab hier mal den 12f629 Code für den Only CIC Umbau beim U16 hochgeladen:

https://dl.dropboxusercontent.com/u/197 ... ic-pic.zip

Scheint exakt dieselbe Datei wie meine zu sein.

Deine Dumps passen weder zum snescic-lock.hex noch zum snescic-lock-resync.hex - zumindest nicht zu den Dateien, die ich habe. Sie unterscheiden sich an diversen Speicherstellen - ich müsste das mal disassemblieren, um genau zu sehen, was das ist. Und nein, es liegt nicht daran, dass ich bei mir 'bankel'-Befehle durch 'bcf/bsf STATUS, RP0' und ein 'NOP' ersetzt habe. Es ist mehr, soviel habe ich gesehen.

Merkwürdig :/ Vielleicht solltest du auf den Tl886 umsteigen Der kostet nicht viel und ist zu sehr viel zu gebrauchen

Was mich persönlich interessieren würde:
Ich habe dir mal fix den snescic-lock-resync für den 16F630 (geht auch auf 16F676 und 16F684) fertig gemacht. Anschluss wie für die 12F629 Version, die sechs 'unteren' zusätzlichen Pins frei lassen (sind als Ausgang geschaltet, damit die nicht floaten). Also nur Pins 1-4 und 11-14 verwenden. Funktioniert der Code?

Was mir auch aufgefallen ist: du hast keinen Kerko zw. Pin 1 und 14 (bzw. beim 12F629 Pin 8 ) - das könnte ein GROSSES Problem sein. Hier mal ein Youtube-Video, was gut zeigt, warum

Grüße,

bin ab hier leider raus. Ich hab auch mal in mein SCIC archiv geschaut und kein annährend gleiches Hex gefunden. Geht schon in den ersten 20 bytes los die Unterschiede.

OSCAL Wert beim Willem. Nagle mich nicht fest, ich hatte jedoch mal einen 12F629 für meine Multicarts genutzt und mit OSCAL wert ging gar nicht und ohne auf einmal ohne Probleme. Trotz das beide HEX Files beim Dumpen okay waren.

Ich bin echt mal gespannt woran es hier liegt!

Btw: War die SCIC Version fürs U16 nicht speziell angepasst auf den Takt des CPLDs? Ich hab da irgendwas im Kopf, kann aber auch irrglaube sein!

Gruß

red

Bei deinen Multicarts verwendest du auch den internen Takt des PICs; die CIC-Klone laufen alle über einen externen Takt (über Pin 2 vom PIC), damit CIC-lock und CIC-key synchron laufen.
Der OSCCAL ist zur Kalibrierung des internen Taktgebers. Wenn man den nicht nutzt - sei es keine Kalibrierung im Program vorsieht oder gar den internen Takt nicht nutzt - so kann man auch die letzte Speicherstelle (ist der OSCCAL Wert als rtlw-Befehl) auch durch eigenen Code überschreiben (vorausgesetzt die Programmersoftware lässt das überhaupt zu).

Mit dem U16 verwechselst du irgendwas. Ich habe den snescic-lock-resync verwendet. (Die resync-Version, da man die Module theoretisch im U16 Menü ein- und ausstecken kann, wenn man die Modulsperre entfernt)

borti4938 hat geschrieben:Deine Dumps passen weder zum snescic-lock.hex noch zum snescic-lock-resync.hex - zumindest nicht zu den Dateien, die ich habe.

Wie ist das generell -- muss beim Auslesen exakt dieselbe Datei herauskommen, die auch zum Beschreiben verwendet wurde?

borti4938 hat geschrieben:Ich habe dir mal fix den snescic-lock-resync für den 16F630 (geht auch auf 16F676 und 16F684) fertig gemacht. Anschluss wie für die 12F629 Version, die sechs 'unteren' zusätzlichen Pins frei lassen (sind als Ausgang geschaltet, damit die nicht floaten). Also nur Pins 1-4 und 11-14 verwenden. Funktioniert der Code?

Habe im Moment (außer den beiden SuperCICs) keine 16F-Chips mehr im Haus, aber sobald meine Bestellung eintrifft, werde ich das gerne ausprobieren.

borti4938 hat geschrieben:Was mir auch aufgefallen ist: du hast keinen Kerko zw. Pin 1 und 14 (bzw. beim 12F629 Pin 8 ) - das könnte ein GROSSES Problem sein.

Die Problematik ist mir bekannt, ich dachte nur nicht, dass es daran liegen könnte, weil alle meine früheren SNESCIC- bzw. SuperCIC-Umbauten ohne Kondensatoren funktionierten. Werde aber in Zukunft zur Sicherheit Kondensatoren anbringen, danke für den Hinweis. (Kann man zur Not auch 0,1-µF-Elkos verwenden? Keramikkondensatoren mit 100 nF müsste ich nämlich erst bestellen. Jaja, auf die richtige Polung achte ich dann schon. )

Ein Riesendankeschön an euch beide, besonders an borti, für eure geduldige Hilfsbereitschaft in dieser Sache!

Hmmm ... gegen die Theorie eines Software-Problems seitens meines Willem-Programmers spricht das hier:



Dies war mein ursprünglicher DX2-Mod (der PIC enthielt den regulären snescic-lock.hex). Gerade eben habe ich den 12F629 entfernt und auf einen der PICs, die mir Probleme bereiten, den snescic-lock-resync.hex geschrieben. (Idee dahinter: SA1- und S-DD1-Spiele sollen auch nach einem Reset auf der DX2 erkannt werden, was bislang nicht der Fall war.)

Ergebnis: Alle SA1-/S-DD1-Spiele werden von der DX2 problemlos erkannt, auch nach einem Druck auf Reset (und selbst dann, wenn ich das Spiel über das Menü schon gestartet habe).

Bilder des Mods von heute Abend (auch wenn kaum Neues zu sehen ist):





Super Mario RPG läuft und läuft und läuft ... Schraube die DX2 also nun wieder zusammen.

So, meine 10er-Packung 16F630er ist endlich eingetroffen. Die ersten zwei Chips, die ich testweise mit supercic-lock.hex beschrieben habe, arbeiten einwandfrei in meiner SuperCIC-Testkonsole.

@borti4928, deinen Resync-Code für16F6XX-PICs werde ich baldigst sowohl in der DX2 als auch in einer der "Problemkonsolen" testen und mich spätestens dann zurückmelden.

Ramsis hat geschrieben:

borti4938 hat geschrieben:Deine Dumps passen weder zum snescic-lock.hex noch zum snescic-lock-resync.hex - zumindest nicht zu den Dateien, die ich habe.

Wie ist das generell -- muss beim Auslesen exakt dieselbe Datei herauskommen, die auch zum Beschreiben verwendet wurde?

Die Frage besteht weiterhin. Hintergrund: Ich habe mal irgendwo gelesen, dass schon das bloße Auslesen eines PICs den Code im PIC korrumpiert. Keine Ahnung, ob das stimmt -- falls ja, wäre das ja bereits beim automatischen Verify nach dem Beschreiben fatal, oder?