Hello, Guest the thread was called2.1k times and contains 104 replays

last post from DP64 at the

250407 Rev. B - Black Screen

  • Da liegt ein Missverständnis vor: Der Akku ist IN der CPU.

    Ach sooo. Ich hatte wegen LDA an "Akku" gedacht und danach gesucht und die Stelle der Zeropage gefunden. Zeropage = RAM, deswegen. Aber steht da wortwörtlich im Wiki "ein 8-Bit-Datenregister innerhalb der CPU MOS 6510". Besser genau lesen. :whistling:


    Würde ja aber sonst alles passen. Die beiden RAMs defekt und liefern daher nur eine 0. Kein Farbdurchlauf sichtbar vor dem Hellrot, weil es ja eigentlich das ordnungsgemäße Grau ist usw. :)


    Aber ich sehe gerade, DEC hat mit dem Akku auch gar nichts zu tun, sondern dekrementiert die Speicherzelle direkt.


    Tja, wirst du doch mal noch einen Hardware-Monitor entwickeln müssen. Nützt ja nichts. :D

  • Aber ich sehe gerade, DEC hat mit dem Akku auch gar nichts zu tun, sondern dekrementiert die Speicherzelle direkt.

    Ja, aber das Datum aus der Speicherzelle wird trotzdem in die CPU geladen und dort dekrementiert, und dann wieder zurückgeschrieben. "Read-Modify-Write" nennt sich dieser Instruktionstyp. Dauert daher auch am längsten (braucht am meisten Zyklen).


    Gut, es könnte sein, dass Bit 0 und 2 defekt sind und trotzdem die zwei oder drei Befehle richtig geladen und ausgeführt werden. Mal die Opcodes anschauen ...

    Code
    1. sei
    2. dec $d020
    3. 78 ce 20 d0 a2 ff 9a d8 a9 x. ......

    78 = 0111 1000

    ce = 1100 1110

    20 = 0010 0000

    d0 = 1101 0000


    Könnte schon hinkommen, das CE würde zu CA (Bit 2 kippt). Das ist allerdings DEX. Also doch nicht ...

    Tja, wirst du doch mal noch einen Hardware-Monitor entwickeln müssen. Nützt ja nichts. :D

    Entwickelt ist das längst (geistig), es fehlt nur noch die Implementierung. ;-)

    "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.

  • Die beiden RAMs defekt und liefern daher nur eine 0. Kein Farbdurchlauf sichtbar vor dem Hellrot,

    Stimmt auch nicht, dann müsste Bit 1 auch noch defekt sein, sonst sieht man definitiv einen Farbwechsel:


    hellgrau = 1111

    hellblau = 1110

    hellgrün = 1101

    mit.grau = 1100

    dunkgrau = 1011

    hellrot = 1010


    [EDIT]


    Wenn du den NOP-Generator reinmachst, müsste die CPU WIMRE in einer Sekunde ca. acht Mal "rund um den Adressblock" laufen, A15 müsste also mit ca. 4 Hz blinken, das müsstest du sehen. Dann wäre quasi sichergestellt, dass die CPU richtig arbeitet.


    Hast du einen "Axorpteiler"?


    [/EDIT]

    "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.

  • Gut, es könnte sein, dass Bit 0 und 2 defekt sind und trotzdem die zwei oder drei Befehle richtig geladen und ausgeführt werden.

    Könnte schon hinkommen, das CE würde zu CA (Bit 2 kippt). Das ist allerdings DEX. Also doch nicht ...

    Stehe ich da noch auf dem Schlauch? Die Opcodes werden aus dem ROM an die CPU über den Datenbus übertragen. Da ist das RAM gar nicht beteiligt. Der Bus hängt nicht, also sind die Opcodes doch nicht beeinträchtigt?


    Lediglich ein im RAM abgelegter Wert wird bei Bit 0 und Bit 2 "modifiziert", so dass ein Lesen aus dem RAM die falschen Werte bringt.


    Wenn er nach hellgrau schon abbricht bzw. loopt, zeigt er hellrot, also statt 1111 eben 1010.


    Das Hellrot, was ich sehe, ist eigentlich das Hellgrau! Oder vielleicht auch das Hellblau. Das Programm kommt gar nicht erst zum eigentlichen Hellrot. Das war so mein Gedanke.


    Entwickelt ist das längst (geistig), es fehlt nur noch die Implementierung.

    Wie gesagt, vor morgen nachmittag würde ich ich eh nicht weitermachen...

  • Stehe ich da noch auf dem Schlauch? Die Opcodes werden aus dem ROM an die CPU über den Datenbus übertragen. Da ist das RAM gar nicht beteiligt. Der Bus hängt nicht, also sind die Opcodes doch nicht beeinträchtigt?


    Lediglich ein im RAM abgelegter Wert wird bei Bit 0 und Bit 2 "modifiziert", so dass ein Lesen aus dem RAM die falschen Werte bringt.

    Sorry, Gedankensprung ... meine Annahme dabei war, dass Bit 0 und 2 von den RAMs blockiert (auf GND gezogen) werden. Wollte nur sehen, ob das sein könnte.

    Das Hellrot, was ich sehe, ist eigentlich das Hellgrau! Oder vielleicht auch das Hellblau. Das Programm kommt gar nicht erst zum eigentlichen Hellrot. Das war so mein Gedanke.

    Ja, könnte auch sein. Aber dann müssten Bit 0 und 2 auf GND klemmen. Und dann siehe vorigen Absatz bzw. oben.

    Wie gesagt, vor morgen nachmittag würde ich ich eh nicht weitermachen...

    Achso, ja dann ... alle Zeit der Welt! :thumbsup:

    "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.

  • Wollte nur sehen, ob das sein könnte.

    Ach so. Aber gestern denke ich, habe ich deutlich gesehen, dass der Bus alle Werte einnehmen kann. Deswegen würde ich einen externen elektrischen Defekt bei den Datenbits ausschließen wollen. Die beiden RAMs können ja aber trotzdem auf einem Wert "hängen", und den Bus nur (falsch) beeinflussen, wenn sie angesprochen werden. (?)


    Achso, ja dann ... alle Zeit der Welt!

    Denke so ab 16 Uhr. Versand musst du da natürlich noch berücksichtigen. Aber mit Express sollte das klappen. :D

  • Wenn du den NOP-Generator reinmachst, müsste die CPU WIMRE in einer Sekunde ca. acht Mal "rund um den Adressblock" laufen, A15 müsste also mit ca. 4 Hz blinken, das müsstest du sehen. Dann wäre quasi sichergestellt, dass die CPU richtig arbeitet.


    Hast du einen "Axorpteiler"?

    Gerade erst gesehen. Probiere ich morgen. Der erst Aufbau des Teilers von anno dunnemals müsste noch auf einem Breadboard schlummern. Wenn nicht, ist der auch schnell aufgebaut.


    Gestern mit dem Logic Analyzer lief das eine ganze Weile und rund um den Adressblock ging es da. Habe allerdings nicht darauf geachtet, ob wirklich alle Adressen bzw. auch alle Adressleitungen dabei waren:


    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.

    Du hattest ja anfangs A8 erwähnt.


    Bei den ersten Tests mit dem Logic Analyzer hatte ich auch das Modul drin. Da war zumindest auf den Leitungen, die ich da angeklemmt hatte, durchgehend Bewegung. Die CPUs (original und 8500) haben da jeweils durchgehend gearbeitet. Ob auch richtig, weiß ich (noch) nicht. Der Bildausgabe nach zu urteilen aber nicht richtig genug bzw. nicht weit genug. :)

  • Die beiden RAMs können ja aber trotzdem auf einem Wert "hängen", und den Bus nur (falsch) beeinflussen, wenn sie angesprochen werden. (?)

    Ja, aber - siehe oben - dann muss der DT zu laufen beginnen, denn der benötigt bis zum Beginn des "Initialen RAM Tests" (IRT) gar kein RAM, da läuft alles "aus dem ROM" und in den Registern. Folglich wird auch kein RAM angesprochen.


    Auch der IRT an sich benötigt für den Code kein RAM, testet(sic!) es aber halt und wenn dann ein Fehler auftritt blinkt es. So weit kommt es aber nicht.


    Hast du eigentlich den Harness dran und hat dein Harness LEDs? Sonst:

    "Dead Test" im Eigenbau


    Da sähe man, ob die CPU was tut, auch ohne Bild vom VIC.

    "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.

  • Hast du eigentlich den Harness dran und hat dein Harness LEDs?

    Nein. Ein Deadtest Harness ist mir bisher auch unbekannt. Aber die Tapeport-LEDs sind auch noch schnell aufgebaut.

    dann muss der DT zu laufen beginnen, denn der benötigt bis zum Beginn des "Initialen RAM Tests" (IRT) gar kein RAM, da läuft alles "aus dem ROM" und in den Registern. Folglich wird auch kein RAM angesprochen.

    Das ist mir soweit klar. Ich gehe auch von mindestens zwei Fehlern oder einem komplexeren Fehler aus.


    Das Board (425), was ich letzte Woche (ohne vorherige Analyse) gesockelt habe, hatte am Ende außer einem defekten 8701 lediglich zwei defekte RAMs. Das habe ich aber erst zum Laufen bekommen, nachdem ich alle RAMs (und vorher alle anderen ICs) ausgetauscht habe. Beim Zurücktauschen traten beim zweiten RAM gleich Fehler auf und wurden immer kurioser und der DT blinkte wild, aber nie reproduzierbar, die Blinkcodes waren also kaum brauchbar. Vermutlich, weil ich als erstes gleich schon ein (teil)defektes eingesetzt habe. Wenig hilfreich war auch, dass ein neues RAM ebenfalls defekt war! Die beiden oder drei haben sich irgendwie gegenseitig beeinflusst oder ich habe 8 bis 16mal nicht aufgepasst. :D


    Soll heißen, ich rechne da mit allem und glaube prinzipiell auch an Zufälle. Die Bits haben halt so schön zur Farbe gepasst. :)

  • Ein Deadtest Harness ist mir bisher auch unbekannt.

    Stimmt, gibt es auch nicht. Aber wenn man ein Check64 und damit Dead Test und Diag auf einem EPROM hat, hat man unter Umständen den Harness auch beim Dead Test dran.

    Die Bits haben halt so schön zur Farbe gepasst. :)

    "Flieder bringt den meisten RAM!" :bgdev

    "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.

  • Die RAMs für D0, D2, D4 haben schon mal keine Veränderung gebracht. Das heißt, nur eine kleine: die farbigen Bilder kommen nicht mehr bei jedem Einschalten. Das RAM für D6 mache ich morgen noch. Dann ist diese Reihe zumindest gesockelt. Das Auge RAMt ja mit.


    Den Tapeport-LED-Stecker habe ich gebaut. Da blinkt nichts, dafür leuchten beide LEDs beim URT. In einem gerade greifbaren C64 probiert blinkt da allerdings auch nichts, der Deadtest läuft aber ganz normal durch. Nun bin ich mir gar nicht so sicher, ob ich überhaupt die gepatchte Version auf dem EPROM habe. Muss ich wohl mal noch kontrollieren.


    Den Expansionsport werde ich dann auch erstmal restaurieren. Obwohl es i.O. aussieht, lässt mir das keine Ruhe. Nachher war das die (einzige) Fehlerquelle und irgendwas dort verhindert den Modulstart....


    Deadtest geht doch auch als KERNAL, oder? Also ohne Anpassungen mein ich. Einfach auf ein EPROM und in den KERNAL-Steckplatz? Dann würde ich das vielleicht erstmal probieren, um den Expansionsport zu umgehen.

  • In einem gerade greifbaren C64 probiert blinkt da allerdings auch nichts, der Deadtest läuft aber ganz normal durch. Nun bin ich mir gar nicht so sicher, ob ich überhaupt die gepatchte Version auf dem EPROM habe. Muss ich wohl mal noch kontrollieren.

    Also der 004 sollte auf jeden Fall blinken.

    Den Expansionsport werde ich dann auch erstmal restaurieren. Obwohl es i.O. aussieht, lässt mir das keine Ruhe. Nachher war das die (einzige) Fehlerquelle und irgendwas dort verhindert den Modulstart....

    Typischer Fall von "kaputtrepariert". :-P

    Deadtest geht doch auch als KERNAL, oder? Also ohne Anpassungen mein ich. Einfach auf ein EPROM und in den KERNAL-Steckplatz? Dann würde ich das vielleicht erstmal probieren, um den Expansionsport zu umgehen.

    Ja, das geht. Mir dem Unterschied, dass der C64 dann nicht im Ultimax Mode ist. Was aber erst mal egal sein sollte.

    "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.

  • Oder kaputterrepariert. War ja definitiv nicht mehr im Urzustand. :)

    Von mir aus.


    Wobei es der Vorbesitzer ja schon "kaputtrepariert" haben könnte. :-D :-P

    "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.

  • kinzi gibt es "deinen" Deadtest gar nicht als Einzelfile? Finde ich jetzt nirgends auf meiner Platte und hier nur als Bestandteil Check64 1.4 ...


    Wenn nicht, bin ich fast sicher, dass ich nur den Original-DT auf dem EPROM habe und dementsprechend gar nichts blinken kann. :whistling:


    Dann wäre auch das Mysterium hellrot gar nicht mehr so mysteriös oder anders mysteriös. :)

  • kinzi gibt es "deinen" Deadtest gar nicht als Einzelfile? Finde ich jetzt nirgends auf meiner Platte und hier nur als Bestandteil Check64 1.4 ...

    :guckstdu:Dead Test Rev 781220 Update 002 bis 005

    "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.

  • So, bevor ich den EPROM-Brenner wieder hervor hole (wer hat eigentlich dieses "Äufräumen" erfunden? Total unwirtschaftlich), ein kleines Update:


    Der Tausch vom RAM (D6) hat erwartungsgemäß nichts gebracht. Dafür bleibt es beim nun häufigeren Black statt Light Red bzw. Orange Screen.


    Dann habe ich den Expansionsport entleibt. Das ging bis auf die Masse-Pins recht flott. Der Kleber ist auch "gut" gealtert, so dass das Abhebeln ziemlich einfach ging. Und siehe da:


    Mit dem original KERNAL im Sockel kommt eine kunterbunte Einschaltmeldung ohne Cursor. Letzteres, weil die CIAs noch nicht drin sind. Aber Rahmen und Hintergrund sind richtig-blau. So tippe ich mal noch auf Color-RAM, denn auf U16(4066) und U27(LS08) sind noch die Neuteile. Di können natürlich auch was weg haben, ist aber eher unwahrscheinlich.


    DT-EPROM mache ich trotzdem mal noch. Ist vielleicht nochmal zu was nütze, auch wenn mit ein solcher (mechanischer) Fehler garantiert nie wieder unterkommt. :)


    Nächstes Update in Bälde.

  • Also ist die Expansionportbuchse "morsch"?

    "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.

  • Also ist die Expansionportbuchse "morsch"?

    Auf jeden Fall auch. Die werde ich mal auf (interne) Kurzschlüsse hin überprüfen. Von außen ist zumindest nichts zu sehen. Vielleicht war auch im eingebauten Zustand irgendwas auf dem Board gebrückt. Das kann ich jetzt leider nicht mehr nachvollziehen.


    Auf jeden Fall hat der Ausbau endlich mal eine Veränderung des Fehlerbildes gebracht! :hammer: