C64 mit bald defekten VIC?

Es gibt 50 Antworten in diesem Thema, welches 8.032 mal aufgerufen wurde. Der letzte Beitrag (19. Juli 2021 um 20:34) ist von p3p3.

  • Bit D7 kommt nicht richtig beim VIC an

    A11 scheint aber auch betroffen zu sein. Am "READY" sieht man deutlich, daß ganze Zeichenfolgen invers dargestellt werden.

    Um den Fehler weiter zu lokalisieren, würde ich mal testen, ob das auch bei Zeichensätzen im RAM, bei Grafiken sowie bei Sprites passiert.

    RAM-Defekt halte ich für unwahrscheinlich. Bei so wackeligem Verhalten, würde wohl keine Software mehr laufen.

    Wenn es nur beim Char-ROM passiert, dürfte es wohl der ROM-Chip oder D7 und A11 in dessen Nähe sein. Wenn es nicht aufs Char-ROM begrenzt ist, könnte es MMU, VIC, oder irgendwo dazwischen sein.

  • Wenn es nur beim Char-ROM passiert,

    ...kann auch der LS373 schuld sein, denn der ist einzig dafür da, die Multiplex-Adressen aus dem VIC in statische Adressen für die ROMs (Char oder extern) zu übersetzen.

    Bitte melde dich an, um diesen Link zu sehen. - Das offizielle iComp Supportforum ist online.

  • Wenn ich's mir recht überlege, kann der A11-Fehler natürlich auch daher kommen, daß wegen dem D7-Fehler die Daten beim Adressdecoder im VIC fehlerbehaftet sind.

  • Erst einmal Riesen Dank für die Rückmeldungen sowie den Hilfestellungen. Echt Spitzenklasse! Ich versuche mal auf die Fragen entsprechend der Reihenfolge einzugehen.

    Bitte melde dich an, um diesen Link zu sehen.

    7805

    PIN1 zu 2: 10,65-10,80 V

    PIN3 zu 2: 5,034 V stabil

    7812

    PIN1 zu 2: 19,13-19,38 V

    PIN3 zu 2: 12,020 V stabil

    Bitte melde dich an, um diesen Link zu sehen.:

    Die Linien sind normalerweise durchgängig. Es ist ein Fehlerbild, wobei dies auch schon mal von der Mitte los gehen kann.

    Bitte melde dich an, um diesen Link zu sehen.

    Fehler kommen auch bei Grafiken und Sprites vor. Mal wird ein Intro angezeigt und mal ist es nur Pixelmüll.

    Es kam auch vor, dass sich der C64 gefangen hat und dann wurde aus dem Pixelmüll ein Logo. Und die Musik lief auch wieder.


    Der LS373 schein auch ein guter Kandidat zu sein. Ich werde mal diesen und dann die super krassen RAM Steine tauschen.

    Ich melde mich wieder mit Ergebnissen :)

    Danke

    pepe

  • Fehler kommen auch bei Grafiken und Sprites vor. Mal wird ein Intro angezeigt und mal ist es nur Pixelmüll.

    Es kam auch vor, dass sich der C64 gefangen hat und dann wurde aus dem Pixelmüll ein Logo. Und die Musik lief auch wieder.

    Char-ROM kann man unter diesen Umständen wohl ausschließen.

    Wenn generell D7 nicht zuverlässig beim VIC ankommt, sind auch die Register davon betroffen, und da kann sich ein Programm durchaus komplett verabschieden, wenn sich die Raster-IRQs verheddern. Wahrscheinlich springen durch den Fehler auch Sprites um 128 Pixel nach rechts und/oder nach unten.

  • Char-ROM kann man unter diesen Umständen wohl ausschließen.

    Wenn generell D7 nicht zuverlässig beim VIC ankommt, sind auch die Register davon betroffen, und da kann sich ein Programm durchaus komplett verabschieden, wenn sich die Raster-IRQs verheddern. Wahrscheinlich springen durch den Fehler auch Sprites um 128 Pixel nach rechts und/oder nach unten.

    U. a. aus diesen Überlegungen ist ein Fehler im VIC (z. B. in dessen 40x12-Linebuffer) für mich wahrscheinlicher.

  • Bit D7 kommt nicht richtig beim VIC an:

    [...]

    Allerdings scheint D7 immer nur fälschlich gesetzt, aber nie fälschlich gelöscht zu werden.

    Beim Bild von der U2 scheint es zu fehlen (außer es wäre irgendwie eine invertierte Darstellung), oder täuscht mich das?

    Oh, das hab ich gar nicht gesehen. Invertierte Darstellung kann wegen der Farben nicht sein, die Aussage "das Bit wird immer nur gesetzt, nie gelöscht" muss ich daher zurückziehen.

    Yes, I'm the guy responsible for the Bitte melde dich an, um diesen Link zu sehen. cross assembler. And some Bitte melde dich an, um diesen Link zu sehen..

  • Der LS373 schein auch ein guter Kandidat zu sein.

    Nein, ist er nach Deiner Darstellung nicht mehr: Wenn der Fehler auch bei Sprites auftritt, dann ist der LS373 unschuldig.

    Bitte melde dich an, um diesen Link zu sehen. - Das offizielle iComp Supportforum ist online.

  • U. a. aus diesen Überlegungen ist ein Fehler im VIC (z. B. in dessen 40x12-Linebuffer) für mich wahrscheinlicher.

    Wenn der D7-Fehler auf alles schlägt, wohl eher nicht sowas spezifisches wie der Zeilenpuffer. Er macht sich mindestens an zwei verschiedenen Stellen bemerkbar, nämlich beim Lesen des Zeichensatzes, was sich dadurch bemerkbar macht, daß an etlichen Stellen das linke Bit fälschlicherweise gesetzt ist. Desweiteren führt er zum A11-Fehler, weil beim Lesen des Screen-RAMs der D7-Fehler dazu führt, das im Zeilenpuffer inverse statt normale Zeichen landen.

    Eben weil das zwei verschiedene Schaltkreise sind, und aufgrund der beschriebenen Hänger höchstwahrscheinlich auch die Register betroffen sind, muß der D7-Fehler schon vorher passieren. Entweder ist es die Datenleitung nach außen, oder es passiert bereits woanders auf dem C64-Board. Der Tipp mit dem Kältespray ist in diesem Fall sicher sinnvoll, um das weiter einzugrenzen.

  • Er macht sich mindestens an zwei verschiedenen Stellen bemerkbar, nämlich beim Lesen des Zeichensatzes, was sich dadurch bemerkbar macht, daß an etlichen Stellen das linke Bit fälschlicherweise gesetzt ist. Desweiteren führt er zum A11-Fehler, weil beim Lesen des Screen-RAMs der D7-Fehler dazu führt, das im Zeilenpuffer inverse statt normale Zeichen landen.

    Der Zeilenpuffer enthält die Screencodes einer Zeile, die bei einer Badline aus dem RAM gelesen werden. Ist der Inhalt fehlerhaft, schlägt auch das anschließende "Lookup" der Zeichendaten im Char-ROM fehl. Es erklärt also beides. Natürlich kann es auch was anderes sein, aber wie gesagt: Am Datenbus des VIC ist nichts, das nicht auch am Datenbus der CPU ist (keine besondere Logik, usw.).

    Ob die Register betroffen sind müsste man schauen, wenn man z. B. alle acht Sprites in einer Schleife permanent auf X-Position 255 stellt und dann schaut, ob welche "nach links auf 127" zappeln. Falls ja, sind die Register betroffen.

    Oder man schreibt permanent auf die X-Register und liest den Wert immer wieder zum Vergleich zurück.

  • höchstwahrscheinlich auch die Register betroffen sind

    Warum? Alle Fehlerbilder die bisher *beobachtet* wurden, passieren bei der Übertragung RAM->VIC. Reigster sind aber eine Übertragung CPU->VIC. Die kann durchaus fehlerfrei sein und trotzdem können die beobachteten Fehler auftreten. Ich bleibe bei "VIC oder RAM", mit sehr starker Tendenz zum RAM auf U12.

    Bitte melde dich an, um diesen Link zu sehen. - Das offizielle iComp Supportforum ist online.

  • Oder man schreibt permanent auf die X-Register und liest den Wert immer wieder zum Vergleich zurück.

    This. Ich hab mal mein memtest-Programm so umgestrickt, dass es nur $d000..$d010 testet. Bitte ganz normal mit LOAD und RUN laden und starten.

    Die Fehleranzeige musste ich natürlich ändern, da die Screencodes hier nicht sicher sind: Oben links wird "%........" angezeigt, wenn alles ok ist. Fehlerhafte Bits werden als '#' angezeigt, bei D7 stünde da dann also "%#.......".

    Alle Fehlerbilder die bisher *beobachtet* wurden, passieren bei der Übertragung RAM->VIC.

    Im zweiten und dritten Screenshot sieht man gesetzte D7-Bits in Spaces. Da sind die Screencodes aber schon längst geholt und der Fehler passiert erst beim Lesen der Muster aus dem Char-ROM. Mit einem reinen RAM-Fehler kann ich das nicht erklären.

  • Ist der Inhalt fehlerhaft, schlägt auch das anschließende "Lookup" der Zeichendaten im Char-ROM fehl.

    Das erklärt die inversen Zeichen, aber nicht die Pixelfehler im Zeichen.

    Warum? Alle Fehlerbilder die bisher *beobachtet* wurden, passieren bei der Übertragung RAM->VIC. Reigster sind aber eine Übertragung CPU->VIC.

    Er hat Hänger beobachtet, was auf ein Raster-IRQ-Problem schießen könnte. Daher meine Vermutung, daß die Register auch betroffen sind.

    Um das zu bestätigen würde ich mal vorschlagen, zu prüfen, ob denn auch Sprites sporadisch um 128 Pixel verschoben dargestellt werden, denn das würde einen D7-Fehler von CPU zum VIC bestätigen. Sind die Sprites stets an der richtigen Stelle, sind die Register nicht betroffen.

  • Leider war es nicht U12. Hatte mehrere RAMs getestet. Ich werde wohl mal alle RAMs austauschen.

    Ach so, so sieht es aus wenn U12 komplet fehlt^^

    Bitte melde dich an, um diesen Anhang zu sehen.

    Das ist das Ergebnis des spriteregs Progi., DANKE. Nur bewegt/flackert der Screen mehr.

    Bitte melde dich an, um diesen Anhang zu sehen.

    Erstmal Kids und Frau bespaßen. Wir liesen uns ;)

  • Das ist das Ergebnis des spriteregs Progi., DANKE. Nur bewegt/flackert der Screen mehr.

    Ich hab mal mein memtest-Programm so umgestrickt, dass es nur $d000..$d010 testet. Bitte ganz normal mit LOAD und RUN laden und starten.

    Da die Inversdarstellung offenbar funktioniert, sollte man das Programm evtl. mal so abändern, daß es alles in invers anzeigt.

  • Da die Inversdarstellung offenbar funktioniert, sollte man das Programm evtl. mal so abändern, daß es alles in invers anzeigt.

    Issn Argument. :D

  • Als Unbeteiligter muß ich nun dochmal meinen Senf dazu abgeben.

    Sofern vorhanden wäre es sinnvoll den mutmaßlich defekten VIC mal in einem anderen Board zu testen und zu schauen ob der Fehler mitwandert.

    Wenn man in das eventuell defekte Board einen intakten VIC steckt besteht die Möglichkeit das man hinterher zwei defekte VICs hat ;-).

  • Leider habe ich hier kein zweiten 12V VIC um diesen als Fehlerquelle auszuschließen. Da muss ich noch 21 Tage warten.

    Danke erstmal für die Tools. Beide (spriteregs.prg und spriteregs2.prg) konnte ich ohne Fehler starten bzw. es haben sich keine Artefakte gezeigt. Aber nach nichtmal einer Minute war die Freunde vorbei :(

    spriteregs.prg

    Bitte melde dich an, um diesen Anhang zu sehen.

    spriteregs2.prg

    Bitte melde dich an, um diesen Anhang zu sehen.

    Fehler spriteregs2.prg:

    Bitte melde dich an, um diesen Anhang zu sehen.

    Den Sockel vom VIC hatte ich nachgelötet, auch den Sockel und die Chip selbst gereinigt. Dies brachte keine Veränderung.

    Dennoch Danke euch allen für eure Hilfe!

  • Nochmal ganz langsam und möglichtst unmißverständlich und auch nur für den Fall das ein anderes funktionierendes Board vorhanden ist

    in dem man einen 12 Volt VIC betreiben kann (z.b.: ASSY 250407, 250425. usw..)

    Dann mal den VIC aus dem defekten 64er in ebenjenes Board einsetzen und sehen und staunen ob er darin ordnungsgemäß funktioniert

    oder ob dort dann auch dieselben Fehler auftreten.

    Wenn der "neue" 12 Volt VIC einfach so in das defekte Board eingesteckt wird besteht, je nachdem was nun für ein Defekt vorliegt, die

    Möglichkeit das er dabei beschädigt wird.