petSD+ will nicht am CBM8032

There are 105 replies in this Thread which has previously been viewed 9,191 times. The latest Post (August 16, 2024 at 12:02 AM) was by axorp.

  • Wenn der schon getauscht wurde, bleibt immer noch Bit5. Wenn da alles sauber eingelötet wurde, sollte man den VIA ausschließen können. Und das könnte ein Treiber dahinter sein. Hatte ich bisher noch nie, aber möglich ist alles.

    Welcher Pin des Chips wäre denn Bit5 ? Ich habe zwar sorgfältig gelötet (und das Problem Bestand ja auch schon vorher), aber nachprüfen würde ich es trotzdem gerne.

  • ja, eben. Die 6420 treibt die Daten, UB15 nur einige Steuersignale (eben NRFD).

    Ich sehe aber grade, das Buch zählt ab 0, das Datasheet ab 1.

    Es sind also Pin8 und 15

  • Ja, aber es geht doch darum, mal zu prüfen, ob ich beim einlöten des Sockels bei UB15 nicht unbemerkt ein Problem geschaffen habe... Deswegen die Frage, welcher Pin von UB15 dieses besagte Bit5 ist...

    ...oder verstehe ich hier etwas völlig falsch ?

  • Nicht völlig .)

    Das Sockellöten könnte das Problem mit dem als fehlerhaft gemeldeten NRFD Signal erklären.
    Dazu vor allem

    UB15 PIN11 (NRFDout) und PIN 16 (NRFDin) kontrollieren.

    Datenbit5 wird wie gesagt von der PIA UB16 gesteuert.

    Ich hab nochmal Quellcode und Schema abgeglichen, und ich war bei den IN-Bits einen Pin verrutscht Pins (das neben der Arbeit zu machen ist so ne Sache :) )

    Es sind:

    UB16 PIN7 (Bit5in) und PIN 15 (Bit5out)

  • So, ich habe generell nochmal auf Lötfehler an den Sockeln geprüft, aber insbesondere bei:

    - UB15 PIN11 (NRFDout) und PIN 16 (NRFDin)

    - UB16 PIN7 (Bit5in) und PIN 15 (Bit5out)

    Da ist aber definitiv alles in Ordnung.

    Eine Frage nochmal zu dem Testprogramm... Während des Tests soll aber kein Gerät per IEEE angeschlossen sein, oder ?

    Das abgetippte Programm habe ich gerade auch nochmal auf Tippfehler überprüft, das ist sauber.

  • So richtig viel nicht, was du nicht schon mit dem Programm überprüft hast.

    Btw, deine Zeile 70 ist noch falsch irgendwie. Das Zeichen ist das invertierete Herz. Das sollte den Screen clearen, kein Herz malen :) Einfach mal durch print chr$(147) ersetzen.

    Ich würde auch nochmal Zeilen 100 bis 180 und 520 bis 600 überprüfen. Einfach um sicher zu gehen.

  • OK, das mit dem Herz kam mir auch schon ein bisschen komisch vor, aber ich gehe das Programm gleich nochmal durch.

    Nochmal die Frage nach dem Ersatz für die MC3446N... Kann man da auch DS8839N verwenden ? Hier mal das Datenblatt dazu:

    Please login to see this attachment.

  • Die Sache mit dem Herz habe ich beseitigt, jetzt läuft das ganze auch nicht mehr endlos durch, sondern löscht den Bildschirm und schreibt das Ergebnis immer wieder an die gleiche Stelle...

    Please login to see this attachment.

    Ich bin durch die besagten Zeilen nochmal durchgegangen, habe aber keinen Fehler gesehen. Aber manchmal sehen mehr Augen ja auch mehr, deshalb hier mal zwei Screenshots:

    Please login to see this attachment.

    Please login to see this attachment.

  • 570 if a=0 then goto 600

    590 if a=0 then goto 610

    da hast du jeweils "if a=c..." stehen

    Ach das gibts doch nicht... drei Mal hab ich den Kram durchgelesen und das nicht gesehen...? Ich änder das mal schnell...

  • Wenn ich das korrigiere, sieht die Ausgabe wie folgt aus:

    Please login to see this attachment.

    NRFD IS BAD ist also verschwunden.

    Ändert nichts an der weiteren Vorgehensweise (MC3446N tauschen), oder ?

  • Naja, in dem Fall sind mögliche Ursachen die PIA UB16 oder der MC3446N in UC12. Ich würde da eher die PIA vermuten.

    Wenn du auf Sete 2 des schemas schaust siehst du, dass die die Datenbits verarbeitet (DIO1-8 am Port, an der PIA aufgeteilt in rausgehend DO1-8 und reinkommend DI1-8 an den Ports A und B der PIA. (PA0-7 / PB0-7).

  • Btw, ich habe das Programm auch mal abgetippt (dachte ich bin schlau mit OCR, was aber auch nur bedeutete jede Zeile überarbeiten zu müssen.

    Im VICE meldet er ATN fehlerhaft, aber am 8032 läuft er fehlerfrei durch.

    Für die die es interessiert:


    GPIB Diagnostic Test aus PET and the IEEE 488 Bus (GPIB)

    Please login to see this attachment.

  • Naja, in dem Fall sind mögliche Ursachen die PIA UB16 oder der MC3446N in UC12. Ich würde da eher die PIA vermuten.

    Wenn du auf Sete 2 des schemas schaust siehst du, dass die die Datenbits verarbeitet (DIO1-8 am Port, an der PIA aufgeteilt in rausgehend DO1-8 und reinkommend DI1-8 an den Ports A und B der PIA. (PA0-7 / PB0-7).

    Für die PIA auf UB16 habe ich drei Ersatzchips da, die alle drei den exakt gleichen Fehler liefern... Eher unwahrscheinlich, oder...?

    Was liegt denn vor der PIA ? Vielleicht erhält die PIA ja schon Mist und ist gar nicht verantwortlich dafür ?

  • Die hängt direkt am Daten- und Adressbus der CPU, selbst ohne Treiber dazwischen. (mit Ausnahme von x8xx, aber wenn das flaky wäre würde sie garnicht angesprochen werden. Dann bleibt nur noch UC12.