Posts by rayden

    Ich würde mal alle Bauteile/Lötstellen rund um den Q1, Q2 und Q3 unter Verdacht stellen. Das ist die +9V Schaltung für den Cassettenmotor, da ist auch eine Zenerdiode verbaut.

    Evtl. liegt dort ein Defekt vor und der 6510 kommt im Schaltvorgang irgendwie mit den +9V in Berührung.

    Wenn du eine Datassette anschliesst, wird der Motor beim Kaltstart bzw. Rest richtig an- und ausgeschaltet?


    Olli.

    Optisch sieht alles um Q1, Q2 und Q3 ok aus.

    Der Datasetten-Motor läuft bei Kaltstart und Reset ganz normal an und geht wieder aus. Es liegen an Pin C-3 der Datasette 6,35v bei laufendem Motor an.

    Ich habe auch alle Pins der CPU nochmal gemessen und jeweils einen Reset ausgeführt: der höchste Wert war 4,87V - also während Datasetten-Motorlaufen keine erhöhten Werte an den Pins.,


    Solange Bit3 von $01 nicht gesetzt ist, funktioniert alles, ich habe auf dem fraglichen Board auch die Demo El Dorado/Origo einwandfrei durchlaufen lassen. Aber wehe Bit3 wird in $01 gesetzt und ein CLC/SEC oder INC/DEC ausgeführt: dann hängt die CPU sofort (bzw. CPUs, denn auch die andere, vormals vollständig funktionierende, bis sie auf dem fraglichen Board war).


    Oder könnte die PLA (bzw. die RealPLA) da irgendwie mit reinspielen?


    Ich werde wohl die Tage mal die RealPLA auf einem anderen Board testen. Falls dann dort der Fehler nicht auftritt (und die dortige CPU heile bleibt), werde ich das fragliche Board rückbauen und doch als Ersatzteilspender nehmen.

    Anbei eine eine Tabelle mit den Spannungen an den einzelnen CPU Pins, links das defekte Board, rechts die funktionierende Test-Bench. Beide Messungen mit einer defekten CPU, sowie #$38 => STA $01 (und SEI und endless loop):

    Einzig auffällig finde ich PIN 10, 11, 16, 17, 18, 19, 20, 22, 23, 33, 34 da diese auf dem funktionierenden Board _mehr_ Spannung haben.

    Ich fange an, dieses Board zu hassen.

    Mitunter kommt ja bei den (den Prozessor-Port?) betreffenden Datenleitungen irgendwo ein wenig zuviel Spannung an oder so?

    Das war natürlich der einfachste jedermanns Gedanke, a shame dass du da noch nichts evaluiert/gemessen hast. ;)

    Eigentlich nur die Spannungen von einem nicht defekten Vergleichsboard mit dem in dem defekten SOckel vergleichen du brauchst.


    Gut, sollte es nicht die Versorgungsspannung sein, sondern nur ganz kurze Spitzen an anderen (Datenleitungs-) Pins, dann ist das mit einem lahmen Messgerät evtl. nicht (gut) messbar.

    Ich bin da ein wenig unbedarft und eine kleine Schissbuchse:

    Also mit einem Multimeter (auf Volt) jeden einzelnen der 40 Federkontakte (ok, 39, weil 21 = GND) durchmessen und dasselbe anschliessend mit der funktionierenden Test-Bench - jeweils ohne CPU?


    Und da kann ich durch das Reinstecken der Messspitze - insbes. bei der Test-Bench - auch nichts kaputt machen? (keine Kurzschlüsse produzieren vorausgesetzt)

    Ja, aber was sie -die beiden CPUs- zerstört hat kann ja ggf. auch von gesockeltem Zeugs kommen (eher nicht, aber zum Test halt 'mal..). Welches man 'mal eben tauschen könnte. Aber dann bestünde natürlich die Gefahr dass immernoch, die dann dritte CPU, draufginge.

    An sich korrekt; allerdings sind CPUs bei mir Mangelware und ich möchte nicht erst alle gesockelten ICs tauschen und dann mit einer dritten, funktionierenden CPU auf gut Glück nochmal testen und diese dann auch mitunter kaputt machen - Zumindest bevor ich nicht einigermassen weiss, was der Defekt ist.


    Da zwei CPUs ja nun defekt sind, ist es ja etwas, was reproduzierbar ist - und das beide plötzlich denselben, äusserst merkwürdigen Defekt aufweisen, wäre ein komischer Zufall ;)


    Mitunter kommt ja bei den (den Prozessor-Port?) betreffenden Datenleitungen irgendwo ein wenig zuviel Spannung an oder so?


    Anbei endlich mal ein paar Bilderkes von dem Dingen:

    Tausch doch 'mal alle gesockelten ICs aus, um zu sehen ob's Zeuch von einer derer zustande kommt.. .:) Falls noch nich' getestet.

    Definitiv nein: Der Fehler wandert mit der CPU mit von besagtem 250425 in die Test-Bench. Also zwei verschiedene Boards :)


    Nachtrag: Flackern tun die Zeichen $#2C, $#2D, $#2E, $#3C, $#3D, $#3E - aber nur, wenn im Action Replay Monitor das Scrollen angehalten wird.


    Doppel-Nachtrag: Beide defekten CPUs zeigen dasselbe Flackern der Zeichen.

    CommieSurfer: Ich kann Dir gerne bei Gelegenheit eine der defekten CPUs geben :)

    $01 ist vorher default, also #$37

    #$31 und #$32 läuft durch ohne crash.

    #$38 stürzt reproduzierbar ab.


    Interessanter Zusatzeffekt:

    Im Freeze-Menu vom Action Replay flickert, wenn der Fehler vorher auftrat (und ein Freezen möglich ist, denn manchmal gehts beim Fehler und manchmal nicht) und man beim disassemblieren scrollt und das Scrollen anhält, das Zeichen $2D (Bindestrich) und $2E (Punkt).

    Edit: Nicht nur im Freeze, sondern auch direkt im Maschinensprachemonitor, also einschalten => Fastload => F8 Monitor.


    Es sorgt für weitere graue Haare...

    Char-ROM lässt sich auslesen (LDA#$33 STA$01) und ich kann es kopieren und nutzen (z.B. nach $2000 und dann #$18 => $D018).


    Bereits die folgenden paar Zeilen führen zu einem Hänger, ohne das $0401 inkrementiert wird, d.h. mit dem CLC ist Schluss:

    Code
    1. SEI
    2. LDA#$38
    3. STA$01
    4. CLC
    5. INC$0401
    6. NOP
    7. JMP *-3

    Wenn man dann freezt, ist PC $FFFF und alle Flags (NV-BDIZC) sind 1. Richtig, richtig komisch.


    Es scheint, als wenn bei #$38 => $01 jeglicher Operator, welcher Flags setzt (carry, zero, etc.) die CPU total aus dem Tritt bringt.


    Selbiges gilt für #$34 => $01.

    Mit #$36, #$36 und #$37 wird $0401 inkrementiert und es geht fröhlich weiter bis zum endlos loop.


    Die Tests habe ich alle mit den defekten CPUs in der Test-Bench gemacht.

    Argh, zu früh gefreut: Das Board macht CPUs halbwegs kaputt...


    Es hängt nun ein EF3 und ein SD2IEC (eingelötet) dran.

    Einige Programme funktionieren, einige nicht - obwohl sie alle funktionieren sollten. (Onefiler, also nix von wegen spezielle Loader oder so)

    Es wird einfach nicht gestartet, RUN und es hängt.


    CPU aus dem 250425 in die Test-Bench C64 gesteckt: gleiches Ergebnis. Der Fehler wandert mit und alle Programme, die nicht funktionieren, funktionieren auch auf der Test-Bench nicht.


    Andere CPU in die Test-Bench reingesteckt und _alle_ getesteten Programme funktionieren nun.


    OK, also die funktionierende CPU genommen, rein in das fragliche 250425 und schon wieder laufen einige (dieselben) Programm nicht.

    Die CPU wieder zurück in die Test-Bench C64 und auch hier laufen nun die betreffenden Programme nicht.


    I.d.R hängt es bei den nicht funktionierenden Programmen bereits in der decrunch-Routine.

    Wenn man dann freezt, so steht der PC auf $FFFF, AKKU und YR haben plötzlich zufällige Werte, lediglich XR hat einen erwarteten Wert.


    Das ganze habe ich dann mit ein paar Zeilen Assembler-Code näher analysiert:

    Sobald im Prozessor-Port $0001 BIT 3 (Datasette output signal level) gesetzt wird (also z.B. LDA$#38 STA$01) hängt die Kiste (also sowohl das 250425, als auch die Test-Bench C64) mit der defekten CPU.


    SD2IEC zieht sich den Strom von Pin2 am Tapeport, falls dies wichtig sein sollte.


    Da ich es bislang soweit hergerichtet habe, möchte ich auf der Zielgraden jetzt nicht aufgeben und es doch als Ersatzteilspender umfunktionieren...


    Ich habe keine Ahnung, was ich an dem Mainboard testen, tauschen, messen, analysieren müsste.

    Hat jemand einen Tip? "Aus dem Fenster werfen" ist mir auch schon in den Sinn gekommen ;)

    Der Prozessor ist zwar noch heiß, aber in dem C64 Reloaded blinkt nur die Diagnose LED, wenn ich den VIC da reinstecke.


    Ich lege das Board nun erst einmal beiseite.

    Erst rund 10 Stunden Reparatur und nun noch der VIC hin .... Da muß der Frust erst einmal verpuffen.

    Wenn derselbe VIC vorher im Reloaded (MK2?) funktioniert hat, dann kann er durchaus kaputt sein.


    Aber die Reloaded MK2 Diagnose-LED blinkt auch bei einigen 6569 Versionen, wenn diese nicht zuverlässig erkannt werden.

    Sofern auf dem Reloaded MK2 nicht die aktuellste Firmware drauf ist, könnte eine Aktualisierung Abhilfe schaffen: http://wiki.icomp.de/wiki/C64_…e#Firmware_Aktualisierung


    (Bei meinem Reloaded MK2 habe ich mich kürzlich gewundert, dass ein paar 6569 nicht erkannt wurden und die Diagnose-LED nur am Blinken war - ich dachte erst, dass das Board kaputt sei, weil die VICs in anderen Boards einwandfrei funktionierten. Nachdem ich die Firmware aktualisiert hatte, wurden die VICs dann auch endlich erkannt)

    So nutzlos ist der Deckel nicht: Die Lasche leitet die Hitze vom VIC ab - Wärmeleitpaste zwischen VIC und Lasche vorausgesetzt.

    Nicht so im 425er; da ist der Deckel einfach nur ein Blech, das den ganzen VIC Bereich abdeckt. Der ist nicht wie z.B. bei 407er Boards mit dem VIC verbunden.

    Hm, das kann ich so nicht bestätigen: alle meine 425er haben einen "überspannenden" (wie ein flaches "U") Blechdeckel, bei welchem eine Lasche mit Wärmeleitpaste auf den VIC drückt. Die sieht so aus Schnellreparatur ASSY 250425, 251470-01 Rev. A

    Danke, aber wie das Signal für den 2. SID an dem Modulator angschlossen wird, wurde spätestens mit #139 geklärt :)


    Es geht mir lediglich noch um die GND Verbindung von FGPASID zum GND-Audio am Modulator-Ersatz.

    Hierfür möchte ich ein Kabel nutzen, und suche nach dem "richtigen" Stecker, ob das ein 2-Pin JST mit 1,0 oder 1,25mm Rastermass ist.

    außer das ich den nutzlosen VIC-Deckel abmachen musste.

    So nutzlos ist der Deckel nicht: Die Lasche leitet die Hitze vom VIC ab - Wärmeleitpaste zwischen VIC und Lasche vorausgesetzt.

    Mitunter ist der Rechner aufgrund eines Hitze-Problems hängen geblieben?


    Ich würde einen kleinen Kühler (z.B. von ausgedienter PC-Grafikkarte oder ein Raspberry-Kühler) draufmachen und nochmal einen Dauertest machen. Erst, wenn der Rechner dann erneut einfriert, würde ich an die Fehlersuche gehen.

    Um GNDA und GND zu verbinden, würde ich gerne einen passenden Stecker nutzen.

    Warum?

    Wenn ich mich recht entsinne, dann ist das doch ein einfacher Lötjumper, einfach die zwei Lötpads mit Lötzinn verbinden und fertig.


    Man kann natürlich auch eine auf einer Seite etwas enger gebogene Stiftleiste anlöten und dann einen Jumper Brücke (2,54) drauf stecken.

    Nein, es ist kein Lötjumper. Ich möchte GNDA vom FPGASID mit GND vom Modulator-Ersatz verbinden - oder bin ich da auf dem Holzweg? :)


    Lötjumper auf Modulator-Ersatz wäre für die Brückung nach Audio-L.

    Um GNDA und GND zu verbinden, würde ich gerne einen passenden Stecker nutzen. In dem mitgelieferten 2-Pin Stecker ist ja nur eine Seite belegt.

    Wie heisst dieses Steckerformat? Ist das so ein Mini/Micro JST/SH mit Rastermass von 1,0mm?

    Da es thematisch passt, hier die Bilder von meinen Quattro-SID Gerät:

    Frage zur Compressed-Tastatur, Condensed-Tastatur oder auch Semiblock-Tastatur aka VC20

    Das Dingen ist 1998 von meinem besten Freund Cyclone/Crest/Haujobb gebaut worden.

    Als SID-Basisadressen hatten wir $D400 (L), $D500 (R), $D600 (L) und $D700 (R) benutzt. Die paar Quattro-SID-Tunes, welche ich gemacht hatte, sind bei Deep-SID im exotic Ordner zu finden.

    Bei Fragen: Fragen. Auf Wunsch kann ich auch noch Detail-Fotos machen von der Platine (Dann aber bitte am besten in einen eigenen Thread "Quattro-SID 250407" oder so auslagern.)

    andi6510 Ich habe mal eine Frage zum FPGASID in Kombination mit Verwendung des S-Video Mod von AuSPuFF²:

    Ich möchte den 2. SID nicht auf Pin 7 der DIN-Buchse haben, sondern das Stereo-Signal ausschliesslich via Klinkenbuchs herausführen.

    Reicht es hierfür, wenn ich das Signal des 2. SID auf der S-Video-Platine auf Audio Right lege und die Lötbrücke nach L schliesse, sodass der 1. SID auf links liegt?

    Also 1. SID links, 2. SID rechts.

    Oder interpretiere ich das falsch? Oder muss ich gar noch etwas anderes berücksichtigen, z.B, GND nach GND oder so?