Reparaturbericht Terra Cresta

  • Details folgen später...


    Vorher:
    [ATTACH=CONFIG]25338[/ATTACH]
    Damit:
    [ATTACH=CONFIG]25339[/ATTACH]
    Nachher...
    [ATTACH=CONFIG]25340[/ATTACH]

  • Also wie versprochen, auch wenn's (außer einem) keinen interessiert:


    Terra Cresta, eingeliefert mit massiven Grafikfehlern.


    [ATTACH=CONFIG]25342[/ATTACH][ATTACH=CONFIG]25343[/ATTACH]


    Man sieht deutlich: die Fehler sind nur an den Background-Tiles vorhanden. Sprite-Daten und Text-Gfx. werden korrekt dargestellt.


    Es gibt keinen Schaltplan, aber die hilfreiche MAME-Source sagt unter terracre.c:


    ROM_START( terracre )
    ROM_REGION( 0x20000, "maincpu", 0 ) /* 68000 code (main CPU) */
    ROM_LOAD16_BYTE( "bk1_1.4b", 0x00001, 0x8000, CRC(60932770) SHA1(887be7a44cb7bf30d11274d34896217cc87ae158) )
    ROM_LOAD16_BYTE( "bk1_3.4d", 0x00000, 0x8000, CRC(cb36240e) SHA1(24696503d9720ced869bb96ec64f336679726668) )
    ROM_LOAD16_BYTE( "bk1_2.6b", 0x10001, 0x8000, CRC(539352f2) SHA1(b960f75d12ebdcd6781a073a66b8e503a8f55186) )
    ROM_LOAD16_BYTE( "bk1_4.6d", 0x10000, 0x8000, CRC(19387586) SHA1(76473493d173efde83ded52ad721d2c532f590e2) )

    ROM_REGION( 0x10000, "audiocpu", 0 )/* Z80 code (sound) */
    ROM_LOAD( "bk2_11.15b", 0x0000, 0x4000, CRC(604c3b11) SHA1(c01d1ddae40fa8b65dfc72f959942cb9664a548b) )
    ROM_LOAD( "bk2_12.17b", 0x4000, 0x4000, CRC(affc898d) SHA1(a78f06fa125de16fcdb8f4dc1629eb775aad913a) )
    ROM_LOAD( "bk2_13.18b", 0x8000, 0x4000, CRC(302dc0ab) SHA1(4db8f12e70f9adf1eb993c6a8af68b5edbf79773) )

    ROM_REGION( 0x02000, "gfx1", 0 ) /* tiles */
    ROM_LOAD( "bk2_14.16g", 0x00000, 0x2000, CRC(591a3804) SHA1(e1b46f5652e7f9677d75f01c6132975ace4facdd) )

    ROM_REGION( 0x10000, "gfx2", 0 ) /* background */
    ROM_LOAD( "bk1_5.15f", 0x00000, 0x8000, CRC(984a597f) SHA1(1f33892f160691c44872b37f0f6cb1493c9f7fb1) )
    ROM_LOAD( "bk1_6.17f", 0x08000, 0x8000, CRC(30e297ff) SHA1(9843826ae63039d6693c8a0b30af721d70f40056) )

    ROM_REGION( 0x10000, "gfx3", 0 ) /* sprites */
    ROM_LOAD( "bk2_7.6e", 0x00000, 0x4000, CRC(bcf7740b) SHA1(8701862c35eb8fb1ec239253136a3858ebea4d0c) )
    ROM_LOAD( "bk2_8.7e", 0x04000, 0x4000, CRC(a70b565c) SHA1(153e5f5a9927c294660dd0d636a9f651d4984d6d) )
    ROM_LOAD( "bk2_9.6g", 0x08000, 0x4000, CRC(4a9ec3e6) SHA1(0a35b82fb49ecf7edafd02744a48490e744c0a00) )
    ROM_LOAD( "bk2_10.7g", 0x0c000, 0x4000, CRC(450749fc) SHA1(376ab98ab8db56ed45f7d97a221dfd52e389cb5a) )

    ROM_REGION( 0x0400, "proms", 0 )
    ROM_LOAD( "bk1_3.10f", 0x0000, 0x0100, CRC(ce07c544) SHA1(c3691cb420c88f1887a55e3035b5d017decbc17a) ) /* red component */
    ROM_LOAD( "bk1_2.11f", 0x0100, 0x0100, CRC(566d323a) SHA1(fe83585a0d9c7f942a5e54620b627a5a17a0fcf4) ) /* green component */
    ROM_LOAD( "bk1_1.12f", 0x0200, 0x0100, CRC(7ea63946) SHA1(d7b89694a80736c7605b5c83d25d8b706f4504ab) ) /* blue component */
    ROM_LOAD( "bk2_4.2g", 0x0300, 0x0100, CRC(08609bad) SHA1(e5daee3c3fea6620e3c2b91becd93bc4d3cdf011) ) /* sprite lookup table */

    ROM_REGION( 0x0100, "user1", 0 )
    ROM_LOAD( "bk2_5.4e", 0x0000, 0x0100, CRC(2c43991f) SHA1(312112832bee511b0545524295aa9bc2e756db0f) ) /* sprite palette bank */

    /* 11e and 12a might be PALs */
    ROM_END

    Also sehen wir uns doch mal die ROMs 15F und 17F genauer an. Datenleitungen sind i.O. aber die höchstwertigen Adressleitungen sind tot... Ein kurzschließen der toten Adressleitungen mit +5V erzeugt ein Bild, welches dem Original schon näher kommt... Da muss die Ursache liegen.


    Verfolgen wir nun die Adressleitungen zu ihrem Ursprung: Sie werden won einem 74LS273 (oktal Latch) bereit gestellt, welcher ganz am Rand der Platine sitzt. In den RAMs darunter werden die anzuzeigenden Tile-Nummern gespeichert. Die hochwertigen Adressbits sind die Nummern der einzelnen Tiles, die niederwertigen Adressbits sind die jeweiligen Zeilennummern, da diese aber funktionieren, werden die falschen Tiles richtig dargestellt... Alles klar?


    Jetzt kommt die harte Probe, habe ich schon gelesen, aber vorher noch nie so ausprobiert: einfach mal einen funktionierenden TTL auf den vermeintlich defekten aufstecken und hoffen, dass sich der "gute" durchsetzen wird. Und voila:


    [ATTACH=CONFIG]25344[/ATTACH]


    Schon klappt's mit der Adressierung!!!


    [ATTACH=CONFIG]25346[/ATTACH][ATTACH=CONFIG]25347[/ATTACH]


    Grüßle,
    Mike McBike

    Dateien

    • huckepack.jpg

      (259,38 kB, 16 Mal heruntergeladen, zuletzt: )
    • sc_nachher0.jpg

      (126,65 kB, 7 Mal heruntergeladen, zuletzt: )
    • sc_nachher1.jpg

      (230,47 kB, 12 Mal heruntergeladen, zuletzt: )
    • sc_nachher2.jpg

      (250,05 kB, 10 Mal heruntergeladen, zuletzt: )
    • sc_vorher0.jpg

      (111,64 kB, 6 Mal heruntergeladen, zuletzt: )
    • sc_vorher1.jpg

      (156,97 kB, 11 Mal heruntergeladen, zuletzt: )
  • Vielleicht sollte ich noch abschließend erwähnen, dass der beschriebene Weg keinesfalls derjenige war, den ich konsequent gegangen bin... parallel dazu habe ich noch gefühlte 20 andere Chips auf Funktion gemessen und mit dem Durchgangsklingler die Daten- und Adressleitungen verfolgt... Reparaturzeit: ca. 3h...


    Wenn man vorher immer wüsste, was hinterher rauskommt, könnte man viel effektiver arbeiten.

  • Hey Wolfgang,


    jetzt läufts aber bei dir! Im (gefühlten) Minutentakt haust jetzt reparierte PCBs raus. Klasse.
    Guter Bericht! Und mit den Mame Sources hab ich auch schon das eine oder andere raparieren können, wo kein Schaltplan vorhanden ist.


    Mach weiter so!


    Gruß
    Enrico

  • Danke Eni! Ich frage mich nur immer: woher wissen die MAME-Entwickler immer so gut, wie das alles läuft? Da komme ich mir immer ganz blöd vor...


    Grüßle,
    Mike McBike

  • Hihi :)
    Naja ganz blöd sind wir alle nicht.
    Ja das sind halt Programmiercracks.... das Zauberwort lautet Reverse Engineering.
    Außerdem würde es mich nicht wundern, wenn der eine oder andere Programmierer von damals sein Wissen mit anderen geteilt hat :)


    Aber ein Glück gibt es solche Jungs! Davon profitieren wir jetzt alle.

  • Todschick!
    Aber das mit dem Huckepack funzt nur, wenn der Defekt eine Unterbrechung im IC ist.
    Bei Schluß einer Leitung nach GND oder Vcc kann der neue ebenfalls mit zerstört werden.
    Das hattest Du aber sicherlich vorher gecheckt.
    Gruß
    Winfried

    Vacuum-Fachverkäufer


    Wissen ist der einzige Rohstoff, welcher sich durch Gebrauch vermehrt! :thumbsup:


    Aus aktuellem Anlaß weise ich darauf hin, daß Reparaturtips nur unter Beachtung der Regeln im Umgang mit elektrischen Geräten befolgt werden sollten!
    Sollten dort Zweifel bestehen, bitte einen Fachmann zu Rate ziehen!

  • Todschick!
    Aber das mit dem Huckepack funzt nur, wenn der Defekt eine Unterbrechung im IC ist.
    Bei Schluß einer Leitung nach GND oder Vcc kann der neue ebenfalls mit zerstört werden.
    Das hattest Du aber sicherlich vorher gecheckt.
    Gruß
    Winfried


    Yepp, war floating... ;)

  • Ist mir schon klar, dass die das wissen müsse. Ich frage mich nur: Warum sind die so viel schlauer, als ich? ?(

  • sind sie nicht, aber es sind weltweit sehr viele leute......................das ist dann "schwarmintelligenz"