Beide MMF9000 Zusatzplatinen sind funktionslos.
Mach Dir nix draus. Schenk mir den Kruscht, und Du hast Ruhe.
ich nähme auch eine der "Schrott"-Platinchen 
8032029 Universal Board - Fehlersuche
-
-
ich nähme auch eine der "Schrott"-Platinchen
Das Ding funktioniert nur in Kombination, werter Herr...
Wenn, brauchst du alle drei (Bild noch vor dem Vollbad aufgenommen):
Platinen zum Nachbauprojekt von zitruskeks habe ich keine mehr vorliegen.
-
ok, ok - bevor ich mich schlagen lass ...ich nehm die anderen beiden "auch"
zurück zur Realität:
könnte vielleicht gerade dein Vollbad schuld sein, an der "nichtmehrFunktion" der Platinen? ...also gerade Jumper, Steckverbindungen, Potis, Trimmer, Drehkondensatoren, und auch QUARZE! ...sind nicht wasserdicht und sollten nach einem Bad im "nicht"-VE-Wasser ...wie es im Hobby-Bereich halt so verwendet wird wieder gut gesäubert werden von der Kalkschicht, die sich drauf ablagert
heisst bei Potis, Trimmern, Drehkos : mehrfach in verschiedene Stellungen drehen, danach wieder in die Ausgangslage
bei Steckverbindern, Jumpern, Schaltern, Dips.. mehrfach Stecken, Schalten, bewegen !
-
Alter Falter... da hab ich mir was aufgehalst...
Mittlerweile ist das Universal Board bei mir eingetroffen - also erst mal den eigenen 8096 auf den Platz wuchten und die Spannungsversorgung "ausleihen"...
Das Board ist ja sauberer, als es jemals bei der Herstellung gewesen sein kann... putzt du das im Ultraschallbad?
By the way - lieber dreckig und geht als sauber und karpott.
Erste Tests: Spannungen liegen überall an, CPU hat Takt, RESET# geht nach 1s auf High. Kein Wait, NMI# sauber auf High - IRQ# auf Dauer-Low, das deutet auf ein Problem mit den 6520/22 hin, sollte aber die Programmausführung nicht behindern. Adressbus und Datenbus zappelt kurz und legt sich dann still.
RAS/CAS an den DRAMs ist aktiv.
Die gesockelten ROMs laufen in meiner Kiste einwandfrei, die 6502 läuft auch.
Schritt 1: Sichtkontrolle des Datenbusses. Mehrere Bits sind stuck low / high oder anderweitig halblebig. Zwei der bereits gesockelten RAMs sind platt. Protip: defekte RAMs werden durch Sockel nicht ganz...
Durch den Tausch normalisieren sich zwei Datenleitungen wieder. Vier (!) andere sind immer noch doof.
Alle Datenleitungen zappeln jetzt (wenn das System mal startet - und das ist nur sporadisch der Fall...) halbwegs normal.
Zum Vergleich: der IRQ# eines funktionierenden Systems - aber da sind wir noch weit von weg.
-
Die RAMs 4116 sind dafür berüchtigt, massenhaft kaputt zu gehen - Williams Arcadeboards sind voll davon und beliebte Reparaturobjekte. Aber weiter mit dem CBM...
Da das System mit halbwegs vernünftigen RAMs immer noch nicht richtig laufen will, checke ich die Chip Select Signale gegen das Verhalten auf dem Datenbus. Überraschung: es gibt kein einziges ROM, welches angesprochen wird. Der 74154 Adressdecoder ist tot. Muss ersetzt werden.
Jetzt bekommen wir beim Start schon mal sowas, was wie ein Programmablauf aussieht...
Aber das bricht immer wieder ab, startet nur sporadisch und Piepen tut schon mal garnichts...
Nächster Schritt: konsequent alle RAMs tauschen.
Trotzdem: es gibt Busteilnehmer, die keinen richtigen Pegel zustandebringen - die gilt es jetzt zu finden...
Mittlerweile frage ich mich, was so ein Board durchgemacht haben muss, dass fast alle Bauteile einen Knacks weg haben - zumal es keine äußeren sichtbaren Belastungsspuren gibt...
-
Schau Dir doch mal die SN74LS244 Buspuffer an, die in den fragwürdigen Signalwegen liegen. Ich hatte schon bei einigen Universal Boards defekte Buspuffer, die z.T. merkwürdige Fehlerbilder ergeben. Von den Teilen sind bestimmt 8 Stück auf dem Board verbaut.
-
Juhuuuu!
Erstmal vielen herzlichen Dank für deinen heftigen Einsatz. Bestätigt, dass da doch etwas mehr defekt ist.
Was mit dem Rechner passiert ist… gute Frage! Ich weiß nur, dass der Netzfilter geplatzt war, und auf manchen Stellen des Boards leitfähige Späne lag. Ganz fein, fast wie Staub. Nicht überall, aber auf der obersten der drei Platinen. Echt suspekt.
Also hab ich keinen Lötfehler drin- freut mich.
Und: So viele defekte ICs- das hätte ich niemals gefunden… bzw nur über mein obligatorisches „Pauschaltauschen“.
Mir graut schon vor den anderen beiden Platinen… die machen ja auch wenig bis nix.
Viele Grüße- ich lausche und lese gespannt,
Matthias
-
Danke für den Tip mit den LS244 Buffern - hat aber leider nicht geholfen...
Bei Zugriff auf das "FFxx"-ROM treten Fehler auf dem Datenbus auf:
In den letzten 500ns wird der Datenbus D0 (hier im Bild) vermutlich von einem weiteren Teilnehmer gewaltsam auf einen ungültigen Level gezogen.
Es gibt nicht viele Teilnehmer, die nur in den letzten der vier 500ns Zeitslots wechselnde Aktivität haben.
Trotzdem hab ich mal den Bustreiber zum Buffered Databus getauscht:
Wirkung: genau null.
Auch die dynamischen RAMs an D0 können es nicht sein, wenn man die entfernt, bleibt alles wie gehabt.
O.K. - du willst die harte Tour: alle Teilnehmer am Datenbus bis auf CPU und Grafikkontroller (auch schon getestet) entfernen:
Wirkung: genau nix. Ich werde irre...
-
Was ist bloß mit dem Ding passiert?!
Einen Vorteil hat dein Wahnsinn aber jetzt schon: Späterer IC-Tausch wird dank Sockeln überall leicht von der Hand gehen.
Der 6545 war ja auch defekt (Horizontale Linie auf dem Schirm, kein V-Signal mehr). Deshalb hab ich den getauscht. Danach ging ja ein bisserl was.
Aber je öfter man einschaltete, desto weniger Leben war im Board. Echt suspekt. Am Netzteil liegt es nicht, ich hab hier ein 4032-Board drangehängt, mit dem alles zigmal funktionierte.
-
Und wenn die CPU einfach einen "Knacks" hat? Läuft die in einem anderen Rechner ordentlich?
Andernfalls bleibt ja eigentlich nur noch ein Leiterbahnproblem oder eine schlechte Lötstelle. -
CPU habe ich gewechselt - gegen zwei neue, keine Änderung. Grafikcontroller entfernt, keine Änderung.
Die beiden Bustreiber, die den Buffered Databus bedienen, bekommen die korrekten Steuersignale.
Es sind alle 8 Datenleitungen betroffen.
Ich löte jetzt die zwei letzten verbliebenen ROMs aus...
-
Ich löte jetzt die zwei letzten verbliebenen ROMs aus...
Auf die setze ich jetzt auch. Hatte doch neulich einen 64er, der sich auch derbe tot gestellt hatte... da war's auch ein ROM.
-
die waren es nicht...
-
die waren es nicht...
Mein eingelöteter CPU Sockel ist es ned, oder?
-
Mein eingelöteter CPU Sockel ist es ned, oder?
Nein, keine Kurzschlüsse, keine Probleme. Wenn an einem Datenpin ein Kurzschluss wäre, dann wäre der Pegel ja permanent falsch...
-
In den letzten 500ns wird der Datenbus D0 (hier im Bild) vermutlich von einem weiteren Teilnehmer gewaltsam auf einen ungültigen Level gezogen.
Da der 8032 bei 1 MHz in einem Takt zwei Video-RAM Zugriffe für den CRTC tätigt (dabei wird ein Zeichen zwischengespeichert), könnte es evtl. auch an diesem (Odd-) Datenweg liegen. Hast Du mal UB6 und UB7 geprüft? Oder auch UC3 für die Erzeugung von READ ODD und WRITE ODD?
-
Alle 74er raus und auf den IC Tester
das wird sonst ein Spiel gegen Windmühlen vermute ich. Logikanalysator dran und schauen was da abläuft. Denke du hast einen sonst helfe ich gerne aus -
Alle 74er raus und auf den IC Tester
Nicht Dein Ernst, oder?
-
die beiden Bustreiber UB6 und UB7 sind einwandfrei, bedienen aber auch den buffered databus, der hat ja die Probleme nicht.
UC3, im Scaltplan ein 74LS42 ist bei mir ein 74LS138, macht, was er soll, wenn er denn angesprochen würde. Aber soweit kommt das Programm ja nicht.
Die beiden Bustreiber 74LS244 UB9 und UB10 habe ich mal entfernt, der Datenbusfehler bleibt. Jetzt sind nur noch ROM und CPU am Datenbus.
Die CPU setzt R/W# auf 0, während sie auf das ROM UD6 (Fxxx) zugreift... schreiben auf ein Eprom verpfuscht natürlich den Datenbus. Es gibt in diesem Konstrukt ja keinen Schutz gegen falschen Datenzugriff.
Ich werde jetzt mal ein rudimentäres 2532 ROM mit Resetvektor und Endlosschleife brennen, das müsste laufen.
-
UC3, im Scaltplan ein 74LS42 ist bei mir ein 74LS138
Hast du den passenden Plan?
-
Guten Tag
Anhand UC3 74LS138
würde dann eher auf das vorliegende Board die Schematic 8032081-08 passen,
-
Vielen Dank für den richtigen Plan! Ansonsten scheint sich das Ganze nicht groß zu unterscheiden.
Weiter im Text: ein komplettes Abkoppeln des buffered Databus hat nichts gebracht. Der Datenbus wird weiter zeitweilig doppelt verwendet. Also kann es nur was mit der CPU und dem ROM zu tun haben. Die CPU versucht auf das ROM zu schreiben.
Also Fehler im Programmablauf - vermutlich schreibt die CPU Sprungadressen in das RAM und springt dann in die Prärie...
Ich entferne alles Unnötige:
...und schreibe ein aufwändiges Testprogramm direkt am Hex-Editor.
Die Sprungvektoren darf man natürlich auch nicht vergessen:
Das Ganze in ein TMS2532 gebrannt:
Und schon kann man in aller Ruhe das Verhalten der Schaltung bewundern:
In diesem Fall ist Gelb das Chip select von ROM Fxxx und Lila ein Chip Select von ROM Bxxx (der vierte LDA Befehl) Die 10µS Pause oben sind der Rücksprung auf Adresse F000.
-
Das Programm wird erweitert: Zugriffe auf die komplette I/O, den Video-RAM (hätte ich schreiben und nicht lesen sollen - so hat's keinen Effekt...) und wichtig einmal Schreiben und Lesen im DRAM.
Die Chip Selects an ROM F:
Und DRAM Schreiben und Lesen einer "1":
Und einer "0" mit und ohne Datenbusaktivität:
-
Dazu fällt mir nix mehr ein, Wahnsinn!
Jetzt müsste ich nur verstehen, was da genau passiert- und warum?
Danke für deinen wirklich heftigen Einsatz!
-
Jetzt müsste ich nur verstehen, was da genau passiert- und warum?
Eigentlich ganz einfach:
ich habe ein rudimentäres 6502-Assemblerprogramm geschrieben, welches nacheinander Speicherzugriffe auf verschiedene Hardware auf dem CBM-Board durchführt:
ROM E, D, C, B, A und 9
Außerdem auf die drei Schnittstellenbausteine, den CRT-Controller und einen Schreib- und einen Lesezugriff auf das DRAM auf Adresse 0x0000.
Auf den Adressen FFFC und FFFD steht der Reset-Vektor, den die CPU nach einem Reset anspringt - den habe ich hier auf 0xF000, also die erste Adresse des ganz linken ROMs F gesetzt. Nach dem Reset springt die CPU also an den Anfang dieses ROMs und läuft in einer Dauerschleife die Schreiboperationen ab.
Wenn man jetzt auf das ROM-Chip-Select triggert, dann kann man alle übrigen Chip-Selects überprüfen und sehen, ob die Hardware an dieser Stelle funktioniert.
Das läuft hier einwandfrei, also folglich läuft die CPU, Die ROMs werden richtig angesprochen, ebenso die Schnittstellenbausteine und die Kommunikation zu den DRAMs funktioniert auch!
-
Herzlichen Dank für die detaillierte Ausführung.
Jetzt stellt sich die Frage: Was zum kompletten Henker ist denn dann defekt?!
-
Was zum kompletten Henker ist denn dann defekt?!
Nachdem ich jetzt ausschließen kann, dass die CPU mit den ROMs nicht klarkommt, vermute ich, es liegt an den Daten, die in den DRAMs abgelegt werden. Wenn die Zeropage nicht richtig funktioniert, dann springt die CPU - wenn sie einen indirekten Jump über die Zeropage machen will - in die Wüste...
Und wenn die Daten auf der Zeropage willkürlich gelesen werden, dann würde es auch erklären, warum das Teil immer anders und nicht nachvollziehbar startet...
