PET 2001-32N, Teil 4

RAM Test
RAM Test

Die Kiste läuft natürlich nicht stabil und stellt mein eigenes Durchhaltevermögen ganz schön auf die Probe. Wie schon im letzten Teil beschrieben, läuft Vossis ROM/RAM-Test fehlerfrei durch. Auch die anderen 16kB RAM sind in Ordnung, was mit den gekreuzten Leitungen festgestellt werden kann. Nur der Test für IEEE läuft auf Fehler. Es scheint auch noch der zweite PIA 6520 defekt zu sein. Mit den originalen ROMs startete der PET meistens bis ins BASIC, bleibt aber jetzt wieder, was ich mit dem Logic Analyzer feststelle, in einer Routine recht früh nach dem Start hängen.
Um Fehler durch schlechte Kontakte mit den weißen Sockeln auszuschließen, ersetze ich alle ROM-Sockel durch neue mit doppelten Kontakten. Die gepimpte Entlötstation  leistet hier wirklich gute Dienste und das Entlöten der insgesamt 120 Pins ist in kurzer Zeit erledigt.

Nach einigem Suchen stelle ich fest, dass ein Bit nicht richtig gesetzt wird. Seltsam ist, dass dieses Bit aus dem ROM richtig an der CPU ankommt. Auch am ROM ist das Bit korrekt, jedoch nicht am “Bufferd Data Bus”, an dem auch das RAM hängt. Entweder ist schon wieder ein 74LS244 Treiber defekt, oder es ist ein weiteres RAM defekt.

Fehlendes Bit

Am Logic Analyzer sieht man schön, dass das Bit 1 gekippt ist: es kommt $D9 anstatt $DB an:

$D9 = b11011001
$DB = b11011011

Die Leitungen des Datenbits D1 sind in Ordnung und können einfach mit dem Durchgangsprüfer getestet werden. Diese Problem hat mich noch etwas länger beschäftigt und ich musste die Analyse etwas auswerten und mir die komplette Routine, und nicht nur die kleine Schleife, ansehen. Mir kam der Adressbereich bei $E6xx bekannt vor und mir fiel es wie Schuppen von den Augen: der PET befindet sich im Interrupt, dessen Einsprung-Adresse bei $FFFE und $FFFF hinterlegt ist. Auch die kleine Schleife wurde wieder verlassen (was zuerst eine Fehlinterpretation von mir war) und ich konnte sogar einwandfrei den Rücksprung aus dem Interrupt tracen.

Interrupt nach Interrupt

Seltsam war aber, dass nach dem Verlassen des Interrupts sofort wieder in diesen gesprungen wurde. Die Messung am Interrupt-Eingang der CPU ergab dann auch, dass /IRQ immer 0 (low) war, sodass sofort wieder in den Interrupt gesprungen wurde. Nun bin ich erstmal auf der Suche, was die IRQ-Leitung auf Masse zieht und somit immer einen Interrupt auslöst.

Der Widerstand passt nicht

Zwischen VCC und GND messe ich einen Widerstand von ca. 304 Ohm, was viel zu wenig ist – es muss sich ein weiteres Bauteil verabschiedet haben, was mir somit den IRQ-Leitung Richtung GND zieht.

Mit dem Ohmmeter allein kann ich das defekte Bauteil nicht lokalisieren. Ich entlöte die drei IEEE Bustreiber und diverse Block-Kondensatoren sowie die drei 47µF Elkos ganz oben beim Kühler. Der Widerstand wird etwas besser, aber gut ist er immer noch nicht. Wenigstens wird die Interrupt-Leitung nicht mehr auf GND gezogen. Auch nicht, wenn ich die CPU wieder einstecke. Das ist schon mal gut.

Interrupt Signal an CPU

Als nächstes IC kommt der 6522 VIA wieder in seinen Sockel und zieht mir die Interrupt-Leitung auf GND! Das ist also der Verursacher. Der neue 6522 ist defekt!
Mit dem alten 6522 bekomme ich wieder einwandfreie Interrupts.
Irgendwie drehe ich mich im Kreis, wenn ich mich nicht mal auf die neuen Bauteile verlassen kann…