Schlägt das alles fehl, müßte ich einen neuen VIC bestellen. Da der mit 30.-EUR zu Buche schlägt, bestelle ich den einmal nicht auf Verdacht, sondern erst nach Bedarf.
Da könnte es billiger sein einen totak verranzten aber kompletten C64 von Ebay zu kaufen. Der VIC ist immer gesockelt und geht eher selten kaputt. Man muss nur schauen, daß man ein Board findet welches denselben VIC-Typ (6569 oder 8565) hat.
Das wird nichts... Weil dann die CPU den VIC beim RESET nicht programmieren kann und er gar nichts anzeigen wird.
Stimmt ... 
Woraus sich umgekehrt folgern lässt, dass die Register des VIC ansprechbar sind. Wenn es der VIC ist, muss es ein sehr spezieller Fehler sein. Was ist mit "R/W" dauernd auf L? Was passiert dann, wenn der VIC Daten holen will? Ich nehme mal an, R/W beeinflusst auch die Datenbus-Treiber im VIC (Richtungsumschaltung). Evtl. "fährt" er da "ins Leere"?
...und die Zeichensatz-Daten für das '@' kämen auch nicht an.
Stimmt auch ... 
Wobei: Da müsste dann ja ein leeres Zeichen (lauter 0) angezeigt werden - immerhin was anderes als "Schachbrett". 
Was ist mit "R/W" dauernd auf L?
Ist das der Fall bekommt auch die CPU Probleme weil die RAMs jeden Zugriff als Schreibzugriff interpretieren und du gar nicht mehr an die ROMs rankommst (die PLA lässt grüssen).
VIC woanders testen... kann schliesslich wirklich ein Fehler im VIC sein, z.B. sein internes RAM (40 x 12) bzw, dessen Ansteuerung,
C=64 habe ich nur den einen hier und in Folge dessen auch nur den einen VIC 6569. Ein C=16 steht noch neben mir, aber der hat mit Sicherheit einen anderen VIC und scheidet somit auch aus. Bei Ebay habe ich vielleicht etwas gefunden - mal sehen wie sich das noch entwickelt. Ansonsten ist eben doch ein "neuer" VIC fällig.
Jetzt fällt mir noch U24, ein 74LS373 ein, der da an RAM und VIC mit dranhängt. Ich würde jetzt noch machen:
- VIC raus
- VIC-Sockel nachlöten
- VIC -Beinchen evtl. so ausrrichten, dass der Kontakt zum Sockel optimal ist (etwas auf "Spannung" ausrichten)
- 74LS373 nachlöten
- 74LS373 ggf. austauschen
- VIC tauschen
[EDIT]
Was U13 und U25 für ICs bei dir, sind das 74LS257 oder MOS77xx?
[/EDIT]
So Freunde der Nacht - obige Liste habe ich gerade eben abhaken können (bis auf VIC tauschen). D.h. die 3 Chips gegen neue ersetzt und den VIC inkl. Sockel überprüft, bzw. nachgelötet. Ich sehe nach wie vor ein einwandfreies Checkerboard. 
Ich gehe jetzt einmal schwer davon aus, daß der VIC hin ist. Oder gibt es verdächtige Leiterbahnen, die ich einmal näher beäugen sollte und zu beschriebenem Fehler führen könnten? Rein optisch sieht alles soweit gut aus und ist unauffällig.
Jaein ... wie gesagt, die AEC-Leitung vom VIC auf die TTL-ICs würde ich mal durchklingeln. Dazu am besten den VIC entfernen und die Pins wie in meinem Post weiter oben mit dem Multimeter auf "Durchgangsprüfung" auf Verbindung prüfen. Du könntest natürlich auch noch /VA14 und /VA15 vom CIA zum 74LS258 durchklingeln; möglich, dass diese Leiterbahnen was haben.
Adress- und Datenbus des VIC scheinen in Ordnung zu sein, da das C64-Kernal nach dem Reset anläuft und Rahmen- und Hintergrundfarbe richtig setzt; außerdem ändert sich mit CTRL-x (mit x = 1..8) ja anscheinend auch sichtbar die Cursorfarbe. Das spricht dafür, dass Takterzeugung, CPU, große Teile des VIC usw. funktionieren. Zur Sicherheit kannst du ja mal noch blind "POKE 53280,1" eingeben, dann müsste der Rahmen weiß eingefärbt werden.
Da bleibt dann nicht mehr viel über. Theoretisch könnte noch die PLA was haben, /VA14 hängt auch noch auf der PLA drauf. Wäre zumindest theoretisch denkbar, dass die /VA14 fix auf H oder L zieht. Da würde ich aber erstmal den VIC tauschen.
Das sind übrigens die Schaltpläne:
ftp://ftp.zimmers.net/pub/cbm/c64/schematics/251138-1of2.gif
ftp://ftp.zimmers.net/pub/cbm/c64/schematics/251138-2of2.gif
Ich möchte noch einmal auf Colts Testprogramm hinweisen, das in Beitrag #38 verlinkt ist. Damit sollte recht einfach geklärt werden können, ob alle vier VIC-Bänke funktionieren. Da es nur mit Sprites arbeitet, ist es auch unabhängig vom möglicherweise defekten Linebuffer des VIC.
Auf einem funktionierenden 64er wird "Bank 3: ok" angezeigt, und jeweils nach Tastendruck geht das dann über Bank 2 und Bank 1 runter zu Bank 0.
Alle anderen Zahlenkombinationen wären Hinweise auf Probleme mit den VIC-Banks.
Die Leiterbahnen klingeln soweit durch und bestätigen die optisch, einwandfreie Erscheinung. Das mit dem Poke habe ich jetzt nicht ausprobiert, vermute aber, auch das wird gehen. Da ich jetzt keinen C=64 komplett kriegen konnte, dem ich hätte etwas ausleihen können, biß ich in den sauren Apfel und habe mir einen VIC Chip geordert. Der wird im laufe der nächsten Tage ankommen und dann sehen wir einmal weiter.
Das Testprogramm kriege ich immer noch nicht in den C=64 mangels Laufwerk, außer dem SD2IEC. Und um von dem etwas auf dem C=64 zu Laden und Meldungen vom Prg. lesen zu können, müßte ich etwas sehen auf dem TV, was sich ja gerade als Problem erweist. 
OK, dann nochmal erneut vielen Dank an alle für die Hilfe bis hierher!
Das Testprogramm kriege ich immer noch nicht in den C=64 mangels Laufwerk, außer dem SD2IEC. Und um von dem etwas auf dem C=64 zu Laden und Meldungen vom Prg. lesen zu können, müßte ich etwas sehen auf dem TV, was sich ja gerade als Problem erweist.
Kopier das Programm am PC in das Rootverzeichnis der SD-Karte und benenn es um in "!". LOAD"!",8,1 und RUN kann man am 64er auch noch blind eintippen. Und da die Ausgabe nur mit Sprites realisiert ist, müsste das sogar auf einem VIC mit defekter Text-Einheit lesbar sein (und wenn nicht, haben wir hier mehr Daten zum Herumrätseln ).
Ahhhhhja. 
Du wirst schon was damit anfangen können. 
ich muss gestehen...
ich dachte gerade, es ist ein "Video" und was man sieht "ist die Pause" Taste und habe direkt man drauf gedrückt.. 
das kriegen die Jungs mit dir aber sicher wieder hin... 
Ahhhhhja.
Du wirst schon was damit anfangen können.
Oookay, das sieht nicht so aus wie erwartet.
Damit ist aber schon mal klar, dass es nicht an der VIC-Bank-Logik liegen kann, denn dann wäre das Sprite vollständig sichtbar.
Der VIC macht bei einem aktivierten Sprite vier Zugriffe pro Rasterzeile: Erst wird der Pointer gelesen, dann drei Datenbytes. Auf Deinem Bild sieht man, dass das erste und dritte Datenbyte Grütze (bzw. $ff) sind, das zweite aber ok ist. Da das zweite Datenbyte korrekt ist, muss auch der Pointer korrekt gewesen sein.
Laut VIC-II-Text werden die vier Zugriffe in vier aufeinander folgenden Speichertakten gemacht, also abwechselnd während der CPU- und der VIC-Pegel des Taktsignals. Und tatsächlich kommen die beiden Bytes, die hier den Wert $ff haben, aus CPU-Zyklen - das passt wie Arsch auf Eimer zu dem Schachbrettmuster, denn die Screencodes werden ja auch während CPU-Zyklen gelesen, und das Schachbrett-Zeichen hat Screencode $ff.
So, was kann man daraus ableiten?
- Entweder ist der VIC karpott (gut, so weit waren wir schon), oder
- die Bus-Arbitrierung zwischen VIC und CPU klappt nicht richtig. Allerdings läuft der Rechner ja gut genug, um Programme laden und starten zu können, also kann man davon ausgehen, dass die CPU in den Badlines tatsächlich korrekt angehalten wird. Allerdings liest der VIC in diesen Zyklen immer nur $ff statt gültiger Daten. Möglicherweise lässt sich das aber auch durch einen PLA-Defekt erklären, und der VIC ist völlig ok? Hardwarespezis vortreten, bitte.
Allerdings liest der VIC in diesen Zyklen immer nur $ff statt gültiger Daten.
Das deutet eher auf einen defekten VIC hin. Denn er sollte, wenn wegen PLA-Defekt nichts auf dem Bus zu finden ist, eben keine $FF lesen sondern das was er selbst im Zyklus davor gelesen hat. Klappt ja auch umgekehrt wenn man die CPU ihr Programm aus einem unbelegten Bereich lesen lässt.
Ausnahme: Jemand hat den Datenbus mit Pullups versehen. Die Originalschaltung des C64 hat keine. Defekter IC der den Bus belegt fällt aus, wäre es so hätte auch die CPU Probleme.
Jetzt wäre ein Oszi oder Logic-Analyzer gut, dann könnte man gleich sehen ob die $FF von aussen kommen oder im VIC passieren.
Blöde Frage:
Was passiert, wenn der 373 nicht richtig durch AEC umgeschaltet wird? Der CPU-Bus ist hochohmig, also müsste der 373 an seinen Eingängen "1" sehen -> an den Ausgängen müssten "1" anliegen.
Ohne von kinzis berechtigter Frage ablenken zu wollen,
kann es sein, dass nicht der Datenbus blockiert oder fehlbelegt ist (->PLA),
sondern die vom VIC ausgegebene Lese-Adresse in den CPU-Takthälften beeinträchtigt wird und dadurch von einer "abgelenkten" Adresse gelesen wird? Von irgendwo im RAM, wo die ganzen unbenutzten $FF-Bytes stehen ... Vermutung geht in Richtung "CPU wird zwar DMA-mäßig angehalten, Adressbus wird aber nicht richtig hochohmig und kollidiert mit VIC-Adresse". CPU kaputt?
Denn bei NMOS-Bausteinen würde, wenn mehrere den Datenbus zugleich treiben, das Datenwort das AND-Resultat mehrerer Eingänge sein und höchstwahrscheinlich eher mit mehreren Bits in Richtung $00 liegen als in Richtung $FF. Nur mal laienhaft vermutet.
EDIT: weitere Vermutung: Ausserplanmässige Verbindung (Lötklecks, Zinnbrücke) zwischen A0 und AEC oder R/W und A0 oder dergleichen...
Was passiert, wenn der 373 nicht richtig durch AEC umgeschaltet wird? Der CPU-Bus ist hochohmig, also müsste der 373 an seinen Eingängen "1" sehen -> an den Ausgängen müssten "1" anliegen.
Der 373 ist aber nur für die Adressen zuständig und auch nur für 8 Bit davon für den Zugriff auf Char-ROM und Farb-RAM.
Der Zugriff auf das Farb-RAM funktioniert aber anscheinend, sonst würde der Trick mit dem Cursor nicht gehen.
CPU-Defekt wäre natürlich möglich, aber es müsste ein interessanter Defekt sein wenn die CPU problemlos läuft und nur bei AEC auf LOW Ärger macht.
Der 373 ist aber nur für die Adressen zuständig und auch nur für 8 Bit davon für den Zugriff auf Char-ROM und Farb-RAM.
Ach herrje, sorry, ich hatte das anders im Kopf - ich dachte, die Ausgänge des 373 arbeiten Richtung RAM/VIC-Adressbus, dabei sind dort die Eingänge.
Passt, ist quatsch. 
Hätte ich nur vorher den Schaltplan nochmals angeschaut. 
Die Idee war ähnlich wie Stefans, dass immer von einer bestimmten Adresse gelesen wird (z. B. $FFFF).
Noch eine Idee (sorry ...):
AEC schaltet wegen Defekt von U8b (7406) die 74LS257 nicht richtig auf Tristate -> CPU-Adressleitungen werden immer durchgeschaltet -> Tristate-CPU-Adressausgänge = offener Eingang an 74LS257 = "H".
Da der 74LS257 kein NMOS ist, schafft der VIC es nicht, die Adressleitungen nach GND zu ziehen -> Es liegt immer $FFFF als Adresse an.
ich hatte leider außer Acht gelassen, dass im C64 ja - anders als in der 264er Serie - ein Teil der Adressen "mundgerecht gemultiplext" vom VIC direkt ans RAM geliefert wird.
Aber dass irgendwas im Umfeld von AEC beschädigt sein könnte, scheint hoch plausibel.
Ließe sich der Fehler (gefahrlos?) reproduzieren bzw. simulieren, indem man bei der CPU einfach das AEC-Beinchen aus dem Sockel zieht und hochbiegt?
Dass die CPU auf dem AEC-Signal "taub" ist, zog ich in Betracht, weil jemand mal einen 8501 - Prozessor hatte, der auf dem IRQ-Pin "schwerhörig" war (CPU defekt), ich glaube das war Jogis 8501.
Edit (sorry): kinzi, kann es dann sein, dass die LS257er (oder heissen die hier 74LS258 richtigerweise? EDIT2) selber beschädigt sind und dann ebenfalls dauernd aktiv?
Edit (sorry): kinzi, kann es dann sein, dass die LS257er selber beschädigt sind und dann ebenfalls dauernd aktiv?
Möglich. Die wurden glaube ich auch noch nicht aber schon getauscht, siehe oben.
Daher muss es noch was anderes sein, und der 7406 wird "immer wieder gern genommen" als Ursache.
(Vorbehaltlich der "Triviallösung" = VIC defekt)
