PET 2001-8C Assembly 320008 hängt beim "Garbage screen"

1. Ist der Motor der eingebauten Datasette bei entriegelten Tasten (= nichts gedrückt) auch im Dauerlauf, während die Zufallszeichen am Schirm sind? Oder steht der selbige still?

2. ist - wenigstens schemenhaft angedeutet - der Anschein eines mit 2 Hz blinkenden Cursor da zu erkennen, wo er normalerweise zu sehen ist? (unter dem READY.)

3. Fängt der Motor an zu drehen, wenn man probehalber PLAY drückt? und hört wieder auf zu drehen wenn man die Play - Taste wieder entriegelt /ausschaltet?

Falls der Motor nicht auf das Play-Drücken reagiert, wäre m.E. ein Defekt der RESET-Schaltung oder des Prozessor 6502 möglich.

Wie sieht die RESET-Leitung aus, hast du Möglichkeiten deren Pegel zu bestimmen?
Zumindest den "statischen" Pegel. Fehlermöglichkeiten: a) "stuck low" b) "no pulse"

(Die Möglichkeit b) ist prinzipiell auch ohne teures Oszilloskop testbar, indem man den Stecker eines hochohmigen Ohrhörers (Piezo, > 100kOhm) mit dem Spitzenkontakt an die Resetleitung hält, mit dem Zeigefinger eine Art Massekontakt bereitstellt indem man den Ringkontakt des Klinkensteckers berührt.
Wenn man dann mit der freien Hand den evtl. noch anzubauenden Reset-Taster drückt, müsste ein deutliches Klicken im Ohrhörer zu hören sein. Bei diesen Tests sollte man tunlichst nicht irgendwohin abrutschen und einen Kurzschluß verursachen auf dem Board.)

----
Nach längerem Lesen des VcFed-Threads denke ich, ähneln sich die Fehlerbilder doch sehr stark. Die Vermutung geht in Richtung defektes ROM.

Am User-Port (?) des PET so wie ich ihn kenne gibt es auch einen Diagnostic-Eingang, an dem man einen Taster (gegen GND) anschließen kann. Hält man diesen gedrückt während dem Einschalten bzw. RESET, springt das Kernel-ROM in den TIM-Monitor (Maschinensprachmonitor). Meines Wissens geschieht das vor dem Anspringen des Basic-ROM. es gibt so eine schwache Chance, dass ein defektes Basic-ROM sich so "umgehen" lässt. Wenn statt des Basic- das Kernel-ROM selber defekt ist, vermindert sich diese Chance.

Es hängt aber von der Version des PET ab bzw. welche Firmware drin ist, weiß nicht ob schon die ganz alten den Diagnostic-Eingang ausgewertet haben.

----
der Test mit dem Motor soll eine Einschätzung erlauben, wie weit die Initialisierung des Rechners "gediehen" ist und ob er auf äussere Signale reagieren kann. Das ist hier nun nicht der Fall, denn sonst müsste beim Entriegeln der Play-Taste die Interrupt-Routine den Motor-Pin abstellen.

----
Weitere Test-Möglichkeiten, ohne Ersatz-ROMs zu beschaffen:
* PIA 6520 - Bausteine entfernen, evtl. zusätzlich auch VIA 6522 (bin unsicher, wieweit das die natürliche Funktion beeinträchtigt) --> würde Defekt beheben, falls Baustein die Datenleitungen blockiert

* Die Chip-Select-Leitungen vom Decoder 74154 zu den Roms verfolgen und auf Durchgängigkeit messen (dabei auf Möglichkeit zu hoher Meßströme und oder statischer Entladung achten; ich verwendete dafür früher meist ein Zeiger-Multimeter mit schwacher Batterie ~ 0,8 Volt im Meßbereich "niederohmig"--> dann fließt besonders wenig Meßstrom)

* sofern untereinander kompatibel, RAMs die Plätze tauschen lassen. Möglichst so, dass in die erweiterte Zeropage 0 .. $03FF Bausteine kommen die vorher da nicht saßen.

Edit: sorry, das hatte ich übersehen, dass du schon sehr viel gestestet hattest.

Zitat von mantillo

Bei allen gesockelten ICs Phi / CLK - Spannung (mit Multimeter ~1.86V) gemessen. => Ist OK, oder?

Kommt mir relativ normal vor, wenn 4 Volt der ~ High-Pegel ist und ca. 50% Duty-Cycle -> 2 Volt zu erwarten, dein Meßwert liegt lediglich 7% darunter. NMOS geht nicht bis auf die vollen 5 Volt rail-to-rail wie es CMOS täte.

Zitat von mantillo

Wenn ich beide PIAs und alle Arbeitsspeicher-RAMs, bis auf die "ersten" 4 (I1, I2, J1 und J2) herausnehme, ändert das nichts. => Schade!

Ja, finde ich auch schade.
Was du auch noch tun kannst, ist, das Fehlerbild fotografieren und vergleichen ob sich was ändert wenn das Kernel-ROM (bzw. die Kernel-ROMS, wenn das 2 oder mehr Bausteine verteilt ist, kenne mich mit Uralt-PET nicht so aus) gänzlich entfernt ist.

auch sehenswert:
http://www.cbmhardware.de/show…%20ROM%20und%206550%20RAM

EDIT:
Da die Video-Logik ganz offensichtlich "arbeitet" und das Video-ROM offensichtlich intakt ist, denn sonst wären keine Zeichen identifizierbar (R,S,T,Q .. A,E,P,Y ..) kommt mir noch folgende verwegene Idee:

Falls das Character-Generator-ROM das du oben "Video-ROM" genannt hast, ein 2 KB großes 6540 ist und der Kernel aus 2 dazu pinkompatiblen weiteren 6540 besteht,
... könnte man probehalber das Character-Generator-ROM aus dem Sockel entfernen und sicher beiseitelegen
und dann
... die beiden Kernel-ROMs jeweils einzeln probehalber als Character-Generator-ROMs "temporär" einsetzen.
So müsste sich zumindest grob abschätzen lassen, ob größere "eintönige" Farbflächen, oder feingrieselige Bitmap-Strukturen sich ergeben. In ersterem Fall ist das ROM stärker beschädigt (Datenleitungen verklemmt) als in letzterem (evtl. nur einzelne Bitfehler oder gar intakt).

Das wäre eine primitive Möglichkeit das Kernel-ROM irgendwie "auszulesen" auch ohne Eprom-Brenner / Ersatzrechner / Adaptersockel.

Unter der Annahme, dass ähnliche Bausteine mit ähnlichem Herstellungsdatum sich auch in der Haltbarkeit ähneln, spricht ein intaktes "Video_ROM" allerdings dafür, dass auch die Kernel-ROMs noch intakt sind (Spekulation).

Wäre nett, wenn du von diesem " Zufallsbild" wenn eines der Kernel-Roms im Steckplatz des Character-Generator-ROMs steckt, noch ein Foto hättest (dann lerne ich noch was..)

* Andere User nennen das Durchmessen oft "Durchklingeln" und schreiben nicht dazu, mit welchem Meßgerät... (digital/analog)... habe nur geschrieben womit ich das gemacht habe.

Beim oben abgebildeten Bildschirm fiel mir noch folgendes auf:

Das Bit 7 des Video-RAM alterniert sehr exakt alle 64 Zeichen; nach 128 Zeichen ist wieder der "Originalzustand" erreicht. Dadurch folgen auf je 64 "normale" Zeichen (helle Schrift auf dunkel) dann 64 invertierte Zeichen (Negativdarstellung/Attribut). Kleine Ausnahmen vorhanden (Einsprengsel).

Wenn die Zeichen invertiert sind, bit 7 = 1 , dominiert eindeutig der Zeichencode 110 = hex. $6E bei dem die Mehrzahl der Bits gesetzt ist.

Wenn nicht invertiert, bit 7 = 0, sind Q, U wie es scheint merklich häufiger als der Durchschnitt (Codes 17 und 21 = $11 und $15).

Der Code $11, besagter "Q-Bildschirmcode", ist nun die genaue 7bittige binäre Negation zu $6E. Ergänzt sich mit $6E zu $7F.
$6E stellt sich bei den Inversen viel häufiger ein als Q bei den nicht-Inversen. Bit 7 zieht die anderen "mit"?

Das kann natürlich eine interne "Vorzugsrichtung" der RAMs bezeichnen, dass die nach dem Einschalten (Reset) zufälligen Bits in beetimmten Bereichen in eine bestimmte Richtung fallen wollen. Um das zu beurteilen müsste man wissen wie ein zufälliger Garbage-Screen auf echter Hardware typischerweise aussieht. Aber es fiel mir halt auf.

Wenn man nichts über das Innenleben der RAMs weiß, würde man fast annehmen, dass bit 6 der Video-Logik-Adresse VA6 auf VD7 (und weitere Datenbits) "einstreut".

Nachtrag (ausnahmsweise nicht als Edit):

wenn du einen (auch improvisierten) Reset-Taster anbauen könntest - Bauanleitung sollte sich finden - , ließe sich mehr ausprobieren; auch testen, ob der Impuls bis zur CPU durchkommt. (z.B: Taster gedrückt halten - > mit Multimeter am CPU-Eingang messen -> geht solange auf LOW)

Beim CBM 3008 Schaltbild ist ein Timer NE 555 mit paar sehr hochohmigen Widerständen eingezeichnet, der den RESET erzeugt. Nachgeschaltet sind 2 Inverterbausteine 7407 (oder 74S04 o.s.ä.) und ein 7417. Da wären Ansatzpunkte zu überprüfen ob das in Ordnung ist (bei den Invertern kann man einfach messen, dass Pin 1 und 2 sowie alle nachfolgenden jeweils entgegengesetzten Pegel haben müssen). Ob das Netzteil des Uralt-PET ein Power-Good-Signal vom Netzteil braucht um den Reset hinzukriegen, weiss ich allerdings nicht.