atari-home.de - Foren
Hardware => Hardware (Classic 16-/32-Bit) => Thema gestartet von: Lukas Frank am Fr 10.04.2026, 11:12:37
-
Habe ein defektes 520/1040STE Mainboard geschenkt bekommen. Schaue mal ob ich das wieder hin bekomme. Den U400 Combo incl. internen Blitter habe ich noch falls nötig. Seltsam das der Soundcontroller und der 74iger in der Nähe gesockelt sind und ein anderer 74iger ...
Scheint eines der letzten Boards zu sein wegen dem AJAX der verlötet ist.
-
... bißchen was gemacht.
Viele Kontakte an den vier SIMM Sockeln sind kaputt. Das erste ist jetzt alles rund um die SIMM Sockel nachzumessen und reparieren mit Patchkabeln.
-
Alles Rund um das Ram ist in Ordnung. Mainboard stellt sich tot und muss auf die Suche gehen. Nur so einen Punkt als Lebenszeichen im Terminal mit Testmodul hatte ich schon öfter aber weiss nicht mehr was der Grund war, meine ein Problem auf den Adressbus ...
-
Kennst du den Grund, weshalb die beiden RAM-Sockel ausgelötet waren? Diese 3 seltsamen Verfärbungen an den Leiterbahnen zum RAM lassen Böses erahnen.
-
Nein das weiss ich nicht aber der Lack wurde an manchen Stellen entfernt um zu messen ob die Durchkontaktierungen/Lötaugen noch in Ordnung waren denke ich mal. Vielleicht waren die alten Sockel kaputt weil da immer die Haltenasen abbrechen. Habe alles nachgemessen und geflickt, ist alles in Ordnung jetzt. Vielleicht wegen dem Fehler/Problem das es jetzt gibt?
Der Reset Elko wurde ausgelötet und ein größerer eingelötet und dabei die Leiterbahn zum Reset Taster abgerissen, habe die originalen 10uF wieder eingelötet und die Leiterbahn geflickt. Reset reagiert jetzt wieder.
-
War noch ein 220pF Kondensator C122 im 32Mhz System Clock Schaltungsteil zerbrochen.
Der Rechner bootet nicht. Unter ST-Hoch bleibt der Monitor schwarz aber die Sync Signale sind da und unter ST-Low ist der Bildschirm nur weiss. Mit einem Testmodul und über ein Nullmodem Kabel stellt sich der Rechner auch tot.
Habe mal TOS 2.06 Eproms aufgesteckt. Adressbus und Datenbus und alle Verbindungen zu den Eproms sind in Ordnung.
Problem ist zu wissen bzw. heraus zufinden ob der Video Shifter oder der Combo Baustein defekt ist weil beide fest aufgelötet sind.
Da das ROM CS Signal vom Combo Baustein erzeugt wird und beide Video Sync Signale auch denke bzw. vermute ich mal der Combo Baustein ist in Ordnung ...? H/V Sync können auch andersrum liegen anstatt auf 04 und 05 weil man die Widerstandsnummern R435 und R437 nicht zu lesen sind.
-
Du könntest Dir zum Vergleich die Bootsequenz an einem heilen STE mit TOS 2.06 ansehen. Nach wenigen /ROMCS-Pulsen solltest Du /RESET nochmal für ca. 120 Clock-Zyklen auf "low" gehen sehen, während die CPU die RESET-Instruktion ausführt.
Das sieht man in Deinem Trace nicht. Daraus folgere ich, dass die CPU nicht korrekt aus den ROMs liest. Da Du die Verbindungen (Adressbus/Datenbus) ja schon gemessen hast: vielleicht ein Buskonflikt? D.h. irgendwas anderes zieht ein Adress-/Datensignal permanent "high" oder "low"? Oder zwei benachbarte Signale sind kurzgeschlossen?
-
Halt geht nach kurzer Zeit doch auf Low ...
Auf dem Datenbus hängen ansonsten nur die vier Latches für die beiden Paddleports.
Auf dem Daten und Adressbus misst man nur die Pullups und alle Verbindungen sind da und es gibt keinen Schluss irgendwo.
-
Bin mal nach dem Service Manual vorgegangen " Troubleshooting a Dead Unit" ...
Reset = Hi
Halt = Lo
Berr = Hi
Clocksignale sind alle da also der Master Clock von 32Mhz und die 8Mhz an der CPU und dem DMA Baustein und die 4Mhz am MFP.
Da steht etwas von defektem DMA oder MFP ...? Beim DMA kann ich mir das nicht vorstellen weil da nach aussen kein Signal direkt geht, da sind Treiber dazwischen zum DMA Port.
Bin jetzt erstmal Ratlos, ist ein Risiko einfach den Combo Baustein zu ersetzen?
-
Ich habe jetzt gemacht, was ich Dir schon vorgeschlagen hatte: die Vergleichsmessung an einem funktionierenden 1040STE mit TOS 2.06. Wie bereits geschrieben, muss das /RESET-Signal noch einmal "low" werden, während die CPU die RESET-Instruktion am Beginn der TOS-ROMs ausführt.
Wir können also aus Deinem Trace folgern -- dort wird /RESET offensichtlich nicht noch einmal "low" -- dass die CPU nicht die korrekten Instruktionen ausführt. Alles danach sind Folgefehler. Wäre es mein Mainboard, würde ich mich darauf konzentrieren, herauszufinden, warum die CPU nicht die korrekten Instruktionen ausführt.
-
Ja bei mir bleibt Reset die ganze Zeit high. Die CPU läuft ja nicht weil Halt Low ist. Verbindungsproblem auf dem Board kann ich nicht finden. Oxidationsprobleme hat das Board nicht.
Service Manual sagt Combo Baustein wechseln ...?
Von außen kaputt machen kann man ja nur die vier Latches von den Paddleports die auf dem 16bit Datenbus hängen?
-
Naja, die CPU läuft schon. Sonst würdest Du keine ROM-Zugriffe (/ROMCS) sehen. /HALT kommt erst später, vermutlich als Reaktion auf einen doppelten Bus- oder Address-Error. Das ist aber ein Folgefehler, wie geschildert.
-
... nehme eine Sekunde auf und Reset bleibt die ganze Zeit high.
Schaue mal alle 16 Datensignale mit dem Oszi an ob man da etwas sehen kann?
-
Ich habe mal dreckig per Bildbearbeitung das /ROMCS Deinen Trace (rot) und aus meinem Trace (grün) übereinandergelegt. Was ich darin erkenne: Bereits bei der Ausführung der ersten Instruktion ist bei Dir ein anderes "Muster" an ROM-Zugriffen. Was mich in der Aussage bestärkt, dass die CPU andere (d.h. die falschen) Instruktionen ausführt. Entweder weil sie falsche Daten bekommt oder weil sie auf die falschen Adressen zugreift.
-
Ich weiss nur das ich zwei Rombausteine nutze die in Ordnung sind aber ich weiss nicht ob es TOS 2.06 Eproms sind oder EmuTOS 1.4 ...?
-
Oben schriebst Du noch: "Habe mal TOS 2.06 Eproms aufgesteckt.". Ich habe den STE wieder abgebaut und werde Dir keinen Referenztrace für EmuTOS 1.4 aufnehmen können. EmuTOS macht vor der RESET-Instruktion noch ein paar andere Dinge, die auf einem defekten System fehlschlagen könnten
-
Lösche morgen mal die Roms und programmiere da ein ungepatchtes TOS 2.06 drauf weil ich nicht weiss was da drauf ist, müsste sonst einen Mega ST aufbauen und sehen was das für Roms sind ...
-
Neu gemacht die beiden Rom Bausteine und getestet zuvor. Hatte mich schon gewundert weil "Halt" zu beginn meiner Fehlersuche immer High war ...
Wahrscheinlich war da ein KAOS auf den Roms ...?
Läuft aber immer noch nicht, der Monitor bleibt dunkel.
-
Testmodul gibt immer noch nichts brauchbares aus über die serielle Schnittstelle ...
-
Okay, also falsche Fährte, weil ich davon ausging, dass Du TOS 2.06 in den ROMs hattest. Nun zeigt der Vergleich: Die CPU führt Code (zumindest die ersten Instruktionen) wohl korrekt aus.
Neue Idee (aber nur wilde Spekulation, dieses Mal): irgendein Problem mit dem MFP oder mit den Verbindungen zum MFP? Der wird ja auch für die serielle Ausgabe des Testmoduls verwendet.
-
Messe den MFP mal komplett nach und schaue ob der Quarz in Ordnung ist am MFP und wenn ich nichts finde löte ich mal einen Sockel ein und tausche den das Verzweiflung ...
-
MFP alle Pins nachgemessen und alles da ausser /IACK ...
Vias vom MFP Pin 45 hin zum Combo Baustein sind alle in Ordnung. Das Problem sind die Verbindungen unter dem Combo Baustein also die die nach innen laufen. Hatte sowas schon einmal. Überprüfe die mal alle die nach innen laufen ...
/IACK an Combo Pin 83 neu verlegt aber das hat nicht geholfen, das Verhalten ist immer noch das gleiche.