Da die Einschaltmeldung keine inversen Zeichen darstellt, könnte das Verhalten so erstmal in Ordnung sein. Es blinkt nur der Cursor.
Ändert sich an der Leitung was, wenn ständig ein inverses Zeichen in den Bildschirmspeicher geladen wird?
So z. B.:
10 for i = 1024 to 2023: poke i,128: next i
20 goto 10
Ist so Aktivität feststellbar? Kann das selbst erst heute Abend ausprobieren.
Ich habe ein bißchen mit dem CharROM im Emulator rumgespielt. Ich habe dabei festgestellt, dass meine Aussage von eben bzgl. SA7 leider nicht richtig ist. Jedes anzuzeigende Zeichen benötigt im CharROM 8 Bytes Speicherplatz. Im CharROM sind die inversen Zeichen erst ab der der Speicheradresse 8 x 128 = 1024 bzw. $0400 hinterlegt. Da hatte ich einen Denkfehler. Somit wäre die Leitung, die nicht richtig funktioniert TA10 am CharROM, also Pin 19. Die kommt quasi direkt von der MMU 8722 auf U7 (dort Pin 8). An der Leitung hängt auch noch der Multiplexer auf U15 (Pin 5) sowie der Oktalbus-Transceiver U62 (Pin 13). Und die Leitung geht ebenfalls an den ExpansionPort. (Kontakt M). Ich würde jetzt sagen, dass der Fehler wohl eher dort zu suchen.
Hallo, ich meinte Pin 18 von U55 = Pin 1 am CharROM.
Das ist die Shared-Adressleitung SA7. Mit dem Logic Probe schauen, ob sie sich wesentlich anders verhält, als die anderen Shared-Adressleitungen SA0-6. Vielleicht kann SA7 zwar auf LOW gezogen werden, aber nicht auf HIGH oder sie bleibt TriState. Auf der Leitung hängen auch noch U17 (74ALS373 mit Pin 19) und U19 (SRAM 2016 mit Pin 1) und sie geht auch noch zum ExpansionPort (dort Kontakt: R).
An U55 sind:
SA6 ist Pin 16
SA5 ist Pin 14
SA4 ist Pin 12
SA3 ist Pin 11
SA2 ist Pin 13
SA1 ist Pin 15
SA0 ist Pin 17.
Ich komme darauf, weil scheinbar nur die obere 4K-Bank des CharROMs mit den inversen Zeichen nicht korrekt funktioniert, die untere aber schon. Dies wird durch SA7 umgeschaltet.
Wie wäre es mit einem Problem mit dem Oktalbus-Transceiver auf U55? Vielleicht kann das CharROM nicht richtig adressiert werden. PIN18?
Ah sorry, überlesen.
Hast Du einen Eprom-Brenner, mit dem Du das CharROM auslesen kannst? Dann könnte man die entstandene Datei im Emulator testen. Sofern der Fehler dort auch auftritt, wäre das CharROM defekt.
Es lässt sich schlecht erkennen, ob bei C107 und an einem Bein des Oszillators nicht vielleicht korrodierte Leiterbahnen sind. Ist C107 vielleicht ausgelaufen? Das könntest Du mal überprüfen. Und auch den VIC mal in einem anderen Rechner testen.
Dankeschön für die Auskunft. Der sollte sich besorgen lassen.
Gesendet von meinem XT1032 mit Tapatalk
Ich habe hier einen defekten Hilfstransformator in einem der SX-Netzteile, den ich ersetzen muss. Hat jemand Informationen über einen Ersatztyp, den man heute noch bekommt?
Vielleicht liegt es ja hieran:
"Warning: This version only for device with NEON support.
For device without neon support, as tegra2, will be published separate version later"
Kenne mich aber auch nicht damit aus.
Der Transistor Q2 könnte defekt sein. Wäre einen Check wert.
Das "Fehlerbild" liegt am 02er Kernal wegen des FarbRAM-Bugs. Hab ich bei meinen auch. Kannst Du so lassen.
Man sollte nicht außer Acht lassen, dass das Gate Array auf UC4 direkt an der ATN-Leitung des Busses hängt, so dass es bei einem Defekt des IC zu Problemen mit dem IEC-Bus kommen kann.
Schwierig. Mir würde noch einfallen, die Transistoren Q2, Q3 und Q5 zu kontrollieren, den Speicherbaustein und die nachträglich eingebaute IEC-Buchse. Ich vermute mal, dass es mit Ersatzteilen für die Gate Arrays und den Hybrid-IC wohl eher schlecht aussieht. Die Dioden gehen ja eigentlich auch nicht kaputt.
Also laut Schaltplan sollte auf UC6 ein 74LS04 sein, kein 7406.
Toll das das Teil wieder läuft .... 
So wie es aussieht, ist da ja noch der Originalsockel für den VIC auf dem Board. Bedenkenswert ist, dass sich die Wärme vom VIC auf den Sockel überträgt und es daher zu Kontaktproblemen kommt. Der Sockel ist immerhin über 30 Jahre alt. Ich würde wohl den Sockel gegen einen Neuen auszutauschen oder zum Testen auch mal nen Präzisionssockel in den vorhandene Sockel zu stecken. Ich hab schon häufiger erlebt, dass gerade die Sockel bei VIC und SID "marode" werden.
Der Thread ist zwar schon etwas älter, aber ich hab das mit dem Burstmode im C64 vor einiger Zeit mal nach folgender Anleitung ausprobiert:
http://www.cs.tut.fi/~albert/Dev/burst/
Ich habe die Version mit der CIA1 genutzt. Hat grundsätzlich funktioniert, ist aber nach meiner Erfahrung nicht sehr kompatibel.
Auf dem 1. Bild ist CIA 1 mit der Kerbe nach unten im Sockel. Ist das immer noch so?
Aber ich meine es braucht auch die Indexlocherkennung für das MFM-Format.
