Hello, Guest the thread was called2.4k times and contains 56 replays

last post from deluxeF at the

C64 erworben, aber leider kein Bild

  • Aber das könnte man ja durch die Verwendungen eines "klassischen" Dead-Tests ausschließen.

    Das hat geholfen!


    Der ungepatchte DEAD Test zeigt ZERO PAGE = BAD


    Die Ausgabe vom ungepatchen DIAG bleibt allerdings wie zuvor und zeigt ZERO PAGE = OK

    Da die ZP in der CPU liegt habe ich diese jetzt mal in mein Referenz Board gesetzt und der Fehler wandert mit :thumbsup:


    Somit waren effektiv der RAM auf U11 und die CPU defekt.


    Der DIAG Test läuft mit meiner eigenen CPU jetzt schon eine Weile ohne Fehler:



    Ich setze die alte CPU wieder in den Sockel und überlasse es dem Eigentümer deluxeF ob er eine neue CPU besorgen und einsetzen möchte.

    Ich habe es bisher nicht geschafft den Cevi mit der Ursprünglichen CPU abstürzen zu lassen - Heute morgen liefen schon einige Demo's von CSDb :D


    Ich glaube der Cevi macht es noch eine Weile, auch mit der Ursprungs CPU und ich zähle in ab jetzt zu den "geretteten" Cevi's ^^

    Zumal ja sogar die Datasetten Steuerung problemlos funktioniert :huh:


    Danke fürs mitlesen.



    kinzi: Einfach als Feedback - Dieser spezielle Fehler lässt sich mit dem gepatchten DEAD Test leider nicht finden.

  • Danke für den Hinweis.

    kinzi: Einfach als Feedback - Dieser spezielle Fehler lässt sich mit dem gepatchten DEAD Test leider nicht finden.

    Das ist dann aber ein SEHR spezieller CPU-Fehler ... am RAM-Test selbst wurde ja nichts verändert. Habe ich das richtig zusammengelesen:

    • Der originale DEAD TEST bringt "ZP-Fehler".
    • Der gepatchte DEAD TEST blinkt 1x?
    • Der Fehler wandert definitiv mit der CPU mit und(!) zurück?

    Es kann eigentlich nur damit zu tun haben, dass die I/O-Port-Logik der CPU defekt ist und Zugriffe auf $0000/$0001 außen sichtbar sind. Oder eines der Index-Register ist kaputt und es wird statt bei $0002 bei $0000/$0001 mit dem Initial RAM Test begonnen. Oder irgend sowas, müsste mir erst wieder den Code anschauen.

    Blinken denn die LEDs am Tape-Port richtig?

    Da die ZP in der CPU liegt

    Die ZeroPage liegt wie allen anderen Pages im RAM.


    "ZERO PAGE BAD" heißt, dass der "Zero Page-TEST" fehlgeschlagen ist, nicht (zwingend) dass die Zero Page im RAM defekt ist.

    "Steve Jobs hat User hervorgebracht, Jack Tramiel Experten." - Quelle unbekannt.


    Mein Herr, ich teile Ihre Meinung nicht, aber ich würde mein Leben dafür einsetzen, dass Sie sie äußern dürfen." - Voltaire.


    "Diskutiere nie mit einem Idioten - er zieht dich auf sein Niveau hinunter und schlägt dich dort mit seiner Erfahrung!" - Volksweisheit.

  • Zusatzfrage:


    Läuft mit der dubiosen CPU das DIAG 586220 durch, insbesondere RAM- und PLA-Test?

    "Steve Jobs hat User hervorgebracht, Jack Tramiel Experten." - Quelle unbekannt.


    Mein Herr, ich teile Ihre Meinung nicht, aber ich würde mein Leben dafür einsetzen, dass Sie sie äußern dürfen." - Voltaire.


    "Diskutiere nie mit einem Idioten - er zieht dich auf sein Niveau hinunter und schlägt dich dort mit seiner Erfahrung!" - Volksweisheit.

  • Danke für den Hinweis.

    Das ist dann aber ein SEHR spezieller CPU-Fehler ... am RAM-Test selbst wurde ja nichts verändert. Habe ich das richtig zusammengelesen:

    "ZERO PAGE BAD" heißt, dass der "Zero Page-TEST" fehlgeschlagen ist, nicht (zwingend) dass die Zero Page im RAM defekt ist.

    Wenn der Fehler mit der CPU mitwandert, so bedeutet dies, dass bei $00 oder $01 bei Schreiben/Lesen/Verify ein anderer Wert zurückgeliefert wird, als erwartet (Ich weiss, wovon ich rede: Beast-Board ;))

    Somit dürfte - wie bereits von kinzi vermutet - von der CPU der Prozessor-Port aka IO einen leichten Defekt haben. Mitunter funktionieren bestimmte Cartridges nicht oder auch eine angeschlossene Datasette funktioniert nicht.

  • Danke für den Hinweis.

    Gern! ^^

    Der originale DEAD TEST bringt "ZP-Fehler".

    Korrekt.

    Der gepatchte DEAD TEST blinkt 1x?

    Richtig. Das 1x blinken wiederholt sich endlos. Außerdem passiert nichts.

    Der Fehler wandert definitiv mit der CPU mit und(!) zurück?

    Auch richtig.

    Blinken denn die LEDs am Tape-Port richtig?

    Ich hatte diese ehemals mit auf mein Cartridge gelötet und nicht an den Tape Port, wenn Du denn diese LED's meinst.

    Die eine leuchtet ständig und die andere blinkt im Takt des flashens - Allerdings ist das blinken nur extrem schwach und schwer war zunehmen.

    Die ZeroPage liegt wie allen anderen Pages im RAM.

    Da lasse ich mich da gerne belehren, da ich ja ständig dazu lerne. Allerdings scheinen sich die Info's im "C64_Dead_Test_Diagnostic_Manual.pdf" und im "C64_Diagnostic_Instruction_and_Troubleshooting_Manual_(326070-01).pdf" zu widersprechen - Wenn ich es denn richtig verstehe:


    Das deckt sich mit deiner Aussage:



    Hier steht aber:


    "ZERO PAGE BAD" heißt, dass der "Zero Page-TEST" fehlgeschlagen ist, nicht (zwingend) dass die Zero Page im RAM defekt ist.

    Das ist wohl richtig - In diesem Fall schlägt der Zero Page Test dann fehl aufgrund der CPU.


    Läuft mit der dubiosen CPU das DIAG 586220 durch, insbesondere RAM- und PLA-Test?

    Nein. DIAG startet und bleibt bei RAM TEST1 stehen. Sowohl das originale als auch deine Version.


    Die Tests schlagen in meinem Referenz Board genauso fehl, sobald die CPU eingesetzt ist.

  • Die eine leuchtet ständig und die andere blinkt im Takt des flashens -

    Gut, das hört sich stark nach einem defekten I/O-Port an.

    Hier steht aber:

    Das ist definitiv falsch.


    Es wird von der CPU lediglich eine andere Adressierungsart für die ZP verwendet, das Hi-Byte ist dabei automatisch "00" (daher "Zero"-Page), wodurch die betreffenden Befehle ein Byte kürzer und um einen Takt schneller sind.

    DIAG startet und bleibt bei RAM TEST1 stehen.

    Hmmm ... das wiederum ist auch eigenartig ... der RAM TEST 1 geht von $0800 bis $7FFF, WIMRE. Da ist nix mehr mit ZP. Gut, es wird sicher ein ZP-Register dafür verwendet, müsste man mal sehen welches. Nun ja. Die CPU würde ich aufbewahren, so eine spezielle hat vermutlich sonst niemand. ^^

    "Steve Jobs hat User hervorgebracht, Jack Tramiel Experten." - Quelle unbekannt.


    Mein Herr, ich teile Ihre Meinung nicht, aber ich würde mein Leben dafür einsetzen, dass Sie sie äußern dürfen." - Voltaire.


    "Diskutiere nie mit einem Idioten - er zieht dich auf sein Niveau hinunter und schlägt dich dort mit seiner Erfahrung!" - Volksweisheit.

  • wie bereits von kinzi vermutet - von der CPU der Prozessor-Port aka IO einen leichten Defekt haben.

    Gut, das hört sich stark nach einem defekten I/O-Port an.

    So wird es wohl sein :)

    Mitunter funktionieren bestimmte Cartridges nicht oder auch eine angeschlossene Datasette funktioniert nicht.

    Zumindest die Cartridges die ich ausprobiert habe funktionierten alle (IK, Super Zaxxon, SMB64 und diverse andere Spielmodule)

    Auch das laden und speichern von Programmen von/auf Datasette funktioniert.

    Ist schon kurios.


    Das ist definitiv falsch.


    Es wird von der CPU lediglich eine andere Adressierungsart für die ZP verwendet, das Hi-Byte ist dabei automatisch "00" (daher "Zero"-Page), wodurch die betreffenden Befehle ein Byte kürzer und um einen Takt schneller sind.

    Danke! Das werde ich mir merken. Ich habe schon mehrmals von Fehlern in den alten Commodore Unterlagen gelesen...Erfahrungen machen das ja dann wett :D

    Die CPU würde ich aufbewahren, so eine spezielle hat vermutlich sonst niemand.

    Würde ich ja, aber ist nicht meine - Und vorerst bleibt sie ja vermutlich in Betrieb.

  • Mit dieser CPU lässt sich übrigens auch kein alternativer Kernal laden. Egal ob via EF3 oder direkt gesteckt:

    Welche hast du ausprobiert? Weil "direkt gesteckt" wundert mich jetzt ... via EF3 würde ich noch verstehen ...

    "Steve Jobs hat User hervorgebracht, Jack Tramiel Experten." - Quelle unbekannt.


    Mein Herr, ich teile Ihre Meinung nicht, aber ich würde mein Leben dafür einsetzen, dass Sie sie äußern dürfen." - Voltaire.


    "Diskutiere nie mit einem Idioten - er zieht dich auf sein Niveau hinunter und schlägt dich dort mit seiner Erfahrung!" - Volksweisheit.

  • Weil "direkt gesteckt" wundert mich jetzt

    kinzi: Das passiert wenn man "mal eben" etwas testen möchte zwischen Töpfe spülen und Kinder Bespassen. Man versucht einen Kernal im Sockel vom Char Rom zum laufen zu bekommen! ...Kein Plan was da in meinem Hirn ablief....:oob:

    Natürlich hast Du recht - Fakt ist allerdings das die CPU verhindert einen alternativ Kernal vom EF3 zu laden.

    :schande:


    ich lasse ja gerne die Hosen runter, dann haben andere auch was davon :D

  • Das passiert wenn man "mal eben" etwas testen möchte zwischen Töpfe spülen und Kinder Bespassen.

    :rolleyes:

    Kennen wir alles. ^^

    Fakt ist allerdings das die CPU verhindert einen alternativ Kernal vom EF3 zu laden.

    Damit das EF3 einen Kernal startet, muss dieser mal erst aus dem Menü ausgewählt werden. Wahrscheinlich klappt das mit der kaputten CPU schon nicht richtig. Weil das Aktivieren des externen Kernals braucht die CPU ja nicht unbedingt - also nicht mehr, als ein interner Kernal natürlich - das ist eine Sache, die rein im EF3 abläuft.


    Du bist dir aber sicher, dass das PLA OK ist? Weil das alles röche enorm danach und eigentlich nicht so sehr nach CPU.

    "Steve Jobs hat User hervorgebracht, Jack Tramiel Experten." - Quelle unbekannt.


    Mein Herr, ich teile Ihre Meinung nicht, aber ich würde mein Leben dafür einsetzen, dass Sie sie äußern dürfen." - Voltaire.


    "Diskutiere nie mit einem Idioten - er zieht dich auf sein Niveau hinunter und schlägt dich dort mit seiner Erfahrung!" - Volksweisheit.

  • Ultimax RAM Test hat direkt im ersten Test"Memory Error in Screen RAM Test" gezeigt - Oben Links wurde ein nicht invertiertes @ gezeigt was sich widerspricht?! . Ein reverses @ hätte sich zumindest mit dem DEAD Test gedeckt (Bit 7)

    Es ist denkbar, dass der gefundene Fehler in Bit 7 exakt in der Speicherstelle vorliegt, die zum Anzeigen des Ergebnisses benutzt wird -> dann ist die Anzeige natürlich falsch. Es wäre wohl besser, wenn der erste Testteil gleich die ganze erste Bildschirmzeile mit dem Fehlerbyte vollschreibt oder so, um auch solche Fälle erkennen zu können.

    Ultimax RAM Test besteht den ersten Screen RAM Test
    Nach dem Umschalten in Ultimax mode friert es ein

    Kleine Korrektur: Durch das Umschalten auf den zweiten Testteil schaltet man den Ultimaxmodus aus, der zweite Teil läuft komplett im RAM. Das Symptom des Einfrierens hier passt zum später festgestellten Problem mit der CPU, denn beim Start des zweiten Teils benutzt der Code den Prozessorport, um die ROMs auszuschalten.

  • Wahrscheinlich klappt das mit der kaputten CPU schon nicht richtig.

    Doch das klappt noch.

    Du bist dir aber sicher, dass das PLA OK ist? Weil das alles röche enorm danach und eigentlich nicht so sehr nach CPU.

    Der Rechner war schon zu - Aber das hat mir keine Ruhe gelassen :rolleyes:

    Also: Ich habe die CPU nochmal in mein Referenz Board gesetzt und versucht dort über EF3 ein alternativ Kernal zu laden - Und TADAAA. Es funktioniert!


    Zur Sicherheit nochmal den alten DEAD Test probiert mit meinem Referenz Board, welcher aber nach wie vor ZERO PAGE -> BAD anzeigt.

    Haben wir auf besagtem Board jetzt eine PLA welche im Betrieb eigentlich keine Störung anzeigt aber solch ein Verhalten an den Tag legt?


    Da ich genug PLA's hier habe, neige ich dazu diese noch auszulöten - Nur um es zu wissen :D


    ...Aber nicht heute - Zuviel Sonne draußen.



    Mac Bacon: Danke für deine Erklärung! Dann passt dieser Teil ja schonmal :)

  • ...Aber nicht heute - Zuviel Sonne draußen.

    Doch heute :whistling:


    Ich habe jetzt nochmal meine CPU in das Gast-Board gesetzt und es lies sich der Kernal übers EF3 Menu aktivieren.

    Dann die defekte CPU zurück ins Board - Und: Es lies sich der Kernal übers EF3 Menu aktivieren! 8\|


    Vielleicht spulen wir einfach ein paar Beiträge zurück und wir vergessen diesen Teil einfach - Keine Ahnung was ich da gemacht habe :oob:

    Also das Board scheint, bis auf den mysteriösen Fehler in der CPU OK zu sein. Für mich deutet grade nichts mehr auf PLA hin.


    Ich mach mal noch mit der Floppy weiter -Die ärgert auch noch rum.



    ...Aber nicht mehr heute - Zuviel Sonne draußen. :D

  • So Floppy auch fertig ^^


    Jetzt habe ich extra noch den 6410 NOP CPU Tester aufgebaut um mal diese CPU zu testen.


    Eine heile CPU zählt die LED‘s schön hoch - Diese CPU macht die LED‘s irgendwie aus anstatt an. Man sieht also recht deutlich das da etwas nicht stimmt :thumbsup:


    Heute so gebastelt ...


    Tolle Sachen gibt‘s... :love: