Hello, Guest the thread was called2.3k times and contains 50 replays

last post from p3p3 at the

C64 mit bald defekten VIC?

  • 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.

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

    #08

    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

    #10:

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


    #21

    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.

    "Wenn du überredet, ermahnt, unter Druck gesetzt, belogen, durch Anreize gelockt, gezwungen, gemobbt, bloßgestellt, beschuldigt, bedroht, bestraft und kriminalisiert werden musst. Wenn all dies als notwendig erachtet wird, um deine Zustimmung zu erlangen, dann kannst du absolut sicher sein, dass das, was angepriesen wird, nicht zu deinem Besten ist." - Quelle unbekannt.


    "Steve Jobs hat User hervorgebracht, Jack Tramiel Experten." - Quelle unbekannt.

    "Mein Herr, ich teile Ihre Meinung nicht, aber ich würde mein Leben dafür einsetzen, dass Sie sie äußern dürfen." - Voltaire.

    "Diskutiere nie mit einem Idioten - er zieht dich auf sein Niveau hinunter und schlägt dich dort mit seiner Erfahrung!" - Volksweisheit.


  • 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.

  • 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.

    "Wenn du überredet, ermahnt, unter Druck gesetzt, belogen, durch Anreize gelockt, gezwungen, gemobbt, bloßgestellt, beschuldigt, bedroht, bestraft und kriminalisiert werden musst. Wenn all dies als notwendig erachtet wird, um deine Zustimmung zu erlangen, dann kannst du absolut sicher sein, dass das, was angepriesen wird, nicht zu deinem Besten ist." - Quelle unbekannt.


    "Steve Jobs hat User hervorgebracht, Jack Tramiel Experten." - Quelle unbekannt.

    "Mein Herr, ich teile Ihre Meinung nicht, aber ich würde mein Leben dafür einsetzen, dass Sie sie äußern dürfen." - Voltaire.

    "Diskutiere nie mit einem Idioten - er zieht dich auf sein Niveau hinunter und schlägt dich dort mit seiner Erfahrung!" - Volksweisheit.


  • 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.

  • 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.

  • 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


    spriteregs2.prg


    Fehler spriteregs2.prg:


    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.

  • Glaube ich nicht, bei dem Fehlerbild.

    "Wenn du überredet, ermahnt, unter Druck gesetzt, belogen, durch Anreize gelockt, gezwungen, gemobbt, bloßgestellt, beschuldigt, bedroht, bestraft und kriminalisiert werden musst. Wenn all dies als notwendig erachtet wird, um deine Zustimmung zu erlangen, dann kannst du absolut sicher sein, dass das, was angepriesen wird, nicht zu deinem Besten ist." - Quelle unbekannt.


    "Steve Jobs hat User hervorgebracht, Jack Tramiel Experten." - Quelle unbekannt.

    "Mein Herr, ich teile Ihre Meinung nicht, aber ich würde mein Leben dafür einsetzen, dass Sie sie äußern dürfen." - Voltaire.

    "Diskutiere nie mit einem Idioten - er zieht dich auf sein Niveau hinunter und schlägt dich dort mit seiner Erfahrung!" - Volksweisheit.