250407 Rev. B - Black Screen

So, habe mal im Wahn XP aktiviert und den Logic Analyzer ausprobiert.

Dachte erst, da tut sich nichts. Aber 250 MHz sind wohl zu viel bzw. wenig, jedenfalls nicht sehr anschaulich.

RESET als Trigger ist wohl auch eher ungünstig. Zumal die steigende Flanke ja auch beim Einschalten erstmal kommt.

Deswegen habe ich ab da auch "continous sampling" verwendet und "phi0" als Trigger.

Bei 1 MHz Sampling Rate tut sich schon mehr bzw. man sieht überhaupt was.

Bild 3 mal noch mit AEC und RDY (@ 5 MHz).

Und Nr.4 mit eingestecktem Deadtest (@ 5 MHz).

War jetzt erstmal nur so hingefummelt. Die Bilder super umständlich über die Druckfunktion erstellt und von XPS in PDF gewandelt und per Screenshot in jpg. Geht sicher einfacher und in Farbe mit der Software. Aber war jetzt auch nur der erste Funktionstest.

Also die Leitungen hängen augenscheinlich nicht. Gemessen am KERNAL-Sockel (die Klemmen sind zu groß für direkt an den Pins der Chips) bzw. AEC und RDY an U27 (4066). Ob sich am Bild was getan hat, kann ich nicht sagen, der XP-Rechner hängt am gleichen Monitor wie das Board.

Ich würde mal die "Boot"-Sequenz der CPU kontrollieren. Deshalb hatte ich zuerst RESET als Trigger. Sobald ich dahintergesteigen bin, wie ich das am besten anstöpsele. Einfach um zu sehen, ob die CPU (ohne KERNAL) was tut und wie weit sie kommt.

Ansonsten könnte man auch die Mutliplexer Ein- und Ausgänge in Augenschein nehmen, ob da was auffällt.

Oder gibt es offensichtlich sinnvollere Dinge zu prüfen? Jetzt, wo das Ding einmal draußen ist.

Ein bisschen rumprobiert und ich habe eine Einstellung gefunden, wo ich reproduzierbar den Bootvorgang der CPU erkennen kann. Ab Takt Nr. 6 wird da der RESET-Vektor ($FFFC, $FFFD) abgefragt. Danach geht es - mangels KERNAL und Modul - erwartungsgemäß ins Leere.

Nachdem ich mir nun endlich einen NOP-Generator gebastelt habe, läuft dann auch fleißig ein $EA über den Datenbus. NOP steckt im KERNAL-Sockel und abgegriffen wird am Expansionsport. Leider habe ich nur 16 Kanäle. Deswegen Datenbus und Adressbus getrennt. Auf letzterem zählt es aber auch erwartungsgemäß die Adressen durch. Habe ich jetzt nicht genauer überprüft, aber anhand der zyklischen Bewegungen sieht es zumindest sehr danach aus.

CPU läuft also und kann mit den Bus-Leitungen hantieren. Blockiert ist da soweit (für mich) erkennbar nichts.

Dann werde ich mal noch die Chip Selects versuchen anzustöpseln. Wenn da alles tutti ist, kommt ja eigentlich nur noch der RAM-Zugriff in Frage.

Ja, $FFFF war dieses "Leere". Ich hab dem "ohne alles" Zustand nicht viel Beachtung geschenkt. War froh, dass ich alle Klemmen dran bekommen habe und noch was gemessen wurde. Es lief dann halt so vor sich hin, was mir in dem Moment schon genügte. Mit NOPs auf dem Datenbus passiert ja das Erwartete.

Die Chip Selects selektieren die Chips. Ob wie vorgesehen, weiß ich zwar nicht, aber es passiert was.

Dann würde ich die ROMs doch erstmal drin lassen. Sollten die defekt sein, dürfte das per Diagnose feststellbar sein. Da nichts blockiert, müsste man auch mit den beiden am Bus den Deadtest zum Laufen bekommen.

Damit wäre ich dann bei den Multiplexern als erste Kandidaten. Da jetzt irgendwie Ein- und Ausgänge zu analysieren ist mir ehrlich gesagt zu fummelig. Also nicht das Analysieren, sondern das Anbringen der Leitungen. Und bevor ich einen neuen Kabelsatz mit kleineren Klemmen gebastelt habe, sind die zwei dann auch ausgelötet.

Wohl wahr. Dann sind sie aber garantiert auch in Ordnung.

Also:

Zwischenstand:

Es sind nicht die Multiplexer.

Ich hab dann weiter getauscht, was (halbwegs) mit der Adressierung zu tun hat. Es sind auch nicht:

U26 (LS373)

U14(LS258)

U16(4066)

U8(7406)

U27(LS08)

Alles mit Neuteilen ersetzt und keinerlei Änderung! Nichts. Immer nur hellrot und braun, sorry, orange. Das kann doch eigentlich gar nicht sein. Wenn doch nach einem Tausche wenigstens kein Bild gekommen wäre.

Dann dachte ich mir so, vielleicht doch irgendwie /CS vom VIC? Also wär U15(LS139) der nächste Kandidat gewesen.

Doch dann stieß ich beim Weglegen des Schaltplans an das Modul und das Bild flackerte. War noch angeschaltet und URT war gerade "aktiv". Farben waren die, was ich oben schon beschrieben hatte: hellgrau und blau zwischen all dem brau..range. Beim Klopfen auf das Modul konnte man "Veränderungen" erzeugen und einmal blieb auch hellgrau. Sah auf jeden Fall nach Wackelkontakt aus.

Also Modul raus aus dem Schacht und Auge rein in den Schacht. Ja. Klar. Zwei verbogene Kontakte. Klassich getrollt!

Sieht zwar so aus, als wär das schon vor langer Zeit passiert, aber ich hätte vermutlich trotzdem erstmal alles ausgelötet, nur diese Buchse nicht.

Nun bin ich stark am Überlegen, ob ich mir das Rausfummeln antue oder gleich eine neue Buchse einbaue. Aber über 40 kontakte und Kleber...

Vorher werde ich mal noch ein nicht-PLAnkton raussuchen. Es sieht nämlich danach aus, als wären das Kontakt 1 und B, die da zusammengequetscht wurden. Das wären GND und ROMH. ROMH geht nur zum PLA. Das entsprechende Bein könnte man rausbiegen und somit diesen unerwünschten Kontakt mit GND aus der Rechnung nehmen.

Aber jetzt erstmal kurz beruhigen.

Zitat von kinzi

Bei einem "normalen" PLA wäre ich geneigt zu sagen, das ist dem egal.

Du meinst, es passiert nichts, wenn ROMH dauerhaft mit GND verbunden ist? Wo es doch eine "low active" Leitung ist.

Vielleicht macht es ja dem PLA nichts, aber dem Modul vielleicht?

Aber dann dürfte das Wechseln der Buchse ja auch kaum was ändern...

Ich weiß jetzt vor Schreck gar nicht, was ich da für ein EPROM im Modul hab. Ist aber auf jeden Fall eine Commodore Universal-8k/16k-Platine.

Na ja, wird wohl so oder auf eine länger Entlötaktion hinauslaufen.

Ok, hat nichts gebracht. Mit einem echten PLA übrigens Black Screen, keine Farbe!

Die Kontakte konnte ich auch einigermaßen rausziehen, so dass sie sich nicht mehr berühren. Ging leichter als gedacht, es muss nur jemand die Lampe halten. Da das doppelte Federn sind, waren und sind aber noch alle Kontakte zum Modul vorhanden. Jetzt sitzt es auch gerade im Schacht. Komisch, ja?

Tja, was dann jetzt? Ein RAM nach dem anderen, oder?

Ich weiß genau, am Ende ist es doch ein ROM oder irgendwo ist ein Haarriss...

Nein, aber Diagmodul, wo die Leitungen alle gejumpert (und in der DT-Konfiguration offen) sind. Die Idee kam mir auch.

Super Zaxxon hatte ich ja am Anfang schon probiert.

Ich glaube fast, da war (auch) die RESET-Leitung betroffen, wenn ein Modul drin steckte. Oder es gab einen kurzen Spannungseinbruch, weil ja +5V direkt danbeben liegt und die wurde(n) beim Wackeln kurz gebrückt oder so. Es ist jedenfalls weiterhin alles so, wie es schon immer war.

Mal sehen. Morgen nachmittag wäre vermutlich wieder etwas Zeit zum Entlöten.

Mal angenommen, es ist das RAM. Wenn er eine 8 (b00001000) in den Akku bekommt, dann dürfte ja Bit 3 in Ordnung sein, zumindest gesetzt und zurückgelesen werden können. Wenn statt 15 (b00001111) nun eine hellrote 10 (00001010) im Akku landet, könnten (müssten?) Bit 0 und Bit 2 den Dienst verweigern. Sehe ich das halbwegs richtig? Dann könnte sich ja die Farbe zumindest ändern und/oder der Programmablauf kommt etwas weiter, wenn ich erstmal ein RAM davon tausche.

Unter der Annahme, die Adressierung funktioniert fehlerlos und es sind keinere weiteren obskuren Fehler vorhanden natürlich.

Wird sicher darauf hinauslaufen, dass ich wenigstens eine komplette Bank sockele, schon aus optischen GRünden. Aber so rein technisch gesehen...?

Zitat von kinzi

Denn wenn Bit 0 und 2 "blockiert" würden, würden die Opcodes aus dem ROM auch verstümmelt

Der Bus ist ja frei. Ich meine die für D0 und D2 zuständigen RAMs. Das LDA schreibt ja den entsprechenden in den Akkumulator und das STA $D020 den Wert aus dem Akkumulator in den VIC. Das Schreiben in den Akku hat keine Rückmeldung, dementsprechend auch keinen Fehler, so dass der nächste Befehl ausgeführt wird. Wenn nun die CPU beim STA den Wert aus $030C liest, nimmt sie das, was ihr vom RAM geliefert wird, und das ist bei defekten D0 und D2 (angenommen: Dauer-Zero) eben bxxxxx0x0, egal was vorher reingeschreiben wurde.

Das macht bei Orange = $08 = b00001000 keinen Unterschied. Beim rückwärts gezählten Hellgrau = $255 = b11111111 aber eben schon, denn das wäre ja dann stattdessen b11111010 = $FA = Hellrot, die dann an den VIC übermittelt werden.

Was auch immer danach kommt, da hängt es dann.

Zitat von kinzi

Sind es eigentlich µTs?

Ich weiß ja, dass du die siehst, wo auch immer du hinguckst, aber das war vorsorglich im ersten Post schon geklärt. Wären es welche, würde ich die natürlich jetzt nicht verdächtigen. Logisch!