bin mir aber nicht ganz klar, ob der Rechner hiermit zurecht kommt (wenn der Programmcode länger als eine Zeile ist):
Basic Zeilen können zwei Bildschirmzeilen lang sein, das ist kein Ding
petSD+ will nicht am CBM8032
- Snocksman
- Thread is marked as Resolved.
-
-
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.
-
Pin14 UB16 (bit5 out)
Pin6 UB16 ist Bit5in
-
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
-
Nicht völlig .)
Das Sockellöten könnte das Problem mit dem als fehlerhaft gemeldeten NRFD Signal erklären.
Dazu vor allemUB15 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 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. -
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...
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:
-
570 if a=0 then goto 600
590 if a=0 then goto 610
da hast du jeweils "if a=c..." stehen
-
Nochmal die Frage nach dem Ersatz für die MC3446N... Kann man da auch DS8839N verwenden ?
Passt nicht.
-
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:
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) -
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.
