C64 funktioniert, aber kein cursor
- saticon
- Thread is Unresolved
-
-
Wäre schön wenn es die PLA wäre, der Nachbau-Ersatz ist günstig.
Jetzt spinnt auch mein 1541-II Diskettenlaufwerk herum. Seit dem no-cursor Problem macht es beim laden ein "Brrrrrrrrrrrrrrrr" hochfrequenter als ich es sonst je gehört habe. Das passierte ca. 2-3 mal. Jetzt liest das Laufwerk keine Disketten mehr, d.h. es reagiert auf den Loadbefehl, der Bildschirm zeigt nur ein ready und die Laufwerks LED blinkt.
-
Reinige mal bitte den Kopf. Mehrmals !!!
Schiebe den Kopf dann wieder in die Mitte. Er müsstewahrscheinlich am Rand Richtung Buchsen stehen.
Natürlich ist das Gerät ausgeschaltet und die Diskette draussen.Dann versuche mal eine Disk zu formatieren.
-
Fehlerkanal auslesen
-
Versuche mal das Laufwerk mit Diskette zu initialisieren.
open 1,8,15,“I“:close 1 -
Hab das Laufwerk geöffnet, der Kopf war ganz vorne. Kopf gereinigt und in die Mitte geschoben, jetzt läuft er erstmal wieder. Ein kaputtes Laufwerk hätte mir gerade noch gefehlt. Erst 160€ in den C64 gesteckt, dann geht alles im A........
In der Zwischenzeit habe ich Mayham in Monsterland von Diskette geladen und C64OS ausprobiert, funktioniert bestens. Hab das Mainboard mittlerweile aus dem Gehäuse genommen. Der Cursor ist immernoch weg
Dann habe ich noch einen RAM Test gemacht, von JMP$FCE2. Auch da ist alles ok, aber die Zeropage wird nicht getestet. Jetzt könnte ich eine Test-Cartridge gebrauchen.
(Der Kühlköper auf dem SID ist nur mit Arctic-MX Kühlpaste befestigt. Es bewegt sich keinen Millimeter. Auch nicht als das Board ein Jahr hochkant im Regal stand.)
-
Ich würde vor PLA-Nachbau-Kauf ja echt mal das ZP-RAM testen, denn
Es könnte noch an einem RAM-Fehler in der Zeropage liegen, bei $cd liegt z.B. der Zähler für das Cursorblinken.
-> Speicher testen!
... und bei $CC liegt der Status (blinken oder statisch)
auch ohne CRT mal folgendes machen (funzt nur als Programm, nicht im Direktmodus AFAIK)
und erzähle, was passiert
-
mal ein ganz anderer ansatz:
laufen die Uhren eigentlich (beide) ? Könnte mir vorstellen das die es auch nicht tun...
-
-
Ich würde vor PLA-Nachbau-Kauf ja echt mal das ZP-RAM testen, denn
Es könnte noch an einem RAM-Fehler in der Zeropage liegen, bei $cd liegt z.B. der Zähler für das Cursorblinken.
-> Speicher testen!
... und bei $CC liegt der Status (blinken oder statisch)
auch ohne CRT mal folgendes machen (funzt nur als Programm, nicht im Direktmodus AFAIK)
und erzähle, was passiert
Mittlerweile habe ich auch die Flussmittelreste (topnik tk83) vom Board geputzt die ich noch dran gelassen hatte.
Hier sind die Ergebnisse der Programme:
-
Und was ist mit den Uhren?
Läuft ti$ ? Besser mal mit nem Diag Programm beide Uhren prüfen...
-
Scheint allles Ok zu sein. Das sind die Testprogramme die ich auf Anhieb gefunden habe: CIA Diagnostic und CIA Time of Day (ToD) Clock Test von Gold Beaver
Ist es vielleicht ein Bitflip in der JiffyDos ROM, oder so? Oder vielleicht fühlt sich mein C64 entwürdigt durch diesen ganzen neumodischen Schnickschnack den ich an ihm angebracht habe ... jetzt hasst er mich
-
Besser ist ein Check64 oder Harness.
Da werden beide Uhren angezeigt
-
Hier sind die Ergebnisse der Programme:
Blinkt der Cursor denn nun oder nicht? Auf dem linken Bild sieht man ihn ja zumindest schon mal.
Der siebte angepinnte Thread in der Reparaturecke enthält auch noch einen passenden Speichertest...
-
Hier sind die Ergebnisse der Programme:
Blinkt der Cursor denn nun oder nicht? Auf dem linken Bild sieht man ihn ja zumindest schon mal.
Der siebte angepinnte Thread in der Reparaturecke enthält auch noch einen passenden Speichertest...
Er blinkt nicht. Er bleibt einfach statisch, so wie auf dem Bild.
Den Speichertest aus der Reparaturecke hab ich ca. 10 minuten laufen lassen. War das genug?
-
Den Speichertest aus der Reparaturecke hab ich ca. 10 minuten laufen lassen. War das genug?
Ja, in diesem Fall schon. Am ZP-RAM liegt es also auch nicht.
Ist es vielleicht ein Bitflip in der JiffyDos ROM, oder so?
Ich denke ja, jedenfalls fällt mir nichts anderes ein.
-
Ist es vielleicht ein Bitflip in der JiffyDos ROM, oder so?
Hast du denn kein anderes Kernal zum ausprobieren?
Oder ein Easyflash3 Modul?
Könnte man nicht per Software einfach ein Kernal laden, kann man zwar nicht vernünftig mit arbeiten aber zum testen könnte es doch ausreichen oder? -
Könnte man nicht per Software einfach ein Kernal laden, kann man zwar nicht vernünftig mit arbeiten aber zum testen könnte es doch ausreichen oder?
Kann man.
- Kernal-File organisieren.
- Checken, ob die Ladeadresse "vorne dran" steht. Ggf. ergänzen ($E000).
- Kernal auf Disk kopieren.
- Kernal mit LOAD"xxx",8,1 nach $E000 ins RAM laden.
- Mit POKE 1,53 auf Kernal im RAM umschalten.
Ich bezweifle allerdings, dass im ROM genau ein Bit so gekippt ist, dass der Fehler sich so auswirkt.
-
Kann der 74LS139 U15 nicht auch als Fehlerquelle in Frage kommen? 🤔
-
Nein.
Der 74LS138 Steuert SID, Color-RAM, CIAs und I/Ox an.
Mit der Cursor-Darstellung hat der nichts zu tun.