letzter Beitrag von TurboMicha am
Datenbus-Blocker mit Verbindung zu D6 und Farb-RAM sind jetzt in der Spitzenposition.
Das Farb-RAM hat einen eigenen Datenbus zum VIC. Offensichtlich läuft die CPU und schreibt diese Werte "korrekt" -> eher kein Datenbusproblem, eher ein VIC-internes Problem.
Offensichtlich läuft die CPU und schreibt diese Werte "korrekt"
Woran erkennst du das?
Offensichtlich läuft die CPU und schreibt diese Werte "korrekt"
Woran erkennst du das?
Weil der VIC genau mit den Werten aus dem ROM (Reset-Routine) initialisiert ist, die er bei mir im Vice auch hat - abgesehen von dem klemmenden D6. Wenn man das mit dem Beispielprogramm "nachholt", sind sie genau gleich. Wäre der VIC nicht initialisiert, sähest du ... genau: NIX! ("Black Screen" ist default beim VIC, eh schon wissen. 
)
[EDIT]
Offensichtlichstes Beispiel ist die hellblaue Rahmenfarbe. 
[/EDIT]
Täuscht es mich, oder ist Bit 7 immer 0?
Nee, ist teilweise gesetzt (siehe Pfund-Zeichen).
Nee, ist teilweise gesetzt (siehe Pfund-Zeichen).
Ist das nicht nur ein "Ausreißer" vom Schirm?
Bei anderen Zeichen, bei denen es gesetzt sein müsste fehlt es meiner Meinung nach.
[EDIT] Blödsinn, beim "#" ist es auch gesetzt, und die normalen Buchstaben haben das Bit nicht gesetzt. [/EDIT]
Falls du den POKE 53280,0 dann doch mal ausprobierst, teste bitte auch noch was passiert, wenn du "C=" und "SHIFT" gleichzeitig drückst - ändert sich da der Zeichensatz von "groß" auf "klein"?
Die Zeichen stimmen dann (zumindest im Vice) überein
Faszinierend! Und ganz ohne Kabel möglich.
Was man da sieht ist übrigens ein Teil des Zeichensatz-ROMs, welches der VIC an der Stelle in seinen Adressraum eingeblendet bekommt, an der bei gesetztem Bit 6 nun der Bildschirmspeicher liegt (bei 5120 in diesem Fall).
Was man da sieht ist übrigens ein Teil des Zeichensatz-ROMs, welches der VIC an der Stelle in seinen Adressraum eingeblendet bekommt, an der bei gesetztem Bit 6 nun der Bildschirmspeicher liegt (bei 5120 in diesem Fall).
Die Fehlerbeschreibung im (engl.) Artikel zum CHAR-ROM im C64-Wiki ist übrigens verdächtig übereinstimmend. (wiki)
Weil der VIC genau mit den Werten aus dem ROM (Reset-Routine) initialisiert ist
Ich hatte dich so verstanden, dass die CPU korrekt ins Farb-RAM schreibt. Deswegen war ich etwas stutzig. Jedenfalls glaubte ich, die Rahmenfarbe ist im KERNAL hinterlegt und wird ins RAM (nicht Farb-RAM) geschrieben. Aber ich lasse mich natürlich gern auch eines Besseren belehren! 
Die Fehlerbeschreibung im (engl.) Artikel zum CHAR-ROM im C64-Wiki ist übrigens verdächtig übereinstimmend. (wiki)
Ich denke nicht, dass die Beschreibung dort so gemeint ist. Garbage Characters kann alles meinen...von falschen Zeichen bis zu falschen Pixeln. Die Daten aus dem ROM scheinen mir ok zu sein, denn sie bilden die Grundlage für die Zeichenauswahl auf dem Bildschirm. Wären die falsch, dann müssten sich die Zeichen zwischen dem Screenshot und meinem Testbild unterscheiden und das sehe ich nicht (ich meine damit die Auswahl der Zeichen, nicht ihre konkrete Darstellung).
Ich hatte dich so verstanden, dass die CPU korrekt ins Farb-RAM schreibt. D
Nein, das war nicht gemeint.
Gemeint war. Die CPU initialisiert während des Abarbeitens der Reset-Routine im ROM alle I/O-Bausteine, auch den VIC, mit sinnvollen(?) Werten. Dazu gehören Rahmen- und Hintergrundfarbe, Bildschirmformat, usw. Das scheint zu klappen, da der Rahmen richtig gesetzt ist, ein Bild produziert wird und weil man in VICE das Fehlerbild nachstellen kann, wenn man überall Bit 6 setzt -> es sieht gleich aus -> der VIC wird durch die initialisiert (sonst wäre das Bild schwarz) -> die CPU läuft korrekt an und liest korrekt aus dem ROM -> kein (generelles) Datenbusproblem.
edenfalls glaubte ich, die Rahmenfarbe ist im KERNAL hinterlegt und wird ins RAM (nicht Farb-RAM) geschrieben.
Nein, ins RAM wird die Farbe eher nicht geschrieben, dort hätte sie keine Wirkung; diese entfaltet nur ein Schreibzugriff auf die VIC-Register. 
und weil man in VICE das Fehlerbild nachstellen kann, wenn man überall Bit 6 setzt -> es sieht gleich aus -> der VIC wird durch die initialisiert
Da wir mal davon ausgehen können, dass der VIC im VICE funktionstüchtig ist, sollte der VIC hier auch erstmal als funktionstüchtig angenommen werden. Er zeigt an, was im Bildschirmspeicher steht mit den Informationen aus dem Farb-RAM. Mindestens eins davon macht nicht, was es soll. Aber dafür kann der VIC nichts. Der ist ja auch nur ein Chip.
Nein, ins RAM wird die Farbe eher nicht geschrieben, dort hätte sie keine Wirkung; diese entfaltet nur ein Schreibzugriff auf die VIC-Register.
Das klingt nachvollziehbar. Wer biegt denn den Zugriff auf $d020 um (z.B. bei POKE 53280), dass der Wert im VIC-Register landet?
Mindestens eins davon macht nicht, was es soll. Aber dafür kann der VIC nichts. Der ist ja auch nur ein Chip.
Doch, der kann meiner Meinung nach schon was dafür, wenn sein Eingang D6 fix auf VCC klemmt, weil er defekt ist.
Es wäre jedenfalls eine mögliche Erklärung.
[EDIT 2]
Was es nicht erklärt sind die bunten Zeichen, aber ein kaputter VIC kann ja mehr als ein Problem haben.
[/EDIT 2]
Wer biegt denn den Zugriff auf $d020 um (z.B. bei POKE 53280), dass der Wert im VIC-Register landet?
Das PLA, indem es Bits 0..2 des CPU-Ports auswertet und bei Modus 1 (siehe https://www.c64-wiki.de/wiki/PLA_(C64-Chip)) ) den I/O-Bereich einblendet, was zum Beschreiben des VIC-Registers führt.
[EDIT]
Das nennt man Bankswitching und es ist fundamental für das Verständnis des C64.
[/EDIT]
Aah! Ich hatte I/O nicht mit dem VIC in Verbindung gebracht. Aber der VIC ist ja I/O, wenn man es vom Standpunkt des 6510 betrachtet. Außerdem gäbe es sonst auch nichts zu betrachten, vom Standpunkt des Nutzers aus gesehen. 
Ich habe mich mal durch's ROM-Listing gehangelt, um zu sehen, was beim POKEn passiert. Von dem ganzen hin- und her Gejumpe ist mir jetzt schwindelig.
Was es nicht erklärt sind die bunten Zeichen
Na ja, wenn D6 immer 1 ist, klappen doch sämtliche die allermeisten Zugriffe nicht, wo die Adresse(n) über den Datenbus weitergegeben werden. Also weder die Zeichen aus dem Zeichensatz (wie man sieht) und dann wohl auch nicht die Farben.
Na ja, wenn D6 immer 1 ist, klappen doch sämtliche die allermeisten Zugriffe nicht, wo die Adresse(n) über den Datenbus weitergegeben werden. Also weder die Zeichen aus dem Zeichensatz (wie man sieht) und dann wohl auch nicht die Farben.
Eben, daher kann es kein klemmendes Datenbit 6 auf dem Bus sein. Jeder Opcoce-Fetch usw. würde in die Binsen gehen. Die CPU käme niemals so weit, den Wert für die Rahmenfarbe aus dem ROM zu lesen und in den VIC zu schreiben. Daher muss es fast ein VIC-internes Problem sein, oder aber den 74LS373 oder den 4066 betreffen, wobei ich mir noch nicht überlegt habe wie.
Bleibt die Frage, woher das Sprite kommt, denn das ist beim Nachstellen des "D6-Problems" in VICE ja nicht da. Es muss sich um Sprite 6 handeln (-> D6), es steht an X-Position 320 (256 + 64, da XPOS=64 und das MSB dazu gesetzt ist (stimmt auch mit der Beobachtung überein), die Y-Position ist 64 (-> D6, könnte hinkommen). doppelt breit und hoch könnte auch hinkommen ... die Farbe ist schwarz (64 MOD 16 = 0, passt auch) ... warum wird es in VICE nicht angezeigt?
[EDIT]
Ich habe mich mal durch's ROM-Listing gehangelt, um zu sehen, was beim POKEn passiert. Von dem ganzen hin- und her Gejumpe ist mir jetzt schwindelig.
Und genau deshalb wäre das Ergebnis eines POKE53280,0 auf der defekten Maschine sehr interessant, wenn das klappt ist der Datenbus sicher OK.
Aber ich rede mir damit ha den Mund fusselig. 
[/EDIT]
Daher muss es fast ein VIC-internes Problem sein
Oder ein Kontaktproblem am VIC-Sockel? D6 wäre Pin 1
Und genau deshalb wäre das Ergebnis eines POKE53280,0 auf der defekten Maschine sehr interessant, wenn das klappt ist der Datenbus sicher OK.
Da wäre naürlich auch die Antwort auf diese Frage
Ist das "Einschaltbild" immer gleich
interessant. Denn sieht es jedes Mal anders aus, ist das Bit 6 nicht zwangsläufig blockiert, sondern war es nur (neben wer was was noch) bei diesem einen Mal.
Oder ein Kontaktproblem am VIC-Sockel? D6 wäre Pin 1
Hmmm ... interpretiert der VIC offene Eingänge als "1"? Noch nie getestet ...
interpretiert der VIC offene Eingänge als "1"? Noch nie getestet
Du erinnerst dich an die Grey Dots? Da könnte ein internes Precharging der Leitungen reinspielen. Und wenn auf D6 dann nichts kommt könnte eine offene Leitung als '1' gelesen werden. Ansonsten sitzt das Pad für D6 auf dem Die direkt neben dem Pad für Vcc.
Jedenfalls sollte man nachsehen ob Pin 1 am VIC vielleicht keinen Kontakt zum Rest des Systems hat.
Alles anzeigenNee, ist teilweise gesetzt (siehe Pfund-Zeichen).
Ist das nicht nur ein "Ausreißer" vom Schirm?
Bei anderen Zeichen, bei denen es gesetzt sein müsste fehlt es meiner Meinung nach.[EDIT] Blödsinn, beim "#" ist es auch gesetzt, und die normalen Buchstaben haben das Bit nicht gesetzt. [/EDIT]
Falls du den POKE 53280,0 dann doch mal ausprobierst, teste bitte auch noch was passiert, wenn du "C=" und "SHIFT" gleichzeitig drückst - ändert sich da der Zeichensatz von "groß" auf "klein"?
Bei POKE 53280,0 und C= + SHIFT passiert genau gar nichts. Bild bleibt immer gleich!
Hier nochmal der Output frisch erstellt (schaut für mich gleich aus):
SID wurde testweise auch mal entfernt => gleicher Output.
VIC (6569R3) wird sehr heiß.
Hab jetzt nicht alles noch durchlesen können aber was braucht ihr als nächstes von mir zur Fehlereingrenzung?!
Vielen Dank für eure Mühen!
LG
PS: Hat leider etwas länger gedauert da ich noch einen Sockel für den PLA einlöten musste! (war also ursprünglich nicht gesockelt)
Ich find ja Fotos immer hilfreich. Einfach auch für den Überblick.
Check mal ob Pin 1 beim VIC (messen am IC während der im Sockel steckt! C64 natürlich ausgeschaltet) eine Verbindung zum SID Pin 21 hat. Alternativ Pin 16 am Char-ROM
