Seid ihr einverstanden, wenn ich Montag bit Bit 6 nehme ?
Riskiere nichts! Nimm das gesamte CHAR ROM raus! 
Posts by advotax
-
-
Denn Bit 0 und Bit 7 sind - zumindest für Buchstaben und Zahlen - fast immer 0, sodass für Buchstaben ganz links und ganz rechts am Rand noch ein Pixel frei ist.
Genau deswegen hätte es auch Bit 1 sein können.
Kommt halt drauf an, ob das von links nach rechts (D0, D1 .. D7) oder von rechts nach links (D7, D6 .. D0) aufgebaut ist. Aber die 6 ist ja nun mehrfach bestätigt.
-
Aus dem RAM wird der Zeichencode gelesen.
Ach klar. Bei 8 Byte pro Zeichen (= ~8k pro Bildschirmseite) passt das ja auch gar nicht da rein.
Bald habe ich verstanden, wie das Ding funktioniert. Dann leg ich mir endlich auch sowas zu.
-
Das wird bei jedem Frame neu eingelesen. Zeile für Zeile.
Aber immer wieder aus dem ROM? Nicht aus $0400-$07E7 (->Screen RAM)?
Eher Bit 7, MMN.
Ein Char = 8x8 Pixel - die normalen Buchstaben sind aber nur 6 Pixel breit, also links und rechts einer leer. Sonst würden sich zwei nebeneinanderstehende Buchstaben berühren, wie es bei den Linien ja möglich und gewollt ist.
-
Naja, "kurz" ... halt in jedem Frame die oberen Zeilen.
Ach so? Ich dachte das wird nur einmal aus dem ROM gelesen und in den Bildschirmspeicher geschrieben und der VIC zeigt dann nur aus dem das Bild an. Aber wenn das bei jedem Frame neu aus dem ROM gelesen wird, ist ja richtig was los auf dem Bus.
Nein, Bit 7 ist ganz links im Char, Bit 0 ganz rechts.
Ja, hab ich inzwischen auch so (wieder)entdeckt. Da der Pixel in jeder der 8 Zeilen pro Char fehlt, klemmt Bit 6 offenbar auf "Null".
-
Das müsste ja dann zur SuperPLA gehen.
Nur /CS. Die Datenleitung sind am Bus. Der Bus funktioniert augenscheinlich. Wenn da ein Bit hängen würde, würde wohl kein Programm laufen.
Wenn es das CHAR ROM ist, dann spuckt das bei Bit 6 eben immer ein Null statt der eigentlich gespeicherten Daten aus. Dann ist vermutlich im IC die Verbindung zwischen dem Die und dem Pin wegkorrodiert.
Checksumme müsste F3F7F8 sein.
(https://www.c64-wiki.de/wiki/Diagnostic_Harness)
Die ist bei dir 24F7F8 oder 24F7FB. Spricht also auch für das CHAR ROM als Fehlerquelle.
-
Das ist Pin 16. Der müsste dann immer "logisch 0" sein, während 9, 10, 11, 13, 14, 15, und 17 "pulsen", wenn Pin 20 (Chip Select) "low" ist. Natürlich nur, wenn auch vom CHAR gelesen wird. Das dürfte bei der Einschaltmeldung ja nur relativ kurz sein. Aber beim Diag ist da vielleicht mehr Bewegung.
Vielleicht ist es auch Bit 1? Bin mir jetzt nicht sicher, wie ein Char aufgebaut ist, ob von links nach rechts oder rechts nach links. Aber dir fehlen jedenfalls die zweiten Pixel von links. Und nur diese, wie man am Rahmen im unteren Bild des Diags sieht. Der ganz linke Pixel ist bei den meisten Zeichen ja eh blank, aber bei den Linien wären die Lücken sonst größer, wenn auch das Bit daneben fehlen würde.
-
Leitungen bei mir überprüft, aber immer noch auf der linken Seite fehlt mir
ein Teil von den Zeichen
So ein Problem wie bei mir mit fehlendem oder wackelndem Kontakt dürfte es bei dir ja nicht sein, wenn du am im Sockel steckenden Bauteil gemessen hast.
Wie es aussieht, fehlt in jeder Reihe das 6. Bit bei den Buchstaben. Wenn der Datenbus ansonsten in Ordnung ist, würde ich auch auf das CHAR ROM tippen.
-
WAS für eine schwere Geburt! Sockel gewechselt und nun tut es so, als wär nie was gewesen...
Der Deadtestkinzi005 im KERNAL-Modus läuft anstandslos durch. Und natürlich ist das original Color-RAM noch völlig in Ordnung und natürlich ist auch der andere Multiplexer noch völlig in Ordnung. Das heißt also, alles rings ums RAM ist noch gut. CPU tut noch, VIC tut noch. PLA und SID waren ja nicht dabei, aber ich wette, zumindest das PLA war vermutlich fälschlich verdächtigt worden und ein Wechsel hatte nichts gebracht oder sowas.
Mich beschleicht auch der Verdacht, das war ein sehr frühzeitiger Defekt und das Board hatte gar nicht so viele Betriebsstunden.
Egal, jedenfalls funktioniert soweit alles, wie es in dem Zustand funktionieren kann!
Eventuell mach ich die restlichen 40pinnigen Sockel auch noch und sobald wieder eine Expansionsportbuchse drin ist, werde ich auch noch die Peripherie testen und den Ultimate RAM-Test ultimativ den RAM testen lassen usw. Aber das, was ich im ersten Anlauf schaffen wollte, habe ich nun im dritten (fünften?) geschafft und statt den einen Sockel zu wechseln, der nötig war, habe ich nun doch ca. 20 eingebaut. Aber was soll's.
Und sorry, dass ich hier fünf Seiten zugespammt habe. Das hatte teilweise Notizbuchfunktion.
Melde mich zu gegebener Zeit noch mit dem Abschlussbericht.
Reparateur wechseln
Mit dem HW-Analysator von kinzi design wär's bestimmt viel schneller gegangen ...
-
Ich glaub, ich hab's.
Das
Vermutlich ist R/W am Color-RAM dauernd auf 0.
ist der Grund für die Farbrotationen. Es stellt(e) sich jedoch die Frage - warum ist das so? Die Verbindungen habe ich (mehrfach) überprüft. PCB-seitig ist da alles in bester Ordnung und sowohl PLA(ankton) als auch Color-RAM selbst funktionieren defintiv und auch miteinander - zumindest in der 425.
Nun habe ich gestern abend doch nochmal den Durchgangsprüfer für eine 4. Runde "Piep mal" zur Hand genommen und man staune! - die Leitung im Schaltplan als "GR/W" bezeichnet von PLA-Pin13 zum /OE des Color-RAM (Pin 10) piept nicht. Damit kann auch die Umschaltung Lesen/Schreiben nicht funktionieren.
Nachdem ich mein Kinn vom Tisch genommen und wieder eingerenkt habe und gerade eine Papiertüte zum drüberziehen holen wollte, habe ich beide (PLA und 2114) aus den Sockeln genommen und nochmal geprüft, denn ich war mit 107% sicher, dass ich das schon mehrfach! getan habe. Es piept. Selbst bei nur sanftester Berührung der Kontakte. Hä? Color-RAM wieder rein - piep. PLAnkton wieder rein - kein piep. Einziger Unterschied zu den vorherigen Prüfungen: Das Board ist jetzt voll bestückt! AHAAA!
Ende vom Lied: dieser Kontakt vom PLA-SOCKEL(!!!) verweigert den Dienst. Dabei sitzt das alles recht stramm, so dass ich daran niemals gedacht habe. Es ist auch deutlich weniger als ein mm Luft, aber es ist ohne Drücken definitiv kein Kontakt zwischen Sockel und Pin!
Das erklärt jetzt nicht nur das Farb-Problem, sondern ist wahrscheinlich auch der Grund für die anderen zufälligen und wenig bis gar nicht nachvollziehbaren oder reproduzierbaren Fehler. Das betrifft nämlich garantiert nicht nur den einen Kontakt an dem einen Sockel. Es waren ja werkseitig auch noch die beiden CIA, die CPU und KERNAL (und SID und VIC) gesockelt, und zwar mit den gleichen einseitigen Federkontaktsockeln! Da suche ich gar nicht erst weiter, ich tausche gleich.
Na die bei Commodore werden aber einen gepfefferten Brief bekommen!
Nächste und hoffentlich finale Schirtte: PLA-Sockel wechseln, KERNAL-Sockel wechseln, CPU-Sockel wechseln
Sinnvoll wäre natürlich auch noch CIAs, SID und VIC, aber da muss ich erst die Vorräte prüfen und ggf. erweitern...
-
Ich messe 4.85V an den Sockeln. Das ist sicher nicht zuviel, aber deutlich überm Minimum.
Hab jetzt auch zwei Sockel für die ROMs gefunden. Die kommen morgen rein und dann möchte ich mal einen Einschaltbildschirm sehen, wenn auch mit Fehlfarben! Hatte vorhin nämlich bei der 425 ohne BASIC und ohne CHAR Fehler in der Darstellung, die mit eingesetzten ROMs verschwanden.
Warum das Color-RAM nun immer noch in der Luft hängt? Da werde ich wohl oder übel nochmals mit der Lupe und dem Durchgangsprüfer ran müssen...
-
Habe nun besagtes Set in den Setzkasten getan.
Da ich gerade keine passenden 24er Sockel haben, alles bis auf CHAR und BASIC und CIA1 sowieso nicht. Da auch die Expansionsportbuchse nach wie vor fehlt, also Module erstmal ausfallen, habe ich als KERNAL den Deadtest (kinzi 005) als EPROM eingesetzt und siehe!
Die Farben laufen ordnungsgemäß durch - der Initial RAM Test wird demnach (erfolgreich) absolviert und dann kommt auch das Deadtest-Bild mit
...
farb-flackernden Zeichen.
Abbruch erwartungsgemäß beim Color-RAM-Test. Die dort angezeigten Daten-Bits sind very random, aber immer nur D0-D4, weswegen ich darauf tippe, dass da die als "falsch" getesteten Bits des Color-RAMs angezeigt werden, nicht etwa die nun zigfach als ok getesteten RAMs.
Selbes Ergebnis mit dem orignal 2114 und ich habe natürlich auch noch ein weiteres neues 2114 eingesetzt und auch mit leerem Sockel getestet - es ist immer das gleiche Flackern der Farben. Aber! Sehr viel langsamer als gestern (oder wars schon vorgestern?) als es mehr geflimmert als geflackert hatte.
Naja. Immerhin wieder ein Bild.
aber die 5V sind doch da und nicht zu niedrig unter Last?
Die 5V sind da und stabil. Greisi sei Dank!
-
Letzte Reihe:
- CPU war ja schon die ganze Zeit die aus der 407 - ist also ok
- KERNAL - URT ok
- CHAR - URT ok
- BASIC - URT ok, wird aber beim 586220 als BAD angezeigt - erstmal egal
CIA2 ist noch der von der 425 und den nehme ich auch erstmal für die nächsten Tests.
Dann habe ich den 407er VIC wieder reingepackt - URT stürzt ab beim Umschalten.
Aber nur einmal. Danach mehrere Male ohne Absturz und auch ohne RAM-Fehler. Ist es doch (nur) der Schalter?
Dann DTkinzi005 im KERNAL-Sockel - keine Fehler; mehrfacher Durchlauf
Deadtest (ungepatched) per Modul - keine Fehler; mehrfacher Durchlauf
586220 (ungepatched) per Modul - nur die Fehler, die ohne Harness kommen
Nun würde ich sage, habe ich einen Satz ICs, der funktioniert. Sowohl einzeln, als auch miteinander.
Da bei der 407 soweit gemessen alles ist, wie es ein muss, müsste das Board mit diesem Set laufen. Theoretisch. In meinen Wunschträumen.
-
Nächste Reihe:
- die oberen vier RAMs getauscht (gleich auf einmal) und nach drei fehlerfreien Durchläufen vom URT (erneut) abgehakt; Hitachi einfach
Beste!Zweitbeste!- für den zugehörigen Multiplexer (LS257) ein Neuteil, denn der eine war ja aussortiert(**): dreimal Fehlstart URT, danach dreimal ohne Fehler neugestartet und beim vierten Einschalten weiterlaufen lassen - ohne Fehler. Danach noch ein paar mal eingeschaltet - ohne Fehler angelaufen(**)
- das gleiche beim LS139; den originalen eingesetzt, 3 Fehlstarts, dann durchgelaufen ohne Fehler, auch nach mehrmaligem Einschalten danach ohne Fehler angelaufen(**)
- den original LS08 eingesetzt, nur ein Fehlstart (Absturz), danach lief es ohne Fehler durch
Jetzt habe ich mich an meine letzte 469er Reparatur erinnert (250469 Rev.4 - Zeichensalat) Da war es CIA2, der das Bank Switching des VIC nicht richtig vornahm. Nun habe ich hier ein ähnliches Gefühl. Es sind ja noch die CIAs vom 425 drin. Also CIA2 raus und stattdessen CIA1 rein.
- den original LS258 eingesetzt - URT klappt auf Anhieb und läuft fehlerfrei durch; auch nachträglich mehrfacher Neustart: kein Absturz(**), keine RAM-Fehler, nichts.
- PLA gegen PLAnkton getauscht - kein Fehlstart, URT läuft mehrfach fehlerfrei durch, Deadtest meckert nicht, auch erneute Starts des URT danach zeigen keine Fehler oder Abstürze beim Umschalten etc.
Diese Reihe ist also auch ok.
_____
(**) Nun bin ich mir fast sicher, dass es doch nicht am Modul, dem Schalter oder dem Expansionsport liegt. Nach dem Wechsel von CIA2 zeigten sich die Glitches nicht mehr. Wenn man bedenkt, dass ja noch "glitchige" Teile (LS257, 2114) drin stecken, zeigt das eher, dass sich etwas anderes getan haben muss und das kann nur der CIA-Wechsel sein. Nun ist es nicht auszuschließen, dass die CIAs der 407 den gleichen oder einen ähnlichen Fehler haben, wie ja auch die 469 einen solchen Fehler hatte. Warum das bei der 425 bisher nicht auffiel? Kann bei jedem erneuten Einschalten soweit sein...
Die zwei bisher aussortierten ICs (257, 2114) werde ich sicher am Ende nochmal einsetzen. Sind vermutlich völlig in Ordnung. Schließlich lief die 407 mit den alten Chips ja fast komplett. -
Hab ich natürlich mitbekommen und auch gleich überprüft!
"Leider" ist das die mir in Ordnung...
-
Erste Runde Test-O-Rama:
Ich habe jetzt mein 425-Testboard nochmals komplett geprüft. Alles i.O. Die CPU aus der 407 war da noch drin. Die ist somit auch schon ok und bleibt auch erstmal drin.
Dann den VIC aus der 407 eingesetzt und mehrere Durchläufe Deadtest und URT machen lassen - alles ok.
Ich hab ihn dann wieder gegen den anderen VIC ersetzt, weil er ziemlich warm wird. Es ist somit ein deutlicher Defekt ausgeschlossen und ich teste ihn ganz zum Schluss nochmal, falls es irgendwelche Wechselwirkungen gibt. Aber ganz ohne Kühlung im Dauerbetrieb will ich dann auch nicht. Ziel ist es jetzt erstmal, einen funktionierenden Satz Bauteile zu bekommen, den ich dann in die 407 einsetzen kann.
Das Vorgehen erfolgt "zeilenweise". Angefangen mit der unteren Reihe an ICs. Ein IC nach dem anderen wird zunächst durch die original ICs aus dem 407 ersetzt. Falls da einer nicht will, wird ein Neuteil eingesetzt und getestet.
- Als erstes die vier RAMs eingesetzt - Deadtest(KERNAL) und URT(Modul) zeigen keine Fehler
- Dann den Multiplexer (LS257) für diese RAMs eingesetzt - erster Glitch beim URT! Erst wird ein Bit-Fehler angezeigt, nach einen Neustart ist dann alles o.k. Eine weiterer Neustart verursacht einen Absturz beim Umschalten des URT. Der Deadtest läuft allerdings durch. Dieser LS257 wird erstmal aussortiert.(*)
- Den anderen LS257 eingesetzt - eine Runde URT ohne Beanstandung; aus- wieder eingeschaltet ein Glitch mit Programmabsturz beim Umschalten(*); danach mehrfach ok. Der bleibt erstmal drin.
- Den LS373 eingesetzt - alles läuft wunderbar durch
- Color-RAM (ist bei der 425 neben dem 373) - URT stürzt ab beim Umschalten, Deadtest als KERNAL läuft ohne Fehler durch, auch beim Color-RAM-Test! Neues Color-RAM eingesetzt, URT stürzt wieder ab, Deadtest läuft ohne Fehler durch. Color-RAM aus der 425 eingesetzt - keine Fehler! Also sind die beiden 2114-RAMs defekt? Auch das neue? Kann natürlich sein. Hin und her und her und hingetauscht - URT läuft durch, zeigt einmal einen Bitfehler im RAM, aber nach mehreren Neustarts dann ohne Fehler, mit dem neuen, wie auch mit dem Original.(*) Altes Color-RAM trotzdem raus und neues dringelassen.
- 4066 eingesetzt - alles Test werden mehrfach bestanden
Somit ist die erste Reihe offenbar ok und es gibt auch keine erkennbaren Wechselwirkungen.
Da das Board nun eine ganze Zeit lief, erstmal eine halbe Stunde Cooldown. Dann wieder angeschaltet (ohne weitere Änderungen) - der URT macht zwei Fehlstarts (1x Bitfehler auf allen! RAMs; 1x Absturz)(*), im dritten Versuch läuft er ohne Fehler drei komplette Runden durch.
Weiter geht's.
_____
(*) Ich vermute, hier spielt mir jetzt das Modul einen Streich. Der Umschalter beim URT, mit dem man den Ultimax-Mode ausschaltet prellt vermutlich zu stark und verursacht damit die Abstürze und/oder das Modul an sich (intern) hat irgendwo einen Wackler und/oder die Kontakte Modul/Expansionsport sind nicht sehr stabil miteinander verbunden. Auch faszinierend: Wenn ich den KERNAL-Ersatz mit dem Deadtest005 im EPROM im KERNAL-Sockel lasse, stürzt der URT per Modul häufig ab. Auch vor dem Umschalten! Nehme ich ihn raus (sonst keine Änderung, keine auch nur sanfte Berührung des Moduls), läuft der URT.
Werde ich eh neumachen. Hab ja den falschen Dedatest gebrannt. Dummerweise ist das EPROM eingelötet, sonst wär das alles schon längst passiert...
-
Der VIC greift auf das Char-ROM zu, in dem er selbiges über A0..A7 via 74LS373 adressiert und die Daten über den Datenbus holt.
Bei einer 469 ist das mangels diskretem 74LS373 etwas anders umgesetzt.
-
Hattest du eigentlich mal den Modulator überprüft?
Nein. Aber das Bild, dass ich ja zwischendurch hatte, deutete nicht auf einen dortigen Defekt hin. Da der Monitor über Composite angeschlossen ist, ist da vom eigentlichen Modulator nur wenig im Signalweg. Aber ist natürlich trortzdem eine mögliche Fehlerquelle. Mal sehen, ob ich den Deckel abbekomme, der hoffentlich nirgends angelötet ist. Einen Blick könnte ich ja schon mal riskieren.
-
Wahrscheinlich muss ich nur wieder eine Expansionsportbuchse einlöten und die fängt dann Erdstrahlen ein, ohne die es nicht geht. Irgendwie sowas.
-
Aber was ein Modem ist, weißt du? Das kann über die im C64 implementierte RS-232-Schnittstelle angeschlossen werden.
Andere Begriffe dafür: serielle Schnittstelle, COM-Port
